是mongodb适用于像stackoverflow这样的网站吗？
答案 0 :(得分：39)
简单地说：是的，可能是。
让我们分解各种页面/功能，看看它们如何在MongoDB中存储/复制。
此页面中的所有信息都可以存储在集合questions下的单个文档中。这可能包括每个答案的“子文档”，以保持快速检索此页面。
编辑：正如@ beagleguy指出的那样，您可以通过这种方式快速达到4MB的文档大小限制，因此最好将答案存储在单独的文档中并将它们链接起来通过将ObjectID存储在数组中来解决问题。
votes可以存储在一个单独的集合中，其中包含指向问题的简单链接以及投票的user。在添加投票时，可以执行db.eval()调用 来直接在文档中递增/递减投票计数（尽管它会阻止，因此不会非常高效），或者{{ 3}}可以定期调用来抵消那项工作。对于favourites，它可以采用相同的方式。
“查看”号码，记录用户访问时间等内容通常使用MapReduce到modifier operation个计数器来处理。从v1.3开始，有一个新的“查找和修改”命令，它可以在检索文档时发出更新命令，从而为您节省额外的电话。
可以使用increment收集任何类型的统计数据（例如声誉，徽章，唯一标记）并推送到特定的集合。像通知这样的东西可以被推送到另一个充当作业队列的集合中，有许多工作人员正在侦听队列中的新项目（想想徽章通知，自用户上次访问时间以来的新答案等）。
“问题”页面及其过滤器都可以使用上限集合进行处理，而不是立即查询该数据。
最终，YMMV。与所有工具一样，有优势和成本。有一些SO功能需要在RDBMS中进行大量工作，但在Mongo中可以很简单地处理，反之亦然。
我认为Mongo优于RDBMS的主要优点是无模式方法和复制。在基于RDMBS的“实时”应用程序中定期更改架构可能会很痛苦，甚至在大量数据大量使用时也是不可能的 - 这些类型的操作可能会长时间锁定表。在Mongo中，添加新字段非常简单，因为您可能不需要将它们添加到每个文档中。如果您执行相对较快的操作来运行map / reduce来更新文档。
对于复制，Mongo的优势在于不需要暂停DB来为从属设备拍摄快照。如果没有这种方法，许多RDBMS都无法设置复制，在大型数据库上可以将主服务器关闭 long 时间（我正在看着你，MySQL！）。对于StackOverflow类型的站点来说，这可能是一种祝福，您需要随着时间的推移进行扩展 - 每次需要添加节点时都不需要关闭主站。
答案 1 :(得分：5)
我认为是。
您可以将问题本身，答案和对问题+答案的评论存储为一个mongo文档。最大doc大小是4 MB，因此stackoverflow上的文档对于mongo来说不会太大。我已经用bittorrent下载了stackoverflow（数据转储）的内容，我已经能够将这些内容导入到mongo中了。
将此数据导入mongo并非易事，因为stackoverflow的转储由多个xml文件组成，每个xml文件与一个关系表匹配，因此必须将此数据重新组合为文档格式。
我还在本文档中添加了显示名称+ OP + answerers +评论者的声誉。这意味着如果用户更改了他/她的显示名称，则必须使用他/她的用户ID更新所有文档。如果您对数据进行非规范化，则需要付出代价。如果用户的声誉发生变化，则相同。
这个想法是，您在这样的页面上看到的所有数据都包含在一个mongo文档中。您拥有一个查找和没有连接的所有必要信息。
在这里，您可以下载stackoverflow的数据转储：http://blog.stackoverflow.com/category/cc-wiki-dump/
答案 2 :(得分：1)
我会说不，它不是很合适，对象越复杂，对象/文档数据库就越有意义。但是如果你看一下SO，大部分都不是复杂的对象关系。
有一个问题表，但有许多属性，然后是一系列答案......但所有这些都需要根据您来自哪个视图而独立访问，例如：您的活动屏幕或问题/答案屏幕。由于您在很多角度访问它并且每个部分都相对简单，因此关系模型的效果更好。
在后台运行查询以获取徽章等等，您需要快速检查是否要为投票获得声誉上限...鉴于对象模型的复杂性，许多关系查询在RDBMS中更简单
这当然是我的意见，也许SO的结构比看起来更复杂
答案 3 :(得分：1)
使用适用于应用程序的OLTP端的RDBMS和正确的缓存 - 它应该可以正常工作。
实际上 - 有open source stackoverflow clone使用RoR＆amp; MongoDB的。 ：）
答案 4 :(得分：0)
您还可以使用$ inc / $ dec进行投票跟踪，因此无需使用db.eval
答案 5 :(得分：0)
我认为这是一个不错的选择。在与StackOverflow功能类似的站点上使用像MongoDB这样的Nonrel数据库有很多原因。考虑RDBM如何将数据存储到磁盘，并在规划布局时考虑文件系统块大小和类似的磁盘属性。我喜欢利用跨越多个文件系统块的文档，并在其自身内部存储大量相关信息。我发现存储的分散程度较低，可以编写一个包含大量信息的块，其中多个块将使用其他解决方案写入。
答案 6 :(得分：-1)
对我来说，MongoDB非常适合所有不需要交易的网站。