PHPで巨大データ検索の高速化: strposと計算量の重要性

2025/03/23 PHPerKaigi2025 LT大会
PHPで巨大データ検索の高速化：strposと計算量の重要性

PHPで大量データを扱う際、コードが正しく動いていても、パフォーマンスの低下が発生し、ユーザーの離脱につながったりすることがあります。
本トークでは、私たちのプロジェクトで直面した「strposによる文字列検索が原因で処理が30秒以上かかった」事例をもとに、計算量の重要性とパフォーマンス最適化についてお話しします。

問題の背景は、数千件の文字列を1件ずつ、約1万件の集合と照合する処理でした。
文字列の部分一致のチェックをstrposで実装していましたが、線形検索（O(n)）のため、1回の検索がミリ秒単位でも、繰り返し処理が積み重なり、最終的には数十秒に達しました。
処理の遅延が原因でタイムアウトが発生し、ユーザーが機能を使えない危機に直面しました。

解決策として、array_flipとarray_key_existsを用いて、検索処理をハッシュベース（O(1)）に変更することで、処理時間を30秒から約6秒に短縮しました。
この経験を通じて、パフォーマンス問題を解決するには計算量の意識が不可欠であると学びました。

このように、1回の処理がわずか1ミリ秒遅延しただけであっても、大規模データでは致命的な影響を与える可能性があること、計算量や計算時間が特に大事になってくることを学びました。
このようなパフォーマンス改善は、ユーザー体験を向上させ、機能の価値を最大化するための重要なステップです。
ユーザーが快適に使える環境を提供するため、私たちエンジニアが取り組むべき課題を一緒に考えてみませんか？

https://fortee.jp/phperkaigi-2025/proposal/1740b466-cd6f-4895-8362-2f16c8ace62e

Transcript

1. PHPで巨大データ検索の高速化
 strposと計算量の重要性
 PHPerKaigi2025 2025/03/23
 NE株式会社 まさき。

2. 2 実装するときに
 「計算量」って意識してますか？

3. 3 私はあまり意識できてなかったです

4. 4 扱うデータが多くなってくると
 計算量を意識していかないと
 ときにユーザー体験をも
 悪化させちゃいます

5. 5 ユーザー体験を良くするためにも
 「計算量」を意識して実装しましょう！という 話をします！

6. まさき。
 NE株式会社 (開発者兼プロダクトオーナー)
 小田原を捨てて(ないよー)横浜市民に！
 
 その他
 - 引っ越し時はサブスクや届くはずの郵便物が遅延してないか気にしま しょう
 - ノベルティBOXが小田原に配達されてしまって受け取ったのがそれから1 週間後
 - 転送料金がかかる。4つくらい払って4000円くらいの出費、、、 
 - アニメDr.STONEに今更ながらハマり、最新話に追いつきました 
 6
7. ロードマップ
 1. 導入と自己紹介
 2. 直面した課題
 3. 原因の追求と解決
 4. まとめ
 7
8. ロードマップ
 1. 導入と自己紹介
 2. 直面した課題
 3. 原因の追求と解決
 4. まとめ
 8
9. strpos
 9
10. strposの使用例
 10 <?php $text = "PHPで巨大データ検索の高速化 :strposと計算量の重要性 "; if (strpos($text, 'PHP') !== false) { var_dump("あったよ！ "); }
11. str_containsをつかうべき？
 可読性を高められるので、
 PHP8.0以降なら使いましょう！　　　　　　　　　
 (内部的にはstrposと同じphpmemnstrを呼び出す)
 11
12. 計算量(ここでは時間計算量)
 12 プログラムが処理を実行する際にどのくらいステップ数を必要とするか
 
 データ数が増えたときに計算量も増えるアルゴリズムだと処理にかかる時 間が伸びてしまう
 
 プログラムの速度を見積もる際に、
 データ量に対する処理時間の増え方を考える
 → O記法(オーダー記法)で評価する

13. O記法(オーダー記法)
 計算量の目安を表す。
 
 O(1): データ量が増えても一定　　　　 例: 連想配列のキーから値の取得
 O(N): データ量が増えると計算量も比例し て増える 例: strposでの検索
 
 13
14. 計算量に関してはこちらがオススメ！
 14 PHPerのための計算量入門 /Complexity101 for PHPer - Speaker Deck
15. 今回やりたいこと！
 複数の文字列がスペース区切りで指定されたときに、
 それらを多く含むテキストを特定するアルゴリズムをPHPで実装
 15
16. 検索スコアリングのアルゴリズム
 16 <?php for (テキストのリストでループ ) { for (検索キーワードのリストでループ ) { if (strpos(検索キーワード , テキスト) !== false) { //テキストで見つかったキーワードの数をカウント } } } // もっともキーワードの数が多かったテキストを採用
17. 問題に直面！
 数万件のテキストデータを対象に最大1万回程度検索を行った結果、 処理に30秒以上かかる事態に！
 17
18. ユーザー離脱、、、
 30秒以上も待たされたら当然ユーザーは離脱。
 タイムアウトで画面が開かなくなり機能を使えない。
 → ユーザー体験は最悪
 18
19. ロードマップ
 1. 導入と自己紹介
 2. 直面した課題
 3. 原因の追求と解決
 4. まとめ
 19
20. ボトルネックの特定
 ログで各処理の実行時間を計測し原因を特定
 20 <?php $start = microtime(true); if (strpos(検索キーワード , テキスト ) !== false) { //テキストで見つかったキーワードの数をカウント } $end = microtime(true); logger()->debug("Execution time: " . ($end - $start) . " sec");
21. 原因はチリツモだった
 1つ1つの処理は大して遅くないけど、
 膨大な回数実行されているのが原因！
 21 0.001ms = 1μsだとして、30秒を超えるには、
 3000万回のループ = 1万件のデータ × 3000個のキーワード

22. 解決策
 1. 必要になる検索回数の見直し！
 2. 線形探索O(N)をハッシュO(1)に！
 22
23. 解決策1 必要になる検索回数の見直し
 ターゲットユーザーのデータ量を分析し、実際に耐えないといけない負荷を決定
 
 私たちが使って欲しいと考えているユーザーはどのくらいの規模のテキストデータを持っ ているのか？
 → ターゲット層は、1万くらいあれば十分。最大だと100万ある可能性もある。
 
 どのくらいの検索キーワードを持っているのか
 → ターゲット層は3000くらいあれば十分。最大だと数万。
 23
24. 解決策1 必要になる検索回数の見直し
 ターゲットユーザーのデータ量を分析し、
 実際に耐えないといけない負荷を決定
 
 ターゲット層の使用データを分析して中央値を参考に
 1万件のテキストデータ×最大3000回の検索に限定！　　　　　　　　　
 24
25. 解決策2 線形探索O(N)をハッシュO(1)に！
 
 25 $texts = [ // strpos エスティーアールポス 読み方 日本語 [ 'strpos' => 0, 'エスティーアールーポス' => 1, '読み方' => 2, '日本語' => 3, ], // str_contains 使い方 [ 'str_contains' => 0, '使い方' => 1, ], ]; 検索される側が連想配列のキーに
 キーワードを持っていれば、
 1発でそのキーワードがそのテキストに
 含まれるかがわかる

26. 解決策2 線形探索O(N)をハッシュO(1)に
 26 <?php // テキストに含まれる単語をキーに持つ連想配列のリストを作っておく for (連想配列のリストでループ ) { for (検索キーワードのリストでループ ) { // 1発でそのテキストにそのキーワードが含まれているかがわかるようになった O(1) if (isset(連想配列[検索キーワード ])) { //テキストで見つかったキーワードの数をカウント }　 } } // もっともキーワードの数が多かったテキストを採用
27. その結果...
 30秒以上かかっていた処理が約6秒に短縮！
 もちろん6秒はWebサービスにしては長いので改善の余地はまだまだある。
 計算量を意識することでパフォーマンス改善につながり、
 結果としてユーザー体験を改善できた。
 27
28. おまけ
 28 ChatGPTと話しながら資料作成してたら、もっと良い改善提案された
 分割コストさえ問題にならないならarray_intersectが最適な気がする

29. まとめ
 O(N)の処理を膨大に繰り返した結果、パフォーマンスが破綻。
 ✅ 仕様を見直して繰り返し回数を削減
 ✅ ハッシュでO(1)に最適化
 
 処理の計測 → ボトルネックの特定→ 計算量削減 の流れが重要。
 小さな遅延も積み重なればUXを損なうと実感。
 
 もっと良い方法があればぜひ教えてください！
 29
30. 30 ユーザー体験を良くするためにも
 計算量を意識して実装しよう！