Mongo DB设计，嵌入与关系 [英] Mongo DB Design, embedding vs relationships

问题描述

我正在建立一个简单的会计系统，其中用户有很多账单.现在，我试图确定帐单应该是其自己的集合，还是应该嵌套在用户内部.我倾向于前者，但我从未做过任何noSQL的工作，所以我只是反复尝试，我认为这对我来说是有意义的.

I'm building a simple accounting system where a user has many bills. Now I'm trying to decide if bills should be its own collection, or nested within the user. I'm leaning towards the former but I've NEVER done any noSQL stuff so I'm just going by trial and error and what I think makes sense to me.

我知道Mongo的文件大小限制为4mb，这让我认为我应该为票据单独收集，因为这些票据每天都会积累，最终可能会占用大量空间.

I understand that Mongo has a 4mb document size limit which is what's making me think that I should have a separate collection for bills, as these will accumulate daily and could eventually take up a large amount of space.

我只是在寻求有关此事的意见.基本上，我将查询不同日期之间的用户帐单(就像您可以想象的那样，会计系统会这样做).

I'm just looking for opinions on the matter. Basically I'll be querying for bills of a user between different date periods (as you can imagine an accounting system would do).

并不是真的很重要，但是我在Rails3项目中使用了Mongoid.我想我会做类似的事情:

Not that it really matters but I'm using Mongoid in a Rails3 project. I figured I'd do something like:

class User
  references_many :bills
end

class Bill
  referenced_in :user
end

任何评论或设计建议都将不胜感激.

Any comments or design suggestions are greatly appreciated.

推荐答案

1)关于4MB的文档限制，这就是"MongoDB:权威指南"中所说的内容:

1) Regarding the 4MB document limit, this is what the "MongoDB: The Definitive Guide" says :

大于4MB的文档(转换为BSON时)无法保存到数据库.这是一个任意的限制(将来可能会提高)；这主要是为了防止不良的架构设计并确保一致的性能.要查看文档 doc 的BSON大小(以字节为单位)，请从外壳程序运行Object.bsonsize( doc ).

Documents larger than 4MB (when converted to BSON) cannot be saved to the database. This is a somewhat arbitrary limit (and may be raised in the future); it is mostly to prevent bad schema design and ensure consistent performance. To see the BSON size (in bytes) of the document doc, run Object.bsonsize(doc) from the shell.

为了让您了解4MB的大小，《战争与和平》的整个文本仅为3.14MB.

To give you an idea of how much 4MB is, the entire text of War and Peace is just 3.14MB.

最后，取决于您期望用户增加的账单数量.希望以上摘录能使您了解文档大小所带来的限制.

In the end it depends on how big you expect the bills for a user to grow. I hope the excerpt above gives you an idea of the limits imposed by the document size.

2)如果您知道永远不会对账单运行全局查询，则可以使用非规范化模式(帐单与用户文档一起使用)(这种查询的示例是您要检索十个帐单)最新的帐单已输入到系统中).如果使用非规范化架构，则必须使用map-reduce来检索此类查询的结果.

2) De-normalized schema (bills go with the user document) is the way to go if you know that you are never going to run global queries on bills (example of such a query is if you want to retrieve the ten most recent bills entered into the system). You will have to use map-reduce to retrieve results for such queries if you use a denormalized schema.

如果想要灵活地查询帐单，则标准化的模式(用户和帐单位于单独的文档中)是一个更好的选择.但是，由于MongoDB不支持联接，因此每次您要检索与用户相对应的帐单时，都必须运行多个查询.

Normalized schema (user and bills in separate documents) is a better choice if you want flexibility in how the bills are queried. However, since MongoDB doesn't support joins, you will have to run multiple queries every time you want to retrieve the bills corresponding to a user.

鉴于您提到的用例，我将使用非规范化模式.

Given the use-case you mentioned, I'd go with de-normalized schema.

3)MongoDB中的所有更新都是原子的并已序列化.那应该可以解决史蒂夫的担忧.

3) All updates in MongoDB are atomic and serialized. That should answer Steve's concern.

这些幻灯片可能会有所帮助. http://www.slideshare.net/kbanker/mongodb-meetup

You may find these slides helpful. http://www.slideshare.net/kbanker/mongodb-meetup

您还可以查看MongoDB的生产部署页面.您可能会发现SF.net幻灯片很有帮助.

You may also look at MongoDB's Production Deployments page. You may find the SF.net slides helpful.

这篇关于Mongo DB设计，嵌入与关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！