分库分表与NewSQL怎么选择

本文内容主要讲解“如何选择子数据库子表和NewSQL”。感兴趣的朋友不妨看看。本文介绍的方法简单、快速、实用。让边肖带你学习“如何选择子表和NewSQL”！

NewSQL 数据库先进在哪儿？

首先，国外有一篇论文pavlo-NewSQL-sigmoderec关于“中间件关系数据库子数据库子表”是否是NewSQL分布式数据库：

3359 db.cs.cmu.edu/papers/2016/pavlo-newsql-Sigmodrec 2016.pdf根据本文的分类，扳手、TiDB和OB是第一个新的架构类型，而一些中间件解决方案如Sharding-Sphere、Mycat和DRDS是第二个(本文中还有第三个云数据库，本文

传统的基于中间件(包括SDK和Proxy)的关系数据库模型是分布式架构吗？

我认为是这样，因为存储确实是分布式的，可以横向扩展。但不是“伪”分布式数据库？从高级架构的角度来看，这种说法有些道理。

“伪”主要体现在中间件层和底层DB之间重复的SQL解析和执行计划生成，以及基于B树的存储引擎，这在分布式数据库架构中实际上是冗余且低效的。

为了避免真假分布式数据库的口水战，本文参考了这种新架构的NewSQL数据库。

与中间件子数据库子表相比，NewSQL数据库有什么优势？画一个简单的架构对比图：

传统数据库是面向磁盘、基于内存的存储管理和并发控制，效率不如NewSQL数据库。

中间件的Schema SQL分析和执行计划优化在中间件和数据库中重复工作，效率相对较低。

与XA相比，NEWS SQL数据库的分布式事务进行了优化，具有更高的性能。

NewSQL数据库存储设计的新架构基于Paxos(或Raft)协议。与传统数据库主从模式(也存在半同步到异步后数据丢失的问题)相比，真正做到了高可用、高可靠(RTO30s，RPO=0)。

NewSQL数据库自然支持数据分片，数据的迁移和扩展都是自动的，大大减少了DBA的工作，同时对应用透明，不需要在SQL中指定子数据库和子表键。

这些大部分都是NewSQL数据库产品的主要宣传点，但这些看似漂亮的功能真的如此吗？接下来，我将分别阐述我对以上几点的理解。

分布式事务

首先要说的是分布式事务：这是一把双刃剑。

CAP 限制

想想为什么早期出现的NoSQL数据库不支持分布式事务(最新版本的MongoDB也开始支持分布式事务)。是缺乏理论和实践支撑吗？

不是，原因是CAP定理仍然是分布式数据库头上的一个颈环诅咒，在保证强一致性的同时，必然会牺牲可用性A或者分区容差P。

为什么大多数NoSQL不提供分布式事务？那么，NewSQL数据库突破CAP定理了吗？不完全是。

NewSQL数据库(目前大部分分布式数据库都是按照Spanner架构设计的)的鼻祖Google Spanner提供了大于5个9的一致性和可用性，声称它是“事实上的CA”。

真正的意义是系统处于CA状态的概率高，网络分区导致服务中断的概率很小。真正的原因是私有的全局网络保证了不会出现网络中断导致的网络分区。

提到在分布式系统中，你可以知道工作在哪里或者什么时候完成工作，但是不能同时知道两者；两阶段协议本质上是一个反可用性协议。

完备性

两阶段提交协议是否严格支持ACID，各种异常场景能否覆盖？

2PC在提交阶段发送异常。事实上，类似于尽力而为的第一阶段提交，会有一些可见的问题。严格来说，A的原子性和C的一致性在一段时间内是无法保证的(Recovery机制可以保证故障恢复后的最终A和C)。

完整的分布式事务支持不是一件简单的事情。它需要能够处理网络和各种硬件的各种异常，包括网卡、磁盘、CPU、内存、电源等，并通过严格的测试。

在和朋友沟通之前，他们甚至说目前已知的NewSQL在分布式事务支持上是不完整的，都有无法逃脱的案例。圈内人如此肯定，也说明分布式事务的支持完整性程度其实参差不齐。

然而，分布式事务是这些NewSQL数据库非常重要的底层机制。DML、DDL等。跨资源都取决于它的实现。如果这个块的性能

、完备性打折扣，上层跨分片  SQL 执行的正确性会受到很大影响。

性能

传统关系数据库也支持分布式事务 XA，但为何很少有高并发场景下用呢?

因为 XA 的基础两阶段提交协议存在网络开销大，阻塞时间长、死锁等问题，这也导致了其实际上很少大规模用在基于传统关系数据库的 OLTP 系统中。

NewSQL 数据库的分布式事务实现也仍然多基于两阶段提交协议，例如 google percolator  分布式事务模型，采用原子钟+MVCC+Snapshot Isolation(SI)。

这种方式通过 TSO(Timestamp Oracle)保证了全局一致性，通过 MVCC 避免了锁，另外通过 primary lock 和  secondary lock 将提交的一部分转为异步，相比 XA 确实提高了分布式事务的性能。

SI 是乐观锁，在热点数据场景，可能会大量的提交失败。另外 SI 的隔离级别与 RR 并无完全相同，它不会有幻想读，但会有写倾斜。

但不管如何优化，相比于 1PC，2PC 多出来的 GID 获取、网络开销、prepare  日志持久化还是会带来很大的性能损失，尤其是跨节点的数量比较多时会更加显著。

例如在银行场景做个批量扣款，一个文件可能上 W 个账户，这样的场景无论怎么做还是吞吐都不会很高。

Spanner 给出的分布式事务测试数据：

虽然 NewSQL  分布式数据库产品都宣传完备支持分布式事务，但这并不是说应用可以完全不用关心数据拆分，这些数据库的最佳实践中仍然会写到，应用的大部分场景尽可能避免分布式事务。

既然强一致事务付出的性能代价太大，我们可以反思下是否真的需要这种强一致的分布式事务?

尤其是在做微服务拆分后，很多系统也不太可能放在一个统一的数据库中。

尝试将一致性要求弱化，便是柔性事务，放弃  ACID(Atomicity，Consistency，Isolation，Durability)，转投BASE(Basically Available，Soft  state，Eventually consistent)。

例如 Saga、TCC、可靠消息保证最终一致等模型，对于大规模高并发 OLTP 场景，我个人更建议使用柔性事务而非强一致的分布式事务。

关于柔性事务，笔者之前也写过一个技术组件，最近几年也涌现出了一些新的模型与框架(例如阿里刚开源的  Fescar)，限于篇幅不再赘述，有空再单独写篇文章。

解决分布式事务是否只能用两阶段提交协议?OceanBase1.0 中通过 updateserver 避免分布式事务的思路很有启发性 ，不过 2.0  版后也变成了 2PC。

业界分布式事务也并非只有两阶段提交这一解，也有其他方案 its-time-to-move-on-from-two-phase：

https://www.jdon.com/51588

HA 与异地多活

主从模式并不是最优的方式，就算是半同步复制，在极端情况下(半同步转异步)也存在丢数问题。

目前业界公认更好的方案是基于 Paxos 分布式一致性协议或者其他类 Paxos 如 Raft 方式，Google  Spanner、TiDB、cockcoachDB、OB 都采用了这种方式。

基于 Paxos 协议的多副本存储，遵循过半写原则，支持自动选主，解决了数据的高可靠，缩短了 Failover  时间，提高了可用性，特别是减少了运维的工作量，这种方案技术上已经很成熟，也是 NewSQL 数据库底层的标配。

当然这种方式其实也可以用在传统关系数据库，阿里、微信团队等也有将 MySQL 存储改造支持 Paxos 多副本的，MySQL 也推出了官方版 MySQL  Group Cluster，预计不远的未来主从模式可能就成为历史了。

分布式一致性算法本身并不难，但具体在工程实践时，需要考虑很多异常并做很多优化，实现一个生产级可靠成熟的一致性协议并不容易。

例如实际使用时必须转化实现为 multi-paxos 或 multi-raft，需要通过 batch、异步等方式减少网络、磁盘 IO 等开销。

需要注意的是很多 NewSQL 数据库厂商宣传基于 Paxos 或 Raft  协议可以实现【异地多活】，这个实际上是有前提的，那就是异地之间网络延迟不能太高。

以银行“两地三中心”为例，异地之间多相隔数千里，延时达到数十毫秒，如果要多活，那便需异地副本也参与数据库日志过半确认，这样高的延时几乎没有 OLTP  系统可以接受的。

数据库层面做异地多活是个美好的愿景，但距离导致的延时目前并没有好的方案。

之前跟蚂蚁团队交流，蚂蚁异地多活的方案是在应用层通过 MQ 同步双写交易信息，异地 DC 将交易信息保存在分布式缓存中。

一旦发生异地切换，数据库同步中间件会告之数据延迟时间，应用从缓存中读取交易信息，将这段时间内涉及到的业务对象例如用户、账户进行黑名单管理，等数据同步追上之后再将这些业务对象从黑名单中剔除。

由于双写的不是所有数据库操作日志而只是交易信息，数据延迟只影响一段时间内数据，这是目前我觉得比较靠谱的异地度多活方案。

另外有些系统进行了单元化改造，这在 Paxos 选主时也要结合考虑进去，这也是目前很多 NewSQL 数据库欠缺的功能。

Scale 横向扩展与分片机制

Paxos 算法解决了高可用、高可靠问题，并没有解决 Scale 横向扩展的问题，所以分片是必须支持的。

NewSQL  数据库都是天生内置分片机制的，而且会根据每个分片的数据负载(磁盘使用率、写入速度等)自动识别热点，然后进行分片的分裂、数据迁移、合并，这些过程应用是无感知的，这省去了  DBA 的很多运维工作量。

以 TiDB 为例，它将数据切成 Region，如果 Region 到 64M 时，数据自动进行迁移。

分库分表模式下需要应用设计之初就要明确各表的拆分键、拆分方式(Range、取模、一致性哈希或者自定义路由表)、路由规则、拆分库表数量、扩容方式等。

相比 NewSQL 数据库，这种模式给应用带来了很大侵入和复杂度，这对大多数系统来说也是一大挑战。

分库分表模式也能做到在线扩容，基本思路是通过异步复制先追加数据，然后设置只读完成路由切换，最后放开写操作，当然这些需要中间件与数据库端配合一起才能完成。

这里有个问题是 NewSQL 数据库统一的内置分片策略(例如 TiDB 基于  Range)可能并不是最高效的，因为与领域模型中的划分要素并不一致，这导致的后果是很多交易会产生分布式事务。

举个例子，银行核心业务系统是以客户为维度，也就是说客户表、该客户的账户表、流水表在绝大部分场景下是一起写的。

但如果按照各表主键 Range 进行分片，这个交易并不能在一个分片上完成，这在高频 OLTP 系统中会带来性能问题。

分布式 SQL 支持

常见的单分片 SQL，这两者都能很好支持。NewSQL 数据库由于定位与目标是一个通用的数据库，所以支持的 SQL 会更完整，包括跨分片的  Join、聚合等复杂 SQL。

中间件模式多面向应用需求设计，不过大部分也支持带拆分键 SQL、库表遍历、单库  Join、聚合、排序、分页等。但对跨库的join以及聚合支持就不够了。

NewSQL 数据库一般并不支持存储过程、视图、外键等功能，而中间件模式底层就是传统关系数据库，这些功能如果只是涉及单库是比较容易支持的。

NewSQL 数据库往往选择兼容 MySQL 或者 PostgreSQL 协议，所以 SQL 支持仅局限于这两种，中间件例如驱动模式往往只需做简单的  SQL 解析、计算路由、SQL 重写，所以可以支持更多种类的数据库 SQL。

SQL 支持的差异主要在于分布式 SQL 执行计划生成器，由于 NewSQL 数据库具有底层数据的分布、统计信息，因此可以做  CBO，生成的执行计划效率更高。

而中间件模式下没有这些信息，往往只能基于规则 RBO(Rule-Based-Opimization)。

这也是为什么中间件模式一般并不支持跨库 Join，因为实现了效率也往往并不高，还不如交给应用去做。

这里也可以看出中间件+分库分表模式的架构风格体现出的是一种妥协、平衡，它是一个面向应用型的设计;而 NewSQL  数据库则要求更高、“大包大揽”，它是一个通用底层技术软件，因此后者的复杂度、技术门槛也高很多。

存储引擎

传统关系数据库的存储引擎设计都是面向磁盘的，大多都基于 B+ 树。B+  树通过降低树的高度减少随机读、进而减少磁盘寻道次数，提高读的性能，但大量的随机写会导致树的分裂，从而带来随机写，导致写性能下降。

NewSQL 的底层存储引擎则多采用 LSM，相比 B+ 树 LSM 将对磁盘的随机写变成顺序写，大大提高了写的性能。

不过 LSM 的的读由于需要合并数据性能比 B+ 树差，一般来说 LSM 更适合应在写大于读的场景。

当然这只是单纯数据结构角度的对比，在数据库实际实现时还会通过 SSD、缓冲、Bloom Filter  等方式优化读写性能，所以读性能基本不会下降太多。

NewSQL 数据由于多副本、分布式事务等开销，相比单机关系数据库 SQL 的响应时间并不占优，但由于集群的弹性扩展，整体 QPS  提升还是很明显的。

这也是 NewSQL 数据库厂商说分布式数据库更看重的是吞吐，而不是单笔 SQL 响应时间的原因。

成熟度与生态

分布式数据库是个新型通用底层软件，准确的衡量与评价需要一个多维度的测试模型。

需包括发展现状、使用情况、社区生态、监控运维、周边配套工具、功能满足度、DBA 人才、SQL  兼容性、性能测试、高可用测试、在线扩容、分布式事务、隔离级别、在线 DDL 等等。

虽然 NewSQL 数据库发展经过了一定时间检验，但多集中在互联网以及传统企业非核心交易系统中，目前还处于快速迭代、规模使用不断优化完善的阶段。

相比而言，传统关系数据库则经过了多年的发展，通过完整的评测，在成熟度、功能、性能、周边生态、风险把控、相关人才积累等多方面都具有明显优势，同时对已建系统的兼容性也更好。

对于互联网公司，数据量的增长压力以及追求新技术的基因会更倾向于尝试 NewSQL  数据库，不用再考虑库表拆分、应用改造、扩容、事务一致性等问题怎么看都是非常吸引人的方案。

对于传统企业例如银行这种风险意识较高的行业来说，NewSQL 数据库则可能在未来一段时间内仍处于探索、审慎试点的阶段。

基于中间件+分库分表模式架构简单，技术门槛更低，虽然没有 NewSQL 数据库功能全面，但大部分场景最核心的诉求也就是拆分后 SQL  的正确路由，而此功能中间件模式应对还是绰绰有余的，可以说在大多数 OLTP 场景是够用的。

限于篇幅，其他特性例如在线 DDL、数据迁移、运维工具等特性就不在本文展开对比。

总结

如果看完