StoneDB 2.0 调研：架构解析内存引擎详细设计

StoneDB 官方介绍：StoneDB 是一款支持行列混存+内存计算的 HTAP 数据库。其采用完全自主研发的存储和计算引擎，可将 MySQL 的分析性能提高100倍；其创新的一体化 HTAP 架构，打破传统 TP 型数据库能力边界，为用户提供一站式 OLTP+OLAP 解决方案。

一句话概括：StoneDB 一体化实时 HTAP 开源数据库。

最近stonedb官方发布了内存引擎详细设计的视频，打算调研一下。

找到了官方发布在b站的视频解说：

StoneDB 2.0 架构解析：内存引擎详细设计（一）_哔哩哔哩_bilibili

 StoneDB 2.0 架构：内存引擎设计（二）_哔哩哔哩_bilibili

stonedb的次引擎

在stonedb1.0之中，只支持基于磁盘的列存引擎 Tianmu。同 InnoDB 角色一样，可以作为 MySQL 的另外一个主引擎。在 StoneDB 2.0 版本中，我们将引入 MySQL 8.0.2 中的新特性：次引擎。

StoneDB 2.0 版本中，将推出基于内存计算的列存引擎，该版本将基于 MySQL 8.0 构建，基于此引擎我们将实现 AP 负载的全内存计算。

使用次引擎的原因？

1. 次引擎是一个 MySQL 框架，用于提供多引擎的能力。基于通用的接口和框架，MySQL 可以根据每个工作负载的类型将不同的工作负载路由到相应的引擎，发挥其优势以提供优质的服务。次引擎也可以使 MySQL 拥有增强多模能力的机会，例如让 ClickHouse 成为一个次引擎来提供分析服务。
2. 逻辑上讲，将子任务路由到次引擎，主任务放到主引擎去执行，比较自然能想到。
3. 业内也有一些样例，Oracle 已经将次引擎的特性用在了它们的在线服务中。比如说MySQL HeatWave： 一个内置机器学习的内存查询加速器。

ps:启用 HeatWave能将分析和混合负载的性能提高几个数量级。启用 HeatWave 后，MySQL HeatWave 比 Amazon Redshift 快 6.5 倍，成本只有一半，比 Snowflake 快 7 倍，成本只有五分之一，比 Amazon Aurora 快 1,400 倍，成本只有一半。客户对存储在 MySQL 数据库中的数据进行分析，无需单独的分析数据库和 ETL 复制。

为什么要使用基于内存的列式引擎？

 首先从当前分析处理系统存在的一些挑战来讲，好的分析查询性能要满足以下几个要求：

• 了解用户的访问模式
• 提供良好的性能，通常需要创建索引、物化视图和 OLAP 多维数据集。

 这样比较极端的情况是，对每一列都会创建一个索引，会造成创建索引的空间比表占用空间还要大的一种情况。

 为了提升性能，StoneDB 在 1.0 的版本中使用了基于列的数据格式。列式数据格式以列的形式组织数据，而不是行。

 （使用列存的好处大家可以自行搜索，网上的资料非常之多。）

行存和列存没有孰优孰劣之分，在不同的应用场景中会有不同的表现，具体为"增改查"的区别。 

• 行存的优势在于写入和修改的效率很高，同时对于每行数据的完整性上具有天生的优势，适用于面向事务型处理的应用场景。
• 列存的优势在于读取的效率很高，并且可以使用高效的压缩算法来节省储存空间，适用于查询密集型的应用场景

大体上来说使用列存在分析型事务中可以更方便呢的过滤多余数据。

那么问题就是：应用程序要么实现快速分析，要么实现快速交易，但不能同时实现两者。混合工作负载数据库的性能问题并不能通过仅以一种单一格式存储数据来解决。

所以stonedb在2.0中引入了新的引擎，即基于内存列的存储，用于分析工作负载。内存中的