如何看待NewSQL+MPP的云数据库架构？
众所周知，关系型数据库自System R确立了关系模型+SQL+事务处理这老三样以来，统治了数据处理超过30年，直到2000年代初。当时，一方面互联网的快速发展使得大型网络公司对数据处理能力的需求急剧增加，另一方面传统关系数据库无法在共享内存的主流体系上有效scale-up，迫使Google等开发出以Google老三篇（GFS+MapReduce+BigTable）为代表的第一代大数据系统NoSQL以追求scale-out的性能扩展。到了2012年，Google Spanner将大数据推进到NewSQL第二代。Spanner创新的为数据处理系统添加了基于物理时钟的全球分布部署能力和基于共识协议（Paxos）的高可靠性HA模块，使用简单的Commit Wait处理Clock Skew，使得该系统具有近乎无限的scale-out能力并同时实现强一致，不过该系统依赖原子钟和GPS时钟同步。Cockroach DB是Spanner的首个开源克隆，采用了基于UNIX时钟和Lamport时钟的混合时钟HLC，同时采用了类似XiangYao YU的Tictoc的MVTO并使用Retry Read来处理大的Clock Skew，使其能在市售硬件和大抖动的NTP上实现全球分布部署，另外简化共识协议，以Raft实现HA。Yugabyte DB是另一个Spanner开源克隆，它同样使用HLC和Raft，不过在并发控制算法上使用了常规的MV2PL+SI组合，处理Clock Skew的方法除了Retry Read，可以采用来自Clock-SI的Read Old，使得系统更简单易懂。另一方面，数据库厂商也在内存数据库，MPP和Column Store这三个主流方向进行了长足发展。 我认为数据库与分布计算经过单机数据库到NoSQL的合久必分，又经过NewSQL的技术积累，将会分久必合。其后更多是商业驱动，纯粹的性能驱动的NoSQL市场已趋于饱和，未来市场的发展方向更多的将是功能和性价比驱动。最能适应未来市场的数据平台将会是云上的全球分布的HTAP数据库，它将结合MPP数据库的并发计划并发执行技术与New SQL的基于时钟的全球分布部署能力和基于共识协议的HA，能在全球部署下支持HTAP应用，做到One size fits most。典型应用是用以替换原有的单机或集群TP系统，以本地TP为主，分布TP为辅，并增加分布AP能力，可直接访问分布的数据无需ETL。上述构架的优点是在单一系统内，以尽可能小的成本满足绝大多数客户的多样的数据处理需求，其瓶颈是并发控制。Google Spanner使用的2PL并发能力太低无法支撑超大规模的HTAP workload，在Spanner之上的F1被迫使用TP+AP的双系统来实现HTAP，从而大大增加了成本。Cockroach DB为了处理大的Clock Skew，采用MVTO也就继承了TO的化读为写的缺点，新版本甚至放弃了SI，只专注OLTP。我认为要支撑单系统HTAP workload就必须处理好源自AP的大谓词读集和源自TP的小写集之间的冲突。MV2PL能处理只读AP，但读写AP的大读集会长时间阻塞TP，OCC则会让TP不断的abort长AP造成饥渴，而TO的化读为写会把大读集变成大写集。真正实用的强一致分布HTAP并发控制和单机时一样只有SI。不过SI有两点缺点，1是时间戳分配这个单点瓶颈，2是write skew。 Silo，Tictoc，Cicada等现代算法通过追踪事务间依赖来确定事务先后最后反推时间戳，从而缓解时间戳分配的单点瓶颈。上海的一些学者把这技术应用到SI上，我认为这不是最佳方案，因为统一时间戳分配既是SI的性能瓶颈也是SI低运行开销和其他优良特性的源泉，解决之道应是硬件优化。 基于物理时钟和混合时钟的NewSQL在节点内使用中心时钟，在节点间则同步与物理时钟，做到了很好的平衡，既能做的全球分布部署，又缓解了基于中心节点的传统集群系统的单点瓶颈，TP在各个节点都有独立的本地时钟源来支撑高吞吐量。挑战在于分布的并发控制算法必须增强以处理各节点独立时钟源间的clock skew,从上述对Spanner/CockroachDB/YugabyteDB的简单分析可以看出Clock-SI的read old具有明显优势。未来系统的性能将很大程度上取决于硬件对物理时钟或混合时钟的优化程度，这一点上云数据库可以在数据中心内以一个原子钟和局部时钟网覆盖所有局部服务器，提供远高于NTP的时钟精度。单系统HTAP可以支持TP和AP并发运行但不可能同时对两者优化，客户未来可以根据自己的偏好选择合适的存储引擎。 SI在HTAP和分布并发上都有巨大优势而被工业界广泛采用，所以解决write skew，并将SI序列化是大家的梦想。SSI的出现一度让人看到希望，然而十多年后SSI并未在商业系统中大规模应用。Oracle和SAP HANA仍然只支持SI，不提供真正的序列化，MS SQL SERVER同时提供SI和MV2PL。只有Postgresql采用了SSI（FoundationDB的SSI实际上是下面的Hyper2/OSSI算法），而Greenplum和YugabyteDB这两个基于Postgresql的数据库甚至将自带的SSI改回2PL。真正原因，SSI的原创Fakete教授在2013年对微软的内部报告解释的很清楚，SSI无法scale-up。不单基于锁的SSI不行，基于SGT的PSSI也不行，在32核时，两者相对SI的性能损失已经高达80%。其后TianZheng Wang的SSN虽然理论上很漂亮，但是基于TO的ERMIA算法实现同样运行时空开销太大。Hyper2/OSSI将OCC直接用在SI上，虽能序列化，但同时失去SI大部分优点，退化为OCC一样的高abort rate，实践中只能取消写并发。我个人基于对前述算法的仔细分析，最终找到了能将SI序列化的Scalable算法，为未来全球分布式HTAP应用建立了一个可行的道路。 我对未来系统的实现设想是这样。步骤1，将成熟MPP数据库（Greenplum）与成熟NewSQL(YugabyteDB)结合，搭建一个全球分布基于SI的HTAP数据库原型，并将SI序列化。步骤2.将原型各个软件子系统充分优化。重点在存储系统，2PC与Paxos/Raft融合，管理智能化等。步骤3，硬软结合的进一步优化。 现在这个技术路线已经被PolarDB公开并将开源，由于其进入门槛很低（MPP和NewSQL都有成熟的基于Postgresql的开源实现）同时综合性价比高，各大厂商将会很快跟进成为市场主流。PolarDB率先发布并开源是很好的抢占市场的商业策略，接下来就看友商特别是华为的应对了，华为实际上有NewSQL CockroachDB的原始股。