是否有可靠的（单服务器）MongoDB替代方案？

Question

我喜欢文档数据库的想法，尤其是MongoDB。它允许更快的开发，因为我们不必调整数据库模式。但是，MongoDB不支持多文档事务，并且不能保证修改会像普通数据库一样立即写入磁盘（我知道你可以让刷新之间的时间非常小，但仍然无法保证）。

我们的大多数项目都不是那么大，他们需要像多服务器环境这样的东西。所以记住这一点。是否有任何单个服务器类MongoDB文档数据库支持多文档事务和可靠的刷新到磁盘？

Answer 1

看ArangoDB可能是值得的。它是一个多模型数据库，具有文档，图形和键值的灵活数据模型。根据您的具体要求，ArangoDB数据库具有完整的ACID事务，可以跨越同一集合中的多个文档以及多个集合（请参阅Transactions in ArangoDB）。也就是说，您可以在事务中一起对文档执行一组操作，并保证原子性和隔离性。如果您另外设置waitForSync: true （如上所述，您可以在事务报告完成之前获得保证同步到磁盘）。请注意，如果您的事务跨越多个集合，则会自动发生这种情况。

Answer 2

对特定（但简短）要求的简短回答：

  

是否有任何单个服务器类似MongoDB的文档数据库支持多文档事务并可靠地刷新到磁盘？

1. RavenDB [1]支持多文档事务[2]。不幸的是，我不知道它处理耐久性。

2. CouchDB [3]提供持久写入，但没有多文档事务

3. RethinkDB [4]提供持久写入，但没有多文档事务。

所以你可能想知道这三种解决方案有什么不同？大部分时间是他们的查询支持（我说RethinkDB有最先进的一个涵盖几乎所有类型的查询：子查询，JOIN，聚合等），他们的历史（阅读：生产准备 - 在这里我可能会说CouchDB处于领先地位，他们的分销模式（你提到这对你来说并不感兴趣），他们的许可（RavenDB：商业，CouchDB：Apache许可证，Rethinkdb：AGPL）。

下一步是让您简要查看一下他们的功能集，找出哪一个接近您的需求并尝试一下。

Answer 3

我对CouchDB和ArangoDB有一些经验，我可以分享：

您可以在启用持久性的情况下运行CouchDB（delayed_commits = false），这样它也会将您的数据同步到磁盘。 但是，这是一个全局设置，因此它会影响所有写入。 AFAIK你不能在每个集合级别设置它（CouchDB术语“集合”将是“数据库”）。

关于多文档操作：CouchDB具有MVCC，因此即使面对并行编写器，从同一数据库读取多个文档也能提供一致的结果。 将多个文档写入同一数据库也可以对特殊情况进行交易，例如：使用批量文档API时。 但是没有办法在CouchDB中执行跨数据库操作。这不是故意的。

在ArangoDB上：在ArangoDB中，您可以在每个集合级别打开立即同步到磁盘：您可以为不能容忍任何数据丢失的集合打开它。您可以立即关闭同步关闭出于性能原因的重要收藏。然后它仍会经常同步修改磁盘，但不会立即同步。它提供多文档和多收集交易。

Answer 4

检查以下内容：

1. arangodb

2. rethinkdb

Answer 5

我建议你看看Couchbase。

Couchbase可以运行单一服务器＆amp;如果需要，可以稍后添加节点。

Couchbase集成了memcached，因此您可以快速缓存常见数据，并采用可靠的方法将更新写入磁盘。

他们还有一种新的查询语言（在开发中，但你现在可以使用它），称为NQL（“Nickel”），它为你提供类似访问的SQL，如果这对你很重要的话。

通过跨数据中心复制，您可以将不同计算机或数据中心上的两个数据库保持同步，这对于进行异地备份非常有用。如果您希望为这些类型的查询提供全文搜索引擎，还可以添加弹性搜索。

简而言之，Couchbase是一个非常完整的解决方案，所有开源并且具有智能（在我看来）架构，用于解决分布式数据库的典型问题（例如：每个文档都由给定节点“拥有”，因此所有更改转到那个节点，然后复制更新，我认为这比你说可以更新的Riak更好地转到两个节点，然后必须进行协调。）

您可以在一个节点上使用Couchbase，通过将项目分成不同的存储桶来为许多项目运行数据库。

Answer 6

有这么多的nosql数据库，绝对很难选择一个。您必须提出适当的要求并确切地知道您想要什么。 以下链接比较了几乎所有流行的nosql数据库 http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

我希望这会有所帮助。

Answer 7

Berkeley DB是我们使用的。它支持ACID。它确实有交易，但对于你的术语“多文档”适用，我不完全确定。我想只要每个数据库（即单个文档）共享相同的BDB环境（即存储事务的地方），那么可能会得到你想要的。 BDB确实有其他权衡。具有完全持久性和高并发性，提交非常缓慢。

Answer 8

尝试：http://www.orientdb.org/

“OrientDB具有Document数据库的灵活性和Graph数据库管理关系的强大功能。它可以在无模式模式，模式完整或两者兼而有之。支持ACID等高级功能事务，快速索引，本机和SQL查询。它使用JSON导入和导出文档.OrientDB使用一种新的索引算法MVRB-Tree，它来自红黑树和B +树，同时具有以下优点：快速插入和超快速查找“。

Answer 9

您不必调整文档数据存储中的模式，但这并不意味着您不需要某种模式，因为您可能希望对数据执行一些有意义的操作。看来你想要一个ACID数据库。如果你有关系数据，并且你需要与这些数据进行交易，那么听起来就像你需要一个关系数据库。

对于像Mongo这样的“NoSQL”数据库，您放弃了ACID的功能，例如许多可写副本，分片和快速访问文档数据。听起来你没有从中受益，那么为什么要进行权衡呢？最近很多人一直在使用PostgreSQL进行混合方法，将文档作为JSON blob存储在关系表中。有了这个，您可以将数据存储为不需要的严格结构化列。

因此，如果您有多个文档需要在更新时进行事务处理，则可以列出键，并使用列“文档”或其中只是一个JSON blob，您可以对其进行序列化和反序列化。这并不是批评Mongo或其他文档存储作为数据库，但它对于事务性多文档数据来说并不是一个好的选择。 MarkLogic我认为ACID也可以在多个文档上进行。

我认为很多人都会因为模式较少而找到mongodb的吸引力，但我认为最终他们会试图将关系模型强加给它。因此，数据库选择一直取决于数据的来源。

Answer 10

如果我是你，我会仔细看看Solr。底层数据层（Lucene）是目前最成熟的NoSQL数据库，Solr使得单主机lucene存储的安装，配置和集成变得微不足道。

在回答您的问题时，它支持用户描述的交易。 Lucene的读取优化特性使其不适合许多应用程序，但大多数应用程序非常适合Solr / Lucene + [SQL，Cassandra，CouchDB，RDF]，具体取决于要求。

就我个人而言，我倾向于从Solr + SQL或Solr + RDF开始，但我知道有些人喜欢整个NodeJS + CouchDB风格，我相信它提供的灵活性的价值。

最重要的是，有足够的NoSQL和SQL扩展，关注数据完整性，以满足您的任何要求，而不必损害您或您的用户数据。

Answer 11

我个人认为你真的需要检查你的要求是什么。

由于服务器操作系统工作原理的动态变化，即使你告诉它，所有内容都“立即”进入磁盘也很复杂。当然，我知道像SQL这样的ACID技术很容易因未完成的业务部分损坏而在单个服务器出现故障时在特定窗口内丢失操作，不幸的是这是使用单个服务器的问题之一;你别无选择，只能接受它。

我应该注意，事务并不能确保您的服务器在失败之前会收到整个数据（http://en.wikipedia.org/wiki/Database_transaction），我的意思是如果服务器在事务中途中断了怎么办？

您可以根据事务约束执行安全回滚，但很少有数据库能够继续播放事务，除非他们已经收到了所有必需的数据（通常不是这种情况），到时为止无论如何，数据甚至可能都是陈旧的。

事实上，由于某些事务的权重以及在其中执行的查询量，我认为使用事务可能会比使用MongoDB上的60ms写入磁盘窗口获得更大的操作丢失窗口。但当然这取决于滥用，但是，就像存储过程一样，这种滥用是常见的。

事务发生在级联删除和典型情况下，例如在银行帐户中转移资金，但是，可级联删除通常由cronjob更好地完成（如大多数网站所做），应用程序将该行标记为已删除（以避免回滚将删除的数据再次显示给用户的交易）;通过这种方式，您可以执行大量操作以确保在用户使用应用程序时无法实现的一致性。

因此，您应该真正质疑为什么需要技术以及它将成功做什么，因为您的问题的简洁性告诉我您不完全确定您的要求。