在今年的第七届中国开源年会上，StoneDB 团队在大数据分论坛发表了《HTAP 的下一步？SoTP 初探》主题演讲，在本次演讲中，我们首次正式对外阐释了“SoTP 数据库”的技术理念，本系列是演讲实录+小编补充版，权当抛砖引玉，供大家批评指正。由于内容比较多，本文为第一章节，主要讲讲我们提 SoTP 的背景：From Big to Small and Wide Data。

HTAP 的起源、流派和迷思

HTAP 起源

我们首先从起源讲起，不过由于是公开演讲，考虑到一些听众是小白，所以这里主要是从一个比较宏观的关系型数据库行业发展历史视角来看的，关于 HTAP 更具体的技术和商业的起源背景，可以看看 StoneDB 首席架构师李浩老师写的这篇文章：HTAP 的背景。

众所周知，图灵奖（Turing Award）算是计算机领域里最高的一个奖项，截至今日，因为在数据库领域有杰出贡献而获得图灵奖的只有四位，分别是：

1. 查尔斯·巴赫曼（CharlesW. Bachman），1973 年获奖，设计并开发了网状数据库管理系统 IDS，推动了数据库标准的制定，包括网状数据库模型、数据定义和数据操纵语言的规范说明（通俗来讲，是他第一次提出了数据库这么个东西，可以说是咱们的祖师爷）；
2. 埃德加·弗兰克·科德（Edgar Frank Codd），1981 年获奖，提出了关系数据库模型（关系型数据库经久不衰，目前依然占据市场最多的份额）；
3. 詹姆斯·古瑞（James Gray），1998 年获奖，主要是在大型数据库和事务处理技术上的突破（重点研究如何保障数据的完整性、安全性、并行性，以及故障恢复，曾担任 VLDB 期刊的主编）；
4. 迈克尔·斯通布雷克（Michael Stonebraker），2014 年获奖，现代数据库系统的概念和实践方面的基础性贡献（领导了影响力巨大的奠基性数据库 Ingres 的开发，也是最早提倡发展列存数据库的大佬之一）。

除了这四位数据库界公认的大佬外，也有其他大牛，比如：

• 1988 年，为解决数据集成问题，IBM 的 2 位研究员 Barry Devlin 和 Paul Murphy，创造性地提出了数据仓库（Data Warehouse）的概念；
• 1992 年，比尔·恩门（Bill Inmon）给出了数据仓库的定义。数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理中的决策制定；
• 1993 年，E.F.Codd 提出 OLAP，以及 OLAP 12 条准则。
• ......

能看到，早些年的数据库界名人们，并没有太多中国人士，和操作系统一样，中国在这类基础软件上的起步和投入都不算太早，这也是数据库领域目前成为我国 35 个“卡脖子”技术之一的原因吧。

我这里要指出的是——相信那些在数据库界深耕数十年的朋友们应该早就感受到了——仿佛，自从上述这些大佬奠定了关系型数据库发展的总基调后，后续的几十年里，就再没看到什么轰动一时的创新了，或者说，影响力能达到以上这些人士的数据库专家学者也没那么多了。那段时间，关系型数据库的热点话题好像从百家争鸣陷入了一个相对沉寂的时期，当然，后面也断断续续有一些新的技术热点，不过，能像上面这些大佬一样直接奠定一个学科或者理论的，就比较少了。

万籁“俱寂”时，一家知名 IT 研究与顾问咨询机构的发声，给关系型数据库这个平静的池塘丢了颗巨石：2014 年，Gartner 正式提出了 HTAP 这个概念。

Gartner’s definition in 2014: utilizes in-memory computing technologies to enable concurrent analytical and transaction processing on the same in-memory data store.

Gartner’s new definition in 2018: supports weaving analytical and transaction processing techniques together as needed to accomplish the business task.

可以看到，Gartner 重点强调了使用内存技术实现 HTAP 的可行性，并表示 HTAP 将为巨大的业务创新创造机会，增量市场空间巨大。

一石卷起千层浪，陷入半沉寂的关系型数据库技术，好像迎来了春天。那个时候，商业智能（BI）已经开始广泛渗入到众多企业的营销业务体系里了，处理数据的业务分析部门对实时处理和运维最简化的需求越来越重要，HTAP 方案的提出自然迅速地引起了行业的强势关注，因为这玩意儿光是听起来就省心省力，诱惑很大。

我们正在做的 StoneDB，就是对标 Oracle MySQL HeatWave 的一款开源版实时一体化 HTAP 数据库。

HTAP 流派

上图是 HTAP 数据库的发展时间线，我们这里再举几个大家耳熟能详的企业：像数据库巨头 Oracle 去年就推出了 MySQL HeatWave，没错，Oracle 官方已经明确表示了，做 HeatWave 的目的就是为了支持 HTAP，在最近的 Oracle CloudWorld 大会上还官宣了 MySQL HeatWave Lakehouse；Google 在 HTAP 上也动作频频，除了搞 F1 Lightning 以外，在今年 5 月 12 日的 Google I/O 2022 开发者大会还宣布了云原生 HTAP 数据库 AlloyDB for PostgreSQL；紧接着，所有云数仓都想打的知名厂商 SnowFlake 也在 6 月 14 日的用户大会 Snowflake Summit 2022 上官宣正式推出 HTAP 存储引擎 Unistore；数据库独角兽SingleStore（前身为 MemSQL） 也早就在 HTAP 领域上频频发声，顶会论文都发了。国际上的这些大厂和独角兽都在搞 HTAP，国内的更不用说了，阿里、百度、腾讯、华为、字节和众多新兴创业公司（包括咱们 StoneDB），以及老牌数据库厂商都开始宣传自己的一些产品可以实现或者主攻 HTAP。Gartner 之前在报告里预测说，到 2024 年，HTAP 数据库会被广泛用到各行各业中，现在看来，真的是有这种势头了。

显而易见，HTAP 这俩马车的车轮已经压在了数据库行业的历史轨迹上，正在滚滚向前，势不可挡。但是，随着越来越多的厂商正式加入赛道，对于 HTAP 架构的技术实现，自然产生了一些分化。

我们之前在文章《深度干货！一篇 Paper 带您读懂 HTAP》中有做介绍，这篇报告里提到，至少有四种不同的架构方式可以实现 HTAP。

目前 HTAP 大致有四种实现方式：

• 方案 1（一套系统一套存储）：在一个系统里用一种数据格式满足两种业务需求；

• 方案 2（一套系统两套存储）：一个系统里同时存在行存储和列存储，行存储上的更新会定期导入到列存储里转换成列存储格式；

• 方案 3（两套系统两套存储）：系统里同时存在 OLTP 与 OLAP 两套引擎，分别写入和读取行存储和列存储；

• 方案 4（多套系统松耦合）：不同的异构系统之间，通过独立的插件服务对数据进行准实时同步，对外呈现 HTAP 能力。

下面这张表图是我们对这四种架构方案的一个简单的综合盘点