脑洞一下未来的数据库

对于未来的预测，总是被人津津乐道。

作为从事数据库行业多年的你，有没有想过未来的数据库会长什么样，能不能做到 DBAAS（database as a service），我们只需关注如何使用表达力丰富的 SQL 就行了？

OLTP 与 OLAP 是数据库应用中两个大类，而这两类应用如果放在一起，肯定是会打架的。吃过这个亏的团队很多，因为从应用角度来看，这些团队是分不清 OLTP 与 OLAP 的区别以及对应的最佳实践架构设计的。

而两者的区别，恰恰说明了他们不能共存，至少目前来说不行。

这篇文章来自于对 PingCAP CTO 黄东旭分享的理解。他原文讲了很多，提出了很多概念性的东西，也阐述了应用场景不同，而引发的架构调整。为了将火星语转成地球语，我试着讲讲其中的要点，原文在这里：

http://database.51cto.com/art/201903/592859.htm

看到这篇文章的时候，非常来劲。花了大约 3 小时，一点点扣其细节，加入自己的理解，在知识星球发布了零星的感悟。所以有时候，知识星球的内容会先于公众号。

数据库的产生，包括 NoSQL也是，都是为了解决某一类应用场景，踢开应用场景讲数据库的设计，肯定没有说服力。基于现在的应用数据规模，业务上，需要强调敏捷、微服务和中台化支持。数据新类型，典型的一种是热数据。热数据的事务、实时读取和写入以及支持规模比以往更大。离线数据仓库往往在走下坡路，意味着前些年热衷的 BI 报表技术，托拉拽的开发模式之后几年统统会被实时、流式计算取代。一波升级拉开帷幕。无论是自研、教育、培训以及相关周边产业都应该提前布局。

2008 年时还特别流行 ETL->Data Warehouse 架构。而 2018 年 MySQL/Oracle ->MQ->Hadoop->ELT->OLAP On Hadoop 已经非常成熟了。数据副本的概念，比以往任何时候都更加复杂。

（图来自于黄东旭的 PPT）

面向未来的数据库，技术之一：Log is the new database. 

重用 Log. 这一重要技术的基础是分布式存储。所以单机数据库技术的玩法，在未来将不再是重点。如果你目前所接触的数据库还是在使用单实例数据库，99%可以说，你在未来将失去竞争力。能挽回你一点余地的便是 oracle exaData 一体机或类似一体机的出现。如果未来的数据库硬件的设计，将分布式存储、分布式计算都统一到一个分布式引擎（HDFS, MapReduce 都是需要 YARN 的配置）或许你不用考虑太多网络的复杂度和失效性故障。但上千台的规模，一体机目前达不到这种算力。除非底层的存储和计算单元全部有了突破性的发展，单台计算机资源都做成树莓派这么小而美。

(取自 Google，著作权归原作者所有）

Log 作为复制协议或手段，大家都是不陌生的。但如果基于 MySQL, 还在使用 binlog 或者逻辑语句同步数据，黄旭东指出，这种做法还是比较 low 的。基于慕尼黑工业大学的一项实验室数据库测试，最快的同步数据不是用 SQL 或者逻辑日志，而是物理日志。TiDB 的 TiFlash 同步的正是 Raft 日志，而不是 binlog. Raft 是一种共识算法，讨论的是主从协议。网络不稳定就容易造成主从数据不一致、数据有延迟、节点故障丢失数据等一系列问题，如何解决这些问题，业界已经有很多方法，Raft 就是一种，还有就是 Paxos, Zookeeper 等

面向未来的第二个数据库技术：Vectorized, 向量化。

其实这不是什么新鲜事。SQL Server, Oracle 都已经实现。就是列式存储。列式存储能显著提高计算效率，随机访问的缺点用更大的数据块（底大）来弥补了。之前我们一直会用碎片化整理来提高访问效率，而列存储用尽可能多的地方一次性容纳更多的数据来替换随机访问带来的计算效率问题。如今列式存储都内存化了，压缩技术更有效率，所以计算更快了。向量化计算，是有特定使用场景的，那就是数据仓库中常用的聚合运算。OLTP 还是随机访问更靠谱，效率更高，因为一次性访问的数据量有限。

面向未来的数据库，技术之三：OLTP 与 OLAP 的隔离，且是物理隔离。

OLAP 是非常吃资源的应用模式，动辄 TB 级的操作，肯定不能与 OLTP 同台计算，只能通过 ETL 同步数据。千万级的应用，一旦两边的处理速度不同步，就会导致消息积压，比如 kafka 作为中间件，消息两边处理不平衡，OLTP 为 200W 级并发，而 OLAP 只能接受 100W，那么 100W 就会剩下，积压，此时就受制于 kafka 的吞吐。要突破这份限制，只能发明更有效的协议，比如 Raft

（图来源于黄旭东的 PPT）

面向未来的数据库，技术之四：SIMD. 

Single Instruction, Multiple Data. 单指令多数据计算。黄旭东认为，IO 在将来不会是瓶颈，而 CPU/GPU 即将成为瓶颈，而 GPU 则可以最大程度的辅助 CPU.

面向未来的数据技术，第五点：动态数据扩容。

数据分片一直无法克服的问题是数据倾斜。目前的做法都是预先确定 router, 一旦某个业务 router 规则需要实时变化，这种预先制定的规则就要被打破，否则就容易有数据倾斜问题。这类问题其实不需要 AI 这么高大上的概念来解决，做好历史记录，动态分片即可。

以上五点我觉得是最重要的基石。而这些特性或多或少已经在各种数据库中实现了，但没有一种数据库可以全部拥有这些功能。流行的 DBAAS 可以达到这些效果，但也是多种 XAAS 的集成而已。

再次声明：以上内容框架来自于黄旭东（PingCAP CTO), 个人加入了自己的理解和实践中应用的一些技术细节的阐述。

猜你喜欢：

写文章的这些年

如何让你的 SQL 执行的飞起？

一次 BO 报表引发的数据库宕机要点分析