弾性検索、複数のインデックスvs 1つのインデックス、および異なるデータセットのタイプ？

MVCパターンを使用して開発されたアプリケーションがあり、その複数のモデルにインデックスを付けたいと考えています。これは、各モデルに異なるデータ構造があることを意味します。

• モデルごとに1つずつ、または各モデルの同じインデックス内に型を持つ複数のインデックスを使用する方が良いですか？どちらの方法でも、別の検索クエリが必要になると思います。私はこれから始めました。

• データセットが小さい場合または大きい場合、両方の概念のパフォーマンスに違いはありますか？

その目的のために誰かが私にいくつかの良いサンプルデータを勧めてくれるなら、私は2番目の質問を自分でテストします。

どちらのアプローチにも異なる影響があります。

Elasticsearchのデフォルト設定を使用している場合、各モデルに1つのインデックスがあると、1つのインデックスで5つのシャードが使用され、5つのデータモデルで25のシャードが使用されるため、シャードの数が大幅に増加します。1つのインデックスに5つのオブジェクトタイプがある場合でも、5つのシャードを使用します。

各データモデルをインデックスとして持つことの影響：

• インデックス内で分散されるため、各シャードのデータ量が少なくなるため、効率的でインデックス内の検索が高速です。
• 2つ以上のインデックスからデータモデルの組み合わせを検索するとオーバーヘッドが発生します。これは、クエリをインデックス間でより多くのシャードに送信し、コンパイルしてユーザーに送信する必要があるためです。
• データセットが小さい場合は、シャードが追加されるたびにストレージが増えるため、パフォーマンスの向上はわずかであるため、お勧めしません。
• データセットが大きく、クエリの処理に長い時間がかかる場合に推奨されます。専用のシャードが特定のデータを格納し、Elasticsearchの処理が容易になるためです。

各データモデルをインデックス内のオブジェクトタイプとして持つことの意味：

• インデックスの5つのシャード内により多くのデータが保存されます。つまり、さまざまなデータモデルでクエリを実行してもオーバーヘッドの問題は少なくなりますが、シャードのサイズは大幅に大きくなります。
• フィルター処理するドキュメントの数が多いため、シャード内のデータが多いほど、Elasticsearchが検索に時間がかかるようになります。
• 1テラバイトのデータを処理していて、Elasticsearchマッピングの異なるインデックスまたは複数のシャードにデータを分散していないことがわかっている場合は、お勧めしません。
• 各シャードがハードウェアのスペースを占有するため、わずかなパフォーマンス向上のためにストレージスペースを無駄にしないため、小さなデータセットに推奨されます。

小さすぎるデータと多すぎるデータとは何ですか？通常、ハードウェアのプロセッサ速度とRAM、Elasticsearchのマッピングの各変数に格納するデータの量、およびクエリの要件によって異なります。クエリで多くのファセットを使用すると、応答時間が大幅に遅くなります。これに対する簡単な答えはなく、ニーズに応じてベンチマークする必要があります。

当時はジョナサンの答えは正しかったが、世界は進んでおり、ElasticSearchの背後にいる人々は複数のタイプのサポートを廃止する長期計画を持っているようです。

目的の場所：親子をサポートしながら、Elasticsearchから型の概念を削除します。

したがって、新しいプロジェクトでは、インデックスごとに1つのタイプのみを使用すると、ElasticSearch 6.xへの最終的なアップグレードがより簡単になります。

ジョナサンの答えは素晴らしいです。私は考慮すべき他のいくつかの点を追加します：

• 選択したソリューションごとに、シャードの数をカスタマイズできます。15個のプライマリシャードを持つ1つのインデックスを使用するか、5つのシャードに対して3つのインデックスに分割することができます-パフォーマンスの観点は変更されません（データが均等に分散されていると想定）
• データの使用について考えます。つまり。キバナを使用して視覚化すると、特定のインデックスを含めたり除外したりするのが簡単になりますが、タイプはダッシュボードでフィルタリングする必要があります
• データ保持：アプリケーションログ/メトリックデータでは、異なる保持期間が必要な場合は異なるインデックスを使用します

上記の両方の答えは素晴らしいです！

インデックスにいくつかのタイプの例を追加しています。図書館で本を検索するアプリを開発しているとします。ライブラリの所有者に尋ねる質問はほとんどありませんが、

質問：

1. 何冊の本を保管する予定ですか。

2. どんな本を図書館に保管しますか？

3. どのように本を検索しますか？

答え：

1. 50 k〜70 k冊の本を保管する予定です（およそ）

2. 15 k〜20 kの技術関連の本（コンピュータサイエンス、機械工学、化学工学など）、15 kの歴史書、10 kの医学科学書を用意します。言語関連の書籍（英語、スペイン語など）10 k

3. 著者名、著者姓、出版年、出版社名で検索します。（これにより、インデックスに格納する必要がある情報についてのアイデアが得られます）

上記の回答から、インデックス内のスキーマは次のようになるはずです。

//これは例のためだけの正確なマッピングではありません

            "yearOfPublish":{
                "type": "integer"
            },
            "author":{
                "type": "object",
                "properties": {
                    "firstName":{
                        "type": "string"
                    },
                    "lastName":{
                        "type": "string"
                    }
                }
            },
            "publisherName":{
                "type": "string"
            }
        }

上記を実現するために、Booksと呼ばれる1つのインデックスを作成し、さまざまなタイプを持つことができます。

インデックス：本

タイプ：科学、芸術

（または、より多くの本がある場合は、テクノロジー、医学、歴史、言語など、多くのタイプを作成できます）

ここで注意すべき重要な点は、スキーマは似ていますが、データが同一で​​はないということです。もう1つ重要なことは、保存するデータの合計です。

上記がインデックス内の異なるタイプに移動するときに役立つことを願っています。異なるスキーマがある場合は、異なるインデックスを検討する必要があります。少ないデータのための小さなインデックス。ビッグデータのビッグインデックス:-)