分库分表 or NewSQL数据库？终于看懂应该怎么选！

最近与同行科技交流，经常被问到分库分表与分布式数据库如何选择，网上也有很多关于中间件+传统关系数据库(分库分表)与NewSQL分布式数据库的文章，但有些观点与判断是我觉得是偏激的，脱离环境去评价方案好坏其实有失公允。

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

一、NewSQL数据库先进在哪儿?

首先关于“中间件+关系数据库分库分表”算不算NewSQL分布式数据库问题，国外有篇论文pavlo-newsql-sigmodrec，如果根据该文中的分类，Spanner、TiDB、OB算是第一种新架构型，Sharding-Sphere、Mycat、DRDS等中间件方案算是第二种(文中还有第三种云数据库，本文暂不详细介绍)。

基于中间件(包括SDK和Proxy两种形式)+传统关系数据库(分库分表)模式是不是分布式架构?我觉得是的，因为存储确实也分布式了，也能实现横向扩展。但是不是“伪”分布式数据库?从架构先进性来看，这么说也有一定道理。

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

NewSQL数据库相比中间件+分库分表的先进在哪儿?画一个简单的架构对比图：

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

这些大多也是NewSQL数据库产品主要宣传的点，不过这些看起来很美好的功能是否真的如此?接下来针对以上几点分别阐述下的我的理解。

二、分布式事务

这是把双刃剑。

1、CAP限制

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

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

并没有。NewSQL数据库的鼻祖Google Spanner(目前绝大部分分布式数据库都是按照Spanner架构设计的)提供了一致性和大于5个9的可用性，宣称是一个“实际上是CA”的，其真正的含义是系统处于CA状态的概率非常高，由于网络分区导致的服务停用的概率非常小，究其真正原因是其打造私有全球网保证了不会出现网络中断引发的网络分区，另外就是其高效的运维队伍，这也是cloud spanner的卖点。详细可见CAP提出者Eric Brewer写的《Spanner, TrueTime和CAP理论》。

2、完备性

两阶段提交协议是否严格支持ACID，各种异常场景是不是都可以覆盖?

2PC在commit阶段发送异常，其实跟最大努力一阶段提交类似也会有部分可见问题，严格讲一段时间内并不能保证A原子性和C一致性(待故障恢复后recovery机制可以保证最终的A和C)。完备的分布式事务支持并不是一件简单的事情，需要可以应对网络以及各种硬件包括网卡、磁盘、CPU、内存、电源等各类异常，通过严格的测试。

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

但分布式事务又是这些NewSQL数据库的一个非常重要的底层机制，跨资源的DML、DDL等都依赖其实现，如果这块的性能、完备性打折扣，上层跨分片SQL执行的正确性会受到很大影响。

3、性能

传统关系数据库也支持分布式事务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个账户，这样的场景无论怎么做还是吞吐都不会很高。

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

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

（编辑：核心网）

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