検索エンジン チューニングのポイント
検索エンジン を 高速化 するには
前回に続いて 検索エンジン のチューニングのポイントについてです。
以前何かのインタビューで、 検索エンジン の 高速化 について、F1マシンのようなものでどこか突出する部分があるのではなく、総合的に 高速化 することが重要ということを述べました。
===============
【MarkeZineインタビュー】
人手不足のスーパーマーケットに朗報！ECのノウハウ満載の「販売予測システム」が自動仕入れを実現（https://markezine.jp/article/detail/26473）より引用
山崎：予測ロジックというと一撃必殺のようなイメージを持たれがちですが、実は小さなノウハウの積み重ねで、実に泥臭いものなんです。
例えて言うなら、F1の車があれだけ高速で走れるのは、決して「すごいエンジン」を積んでいるからだけじゃない。
タイヤ一つ、ネジ一つという技術の積み上げですよね。
ゼロスタートの予測ロジックは、そうした職人的な全体性能の高さで成り立っているんです。
===============
処理速度を決めるのはボトルネックなので、バランス良く 高速化 する必要があります。
ただ「総合的に 高速化 することが重要です」ではあまり参考にならないので、いくつかポイントをピックアップしてみます。
インデックス を改善するメリット
まず検索エンジン といえばやはり特徴的なのが インデックス です。
インデックス そのものについてどこまで解説するかは微妙ですが、よく言われるのは索引という表現です。
間違ってはいないというかまさに インデックス は索引ではあるのですが、あまり索引という表現で インデックス の機能のイメージは伝わらないような気がします。
もちろん、エンジニアにとっては インデックス というだけでピンと来ると思いますが。
簡単に言えば、「その情報がどこにあるかについての情報」です。
インデックス がない場合、情報を検索するには基本的に全部のデータを端から順に最後までチェックする必要があります。
インデックス を作成しておくと、任意の情報がどこにあるかはインデックスを見るだけでわかります。
現在のところ、大量のデータを検索する場合、 検索エンジン にかぎらずこの インデックス は必須なテクノロジーだといえます。
そして 検索エンジン のチューニングにおいては、 インデックス を作ること自体は当然として、どういった インデックス を作るかが、かなり重要なポイントになります。
インデックス はその特性上、 インデックス の作成時とその参照時が別のタイミングになりますが、どういう インデックス を作るかは作成時の負荷をそこまで大幅に変えない割に、参照時の負荷を大幅に変えることが可能です。
ROIではないですが、 インデックス の改善は低コスト高リターンが望める取り組みだということです。
また、 インデックス は作成時と参照時で、要求される速度の単位が違います。
もちろん作成時の速度もかなり重要ではあるのですが、参照時(すなわちECにおいては消費者が検索を実行しているタイミング)では速度的には1秒以下の争いになります。
このため、 インデックス は作成時にいかに注力するかが重要なのです。
インフラ改善による 高速化
インデックス はデータフォーマットとしてのチューニングだといえますが、インフラとして重要なのは処理の並列化です。
処理の並列化にはさまざまなレイヤがあります。
UIとしての並列化、プロセス・スレッド・socketなどのレベルの並列化などです。
検索エンジンの挙動には関係ないですが、検索結果をクリックした際にそのページが瞬時に表示されるような実装が増えてきています。
これは検索結果を表示して、人間がそれを眺めている間に、結果上位のページを先読みしているなどで実現されています。
これによってWebなのにあたかもローカルにデータのあるアプリであるかのような速度感が実現できます。
UIとしての並列化は基本的に、人間はコンピュータより数千倍遅いという特徴を活かして行われることが多いでしょう。
並列化していない場合、コンピュータが結果を表示して人間がそのどれかを選んでクリックするまで、例えば99%くらいの時間はなにもしていないことになります。
この(例えばですが)99%の時間を活用することで、人間にとっての処理を高速化することができるということです。
並列化できれば更に高速化も可能
こうしたUI(というよりUX)による 高速化 は、システムのデザインにも関わってきますし、必ずしもどのケースでもうまく行くとは限りません。
その代わり、うまくハマればかなりの 高速化 にも繋がります。
これに対してインフラ面の 高速化 は、比較的汎用性の高いチューニングとなります。
一つのCPUがある一ユーザにかかりっきりになることはないので、様々なユーザの様々な検索を順次処理していくことになりますが、処理をノンブロッキング&非同期化することによって、UXによる並列化のように、とある処理の待ち時間に別の処理を行うことが可能になります。
ただUXの場合、人間による処理の待ち時間の活用に対して、インフラ面の場合はCPUの待ち時間の活用なので、数千倍というようなレバレッジは望めません。
その代わり適用出来るケースが多くなるため、積み上げればトータルでかなりの 高速化 も実現できます。
ちなみにこの、ノンブロッキング&非同期化による並列化は、検索エンジンだけでなくコンピュータを使用する処理全般で有効なチューニングであり、またそれについてここでは詳しく書きませんが、情報はたくさんありますので(そのかわり真贋怪しい情報も多いですが)興味のある方は調べてみてください。
ノンブロッキングと非同期化は両方同時に実装することが重要なのですが、本質的に重要なのは非同期化であり、その実現のためにノンブロッキングとの併用が重要、だといえます。
■ZETA CXシリーズ■
・サイト内検索エンジン・EC商品検索 「ZETA SEARCH」
・レコメンドエンジン「ZETA RECOMMEND」
・レビューエンジン「ZETA VOICE」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【著者情報】
ZETA株式会社
代表取締役社長 山崎 徳之
【連載紹介】
[gihyo.jp]エンジニアと経営のクロスオーバー
[Biz/Zine]テクノロジービジネスの幻想とリアル
[ECZine]人工知能×ECことはじめ
[ECのミカタ]ECの役割
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
– 前の記事 –
用語解説 検索クエリ
– 次の記事 –
用語解説 検索の ドリルダウン
