2

ゲームサーバーのさまざまな地域で数時間ごとに実行されるアップデータースクリプトがあります。このスクリプトをより頻繁に実行し、リージョンを追加したいと考えています。理想的には、CPU と I/O の負荷をできるだけ均等に分散したいと考えています。以前は mysql を使用してこのスクリプトを実行していましたが、現在、この Web サイトではすべてに mongodb を使用しているため、アップデーター スクリプトも mongodb に移動することに意味がありました。mongodb がすべての更新をデータベースにフラッシュすると、I/O スパイクが非常に高くなります。

C#あまり相対的ではないと思いますが、スクリプトは で書かれています。さらに重要なことは、これらのスクリプトの 1 つが実行されるたびに、約 50 万から 120 万の更新を行っていることです。コードとインデックスでいくつかの小さな最適化を行いましたが、現時点では、実際の mongodb 設定を最適化する方法に行き詰まっています。

いくつかの他の重要な情報は、私たちがこのようなことをするということです

update({'someIdentifier':1}, $newDocument)

これの代わりに：

$set : { internalName : 'newName' }

これが行うかどうかよりもパフォーマンスがはるかに悪いかどうかはわかり$setません。

負荷を分散するために何ができるでしょうか? それが役立つ場合は、VM により多くのメモリを割り当てることができます。

より多くの情報を提供できることをうれしく思います。

4

1 に答える 1

5

ここに私の考えがあります：

1) パフォーマンスに関する懸念事項を適切に説明します。

これまでのところ、問題が何であるか、または問題があるかどうかを実際に把握することはできません。私が知る限り、あなたは約 1 GB の更新を行っており、約 1 GB のデータをディスクに書き込んでいます...あまりショックではありません。

ああ、いくつかのテストを行います - Not sure if this is a lot worse in performance than doing $set or not.- なぜわからないのですか? あなたのテストは何を言っていますか？

2) ハードウェアの不一致がないかどうかを確認します。

ディスクが遅いだけですか？ワーキング セットは RAM よりも大きくなっていますか?

3) mongo-user およびその他の MongoDB 固有のコミュニティで質問する...

...単純に、ここに答えがないよりも良い答えが得られる可能性があるからです。

4) TokuMX の使用を検討してください。

待って何？基本的に彼自身の製品をスパムすることを提案した最後の男を非難しませんでしたか?

確かに、これは Mongo にごく最近導入されたばかりの新製品ですが (mysql バージョンがもう少し長く存在するようです)、基本はしっかりしているようです。特に、挿入だけでなく、更新/削除も高速であることが非常に優れています。問題のドキュメントに実際に行って変更を加える必要はありませんが、挿入/更新/削除メッセージをインデックス構造の一部としてバッファリングされたキューに保存します。バッファーがいっぱいになると、これらの変更が一括で適用されるため、I/O の点で非常に効率的です。その上、データの保存に圧縮を使用するため、I/O がさらに削減されます。書き込みが物理的に少なくなります。

これまでに見た最大の欠点は、ビッグデータで最高のパフォーマンスが得られることです。一連のテストで BTree に負けるよりも、データが RAM に収まる場合です。それでも速いですが、それほど速くはありません。

ええ、それは非常に新しいものであり、テストなしでは何に対しても信頼できず、ミッションクリティカルではないものに対しても信頼できませんが、それはあなたが探しているものかもしれません. そして TBH は、単なる新しいインデックス/ストア サブシステムであるため、別の製品よりも mongodb の最適化に適しています。特に、mongodb のインデックス/ストレージ システムは常に少し単純なので、「キャッシュにメモリ マップ ファイルを使用してみましょう」などです。

于 2013-07-13T04:59:20.313 に答える