数据结构设计上遇到点难题 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
vlike
V2EX    MongoDB

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

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

    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     Solana     867 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 22ms UTC 19:41 PVG 03:41 LAX 12:41 JFK 15:41
    Do have faith in what you're doing.
    ubao snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86