1

約 400 万のドキュメントと約 5 ~ 6 GB のデータベース サイズで MongoDB を使用しています。マシンには 10GB の RAM が搭載されており、空き容量は約 3.7GB しか使用されていません。このデータベースは、ビデオゲーム関連のラダー (ランキング) Web サイトに使用され、地域ごとに区切られています。

これはかなり書き込み負荷の高い操作ですが、それでもかなりの数の読み取りが行われます。外部ソースに 1 ~ 2 時間ごとにクエリを実行するアップデーターを使用しています。次に、このアップデーターがレコードを処理し、データベース上のドキュメントを更新します。アップデーターは一度に 1 つのリージョンのみを処理するため (前の段落を参照)、データベースの約 33% が更新されます。

アップデーターが実行されると、その実行中に、平均フラッシュ時間が約 35 ~ 40 秒まで急上昇し、他のクエリで一般的な速度低下が発生します。アップデーターは SEPARATE MACHINE 上の RAN であり、すべてのデータがサードパーティから取得および処理されたときに、最後に MongoDB にのみクエリを実行します。

一部の人々は、更新の数を遅くするか、変更したプレーヤーのみを更新することを提案していますが、問題はランキングにあります. プレイヤー間の同点をサポートしているため、ランクを事前に計算する必要があります。そのため、実際にランクを変更したユーザーが数人しかいない場合でも、それに応じて残りのユーザーのランクを更新する必要があります。少なくとも、MySQL の場合はそうでした。MongoDB を使用して、最大 800K から 120 万のドキュメントをランク付けするための適切なソリューションがあるかどうかはわかりません。

私の質問は、私たちが経験しているフラッシュとスローダウンをどのように改善できるでしょうか? なぜこんなに急上昇しているのですか?データベースは頻繁に更新されるため、ジャーナリングを無効にすると (I/O の負荷を軽減するために) 役に立ちますか?

サーバーの状態: http://pastebin.com/w1ETfPWs

4

2 に答える 2

5

仕事に間違ったツールを使用しています。MongoDB は、大規模なはしごをリアルタイムで、少なくとも迅速にランク付けするようには設計されていません。

Redis のようなものを使用してください。Redis には、このジョブ専用に設計された「ソート済みリスト」と呼ばれるものがあります。これにより、1 億のエントリを保持し、5000000 番目から 5001000 番目までをサブミリ秒の速度で取得できます。

公式サイトから ( Redis - Sorted sets ):

ソートされたセット

ソート済みセットを使用すると、非常に高速な方法で(要素数の対数に比例する時間で)要素を追加、削除、または更新できます。要素は順番に取得され、後で並べ替えられないため、スコアまたはランク (位置) による範囲を非常に高速に取得することもできます。ソートされたセットの中間へのアクセスも非常に高速であるため、必要なものすべてにすばやくアクセスできる非繰り返し要素のスマート リストとしてソート セットを使用できます: 要素の順序、高速な存在テスト、中間の要素への高速アクセス!

要するに、ソートされたセットを使用すると、他の種類のデータベースではモデル化が非常に難しい多くのタスクを優れたパフォーマンスで実行できます。

ソート済みセットを使用すると、次のことができます

新しいスコアが送信されるたびに、ZADD を使用して更新する大規模なオンライン ゲームでリーダー ボードを取ります。ZRANGE を使用してトップ ユーザーを簡単に取得できます。また、ユーザー名を指定して、ZRANK を使用してリスト内のランクを返すこともできます。ZRANK と ZRANGE を一緒に使用すると、特定のユーザーと同様のスコアを持つユーザーを表示できます。すべて非常に迅速に。

ソート済みセットは、Redis 内に保存されているデータのインデックスを作成するためによく使用されます。たとえば、ユーザーを表すハッシュが多数ある場合、ユーザーの年齢をスコアとして、ユーザーの ID を値として持つ要素を持つソート済みセットを使用できます。したがって、ZRANGEBYSCORE を使用すると、特定の年齢間隔ですべてのユーザーを簡単かつ迅速に取得できます。

Sorted Set はおそらく最も高度な Redis データ型です。そのため、Sorted Set コマンドの完全なリストをチェックして、Redis で何ができるかを発見してください!

于 2013-08-10T06:04:30.863 に答える
1

ディスクの統計情報が表示されていないため、ディスクが飽和状態になっていると思います。

これは で確認できiostat -xmt 2%util列を確認します。

ジャーナリングを無効にしないでください。後でマシンがクラッシュしたときに、さらに問題が発生するだけです。

コレクションを分離しても効果はありません。データベースを分離することはできますが、IO バウンドの場合、これは何の役にも立ちません。

オプション

私が正しく、ディスクが飽和している場合、RAID 10 構成にディスクを追加すると、パフォーマンスと耐久性が大幅に向上します。ジャーナルを SSD に分離する場合はなおさらです。

このマシンが単一のサーバーであると仮定すると、レプリカセットをセットアップして、そこに読み取りクエリを送信できます。これはかなり役立つはずですが、ディスクほどではありません。

于 2013-07-11T13:03:28.113 に答える