MongoDB vs SQL Server用于存储递归的数据树

时间:2012-02-11 17:05:31

标签: sql-server mongodb performance nosql

我目前正在推出一个存储线程评论树的项目。

对于那些不熟悉我所说的内容的人我会解释,基本上每个评论都有父评论,而不仅仅是属于一个帖子。目前,我正在研究存储这些数据的关系SQL Server模型,因为它是我习惯的。它看起来像这样:

Id int  --PK
ThreadId int  --FK
UserId int  --FK
ParentCommentId int  --FK (relates back to Id)
Comment nvarchar(max)
Time datetime

我所做的是选择ThreadId的所有注释,然后在代码中,递归地构建我的对象树。我也正在加入以获得用户名这样的内容。

在我看来,像MongoDB这样的文档存储器NoSql可能是这类模型的更好选择。但我对此一无所知。

  • 如果我选择MongoDB会有什么陷阱?
  • 如果我将它作为文档存储在MongoDB中,我是否必须在每条注释中包含用户名,以防止自己不得不按键提取每个用户记录,因为它不是“关系”?
  • 当您使用MongoDB时,是否必须积极地在您需要的对象上缓存“相关”数据?

编辑:我确实找到了this arcticle关于在MongoDB中存储信息树的信息。鉴于我的一个要求是能够向登录用户列出他最近的评论列表,我现在非常倾向于使用SQL Server,因为我认为我不会做任何聪明的事情使用MongoDB可以带来真正的性能优势。但我可能是错的。我真的希望有关此事的专家(或两位)能够提供更多信息。

1 个答案:

答案 0 :(得分:2)

在Mongo(和其他文档数据库)中存储分层数据的主要优点是能够以多种方式存储数据的多个副本,从而使查询对不同的用例更有效。在您的情况下,如果将整个线程存储为分层嵌套文档,则检索整个线程会非常快,但您可能还希望将每个注释存储为非嵌套或可能存储在用户记录下的数组中以满足您的需求第二要求。由于任意嵌套,我不认为Mongo能够通过用户ID有效地索引您的层次结构。

与所有NoSQL商店一样,通过扩展到大量数据节点可以获得更多好处,允许许多同时读者和作者。

希望有所帮助