1

Elasticsearch.org サイトから、 Elasticsearch に挿入されるインデックス名インデックス タイプを整理する方法を説明するドキュメントを見つけることができませんでした。

たとえば、インデックス作成用のデータを配置するには、次のような REST API を使用できることは明らかです。

curl -XPUT localhost:9200/<INDEX>/<TYPE>/<id> -d '{ mydata : "someData" }'

明確ではないのは、次の結果がどうなるかです。

1) INDEX : これはビデオの概要によるデータベースですが、これらが高すぎる場合のパフォーマンスへの影響は何ですか?

2) TYPE :動画の概要に沿った表のようなものです。すべてのデータに固定値を使用するとどうなるか

私の実装では 、INDEX を TENANT_ID として使用し、TYPE を単一のバケット名 (「STUFF」) として使用して、これをマルチテナントシナリオで動作させたいと考えています。テナントの数が非常に多い (数千) 場合があります。これは良いアプローチですか、それとも単一の INDEX を使用して TENANT_ID を TYPE の下に配置する必要がありますか? 特に、より多くのリソースを消費するオプションはどれですか (開いているファイル / パフォーマンス) ?

4

2 に答える 2

5

データベースの類推は忘れてください。エラスティック検索にはテーブルのようなものはなく、類推は複数のレベルで壊れるだけです。スキーマはインデックスとまったく同じではありません。型はテーブルとは関係ありません。行は Lucene などのどこにも存在しません。

@monkjack が示唆するように、シャードの数の観点から考える方が良いです。インデックス、タイプ、およびエイリアスは、基本的にシャードを編成するための論理的な手段です。シャードは、全体として管理される lucene インデックス (フィールドごと) の多かれ少なかれ独立したグループです。インデックスの特定のタイプのドキュメントのコレクションが与えられると、そのコレクションは n 個のシャードに分割され、それぞれが独自のファイル セット (フィールドごと) を持ちます。

クラスターがジャグリングする必要があるシャードの数は、メモリ、ファイル ハンドルの数などに影響します。バランスの取れたクラスターは、R​​AM を効率的に利用できるように、各ノードに十分な量のシャードを割り当てます。したがって、インデックスが 10 個あり、それぞれに 10 個のシャードがある場合、シャードは 100 個になります。それらが 1 回レプリケートされると、事実上 200 個のシャードになります。したがって、4 つのノードがある場合、ノードごとに 50 個のシャードがあります。シャードの大きさによっては、問題になる場合とそうでない場合があります。エラスティック検索は、複数のシャードを処理したり、シャードで同時にインデックスを作成したり、シャード全体を検索したりするなどのことを行うのに非常に効果的です。したがって、ノードごとに 1 つのシャードはおそらくそれほど大きくなく、ノードごとに 1000 のシャードではおそらく多少のオーバーヘッドが発生します。シャードが多いということは、より多くのノードを利用できることを意味します。シャードが 2 つ、ノードが 10 個しかない場合は、いくつかのマシンがアイドリング状態になります。その逆は、おそらくより良い考えです。等。

インデックス: シャードのグループ。レプリケーションとシャードの設定があります。これらは重要です。インデックスを作成した後に変更することはできません。必要な場合の解決策: エイリアスを使用する、新しいインデックスを作成する、データを再インデックス化する、エイリアスを切り替える、古いインデックスを削除する。

タイプ: ドキュメントのグループ。インデックスに属します。インデックスは複数のタイプを持つことができますが、それらはすべて同じシャードを共有します。タイプを作成しても、シャードの数は変わりません。型は複数のインデックスで発生する可能性があり、複数の型とインデックスにまたがるクエリを作成できます。

エイリアス: 1 つ以上のインデックスの代替名。これは非常に強力な機能で、スキーマの移行などを実装したり、新しいインデックスを指すようにエイリアスを変更するだけで毎日新しいインデックスを作成したりできます。

したがって、あなたの場合、それぞれ独自のインデックスを持つ何千ものテナントを持つと、膨大な量のシャードが発生します。おそらく最良のアイデアではありません。シャードの数とテナントの数の間に直接的なリンクは必要ありません。テナントあたりの負荷がわずかで、テナントあたりのドキュメント数が重要でない場合にのみ、これで問題が解決する可能性があります。

たとえば、インデックスごとに異なるサービス品質が必要な場合は、単一のインデックスまたは複数のインデックスの下で各テナントに独自のタイプを与えることをお勧めします。このようにして、シャードの数を制御し、テナントをタイプ レベルで分離しておくことができます。

于 2013-07-18T13:28:02.270 に答える
2

インデックスは別のファイルとして保存されます。型は、インデックス内の論理的な名前空間です。

  • 検索するインデックスがわかっている場合は、物理的に検索するデータ/シャードが少ないため、データをインデックスに分割する方が高速です (2 つのインデックスでそれぞれ 5 つのシャードと 1 つのインデックスで 10 のシャード - 1 つのインデックス検索で 5 つのシャードと 10 のシャードを比較できます)。逆に、どのインデックスを参照すればよいかわからない場合や、インデックス セット全体を頻繁に検索したい場合は、多数のシャードを検索して結果を連結することになる可能性があります。
  • 多くのインデックスがある場合は、多くの開いているファイルがあります。これにより、問題が発生する可能性があります。何百ものインデックスが必要な場合は、実験してみてください。

あなたの場合、大規模な「エンタープライズ」テナントが少数しかないと予想される場合は、テナントごとにインデックスを使用します。何百もの小さなサイト (tumblr など) のルートをたどる場合は、代わりに入力します。

于 2013-07-17T23:01:07.490 に答える