关于newsql数据库先进性介绍
首先，关于“中间件+关系数据库子数据库和子表”是否是newsql分布式数据库，有国外论文pavlo- newsql-sigmodrec。按照文中的分类，Spanner、TiDB、OB是第一种新架构，其次是Sharding-Sphere、Mycat、DRDS等中间件方案(文中还有第三种云数据库。
基于中间件(包括SDK和代理)+传统关系数据库(子数据库和子表)的模型是分布式架构吗？我觉得可以，因为存储确实是分布式的，而且可以横向扩展。但不是“伪”分布式数据库？从高级架构的角度来看，这是有一定道理的。“伪”主要体现在中间件层和底层DB之间重复的SQL解析和执行计划生成，以及基于B+树的存储引擎，这在分布式数据库架构中实际上是冗余和低效的。为了避免真实可信的分布式数据库之间的口水战，本文参考了NewSQL数据库的新架构。
NewSQL数据库相比中间件+子数据库和子表有什么优势？画一个简单的架构比较图:
1.传统数据库是面向磁盘、基于内存的存储管理和并发控制，效率不如NewSQL数据库。
2.中间件模式的SQL分析和执行计划优化在中间件和数据库中重复，效率比较低；
3.与XA相比，3的分布式事务。NewSQL数据库优化，性能更高；
4.新架构NewSQL数据库的存储设计基于paxos(或Raft)协议，有多个副本。与传统的数据库主从模式(半同步到异步后也存在数据丢失的问题)相比，它实现了真正的高可用性和高可靠性(RTO
5.NewSQL数据库天生支持数据分片，数据迁移和扩展都是自动的，大大减少了DBA的工作，同时对应用透明，不需要在SQL中指定数据库和表键。
这些大部分都是NewSQL数据库产品的主要宣传点，但这些看似美好的功能真的如此吗？接下来，我将分别阐述我对以上几点的理解。
分布式交易
这是一把双刃剑。
上限限制
想想为什么早先出现的NoSQL数据库不支持分布式事务(最新版本的mongoDB等。也开始支持了)。是缺乏理论和实践支撑吗？不会，原因是CAP定理仍然是分布式数据库的瓶颈诅咒，在保证强一致性的同时，必然会牺牲可用性A或分区容忍度P。为什么大多数NoSQL不提供分布式事务？
那么，NewSQL数据库突破了CAP定理了吗？不完全是。NewSQL数据库的鼻祖Google Spanner(目前大部分分布式数据库都是按照Spanner架构设计的)提供了大于5个9的一致性和可用性，号称是一个“实实在在的CA”。它的真实意义是* *系统处于CA状态的概率很高，由于网络分区而导致服务中断的概率很小。* *真正的原因是其私有的全球网络保证了不会出现网络中断造成的网络分区，以及高效的运维团队，这也是云扳手的卖点。参见CAP的发起人Eric Brewer写的Spanner、TrueTime和CAP Theory。
完整性:
两阶段提交协议是否严格支持ACID，能否覆盖各种异常场景？2PC在提交阶段发送一个异常。实际上，类似于尽力阶段，会有一些可见的问题。严格来说，A的原子性和C的一致性在一段时间内是无法保证的(恢复机制可以保证故障恢复后最终的A和C)。完整的分布式事务支持不是一件简单的事情。需要能够应对网络和各种硬件的各种异常，包括网卡、磁盘、CPU、内存、电源等。，并通过严格的测试。之前和一个朋友交流，他们甚至说目前已知的NewSQL在分布式事务支持上是不完整的，都有跑不过的情况。业内人士如此肯定，也说明分布式事务的支持完备性其实是参差不齐的。**
然而，分布式事务是这些新SQL数据库和跨资源DML、DDL等的一个非常重要的底层机制。一切都取决于它的实施。如果这个块的性能和完整性受到损害，上层跨碎片SQL执行的正确性就会受到很大影响。
传统关系数据库也支持分布式事务XA，但为什么在高并发场景下很少使用？由于XA的基本两阶段提交协议存在网络开销大、阻塞时间长、死锁等问题，在基于传统关系数据库的OLTP系统中很少使用。NewSQL数据库中分布式事务的实现仍多基于两阶段提交协议，如google percolator分布式事务模型，采用原子钟+MVCC+快照隔离(SI)。这种方法通过TSO(时间戳Oracle)确保全局一致性，并避免通过MVCC锁定。此外，与XA相比，使用主锁和辅助锁使提交的一部分异步确实提高了分布式事务的性能。
“SI是一种乐观锁定，在热数据场景下，大量提交可能会失败。此外，SI的隔离水平与RR并不完全相同。不会有幻想阅读，但会有书写倾斜。”
但无论如何优化，与1PC相比，2PC额外的GID获取、网络开销和准备日志持久化仍然会带来很大的性能损失，尤其是在交叉节点数量较多的情况下。例如，如果在银行场景中进行批量扣款，则可能会将一个文件加载到w个帐户中，这种场景的吞吐量无论如何都不会很高。
" Spanner给出的分布式交易测试数据"
虽然NewSQL分布式数据库产品都宣传完全支持分布式事务，但这并不意味着应用程序完全不必关心数据拆分。这些数据库的最佳实践仍然写道，应用程序的大多数场景都尽可能避免分布式事务。
既然强一致事务的性能成本太高，我们可以反思一下，这种强一致的分布式事务是否真的需要。尤其是微服务拆分后，很多系统不太可能放在一个统一的数据库里。试图弱化一致性要求意味着灵活事务，放弃ACID(原子性、一致性、隔离性、持久性)，转而使用BASIC(基本可用、软状态、甚至一致)，如Saga、TCC、可靠消息保证最终一致性等。对于大规模、高并发的OLTP场景，我个人推荐使用灵活事务，而不是强一致性分布式事务。关于灵活交易，笔者之前写过一个技术组件，近几年也出现了一些新的模型和框架(比如阿里帮开源的Fescar)，这里就不赘述了，有空再单独写一篇。
哈和生活在不同的地方
主从模式不是最好的方式。即使是半同步复制，极端情况下也会有数据丢失的问题(半同步转异步)。目前业界公认的比较好的解决方案是基于paxos分布式一致性协议或者其他paxos如raft模式，Google Spanner、TiDB、cockcoachDB、OB都采用了这种方式。基于Paxos协议的多副本存储，遵循半写原则，支持自动选主，解决数据高可靠性问题，缩短故障转移时间，提高可用性，特别是减少运维工作量。这个方案技术上是成熟的，也是newsql database底层的标准。当然，这种方法也可以用在传统的关系数据库中。阿里、微信团队等。还改造了MySQL存储，以支持paxos多副本。MySQL也推出了正式版的MySQL Group Cluster，预计在不久的将来主从模式可能会成为历史。
“分布式一致性算法本身并不难，但在工程实践中，需要考虑很多例外，做很多优化。在生产级实现可靠、成熟的一致性协议并不容易。比如在实际使用中，必须转换成多paxos或者多raft，需要通过批处理和异步的方式减少网络、磁盘IO等开销。”
需要注意的是，很多newsql数据库厂商宣传基于paxos或raft协议可以实现【异地多活】。这其实有一个前提，就是异地之间的网络延迟不能太高。* *以银行“两地三中心”为例。异地距离千里，延迟达到几十毫秒。如果想多活，需要异地副本参与数据库日志过半确认。这样高的延迟对于OLTP系统来说几乎是不可接受的。
在数据库层面多做异地工作是一个美好的愿景，但目前对于距离带来的延迟还没有很好的规划。* *在与蚂蚁团队沟通之前，蚂蚁异地居住的方案是通过MQ同步在应用层双写事务信息，远程DC将事务信息存储在分布式缓存中。一旦发生远程切换，数据库同步中间件会通知数据延迟时间，应用会从缓存中读取交易信息，将这段时间涉及的业务对象，如用户、账户等列入黑名单，待数据同步赶上后，再将这些业务对象从黑名单中移除。因为双写不是全部数据库操作日志而只是事务信息，数据延迟只影响某段时间内的数据，是一种可靠的异地多活动方案。
此外，有些系统已经单元化，这也是paxos选择主控时要考虑的因素。这也是目前很多newsql数据库缺乏的功能。
尺度缩放和碎裂机制
Paxos算法解决了高可用性和高可靠性的问题，但没有解决规模横向扩展的问题，所以必须支持碎片化。newsql数据库天生内置了碎片机制，它会根据数据负载(磁盘使用率、写入速度等)自动识别热点。)的每个碎片，然后对碎片进行拆分、迁移和合并。这些流程无意识的应用，节省了大量DBA的运维工作量。以TiDB为例，它将数据切割成区域，如果区域达到64M，数据会自动迁移。
在数据库和表拆分模式中，拆分键、拆分模式(范围、取模、一致哈希或自定义路由表)、路由规则、拆分数据库表的数量、扩容模式等。应该在应用程序设计之初定义每个表的。与newsql database相比，这种模式给应用带来了很大的入侵性和复杂性，对于大多数系统来说也是一个很大的挑战。
“数据库拆分和表拆分模式还可以实现在线扩容。基本思路是通过异步复制先添加数据，然后设置只读完成路由切换，最后放开写操作。当然，这些只能通过中间件和数据库的配合来完成。”
这里有一个问题是newsql database的统一内置分片策略(比如tidb基于range)可能不是最高效的，因为它与域模型中的分区元素不一致，导致很多事务会产生分布式事务的结果。
比如银行的核心业务系统是面向客户的，也就是说大部分场景下客户表、客户的账户表、日流水表是一起写的。但是，如果每个表都按照主键范围进行分片，那么这个事务就无法在一个分片中完成，这在高频OLTP系统中会带来性能问题。
分布式SQL支持
常见的单片SQL，两者都能很好的支持。newsql Database由于位置和目标是一个公共数据库，所以支持的SQL会更加完整，包括跨片段的join、aggregation等复杂SQL。中间件模式大多是为应用需求而设计的，但是大部分也支持带split key的SQL，库表的遍历，单库连接，聚合，排序，分页等等。但是对跨库连接和聚合的支持还不够。newsql Database一般不支持存储过程、视图、外键等函数。，而中间件模式的底层是传统的关系数据库。如果这些函数只涉及一个库，那么它们很容易支持。NewSQL数据库往往选择兼容MySQL或PostgreSQL协议，所以SQL支持仅限于这两种。驱动模式等中间件往往只需要做简单的SQL解析、路由计算和SQL重写，因此可以支持更多种类的数据库SQL。
SQL支持的区别主要在于分布式SQL执行计划生成器。因为NewSQL数据库有底层数据的分布和统计信息，所以可以作为CBO，生成的执行计划效率更高。而在中间件模式中没有这些信息，往往是基于RBO (Rule-based-optimization)的，这也是为什么中间件模式一般不支持跨数据库的join，因为实现效率往往不高，所以还是留给应用来做比较好。
“这里也可以看出，中间件+子数据库、子表模式的架构风格体现了一种妥协和平衡，是面向应用的设计；而NewSQL数据库则要求更高，“包罗万象”。它是一个通用的底层技术软件，所以它的复杂度和技术门槛要高很多。”
存储引擎
传统关系数据库的存储引擎设计是面向磁盘的，并且大多基于B+树。+B-tree通过降低树的高度来减少随机读取，进而减少磁盘寻道次数，从而提高读取性能。但是大量的随机写入会导致树分裂，从而导致随机写入，导致写入性能下降。
NewSQL的底层存储引擎大多采用LSM。与B+树LSM相比，将对磁盘的随机写入改为顺序写入，大大提高了写入性能。但是，由于需要合并数据，LSM的读取性能比B+ tree差。总的来说，LSM更适合写作大于阅读的情况。当然，这只是从数据结构角度的比较。数据库实际实现时，读写性能会通过SSD、buffer、bloom filter等进行优化。，所以阅读成绩基本不会下降太多。
由于多个副本和分布式事务的成本，NewSQL数据的响应时间并不优于单个关系数据库SQL。但是由于集群的弹性扩展，整体QPS有了明显的提升，这也是为什么NewSQL数据库厂商说分布式数据库比单个SQL响应时间更注重吞吐量的原因。
成熟度和生态
分布式数据库是一种新的通用底层软件。准确的测量和评估需要一个多维度的测试模型，包括开发状态、使用情况、社区生态、监控和运营、外围支持工具、功能满意度、DBA人才、SQL兼容性、性能测试、高可用性测试、在线扩展、分布式事务、隔离级别、在线DDL等。NewSQL数据库的开发虽然经过了一定时间的测试，但大多集中在互联网和传统企业的非核心领域。
相比之下，传统的关系数据库已经发展多年，通过完整的评测，在成熟度、功能、性能、周边生态、风险控制、相关人才积累等方面都有明显的优势。同时与已建立的系统具有更好的兼容性。
对于互联网公司来说，数据量的压力越来越大，追求新技术的基因会更倾向于尝试NewSQL数据库。考虑数据库表拆分、应用转换、扩展和事务一致性等问题，是一个非常有吸引力的解决方案。对于银行等风险意识较高的传统企业来说，NewSQL数据库未来可能仍处于探索和审慎试点阶段。中间件+子数据库/子表模式，架构简单，技术门槛较低。虽然不像NewSQL数据库那么全功能，但是大部分场景的核心需求是拆分SQL的正确路由，这种功能性的中间件模型应对起来绰绰有余，在大部分OLTP场景下可以说是足够了。
如果以上有2个或3个是肯定的，那么可以考虑使用NewSQL数据库。虽然前期可能需要一定的学习，但这是数据库的发展方向，未来收入会更高，尤其是在互联网行业。随着数据量的快速增长，数据库划分和表格划分带来的痛苦会与日俱增。当然，选择NewSQL数据库要做好承担一定风险的准备。
如果这些问题大部分都是正面的，最好把数据库分成表格。软件领域很少有完美的解决方案，NewSQL数据库也不是数据分布式架构的银弹。相比较而言，数据库拆分和表拆分是一种成本更低、风险更小的方案。它最大程度的复用了传统的关系数据库生态，数据库拆分和表拆分后的大部分功能都可以通过中间件来满足，具有更强的定制能力。目前NewSQL数据库还没有完全成熟，可以说是上限低下限高的方案，尤其是传统行业的核心系统。如果您仍然打算将数据库用作黑盒产品，那么充分利用数据库和表将被认为是一个安全的选择。
