译者注：原文题为 a comparison of advanced modern cloud database. 个人因兴趣翻译，欢迎批评指正！
【译文】
本文是一篇面向Aurora、Cosmos、Spanner 的现代云数据库解决方案导引。
最近这些年，涌现出一些让人印象深刻的云计算技术，范围涉及拓展传统数据库的可扩展性（Aurora），到利用定制硬件实现创新设计以获取足够的规模（Spanner）。伴随着数据无止尽的增长，很多组织面临新的问题，我们现在所使用的工具并没有同比升级。
普通用户很难跟踪新工具的发展，也很难准确区分他们之间的差异，所以我尝试汇总这些不同产品，并对比他们之间的差异。
不太可能简单评价哪个是最好的选择，有很多因素需要权衡，不同组织要基于自己面临的问题来选择合适的技术。虽然下面对比表中的很多特性的选择是基于它们对于帮助构建简装软件的重要性，但不得不承认仍会有一些偏见在里面。当然选择哪些技术来对比本身也是一定的偏见。可以有很多选项，我没有选择大部分；这个列表仅聚焦在那些最常见的目标、最实用性和最有趣的方面。
我把一些收藏的观点放在文尾部分。
对比表
各列含义说明
* 并发 ACID：数据库是否支持 ACID（原子性，一致性，隔离性，持久性）影响涉及很多操作。ACID 是保证系统正确性的强有力的工具，直到最近它已经是分布式数据库长期追求但迷惑的幻想。我使用并发 ACID 这个词是因为技术上 Cosmos 保证 ACID，但只能限制在单一操作中。
* HA：数据库是否是高可用（HA）。虽然在列表我将每个数据库都标记为支持 HA，但一些比其他产品更高可用，CockroachDB、Cosmos、Spanner 在这方面处于领先地位。其他则倾向于依赖单一节点的故障转移技术。
* 水平扩展：数据库是否可以通过增加节点实现水平扩展。表中除了 Postgres 外都支持，但我包含该列是为了突显一个事实，不像其他产品，Aurora 的扩展性仅是磁盘。这并不是说它不适合使用，只是一些提醒（见 Amazon Aurora 的下面细节说明）。
* 自动数据分片：区分数据库数据分片、负载是手工处理还是由数据库自动完成。以一个手工的数据库为例，在 CitusDB 或 MongoDB 你需要明确的告诉数据库，你想要一个表是分布式的，基于什么主键来进行分片（例如user_id)。相对而言，Spanner自动算出如何去分布存储的数据到有效的节点，以及必要的重新均衡。这两种选择都是可行的，但手工分布需要更多的操作成本，如果没有足够的看护，会导致不均衡的分片，尤其是大节点过度的负载运行。
* 低延迟：在要求很低的延迟操作（小于1ms）的情景下，CockroachDB、Cosmos 利用额外的内部节点的协调来保证满足不合适的成本。我在基于时间的一致性中会就此更多细节说明。
附加的考虑因素
CAP
CAP 定理指出：给定的一致性，100%可用性和分区容忍性，任何数据库最多可以满足三个中的两个。
为了说明为什么CAP没有包含在上面的表中，我会引用Eric Brewer（谷歌 基础设施VP）关于 Spanner 的论述。
尽管作为一款全球分布的系统，Spanner 宣称一致性和高可用，这暗示无分区，因此存疑。这表示 Spanner 是一个 CA 系统（依据 CAP 的定义）？简单的回答式技术性的“不”，但在效果上“是”。它的用户可以假定 CA。
纯粹主义的回答式“不”，因为分区可以做，事实谷歌也是这么做，在一些分区Spanner 选择 C，损失 A。它可以技术的定义为 CP 系统。我们将在下面探讨分区的影响。
假定 Spanner 总是提供一致性，声明CA 的真正问题 Spanner严谨的用户是否会假设它的可用性。如果它实际可用性很高以致于用户可以忽略运行中断，这样 Spanner 可改为支持有效的 CA。这不是暗示100%的可用性（而且 Spanner 现在不会将来也不会提供它），而是5个9或更高（10的5次方会有1次或更少的失败）。反过来，实际更简单有效的方法是用户是否写代码来处理中断异常（如果他们需要自己的服务高可用）：如果他们没有写这样的代码，他们实际是假定高可用。由于已有大批使用的Spanner的内部用户，我们知道他们是认为 Spanner 是高可用的。
换句话说，现代技术可以实现 CP，而且它可以保持非常好的可用性，如像5个9以上的好。这结果是如此理想，以致于现代的数据库似乎都聚焦在此。列表中的每个数据库都是支持CP，但在 A 上有不同级别的支持。
基于时间的一致性
像 Spanner 和CockroachDB这样的复杂的分布式系统都倾向于需要多一点时间去协调和核实任意给定节点返回结果的准确性。这使得对低延迟操作的符合度降低。
Quizlet 建议， Spanner 操作的最小延迟为小于5ms。Spanner 论文在章节4.1和4.2中，描述不同操作的协调细节。CockroachDB 在他们的 FAQ 中明确表示，它不适合用于对低延迟读写要求极其严格的场景。
微软 Cosmos 的设计没有公开，但它的文档表明相似的性能特征，读写耗时的中位数是5ms。
竞争者
Amazon Aurora
Aurora是一款托管的关系数据库，拥有与 MySQL 和 Postgres 兼容的SQL接口。它其中一个最大的卖点是性能。它宣称在相同硬件环境下，可以提供5倍于 MySQL和2倍于 Postgres 的吞吐量。
Aurora与列表中的其他产品有很大的不同，因为它在节点层面不能水平扩展，它的集群更类似于传统关系数据库的一主（读写）多从（读）。代替的是，亚马逊设计了存储层扩展方案，允许表在尺寸上显著的增长，这要比你见过的传统关系数据库要大的，最多可达到单表64TB。
这种基于存储的扩展有它的不足，计算和内存资源（用于写和一致性读）被限制在单一垂直扩展的节点，但它同样也有很明显的优势：数据存在一个位置上，所以延时很低。它也意味着，你不会弄错分区模式，进而导致一些分片过热，需要重新均衡负载（这种现象很容易发生，但很难解决）。相比 CockroachDB、Spanner，如果用户需要大量的扩展，但有不需要无限扩展时，它可能是个合适的选择。
CitusDB
CitusDB 是一款基于 Postgres 的分布式数据库，允许单个表分片和分布到任意数量上的节点上。它提供聪明的观念，如引用表可以保证数据局部性以提升查询效率。ACID 的保证是在特定的节点范围内的，这个节点通常够用的，因为分片设计保证数据都在该节点上。
最值得说明的是， CitusDB 是开源的，使用 Postgres 扩展 API 来运行。这减少了锁定的风险，这是列表中其他选项最需要考虑的负面因素。相比于 Aurora，它意味着你更可能在你的数据库中看到新版 Postgres 的新特性。
相比 CockroachDB 而言，它的不好的一点是，它的数据需要手工分片的，正如上面提到的，这会导致负载问题。另一个考虑的因素是，它由一个新公司发布，这个公司的商业模式也未得到证明。通常选择一款数据库，冷静的头脑需要知道，你所用的东西在未来十年内一定要被很好的维护管理的。当产品是由大型公司研制的，你可能会很自信，如亚马逊、谷歌、微软，但如果小公司，你的信心会少。
CockroachDB
CockroachDB是由Cockroch实验室发布的产品，该公司由前谷歌员工创立，他最有影响力的是他创建了谷歌文件系统（GFS）和谷歌阅读器（Google Reader）。它基于已经公布的最初的Spanner 论文设计的，像 Spanner 一样，使用基于时间的机制来实现一致性，但没有谷歌 GPS 和原子时钟的支持。
它提供可序列化的分布式事务，外键和辅助索引。它开源，并用 Go 开发，后者使得在开发环境中易安装、易运行。它们的文档写的很清晰，易于阅读，坦率。如以它们已知的限制为例。
像 Spanner，附加的保持分布式一致性意味着，当需要低延时操作时，它是不好的选择（他们自己也承认）。像 上面的 CitusDB，由商业模式未知的小公司发布也是一个负面因素。
微软Cosmos
Cosmos是微软全新的云数据库。它的销售势头很强劲。例如，这有一段关于他们无预定结构的设计的摘录，所宣传的是著名的权衡或更少，一个反特色：
关系数据库和 no-sql 数据库都强迫你去处理模式和索引的管理、版本管理、迁移[……]但不用担心，Cosmos DB让这些问题走开。
这说明，它拥有一组很好的特点。
* 快速且容易的跨区域分布。
* 可配置的一致性模型，包括从强一致性到最终一致性（为速度牺牲读取顺序错乱的可能）。
* 操作 SLA时间保证，99%的情况下，读小于10ms，索引写小于15ms。
像 CockroachDB 和 Spanner 一样，Cosmos 的分布式架构使得它不是很适应用于低延迟要求的应用。它们的文档表示读写延迟的中位数是5ms。
Cosmos 凭借基于 JavaScript 的存储过程的使用，可以提供 ACID。这似乎是依靠只有一个 JavaScript 运行时运行在主节点，所以一个时间只有一个脚本被处理，但它也同事记录一些记录，以保证任意的写可以被还原，因此确保真正的原子性（不像Redis 的 EVAL）。尽管如此，这种方法也没有像 MVCC 引擎那样复杂（后者则被应用在列表中的其他数据库中），因为它不能提供并发使用。
MongoDB
MongoDB 是一款 NoSQL 数据存储，它以无模式JSON 文档方式存储数据。它不支持 ACID 事务，如果这够用，关于它2009的发行版，有大量关于核心竞争力的合理批评，包括持久性、安全性、正确性。
为了对比，我已经将其包括在内，因为它仍然还有很多值得关注点，但就复杂度而言，它和列表上的其他系统已经不在一个级别上了。其他的大部分有严格的功能超集，但也支持其他极其重要的特色，如 ACID 的保证。新项目不应该基于 MongoDB 开展，而老系统应该考虑从它迁移走。
Postgres
Postgres是一款值得信赖的传统关系数据库。内置不支持 HA，但借助亚马逊 RDS、Heroku Postgres或 Azure Database 来实现（谷歌运 SQL 也很快支持）。
即使它不如列表中其他产品完美，我仍然将它包含在内，因为它仍然是很多使用场景的最佳选择。大部分组织都没有他们所认为的那么多的数据，通过有意识的限制膨胀，他们可以放弃垂直扩展的 Postgres 节点。这会促成更可操作的栈，更多的选择，万一必须在云和供应商之间迁移。你可以在本地运行 Postgres 或测试，这对于无冲突的生产能力很重要。
结尾
观点时间：对于大多数人，最好的选择是从 Postgres 开始。它是久经考验的数据库，拥有非常多的特性，同时限制也很少。它是开源的，广泛的可用性，所以它可以很容易的运行在部署环境、CI，甚至是迁移至主流的云厂商。垂直扩展能力可以支持组织很长时间的需求。
在你达到AirBnB 或Uber 的级别时，像 Aurora 会更有趣。它看起来拥有很多 Postgres 的优点，仍然可以管理维护数据的位置和扩展的存储（代价时失去开发与生产的对等，锁定在特定厂商）。这个层次的组织运转繁忙，需要计算和内存资源能扩展超越单节点，此时将会收益像 CitusDB 这样的替代品。
在你达到谷歌的级别时，一些接近 Spanner 的产品可能是正确的选择。虽然延迟会有所增加，但它的扩展性会表现的更无限制。
列表中的数据库，在生产环境中，我只见过 MongoDB 和 Postgres，所以应该谨慎的看待这些建议。几乎可以肯定的是，随着进一步了解，关于他们的注意事项会逐渐显现。
原文链接：https://brandur.org/cloud-databases?utm_source=dbweekly&utm_medium=email
