往后二十年缔造了分布式系统资料库的兴起不但透过邻近地区软件产业来同时实现阻抗平衡，并提供更多可扩展性，还具有网络系统内的机壳交互等特性。专门针对云而结构设计的分布式系统资料库，可以横跨易用性地区，透过选曲控制技术，支持公有云、私有云、混和云布署。近几年，市售出现了大批专门针对分布式系统资料库布署而结构设计的新资料库控制系统，和在如上所述结构设计中加进了分布式系统构架模块的其他资料库控制系统。
DB-Engines.com名列前100的资料库
DB-Engines.com是资料库应用领域的权威性榜单，它留存了大部份资料库的盛行成分股，采用一种演算法进行平均数，监控譬如中文网站上的提及单次和Google的搜寻态势，Stack Overflow上的探讨或twitter中的文章，工作职务明确要求的控制技术专业技能，和在LinkedInfacai中提及这些控制技术的数目。
▲截止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中，它就会遭受巨大的性能损失。
s软件产业。
Redis在大多数情况下是以主副本模式运行的。这适用于大批读取的缓存服务器。但这意味着，主节点是数据需要首先写入的地方，然后将这些数据分散到副本，以帮助平衡其缓存阻抗。
有一个企业功能，允许对等的active-active软件产业。Redis可以自动分片和复制数据，但它的拓扑交互仅限于作为企业功能的机壳交互。
▶︎ ScyllaDB
ScyllaDB是按照Apache Cassandra中的分布式系统数据库模型结构设计的。因此，它默认是多网络系统软件产业。它可以自动分片，并且每个操作都有可调整的一致性，如果你想要更强的一致性，它甚至还支持轻量级事务来提供更多写入的线性化。
就拓扑交互而言，ScyllaDB支持机壳交互和网络系统意识，甚至支持标记交互和分片交互，不但知道数据存储在哪个节点上，甚至可以知道与该数据关联的CPU。
结论
虽然对于什么是分布式系统资料库，还没有一个行业标准，但是我们可以看到，很多领先的SQL和NoSQL资料库，都在某种某种程度上支持一组核心功能或特性。其些功能是内置的，有些被认为是增值包或第三方选项。
在责任编辑分析的五个典型分布式系统资料库控制系统中，CockroachDB为SQL资料库提供更多了最全面的功能和特性，ScyllaDB为NoSQL控制系统提供更多了最全面的功能。
该分析应被视为某个时间段的调查。鉴于下一个控制技术周期的需求，每一个资料库控制系统都在不断发展，这个行业并没有停滞不前。
对用户来说，分布式系统资料库每年都在进步，变得更加灵活、性能更强、更具弹性和可扩展性。
