开发分布式SQL数据库的6种技术挑战

我们在本年2月超过了YugaByte DB三年开拓阶段，到今朝为止，这是一段触目惊心的路程，但并非没有公正的技能挑衅。偶然我们不得不回到画图板，乃至筛选学术研究，以找到比我们手头的更好的办理方案，在这篇文章中，我们将概述在构建开源，云原生，高机能漫衍式SQL数据库的进程中我们必需办理的一些最难的架构题目。

好的，让我们开始切磋从最简朴到最具挑衅性的题目：

1.架构：亚马逊Aurora照旧谷歌Spanner？

我们早期做出的一个抉择是找到一个我们可以用作YugaByte DB架构灵感的数据库。我们亲近存眷两个体系，Amazon Aurora和Google Spanner。

Amazon Aurora是一个提供高可用性的SQL数据库。它具有与风行的RDBMS数据库（如MySQL和PostgreSQL）的兼容性，使其易于入门并可运行各类应用措施。Amazon Aurora也是AWS汗青上成长最快的处事之一。

Amazon Aurora处事与MySQL和PostgreSQL兼容，是AWS汗青上成长最快的处事。

Amazon Aurora具有可扩展的数据存储层，但查询层不是这样。以下是我们发明的Amazon Aurora的一些要害可扩展性限定：

• 写入不是程度可伸缩的。扩展写入吞吐量的独一要领是垂直扩展处理赏罚全部写入的节点（称为主节点）。这种扩展方案只是到今朝为止，因此数据库能处理赏罚几多写入IOPS存在固有的限定。
• 写入不是全局同等的。很多当代的云原生应用措施本质上是全局性的，必要跨多个地区陈设底层数据库。可是，Aurora仅支持多主机陈设，在产生斗嘴时最后一个写入措施（具有最高时刻戳）得胜。这也许导致纷歧致。
• 通过行使捐躯同等性的从属副本以得到读取的伸缩扩展。为了扩展读取，应用措施必要毗连到从属节点才气实现读取。当行使这些从属节点实现读取时，应用措施必要面临降级的同等性语义，以及一个单独的毗连端点。这使得应用措施架构很是伟大。

其它，Google Spanner是一个可程度扩展的SQL数据库，专为大局限可扩展和地理漫衍式应用措施而构建。

Cloud Spanner是独一为云构建的企业级、全局漫衍且高度同等的数据库处事，专门用于将相关数据库布局的上风与非相关程度扩展相团结。

这意味着Spanner可以无缝扩展读写，支持必要全局同等性的地理漫衍式应用措施，并在不捐躯正确性的环境下从多个节点执行读取。

可是，它放弃了RDBMS数据库提供应开拓职员祈望的很多认识成果集。譬喻，Google Spanner文档中突出表现了不支持外键束缚或触发器的究竟。

我们抉择回收殽杂要领。

• YugaByte DB的焦点存储架构受到Google Spanner的开导，该架构专为程度可扩展性和地理漫衍式应用措施而构建。
• YugaByte DB保存了与Amazon Aurora相同的PostgreSQL兼容查询层，它可以支持富厚的成果集，并支持最普及的用例。

2. SQL协议：PostgreSQL照旧MySQL？

我们想要对普及回收的SQL方言举办尺度化。我们还但愿它是开源的，而且在数据库周围拥有成熟的生态体系。衡量的天然选择是PostgreSQL和MySQL？

我们之以是选择PostgreSQL（而不是MySQL），缘故起因如下：

• PostgreSQL有一个更宽松的容许证，更切合YugaByte DB的开源精力。
• 与任何其他SQL数据库对比，PostgreSQL在已往几年中的风行度一向在飙升，这绝对没有受到影响！

在今朝排在DB-Engines排名网站前10位的五个SQL数据库中，自2014年以来，只有PostgreSQL的受接待水平越来越高，而其他数据库则趋于安稳或正在失去理智。

另外，对付很多应用措施，PostgreSQL是Oracle的绝佳更换品。组织正在被PostgreSQL所吸引，由于它是开源的，供给商中立（MySQL由Oracle拥有），拥有一个参加的开拓者社区，一个繁荣的供给商生态体系，一个强盛的成果集，以及一个成熟的代码库，一向在战斗 - 颠末20多年的严酷行使而健壮。

3.漫衍式事宜：Google Spanner或Percolator？

关于我们应该怎样计划漫衍式事宜，我们查察了Google Spanner和Percolator。

总而言之，Google Percolator提供高吞吐量但行使单个时刻戳。这种要领本质上是不行扩展的，仅合用于单个数据中心，面向及时说明（称为HTAP）的应用措施，而不是OLTP应用措施。另一方面，Google Spanner的分手时刻跟踪要领对付地理漫衍式OLTP和单数据中心HTAP应用措施来说都是一个很好的办理方案。

Google Spanner是在Google Percolator之后构建的，用于替代告白后端中手动分片的MySQL陈设，以实现程度可扩展性和地理漫衍式用例。可是，思量到其真正的漫衍式特征以及对时钟偏移跟踪的需求，Google Spanner的构建难度要高一个数目级。

有关此主题的更多具体信息，您可以具体相识Percolator与Spanner的衡量。

我们抉择回收Google Spanner要领，由于它可以支持：

• 更好的程度可扩展性
• 高度可用且机能更佳的多地区陈设。

我们坚信，大大都当代云应用都必要上述两种成果。现实上，GDPR和总共提供100个地域的民众云等合规性要求已经使这成为实际。

4. Raft是否合用于地理漫衍式事变负载？

Raft和Paxos是众所周知的漫衍式共鸣算法，而且已被正式证明是安详的，Spanner行使Paxos，可是，我们选择了Raft，由于：

• 对付开拓职员和运营团队Raft比Paxos更轻易领略。
• 它提供动态变动成员资格的手段，这是至关重要的（譬喻：在不影响机能的环境下变动呆板范例）。（banq注：Raft与Paxos首要区别在于Raft候选人可所以任何一个处事器节点，不必要专门指定候选人，不然这些候选人所有宕机怎么办？犹如一些TCC漫衍式事宜中存在事宜和谐器一样有单点风险）

然而，为了确保可线性化的读取，Raft要求吸取读取查询的每个率领者在现实提供读取查询之前起首将心跳动静撒播到Raft组中的大大都节点。在某些环境下，这也许会严峻低落读取机能。这种环境的一个示例是地理漫衍式陈设，个中来回会显著增进耽误，而且在诸如姑且收集分区之类的变乱的环境下增进失败查询的数目。

为了停止Raft高耽误，我们实验了率领者的租赁机制，这将应承我们无需来回实现率领者处事，同时保存了Raft的线性化特征。另外，我们行使单调时钟而不是及时时钟，以容忍时钟毛病。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!