0

現在、単一の MongoDB サーバーを実行しています (運用中)。その中で最大のコレクションは User と呼ばれます。このコレクションにはマルチキー (配列) インデックスがあります。User コレクションに対する主なクエリは、マルチキーのインデックス付きフィールドの値に対する $or クエリです。このコレクションのもう 1 つのフィールドは、PageViews の配列です。

サーバーが忙しくなってきているので、現在のパフォーマンスを維持できるようにサーバーを分割したいと考えています。もちろん、問題はシャード キーの選択です。これを読んでみると、マルチキー インデックスと、主要なクエリに含めることができる他のフィールドがないため、クエリの分離に失敗しているようです。

さまざまな記事で、ランダムな値でシャード キーを作成するのは得策ではないことが指摘されています。これは、クエリの分離を失うためです。しかし、とにかくクエリを適切に分離することができないので、ランダムな値をシャーディングするだけでよいのでしょうか?

他の誰かがこの状況にありましたか?良い選択肢はありますか?

4

1 に答える 1

0

うまくいくと思う計画があるので、それをコミュニティと共有したいと思います.

私のシナリオでは、マルチキー インデックス フィールドには、プレフィックスによって明確化された多数の項目が含まれています。プレフィックスは、マルチキーに格納されている値のタイプを示します。

私の解決策は、どの項目タイプが最も頻繁に照会されるかを把握することです。私のシナリオでは、これが何であるかを知っており、90% 以上の確率でクエリされるアイテム タイプであると言えます。次に、マルチキーに保存されたこのタイプの項目の最後の値を格納する別のフィールドをドキュメントに作成します。次に、この新しいフィールドをシャード キーとして使用します。最後に、アプリケーション層を変更して、新しいフィールドで最初のクエリを実行します。そのクエリが失敗した場合は、マルチキー フィールドに対してクエリを実行します。クエリの 90% 以上をクエリ分離する必要があります。残りはすべてのシャードで実行する必要があります。良い妥協のようです。

于 2013-01-16T17:32:01.123 に答える