2013-06-04 16 views
23

私たちのアプリケーションでは、dbに5つのコレクションが必要です。私たちのアプリケーションにクライアントを追加するときは、顧客ごとに別々のDBを管理したいと考えています。たとえば、500人の顧客がいる場合、500 dbsと2500のコレクション(各データベースには5つのコレクションがあります)があります。このようにして、各顧客データを分離することができます。私の懸念は、パフォーマンス上の問題につながるかどうかです。MongoDBのパフォーマンス - 複数のデータベースを持つ

UPDATE:はまた、このgoogle-group discussionに従ってください。

+0

多くのお客様には、代わりにisloatedインスタンスを探すほうが良いかもしれませんが、 – Sammaye

+2

というものがあります。これは、それぞれが別のmongodインスタンス/レプリカセットです。これはMongoDBの多くのユーザーが複数のテナントをホストしている場合の非常に一般的な構成で、個別のDBが標準的な答えです。 –

答えて

30

私たちのアプリケーションでは、データベースに5つのコレクションが必要です。クライアントを に追加する際には、 お客様ごとに別々のdbを管理したいと考えています。たとえば、500人の顧客がいる場合は、 500 dbsと2500のコレクション(各データベースには5つのコレクションがあります)があります。この方法で、 それぞれの顧客データを分離することができます。

これは素晴らしいアイデアです。 MongoDBのデータベースレベルのセキュリティを使用して、他の顧客のデータへの不慮のアクセスを防ぐことができます。

私の懸念は、パフォーマンス上の問題につながるかどうかです。

ない、と(それがあなたのシナリオで可能の場合)実際には、彼らが競合している場合(それはまだかもしれない別の顧客のパフォーマンスに影響を与えない一人の顧客のためのデータベース・レベルのロックと同様に非常に重いロック競合を助けます同じ入出力帯域幅ですが、--directoryperdbオプションを使用すると、それらのDBを別々の物理デバイスに配置することができます。

シャーディングでは、複数のシャード間でデータベースをラウンドロビンするだけで、別のクラスタに負荷を分散させることができます(そのレベルに達した場合およびそのレベルに達したとき)

他の回答の主張とは異なり、TTLMonitorスレッドは、削除されていない(そして空きリストに追加されていない)文書をRAMにプルしません。 TTLインデックスは、文書が期限切れになるかどうかを知るために、また文書を直接配置するためにも使用されます。

1つのデータベースに対して多数のコレクションソリューションを強くお勧めします。これは、負荷を分割したり、セキュリティを提供したり、アプリケーション側で処理するのが簡単ではないためです。

+0

+1私はまだ適切な答えが状況についてのより多くの情報を要求しているとは思うが、あなたはおそらく私よりも多くの経験を積んでいる。 –

+0

私は同意します - 大部分は、十分な基本情報があるとしたら、多くのデータベースがあれば、多くの断片にまたがってコレクションを分割しなければならないときよりも複雑さを減らすことができます。言い換えれば、そのユースケースは簡単に水平に拡大され、dbを安全なオプションに分割します。 –

+0

OPのシナリオではこれは理にかなっていると思いますが、ユーザー数は少ないと思いますが、ユーザーあたりのドキュメント数が比較的多いのですが、数千人の顧客(1百万人と言えます) – nick

関連する問題