21

私は、ユーザーが多くの請求書を持っている単純な会計システムを構築しています。今、私は請求書をそれ自身のコレクションにするべきか、それともユーザー内にネストするべきかを決定しようとしています。私は前者に傾倒していますが、noSQLのことは一度も行ったことがないので、試行錯誤を繰り返して、自分にとって理にかなっていると思います。

Mongoには4MBのドキュメントサイズ制限があることを理解しています。これにより、請求書を個別に収集する必要があると思います。請求書は毎日蓄積され、最終的には大量のスペースを占める可能性があるためです。

私はその問題についての意見を探しています。基本的に、私は異なる日付期間の間のユーザーの請求書を照会します（会計システムが行うことを想像できるように）。

それは本当に重要なことではありませんが、私はRails3プロジェクトでMongoidを使用しています。私は次のようなことをすると思いました：

class User
  references_many :bills
end

class Bill
  referenced_in :user
end

コメントやデザインの提案は大歓迎です。

4

3 に答える 3

24

1）4MBのドキュメント制限に関して、これは「MongoDB：TheDefinitiveGuide」の内容です。

4MBを超えるドキュメント（BSONに変換した場合）はデータベースに保存できません。これはやや恣意的な制限です（将来的に引き上げられる可能性があります）。これは主に、悪いスキーマ設計を防ぎ、一貫したパフォーマンスを確保するためです。ドキュメントドキュメントのBSONサイズ（バイト単位）を確認するには、シェルからObject.bsonsize（doc）を実行します。

4MBの大きさを知るために、WarandPeaceのテキスト全体はわずか3.14MBです。

結局のところ、それはユーザーの請求額がどれだけ大きくなると予想するかによって異なります。上記の抜粋で、ドキュメントサイズによって課せられる制限について理解していただければ幸いです。

2）非正規化スキーマ（請求書はユーザードキュメントに付属）は、請求書に対してグローバルクエリを実行しないことがわかっている場合に使用する方法です（このようなクエリの例は、最新の10件の請求書を取得する場合です。システムに入力されました）。非正規化スキーマを使用する場合は、map-reduceを使用してそのようなクエリの結果を取得する必要があります。

請求書の照会方法に柔軟性が必要な場合は、正規化されたスキーマ（ユーザーと請求書が別々のドキュメントにある）の方が適しています。ただし、MongoDBは結合をサポートしていないため、ユーザーに対応する請求書を取得するたびに、複数のクエリを実行する必要があります。

あなたが言及したユースケースを考えると、私は非正規化スキーマを使用します。

3）MongoDBのすべての更新はアトミックであり、シリアル化されています。それはスティーブの懸念に答えるはずです。

これらのスライドが役立つ場合があります。http://www.slideshare.net/kbanker/mongodb-meetup

MongoDBの本番環境のデプロイメントページもご覧ください。SF.netのスライドが役立つ場合があります。

于 2010-09-28T15:54:55.077 に答える
1

検討したい質問の1つは、ユーザーのメンバーシップとは別に、請求書を個別に参照する必要がある場合があるかどうかです。もしそうなら、彼らが独立した存在を持っているならば、それはより簡単になるでしょう。

それとは別に、あなたがすでに特定したサイズ制限の問題は、それらを分割する良い理由です。

トランザクションの問題も発生する可能性があります。請求書が多数含まれている大規模なユーザーを作成している場合、異なる接続から同じユーザーに変更を合理的に同時に書き込むとどうなりますか？これをどのように解決するかを知るには、mongoについて十分に知りません-書き込みに異なる追加の請求書が含まれている場合は両方を取得しますが、既存の請求書に異なる変更が含まれている場合は上書きされると思います-他の誰かがこれについてコメントすることを願っていますが、少なくとも私はそれをテストします。別のコレクションに請求書を書いている場合、これは問題ではありません。

于 2010-09-28T14:56:38.987 に答える
1

この質問が解決されてから長い時間が経ちましたが、私は似たようなものを扱っていて、この問題を研究している他の人のために自分の調査結果を追加すると考えました。

私の理解では、バージョン1.8以降では4MBのドキュメントが16MBに拡張されています。これは、MongoDBメンバーの1人であるBankerによるビデオプレゼンテーションからのものです。私はこの値を検証していませんが、彼の言葉を受け入れています（彼が何について話しているのかを知っているといいのですが）。

請求書が埋め込まれた同じユーザーで複数の更新が発生した場合に何が起こるかについての質問については、同じビデオプレゼンテーションから、MongoDBが情報を非常に迅速に更新するため、通常は問題になりません。更新が行われている間、MongoDBインスタンスはロックダウンされるため、複数の更新が問題になることはありません。

埋め込まれたドキュメントについて私が懸念したのは、親ドキュメントから独立して扱うことができないということです。これは、私の意見では、埋め込まれたドキュメントをかなり無価値にします。これらは、特定のユースケースを満たすニッチなケースにのみ役立ちます。

私は個人的に、MongoDB（およびNoSQL DB）が特定のケースに役立つことを発見しましたが、従来のSQL/RDMSは大部分の問題に対して依然として優れています。あなたがCraigslistのような人で、スキーマの変更がアーカイブされたデータで実行するのに2か月かかる場合は、そうです、MongoDBとNoSQLは理にかなっています。しかし、大多数のアプリでは、その量のデータを処理することが大きな問題になるとは思いません。

于 2011-07-12T16:45:58.373 に答える