【问题标题】:comment system rdbms vs nosql评论系统 rdbms vs nosql
【发布时间】:2013-05-04 10:25:32
【问题描述】:

实现评论系统(大量数据写入)的最佳方式是什么?

1) 使用 RDBMS 数据库,例如 MySQL,2 个表,一个用于主题,一个用于 cmets 优点是新评论的插入是快速、高效和简单、高效的索引。 缺点是横向扩展(水平缩放)很难。

2) 使用nosql数据库如couchdb或mongodb,优点是容易横向扩展(横向扩展),支持大数据写入,无模式缺点 我认为新数据的插入不如RDBMS快速高效

例如更新couchdb文档需要抓取整个文档,在本地更新后再提交,文档会很大,会占用带宽。

另外我认为 couchdb 就地更新,Mongodb 更新会很慢并且不会像在 RDBMS 中那样高效

此外,当您想获取每个用户在各种主题中的 cmets 时,我认为在 RDBMS 中搜索会比在 nosql 系统中更快。

这是一个couchdb数据库文档的样本[每个主题的文档样本]

{"_id":"doc id",
 "_rev":"45521231465421"
 "topic_title":"the title of the topic"
 "topic_body":"the body of the topic"
 "comments":[
           {"date":"mm/dd/yy hh:mm:ss"}, {"commment":"bla1"}, {"user":"user1"}
           {"date":"mm/dd/yy hh:mm:ss"}, {"commment":"bla2"}, {"user":"user2"}
           {"date":"mm/dd/yy hh:mm:ss"}, {"commment":"bla3"}, {"user":"user3"}
           {"date":"mm/dd/yy hh:mm:ss"}, {"commment":"bla4"}, {"user":"user4"}
           {"date":"mm/dd/yy hh:mm:ss"}, {"commment":"bla5"}, {"user":"user5"}
           {"date":"mm/dd/yy hh:mm:ss"}, {"commment":"bla6"}, {"user":"user6"}
            ]
}

【问题讨论】:

  • 为什么您认为 CouchDB 或 MongoDB 在插入数据时速度较慢?您是用自己的基准验证了这一点,还是只是在听自己的直觉?
  • 要对couchdb文档添加评论,您需要抓取整个文档,在本地更新并再次提交,并且文档会很大,因此会占用带宽。所以它会“更慢”
  • 为什么要将 cmets 嵌入到博客文章中?您是否期望在显示博客文章时还需要显示其所有 cmets?为什么您认为 RDBM 中的搜索会比 MongoDB 更快?它们都使用索引,都将索引结构作为 B 树。您为什么不实际针对您期望使用的数据对测试进行基准测试?

标签: mongodb rdbms nosql


【解决方案1】:

我认为新数据的插入不如RDBMS快速高效

你在那里碰到了什么东西。 NoSQL 数据库的插入速度取决于您的场景。我不能说的足够清楚,很多人都希望 MongoDB 的执行速度比 SQL 快得多,但当它不适合他们时,他们会感到非常失望,事实上,在此之前,mongodb-user 谷歌组已经充满了这样的人。

例如更新couchdb

不仅如此,CouchDB 还使用版本控制和 JSON,其效率不如将其存储在 SQL 中,并且每条记录会消耗更多空间。

Mongodb 更新会很慢并且不会像在 RDBMS 中那样高效

架构、查询、架构、查询...

归根结底就是这样。问自己一个问题。

我会期待每个帖子有很多 cmets 吗?

如果是这样,内存中(是的,内存中)$push$pull 和其他子文档运算符可能会在大型子文档上变慢(老实说,会的)。

不仅如此,持续增长的文档也可能成为一个问题,并可能导致大量碎片和空间占用,从而产生“瑞士奶酪”效应,大大降低系统速度(使其停止运转)。此演示文稿应该有助于更多地了解存储的实际工作原理:http://www.10gen.com/presentations/storage-engine-internals

所以您已经知道,如果使用不当,子文档可能是个坏主意。话虽如此,您可以通过分配 2 种尺寸的能力来部分解决它:http://docs.mongodb.org/manual/reference/command/collMod/#usePowerOf2Sizes,但如果您插入的评论太多,那么它不会有太大帮助。

我个人不会嵌入这种关系。

所以我会采用与 RDBMS 相同的设置,现在您开始看到问题所在。如果不是 MongoDB 的 fsync 队列,插入的速度可能大致相同,这与直接写入磁盘的 SQL 不同。您可以使用日志写入设置 MongoDB,但最终您可能会从 SQL 获得相同的性能指标。

至于查询,这是 MongoDB 仍然可以脱颖而出的地方,提供 您的工作集适合 RAM。最后一点我不能大胆!

与 SQL 不同,MongoDB 将所有内容(您的整个数据)映射到虚拟内存,而不是 RAM,而且绝对不要与 RAM 混淆。这确实使较大的查找速度更快,对于较小的查找速度将大致相同,因为两者都将从内存缓存中提供服务。

此外,当您想获取各个主题中每个用户的 cmets 时,我认为在 RDBMS 中搜索会比在 nosql 系统中更快。

如果主题 ID 在评论文档中,那么在 MongoDB 中肯定会更快,前提是您的工作集已在 RAM 中准备就绪。

工作集是什么意思?这是一个很好的答案:What does it mean to fit "working set" into RAM for MongoDB?

希望这会有所帮助,

【讨论】:

  • 嗯,有人对我的回答投了反对票,不知道他们有没有解释??
【解决方案2】:

我只能谈论 MongoDB,而您对插入的看法确实是错误的。 Here 是 Mongo 与 MSSQL 的一个很好的比较,Mongo 的性能是 MSSQL 的 100 倍。所以非常适合大数据处理。

搜索也更快(如果插入和搜索不会更快,那么 NoSQL 的全部意义是什么?) - 但需要注意的是,您不能在查询中执行连接,您必须手动连接表在您的应用程序中(但有推荐的解决方法 - nested documents)

【讨论】:

  • 我会非常担心依赖这样的图表然后说 MongoDB 更快是“事实”,即他只在那里使用嵌入式模式并且嵌入并不总是一个好主意,其实应该慎重考虑...
  • 我并不是说嵌入总是一个好主意,但在某些(也许是大多数?)情况下它是可以接受的。如果没有,您仍然可以手动加入,尽管这很痛苦(但这就是拥有 NoSQL DB 的代价)。但是 OP 询问了评论系统,所以在这种情况下嵌入对我来说似乎很好。
  • 这取决于查询和 cmets,但是是的,假设嵌入似乎没问题
猜你喜欢
  • 1970-01-01
  • 2011-08-16
  • 2018-05-24
  • 1970-01-01
  • 2011-08-06
  • 2013-10-28
  • 2011-07-09
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多