Amazon DynamoDB の上にオブジェクトのスケーラブルな順序付けされていないコレクションを実装することを検討しています。これまでのところ、次のオプションが検討されています。
DynamoDB ドキュメント データ型 (マップ、リスト) を使用し、ドキュメント パスを使用してスタンドアロン アイテムにアクセスします。これには、コレクションが 400KB のデータに制限されるという明らかな欠点が 1 つあります。つまり、サイズにもよりますが、おそらく 1..10K オブジェクトです。あまり目立たない欠点は、そのようなコレクションに新しいオブジェクトを挿入するコストが膨大になることです。Amazon は、新しく追加されたオブジェクトだけでなく、アイテムの合計サイズに基づいて書き込み容量が差し引かれることを指定しています。サイズ制限に近づくと 1KB オブジェクトを挿入します。それで、これが除外されたと考えると？
複合プライマリ ハッシュ + 範囲キーを使用します。ここで、プライマリ ハッシュはコレクション内のすべてのオブジェクトで同じままであり、範囲キーは単なるランダムまたはアトミック カウンターです。明らかな欠点は、同一のハッシュ キーを使用すると、キーの配布がうまくいかないことです。多数のオブジェクトを含むコレクションがある場合、カーディナリティが低くなります。これは、不適切なパーティショニングを意味し、同じコレクションのすべての読み取り/書き込みが 1 つのシャードにスタックされるというスケールの問題が発生し、DynamoDB パーティションの 1 秒あたり 3000 回の読み取り / 1000 回の書き込みの制限を受けることになります。
セカンダリ ハッシュ + レンジ キーでグローバル セカンダリ インデックスを使用します。ハッシュ キーは同じコレクションに属するすべてのオブジェクトで同じままであり、レンジ キーはランダムまたはアトミック カウンターです。上記と同様に、パーティショニングは GSI にとって不適切になり、同一のハッシュが多すぎるとボトルネックになり、プロビジョニングされたすべての容量がインデックスに急速に排出されます。GSI が正確にどのように実装されているかわかりませんでした。
問題は、私が (2) または (3) と一緒に暮らすことができ、理想的ではないキー配布に苦しむことができるかどうか、または見過ごされていたコレクションを実装する別の方法があるかどうか、またはおそらく別の nosql データベースエンジンを検討することを検討する必要があるかどうかです。