中国的发展趋势十年_聊聊过去十年，数据库技术的发展趋势

黄徐东信息Q

作者，黄徐东

回顾过去几年，分布式系统领域出现了许多新事物，特别是云和人工智能的兴起，将这个过去并不真正性感的领域带到了前沿。在此期间，许多新技术和新思想诞生了，使这个古老的领域恢复了生机。站在21世纪10年代的末尾，我想和你们谈谈分布式系统令人兴奋的发展，以及一些关于21世纪20年代的大胆推测。

无论哪个时代，存储都是一个重要的话题。今天我们先来谈谈数据库。在过去几年里，数据库技术出现了几个明显的趋势。

存储和计算的进一步分离在我看来，存储和计算分离的最早尝试是雪花。雪花团队2016年发表的论文《雪花弹性数据仓库》(The雪花弹性数据仓库)是我近年来读过的最好的大数据相关论文之一，特别推荐阅读。雪花架构的关键点是在无状态计算节点+中间缓存层+S3上存储数据。计算没有耦合到缓存层，这与云的思想非常一致。从AWS最近推出的红移冷热分离框架来看，AWS也认识到雪花是先进生产力的发展方向。此外，近年来关注数据库的朋友们不禁会注意到奥罗拉。与雪花不同，奥罗拉应该是第一个将存储和计算分离的思想应用于OLTP数据库的产品，并大放异彩。奥罗拉的成功在于降低了从Binlog到重做日志的数据复制粒度，大大降低了复制链路上的输入输出放大此外，MySQL在前端被重用，基本实现了100%的应用层MySQL语法兼容性，并托管操作和维护。同时，传统MySQL的应用范围进一步扩大。在中小型数据量场景中，这是一个非常无忧的方案虽然奥罗拉取得了商业上的成功，但我认为技术上没有多少创新。熟悉甲骨文的朋友第一次看到奥罗拉的架构时，可能会觉得自己很熟悉RAC。甲骨文在大约十年前使用了类似的方案，甚至完美地解决了缓存一致性的问题。此外，极光的多主机还有很长的路要走。从最近关于“重塑”的声明来看，极光多主机的主要场景对于单个作家来说仍然是一个高度可用的方案。根本原因是目前多作者采用乐观冲突检测。冲突检测的粒度为页面(Page)，当冲突率较高时，会导致性能大幅下降。

我认为极光是一个很好的解决方案，可以满足90%的公共云互联网用户的需求:100%的MySQL兼容，不太关心一致性，读得比写得多，完全托管但与此同时，奥罗拉的架构决定放弃10%有极端需求的用户，如全球ACID事务+强一致性、超大规模(超100 t，业务不方便拆卸库)，需要实时复杂的OLAP。我认为唯一的出路是类似TiDB的无共享设计。作为一名分布式系统工程师，我觉得任何不能横向扩展的架构都不那么优雅。

分布式数据库走上舞台。酸性全面回到

。回想几年前，当NoSQL处于巅峰时，每个人都想用NoSQL来改造所有的系统。尽管可用性、可伸缩性和性能都很好，但大多数NoSQL系统放弃了数据库中一些最重要的东西，如ACID约束、SQL等。NoSQL的主要驱动力是互联网公司。互联网公司的简单业务和超级强大的工程师团队使得NoSQL有可能简单地用一些工具来解决问题。然而，近年来，人们逐渐发现下垂的果实基本上消失了，剩下的都是硬骨头。

最好的例子是谷歌作为NoSQL创始人的第一份新闻季刊(扳手和F1)。在后移动时代，业务变得越来越复杂，要求越来越实时，同时对数据的需求也越来越强。尤其是对一些金融机构来说，一方面，产品正面临互联网；另一方面，无论是出于法规要求还是业务需求，ACID都很难绕过。更现实的是，大多数传统公司的人才供应不如顶级互联网公司。大量的历史系统是基于SQL开发的，完全迁移到NoSQL是绝对不现实的。

在这种背景下，我认为分布式关系数据库是我们这一代人在开源数据库市场上最后缺失的一部分，并最终得到普及。由于篇幅的原因，我不会介绍这背后的许多细节。我推荐阅读PingCAP TiFlash技术负责人马小宇从大数据到数据库的一篇文章，这篇文章对这个话题有很好的阐述。

云基础架构和数据库的进一步集成

在过去几十年中，数据库开发人员一直在独立行动，就好像操作系统下的一切都是一个黑匣子。这个假设也是正确的，毕竟，大多数软件开发人员没有硬件背景。此外，如果一个方案过于绑定到硬件和底层基础设施，它必然很难成为事实上的标准，而且硬件不利于调试和更新，成本太高，这就是为什么我对定制一体机不太感兴趣。然而，云的出现已经把IaaS的基本功能变成了一个可重用的软件单元。我可以在云中按需租用计算能力和服务，这将为数据库开发人员设计系统带来更多可能性。举几个例子:

1，扳手的本地真实时间应用程序接口依赖原子钟和全球定位系统时钟，如果纯粹由软件实现的话。有很多东西需要牺牲(例如，CockroachDB的HLC和TiDB的改进过滤器模型都是基于软件时钟的事务模型)然而，从长远来看，AWS和GCP将提供与TrueTime类似的高精度时钟服务，这样我们就可以更好地实现低延迟的长距离分布式事务。

2。借助Fargate+EKS轻量级容器+托管K8s服务，数据库可以应对突发热点和小表读取的场景(这种场景几乎是无共享架构中的一个长期问题)。例如，在TiDB中，Raft Learner可以与云的自动缩放器合作，在新容器中快速创建只读副本，而不是只通过3个副本提供服务。例如，将动态激活10个pod来创建热数据的Raft副本(这是我们将TiKV数据片段设计得如此之小的一个重要原因)。在处理突发的读取流量后，这些容器将被销毁成3个副本。

3，冷热数据分离，这很容易理解，将不会常用的数据碎片、分析拷贝、数据备份放在S3，大大降低成本

4，RDMA/中央处理器/超级计算即服务，只要开放应用编程接口，云上任何硬件级别的改进都会给软件开发人员带来新的好处。仍然有许多

的例子，所以我不会一一列举。总之，我认为云服务应用编程接口的能力将与过去的代码标准库一样，每个人都可以依赖。尽管公共云的服务水平协议仍然不理想，但从长远来看，它将越来越完善。那么，数据库的未来在哪里？它是更加垂直还是走向统一？关于这个问题，我同意这个世界上没有灵丹妙药，但我并不像我的偶像沃格尔斯博士那样悲观，我相信未来是一个支离破碎的世界(AWS希望为每个细分的场景设计一个数据库)过度分割会增加不同系统中数据流动的成本。解决这个问题有两个关键:

数据产品应该划分成什么粒度？

个用户能不知道他们背后发生了什么吗？第一个问题

没有明确的答案，但我认为它肯定没有尽可能好，这与工作量有关，例如，如果没有这么多数据，直接在MySQL或PostgreSQL上运行分析查询实际上根本没有问题，就没有必要使用红移虽然没有直接的答案，但我隐约觉得第一个问题和第二个问题密切相关。毕竟，没有什么灵丹妙药，就像OLAP在列存储引擎上运行必须比行存储引擎快，但它实际上可以成为用户的SQL接口。

SQL是一种非常好的语言，它只描述用户的意图，并且完全独立于实现。对于数据库，它实际上可以在SQL层之后进行分段。在TiDB中，我们引入TiFlash作为一个很好的例子动机很简单:

1，用户不是数据库专家，你不能期望用户在正确的时间100%使用正确的数据库，并使用正确的

2，数据之间的同步可以在一个系统下保持尽可能多的信息。例如，TiFlash可以将MVCC版本的事务保存在TiDB中，TiFlash的数据同步粒度可以小到Raft日志级别。其他新的功能仍然可以由SQL接口提供，比如全文检索，也可以用SQL简洁地表达出来。在这里我不会一个接一个地开始。我坚信这个系统必须朝着更加智能和易于使用的方向发展。现在是21世纪，你是想每天都带着诺基亚和相机，还是想直接使用手机？作者

介绍了

黄徐东，分布式系统专家、架构师和开源软件的作者。平冠联合创始人兼首席技术官，著名开源项目Codis/TiDB/TiKV主要作者，曾在微软亚洲研究院、网易有道和豆荚工作过他于2015年开始创业，并成立了PingCAP。他致力于下一代开源分布式数据库的研究和开发。他擅长分布式存储系统的设计和实现，以及高度并发后端架构的设计。

推荐阅读

经常会问一个问题，为什么我们需要分发？在很大程度上，这可能是必要的如果摩尔定律没有失败，如果互联网不断增长的计算和存储需求可以通过低成本硬件解决，我们不需要分发吗？

在过去的20到30年里，软件工程师拯救了自己，并进行了一场伟大的革命。分布式技术的发展深刻地改变了我们的编程模式和我们对软件的看法。通过无处不在的X86或Arm机器，建立了无限扩展的计算和存储容量，这是软件工程师最浪漫的自我拯救。

9 Pingcap和InfoQ共同策划并制作了“分布式系统中的先进技术”这一主题。朱安兴、脉冲星、伟忠银行、UCloud、智湖、壳牌黄金服务等技术团队应邀参与项目，从数据库、硬件、测试、运行维护等方面共同探索这一古老领域的新活力。