検索サーバーの仕組み（Elasticsearch）

Elasticsearch

前回書いたHTTPの仕組み（クライアント/サーバー）のアプリケーションサーバーで出てきた検索サーバーの一つである、Elasticsearchについて簡単に調べてみた。Googleの検索エンジンはElasticsearchのような検索サーバーの仕組みを利用している。

Elasticsearchとは？

Elastic社が開発している、スケーラビリティ（拡張性）に優れた全文検索エンジン。
特徴は大きく3つ

RDBとの違い

検索という観点では、RDBでSQLを発行して検索結果を取得するという方法もあるが、RDBでSQLを発行して検索する際は、基本的にはデータベースにあるデータを一行ずつ検索結果に合致するか判定しながら抽出するので、データベースのデータ量が多いと時間がかかる。ウィンドウ関数を使って定義した集合毎に条件分岐をして抽出することで解消できる部分はあるだろうが、完全には解消できない。仮にadd_indexでカラムにインデックスを付けたとしても、RDB内にインデックスを設けることになるので、負荷がかかってしまうので、やはり大規模なデータ処理にはElasticsearch（検索サーバー）を使った方が良さそう。

以下、RDBとElasticsearchの特徴
参照：3分で分かった気になる、Elasticsearchとは？

以下、呼び方の違い

RDB	Elasticsearch
データベース	インデックス
テーブル	マッピングタイプ
カラム	フィールド
レコード	ドキュメント

 

全文検索って何？

全文検索の前にまず、検索とは「データのまとまりの中から目的のデータを探し出すこと」
そして、全文検索とは、複数の文書ファイルから特定の文字列（キーワード）を検索するための技術。対象の文書ファイルの全文からテキスト情報を抽出して、合致するキーワードを検索する。Googleの検索エンジンもこの全文検索を使って、Webページ上に存在する膨大なデータの中から検索キーワードに入力された特定の文字列を検索し、アクセス数等の様々な観点からランキング化されたページ順に、検索結果を表示させている。

検索方法は2つ

grep型

逐次検索ともいう。検索したい文字列を文書の先頭から片っ端から探していくので、文書量が増えると検索時間も長くなってしまう効率の悪さが難点。データ量が少ない文書や一時的な文書の検索には適している

索引型（インデックス型）⇒こっちが主流

grep型とは反対に、いきなり片っ端から検索するのではなく、先に検索しやすいように文書から索引（インデックス）を作ることで、検索速度が速くする工夫がされている。
この索引を作る前処理のことをインデッキシングと言う。索引を作るまでに時間はかかるが、一度索引を作ってしまえば、後はその中から文書を探すだけなので、結果的に検索速度が速くなる。

では、どういう風にして文字列を抽出してくるのか？

全文検索の3つの仕組み

参照：検索エンジンの3つの仕組みと、アルゴリズムを公開します

n-gram法

Nで指定した単語の長さに、先頭から1文字ずつ文字列を分割していく。

例：ｎ= 2、文字列 = 全文検索　でn-gram法を実行
⇒結果：全文　文検　検索　索

この方法は単語抽出の取りこぼしは防げるが、「文検」みたいな邪魔な単語も多くなってしまうので、検索精度に悪影響が出る可能性がある。例えば、「東京都」という文字列であれば、「京都」でもヒットしてしまう。

形態素解析法　⇒オーソドックスな方法

日本語の全文検索で一番オーソドックスな方法。この方法では「単語の最小の構成単位」に分割する。英語の場合は、基本的には単語と、単語の間に空白があるからそれを「単語」として認識しやすい。でも日本語の場合は、どこまでが単語なのかが分かりにくいので、ちょっとひと手間加えている。

日本語はこういう困り事があるから、ちゃんと単語を区別するために、広辞苑みたいな感じで、形態素解析用の辞書を作っている。この辞書に「全文検索」という単語がなければ、上記の例の全文検索は「全文」「検索」という2つの単語が抽出される。

ハイブリッド法

n-gramと形態素解析を組み合わせて使う。ただ、処理が重くなるので、状況に応じて使い分けが必要。

実際に、ユーザーインターフェース（例えば、Google Chromeの検索画面）で検索したいキーワードを入力してから、検索結果が返ってくるまでの流れはこんな感じ。