分库分表 or NewSQL数据库？终于看懂应该怎么选-爱可生

作者介绍

温卫斌，就职于中国民生银行信息科技部，目前负责分布式技术平台设计与研发，主要关注分布式数据相关领域。

最近与同行科技交流，经常被问到分库分表与分布1 d V V ~ t #式数据库如何选择，网上也有很多关于中间件L E V x { { N B ~+传统关系数据库（分库分表）与NewSQL分布式数据库的文章e h Y { ，但有些观点与判断是我觉得是偏激的，脱离环境去评价方案好坏其实有失公允。

本文通过对两种模式关键特性实现原理对比，希望可以尽可能客观、中立的阐明各自真实的优缺点以及适用场景。

一、NewSQL数据库先进在哪儿？a d L 0 !

首先关于“中间件+关系数据库分库分表”算不算NewSQL分布式数据库问题，国外有篇论文pavlo-newsqs X N dl-sigmodrec，如果根% {据该, ! ? / 5 s *文中的分类，Spanner、TiDB、OB算是第一种新架构型，Sharding-Sphere、Mycat、DRDS等中间件方案算是第二种（文中还有第三种云数据库，本文暂不详细介n q | R # %绍）。

「pavlo-newsql-sigmodrec」

基于中间件（包括SDK和Proxy两种形式）+传统关系数据库（分库分表）模式是不是分布式架构？我觉得是的，因为存储确实也分布式了，也能6 c l P H r , H ~实现横向扩展。但是不是“伪”分布式数据库？从架构先进性来看O d m & L，这么说也有一定道理。

“伪”主要体现在中间件层与底层DB重复的SQL解析与执行计划生成、存储引擎基于B+Tree等，这在分布式数据库架构中实际上冗余低效的。为了避免引起真伪分布式数据库的口水战，本文中NewSQL数据库特指这种新架构NewSQL数据库。

New8 : u f R qSQL数据库相比中间件+分库分表的先进在哪儿？画一个简单U q Q b 0 q l + V的架构对比图：

• 传统数据库面向磁盘设计，基于内存的存储w ) V K +管理及并发控^ ] z t s v制，不如NewSQL数据库那般高效利用；
• 中间件模式SQL解析、执行计划优化等在中间件与数据库中重复工作，效率相比较低；
• NewSQL数据库的分布式事务相比于XA进行了优化，性能更高；
• 新架构NewSQL数据库存储设{ M H计即为基于paxos（或Raft）协议的多副本，相比于传统数据库主从模式（半同步转异步后也存在丢数问题），在实现了真正的高可用、高可靠（RTO<30s，RPO=0）；
• NewSQL数据库天生支持数据分片，数据的迁移、扩容都是自动化的，大大减轻了DBA的工作，同时对应用透{ ? T G n 5 G m o明，无需在SQL指定分库分表键。

这些大多也是Newl + o n 9 fSQL数据库产品主要宣传的点，不过这些看起来很美好的功能q Y O a t r w l #是否真j t j H T [ Y I的如此？接下来针对以上几点分别阐述下的我的理解。

二、分布式事务

这是把双刃剑。

1、CAP限制

想想更早些出现的NoSQL数据库为何不支持分布式事务（最新版的MongoDB等也开始支持了），是缺乏理论与实践支撑吗？并不是，原因是CAP定# 5 q Z 9理依然是分布式k h 9 + $ P数据库头上的紧箍咒，在保证强一致的同时必然会牺牲可用性A或分区容忍性P。为什么大部分NoSQL不提供分布式事务？

《为什- P E S / +么大部分NoSQL不提供分布式事务？》

那么NewSQL数据库突破CAP定理限制了吗？

并没有。NewSQy m :L数据库的鼻祖Google Spanner（目前绝大部分分布式数据库都是按照Spannerb E % 8 m架构设计的）提供了一致性和大于5个9的可用性，宣称是一个“实际上是CA”的，其真正的含义是系统处于CA状态的概率非常高，由于网络分区导V X C t P . ) Q致的服务停用的概率非常小，究其真正原因是其打造私有全球网保证了不会出现网络中断引发的网络分区，另外就是其高效的运维队伍，这也是cloud spanner的卖点。详细可见CAP提出者EY ( {ric Brewg r G V ) V O Ler写的《Spanner, TrueTime和CAP理论》。a ^ u 6 d + 0 B

《Spanner, TrueTime和CAP理论》S P ^、CPU、内存、电源等各类异常，通过严格的测试。

之前跟某友商交流，他们甚至说目前已知的NewSQL在分布式事务支持上都是不完整的，他们都有案例跑不过，圈内人士这么笃定，也说明了分布式事务的支持完整程度其实是层次不齐的。

但分布式事务又是这些NewSQL数据库的一个l Y O `非常重要的底层机制，跨资源的DML、DDL等都依赖其实现，如果这块的性能、完备性打折扣Q H } 0 S m $ 5 I，上层跨分片S5 : YQL执行的正确性会受到很^ m 9大影响。

3、性能

传统关系数据库也支持分布式事务XA，但为何很少有高并发场景下用呢？因为XA的基础两阶段提交协议存在网络开销大，阻塞时间长、死锁等问题，这也导致了其实际上很少大规模用在基于传统关系数据库的OLTP系统中。

NewSQL数据库的n y @ B 3 M { 5 o分布式事务实现也仍然多基于两阶段提交协议，例如google percolator分布式事务模型，采用原子钟+MVCC+ Snapshot Isolation（SI），这种方式通b . o V ^ @过TSO(Timestamp Oracle)保证了全局一致B 1 y ? X o性，通过MVCC避免了锁，另外通过prima1 8 7 A * !ry lock和secondary lock将提交的一部分转为异步，相比XA确实提高了分布式事务的性能。

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

但不管如何优化，相比于1PC，2PC多出来的Gy c 5 b t . S XID获取、网络开销、prepare日志持久化还是会带来? q N + & o W e很大的性能损失，尤其是跨节点的数量比较多时会更加显著，例如在银行场景做个批量扣款，一个文件可能上Wq | 8 & x个账户，这样的场景无论怎么做还是吞吐都不会很高。

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

虽然NewSQL分布式数据库: y n产品都宣传完备支持分布式事务，但这并d : 5 ^ g h p不是说应用可以完全不用关心数据拆分，这些数据库的最佳实践中仍| 7 - H ( V :然会写到，应用的大部分场景尽可能避免分布式事务。

既然强一致事务付 g r p m T出的性能代价太大，我们可以反思下是否真的需要这种强一致的分布式事务？尤其是在做微服务拆分后，很多系统也不太可能放在一个统一的数据库中J * * ; E 8 K。

尝试将一致性要求弱化，便是柔性事务，放弃ACID(Atomicity, Consistency, Isolation, Durability)，转投BASE(BasicaL r y : ` ! m % ]lly Available, Soft state, Eventually consistent)，例如Saga、TCC、可靠消息保证最终一致等模型，对于大规模高并发OLTP场景，我个人更建议使用柔性事务而非强一致的分布式事务。

关于柔性事务2 t k + R ，笔者之前也写过一个技术组件，最近几年也涌现出了一些新的模型与1 f 框架（例如阿里刚开源的Fescar），限于篇幅不再赘述，详细可阅读《分布式事务选型的取舍》。

解决分布式事务是否只能用两阶段提交1 N S D D - x 9协议？

OceanBase 1.0中通过updateserver避免分布式事务的思路很有启发性 ，不过2.9 S 3 P E M | e X0版后也变成了2PCF s 1 m 4 #。业界分布式事务也并非只有两阶段提交这一解。

三、HA与异V c : E y B [地多活

主从模式并不是最优的方式，就算是半同步复制，在极端情况下（半同步转异步）也存在丢数据问题，目前业界公认更好的方案是基于paxos分布式一致性协议或者H L y -其它类paxos如raft方式，Google Spanner、TiDB、/ Z F @CockcoachDB、OB都采用了这种方式，基于Paxos协议的多副本存储，遵循过半写原则，支持自动选主，解决了数据的高可靠，缩短了failover时间，提高了可用性，特别是减少了运维的工作量，这种方案技a n { t G术上已经很成熟，也是NewSQL数据库底层的标配。

当然这种方式其实也可以用在传统关系数据库，阿里、微信团队等也有将MK z K R e # f X )ySQL存储改造支持paxos多r m : K副本的，MySQL也推出了官方版MySQL Group Cluster- 6 Y r a v E R，预计不远的未来主从模式可能就成为历史了。

分布 r ;实现为multi-P g paxos或J : I +multi-raft，需要D ; c 3 &步中间件会告之数据延迟时间，应用从缓存中读取交易信息，将这段时间内涉及到的业务对象例如用户、账户进行黑名单管理，等数据r h同步追上之后再将这些业务对象从黑名单中剔除。

由于双写的不是所有数据库操作日志而只是交易信息，数据延$ q # J v v * d迟只影响/ & _一段时间内数据，这是z 8 H目前我觉得比较靠谱的异地度多活方案。

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

四、ScaJ ] A [ x P M y cle横向扩展与分片机制

paxos算法解决了高可用、高可靠问题，并没有解决Scale横向扩展的问题，所以分片是必须支持的。N| T 6 = k L MewSQL数据库都是天生内置分片机制的，而且会根据每个分片的数据负载(磁盘使用率、写入速度等)自动识别热点，然后进行分片的分裂、数据迁移、合并，这些过程应用是无感知的，这省去了D) R y Y 4 eBA的很多运维工作量。以TiDB为例，它将数据切成regiou H !n，如果region到64M时，数据自动进行迁移。

分库分表模式下需要应用设计之初就要明确各o 0 A O表的拆分键、拆分方式（rangeG u O、取模、一致性哈希或者自定义路由表）、路由规则、拆分库表数量、扩容方式等。相比NewSQL数据库，这种模式给应用带来了很; ? f I Y ) 3 J I大侵入和复杂度，这对大多数系统来说也是一大挑战。

分库分表模式也能做到在线扩容，基本思路是通过异步复制先追加数R ~ ? p r * p :间- r } J k件+分库分表模式的架构风格体现出的是一种妥协、平衡，它是一个面向应用型的设计；而NewSQL数据库则要求更高、“大包大揽”，它是一个通用底层技术软件，因此后者的复杂度、技术门槛也高很多。

六、存储引擎

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

NewSQL的底层存储引擎则多采用LSM，相比B+树LSM将对磁盘o , B - C的随机写变成顺序写，大大提高了写的性能。不过LS+ K 2 & i s 9 d WM的的读由于需要合并数据性能比B+树y q 5 ` 2 ^ x /差，一般来说LSM更适合应在写大于读的场景。当然这只是单纯数据结构角度的对比，在数据库实际实现时还会通过SSD、缓冲、bloom filter等方式优化读写性能，所以读性能基本不会下降太多。

NewSQL数据G F 3 ~ N 1 L P由于多副本、分布式事务等开销，相比单机关系数据库SQL的响应时间并不% O 0 ( O /占优，但由于集群的弹性扩展，整体QPS提升还是很明显的，这也是NewSQL数据库厂商说分布式数据库更看重的是[ : 0 7 l v吞吐，而不是单笔SQL响应时间的原因。

七、成熟度与生态

分布式数据库是个新型通用底层软件，准确的衡量与评价需要一个多维度的测试模型，需包括发展现状、使X N N % u l g用情况、社区生态、监控运维、周边配套工具、功能满足度、DBA人才、SQL兼容性、性能测试、高可用测试、在线扩容、分布式# T E e j事务、隔离@ _ ^ F级别、在线DDLG u l *等b 0 z ^ { h K等，虽然NewSQL数据库发展经过了一定时间检验，但多集中在互联网以及传统企业非核心交易系统中，目前还D N 1 3 Y f / 7处于快速迭代、规模使用不断优化完善的阶段。

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

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

对于传统企业例如银行这种风险意识较高的行业) o % V q B 3 |来说，NewSQL$ D : k X U数据库则可能在未来一段时间内仍处于探索、审慎试点的阶O m z 4 T O (段。基于中间件+分库分表模式架构简单，技术门槛更低，虽然没有NewSQL数据库功能全面，但大部分场景最核心的诉求也就是拆分后SQL的正确路由，而此功能中间件模; q !式应对还是绰绰有余的，可^ ` N 9 q ] 统，如果你仍然打算把数据库当做一个黑盒产品来用，踏踏实实用好分库分表会被认为是个稳妥的选择。

很多时候软件选型取决于领域特征以及架构师风格，限于笔者知识与所属行业特点所限，以上仅为个人粗浅的一些观点，欢迎讨论。