2

さて、私のゲームのすべてのプレイヤーは私のプレイヤー コレクションにドキュメントを持ち、各プレイヤーはゲームの状態をシリアル化した 1 つの文字列を持っています。したがって、このストリングは長くも短くもなり、プレーヤーごとに大きく異なります。

モンゴの経験があまりない人に、コレクション内のすべての文字列をすべて同じ長さになるようにパディングする必要があると言われました。そのため、すべてのショートおよびミディアム ゲーム ステート文字列の最後に大量のゼロを追加するようにします。

A) これでいいの？

B) ゲームの最長の長さを調べる方法がよくわからないので、どこまでパディングすればよいか、後でゲームの状態がパディングの長さを超えた場合はどうすればよいかわかりません。

私の友人は、断片化のためにmongoコレクションが爆発し続け、パディングを実装するとすべての問題が解決したと言いました。

ああ、それが問題だとは思いませんが、私のコードはphpであり、明らかにphp pecl mongoドライバーを使用しています

ご意見やご感想をお寄せいただきありがとうございます!!!!!

-デイブ

4

3 に答える 3

2

MongoDB は、作成時にドキュメント用のスペースを割り当てます。ドキュメントのサイズが大きくなった場合は、ドキュメントを新しい場所に移動して、より大きなサイズに対応する必要があります。元のスペースはオペレーティング システムに解放されません。代わりに、MongoDB は最終的にこのスペースを再利用します。これが発生するまでは、データベースが過剰に割り当てられているか、断片化されているように見えることがあります。

それで、おそらくあなたの友人に何が起こったのでしょう：

  • ドキュメントが挿入されました
  • フィールドが更新されると、サイズが大きくなることがあり、そのためドキュメントが大きくなりました
  • ドキュメントが大きくなるにつれて移動され、データベースが過剰に割り当てられました (あなたの友人が断片化と呼んだもの)。

また、ドキュメントのフィールドをパディングすることで、友人はドキュメントのサイズが決して大きくならないようにすることができ、したがって彼のデータベースが過剰に割り当てられることはありませんでした。

パディング アプローチは有効ですが、アプリケーションが複雑になります。通常、値自体のサイズを固定するのではなく、最終的に作成されるフィールドに対してパディングが実行されますが、考え方は同じです。あなたの場合、フィールドサイズを予測できないため、パディングが優れたオプションであるようには思えません。

代わりに、usePowerOf2Sizes の使用を検討してください: http://docs.mongodb.org/manual/reference/command/collMod/

この構成により、ドキュメントに割り当てられたスペースが自動的に埋められ、MongoDB によってスペースが効率的に再利用される可能性が高くなりますが、データベースがわずかに大きくなります。

于 2013-03-26T10:05:36.237 に答える
1

A) これでいいの？

依存します。ゲーム ドキュメントがディスク上で頻繁に移動するような方法で頻繁に更新される場合、パディングが役立つことに気付くかもしれませんが、Shakespear の作品全体が 4 MB のドキュメントに収まり、余裕が残っていることを考えると、あなたが持っている文字列が大量の断片化を引き起こすことを非常に疑ってください。実際、もしそうなら、私はかなり驚かれることでしょう。

理論的に発生する可能性のある問題は、フリーリスト内に大量のドキュメントを取得し、再利用できないバケットを削除して、断片化が発生することです。

それだけでなく、ディスク移動の IO が永続的になると致命的となる可能性があります。

B) ゲームの最長の長さを調べる方法がまったくわからないので、それらをどこまでパディングすればよいか、後でゲームの状態がパディングの長さを超えた場合はどうすればよいかわかりません。

実際、アイデアは90％の時間役に立たず、これが問題になる場合は、ドキュメントに2の累乗のサイズ割り当てを使用する方がよいでしょう：http://docs.mongodb.org /manual/reference/command/collMod/#usePowerOf2Sizes

このオプションを使用すると、断片化の問題を解決するためのはるかに最適なアプローチになります。

私の友人は、断片化のためにmongoコレクションが爆発し続け、パディングを実装するとすべての問題が解決したと言いました。

私の友人の友人、いとこ、姪の友人も同様のことを言いました... これを自分でテストしたほうがいいでしょう.

彼が抱えていたより大きな問題は、彼が実行したインデックスとクエリにあったに違いありません。文字列の長さが原因で、実際に人為的なパディングを使用するほどディスクの移動時に大量の IO 使用が発生することは非常にまれです。

于 2013-03-26T09:47:52.787 に答える
0

あなたの質問から、これらの文字列は単なるブロブであることを理解しています。つまり、コンテンツの db クエリ/フィルタリングを許可するための何らかの方法で構造化されていません。この場合は、それらをファイルに保存し、ファイル名を mongo ドキュメントに保存します。

于 2013-03-26T05:43:21.453 に答える