1 概述
SQL引擎V2.0是使用 DuckDB 作为 数据模型 SQL 查询的执行引擎。
作为一款嵌入式数据库,DuckDB 专为高效处理大规模数据分析任务而设计,其内存引擎在其中扮演了至关重要的角色。
以下是关于 DuckDB 内存引擎的一些关键点:
内存中的数据结构
DuckDB 使用一种称为 "flat columnar" 的存储格式来组织数据。这种格式将表的每一列分别存储在一个连续的内存块中,而不是按行存储。这不仅提高了缓存命中率,还使得对单个列的操作更加高效,非常适合用于分析查询中常见的聚合操作。
矢量化执行
DuckDB 的内存引擎采用了矢量化执行模型。这意味着在处理数据时,它不是一次处理一行,而是批量处理一整批(通常是1024或更多)的数据记录。矢量化可以显著减少解释开销,并允许现代CPU更好地利用SIMD(单指令多数据流)指令集进行并行计算,从而大幅提升查询性能。
内存管理
DuckDB 的内存管理机制能够智能地决定何时将数据保留在内存中以及何时将其写回到磁盘。对于临时结果和中间状态,DuckDB 可以根据可用内存自动调整策略,确保即使是在资源受限的环境中也能保持良好的性能。此外,DuckDB 支持显式的内存预算设置,用户可以根据具体需求控制最大内存使用量。
并发与事务支持
尽管主要针对读密集型工作负载进行了优化,但 DuckDB 的内存引擎也提供了基本的并发控制和事务支持。它可以安全地处理多个并发查询,并保证ACID属性(原子性、一致性、隔离性和持久性),即使所有操作都在内存中完成。
内存中的索引
为了加速查询,DuckDB 在内存中构建了多种类型的索引结构,如哈希索引、B树索引等。这些索引可以帮助快速定位特定值的位置,减少不必要的全表扫描,提高查询效率。特别是在涉及大量连接或查找操作的情况下,适当的索引可以极大地改善性能。
信息 | ||
---|---|---|
| ||
信息 | ||
1、SQL引擎V2.0 只能在数据模型V2.0开启之后才能使用。 2、SQL引擎V1.0的支持范围可查看SQL引擎V1.0介绍。 3、SQL引擎V2.0不会加载明细数据到内存中,是计算汇总后的数据。 4、如果只是简单查询,比如只有维度+度量(原子度量),即使开启了SQL引擎V2.0 仍然会走SQL引擎V1.0。 |
1 概述
1.1 SQL引擎V2.0 是什么?
- SQL引擎V2.0是 数据模型引擎V2.0 下面的执行引擎。
- 它是SQL引擎V1.0的升级。
1.2 SQL引擎V2.0适合的查数场景
- 指标二次计算: 指标之间的加、减、乘、除、case when、IIF等的简单加工支持走SQL引擎V2.0。
- 快速计算:在报表层使用快速计算可以走SQL引擎,比如同期值、前期值、累计值等。
1.3 如何开启SQL引擎V2.0?
- 需要先在运维设置/系统限项/高级设置 中开启数据模型引擎V2.0:OLAP_QUERY_NEW_ENGINE_BUILD_MDX=true;USE_NEW_ENGINE_PREPROCESS=true
- 再开启SQL引擎V2.0: USE_NEW_ENGINE_NEW_SQL=true, 这个一旦开启,是全局性的,所有基于数据模型的报表查询满足条件都会走SQL引擎V2.0。
- 如果只是想要在某个数据模型中开启,可以在高级选项开启:DATAMODEL_OPEN_SMARTCUBE_ENGINE_BUTTON=true,效果如下图所示:
2、SQL引擎V1.0的支持范围可查看SQL引擎V1.0介绍。
...
2 SQL引擎V2.0 VS V1.0的功能对比
2.1 SQL引擎V2.0 比SQL引擎V1.0增强了那些功能
序号 | 内容 | V1.0 | V2.0 |
---|---|---|---|
1 | 快速计算支持走SQL引擎 | 不支持 | 功能增强,在V2.0上,支持快速计算走SQL引擎。 |
2 | 计算度量如果表达式仅涉及加(+)、减(-)、乘(*)、除(/),或者仅使用case when/IIF函数,也支持走SQL引擎 | 仅有clickhouse、mysql支持,其他库仍然不支持 | 功能增强,全部库支持。 |
涉及多维计算如:计算度量基于MDX函数表达式、计算成员、命名集 目前依然不支持走SQL引擎。 |
...
2.2 SQL引擎V2.0
...
与 V1.0的差异
序号 | 内容 | V1.0 | V2.0 |
---|---|---|---|
1 | 查询度量并且把汇总依据切换成“唯一计数”并显示“合计”,如下图报表: | 支持 | 支持 |
2 | 当过滤条件是度量并且显示了合计的情况,如下图: | 不支持,会走OLAP引擎 | 不支持,会走OLAP引擎 原因: 生成的执行SQL语句,度量在外层,度量对合计不生效。 |
3 | 年周层次,涉及到时间的计算不支持走SQL引擎,如下图: | 不支持 | 不支持 注意:年周+排名、占比是支持走SQL引擎的。后续年周的时间计算会支持走SQL引擎。 |
4 | 中文排序结果可能不同,如下图: | V1.0显示效果: | V2.0显示效果: 排序不一致:主要是由于数据库本身的字符集或者中文编码而造成的排序结果不一样,有的中文排序结果是一样的,暂时没有得到什么规律。 |
5 | 空值(Null)的排序: | 由数据库决定 | 在SQL引擎V2.0时,升序时空值在第一行,降序在最后一行。 |
6 | 当数据模型是多事实并且是抽取模式(抽取到SmartbiMpp产品默认使用高速缓存库CH)中,如果度量的值没有时(full join 出现来的空),在报表层显示效果不一致。 | SQL引擎V1.0显示”0“,如下图: | SQL引擎V2.0显示“空”,数据是什么就显示什么: |
...
3 如何判断是否走了SQL引擎V2.0
方法1:查看系统监控 “SQL/MDX监控”记录的数据源是否显示“SQL引擎V2.0”,如果是,则走了SQL引擎V2.0。
方法2:耗时分析,与方法1一样查看执行数据源:
4 SQL引擎V2.0 VS V1.0的性能对比
...
4 SQL引擎V2.0的原理简说
SQL引擎V2.0是使用 DuckDB 作为 数据模型 SQL 查询的执行引擎。
作为一款嵌入式数据库,DuckDB 专为高效处理大规模数据分析任务而设计,其内存引擎在其中扮演了至关重要的角色。
以下是关于 DuckDB 内存引擎的一些关键点:
内存中的数据结构
DuckDB 使用一种称为 "flat columnar" 的存储格式来组织数据。这种格式将表的每一列分别存储在一个连续的内存块中,而不是按行存储。这不仅提高了缓存命中率,还使得对单个列的操作更加高效,非常适合用于分析查询中常见的聚合操作。
矢量化执行
DuckDB 的内存引擎采用了矢量化执行模型。这意味着在处理数据时,它不是一次处理一行,而是批量处理一整批(通常是1024或更多)的数据记录。矢量化可以显著减少解释开销,并允许现代CPU更好地利用SIMD(单指令多数据流)指令集进行并行计算,从而大幅提升查询性能。
内存管理
DuckDB 的内存管理机制能够智能地决定何时将数据保留在内存中以及何时将其写回到磁盘。对于临时结果和中间状态,DuckDB 可以根据可用内存自动调整策略,确保即使是在资源受限的环境中也能保持良好的性能。此外,DuckDB 支持显式的内存预算设置,用户可以根据具体需求控制最大内存使用量。
并发与事务支持
尽管主要针对读密集型工作负载进行了优化,但 DuckDB 的内存引擎也提供了基本的并发控制和事务支持。它可以安全地处理多个并发查询,并保证ACID属性(原子性、一致性、隔离性和持久性),即使所有操作都在内存中完成。
内存中的索引
为了加速查询,DuckDB 在内存中构建了多种类型的索引结构,如哈希索引、B树索引等。这些索引可以帮助快速定位特定值的位置,减少不必要的全表扫描,提高查询效率。特别是在涉及大量连接或查找操作的情况下,适当的索引可以极大地改善性能。