我喜欢文档数据库的想法，特别是MongoDB。它允许更快的开发，因为我们不必调整数据库模式。然而，MongoDB不支持多文档事务，并且不能保证修改能够像普通数据库一样立即写入磁盘（我知道你可以使两次刷新之间的时间相当短，但仍然无法保证）。是否有可靠的（单服务器）MongoDB替代方案？
我们的大部分项目都不是那么大，他们需要像多服务器环境这样的东西。所以记住这一点。是否有任何支持多文档交易和可靠刷新到磁盘的单服务器MongoDB类文档数据库？
一个非常简短的回答您的具体（但短暂的）要求：
是否有支持多文档交易和可靠的冲洗到磁盘上任何一台服务器的MongoDB类的文档数据库？
所以你可能想知道这三种解决方案有什么不同？大部分时间是他们的查询支持（我认为RethinkDB具有最先进的功能，涵盖几乎所有类型的查询：子查询，JOIN，聚合等），他们的历史（阅读：生产准备 - 在这里我可能会说CouchDB处于领先地位），他们的分布模型（你提到的对你来说并不感兴趣），他们的许可（RavenDB：商业，CouchDB：Apache许可，Rethinkdb：AGPL）。
下一步应该是让您简要了解他们的功能集并找出哪一个接近您的需求并尝试一下。
最终一贯的技术如couchdb不提供持久的写入，它在事实上打破了耐久性。除非他们有确保立即写入磁盘和立即复制的方法 – Sammaye 2013-02-22 10:03:24
@Sammaye CouchDB是一个单一的服务器数据库。它允许你设置主 - 主复制，但这是一个不同的故事。在确认操作之前，CouchDB写入磁盘。最终一致性与耐久性本身几乎没有关系：基本上同步复制的数据库可能不耐用。 – 2013-02-22 20:07:42
奇怪我读了这个页面：http：//guide.couchdb.org/draft/performance.html，它说：...“缓冲区在将数据提交到磁盘之前将数据存储在内存中，以确保更高的数据吞吐量。 （硬件或软件）的电力损失或崩溃，数据就消失了。“...上次我检查立即复制是单服务器设置之外的真正耐久性的要求，我也不确定你的人它是一个单一的服务器数据库，我相当肯定couchdb可以设置在一个集群中：http://guide.couchdb.org/draft/clustering.html – Sammaye 2013-02-22 20:21:33
您不必调整文档数据存储中的模式，但这并不意味着您不需要某种模式，因为您可能想对数据做一些有意义的事情。看起来你想要一个ACID数据库。如果您有关系数据，并且您需要与该数据进行交易，那么听起来非常像您需要关系数据库。
对于像Mongo这样的“NoSQL”数据库，您放弃了许多可写副本，分片和快速访问文档数据等功能的ACID。听起来你没有从中受益，所以为什么要权衡？通过将关系表中的文档存储为JSON斑点，许多人最近一直在使用PostgreSQL来进行混合方法。有了这个，您可以将数据存储为不需要严格构造的列。
因此，如果您有多个需要在更新时进行事务处理的文档，您可以列出关键字，并且有一个“文档”列或其中只是一串JSON的序列化和反序列化。这不是批评Mongo或其他文档商店作为数据库，但它不是一个真正的交易型多文档数据的好选择。 MarkLogic我相信也可以处理多个文档的ACID。
我认为很多人会因为模式不足而发现mongodb的吸引力，但我认为最终他们会试图通过尝试将关系模型强加给它。所以数据库的选择取决于你的数据是如何。
有这么多的nosql数据库，肯定很难选择一个。你将不得不提出适当的要求，并确切知道你想要什么。 继环比几乎所有流行的NoSQL数据库 http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
我希望这有助于。
我个人认为你确实需要检查你的要求是什么。
由于您的服务器的操作系统工作原理的动态性，即使您告诉它，即使“立即”立即执行，也很复杂。当然，我知道像SQL这样的ACID技术人员容易受到未完成业务的部分腐败和单个服务器宕机时在特定窗口内丢失操作的影响，不幸的是，这是使用单个服务器的问题之一;你别无选择，只能接受它。
我应该注意到事务不能确保你的服务器在失败前会收到全部数据（http://en.wikipedia.org/wiki/Database_transaction），我的意思是如果服务器在事务中中途中断？
您可以基于事务约束执行安全回滚，但很少数据库将提供继续播放事务的能力，除非他们已经收到了所有必要的数据（通常不是这种情况），到那个时候无论如何，数据甚至可能是陈旧的。
实际上，由于某些事务的重要性以及在它们中执行的查询量，我认为您可能会使用事务处理的操作丢失的窗口超过您在MongoDB上有时从磁盘窗口执行60ms的操作。但是，当然这取决于滥用，但是，就像存储过程一样，这种滥用是常见的地方。
在级联删除和像银行账户中转移货币这样的典型场景上发光，但是，级联删除通常会更好地完成（如大多数站点所做的那样），通过cronjob将应用程序标记为已删除的行（以避免回滚交易显示删除的数据再次返回给用户）;这样你可以做很多事情来确保用户在使用应用程序时不能实时执行的一致性。
所以你应该真的质疑为什么你需要一种技术，它会成功做什么，atm你的问题的简洁告诉我你完全不知道你的需求。
崩溃的MongoDB实例可能会导致数据库中的数据损坏（因为要执行的操作中有一半是执行的，因为它不支持多文档事务）。据我所知，这是PostgreSQL不可能的。这是我们需要的。 – Tim 2013-02-19 19:19:54
@Tim如果您希望自己的速度爬到不会超越小型站点的地步，那么这是不可能的，交易只能真正用于重要的关键任务程序。 – Sammaye 2013-02-19 19:42:39
@Tim基本上，如果你使用除交易以外的任何东西，并且有人告诉你你不能腐败，那么这个数据库可能会违反计算规律。即使使用交易，交易也可能被损坏的机会很小 – Sammaye 2013-02-19 19:45:08
如果我是你，我会仔细看看Solr。底层数据层（Lucene）是迄今为止最成熟的NoSQL数据库，Solr可以安装，配置和集成单主机lucene存储。
在回答您的问题时，它支持用户划定的交易。 Lucene的读取优化特性可能使其不适用于许多应用程序，但其中大多数非常适合Solr/Lucene + [SQL，Cassandra，CouchDB，RDF]，具体取决于要求。我个人倾向于从Solr + SQL或Solr + RDF开始，但我知道一些热爱整个NodeJS + CouchDB风格的人，并且我确信提供的灵活性的价值。
底线是，有足够的NoSQL和SQL扩展，关心数据完整性以满足您的任何需求，而无需泄露您或用户的数据。
几年前我使用solr时，它不适合这种用途。它在高承诺量下崩溃，提交缓慢。近期有关NRT的一些工作，但仍有一段路要走。看到这里列出的警告：http://wiki.apache.org/solr/NearRealtimeSearch – 2013-02-20 01:41:00
@FrankFarmer不幸的是，提问者没有提供他们使系统的'使用'的细节。我只能假设你的情况是高容量小写。我在低容量大写/大容量大读项目上运行Lucene，完全没有任何不稳定问题，并且没有发现比Lucene更好的用途。具有一小组hv-sw数据和大量lv-lw数据的应用程序类别非常重要，Solr +？是一个很好的候选人。 – Recurse 2013-02-20 02:37:14
伯克利DB是我们用过的。它支持ACID。它确实有交易，但对于您的术语“多文档”适用，我不完全确定。我想象，只要每个数据库（即单个文档）共享相同的BDB环境（即存储事务的地方），那么可能会得到你想要的。尽管BDB确实有其他的折衷。凭借完全的持久性和高并发性，提交非常缓慢。
给一个尝试：http://www.orientdb.org/
“OrientDB具有文档数据库的灵活性和图形数据库的权力来管理关系，可以在无模式的模式，架构完整或混合使用。支持ACID Transactions，Fast Indexes，Native和SQL查询等高级功能，它使用JSON导入和导出文档，OrientDB使用一种新的索引算法MVRB-Tree，该算法派生自红黑树和B +有两种好处的树：快速插入和超快速查找“。
这可能是值得看ArangoDB。它是一个多模型数据库，具有灵活的文档，图形和键值数据模型。根据您的具体要求，ArangoDB数据库具有完整的ACID交易，可跨越同一集合中的多个文档以及多个集合（请参阅Transactions in ArangoDB）。也就是说，您可以在事务中一起对您的文档执行一组操作，并保证原子性和隔离性。如果您另外设置了waitForSync: true （如所述页面的下面所述），则在事务处理报告完成之前，您会保证与磁盘同步。请注意，如果您的交易跨多个集合，则会自动发生。
我使用CouchDB和ArangoDB一些经验，我可以分享：
可以与耐久性运行的CouchDB开启（DELAYED_COMMITS = FALSE），所以它也将同步你的数据到硬盘。 但是，这是一个全局设置，因此会影响所有写入。 AFAIK不能在每个集合级别上设置它（CouchDB的“集合”术语将是“数据库”）。
关于多文档操作：CouchDB具有MVCC，因此即使面对并行编写器，从同一数据库读取多个文档也能提供一致的结果。将多个文档写入同一数据库也可以针对特殊情况进行交易，例如，当使用批量文档API时。 但是没有办法在CouchDB中执行跨数据库操作。这只是没有打算。
在ArangoDB上：在ArangoDB中，您可以在每个集合级别打开立即同步到磁盘：您可以将其打开用于无法容忍任何数据丢失的集合。您可以立即关闭不需要的同步出于性能原因的重要收藏。然后，它会频繁地将修改同步到磁盘，但不会立即。它提供了多文档和多集合交易。
我建议你看看Couchbase。
Couchbase可以运行单个服务器&如果需要，您可以稍后添加节点。
Couchbase具有集成的memcached，因此您可以快速缓存常用数据，并具有将更新写入磁盘的可靠方法。
他们也有一种叫做NQL（“镍”）的新查询语言（在开发中，但你可以使用它），如果这对你很重要，它可以为你提供SQL访问权限。
使用跨数据中心复制，可以使不同机器或数据中心上的两个数据库同步，这对于进行非现场备份很有用。如果您希望针对这些类型的查询拥有全文搜索引擎，还可以添加弹性搜索。简而言之，Couchbase是一个非常完整的解决方案，所有开源代码都具有智能（在我看来）架构，用于解决分布式数据库的典型问题（例如：每个文档由给定节点“拥有”，因此所有更改到那个节点，然后更新被复制，我认为比Riak更好，在那里你可以让更新进入两个节点，然后必须协调。）
你可以在一个上使用Couchbase节点通过将项目分成不同的桶来运行许多项目的数据库。
你是什么意思，“像正常数据库一样立即写入磁盘”？高性能数据库通常使用日志（或预写日志）在批处理写入操作时最大化写入一致性。 MongoDB具有[this]（http://docs.mongodb.org/manual/administration/journaling/），强烈推荐（并且在64位2.0+中默认）。尽管MongoDB没有立即/强制写入日志的选项（有些DB）。对于MongoDB - 它可以在2-300ms内配置。 – WiredPrairie 2013-02-19 16:48:49
这就是我的意思。有了像PostgreSQL这样的数据库，如果我向数据库写入数据并且事务成功了，那么如果机器出现故障，我确信数据将在那里。 MongoDB通过日志来接近这一点。但正如你注意到它不保证它。 – Tim 2013-02-19 16:56:35
是的，这是ACID中的'D'。 – 2013-02-19 17:03:02