数据结构设计上遇到点难题

[vlike]

需求不太好描述，我就抽象一下，用小说数据结构来举例说明吧，
这样一下子容易理解多了，理想中的数据看起来应该是这样的：

db.book.collection 里的文档：

{
name: 小说名
chapter: [
{id: 1, name:章节名, text:小说内容},
{id: 2, name:章节名, text:小说内容},
{id: 5, name:章节名, text:小说内容},
{id: 9, name:章节名, text:小说内容}
]

}

需求：
1 数据需要分片，因为小说会不断增多
2 chapter 里面的章节会不断增加
3 chapter 里的 DOC 能够按 ID 范围读取,例如取 5-9 章节
4 chapter 能够按列表位置读取，例如读第 0 位，就是取出 ID 为 1 的文档
5 可以返回 chapter 成员的所有 ID ，如 1,2,5,9

作为一个 mongodb 新手，我现在还不确定能不能实现以上所有需求，
但有一点，
mongodb 好像有：每个文档最大 16M 的限制，这样 chapter 不断增加会超出其这个限制，
所以按上面的结构去设计，不知道最终会是一个什么后果，

能不能把 chapter 提出来作为一个 collection ？
就是说 chapter 库下有很多很多 db.chapter.12345 这样的东西，
mongodb 是否允许有很多很多 collection ？

如果允许，是否又能按整个 collection 分片？

[cdxem713]

可以把内容单独分到一个 collection 里面，章节里面存 ref （就是表链接，不知道有没有表述清楚）
还有就是不要用 id 来查询，最好是使用内部的_id 吧

[ljbha007]

楼主读一下这三篇文章就很清楚改怎么做了
http://docs.mongodb.org/manual/tutorial/model-embedded-one-to-one-relationships-between-documents/
http://docs.mongodb.org/manual/tutorial/model-embedded-one-to-many-relationships-between-documents/
http://docs.mongodb.org/manual/tutorial/model-referenced-one-to-many-relationships-between-documents/

楼上说的没错 你这种情况应该 用“表间关联”的模式 这样不仅不会受文档大小限制 还便于搜索和索引

[ljbha007]

mongo 官方是推荐 manual reference 的 也就是自己吧_id 字段存下来
DBRef 主要是用于一个 collection 中关联了多个其它 collection 为了减少出错使用 性能上好像并没有什么区别

[CheungKe]

@ljbha007 请问下 mongo 横向扩展怎样，我们现在单表在千万以上，还没分表，只用 id 查询。预计 10 亿规模左右，想尝试下 mongodb 。

[ljbha007]

@CheungKe
这个我还没有用到过
你可以看看官方关于 sharding 的介绍
http://docs.mongodb.org/manual/core/sharding-introduction/

[vlike]

@ljbha007
@cdxem713

感谢两位，有点明白了，我现在理解的是：

把所有小说的所有章节都保存在同一个 collection 下面，是不是变成这样：

db.chapter.collection:

[
{bookid: 1, chapterid: 2, name:章节名, text:小说内容},
{bookid: 1, chapterid: 5, name:章节名, text:小说内容},
{bookid: 1, chapterid: 6, name:章节名, text:小说内容},
{bookid: 1, chapterid: 9, name:章节名, text:小说内容},
{bookid: 99, chapterid: 3, name:章节名, text:小说内容},
{bookid: 99, chapterid: 7, name:章节名, text:小说内容},
{bookid: 99, chapterid: 9, name:章节名, text:小说内容},
{bookid: 99, chapterid: 6, name:章节名, text:小说内容},
]


如果是这样，那 chapter 集合会很大很大，建索引是肯定的，

但查询的速度会因数据量不断变大而打拆扣吗？

[vlike]

@CheungKe

我们也是因为 mongodb 扩展起来实在太简单了所以才打算尝试的，他那种分片随用随加的机制很吸引我。

不过前路不知道会遇到什么坑 ^_^

[ljbha007]

@vlike 会 但是你现在肯定还远远没到担心性能的时候

[cdxem713]

@vlike 看你的数据怎么用了，我想不到什么场景需要同时加载很多小说的全部内容的，内容一般只在详情的时候才会展示，也就只需要查询单个内容，这样的话存储为一个独立的 collection 没有任何问题，反而是你原来的那种存储方式对性能影响非常大