分布式数据库的架构分析.docx

?

?

分布式数据库的架构分析

?

?

【摘要】在分布式关系型数据库领域，没有一个真正科学的普适性的标准，可以评判某个数据库的好坏。虽然如此，我们还是可以从较为理性的角度来分析某个分布式数据库的好坏。

Oracle12C正式发布前，我曾经参加过一个中国企业用户与Oracle研发副总裁的圆桌会议，主要是提出国内企业级用户对Oracle数据库的一些需求，供Oracle下一个版本增加功能时参考。当时会上提出的很多需求后来在19c/20c里都看到了响应，不过这些还不是让我印象最深的，印象最深的是针对Oracle12CSHARDING功能的讨论。

当时我问Oracle12C的MPP功能发展的方向是什么，当时与会的Oracle研发部门的人首先纠正了我的问题，Oracle12C推出的只是SHARDING数据库，而不是MPP数据库。SHARDING主要面向的是高并发写入，业务逻辑相对简单的应用类型，而不是面向复杂的数据仓库计算的，因此这个功能不能被称为MPP。我继续追问Oracle今后是否会把目前的SHARDING升级为完全意义上的MPP，Oracle方面的回答让我有点意外，他们认为对于一般的OLTP，OracleRAC已经完全能胜任，在12C中推出的inmemorydb特性可以解决以前Oracle在OLAP方面的不足，SHARDING只是用于解决未来物联网等应用的需求。Oracle不会推出新的MPP数据库，因为这意味着重新写一个新的ORACLE出来，而Oracle的技术储备并不足够。

虽然Oracle的技术储备并不足够，这并不能阻止大量的分布式数据库蜂拥而出。目前市场上的分布式数据库已经有上百个了，在这些产品之间做选型确实是一个十分具有挑战的工作。更可怕的是，几乎所有的数据库厂商都告诉你，他们的数据库是最优秀的，最符合你需求的。这让你无从拒绝，因为在分布式关系型数据库领域，没有一个真正科学的普适性的标准，可以评判某个数据库的好坏。虽然如此，我们还是可以从较为理性的角度来分析某个分布式数据库的好坏。实际上我们不需要去分辨RAFT还是PASOX哪个共优秀更高效，而需要从数据库的最为基本的原理去分析就可以了。

首先我们要考虑的是存储引擎。存储引擎是数据库娘胎里就带出来的基本属性，一旦存储引擎确定了，那么数据库的一些特性基本上也就确定了。2017年在贵阳数博会上，我遇到了某厂商的CTO，他负责数据库核心研发团队。当时他们的研发团队的一个负责人和我们为了一个电力应用场景上某数据库的优化已经一起工作了两个多月了。谈到这个项目，他深有感触，他以前觉得自己已经能够支撑各种复杂的应用场景了，通过这两个月的测试他们发现以前他们在美国遇到的场景都是大并发量写入后的延时分析，而这种高并发写入后的准实时分析场景，他们的基于HBASE的存储引擎已经难以支撑了。通过这个项目他认识到，要想真正实现HTAP，必须重写存储引擎。通过这个例子，我想要表达的意思是，我们想选择适合于我们应用场景的分布式数据库，必须首先了解这个分布式数据库的存储引擎，以及存储引擎的特点是什么。基于HEAP存储的、B-TREE存储的和LSM-TREE存储的引擎其优点和缺点都十分明显。有一句话说的很清楚：天底下没有免费的午餐。在某个地方特别优秀的存储引擎，可能就会在另外一个地方差的一塌糊涂，这一点一定要做好思想准备。堆表高并发下的热块冲突会十分严重，B-TREE存储批量装载性能受到影响，LSM-TREE在比较合并时的开销过大，这些都是从娘胎里带出来的缺陷，你很难说可以轻松消解的。PingCap的架构师是一个具有整体思维的好架构师，在TiDB上的一些设计都是在弥补LSM-TREE上的不足。使用SSD盘、每个节点不超过16TB的存储容量、使用TiSPARK引擎来处理一些复杂的分析场景等，无不是对LSM-TREE的优缺点十分了解后的弥补措施。特别是TiFlash副本的推出，让TiDB向HATP走出了十分坚实的一步。不过这种架构也不是完美的，很多功能的代价是成本，这种架构决定了，TiDB对硬件的要求极高。

其次我们要考虑分布式事务的实现方式，因为没有一个分布式数据库厂商会主动和你深入探讨这方面的问题。无论厂家如何说自己的分布式事务如何完美，如何高性能，有一个事实是必须接受的，基于网络通讯的分布式事务，其效率比起内存中实现的事务锁的效率肯定是低了不止一个数量级的。因此分布式数据库必须通过一定的算法来解决这个问题。实际上可用的方法也不多，最常用的分布式事务的解决方案就是全局事务号和两阶段提交。很多分布式数据库的高性能指标都是在基于2PC的“乐观锁”场景下获得的。乐观锁可以解决分布式事务中的强一致性要求所带来的性能损失，不过乐观锁对于用惯了集中式通用数据库的我们会有些不习惯。因为在修改数据时