我正在使用Node.JS和Express创建一个社区站点，几乎所有表达教程或示例都使用MongoDB，所以我检查了它。我到目前为止使用的唯一数据库是MySQL，但我对它并不熟悉，因此不会打扰我阅读MongoDB。 Mongo看起来相当不错，文档模型可能是有益的。使用猫鼬它很容易使用。但是我得到了一些问题，所以如果它根本不合适，我不会花很多时间学习使用MongoDB：
我已经读过如果你只在一台机器上使用MongoDB并且可能会遇到数据丢失，那么MongoDB是不可靠的。是对的吗？该项目并不是那么大，我可以负担得起另一台服务器和数据丢失是完全不行！想象一下，一些论坛帖子就消失了。但我想如果发生这种情况，人们就不会使用它。
该网站将包含一个自建论坛，我不确定关系数据库是否会更好。但是，您可以使用嵌入的帖子保存线程，依此类推。但不知道如何搜索，因为Mongo不支持全文搜索。你觉得怎么样？
何时在Mongo中使用嵌入式文档？示例：用户可以在Twitter上发布状态更新。您会在用户文档中保存这些更新吗？可以进行很多更新。或者每次更新一个文档并将其链接到用户ID？ 3.1以及如何跨多个文件查询？您想要获取朋友的最近10个状态更新。你可以用MySQL中的JOIN来做到这一点。
有没有办法为MySQL等文档使用自动增量ID？例如，用户应该有一个唯一的整数键，但我不想像Mongo那样使用一些随机数，以保持用户ID的小。
你如何处理猫鼬的竞争状况？您从db加载文档，编辑并稍后保存。但也许它已经在同一时间发生了变化。
答案 0 :(得分：8)
分别解决每个问题：
不，这不再是真的了。较旧版本的MongoDB没有日记功能，但是当前版本没有日志功能，而且从第2版开始，默认情况下会激活它。但是，您应该在驱动程序级别使用SafeMode，以确保驱动程序和数据库之间的通信成功。
嵌入式帖子和帖子可能不是最佳选择。我们已经构建了类似的东西，我们使用的是一个平面集合，其中每个帖子都存储了ParentId和ParentThreadId。嵌入有利有弊，但我们决定的论点是：
a）通常，我们只想在站点范围内获取最新的评论，或者在给定的线程中获取 n 最近的评论，这两种评论都无法使用嵌入式文档完成。
b）如果你有很多人同时写同一个主题，你需要注意并发性。这可以解决，但我们觉得使用不能真正干扰的不同对象更安全，即使你犯了错误
c）正如Joe指出的那样，你必须在另一个系统中处理全文搜索。
如果您有大量更新，嵌入式文档不太适合，因为容器（包含嵌入对象的集合项）将会增长。当它增长时，MongoDB将不得不重新分配它，这可能需要更长的时间并分割数据。
3（a）中。对于朋友的状态更新，使用扇出策略是有道理的。我answered a similar question yesterday。
请勿使用自动增量编号。默认情况下，这是一个有缺陷的设计，因为它在分布式环境中并不能很好地工作。对于数据库，它是否存储值int的{{1}}或值0x00000001的存储没有区别。保持数字小是没有意义的。我会选择Mongo 0xfa9ac7335或ObjectId / Guid。前者还包含时间戳btw。
我没有使用过mongoose，但总的来说，有悲观和乐观锁定的典型策略。
答案 1 :(得分：4)
默认情况下，MongoDB写入会发生故障，因此如果出现问题，则可能会丢失数据。您可以使用SafeMode，如果写入成功与否，它会给您一个响应，然后以您想要的任何方式处理它。说过我自己没有经历任何丢失的数据。多个服务器将是用于故障转移的复制，如果一个节点发生故障，另一个节点可以自动升级为主节点。
如果您想要全文搜索，那么您无法真正使用Mongo。您可以对帖子中的每个单词进行标记，并将每个单词存储在文档中的嵌入数组中，该文档将被编入索引，您可以查询每个单词。那个问题就是你没有相关性。您可以使用Map Reduce构建一些相关性逻辑，但这会降低查询速度。如果您真的想要快速全文搜索，您应该查看SOLR或弹性搜索。
我个人不会在嵌入式文档中存储状态更新，我会将它们全部放在一个带有用户标识符的单独集合中。 Mongo中没有连接，所以你必须做两个查询，一个用于获取朋友的ID，另一个用于获取状态更新。根据您的集合的大小，使用正确的索引，即使是两个查询，这将非常快。
我认为您不能在Mongo级别使用自动递增整数作为ID。您可以在应用程序中自己处理它，因为您可以使用任何字段作为标识符。添加新文档时，您必须查询集合以获取最高ID并增加它。 Mongo对象ID由机器ID，进程ID，TimeStamp和一些随机性组成，以创建唯一密钥。
我对Mongoose不熟悉。
答案 2 :(得分：2)
以下是NoSQL数据库的比较，显示了它们最适合的优势，劣势和项目类型： http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis