数据库 关于类似网易评论盖楼的数据库设计

tony · 2012年04月11日 · 最后由 riioch 回复于 2014年12月16日 · 20953 次阅读

关于类似网易评论盖楼的数据库设计 或者 reddit 那种方式,对评论进行评论 表应该怎么设计?

我的想法是一次性把某主题下所有的评论全部读取处理,做完处理再显示 但要是评论很多,一次性全部取出来耗资源,大家有没有更优化的设计想法?

其中一个方案是 google "MPTT"

Trees in MongoDB http://www.mongodb.org/display/DOCS/Trees+in+MongoDB

不单是说 mongodb,还说了其他设计思路

有好几种设计模型,各有优点,需要兼顾增删改查不同操作的效率。提供几个关键词供搜索 tree threaded hierarchical 。

另:

  1. reddit 貌似是开源的(记得至少以前的 webpy 版是开源的),可以看看代码,不过是 python 的。
  2. 推荐一种方案,基于 PATH 的。使用一个叫 ancestry 的 gem https://github.com/stefankroes/ancestry 。视频 http://railscasts.com/episodes/262-trees-with-ancestry 。如果深度不那么深,推荐一下。每次增删改,只影响一条记录。 Postgres 有 ltree 模块,与这个设计思路应该是一样的。
  3. MongoDB 可以直接保存嵌套数据。但不能查找某一个评论。

楼主研究透了,可以分享一下哈~

stackoverflow 上的一个总结(好棒的社区哇),不知道复制过来是否合适⋯⋯

What are the Options for Storing Hierarchical Data in a Relational Database?

#2 楼 @caryl nested set 不适合 comments 这种场景,插入代价太高了,每次插入要更新整个表。这种插入多的树结构建议用 ancestry ,不同于 nested set,ancestry 把 ancestors 以 path 的形式保存,比如 comment 3 回复的 comment 2, comment 2 又回复的 comment 1, comment 3 的 ancestry 就是 1/2。ancestry 的大部分查询都只用一次 SQL,虽然 desendents 要用到 LIKE,但是不是以通配符开头,所以可以利用到 index。唯一限制的是 ancestry 最长是 255 个字符

想到的方法是,回复 model 有个 parent_id,父节点如果分页量大可能还要查一次内容,相同数据前端再套一次

谢谢楼上各位的回答,长见识了

可以给每个回复搞个 children_id 。

其实,就一个 parent_id 就好了,查询的时候用 WITH RECURSIVE ,传说还是这样效果最好

#10 楼 @bhuztez 这样用的是 embed 方式吧, 会导致单个文档体积膨胀,慎用

有一个 mongoid-tree, 实现方式楼主可以参考一下 它是用两组外键 一个 parent_id 外加一个 parent_ids,后者用来查询间接先祖和子孙节点 , 配合上 identity map,使用起来效果还行

楼主现在能否回来分享一下你的方案呢?

需要 登录 后方可回复, 如果你还没有账号请 注册新账号