Elasticsearch分散アーキテクチャの原則は、私たちが本当に知っておく必要があり、非常に重要です

Elasticsearch は、可用性とスケーラビリティに優れたシステムを構築するために使用されます。スケーリングは、より優れたサーバーを購入する (垂直スケールまたはスケールアップ) か、またはより多くのサーバーを購入する (水平スケールまたはスケールアウト) ことによって実行できます。

[[281098]]

Elasticsearch はより強力なハードウェアを使用することでより優れたパフォーマンスを得ることができますが、垂直拡張には限界があります。実際の拡張は水平方向、つまりノードを追加することで負荷を分散し、信頼性を高めることが必要です。

ほとんどのデータベースでは、スケールアウトとは、新しく追加されたデバイスを活用するためにアプリケーションを大幅に変更する必要があることを意味します。対照的に、Elasticsearch は本質的に分散されており、高いスケーラビリティと高可用性を実現するためにノードを管理する方法を知っています。つまり、プログラムではこの点について心配する必要はありません。

ES はどのようにして配布を実現するのでしょうか?

インデックスの追加

es にデータを格納するための基本単位はインデックスです。 ES にデータを追加するには、インデックスを追加する必要があります。

ここで、ES のインデックスとシャードの関係について説明する必要があります。シャードは最小レベルの「ワーカー ユニット」であり、インデックス内のすべてのデータの一部のみが格納されます。すべてのドキュメントはシャードに保存され、アプリケーションと直接やり取りするドキュメントは繰り返しインデックス化されます。

ホテル検索を例に挙げて、すべてのホテルインデックスhotel_idxを追加してみましょう。

 /hotel_idx を入力する 
 {  
 "設定" ： {  
 「破片の数」 : 3,  
 「レプリカ数」 : 1  
 }  
 }

3 つの ES ノードを起動します。現在、hotel_idx には 3 つのプライマリ シャードが割り当てられており、各プライマリ シャードには 1 つのレプリカ シャードがあります。

1. ES クライアントはノードを選択します。上記ではNODE1が選択されており、これがデータを書き込むコーディネーションノードになります。現時点では、ES はドキュメント (ホテルデータの一部) をどのシャードにルーティングするかをどのように判断できるのでしょうか?実際、それは次の式に基づいています:

シャード=ハッシュ(ルーティング)%プライマリシャードの数

ルーティングは変数値です。デフォルトはドキュメントの _id です。ホテルの hotel_id などのカスタム値に設定することもできます。ルーティングはハッシュ関数を通じて数値を生成し、この数値を number_of_primary_shards (プライマリ シャードの数) で割って余りを取得します。 0 と number_of_primary_shards-1 の間の余りは、探しているドキュメントが配置されているシャードの場所です。

2. P0 を書き込んだ後、そのコピーである R0 と同期されます。同期が成功すると、調整ノード Node1 に返され、最終的にクライアントに返されます。

3. ESクライアントはプライマリシャードとセカンダリシャードの両方からデータを読み取ることができる

高可用性を確保する方法

• NODE1 マスターノードがクラッシュした場合、ES は再選出を行い (必要に応じて、後で分散選出トピックを共有することを検討します)、NODE2 がマスターとして選択されます。
• マスター以外のノード (ノード 2) に障害が発生した場合、マスター ノード ノード 1 は、書き込み操作を受信するために、ノード 3 の R1 コピーをプライマリ シャード P1 に変換します。 NODE2 が回復すると、以前の P1 は R1 コピーに変換されます。

拡大方法

ES では、インデックスを作成するときにプライマリ シャードの数を指定する必要があるため、プライマリ シャードを拡張することはできません。ストレージ容量が現在の ES ノードを超える場合、一部の運用方法では通常、現在のインデックスよりも多くのシャードを持つ新しいインデックスを作成し、データをインポートします。しかし、これにはいくつかの欠点もあります。そうすると、許容できない時間が消費されてしまいます。

当社では、事前に割り当てておくのが一般的です。事前に計画を立て、事前割り当てを行うことで、この問題を完全に回避することができます。

その中で、レプリカ シャードは動的に拡張できます。読み取りボリュームが大きいシナリオでは、レプリカを適切に拡張するとスループットが向上します。

 /hotel_idx/_settings を配置します 
 { 
  「レプリカ数」 : 2  
 }

シャード容量の見積もり方法

これを説明するのは実際には困難です。使用するハードウェア、ドキュメントのサイズと複雑さ、ドキュメントのインデックス作成と分析の方法、実行するクエリの種類、実行される集計、データ モデルなど、関連する要因が非常に多いためです。

制作における経験と提案:

1. 運用で使用する予定のハードウェアに基づいて、単一ノード クラスターを作成します。

2. 運用環境で使用するのと同じ構成とアナライザーを使用して、プライマリ シャードを 1 つだけ使用し、レプリカ シャードを使用しないインデックスを作成します。実際のドキュメント（または可能な限りそれに近いドキュメント）をインデックスします。

3. 実際のクエリと集計（またはそれにできるだけ近いもの）を実行します。

基本的には、現実世界の使用パターンを再現し、それをすべて 1 つのシャードに押し込んで「破損」させる必要があります。何が正確に中断するかはあなた次第です。ユーザーによっては、50 ミリ秒以内にすべての応答を必要とする場合があります。 5 秒待つだけで満足する人もいます。

したがって、単一のシャードの容量を定義すると、インデックス全体のシャードの数を簡単に推測できます。インデックスを作成する必要があるデータの総量と予想される増加分を合計し、それを 1 つのシャードの容量で割ります。結果が、必要なプライマリ シャードの数になります。