关于数据库:StoneDB-为何敢称业界唯一开源的-MySQL-原生-HTAP-数据库

时代在号召：HTAP Is On The Way

近些年，HTAP 正在受到人们越来越多的关注，Gartner 在 2014 年提出了 HTAP 这个术语和它的定义：

Hybrid transaction/analytical processing (HTAP) is an emerging application architecture that”breaks the wall“between transaction processing and analytics. It enables more informed and”in business real time“decision making.

在此之前，市面上根本是 OLTP 和 OLAP 数据库的天下。

OLTP

第一个无效的面向事务的数据库在 1970 / 1980 年代开始宽泛应用，它们起初被称为在线事务处理 (OLTP：Online Transaction Processing) 零碎，事务处理对单记录操作可靠性、准确性和速度要求十分高。

OLAP

随着数据量的增大，特地是互联网的倒退，OLTP 数据库的工作负载越来越大，同时剖析能力重大受限，咱们须要一个能十分疾速地在一个或多个数据库表中查找单个记录、多条记录或一种记录总数的数据库。OLAP 数据库同 OLTP 数据库在技术上也各奔前程。

然而，针对不同数据场景抉择对应的 TP / AP 零碎也带来了相应的难题，因为 TP 和 AP 不是一套零碎，在搭配应用时就会有数据传输的过程。在 一体化实时 HTAP 数据库 StoneDB，如何替换 MySQL 并实现近百倍性能晋升的文章中，咱们总结了业界通过 TP / ETL 或数据迁徙 / AP 构造来构建 HTAP 零碎存在的一些问题：

• 实时性低（TP + AP 零碎导致了数据孤岛，意味着 OLAP 数据库中的数据总是过期的，依据数据量的不同，数据提早通常从几小时到一周）。
• 企业保护两套数据库系统，治理和保护老本很高。

Gartner 的最新报告表明，传统的 TP + AP 架构将事务和剖析零碎离开，业务实时响应的高需要意味着应用“过期”的数据曾经不合时宜，商业时刻转瞬即逝。咱们须要创立一套更简略的体系结构，让 TP + AP 及 ETL 过程被单个数据库所取代，打消数据正本，将数据存储在 OLTP 引擎中进行事务处理，而后将数据复制到 OLAP 引擎（可能屡次）以进行剖析。随着软硬件基础设施和数据库技术的不断进步，属于 HTAP 数据库系统的时代曾经到来。

HTAP 数据库 StoneDB 为什么抉择拥抱 MySQL 生态?

StoneDB 并不心愿打造一个新的 StoneDB HTAP 生态。对于大部分数据库用户来说，最好的产品体验就是开箱即用，在一个黑盒零碎中实现业务的平滑迁徙，最大水平的升高用户学习老本和运维老本。而 MySQL 是世界上最风行的数据库，领有宏大和成熟的生态。

从 DB-Engines 排名上看到，MySQL 稳居第二，仅次于 Oracle。（下图来自 DB-Engines）

Shadowserver Foundation 在 5 月 31 日公布了一份全网的 MySQL 扫描报告，超过 360 万个 MySQL 实例裸露在公网。这只是裸露进去的，咱们能够推断，理论的装机量要远远大于这个数字。

IPv4 扫描

IPv6 扫描

业界惟一开源的 HTAP

咱们以存储架构为特色对业界最新的 HTAP 数据库做一个概览：

• 基于磁盘的行存储 + 分布式列存储：MySQL HeatWave
• 以行存储为主 + IMCS（内存列）：Oracle Database In-Memory（A dual format in-memory database）、SQL Server、DB2 BLU
• 分布式行存储 + 列存正本：SingleStore
• 以列存为主 + Delta Row Store：SAP HANA

从上述中能够看到，哪怕是最风行的开源数据库 MySQL，它的 HeatWave 也不开源。

StoneDB 就是心愿突破这种场面，在开源这条路线上做一个摸索，做一款由咱们中国人主导的开源 HTAP 数据库。

MySQL 原生

StoneDB 沿用并适配 MySQL sql 层，原生 100% 兼容 MySQL 协定和语法，咱们先看下 StoneDB 官网提供的  2.0 架构图：

架构图中相干术语介绍：

IMCDP：In Memory Column Data Pack 的缩写，存储在内存中的列数据包。

IMCDPI：In Memory Column Data Pack Index 的缩写，用于保留 IMCDP 的元数据，包含：

• 对象数量
• 列数量
• 映射行的信息
• 事务相干的数据

SMU：snapshot meta unit 的缩写。

在 StoneDB 2.0 的设计中，会推出相似 MySQL HeatWave 的 In-Memory Column Store 引擎：基于磁盘的 RDBMS（MySQL 8.0）和分布式内存列存储（IMCS）来实现 HTAP。

StoneDB 在不扭转 MySQL 原生的 OLTP 工作负载的前提下，深度集成 IMCS 集群以减速查询处理，事务在原生 MySQL 工作负载中执行。另外 StoneDB 会自行判断简单查问并将其下推到 IMCS 引擎进行减速解决，常常拜访的列将被加载到 IMCS 中，列数据从行存储中提取（由 InnoDB 并行加载到 IMCS），热数据驻留在 IMCS，冷数据落盘。

基于 IMCS 引擎咱们将实现 AP 负载的全内存计算：

1. 内存中数据组织形式：IMCDP + IMCDPI。
2. 数据加载形式：由 InnoDB 并行加载至 IMCS 中。
3. 数据的更新：当 TP 中的数据发生变化的时候，实时更新到 AP 引擎中。
4. 内存中数据长久化及零碎复原：为了减速复原的速度，咱们将内存中的数据长久化到咱们的 on-disk column store 中。

高效加载 TP 数据（From InnoDB）

上图是刚刚介绍了 StoneDB 2.0 架构中提到的从 InnoDB 并行加载数据的示意图。

与 HeatWave 采纳的计划相似，通过并行扫描 TP 中的数据（次要是 InnoDB 表），将须要加载的数据按 partition ,chunk, vector, tile 的数据组织形式并行的加载至 IMCS 中，每个 partion 中包含若干个 chunk，每个 chunk 中又蕴含若干个 vector，每个 vector 中包含了某列中的局部数据。同时，提供导入行为的监控能力，实时感知加载进度。在加载过程中通过非阻塞，无锁机制来实现高性能数据加载能力。

数据的更新

当 TP 中的数据发生变化后，将该项数据插入到 Population Buffer 中，并保护该数据的版本信息。当满足如下任一条件的时候，会将 Population Buffer 中的数据，根据版本信息顺次与内存中的数据合并为最新的版本数据：

1. 当咱们的 Population Buffer 曾经写满后，会执行一次 flush 动作，将 Population Buffer 中的数据更新到其对应的数据中。
2. 指定 merge 的工夫，例如：200ms。
3. 当 AP 中的负载发现其援用到了 TP 中的数据，其会被动的查看 Population Buffer 是否有最新的版本。如果有则合并造成最新数据。

   将来 2.0 其它的重点工作：

• 基于代价的新查问引擎：一个负载通明，具备更加高效，精确的代价模型将是咱们零碎性能的保障；并行查问和向量化等技术也将会失去继续的迭代。

• 分布式 Column Store AP 集群将在单机能力构建后，重点演进。

  最初

  除了 Gartner 的原始定义，咱们对 HTAP 更多视为一个集硬件、TP、AP、内存、云原生数据库技术、可扩大事务管理等多种性能的 新兴架构，使事务处理和剖析（HTAP）可能在同一套数据库上运行。

一个古代的 HTAP 数据库应该具备以下个性：

一致性：蕴含全面的 ACID 事务反对。数据密集型应用程序能够依附它来保证数据一致性，从而进步开发人员的速度和用户体验。

高可用性：无论后端产生什么，用户都能进行 7×24 小时的拜访。有一套外部机制来解决机器故障和网络问题等刹时和永久性故障（比方宕机 / 脑裂），并且提供数据复制和细粒度数据搁置性能，以确保数据高可用。并且提供滚动降级机制，防止集群扩大和架构降级等引发的停机对业务造成影响。

可扩展性：利用云原生技术，其计算和存储资源能够轻松扩大以应答业务的增长。按需且实时地增加新节点，以存储更多数据、解决更多读取和写入以及解决更简单的查问。

实时性：数据库应反对任何实时更新，从而实现细粒度索引和并行查问执行。为了确保及时性，数据库架构必须同时利用行存储和列存储，并基于查问优化器抉择最佳的数据拜访门路。