乐趣区

关于数据库:什么是真正的HTAP二挑战篇

jiezi

上一篇文章中，咱们从技术和商业角度剖析了 HTAP 零碎缘起的背景，本篇文章中，咱们将从 HTAP 定义及其相干核心技术等方面来探讨：构建一个 HTAP 所面临的外围问题和挑战有哪些？

HTAP 波及技术和对产品的影响

HTAP 是将 TP 和 AP 进行高度交融的产物，而非简略的 TP 和 AP 相加：TP+AP ≠ HTAP。有的数据库让 TP 零碎通过简略的数据同步形式（比方 Binlog 等），将数据同步到 AP 零碎，而后再由 AP 零碎进行解决数据，尽管该种形式从用户的角度来看仿佛是取得了同时解决 TP 和 AP 的能力，然而从实质上来看，这并不能称为真正的 HTAP 产品，国内有一些数据库厂商宣传 HTAP 概念很起劲，然而本身可能还真不满足 HTAP 的定义。上面咱们就 HTAP 所波及到的几个外围问题来探讨一下，一个真正的 HTAP 产品须要具备哪些能力。
咱们将从以下维度进行探讨：

  1. 架构抉择（Architecture choice）
  2. 数据导入及查询处理引擎（Ingestion and query processing egnines）
  3. 存储计划（Storage options）
  4. 数据组织计划（Data organization）
  5. 事务语义（Transaction semantics）
  6. 数据的时效性（Recency of data being read by OLAP)
  7. 索引反对（Indexing supports）
  8. AP 负载和 TP 负载的互相烦扰（Workload interference）

当零碎接管到一个查问负载的时候，查询处理模块须要辨认出该查问负载中的 TP 负载和 AP 负载。并可能根据相应的策略（这里能够是基于规定或者是基于查问代价），将相应的负载转发至相应的解决引擎。

1. 架构的抉择
Single system（即 One system）还是 Seperate system 的抉择以后更多是基于工程上的难度。目前不少产品均是在原有的 TP 零碎之上，叠加了一个 AP 零碎并应用某种数据同步工具将 TP 零碎中的数据同步至 AP 零碎中。Seperate system 尽管有其长处，但这种计划存在着许多不容忽视的问题，比方无奈保障对事务的反对能力、数据的时效性，以及简单的零碎架构等（下文会有具体的解释）。相比之下，One system 不仅架构简洁，对于事务的反对能力和数据的时效性等方面都能提供更好的保障。然而，One system 架构的技术难度绝对较大，工程上也具备肯定的难度，同时还须要思考 TP 和 AP 负载间的互相烦扰等问题。StoneDB 目前就是采纳 One System 的架构设计，咱们深知此架构的劣势和难度。

2. 查询处理及数据导入引擎

该维度对产品有两个方面的形容。因为 HTAP 所面临的业务场景通常存着须要对海量数据进行剖析解决需要，而在剖析场景下，为了减速剖析，通常的做法是将须要进行剖析的数据，以列存的形式进行组织，这样能够利用列存的劣势减速剖析。因而，须要将实用于 TP 场景的行存类型数据转为实用于 AP 场景的列存数据。对于一个 HTAP 数据库 首先须要解决的问题是高速的数据载入。这里又包含两个方面：

– 全量数据的载入计划，保障海量数据疾速精确导入。

– 增量数据的更新计划，保证数据的时效性。

在数据加载实现后，另外一个维度是查询处理 。查询处理局部属于整个 HTAP 数据库的外围模块，其最重要的能力是可能同时实现 TP 负载和 AP 负载的解决。
索引已成为 TP 零碎的标配，通过设置索引能够大大提高数据库的检索速度，改善数据库性能。而 AP 零碎中的更新操作通常为批量更新，在更新时首先须要定位到待更新的数据，思考到 AP 零碎的数据组织和存储模型，如何可能通过设置索引疾速定位到须要更新的数据（尤其是在以列存且数据多为压缩模式的状况下）也是须要解决的一个难题。

3. 存储计划

随着存储技术的提高，存储介质和形式以及单位价格都产生了天翻地覆的变动，一个清晰的事实是：高速存储介质正在宽泛地利用到数据库畛域。对于 HTAP 数据库来说，TP 局部和 AP 局部的存储计划抉择波及到架构、性能、老本和业务场景等多方因素的影响。

4. 数据组织计划

抉择列存储加行存储（DSM + NSM），还是 PAX（Partition Attributes Across）计划或者是其它计划。数据组织计划的抉择不仅会极大的影响零碎性能，还会影响数据的存储老本。而 零碎的整体性价比也是咱们筛选产品的重要指标之一。

5. 事务语义

须要具备反对残缺的事务语义的能力，即 无论是 TP 局部还是 AP 局部都须要对事务进行残缺的反对。现有的很多 HTAP 解决方案，AP 零碎中所解决的数据均是同步自 TP 零碎中已提交的数据。这类解决方案存在以下几个问题：首先，对应长事务场景下，如何保障 AP 零碎能够取得最新版本的数据值得咱们认真思考。再者，通过以同步日志的形式，数据的时效性和一致性须要认真思考。最初，为了解决上述问题，会影响到事务的执行效率，导致系统吞吐量的降落。

6. 数据的时效性

须要保障 AP 零碎所解决的数据均为以后最新版本的数据。以后的很多零碎是在 TP 数据提交实现后，通过同步日志的形式将 TP 局部的变更同步到 AP 局部，这种形式无奈保证数据的时效性，因此不能称之为真正的 HTAP 零碎。

7. 索引的反对

索引已成为 TP 零碎的标配，通过设置索引能够大大提高数据库的检索速度，改善数据库性能。而 AP 零碎中的更新操作通常为批量更新，在更新时首先须要定位到待更新的数据，思考到 AP 零碎的数据组织和存储模型，如何可能通过设置索引疾速定位到须要更新的数据（尤其是在以列存且数据多为压缩模式的状况下）也是须要解决的一个难题。

8. 不同类型负载间的互相烦扰

零碎须要可能 保障 AP 负载对 TP 负载无影响或者使得两种类型负载间的影响最小化 。
上述探讨了一个真正的 HTAP 零碎应该具备的几点外围能力，当然这些只是咱们认为的外围能力，其它的相干问题这里就不在开展，后续咱们会陆续给出上述 HTAP 外围能力的具体解读。

从不同维度对现有 HTAP 产品 / 解决方案进行分类

现有的 HTAP 产品图谱分类的次要办法：

  1. 架构形式；
  2. 存储范式（Cloud/Shared Disk）；
  3. 扩大形式（Scale out/Scale up）；
  4. 查问语句规范；
  5. 并发策略（MVCC）；
  6. 数据 / 表的组织形式；
  7. 索引（LSM, ART, B-tree, lock-free Bw-Tree）。

下表从性能 / 许可证 / 是否开源等各个维度，对以后 HTAP 市场中的标杆产品进行了综合剖析。如需获取更多信息，请拜访咱们的官网：_https://stonedb.io/_

其它方面：多模能力等属于非必要，这里暂不思考。

这里咱们将 ClickHouse 放进来，次要是思考其在 AP 解决方面的优异能力，能够作为咱们 HTAP 产品在 AP 方面的一个标杆。

HTAP 所面临的外围挑战

综上，咱们能够总结出 HTAP 面临的挑战有：

  1. 真正的 HTAP，而非 TP 与 AP 的叠加
  2. 架构的抉择
  3. 数据组织计划抉择，存储计划抉择
  4. 查问优化：如何根据负载类型和查问代价抉择适合的执行引擎
  5. 数据的时效性：如何可能缩小 TP 和 AP 之间的数据挪动，高效实时地将 TP 数据更新同步到 AP 数据中
  6. 负载隔离：如何无效地打消或者最小化 TP 和 AP 负载之间的互相烦扰
  7. 资源管理：如何可能高效的治理 TP 和 AP 负载之间的资源应用
  8. 实时剖析的能力
  9. 事务语义反对

以上是对 HTAP 数据库的局部挑战梳理，在下一篇文章中，咱们将对这些外围问题和挑战开展更加深度的探讨并给出抉择一款 HTAP 产品的倡议。
StoneDB 是国内首款基于 MySQL 的一体化实时 HTAP 开源数据库，内核引擎齐全自研。咱们将在开源数据库畛域继续耕耘，一直与各个开源数据库社区、企业单干共建，共创国产开源数据库良好生态。

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

StoneDB 开源仓库

https://github.com/stoneatom/…

作者李浩

StoneDB 首席架构师、StoneDB PMC

曾在华为、爱奇艺、北大方正从事数据库内核外围架构设计。超过 10 年数据库内核开发教训，善于查问引擎，执行引擎，大规模并行处理等技术。领有数十项数据库发明专利，著有《PostgreSQL 查问引擎源码技术探析》。

编辑 & 校对：李明康、王学姣、高日耀、

退出移动版