データベースの類推は忘れてください。エラスティック検索にはテーブルのようなものはなく、類推は複数のレベルで壊れるだけです。スキーマはインデックスとまったく同じではありません。型はテーブルとは関係ありません。行は Lucene などのどこにも存在しません。
@monkjack が示唆するように、シャードの数の観点から考える方が良いです。インデックス、タイプ、およびエイリアスは、基本的にシャードを編成するための論理的な手段です。シャードは、全体として管理される lucene インデックス (フィールドごと) の多かれ少なかれ独立したグループです。インデックスの特定のタイプのドキュメントのコレクションが与えられると、そのコレクションは n 個のシャードに分割され、それぞれが独自のファイル セット (フィールドごと) を持ちます。
クラスターがジャグリングする必要があるシャードの数は、メモリ、ファイル ハンドルの数などに影響します。バランスの取れたクラスターは、RAM を効率的に利用できるように、各ノードに十分な量のシャードを割り当てます。したがって、インデックスが 10 個あり、それぞれに 10 個のシャードがある場合、シャードは 100 個になります。それらが 1 回レプリケートされると、事実上 200 個のシャードになります。したがって、4 つのノードがある場合、ノードごとに 50 個のシャードがあります。シャードの大きさによっては、問題になる場合とそうでない場合があります。エラスティック検索は、複数のシャードを処理したり、シャードで同時にインデックスを作成したり、シャード全体を検索したりするなどのことを行うのに非常に効果的です。したがって、ノードごとに 1 つのシャードはおそらくそれほど大きくなく、ノードごとに 1000 のシャードではおそらく多少のオーバーヘッドが発生します。シャードが多いということは、より多くのノードを利用できることを意味します。シャードが 2 つ、ノードが 10 個しかない場合は、いくつかのマシンがアイドリング状態になります。その逆は、おそらくより良い考えです。等。
インデックス: シャードのグループ。レプリケーションとシャードの設定があります。これらは重要です。インデックスを作成した後に変更することはできません。必要な場合の解決策: エイリアスを使用する、新しいインデックスを作成する、データを再インデックス化する、エイリアスを切り替える、古いインデックスを削除する。
タイプ: ドキュメントのグループ。インデックスに属します。インデックスは複数のタイプを持つことができますが、それらはすべて同じシャードを共有します。タイプを作成しても、シャードの数は変わりません。型は複数のインデックスで発生する可能性があり、複数の型とインデックスにまたがるクエリを作成できます。
エイリアス: 1 つ以上のインデックスの代替名。これは非常に強力な機能で、スキーマの移行などを実装したり、新しいインデックスを指すようにエイリアスを変更するだけで毎日新しいインデックスを作成したりできます。
したがって、あなたの場合、それぞれ独自のインデックスを持つ何千ものテナントを持つと、膨大な量のシャードが発生します。おそらく最良のアイデアではありません。シャードの数とテナントの数の間に直接的なリンクは必要ありません。テナントあたりの負荷がわずかで、テナントあたりのドキュメント数が重要でない場合にのみ、これで問題が解決する可能性があります。
たとえば、インデックスごとに異なるサービス品質が必要な場合は、単一のインデックスまたは複数のインデックスの下で各テナントに独自のタイプを与えることをお勧めします。このようにして、シャードの数を制御し、テナントをタイプ レベルで分離しておくことができます。