分布式数据库：如何正确选择分片键？
过去十年见证了分布式数据库的崛起不仅通过本地集群来实现负载均衡，并提供高可用性，还具有数据中心内的机架感知等属性。专为云而设计的分布式数据库，可以跨越可用性区域，通过编排技术，支持公有云、私有云、混合云部署。近年来，市面上出现了大量专为分布式数据库部署而设计的新数据库系统，以及在初始设计中添加了分布式架构组件的其他数据库系统。
DB-Engines.com排名前100的数据库
DB-Engines.com是数据库领域的权威排行榜，它保留了所有数据库的流行指数，使用一种算法进行加权，监测诸如网站上的提及次数和谷歌的搜索趋势，Stack Overflow上的讨论或推特中的评论，工作职位要求的技术技能，以及在LinkedIn个人资料中提到这些技术的数量。
▲截至2022年5月，DB-Engines.com上排名前100的数据库
虽然DB-Engines收集了数百个不同的数据库（截至2022年5月共有394个）。但是本文我们缩小范围，只观察前100名数据库。在很大程度上，反映了市场现状。
关系型数据库管理系统（RDBMS），传统的SQL系统，仍然是最大的类别，占列表的47%。
另外，列表中有25%是NoSQL系统，涵盖了许多不同类型的数据库，像MongoDB文档数据库、Redis键值系统、ScyllaDB宽列数据库，以及Neo4j图数据库。
还有11%的数据库被列为多模型数据库，包括在同一系统中支持SQL和NoSQL的混合数据库，如微软的Cosmos DB或ArangoDB，或者支持多种NoSQL数据模型的数据库，如DynamoDB，它将自己列为NoSQL键值系统和文档存储。
最后，还有一些是由各种特殊用途的数据库组成，从搜索引擎到时间序列数据库，以及其他不容易归入简单的“SQL与NoSQL”区域的数据库。
但是所有这些数据库都是分布式数据库吗？这个词到底是什么意思？
分布式数据库的定义
2016年12月14日，ISO/IEC发布了最新版本的数据库语言SQL标准（ISO/IEC9075:2016）。随着时间的推移，如何构建与SQL兼容的分布式RDBMS系统一直在发展。分布式SQL，如PostgreSQL或CockroachDB NewSQL系统。相反，没有ANSI或ISO或IETF或W3C定义什么是NoSQL数据库。每种数据库都使用自己的专有查询语言，比如用于宽列NoSQL数据库的Cassandra查询语言（CQL），用于图形数据库的Gremlin/Tinkerpop查询方法。
然而，它们并没有定义数据如何在这些数据库中分布，查询语言也不能解决架构问题。因此，无论是SQL还是NoSQL，对于什么是分布式数据库，并没有标准、协议或共识。
因此，我花了一些时间来写下我自己的定义。坦率地说，这更像是一个门外汉的实用主义观点，而不是计算机科学教授的见解。
简而言之，你必须决定你如何定义集群，以及如何跨集群分配数据。接下来，你必须确定集群中每个节点的角色。每个节点都是对等的，还是有些节点处于更优越的领导地位，而其他节点则是跟随者。
然后，基于这些角色，你如何处理故障转移？最后，你必须在此基础上，弄清楚你如何尽可能均匀和容易地复制和分片数据。而这并不试图做到详尽无遗，你可以添加自己的特定条件。
简短的清单：感兴趣的系统
考虑到这些，我在前100名数据库中，找到五个示例，看看它们在测量属性时是如何比较的。其中有两个SQL系统和三个NoSQL系统。
Postgres和CockroachDB代表最好的分布式SQL。CockroachDB被称为 NewSQL，专为分布式数据库而设计。
MongoDB、Redis和ScyllaDB是分布式NoSQL，分别是文档数据库，键值存储，宽列数据库（也被称为键值数据库）。
在大多数情况下，适用于ScyllaDB的也同样适用于Apache Cassandra和其他与Cassandra兼容的系统。
假定你拥有专业的经验，而且对SQL与NoSQL的区别相对了解。基本上，如果需要一个表JOIN，坚持使用SQL和RDBMS。如果你可以将数据反规范化，那么NoSQL可能是一个很好的选择。我们不打算讨论作为数据结构或查询语言，两者哪个“更好”。而是讨论作为一个分布式数据库，哪个更好。
多数据中心集群
我们的选项在集群方面是如何比较的？现在，它们都能够进行集群，甚至是多数据中心操作。但是在PostgreSQL、MongoDB和Redis中，它们最初设计于单数据中心本地集群，在多数据中心设计之前就已经成为一种架构要求。
Postgres首次发布于1986年，完全早于云计算的概念。后来，它允许在其设计上，纳入这些技术和能力。
作为NewSQL革命的一部分，CockroachDB从一开始就考虑到了全球分布。MongoDB是在公有云诞生之初发布的，最开始设计时考虑到了单数据中心集群，但现在已经增加了对许多不同拓扑结构的支持。通过MongoDB Atlas，可以轻松部署到多个地区。
Redis，由于其低延迟的设计，通常被部署在单个数据中心，但它具有允许多数据中心部署的企业特性。ScyllaDB，像Cassandra一样，从一开始就考虑到了多数据中心的部署。
集群管理
如何进行复制和分片，取决于数据库架构的分层或同质化程度。
例如，在MongoDB中，有一个主服务器，其余的是主服务器的副本。副本是只读的，你只能对这个数据库的主副本进行写操作，不能直接更新。相反，你写到主数据库，它就会更新副本。所以，节点是异质的，而不是同质的。
这有助于在读取繁重的工作负载中分配流量，但在混合或写入工作负载中，对你没有一点好处，主服务器可能会成为一个瓶颈。
同样，如果主服务器发生故障会怎样？你将不得不完全停止写操作，直到集群选出一个新的主服务器，并将写操作分流到它上面。
相反，如果ScyllaDB或Cassandra，或任何其他无active-active的系统，客户可以从任何节点读取或写入。没有单一的故障点，节点的同质化程度要高得多。
而且每个节点都可以更新集群中的任何数据副本。因此，如果你有三个节点，每个节点都会根据其他两个节点的任何写入进行更新。
active-active在计算方面本身就比较困难，但是一旦解决了服务器保持彼此同步的问题，就会得到一个可以更好地平衡混合或写入大量工作负载的系统，因为每个节点都可以提供读取或写入服务。
那么，我们的各种例子在主复本或active-active对等方面是如何叠加的？CockroachDB和ScyllaDB，以及Cassandra一开始就考虑了active-active的主动式设计。在Postgres中，有一些可选的方法可以做到这一点，但它不是内置的。
此外，MongoDB没有正式支持active-active，但是已经有一些人在尝试如何做到这一点了。
对于Redis来说，active-active模型在Redis企业中可以通过无冲突复制数据类型（CRDTs）实现。Postgres、MongoDB和Redis都默认使用主副本数据分布模型。
复制
分布式系统设计也会影响如何跨部署到不同机架或数据中心之间分配数据。例如，给定一个主副本系统，只具有主的数据中心可以为任何写入工作负载服务，其他数据中心只能作为只读副本。
在一个支持多数据中心集群的点对点系统中，整个集群中的每个节点都可以接受读或写操作。
通过ScyllaDB，你可以决定每个站点有相同或甚至不同的复制因素。这里我展示了在一个数据中心的三个副本，在另一个数据中心有两个副本的可能性。
操作可以有不同级别的一致性。你可能在三个节点的数据中心进行本地数据的读或写，需要更新任一数据中心的节点才能成功执行操作。可调整的一致性，结合多数据中心的拓扑感知，为工作负载提供更多的灵活性。
拓扑感知
本地集群是分布式数据库开始的方式，允许多个系统共享负载。如果想让数据库在多个节点上进行分片，或者通过确保相同的数据在多个节点上可用来实现高可用性，那么这一点非常重要。
如果所有节点都安装在同一个机架上，一旦这个机架发生故障，就会很棘手。因此，添加拓扑感知，以便你可以感知同一数据中心内的机架。确保将数据分散在数据中心的多个机架上，从而最大限度地减少电源或连接丢失到一个或另一个机架的中断。
有些数据库做的很好，允许在不同的数据中心运行数据库的多个副本，并使用某种跨集群更新机制。每个数据库都是自主运行的，它们的同步机制可以是单向的，一个数据中心更新一个下游的副本，也可以是双向的或多向的。
这种地理分布可以通过允许更靠近用户的连接，来减少延迟。跨可用性区域或地区的数据库，还可以确保单个数据中心灾难不会导致数据库的部分或全部丢失。
去年我们的一个客户就发生了这种情况，但由于他们部署在三个不同的数据中心，所以数据损失为零。
跨集群更新最初是在批量级别上实现的。确保你的数据中心每天至少有一次同步。这并没有持续多久，后面人们开始确保更活跃的事务级更新。
如果你在运行强一致性数据库，就会受到基于光速的实时传播延迟的限制。因此，实现最终一致性是为了允许每个操作更新使用多数据中心，同时考虑到在短期内，要使所有数据中心的数据保持一致可能需要时间。
那么，在拓扑感知方面，它是如何叠加的？
所以，CockroachDB和ScyllaDB也是内置的。
从2015年开始，拓扑感知也成为MongoDB的一部分，他们在这方面有着多年的经验。
Postgres和Redis最初被设计为单数据中心解决方案，因此处理多数据中心的延迟对两者来说并非易事。现在，你可以添加拓扑感知，就像添加active-active系统功能一样，但它并不是开箱即用的。
让我们回顾一下所讨论的内容，分别查看这些数据库的属性。
▶︎ PostgreSQL
PostgreSQL是世界上最流行的的开源数据库之一，它以可靠性和稳定性而著称,在处理复杂SQL方面也表现出了绝对的优势。然而，Postgres仍在研究其跨集群和多数据中心的集群。
由于SQL基于强一致性事务模式，所以它不能很好地跨地域跨集群。在所有相关的数据中心之间，每个查询都将由于长时间的延迟而暂停。
此外，Postgres依靠的是主副本模型。集群中的一个节点是领导者，而其他节点是副本。虽然有负载平衡器或active-active插件，但这些也超出了基本的服务范围。
最后，Postgres的分片在大多数情况下仍然是手动的，尽管他们在开发自动分片方面取得了进展，但这也超出了基本产品的范围。
▶︎ CockroachDB
CockroachDB声称自己是“NewSQL”，一个专为分发而设计的SQL数据库。它可以水平扩展，在磁盘、机器、机架，甚至数据中心故障时都能生存下来，做到延迟最小，无需手动干预。
值得一提的是，CockroachDB使用Postgres线协议，并大量借鉴了Postgres开创的许多概念，而且并不局限于Postgres的架构。
多数据中心集群和点对点的拓扑结构从一开始就被内置。自动分片和数据复制也是如此。它还内置了数据中心感知功能，而且还可以添加机架感知功能。
对CockroachDB来说，它要求所有的事务都有很强的一致性，你可以把它看作是一个优点或缺点。既没有最终一致性的灵活性，也没有可调的一致性。这将降低吞吐量，并在任何跨数据中心部署中要求较高的基线延迟。
▶︎ MongoDB
MongoDB是NoSQL领域的领导者。随着它的发展，大量的分布式数据库功能被添加。现如今，MongoDB能够支持多数据中心集群。在大多数情况下，它仍然遵循主副本模式，也有办法使其成为对等的active-active。
▶︎ Redis
接下来是Redis，一个旨在作为内存缓存或数据存储的键值存储。Redis的数据全部在内存里，如果突然宕机，数据就会全部丢失，因此必须有一种机制来保证Redis的数据不会因为故障而丢失，这种机制就是Redis的持久化机制。
虽然持久化保存数据，但如果数据集不适合放在RAM中，它就会遭受巨大的性能损失。
正因为如此，它在设计时考虑到了本地集群。如果你无法承受5毫秒的等待时间来从SSD上获取数据，您可能更无法等待145毫秒来完成从旧金山到伦敦的网络往返时间。然而，有一些企业特性允许多数据中心的Redis集群。
Redis在大多数情况下是以主副本模式运行的。这适用于大量读取的缓存服务器。但这意味着，主节点是数据需要首先写入的地方，然后将这些数据分散到副本，以帮助平衡其缓存负载。
有一个企业功能，允许对等的active-active集群。Redis可以自动分片和复制数据，但它的拓扑感知仅限于作为企业功能的机架感知。
▶︎ ScyllaDB
ScyllaDB是按照Apache Cassandra中的分布式数据库模型设计的。因此，它默认是多数据中心集群。它可以自动分片，并且每个操作都有可调整的一致性，如果你想要更强的一致性，它甚至还支持轻量级事务来提供写入的线性化。
就拓扑感知而言，ScyllaDB支持机架感知和数据中心意识，甚至支持标记感知和分片感知，不仅知道数据存储在哪个节点上，甚至可以知道与该数据关联的CPU。
结论
虽然对于什么是分布式数据库，还没有一个行业标准，但是我们可以看到，许多领先的SQL和NoSQL数据库，都在某种程度上支持一组核心功能或属性。其中有些功能是内置的，有些被认为是增值包或第三方选项。
在本文分析的五个典型分布式数据库系统中，CockroachDB为SQL数据库提供了最全面的功能和特性，ScyllaDB为NoSQL系统提供了最全面的功能。
该分析应被视为某个时间段的调查。鉴于下一个技术周期的需求，每一个数据库系统都在不断发展，这个行业并没有停滞不前。
对用户来说，分布式数据库每年都在进步，变得更加灵活、性能更强、更具弹性和可扩展性。
原文链接
https://dzone.com/articles/comparing-distributed-databases
RECOMMEND
推荐阅读
01
《分布式数据库原理、架构与实践》
推荐理由
腾讯T14级别专家、腾讯金融云数据库首席研究员、腾讯TDSQL首席架构师执笔，从原理、架构、案例三个维度深度剖析分布式数据库
02
《深入理解分布式事务：原理与实战》
推荐阅读
京东专家/分布式事务架构专家/多个开源项目创始人撰写，5个维度全面展开，京东、阿里、腾讯、蚂蚁近20位专家力荐
更多精彩回顾
资讯 |《Java核心技术》基于Java 17全面升级！
干货 |再见了Java8，Java17：我要取代你
资讯 | Java核心技术大会2022 · 重磅发布
书单 |今天，Java27岁了！
新书 | 红蓝攻防：构建实战化网络安全防御体系
书讯 |7月书讯 | 12本新书如期而至！
每周赠书 | 第110期：成为架构师的路上，必看的经典好书
上新 | 运维数据治理，构筑智能运维的基石
书评 | 运营其实很重要
