关于数据库:推荐-一体化实时-HTAP-数据库-StoneDB如何替换-MySQL-并实现近百倍性能提升

本文首发于 2022-07-06 09:10:34

举荐语

本文为数据库圈内好友 高日耀 首发于“CSDN 微信公众号”的文章。

最近几年基于 PostgreSQL 开发的国产数据库如雨后春笋般涌现，而受限于 MySQL 的 GPL Licence（感兴趣的可移步我的博文《技术分享 | 如何为你的代码抉择一个适合的开源协定？》），二次开发必须开源，这导致基于 MySQL 开发的国产数据库绝对较少（比方：万里开源的 GreatSQL），因而，当据说 StoneDB 开源的音讯时，我集体还是很兴奋的。

废话不多说，以下为注释。

前言

家喻户晓，MySQL 是世界上最风行的 OLTP 数据库之一，截至 2022 年它在整个数据库行业的市场占有率达到了 43.04%（数据起源：Slintel 网站）。许多企业将各种业务零碎利用于 MySQL 上。然而，随着企业数据量的一直减少，除了在线业务逻辑的读写，数据库还要面对日益简单的剖析性业务需要，比方 BI 报表、可视化、大数据利用等。而 MySQL 原生的架构（基于流式迭代器模型 Volcano Iterator 的执行引擎，没有利用古代多核 CPU 并行处理能力，按行存储的存储引擎）在 AP 场景中存在人造的缺点。针对这种状况，为了补足 MySQL 的 AP 能力缺点，业内围绕 MySQL 做了很多解决方案。次要是围绕 MySQL 搭建的异构 HTAP 数据库系统。

什么是 HTAP？在 2014 年，Gartner 给出了 HTAP 的严格定义，其目标是为了突破，事务型负载和剖析型负载之间的“壁垒”, 使零碎可能反对更多的“数据”在两个零碎之间流动，以及以这些数据为根底的“实时业务”的决策。

传统架构模式下，为了解决同时解决 TP 负载和 AP 负载的问题，通常采纳一套 TP 零碎加上一套 AP 零碎的形式，TP 和 AP 之间通过 ETL 的形式进行数据同步的来满足业务对实时性的需要，这也是以后业界搭建 HTAP 的支流计划。

业内围绕 MySQL 搭建 HTAP 支流计划

咱们先来看看业界支流的基于 MySQL 的 HTAP 解决方案。

1. MySQL + Hadoop

借助 Hadoop 体系，将 MySQL 的业务数据，通过 ETL 工具同步至开源大数据系统（如 Hive，Hadoop，Spark 等）搭建的数据仓库，再基于该数仓做数据分析。

2. MySQL + 数据湖

借助数据湖平台，通过 ETL 工具将 MySQL 数据同步至数据湖，再基于数据湖进行数据、报表、BI 等剖析。

3. MySQL + ClickHouse/Greenplum

通过 ETL 等数据迁徙工具将 MySQL 数据迁徙到 ClickHouse/Greenplum 做剖析。

ClickHouse 官网在 20 年下半年公布了社区版 MaterializeMySQL 引擎，能够将 ClickHouse 作为 MySQL 的一个从库同步主节点数据，除了 ETL 工具，业内也有间接将 ClickHouse 作为一个 MySQL 从库间接挂载的计划。

4. 基于多正本的 Divergent Design

比方兼容 MySQL 协定的 TiDB，在一个 Raft Group 其中一个正本上，通过自研列式存储 (TiFlash) 来响应简单 AP 查问，并通过 TiDB 的智能路由性能来主动选取数据源，实现一套分布式 HTAP 数据库系统，在分布式畛域这块做的是比拟好的。

以上计划存在的问题

以上几种 HTAP 解决方案，尽管是行业内的支流，但仍然存在着一些问题，包含：

1. 零碎架构过重，运维复杂度较高；
2. TP 数据通过 ETL 形式同步到 AP 零碎中，数据延时较大，难以满足服务对剖析的实时性要求；
3. 异构数据库组合，技术上须要保护两套数据库系统，波及到泛滥技术栈，对技术人员要求较高；
4. NewSQL 零碎，须要进行各种兼容性适配，适配工作会比较复杂，对技术人员要求也比拟高。

为此，咱们带来了在 HTAP 方面的解决方案：StoneDB，一款开源的一体化实时 HTAP 数据库。

StoneDB：齐全兼容 MySQL 生态的一体化行列混合存储 HTAP 数据库

StoneDB 是一款刚刚开源的基于原生 MySQL 的一体化实时 HTAP 数据库，用国内首创的一体化行列混存架构，以极低成本实现高性能的实时 HTAP。

StoneDB 采纳一体化的行列混合存储，跟分布式多正本 Divergent Design 做法不同，是在同一个数据库实例中采纳行列混合存储的计划，高度集成，运维复杂度较低，用户应用体验更好。这套架构的设计初衷是用一套数据库，同时解决 TP 和 AP 的问题，更轻量，更优雅，更便捷。 目前国外厂商如 Oracle / SQL Server / DB2 等都采纳了相似的计划，然而它们都不开源。

StoneDB 一体化架构图概览（v1.0）:

StoneDB 以插件的形式接入 MySQL，通过 查问 / 写入接口和 MySQL server 层进行交互，以后一体化架构次要个性有：

• 按列式存储形式组织数据，并联合高效压缩算法，使得 StoneDB 在取得高性能的同时也具备存储老本劣势。
• 基于常识网格（Knowledge Grid）的近似查问及并行处理等机制，使得 StoneDB 在解决海量数据以及简单查问时候，可能最大限度的缩小无关数据的 IO。
• 利用直方图，数据块位图等泛滥统计信息来进一步减速查询处理的速度。
• 采纳带有延后重构模型的 Column-at-a-time 的面向列式存储的执行引擎，又进一步提高执行引擎的效率。
• 提供高速的数据载入能力。

接下来咱们看一下 StoneDB 的架构设计。

架构设计：数据组织模式

在 StoneDB 中，数据按列进行组织。这种数据组织模式，对各类压缩算法敌对，可根据各列类型、数据等因素抉择适合的高效压缩算法，以达到节约 IO 和 Memory 资源的目标。另外还具备以下长处：

• Cache Line 敌对。
• 查问过程中，针对各列的运算并发执行, 最初在内存中聚合残缺记录集。
• 即席查问时，只需扫描特定列即可，无需耗费 IO 资源去读取其余列的值。
• 无需保护索引，反对任意列组合的即席查问。
• 能够提供基于常识网格能力，晋升数据查找效率。

架构设计：基于列的数据压缩

正如下面所提到的，数据按列进行组织，列中所有记录的类型统一，能够依据数据类型抉择对应的高效压缩算法，因为：

• 列中反复值呈现概率高，压缩成果显著。
• 数据节点大小固定，能够最大化压缩性能和效率。
• 依据特定的数值类型压缩（int，float，date/time，string 等）。

StoneDB 能够反对多达 20+ 种自适应压缩算法，目前次要应用：

• PPM
• LZ4
• B2
• Delta 等等

架构设计：数据组织构造与常识网格

StoneDB 的查询处理局部如上图所示。查询处理作为整个数据库的大脑，查问优化算法好坏，间接影响查问效率。

咱们再来讨论一下数据组织构造和常识网格。之前在介绍架构的时候，咱们也提到数据的按列组织，而且在每个列中，数据又按更细粒度的数据块进行划分。该种形式所带来的长处有：

（1）物理数据按固定数据块，进行存储，通常称之为：Data Node，通常为：128KB，零碎不便进行 IO 效率的优化。同时，也可为零碎提供基于块（Block）的高效压缩 / 加密算法。

（2）常识网格能够为查问优化器，执行和压缩算法等提供反对。例如：基于常识网格的查问，优化器会利用常识网格来决定须要抓取哪些 Data Node 来执行数据操作。

咱们解释一下相干概念，以下数据节点、元数据节点皆为逻辑概念：

• 数据节点（Data Node，DN）：数据块大小固定（典型值 128KB），优化 IO 效率，提供基于块（Block）的高效压缩 / 加密算法。
• 常识网格（Knowledge Grid，KG）：用于元数据存储。
• 元数据节点（Metadata Node，MDN）：形容数据节点的元数据信息。由常识节点（Knowledge Node，KN）组成，为查问优化器，打算执行和压缩算法等提供反对。

架构设计 – 查问：常识网格（Knowlegde Grid）概览

架构设计 – 查问：基于 Knowlegde Grid 的优化器

如上图所示：首先由查问优化器进行基于常识网格的优化，对其所须要解决的数据进行剪枝，其采取的策略为：对于满足查问条件的数据节点，即关联性数据节点，对其采取间接读取并返回的策略；对不确定性数据节点，先进行解压，而后在进行基于查问条件的解决，最初返回处理结果；而对与查问条件齐全不相干的数据节点，则间接疏忽。

而后再基于常识网格中的信息进行粗糙集（Rough Set）构建，并确定此次申请所需应用到的数据节点。基于 KN 和 MD，确定查问波及到的 DN 节点汇合，并将 DN 节点分类。执行打算构建时，会齐全躲避非关联 DN，仅读取并解压关联 DN，依照特定状况决定是否读取不确定的 DN。如果查问申请的后果能够间接从元数据节点（MDN）中产生（例如 count，max，min 等操作），则间接返回元数据节点中的数据，无需拜访物理数据文件。

架构设计 – 查问：解决流程

例如对于一个查问申请，通过 KG（常识网格）能够确定 3 个关联性 DN 和 1 个不确定性 DN。如果，此申请蕴含聚合函数。此时只须要解压不确定性 DN，并计算聚合值，再联合 3 个关联性 DN 中 MD 上的统计值即可得出最终后果。如果，此申请须要返回具体数据，那么无论关联性 DN 还是不确定性 DN，都须要读取数据块并进行并行解压缩，以便取得最终后果集。

比方，执行一条 select * from xx where seller = 86，外部执行流程如下：

1. 执行打算优化与执行：

   1. 基于常识网格进行 Cost-based 优化
   2. IO 线程池保护
   3. 内存调配与治理
2. SMP 反对（并发查问）
3. 向量化执行

齐全兼容 MySQL 生态的 StoneDB 一体化 HTAP 零碎的劣势

齐全兼容 MySQL 的 StoneDB 一体化 HTAP 数据库。其具备以下几个特点：

（1）齐全兼容 MySQL。无论是语法还是生态 MySQL 用户均能够无缝切换至 StoneDB。

（2）事务、剖析一体化。无需 ETL，事务型数据实时同步到剖析引擎。使得用户能够获取实时业务剖析后果。

（3）齐全开源。

（4）相较于 MySQL 提供10-100 倍的 AP 能力。 亿级多表关联急速响应，决策后果无需期待。

（5）10 倍导入速度。 因为 AP 场景下，剖析数据量微小，高效导入速度，能给带来良好的用户体验。

（6）1/10 的 TCO 老本，StoneDB 领有高效的压缩算法，无缝的业务迁徙能力，还有它的简略架构，都能为用户带来 TCO 的升高。

StoneDB 2.0 将带来全新架构

上文介绍的是 StoneDB 单机版本的 1.0 架构。尽管 StoneDB 基于磁盘的列存引擎在 AP 场景下的体现曾经十分杰出，然而毕竟其是基于磁盘的解决方案。咱们晓得，IO 和内存在数据库畛域又属于极度贵重的资源，认为进一步晋升 StoneDB 的性能，同时也为了缩小 AP 负载在执行时候对于 TP 负载的影响。将来咱们将在 2.0 版本中将推出了相似于 HEATWAVE 的基于内存计算的列存引擎的全新架构。该版本将基于 MySQL 8.0 构建，基于此引擎咱们将实现 AP 负载的全内存计算。

有对于 2.0 更多的信息欢送关注 StoneDB 的官方网站 https://stonedb.io

同时，StoneDB 在 6 月 29 日已发表正式开源。如果您感兴趣，能够通过下方链接查看 StoneDB 源码、浏览文档，期待你的奉献！

StoneDB 开源仓库：https://github.com/stoneatom/…

作者：高日耀

Title：StoneDB PMC、HTAP 内核架构师

简介：毕业于华中科技大学，喜爱钻研支流数据库架构和源码。8 年的数据库内核开发教训，曾从事分布式数据库 CirroData、RadonDB 和 TDengine 的内核研发工作，现负责 StoneDB 的内核架构师及 StoneDB 我的项目 PMC。

欢送关注我的微信公众号【数据库内核】：分享支流开源数据库和存储引擎相干技术。