1

アプリケーションのデータ ストレージ サービスを開始しています。MongoDB はストレージ メカニズムとして実行されており、開始するために 2 つのシャードを作成しました。

アプリケーションはイベント データを保存し、すべてのデータは次のように構造化されます。

{ 
  _id: '4fa2f7e25626cd1374000002', 
  created_at: '2012-05-03T21:25:54 00:00', 
  name: 'client_session_connect', 
  session_remote_id: '74ACF9AA-9E09-11E1-8C9E-8462380DA5E6', 
  zone_id: '74ACF9AA-9E09-11E1-8C9E-1231380DA5E6',
  additional: {
    some_other_key: 'value'
  }
}

イベントにはさまざまな名前が付けられ、新しいイベント名を使用していつでも新しいイベントを作成できます。システムには同じ名前のイベントがたくさんあります。_id、created_at、および name はすべてのイベントの一部になりますが、他の値は保証されません。

私が読んだ内容 ( hereおよびhere )に基づいて、最適なシャーディング キーは { name: 1, created_at: 1 } のようです。この解釈で正しいでしょうか？

4

1 に答える 1

4

あなたが述べたことから、いくつかの注意点がありますが、それは良いシャードキーになるようです:

-シャード キーは不変であるため、ドキュメントの「名前」フィールドを変更する必要がある場合は、それを削除して再挿入する必要があります (名前を頻繁に変更するつもりがない限り、おそらくこれは問題にはなりません) .

-同じ「名前」で多くのドキュメントを立て続けに書き込む場合、「created_at」はおそらく増加するフィールドであるため、これらの書き込みはすべて同じチャンクに送られます。最終的に、チャンクは複数のチャンクに分割され、受信側のマシンでバランスが取られるため、これは、同じ「名前」を持つドキュメントの大量の書き込みを受信することが予想される場合にのみ問題になります。

-「名前」が均一に分散されていない場合は、名前をハッシュして結果をドキュメントの新しいフィールドに保存し、シャード キー {hashedName : 1, created_at : 1} を作成できます。これにより、負荷分散がより均一になり、後でバランシングの量が減る可能性があります。ただし、ドキュメントが少し複雑になります。

これらのことを認識していると仮定すると、{name: 1, created_at: 1} が最適なシャード キーになる可能性があります。

于 2012-06-07T20:58:07.007 に答える