likes
comments
collection
share

StoneDB 宣布开源,一体化实时 HTAP 架构为何是当前最优解

作者站长头像
站长
· 阅读数 64

国产开源数据库赛道又有了新玩家。近日,一体化实时 HTAP 开源数据库 StoneDB 宣布正式开源。以下内容源自 StoneDB 首席架构师、StoneDB PMC 李浩的演讲。

在 2014 年,Gartner 给出了 HTAP 的严格定义,其目的是为了打破事务型负载和分析型负载之间的壁垒,使系统能够支持更多的“数据”在两个系统之间流动,以及以这些数据为基础的 “实时业务”的决策。

回到 Gartern 所提出的问题的本源:我们来探讨一下 HTAP 此类架构的本源动力是什么?传统架构形式下,为了解决同时处理 TP 负载和 AP 负载的问题,通常采用一套 TP 系统加上一套 AP 系统的方式,TP 和 AP 之间通过 ETL 或是 binlog 等方式进行数据同步来满足业务对实时性的需求。该种方式下,我们认为存在以下几个问题:

(1)系统复杂,带来维护成本增加;

(2)涉及到众多技术栈,对技术人员要求较高;

(3)TP 数据通过 ETL 等方式同步到 AP 系统中,导致数据延时较大,数据的时效性差,难以满足业务对分析的实时性要求。

随着技术的发展,用户需求和商业需求变得越发严苛,传统的方案已无法满足,HTAP 则提供了另外一种解决方案。由此带来业务架构的简化,更少的技术栈,更好的数据的实时性等优点。

当然,任何问题都具有两面性,在给用户和业务带来便利性的同时,也需要解决一些挑战。我们认为,HTAP 需要直面如下挑战,而这也是所有 HTAP 数据库所需要面临的。其中包括:

(1) 架构的选择:one system one copy Or one system two copies, Or tow systems tow copies;

(2) 数据的高效组织,当选定系统架构后,如何高效的组织数据使得在该种模型下,数据可以满足 TP、AP 的需求;

(3) 多类型负载的处理问题以及负载间的隔离问题;

(4) 负载响应时间;

(5) TP 负载中的变化数据需及时同步到 AP 中,即:解决数据的时效性;

(6) 快速的数据加载能力;

(7) 完整而全面的生态支持。

什么是 Stone DB

Stone DB 作为一款开源的 MySQL HTAP 数据库,其主要以下几个特点:

(1)完全兼容 MySQL,无论是语法还是生态,MySQL 用户均可以无缝切换至 StoneDB;

(2)事务、分析一体化,无需经过 ETL,事务型数据可实时同步到分析引擎。使得用户可以实时获取业务分析结果;

(3)完全开源;

(4)相较于 MySQL,StoneDB 提供 10-100 倍的 AP 能力,亿级多表关联,急速响应,决策结果无需等待;

(5)高效导入速度,由于 AP 场景下,所分析数据量巨大、高效的导入速度将给您带来良好的用户体验;

(6)1/10TCO 成本,高效的压缩算法,无缝的业务迁移能力,简单架构,都能为您带来 TCO 的降低。

StoneDB 采用一体化架构,并采用列式存储方式进行组织数据用以支持 AP 负载,结合高效压缩算法使得 StoneDB 在获得高性能的同时也具有存储成本优势。

同时,采用基于知识网格的近似查询及并行处理等机制,使得 StoneDB 在处理海量数据以及复杂查询时候,能够最大限度的减少无关数据的 IO,并利用直方图、数据块位图等众多统计信息来进一步的加速查询处理速度;此外,StoneDB 采用带有延后重构模型的 Column-at-a-time 的面向列式存储的执行引擎又进一步提高执行引擎的效率。最后,StoneDB 提供高速的数据载入能力。

上述技术的运用使得 StoneDB 有潜力成为一款优秀的 HTAP 数据库,当然为了进一步的提升在 HTAP 方面的能力,StoneDB 在 2.0 版本中将推出基于内存的 In-Memory Column Store(IMCS)。

StoneDB Ver 1.0

与 TP 引擎多采用行式存储方案不同,AP 引擎多采用列式存储方案。与行存模型不同,列存模型是将数据按列的方式进行组织。StoneDB 采用,例如:lz4,bz2, zstd, snappy, zlib 等多达 20+以上的压缩算法来对数据进行压缩,从而来进一步减少查询处理过程中所需要的 IO。

查询处理作为整个数据库的大脑,查询优化算法好坏直接影响查询效率。为了使得 StoneDB 能够高效处理海量数据。我们首先再来讨论一下数据组织结构和知识网格。

在 StoneDB 中,数据以列的方式进行组织,在每个列中,数据又按更细粒度的数据块进行划分,这种方式所带来的优点有:

(1)物理数据按固定数据块进行存储,通常称之为: Data Node(或称为 Data Pack)。这样使得系统具有基于块(Block)的高效压缩/加密算法的能力;

(2)知识网格可以为查询优化器、执行和压缩算法等提供支持。例如:基于知识网格的查询,优化器会利用知识网格来决定需要抓取哪些 Data Node 来执行数据操作。

什么是优化器呢?优化器会利用知识网格对其所需要处理的数据进行剪枝:其采取的策略为:对于满足查询条件的数据节点称之为:关联性数据节点,对其采取直接读取并返回的策略;对于无法确定节点中是否存在满足查询条件的数据,我们将其称之为:对不确定性数据节点。对其采取的策略是:先进行解压,然后在进行基于查询条件的处理,最后返回处理结果;而对与查询条件完全不相关的数据节点,则直接忽略。

举例来说,对于一个查询请求,通过 KG(知识网格)可以确定 3 个关联性 DN 和 1 个不确定性 DN。如果该查询请求中包含聚合函数,此时只需要解压不确定性 DN,并计算该节点中满足条件的数据的聚合值,再结合 3 个关联性 DN 中元数据节点(Metea Node,MD)上的统计值即可得出最终结果。如果此请求需要返回具体数据,那么无论关联性 DN 还是不确定性 DN,都需要读取数据块并解压缩,以便获得最终结果集。

随着硬件技术的发展,硬件的红利也慢慢传递到数据库领域,随着 CPU 对向量化执行的支持。如今像 SIMD 指令已经广泛的应用在数据库中,用来提升执行效率。

传统火山模型采用迭代式进行数据处理,通过调用 next()函数来获取下一条记录并进行处理。该种方式下,需要产生大量的函数调用,上下文切换等等问题。因此,越来多的数据库均提供基于 SIMD 指令的向量化执行能力,用以加速执行。除了 SIMD 指令的应用,为了发挥当前 CPU 的多核能力,并行查询也是一个查询效率的倍增器。

数据的加载对于用户的体验也至关重要,通常我们需要处理的数据量非常大。为了给用户提供急速的数据加载体验,StoneDB 在数据加载方面也做了大量的工作。StoneDB 在数据加载时,数据首先在外部完成预处理,随后直接使用二进制的模式进行导入,无需通过转换为 SQL 文本来表达数据,从而避免 SQL 解析、数据验证等操作过程对服务器造成性能冲击。

StoneDB Ver 2.0

我们刚才讨论了 StoneDB ver 1.0 的架构及相关技术。虽然 StoneDB On-Disk Column Store 在 AP 场景下的表现已经非常出色,但是毕竟其是基于磁盘的解决方案。IO 和内存在数据库领域又属于极度宝贵的资源,其通常为整个数据库系统的瓶颈所在。为进一步提升 StoneDB 性能,同时也为了减少 AP 负载在执行时候对于 TP 负载的影响,而这也是我们在前面所讨论的 HTAP 所需要面临的挑战之一。

我们在 ver 2.0 中将推出了类似于 Oracle Heatwave 架构形态的基于 In-Memory Column Store 引擎的全新架构-ver 2.0,该版本将基于 mysql 8.0 构建。基于此引擎我们将实现 AP 负载的全内存计算:

(1)数据在内存中组织方式;以列存方式进行组织,同时包含元数据。元数据部分包括了:数据量,列的数量,行列的映射关系,事务信息,数据分布情况等相关元数据;

(2)数据加载的方式,由 InnoDB 并行加载至 In-Memory Column Store 中;

(3)数据的更新问题,当我们 TP 中的数据发生变化的时候,如何实时更新到 AP 中。同时,更新机制及更新时机;

(4)内存中数据持久化的问题及系统 Recovery 的问题。为了使得系统在 crash 时,能够更快速的完成 Recovery 的过程,in memory 中的数据将会被持久化到我们的 on-disk column store 中。

StoneDB 将提供导入行为的监控能力,实时感知加载进度,在加载过程中通过非阻塞,无锁机制来实现高性能数据 load 能力。

基于代价的新查询引擎也将是 ver 2.0 的重点工作。一个负载透明、且具有更加高效、准确的代价模型将是我们系统性能的保证。同时,并行查询和向量化等技术也将会得到持续的迭代。未来的分布式 AP 集群也将是我们在单节点能力构建之后,下一步的重点工作方向。

关于数据更新问题最后,我们讨论一下数据的更新问题。当 TP 中的数据发生变化后,首先将变化数据插入到 Population buffer 中,并维护该数据的版本信息。Population buffer 中的数据最后会和 in-memory column store 中的数据进行合并,形成该数据的最新版本,更新到 in-memory column store 中。当前诸多现有的 HTAP 方案是提供一个只读的 AP 节点,通过某种机制例如:ETL、Binlog 或者 Raft 同步 Redo Log 等方式将 TP 中数据更新到 AP 节点,并由该 AP 节点对外提供 AP 处理能力,这样导致整个系统架构负载,TP 和 AP 间的数据同步无法保证实时性。

当满足如下三个条件的时候,StoneDB 会将 Population buffer 中的数据,依据版本信息依次与 in memory column store 中数据合并,构成为该数据的最新版本:

(1)当我们的 Population buffer 已经写满后,会执行一次 flush 动作,将 buffer 中的数据更新到其对于的 in-memory 数据中;

(2)到达指定的时间,例如:200ms;

(3)当 AP 负载发现其引用到的数据来自 TP 时,其会主动的检查 Population buffer 是否有最新的版本。如果有,则 StoneDB 也会进行合并动作,形成该数据的最新版本。

StoneDB GitHub 地址:https://github.com/stoneatom/...

社区地址: https://stonedb.io

关于作者

李浩,StoneDB 首席架构师、StoneDB PMC。曾在华为、爱奇艺、北大方正从事数据库内核核心架构设计。超过 10 年数据库内核开发经验,擅长查询引擎、执行引擎、大规模并行处理等技术。拥有数十项数据库发明专利,著有《PostgreSQL 查询引擎源码技术探析》。

可扫码添加小助手:StoneDB_2022

加入 StoneDB 开源社区用户群

讨论交流,共同进步

本文由博客一文多发平台 OpenWrite 发布!
转载自:https://segmentfault.com/a/1190000042178625
评论
请登录