导言
开发人员构建需要数据完整性、高读/写吞吐量和全天候全球可用性的关键任务应用程序，很少或没有停机时间或维护窗口，需要新型数据库。较旧的关系系统在可扩展性、可用性、弹性或负载下的性能方面无法满足这些需求。NoSQL数据库不提供记录系统所需的强大功能、标准查询语言或事务完整性。
此Refcard旨在让您熟悉分布式SQL数据库技术，它的工作原理，它解决的应用程序的问题和类型，以及如何评估不同的产品。
关于分布式SQL
分布式SQL数据库将NoSQL数据库的弹性和可扩展性与关系数据库的全部功能相结合。它们在多台服务器、容器或虚拟机（VM）上分发数据和处理。它们为传统关系数据库管理系统（RDBMS）提供了相同的ACID保证，以及分布式数据库的规模和可用性。与传统关系数据库相比，它们提供了更大的规模、可靠性和更大的数据库大小。与NoSQL数据库相比，分布式SQL提供了更强大的功能和一致性。分布式SQL数据库的固有使用SQL作为标准查询语言。
分布式SQL数据库被设计为通用操作数据库，作为规模、可用性和灾难恢复要求超出传统关系数据库功能的操作存储非常有用。例如，三星使用分布式SQL数据库为其三星云服务存储客户信息，该服务类似于苹果iCloud的照片和信息服务。ShortStack使用分布式SQL数据库来处理其运行在线竞赛的用户数据。
示例用例包括：
| 电子商务数据 | 用户互动、交易、产品 |
|---|---|
| 金融服务 | 交易和交易、防欺诈、客户和帐户信息 |
| 一般业务 | 供应链、库存、财务、客户和账户信息 |
分布式SQL数据库不同于其他一些非传统的关系数据库。例如，Amazon Aurora和谷歌Alloy只允许有多个副本的单个写入器，或者只允许有两个写入器(多主机)，不允许有其他副本。Aurora依赖于共享存储来实现可靠性和可伸缩性。术语“NewSQL”以前用于更多地包含其他类型的数据库，包括像VoltDB这样的内存数据库。虽然将所有或大部分数据保存在内存中可以降低延迟，并且有利于特定的用例，但对于规模较大的应用程序来说，这并不划算。一些NewSQL数据库实际上是分析存储，而分布式SQL数据库主要是事务性的。
分布式SQL的工作原理
分布式SQL数据库使用哈希算法将写操作分配给称为分区(在某些数据库中称为片)的不同单元。图1和图2显示了这些分区是如何分布在多个计算节点(如vm、容器或物理硬件)之间的。每个分区至少复制到两个节点(通常更多)。虽然这与非分布式数据库中的分区或分片有一些相似之处，但它是由哈希而不是值范围自动分配的，并由数据库自动平衡，而不是由操作员干预。
图1
图2
当客户机从分布式SQL数据库中读取数据时，数据库计算散列并选择一个或多个节点来提供所请求的数据。同样，查询也可以类似地分布在数据库中的多个节点中。由于数据是分布式的，所以可以同时从多个存储设备读取数据。为了确保数据在写入或更新时保持一致，数据库使用了一种类似于两阶段提交的分布式事务协议。现代分布式SQL数据库主要使用共识算法，如Paxos或Raft。这些协议协调集群中的成员关系，并确保将数据写入正确的节点，以保证数据的一致性和可靠性。
如果副本分布在云可用性区域（或私有数据中心的不同机架）之间，分布式SQL数据库在云端效果最佳。如果一个区域或区域不可用，则在剩余的一个或多个区域中选出一名新的领导人。数据从幸存的副本复制到现有节点，以保持容错性和数据分布（见图3和图4）。如果添加新节点，数据在新节点之间重新平衡，从而提高分布和性能。
图3
图4
一些数据库支持跨地理区域分发副本或分区。这大大增加了延迟，并影响了整体性能。为了解决这个问题，跨数据中心最终使用一致的容延迟复制协议。
图5
分布式SQL数据库的共享特征
虽然没有两种分布式SQL数据库产品完全相同，但它们确实具有将它们与其他类型的数据库区分开来的共同特征。首先，分布式SQL数据库是操作存储，而不是分析存储。虽然一些分布式SQL数据库与分析存储相结合，但该功能不在分布式SQL本身之外——类似于一些传统关系数据库提供全文搜索的方式。
关系模型
分布式SQL数据库使用关系模型，其中：
- 数据以表格、行和列表示
- 记录是行，字段是列
- 每行都由一个称为主键的唯一标识符标识
- 数据通过称为外键的共享值在表之间连接
- 一个称为主键的唯一标识符标识每行
- 共享值，称为外键，在表之间连接数据
与一些传统关系数据库一样，底层存储可能与表示的存储大不相同：
图6
尽管有相似性和故意兼容性，但与传统关系数据库相比，数据建模方式往往存在差异。最明显的是，序列非常不鼓励，因为在分布式集群中生成序列会造成瓶颈，阻碍了可扩展性和性能。相反，首选自然键或随机生成的唯一键。
一般架构
分布式SQL数据库基于相同的通用架构。数据存储在多个节点上。写入在这些节点之间平衡，并通过哈希算法分配，而读取同样平衡。数据被复制到多个节点，因此分布式SQL数据库可以在一个或多个节点的丢失中幸存下来。写入和更新通过节点之间协调的分布式事务进行处理。客户端代理或负载均衡器的某些组合可以指导数据库节点之间的流量。
ACID交易
与其他分布式数据库技术(即NoSQL)不同，分布式SQL数据库是为记录系统设计的。它们从一开始就提供事务完整性和强一致性，包括协调写入、锁定记录和其他方法(如多版本并发控制)。
同步复制
分布式SQL数据库使用节点之间的同步复制，以确保具有持续可用性的事务完整性。当写入时，每个节点都确认写入。其他类似类型的数据库，如Amazon Aurora，使用异步复制，这可能会导致节点之间的写入不一致。
查询分发
与客户端-服务器数据库技术相比，分布式SQL数据库查询被复制到任意数量的数据库节点。此外，数据可以从多个节点中提取，并聚合到单个结果集中。一些分布式SQL数据库甚至将复杂查询（即连接、子查询）的处理部分分发到不同的节点。
分布式SQL数据库之间的差异
虽然分布式SQL数据库的基本架构方法很容易识别，并且与NoSQL和传统关系数据库不同，但它们之间存在一些关键差异。
交付（云/DBaaS、本地、混合）
目前，每个分布式SQL数据库都可以安装在云中；然而，并非所有数据库都提供完全托管的数据库即服务（DBaaS）。一些分布式SQL数据库以DBaaS形式提供，作为客户安装，甚至混合安装，其中DBaaS可以管理本地实例并在私有数据中心和云安装之间复制，反之亦然。
兼容性
分布式SQL数据库努力与现有的传统RDBMS兼容。然而，与上一代关系数据库类似，方言、数据类型和过程语言等扩展功能也存在差异。领先的分布式SQL数据库有各种寻址兼容性的方法。
例如，MariaDB Xpand与MySQL和MariaDB数据库保持兼容性。这种兼容性包括有线和SQL方言，这意味着您可以使用大多数与MySQL或MariaDB兼容的现有工具和框架。CockroachDB试图与PostgreSQL进行有线兼容，但重新实现查询引擎以分发处理；这增加了兼容性，但减少了分布式查询处理和调优的一些机会。
对于迁移到分布式SQL的复杂应用程序，兼容模式下的现有传统RDBMS前端可能最有意义，特别是如果您正在使用传统数据库的扩展功能。但是，如果您长期运行在生产中，迁移到性能拓扑可能是比使用现有前端更好的选择。
共识算法
在2010年代初，NoSQL数据库因其可扩展性功能而广受欢迎。然而，他们放松了事务一致性，并删除了关键数据库功能，包括连接。虽然对于规模和并发性是最重要的因素的应用程序，NoSQL的采用是迅速的，但大多数需要事务完整性的关键任务应用程序仍然保留在Oracle、MySQL、PostgreSQL和SQL Server等客户端-服务器数据库中。
正在进行的共识算法（例如Paxos Raft）的研究使创建更好的水平缩放数据库能够保持一致性。关于哪个更好，有学术争论，但从用户的角度来看，它们服务于相同的基本目的。这项研究和其他发展使NoSQL的一些妥协变得没有必要：不再需要依赖“最终一致性”或BASE，而不是强级或ACID级事务。
可扩展性
分布式SQL架构实现了水平可扩展性；然而，实现细节对生产现实有很大影响。可扩展性的关键是如何将数据分配给节点，以及如何随着时间的推移重新平衡数据。此外，负载平衡在可扩展性和性能方面都起着核心作用。一些数据库依赖客户端来“知道”要处理哪个节点。其他人需要传统的IP负载均衡器或使用更复杂的数据库代理来了解底层数据库。
故障恢复
所有分布式SQL数据库在很大程度上都容错。然而，它们在故障期间发生的事情不同。客户端是否必须重试失败的交易，还是可以恢复并重播？如果节点丢失，数据库需要多长时间才能在节点之间重新平衡数据？
容器
主要分布式SQL实现支持Kubernetes，但实现和性能因IOPS的处理方式而异。虽然有些允许裸机安装，但当没有Kubernetes的情况下运行时，自愈和其他功能受到限制或丢失。
多式联运
严格地说，多模态功能不是分布式SQL函数，而是基于数据库是否提供辅助处理或数据存储类型，以及一致性保证如何应用于该功能。示例包括列存储、分析和文档存储。如果分布式SQL数据库提供了这些附加特性，那么就有可能将实时分析与操作功能结合起来。
列索引/混合工作负载支持
分布式SQL数据库本质上是操作数据库或事务性数据库。但是，通过添加柱状索引，分布式SQL数据库可以处理实时分析查询。考虑电子商务的情况:大多数查询将是简单的读写，但最终，有人会希望报告销售或客户合作类型——甚至将摘要转移到数据仓库中。这些是长时间运行的分析查询，可能会受益于柱状索引。大多数分布式SQL数据库还不具备此功能，但随着开发人员希望整合和简化他们的数据体系结构，可以预期它将变得更加常见。
图7
评估分布式SQL数据库
设计概念证明(PoC)最重要的方面是关注与实际应用程序密切匹配的数据和查询。人们倾向于用不切实际的查询来测试平台的限制(例如，15个连接6个表，取回1M行或单个行点查询)，并测量不同系统之间的性能。数据库技术针对特定的使用模式进行权衡和优化。对于分布式SQL，数据库会根据事务量的吞吐量进行优化。
在PoC的设计中，实际生产数据和应用流量是最优的。其次是模拟，它在表结构、查询复杂性和读写比例方面与一般模式非常接近。设定目标时，不要只考虑单一因素(如纯数据库延迟)，要关注应用在名义和峰值使用时的整体性能。这意味着，如果传统数据库在名义使用时提供1ms的延迟，但在峰值使用时提供1000ms的延迟，而应用程序执行速度为4s，但性能目标为3s，则不能达到目标。如果分布式SQL数据库在名义使用下的执行时间为15ms，而在峰值使用时的执行时间为20ms——并且应用程序满足其3s目标——那么它就满足了需求。
在生成负载时，必须确保基础设施能够生成足够的负载，以在预期的性能目标上测试数据库系统容量。例如，如果观察到延迟在每秒1000个事务时显著增加，但磁盘、CPU和网络的整体资源利用率似乎没有出现瓶颈，那么可能是负载生成基础设施而不是测试中的系统达到了最大。同样重要的是，确保负载发生器和被测系统之间的客户网络和其他基础设施有足够的容量。
成本考虑因素
评估成本比简单地审查许可、每小时成本或任何其他供应商广告措施更复杂。重要的是要考虑该系统的全部成本，包括以下因素：
- 员工培训
- 持续维护
- 故障期间服务损失的风险
- 升级期间的停机时间
- 支持和支持质量
- 云服务的IOPS
