どのハードウェアが良いMongoDBサーバーを作りますか?どこで入手できますか?


13

今dell.comにいて、小規模なスタートアップ向けにMongoDBデータベースを実行するサーバーを購入しているとします。文字通り、毎分数万の書き込みと読み取りを処理する必要があります(ただし、小さなオブジェクト)。あなたは2プロセッサに行きますか?RAMにもっと投資しますか?

聞いたことがあります(間違っている場合は修正してください)MongoDBはRAMで最大限の処理を行ってから、すべてをディスクにフラッシュします。そしてソリッドステートドライブ..右?

ハイエンド(〜11,309ドル、2つの高価なプロセッサ、96GBのRAM)サーバーまたは2x(〜$ 6,419、2つの高価なプロセッサ、12GBのRAM)サーバーの方が良いでしょうか?

デルは大丈夫ですか?(私はポルトガルの米国外にいます)


3
スタートアップのためにEC2のようなものを購入するのではなく、なぜハードウェアを購入するのですか?少なくとも最初は、要件が何になるかがわかるまで。

トムに同意します。クラウド上でいくつかのインスタンスを取得してみませんか?

1
@mixdev、あなたは間違っています:「Linux、NUMA、MongoDBは一緒にうまく動作しない傾向があります。」出典:mongodb.org/display/DOCS/NUMA
シャドック

回答:


19

最初は、RAMを強化する必要があります。必要なRAMは、保存するデータの量、コレクションの数、それらのコレクションのインデックス、データアクセスパターンなどに依存します。多くの要因。

最も重要なことは、インデックスをRAMに保持するのに十分なRAMを用意することです。そうしないと、MongoがメモリマップファイルをRAMに出し入れする間、サーバーが常にページングするため、パフォーマンスが劇的に低下します。これらのすべてにもかかわらず、書き込み速度が影響を受けることはありませんが、他のすべては影響を受けます。インデックスがRAMに収まらなくなると、キューからの書き込み、フラッシュ、ダンプなどの処理はすべて劇的な打撃を受けます。

したがって、本当の短い答えはありません。基本的に、インデックスについて賢くしてください。必要なものだけを使用してください。可能な場合はコレクションを小さくします(つまり、可能な場合は複数に分割します)。キャップ付きコレクションも興味深いものです。


1
私たちの経験では、MongoがクエリのためにRAMを使い果たすと、クエリはドキュメントに移動するだけでなく(永久に、5分、15分、時間...)、挿入が失敗し始めます。
ジョーンズームは


6

MongoDBで必要なのはRAMです。そしてさらにいくつかのRAM。RAMを購入しても害はありません。


3

プロダクションハードウェアを購入する段階にある場合、実行しているアプリケーションは既に作成されている必要がありますよね?したがって、お持ちのハードウェアでアプリを実行し、メトリックを取得してください。一部のコンポーネントを徐々に変更し、より多くのメトリックを取得します。完了したら、アプリケーションとシナリオにとってどの焦点が最も重要であるかがわかります。


3

最初に-できるだけ多くのRAMを購入します。2番目の制限要因はディスク速度です。RAIDが役立ちます。SSDが役立ちます。より多くの破片が役立ちます。ディスク効率と必要な応答時間と比較してスループットを測定し、予算内で何をするかを決定します。


1

Linuxクラスター化ソリューションがより良い、より安価な代替品になるのではないかと思う。

MongoDBを使用すると、多くのサーバーにデータを分散できます。これは、1つのホーンサーバーでは不可能です。

MongoDBは、ホーンキングサーバーへのリレーショナルデータベースの展開では十分な拡張性が得られないことがわかった後の次のステップの1つだと思いました。


1

1分あたり何万もの書き込みは何もありません。適切なハードウェアで1 あたり50.000以上の書き込みを取得できます。ハードウェアの仕様は、実際に何をしようとしているかによって異なります。一般に、大規模なデータベースと高速IOシステムに十分なRAMは、まともなCPUの横に重要です...


0

ハードウェアを設計する前に、しっかりとしたベースラインを確立することが重要です。一般に、この種の質問は、誰もがあなたの質問に答えることを検討する前に、経験豊富なmongoDBの人々によって尋ねられることを期待しています。

現在のアプリケーション統計(ある場合)

  • これまでの合計記録?
  • ストレージの見積もりを開始しますか?
  • 予想成長率/月?
  • 平均文書サイズ?

データ取り込み作業負荷

  • 1日あたりの新しい挿入数、1秒あたりのピークおよび平均?
  • 更新/日、1秒あたりのピークと平均?
  • 読み取り/日、ピークと平均/秒?
  • クエリごとに返されるドキュメントの平均数:70
  • 削除/日、ピークと平均/秒:なし
  • 一括読み込み/一括更新はありますか?もしそうなら、どれくらいの大きさと頻度ですか
  • 文書の種類はいくつありますか?
  • それぞれいくつ?
  • ドキュメントはどのように見えると思いますか(サンプルドキュメント)?

クエリパターンとパフォーマンスの期待

  • Response SLAをお読みください?
  • 応答SLAを書き込みますか?
  • 読み取りは範囲ベースですか、ランダムですか?

予想されるアクセスパターン

  • セカンダリインデックスの数は必要ですか?
  • 属性の数?
  • ソート条件?
  • シングルまたはコンパウンド?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.