前提
- ElasticSearch 7 系
- 7.17 想定
概要
-
Elasticsearch は、高スケーラブルな全文検索ソフトウェア
- 全文検索とは、複数の文書を対象として、特定の文字列が含まれる文書を探す技術のこと
- RDB との大きな違いとしては、検索条件にどの程度合致しているかがスコアで数値化されること
- RDB は
検索条件に合致するデータを全て取得する
一方、全文検索ではスコアを利用して最も検索条件に合致するデータを取得できる
- また、全文検索では、検索処理のユースケースを主用途としているため、クエリ性能・スケーラビリティが相対的に重視されている
- RDB は
- RDB との大きな違いとしては、検索条件にどの程度合致しているかがスコアで数値化されること
- ショッピングサイトの商品検索のような大規模なデータ検索に使われる
- その他にもログ分析などの幅広い用途で使われる
- 全文検索とは、複数の文書を対象として、特定の文字列が含まれる文書を探す技術のこと
- 実際に内部で検索を行っているのは、Apache Lucene という検索ライブラリ
- コアとなる機能は検索ライブラリに移譲している
- インデックス作成や検索処理
-
Elasticsearch 自体は検索サーバとして、検索ライブラリの補完機能を提供する
- REST API 提供やクラスタ管理等
- コアとなる機能は検索ライブラリに移譲している
特徴
-
転置インデックスによって、全文検索を実現
-
ドキュメント内に含まれる各単語
とそのドキュメント
の組み合わせをインデックスとして構成する- フォーマット:
単語 -> ドキュメント, 単語の出現位置
- フォーマット:
- 検索の流れとしては、該当単語を含むドキュメントを選定した後、出現位置条件の評価を行う
-
-
分散配置によって、高パフォーマンス&高可用性を実現
- 具体的には、シャード&レプリカ
- シャードは、インデックスの分割単位(
書き込み可能
)- インデックスのデータを一定数に分割して、異なるノードで分散保持する
- 演算処理を複数ノードで分散・並列化することでパフォーマンス改善
- シャード数は、インデックス作成時に決定後、変更できない
- レプリカは、シャードの複製(
読み取り専用
)- オリジナルをプライマリシャード、複製をレプリカシャードと呼ぶ
- フェイルオーバーによる高可用性、及び検索分散によるパフォーマンス改善
- レプリカ数は、後から変更できる
- デフォルトでは、各インデックスに1つのシャードと1つのレプリカが割り当てられる
- 1つのプライマリシャードと1つのレプリカシャードの計2シャード
- 推奨シャードサイズは 10〜50GB
- REST API によって、直感的なアクセス方法を実現
- URL を見るだけで、
何
をどうする
のか理解できる- 処理対象のリソースは、URI で一意に表現する
- リソースに対する操作は、HTTP メソッドで表現する
- また、REST API を扱えるツールは数多く公開されているため、容易に実利用できる
- ちなみに、Apache Lucene は Java API を利用する必要がある
- URL を見るだけで、
- JSON フォーマットの採用によって、柔軟性の高さを実現
- インデックス作成・検索対象のドキュメントは全て JSON フォーマットで表現される
- ドキュメントは事前にスキーマ定義しなくても格納できる
- JSON として表現されていれば、ドキュメント格納時に自動的にスキーマを推論してくれる
構成要素
RDB との比較を交えながら見てみる
ES 要素 | 概要 | RDB 類似要素 |
---|---|---|
クラスタ | ノードの集合体。全ノードに対して、統合したインデキシング機能と検索機能を提供する。 | - |
ノード | クラスタに含まれる単体サーバ。具体的には、ElasticSearch が動作する 1 つの JVM インスタンスのこと。1 つの OS 上に複数ノードを起動することも可能。 ノードには、各役割に応じた種別がある。例えば、Master/Data/Ingest/Coordinating/... ノードがある。詳細はまた別途行う予定(各ノード間の連携の話とか)。デフォルトの設定では、各ノードがほぼ全ての役割を持つ。大規模構成の場合は、役割毎に専用ノードを構成することもある。 |
- |
インデックス | ドキュメントを保存する場所。実際には、シャードによって、各ノードに分散して格納されている。 | テーブル(or データベース) |
ドキュメントタイプ | ドキュメントがどのようなフィールドから構成されているのかを表す概念。ドキュメントに含まれるフィールドの型や属性情報などのデータ構造が定義される。1インデックスにつき1ドキュメントタイプだけ定義できる※。 また、それを具体的に定義したものをマッピングと呼ぶ。なお、事前にマッピングが定義されていない場合は、ElasticSearch 側で自動的にマッピング定義してからインデックス作成を行う。 |
テーブル定義 |
ドキュメント | インデックス作成/検索の基本単位。JSON 形式で保存される。1つ以上のフィールドから構成される。 | レコード |
フィールド | ドキュメント内の項目名・値の組。例えば、"name": "taro" が1フィールドになる。転置インデックスはフィールド毎に作成・管理されているため、クエリ実行時はフィールド単位で検索を行う。 フィールドの値にはいくつかのデータ型が用意されている。例えば、文字列のデータ型として、text や keyword がある。詳細はまた別途行う予定(アナライザの話とか)。 |
カラム |
- ※ 元々、一つのインデックス配下に複数のドキュメントタイプを定義できた
-
ver7 以降は前述の通り制限されることになった
- ドキュメントタイプに対するミスリードが起こす弊害を防ぐため
- 同インデックス内の別ドキュメントタイプの同名フィールドは物理的に共有されている
- 別テーブルの同名カラムのように独立しているものと扱おうとすると、、
- 同名フィールドを削除する時や同名フィールドを別インデックスに配置する時など
- ドキュメントタイプに対するミスリードが起こす弊害を防ぐため
-
ver7 以降は前述の通り制限されることになった
それぞれの要素の関連性を可視化してみる
![](https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.ap-northeast-1.amazonaws.com%2F0%2F2627625%2F33c8f762-8106-54c7-c459-2f486f1a365d.png?ixlib=rb-4.0.0&auto=format&gif-q=60&q=75&s=156c617f9c81e99f4b9ef46e216cb17a)