V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
推荐工具
RoboMongo
推荐书目
50 Tips and Tricks for MongoDB Developers
Related Blogs
Snail in a Turtleneck
vlike
V2EX  ›  MongoDB

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

  •  
  •   vlike · 2015-10-17 07:25:46 +08:00 · 4657 次点击
    这是一个创建于 3325 天前的主题,其中的信息可能已经有所发展或是发生改变。
    需求不太好描述,我就抽象一下,用小说数据结构来举例说明吧,
    这样一下子容易理解多了,理想中的数据看起来应该是这样的:

    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 分片?
    9 条回复    2015-10-17 12:15:51 +08:00
    cdxem713
        1
    cdxem713  
       2015-10-17 08:56:25 +08:00
    可以把内容单独分到一个 collection 里面,章节里面存 ref (就是表链接,不知道有没有表述清楚)
    还有就是不要用 id 来查询,最好是使用内部的_id 吧
    ljbha007
        2
    ljbha007  
       2015-10-17 09:03:23 +08:00
    ljbha007
        3
    ljbha007  
       2015-10-17 09:18:06 +08:00
    mongo 官方是推荐 manual reference 的 也就是自己吧_id 字段存下来
    DBRef 主要是用于一个 collection 中关联了多个其它 collection 为了减少出错使用 性能上好像并没有什么区别
    CheungKe
        4
    CheungKe  
       2015-10-17 09:35:09 +08:00
    @ljbha007 请问下 mongo 横向扩展怎样,我们现在单表在千万以上,还没分表,只用 id 查询。预计 10 亿规模左右,想尝试下 mongodb 。
    ljbha007
        5
    ljbha007  
       2015-10-17 09:42:52 +08:00
    @CheungKe
    这个我还没有用到过
    你可以看看官方关于 sharding 的介绍
    http://docs.mongodb.org/manual/core/sharding-introduction/
    vlike
        6
    vlike  
    OP
       2015-10-17 09:57:29 +08:00
    @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
        7
    vlike  
    OP
       2015-10-17 09:59:26 +08:00
    @CheungKe

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

    不过前路不知道会遇到什么坑 ^_^
    ljbha007
        8
    ljbha007  
       2015-10-17 10:03:40 +08:00
    @vlike 会 但是你现在肯定还远远没到担心性能的时候
    cdxem713
        9
    cdxem713  
       2015-10-17 12:15:51 +08:00
    @vlike 看你的数据怎么用了,我想不到什么场景需要同时加载很多小说的全部内容的,内容一般只在详情的时候才会展示,也就只需要查询单个内容,这样的话存储为一个独立的 collection 没有任何问题,反而是你原来的那种存储方式对性能影响非常大
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2329 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 01:00 · PVG 09:00 · LAX 17:00 · JFK 20:00
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.