複数のタイプのドキュメントを単一のインデックスにインデックス付けすることのパフォーマンスへの影響を理解したいと思います。各タイプのアイテム数に不均衡があります (あるタイプには数百万のドキュメントがあり、別のタイプには数千のドキュメントしかありません)。いくつかのインデックスで問題を発見しました。型が 1 つのインデックス内で個別にインデックス化されているかどうか (またはそうでないか) を除外すると、役に立ちます。各テーブルが実質的に分離されているリレーショナル データベースの行に沿って、型が個別にインデックス化されていると想定できますか?
上記の答えが「いいえ」であり、そのタイプが事実上すべてひとまとめになっている場合は、残りの作業をレイアウトして、より詳細な入力を取得しようとします。
この例の使用例は、Twitter ユーザーのツイートをキャプチャすることです (わかりやすくするために所有者と呼びます)。Twitter の所有者ごとに 1 つのインデックスを持つマルチテナント環境があります。とはいえ、単一の所有者に焦点を当てると、次のようになります。
- 各タイムライン (メンション、ダイレクト メッセージ、私のツイート、完全な「ホーム」タイムライン) からのツイートを 1 つのインデックスにキャプチャし、各タイムライン タイプは ElasticSearch で異なるマッピングを持ちます。
- 各ツイートは、親のマッピングを使用して、ツイートを作成したユーザー (所有者である場合とそうでない場合がある) である親タイプを参照します。すべてのタイムライン タイプに対して 1 つの「ユーザー」タイプしかありません
- 1 回のクエリで 1 人の所有者だけを検索してファセットするので、複数のインデックスを検索する必要はありません。
- ホーム タイムラインは数百万のツイートをキャプチャする場合があり、所有者自身のツイートは数百または数千になる可能性があります。
- ユーザー ドキュメントは、Twitter のタイムライン外の情報で定期的に更新されるため、同じユーザー オブジェクトの複数のコピーを複数のインデックス間で同期させなければならない状況を (可能であれば) 回避したいと考えています。
数百万のドキュメントがインデックス化された「ホーム タイムライン」タイプを除外し、数千のエントリを持つタイプだけを残した場合でも、数百万のドキュメントを含むインデックスに対するクエリの応答がはるかに遅いことに気付きました。ツイートとユーザーの間には親子関係があるため、型を個別のインデックスに分割する必要はありません (必要な場合を除く)。
問題が特定のインデックス内のドキュメントの総数にあるのか、「has_child」フィルター処理されたクエリの操作に関係があるのか 、クエリまたはファセットのその他の貧弱な設計に関係があるのか を理解できる方法はありますか?
任意の入力をいただければ幸いです。
編集
ツイートがタイムラインごとに保存されるという記述を明確にするため。これは、home_timeline、my_tweets_timeline、mentions_timeline、direct_messages_timeline などに対して定義された ElasticSearch タイプがあることを意味します。これらは、標準の twitter.com UI に表示されるものに対応しています。そのため、一部の重複はありますが、一連のツイート間には自然な分割があります。
has_child クエリをチェックアウトするために戻ってきましたが、これは現時点で明確な赤ニシンです。大規模なインデックスに対する基本的なクエリは、数千行しかないタイプ (my_tweets_timeline) をクエリする場合でも、はるかに遅くなります。