基本概念

edit

Elasticsearchの中心となる概念がいくつかあります。最初にこれらの概念を理解すると、学習プロセスが容易になります。

ほぼリアルタイム(NRT)

edit

Elasticsearchは、ほぼリアルタイムの検索プラットフォームです。つまり、ドキュメントにインデックスを付けてから検索可能になるまでにわずかな待ち時間(通常は1秒)があります。

クラスタ

edit

クラスタは、データ全体を一緒に保持する1つ以上のノード(サーバー)のコレクションで、すべてのノードにわたって統合したインデキシング機能と検索機能を提供します。クラスタは、一意の名前で識別されます。デフォルトの名前は、「elasticsearch」です。名前でクラスタに参加するようにセットアップされている場合、ノードは1つのクラスタにしか含めることができないため、この名前は重要となります。

別の環境で同じクラス名を再利用しないでください。再利用すると、ノードを間違ったクラスタに参加させてしまう可能性があります。 たとえば、開発クラスタ、ステージングクラスタ、本番クラスタに`logging-dev`、logging-stage、`logging-prod`を使用します。

これは、クラスタにノードが1つしかない場合に有効かつ十分であることに注意してください。さらに、複数の独立したクラスタにそれぞれ独自のクラスタ名を付けることもできます。

ノード

edit

ノードは、クラスタに含まれ、データを保存し、クラスタのインデキシング機能と検索機能に関係する1台のサーバーです。クラスタと同様に、ノードは名前で識別されます。デフォルトでは、起動時にノードに割り当てられるランダムなユニバーサル固有識別子(UUID)になります。デフォルトの名前にしたくない場合は、任意の名前を定義できます。この名前は、ネットワーク内のサーバーとElasticsearchクラスタ内のノードの対応を特定する必要がある管理目的に重要です。

クラスタ名で特定のクラスタに参加するように、ノードを設定できます。デフォルトで各ノードは、`elasticsearch`という名前のクラスタに参加するようにセットアップされます。つまり、ネットワーク上で複数のノードを起動すると(相互に検知可能であることを想定)、そのノードはすべて、`elasticsearch`という1つのクラスタを自動的に形成し参加します。

1つのクラスタには、必要な数のノードを含めることができます。さらに、現在ネットワーク上に別のElasticsearchノードが稼働していない場合、1つのノードを起動すると、`elasticsearch`という単一ノードのクラスタがデフォルトで形成されます。

インデックス

edit

インデックスとは、同様の特性を持つドキュメントのコレクションです。たとえば、顧客データ、製品カタログ、注文データにそれぞれ別のインデックスを付けることができます。インデックスは名前(すべて小文字)で識別されます。この名前を使用して、ドキュメントに対してインデキシング、検索、更新、および削除の操作を実行する際にインデックスを参照します。

1つのクラスタには、必要な数のインデックスを定義できます。

タイプ

edit

インデックス内に1つ以上のタイプを定義できます。タイプは、ユーザーがそのセマンティックスを自由に定義できる論理カテゴリ/区分です。一般に、タイプは一連の共通フィールドを持つドキュメントに定義されます。たとえば、ブログ作成プラットフォームを実行して、すべてのデータを1つのインデックスに格納するとします。このインデックスには、ユーザーデータのタイプ、ブログデータのタイプ、さらにコメントデータのタイプを定義できます。

ドキュメント

edit

ドキュメントは、インデックスを付けられる情報の基本単位です。たとえば、1つの顧客のドキュメント、1つの製品のドキュメント、さらに1つの注文のドキュメントを持つことができます。この文書は、ユビキタスインターネットデータ交換形式である JSON(JavaScript Object Notation)で表されます。

index/type内に、必要な数のドキュメントを格納できます。ドキュメントはインデックス内に物理的に存在しますが、実際にインデックス内のタイプへのインデキシング/割り当てを行う必要があることに注意してください。

シャード&レプリカ

edit

インデックスは、単一ノードのハードウェア制限を超える大量のデータを格納する場合があります。たとえば、1TBのディスク容量をとる大量のドキュメントの単一インデックスは、単一ノードのディスクには適せず、単一ノードからの検索リクエストに応えるだけの処理速度も不足する可能性があります。

この問題を解決するために、Elasticsearchは、シャードという複数の部分にインデックスを分割できます。インデックスの作成時に、シンプルに必要な数のシャードを定義できます。各シャードはそれ自体が、クラスタ内のノード上でホストされるフル機能の独立した「インデックス」です。

シャードは、主に次の2つの理由で重要です。

  • コンテンツ量を均一に分割/拡大可能
  • シャード全体にわたって(場合によっては複数のノード上に)演算処理を分散および並列化でき、パフォーマンス/スループットを向上

シャードを分散する技法およびそのドキュメントを検索リクエストに統合する技法は、Elasticsearchにより完全に管理され、透過的に処理されます。

常に障害が予期されるネットワーク/クラウド環境で、シャード/ノードが何らかの理由でオフラインになるか表示されなくなった場合のフェイルオーバーメカニズムがあると非常に便利であり、これを強くお勧めします。このために、Elasticsearchでは、1つ以上のインデックスのシャードをいわゆるレプリカシャード(略してレプリカ)にコピーできます。

レプリケーションは、主に次の2つの理由で重要です。

  • シャード/ノードに障害が発生した場合の高可用性が提供されます。この理由で、レプリカシャードをコピー元のオリジナル/プライマリと同じノードに割り当てないように注意することが大切です。
  • 検索はすべてのレプリカで並列に実行できるため、検索の量/スループットを拡張できます。

要約するために、各インデックスは複数のシャードに分割されます。インデックスも、ゼロ個(つまりレプリカなし)または1個以上のレプリカを作成できます。レプリカが作成されると、各インデックスはプライマリシャード(レプリカを作成したオリジナルのシャード)とレプリカシャード(プライマリシャードのコピー)を持ちます。 シャードとレプリカの数は、インデックスの作成時にインデックスごとに定義されます。インデックスが作成された後、レプリカの数はいつでも動的に変更できますが、シャードの数は後になってからは変更できません。

デフォルトでは、Elasticsearchの各インデックスは5つのプライマリシャードと1つのレプリカを割り当てられます。これは、クラスタに少なくとも2つのノードがある場合、インデックスは、インデックスにつき合計10個のシャードのうち、5つのプライマリシャードと5つのレプリカシャード(完全なレプリカ1つ)を持つということです。

各ElasticsearchシャードはLuceneインデックスです。1つのLuceneインデックスのドキュメント数には上限があります。 LUCENE-5843では、上限は`2,147,483,519`(= Integer.MAX_VALUE - 128)ドキュメントです。 _cat/shardsAPIを使用してシャードのサイズを監視できます。

その他については、興味のあるところから始めてください。