NoSQL中的分布式、容错事务

ゝ一世哀愁。 2022-08-06 11:03 141阅读 0赞

本文来源于我在InfoQ中文站翻译的文章，原文地址是：http://www.infoq.com/cn/news/2015/01/distributed-fault-tolerant-nosql

5年前，术语NoSQL才[刚刚开始出现][Link 1]，那时[很多][Link 2] [NoSQL][] [数据库][Link 3]的版本都还不到1.0，对于[CAP理论][CAP]来说，众多NoSQL数据库都选择了可用性要高于一致性的做法。[ACID][]是一个沉重的负担，而[BASE][]则被认为是未来的发展方向。时至今日，社区已经逐渐成熟起来，一些天花乱坠的宣传也都不见了踪迹，新一轮的NoSQL数据库开始寻求重新定义我们对NoSQL的期待，随之而来的是分布式、容错事务又开始出现在了人们的视野中。

向分布式、容错事务领域的进军起始于2012年秋季，那时Google发布了[Spanner][]数据库。Spanner是个全局分布式、容错、事务型的NoSQL数据库；这一系列属性在之前则被认为是自相矛盾的。不过，Google击碎了人们的这种误解，宣称他们已经在生产环境下使用该数据库一年多时间了。

就在Google宣布Spanner数据库的几个月后，[HyperDex][]团队默默地发布了[Warp][]扩展，它为HyperDex带来了分布式、容错的事务功能。这标志着对这种事务的首个开源实现的发布。趋势开始发生了转移，不过还有很长的路要走。

2013年5月，[Kyle Kingsbury][]在[RICON][]上谈到了[Jepsen][]。在演讲中，Kingsbury披露了各种NoSQL数据库在各种失败情况下的一系列缺陷。甚至诸如[MongoDB][]和[Redis][]（一般情况下人们都认为他们可以保证一致性）这样的数据库都无法信守其承诺。Kingsbury的工作使得社区开始更多地关注于测试与形式化设计，在选择可用性优于一致性时能更好地理解这种折衷。

出于对一致性的密切关注，[FoundationDB][]发布了其键值存储的1.0版，这是第一个拥有分布式、容错事务支持的私有NoSQL数据库。FoundationDB团队深刻理解严格测试的必要性，同时对其测试框架[Lithium][]给予了高度评价，这使得FoundationDB能够确保ACID特性。后来他们又可以通过[Jepsen][Jepsen 1]对FoundationDB进行[测试][Link 4]。

去年又涌现出了两款将支持分布式、容错事务作为设计目标的开源NoSQL数据库。[CockroachDB][]尝试模仿Spanner的地理位置复制事务，它于去年初启动；[Treode][]则在去年6月发布了最初的0.1版。这两个项目都认真地采取了形式化设计，并吸取了很多分布式系统的学术研究成果。

这些事务型数据库已经逐步对NoSQL世界产生了影响，我们看到一致性的NoSQL数据库正在不断改进自己的承诺。比如说，Redis就面临着[持续的压力][Redis]，在构建器分布式功能时要求专注于形式化设计与测试。最近，[Tokutek][]为MonogoDB发布了其新的[Ark][]一致性算法。Ark基于[Raft][]协议，旨在修复MongoDB已知的一致性问题。

虽然现在还是Treode与CockroachDB的早期发展时段，但已经有[不少公司][Link 5]在生产环境中使用了FoundationDB与HyperDex Warp。分布式、容错事务将会扎根于NoSQL，我们将会看到其产生的影响。

**查看英文原文：**[Distributed, Fault Tolerant Transactions in NoSQL][Distributed_ Fault Tolerant Transactions in NoSQL]

[Link 1]: http://www.google.com/trends/explore#q=nosql
[Link 2]: http://basho.com/riak-1-0-is-officially-released/
[NoSQL]: http://www.infoq.com/news/2011/10/Cassandra-1
[Link 3]: http://bradley-holt.com/2010/07/couchdb-1-0-released/
[CAP]: http://en.wikipedia.org/wiki/CAP_theorem
[ACID]: http://en.wikipedia.org/wiki/ACID
[BASE]: http://queue.acm.org/detail.cfm?id=1394128
[Spanner]: http://research.google.com/archive/spanner.html
[HyperDex]: http://hyperdex.org/
[Warp]: http://hyperdex.org/warp/
[Kyle Kingsbury]: https://twitter.com/aphyr
[RICON]: http://ricon.io/archive/2013/east.html
[Jepsen]: https://aphyr.com/tags/jepsen
[MongoDB]: https://aphyr.com/posts/284-call-me-maybe-mongodb
[Redis]: https://aphyr.com/posts/283-call-me-maybe-redis
[FoundationDB]: https://foundationdb.com/
[Lithium]: https://foundationdb.com/key-value-store/white-papers/testing
[Jepsen 1]: http://blog.foundationdb.com/call-me-maybe-foundationdb-vs-jepsen
[Link 4]: http://blog.foundationdb.com/foundationdb-vs-the-new-jepsen-and-why-you-should-care
[CockroachDB]: http://www.infoq.com/news/2014/08/CockroachDB
[Treode]: https://www.treode.com/
[Tokutek]: http://www.tokutek.com/
[Ark]: http://www.infoq.com/news/2014/08/ark-mongodb
[Raft]: https://raftconsensus.github.io/
[Link 5]: https://foundationdb.com/key-value-store/ecosystem
[Distributed_ Fault Tolerant Transactions in NoSQL]: http://www.infoq.com/news/2015/01/distributed-fault-tolerant-nosql