分布式数据库 关系型数据库_最好的分布式关系数据库

分布式数据库 关系型数据库

关系SQL数据库 （自1980年代以来一直存在）在历史上一直在大型机或单个服务器上运行-这就是我们所拥有的。 如果希望数据库处理更多数据并更快地运行，则必须将其放在具有更多，更快的CPU，内存和磁盘的更大服务器上。 换句话说，您转向垂直可伸缩性或“向上扩展”。 稍后，如果您需要故障转移功能以提高可用性，则可以将“热备份”服务器与“主动-被动”群集中的主动服务器并置在一起，通常是共享存储。

需要ACID的四个属性（原子性，一致性，隔离性和持久性），以确保即使在发生网络分区，电源故障和其他错误的情况下，数据库事务也始终有效。 单个服务器上的数据库相对容易符合所有四个ACID属性。 对于分布式数据库而言，实现起来有点困难。

[SQL数据库正在获得NoSQL功能。 发现旧数据库可以做的10个新技巧 。 | 不要错过MySQL和MariaDB中的这7个强大功能 。 | 通过InfoWorld的App Dev Report新闻通讯了解编程方面的热门话题。 ]

NoSQL数据库 （于2009年左右推出）具有水平可伸缩性（意味着它们可以在多个服务器上运行），但通常缺乏完全的ACID合规性，并且通常不支持SQL语言。 NoSQL数据库引入了“最终一致性”的概念，这意味着，如果您从一台服务器写入数据库并立即从另一台服务器读取数据库，则可能看不到与从原来的服务器读取数据库时得到的结果相同的结果。书面。 但是，如果等待了足够长的时间，新数据将被复制到群集中的所有服务器，并且将保持一致。 最终的一致性对于许多应用程序（例如在线目录）来说足够好，但是对于财务而言却不够好。

[ 单击此处注册免费的三个小时的Kubernetes入门课程，该课程由Pluralsight和InfoWorld提供。 ]

最近，已经引入了几个可横向扩展的“横向扩展” SQL数据库。 更好的是，其中一些服务器可以处理具有地理分布的服务器，而无需牺牲一致性。 由于光速的限制，距离极远的服务器节点比本地节点需要更长的更新时间，但是有几种技术可以缓解该问题，包括使用共识组仲裁以及超高速网络和存储。

通常，您一直在使用的数据库和您想使用的新分布式数据库应尽可能兼容，以最大程度地减少架构和应用程序转换成本。 在最简单的情况下，您可以迁移架构和数据，然后只需在应用程序中更改连接字符串。 在最复杂的情​​况下，您将需要完成数据转换过程，对存储过程和触发器的完全重写以及对应用程序的数据层（包括SQL查询）的重大重写。

Amazon RDS和Amazon Aurora

Amazon RDS（关系数据库服务）是一项Web服务，可让您更轻松地在云中设置，操作和扩展关系数据库。 Amazon RDS支持MySQL，MariaDB，PostgreSQL，Oracle数据库和Microsoft SQL Server。

可以将Amazon RDS数据库配置为具有同步辅助实例进行故障转移的高可用性。 不幸的是，您无法从备用辅助实例读取。 您可以使用MySQL，MariaDB或PostgreSQL只读副本来增加读取比例，但是该副本是异步的，因此副本的状态可能落后于主实例的状态。

Amazon Aurora是Amazon RDS中的一项服务，可在快速的分布式存储上提供MySQL和PostgreSQL数据库的高性能集群 。 您可以在数据库群集中最多创建15个Aurora副本以支持只读查询，并且可以在多个可用区（AZ）中创建副本，以实现全局分发。

据亚马逊称，Aurora可以提供MySQL吞吐量的五倍和PostgreSQL吞吐量的三倍，而无需更改大多数现有应用程序。 亚马逊还声称更新Aurora只读副本的延迟时间约为20毫秒，这比MySQL只读副本快得多。

Azure SQL数据库

Azure SQL数据库是一种完全托管的关系云数据库服务，提供广泛SQL Server引擎兼容性，并允许您动态地上下扩展数据库资源。 Azure SQL数据库包括用于创建活动的地理副本的选项，该地理副本是按地理位置分布的辅助数据库。

在相同或不同的区域中最多支持四个辅助数据库，并且这些辅助数据库还可以用于只读查询。 如果需要将主数据库故障转移到辅助数据库之一，则可以手动或通过API进行。

Clustrix数据库

现在由MariaDB拥有的ClustrixDB是一个横向扩展的，集群化的关系型HTAP（混合事务/分析处理）数据库，采用无共享架构设计。 ClustrixDB主要与MySQL和MariaDB兼容。 当我回顾ClustrixDB时，该产品缺乏对空间扩展类型和全文本搜索的支持。 截至上一版本，它仍然缺少两者。

将节点添加到ClustrixDB可以扩展读取和写入。 ClustrixDB允许将群集部署在多个区域中，以在计划外区域故障期间提供容错能力。 在由独立实验室（但不是由InfoWorld进行）的测试中，ClustrixDB能够在15毫秒的延迟下每秒完成40K事务，负载为90％的读取和10％的写入，使其具有“ Cyber​​ Monday”的电子商务扩展能力。

蟑螂数据库

CockroachDB是由熟悉Google Cloud Spanner的前Google员工开发的，可横向扩展，分布式，兼容PostgreSQLPostgreSQL SQL源。 CockroachDB借鉴了Spanner的数据存储系统设计，并使用Raft算法在其节点之间达成共识。 CockroachDB不需要同步Spanner的GPS和原子钟。

CockroachDB建立在交易和一致的键值存储RocksDB之上。 CockroachDB背后的主要设计目标是支持ACID事务，水平可伸缩性和（最重要的）生存能力，因此得名。 默认情况下，CockroachDB使用可序列化隔离模式，这种隔离模式比大多数其他数据库实现的隔离模式要强。

当我在2018年初审查CockroachDB时，它的JOIN性能不是很好。 此后已解决。 CockroachDB支持将集群分布在多个可用性区域上，并在Google Cloud Platform或Amazon Web Services上提供完全托管的云数据库集群。

Google Cloud Spanner

Google Cloud Spanner是一个托管的分布式数据库，具有NoSQL数据库的可伸缩性，同时保留了SQL兼容性，关系架构，ACID事务和外部一致性。 Spanner非常接近CAP定理 。

Spanner被分片，全局分布和复制，并使用Paxos算法在其节点之间达成共识。 Spanner使用两阶段提交来实现强一致性，但是将Paxos组视为事务的成员。 每个Paxos组仅需要一个法定人数，而不是其成员的100％。

在Google的内部使用中，Spanner的可用性已超过5个9，即99.999％以上，这意味着每年的停机时间不到5分钟。 这就足够好了，大多数程序员通常不必费心编写代码来处理Spanner的可用性故障。

Spanner使用Google Common SQL，这是ANSI 2011 SQL的方言。 通用SQL与PostgreSQL，MySQL，SQL Server或Oracle数据库使用的任何SQL方言并不完全相同，在数据类型上有所不同，在数据处理领域也有很大差异。

相关文章：

• 评论：Amazon Aurora突破了MySQL
• MySQL对抗：Amazon Aurora超越Google Cloud SQL
• 评论：ClustrixDB可以向外扩展
• CockroachDB评论：为生存而构建的横向扩展SQL数据库
• 评论：Google Cloud Spanner将SQL扩展到NoSQL规模

翻译自: https://www.infoworld.com/article/3406458/the-best-distributed-relational-databases.html

分布式数据库 关系型数据库