我喜欢文档数据库的想法，尤其是 MongoDB。它允许更快的开发，因为我们不必调整数据库模式。但是 MongoDB 不支持多文档事务，并且不保证修改会像普通数据库一样立即写入磁盘（我知道您可以使刷新之间的时间非常短，但仍然不能保证）。
我们的大多数项目都没有那么大，以至于他们需要多服务器环境之类的东西。所以请记住这一点。是否有任何支持多文档事务和可靠刷新到磁盘的单服务器类似 MongoDB 的文档数据库？
问问题
15755 次
11 回答
10
看看ArangoDB可能是值得的。它是一个多模型数据库，具有用于文档、图形和键值的灵活数据模型。关于您的特定要求，ArangoDB 数据库具有完整的 ACID 事务，可以跨越同一集合中的多个文档以及多个集合（请参阅ArangoDB 中的事务）。也就是说，您可以在一个事务中一起对您的文档执行一组操作，并保证原子性和隔离性。如果您另外设置waitForSync: true
（如所述页面中进一步描述的那样），您可以在事务报告完成之前保证同步到磁盘。请注意，如果您的事务跨越多个集合，则会自动发生这种情况。
于 2013-11-27T13:57:20.933 回答
7
对您的特定（但简短）要求的非常简短的回答：
是否有任何支持多文档事务和可靠刷新到磁盘的单服务器类似 MongoDB 的文档数据库？
所以你可能想知道这 3 种解决方案有什么不同？大多数时候是他们的查询支持（我想说 RethinkDB 有最先进的支持几乎所有类型的查询：子查询、JOIN、聚合等），他们的历史（阅读：生产准备——这里我可能会说 CouchDB 处于领先地位），他们的分发模型（您提到这对您来说并不有趣），他们的许可（RavenDB：商业，CouchDB：Apache License，Rethinkdb：AGPL）。
下一步是让您简要查看他们的功能集并找出哪个更接近您的需求并试一试。
于 2013-02-22T04:33:06.987 回答
4
我对 CouchDB 和 ArangoDB 有一些经验，可以分享：
您可以在启用持久性的情况下运行 CouchDB (delayed_commits = false)，这样它也会将您的数据同步到磁盘。但是，这是一个全局设置，因此它会影响所有写入。AFAIK 您不能在每个集合级别上设置它（“集合”的 CouchDB 术语将是“数据库”）。
关于多文档操作：CouchDB 有 MVCC，因此从同一个数据库中读取多个文档即使面对并行写入者也能提供一致的结果。对于特殊情况，例如在使用批量文档 API 时，也可以将多个文档写入同一个数据库。但是没有办法在 CouchDB 中执行跨数据库操作。这不是故意的。
在 ArangoDB 上：在 ArangoDB 中，您可以在每个集合级别打开立即同步到磁盘：您可以为不能容忍任何数据丢失的集合打开它。您可以为不那么重要的集合关闭立即同步性能原因。然后，它仍会频繁地将修改同步到磁盘，但不会立即同步。它提供多文档和多集合交易。
于 2013-11-27T15:04:37.297 回答
2
我建议你看看 Couchbase。
Couchbase 可以在单个服务器上运行，如果需要，您可以稍后添加节点。
Couchbase 集成了 memcached，因此您可以快速缓存常见数据，并使用可靠的方法将更新写入磁盘。
他们还有一种名为 NQL（“Nickel”）的新查询语言（正在开发中，但您现在可以使用它），如果这对您很重要，它可以为您提供类似 SQL 的访问权限。
通过跨数据中心复制，您可以使不同机器或数据中心上的两个数据库保持同步，这对于进行异地备份很有好处。如果您希望为这些类型的查询提供全文搜索引擎，这也允许您添加弹性搜索。
简而言之，Couchbase 是一个非常完整的解决方案，全部开源并且具有智能（在我看来）架构来解决分布式数据库的典型问题（例如：每个文档都由给定节点“拥有”，因此所有更改都针对该节点节点，然后复制更新，我认为这比说 Riak 更好，你可以将更新转到两个节点，然后必须进行协调。）
您可以在一个节点上使用 Couchbase 为多个项目运行数据库，方法是将项目分成不同的存储桶。
于 2013-11-28T17:20:38.277 回答
1
有这么多的nosql数据库，绝对很难选择一个。您必须提出适当的要求并确切地知道您想要什么。以下链接比较了几乎所有流行的 nosql 数据库 http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
我希望这有帮助。
于 2013-02-19T18:11:58.803 回答
1
Berkeley DB 是我们使用的一种。它支持酸。它确实有交易，但至于您的术语“多文档”是否适用，我不完全确定。我想只要每个数据库（即单个文档）共享相同的 BDB 环境（即存储事务的位置），那么也许就能得到你想要的。BDB 确实有其他权衡。由于具有完全的持久性和高并发性，提交非常慢。
于 2013-06-06T16:19:33.667 回答
1
“OrientDB 具有 Document 数据库的灵活性和 Graph 数据库管理关系的能力。它可以在无模式模式、全模式模式或两者混合模式下工作。支持 ACID 事务、快速索引、本机等高级功能和 SQL 查询。它以 JSON 格式导入和导出文档。OrientDB 使用一种称为 MVRB-Tree 的新索引算法，该算法源自红黑树和 B+Tree，具有以下优点：快速插入和超快速查找”。
于 2013-06-17T08:03:24.890 回答
0
您不必调整文档数据存储中的模式，但这并不意味着您不需要某种模式，因为您可能希望对数据做一些有意义的事情。看来您想要一个 ACID 数据库。如果您有关系数据，并且您需要与该数据进行事务处理，那么听起来很像您需要一个关系数据库。
使用像 Mongo 这样的“NoSQL”数据库，你正在放弃 ACID 来获得许多可写副本、分片和快速访问文档数据等功能。听起来您并没有从中受益，那么为什么要进行权衡呢？很多人最近一直在使用 PostgreSQL 进行混合方法，将文档作为 JSON 块存储在关系表中。有了这个，您可以在不需要的地方将数据存储为非严格结构化的列。
因此，如果您有多个文档需要在更新时进行事务处理，您可以列出键，并有一个列“文档”或其他内容，它只是一个 JSON 数据块，您可以在其中对其进行序列化和反序列化。这并不是批评 Mongo 或其他文档存储作为数据库，但对于事务性多文档数据来说，它并不是一个好的选择。我相信 MarkLogic 也会对多个文档进行 ACID。
我认为很多人因为没有模式而对 mongodb 有吸引力，但我认为最终他们会因为试图将关系模型硬塞到其中而受到影响。因此，与往常一样，数据库的选择取决于您的数据。
于 2013-02-19T16:50:13.320 回答
0
如果我是你，我会仔细看看 Solr。底层数据层 (Lucene) 是迄今为止最成熟的 NoSQL 数据库，Solr 使单主机 lucene 存储的安装、配置和集成变得轻而易举。
在回答您的问题时，它支持用户描述的交易。Lucene 的读取优化特性可能使其不适用于许多应用程序，但其中大多数非常适合 Solr/Lucene+[SQL,Cassandra,CouchDB,RDF]，具体取决于需求。
就我个人而言，我倾向于从 Solr+SQL 或 Solr+RDF 开始，但我认识一些喜欢整个 NodeJS+CouchDB 风格的人，我相信所提供的灵活性的价值。
最重要的是，有足够的 NoSQL 和 SQL 扩展来关心数据完整性，以满足您的任何要求，而不必损害您或您的用户的数据。
于 2013-02-20T01:34:46.877 回答
-2
我个人认为你真的需要检查你的要求是什么。
由于服务器操作系统如何工作的动态性，即使您告诉它，所有东西“立即”都进入磁盘是很复杂的。当然，我知道像 SQL 这样的 ACID 技术很容易因未完成的业务而受到部分损坏，并且当单个服务器出现故障时会在特定窗口内丢失操作，不幸的是，这是使用单个服务器的问题之一；你别无选择，只能接受。
我应该注意，事务并不能确保您的服务器在失败之前会接收到全部数据（http://en.wikipedia.org/wiki/Database_transaction），我的意思是如果服务器在事务中途死亡怎么办？
您可以基于事务的约束执行安全回滚，但很少有数据库会提供继续播放事务的能力，除非它们已经收到所有必要的数据（通常情况并非如此），到那时数据甚至可能无论如何都是陈旧的。
事实上，由于某些事务的权重和在其中执行的查询量，我认为使用事务可能会比在 MongoDB 上的 60 毫秒写入磁盘窗口中获得更大的操作损失窗口。但这当然取决于滥用，但是，就像存储过程一样，这种滥用很常见。
事务在级联删除和典型场景（例如在银行帐户中转账）上大放异彩，但是，级联删除通常最好通过 cronjob 完成（就像大多数站点一样），应用程序将行标记为已删除（以避免显示的事务回滚已删除的数据再次返回给用户）；这样，您可以做很多事情来确保一致性，而在用户使用您的应用程序时您无法实时做到这一点。
所以你真的应该质疑为什么你需要一种技术以及它会成功做什么，atm你的问题的简洁告诉我你完全不确定你的要求。
于 2013-02-19T18:57:11.520 回答