elasticsearch gotchas - パート1

Elasticsearchは信頼できる成熟したライブラリApache Luceneをベースにした検索エンジンです。git での大きな活動 プロジェクト repository and the implementation in such projects as GitHub, SoundCloud, Stack Overflow and LinkedIn bear testimony to its great popularity. The part “Elastic” says it all about the nature of the system, whose capabilities are enormous: from a simple file search on a small scale, through knowledge discovery, to big data analysis in real time.What makes Elastic a more powerful than the competition is the set of default configurations and behaviors, which allow to create a cluster and start adding documents to the index in a couple of minutes. Elastic will configure a cluster for you, will define an index and define the types of fields for the first document obtained, and when you add another server, it will automatically deal with dividing index data between servers.Unfortunately, the above mentioned automation makes it unclear to us what the default settings implicate, and it often turns out to be misleading. This article starts a series where I will be dealing with the most popular gotchas, which you might encounter during the process of Elastic-based app creation.

シャードの数は変更できない

最初の文書に インデックスAPI:

 $ curl -XPUT 'http://localhost:9200/myindex/employee/1' -d '{".
     「first_name" : "Jane"、
     "last_name" : "Smith"、
     "steet_number"：  12
   }'

この瞬間、Elasticはmyindexというタイトルのインデックスを作成してくれます。ここで見えないのは、インデックスに割り当てられているシャードの数だ。シャードは、インデックス全体のドキュメントの一部のインデックス作成、保存、検索を担当する個々のプロセスとして理解することができます。文書のインデックス作成プロセスにおいて、elasticは文書をどのシャードで見つけるべきかを決定する。これは以下の式に基づいている：

shard = hash(document_id) % number_of_primary_shards。

これで、ドキュメントを含むインデックスではプライマリシャードの数を変更できないことが明らかになった。したがって、最初のドキュメントにインデックスを作成する前に、常に手動でインデックスを作成し、インデックス対象のデータ量に対して十分と思われるシャードの数を指定する：

 $ curl -XPUT 'http://localhost:9200/myindex/' -d '{
     "設定" : {
       "number_of_shards" : 10
     }
   }'

のデフォルト値 シャードの数 これは、インデックス作成中にデータを収集する サーバーを最大5台まで拡張できることを意味する。本番環境では、シャードの値は、予想されるインデックス作成の頻度とドキュメントのサイズに応じて設定すべきである。開発環境やテスト環境では、値を1に設定することをお勧めします。それはこの記事の次の段落で説明する。

比較的少ない文書数でのテキスト検索結果の並べ替え

フレーズで文書を検索する：

 $ curl -XGET 'http://localhost:9200/myindex/my_type/_search' -d
   '{
     "query"：{
       "match"：{
         "title"："素早い茶色の狐"
       }
     }
   }'

Elasticはテキスト検索を数ステップで処理します：

1. リクエストのフレーズは、文書がインデックスされたのと同じ同じ形式に変換される： [クイック」、「ブラウン」、「フォックス」]。 ("the "は重要ではないので削除した）、
2. 索引は、検索された単語の少なくとも1つを含む文書を検索するために閲覧されている、
3. 一致するすべての文書は、検索フレーズとの関連性の観点から評価される、
4. 結果は計算された関連性によってソートされ、結果の最初のページがユーザーに返されます。

第3ステップでは、（とりわけ）以下の値が考慮される：

1. 検索フレーズに含まれる単語が文書中にいくつあるか
2. ある単語が文書に出現する頻度 (TF - term frequency)
3. 一致した単語が他の文書に出現しているかどうか、またその頻度（IDF：逆文書頻度） - 他の文書でよく使われる単語であればあるほど、重要度は低くなる。
4. 文書の長さ

IDFの機能は私たちにとって重要です。Elasticはパフォーマンス上の理由から、インデックス内の全てのドキュメントについてこの値を計算しません。その代わりに、全てのシャード（インデックスワーカー）がそのローカルIDFを計算し、ソートに使用します。そのため、ドキュメント数が少ないインデックス検索では、インデックス内のシャードの数やドキュメントの分布によって大幅に異なる結果が得られる可能性があります。

インデックスに2つのシャードがあり、最初のシャードには「fox」という単語でインデックスされた文書が8つあり、2番目のシャードには同じ単語でインデックスされた文書が2つしかないとします。その結果、"fox "という単語は両方のシャードで大きく異なることになり、誤った結果を生む可能性がある。したがって、開発目的では、1つのプライマリシャードのみからなるインデックスを作成する必要があります：

 $ curl -XPUT 'http://localhost:9200/myindex/' -d
   '{"settings" : { "number_of_shards" : 1 }.}'

"遠い "検索ページの結果を表示するとクラスタが死ぬ

前の段落で書いたように、インデックス内の文書は、まったく個別のインデックス・プロセス（シャード）間で共有される。各プロセスは完全に独立しており、自分に割り当てられた文書だけを扱う。

何百万もの文書を含むインデックスを検索し、トップ10の結果を得るために待機する場合、各シャードはクラスタの ノード検索を開始したその後、各シャードからの応答が結合され、（インデックス全体の中で）検索結果の上位10件が選ばれる。このようなアプローチにより、多くのサーバー間で検索プロセスを効率的に分散することができる。

ユーザーが閲覧できるページ数の制限なしに、1ページあたり50件の検索結果を閲覧できるアプリを想像してみよう。私たちのインデックスは10個のプライマリシャード（各サーバーにつき1個）で構成されていることを思い出してください。

1ページ目と100ページ目の検索結果の獲得がどのようになるかを見てみよう：

検索結果の1ページ目

1. クエリーを受け取ったノード（コントローラー）は、それを10個のシャードに渡す。
2. 各シャードは、関連性でソートされた50のベストマッチ文書を返す。
3. すべてのシャードから応答を受信した後、コントローラは結果（500ドキュメント）をマージする。
4. この結果は、前のステップの上位50文書である。

検索結果の100ページ目

1. クエリーを受け取ったノード（コントローラー）は、それを10個のシャードに渡す。
2. 各シャードは、関連性でソートされた5000のベストマッチ文書を返す。
3. すべてのシャードから応答を受信した後、コントローラは結果（50000ドキュメント）をマージする。
4. 私たちの結果は、4901から5000までの前のステップの文書である。

1つのドキュメントのサイズが1KBであると仮定すると、2番目のケースでは、1人のユーザーが100の結果を表示するために、クラスタ内で〜50MBのデータが送信され、処理されなければならないことを意味する。

結果ページが増えるごとに、ネットワーク・トラフィックとインデックスの負荷が大幅に増加することに気づくのは難しいことではない。そのため、「遠い」検索ページをユーザーが利用できるようにすることは推奨されません。インデックスがうまく構成されていれば、ユーザーは最初の検索ページで興味のある結果を見つけるはずであり、クラスタの不必要な負荷から身を守ることができる。このルールを証明するために、最も人気のあるウェブ検索エンジンが閲覧を許可している検索結果ページの数を調べてみよう。

さらに興味深いのは、連続する検索結果ページのブラウザ応答時間の観察である。例えば、Google検索（検索語は "search engine"）の個々の検索結果ページのレスポンスタイムを以下に示す：

| 検索結果ページ（1ページあたり10文書）｜レスポンスタイム｜検索結果ページ（1ページあたり10文書）｜レスポンスタイム｜検索結果ページ（1ページあたり10文書
|——————————————–|—————|
| 250ミリ秒
| 10 | 290ms |
| 20｜350ミリ秒
| 30 | 380ms |
| 38（最後の1本

次のパートでは、ドキュメントの索引付けに関する問題を詳しく見ていきたい。