Page 445 - 《软件学报》2025年第12期
P. 445

5826                                                      软件学报  2025  年第  36  卷第  12  期


                    除  CPU  和  L3 cache 架构差异外, 远程  NUMA  访问延迟也有较大差异. 我们模拟了           NUMA  内及远程    NUMA
                                29
                 哈希表访问    (预设  2 哈希桶) 操作来评估跨       NUMA  访问延迟, 如表     2  所示, 每个  ARM CPU  有  2  个  NUMA  节点,
                 其他  4  个  x86  每  CPU  有一个  NUMA  节点. 哈希表采用全表扫描, 更新操作模拟远程哈希表的读写操作, 以本地
                 NUMA  节点哈希表访问延迟作为基准延迟             (数值为  1), 远程  NUMA  访问延迟与本地基准访问延迟比率作为远程
                 NUMA  访问延迟的度量值, 该值越大则跨           NUMA  访问延迟越高. 总体而言, Intel x86 CLX(28) 和   ICX(38) 的远程
                 NUMA  访问延迟显著低于       AMD x86 Rome Zen2  和  Milan Zen3. ARM CPU  内部  NUMA  节点访问延迟较低, 但跨
                 CPU NUMA  节点的访问延迟较高, 最大延迟高于           AMD CPU.

                                               表 2 不同平台的     NUMA  访问延迟

                                     读 (NUMA0→目标节点) 延迟比率                  写 (NUMA0→目标节点) 延迟比率
                    CPU架构
                                  0         1        2        3         0        1        2        3
                    ARM(64)       1        1.24     1.91     1.76       1       1.18     1.75     1.64
                     CLX(28)      1        1.29     -         -         1       1.33      -        -
                  Rome Zen2(64)   1        1.94     -         -         1       1.74      -        -
                     ICX(38)      1        1.36     -         -         1       1.31      -        -
                  Milan Zen3(64)  1        1.73     -         -         1       1.58      -        -

                    综上所述, 不同     CPU  架构  NUMA  延迟的差异性使     NUMA  优化方法的性能收益和复杂度产生差异化, ARM
                 CPU  具有多  NUMA  节点的特征, 这增加了      NUMA  优化算法的复杂性或数据分布代价. 但             CPU  内部  NUMA  延迟
                 较低可以将    NUMA  逻辑合并, 从而达到与       x86 CPU NUMA  优化方法的兼容, 并且降低多        NUMA  节点上的数据分
                 布或复制代价.
                  1.3   连接基准
                    连接是数据库重要的基础算子, 在数据仓库和                OLAP  应用中主要实现事实表与维表之间等值匹配连接, 其
                 中事实表庞大且数据量持续增长, 维表较小且缓慢增长, 维表数据量相对事实表数据量占比较低                                 (通常维表数
                 据量占总数据量的       1%  以下). 近年内存连接优化技术研究中主要模拟大表连接与小表连接性能, 如两表固定大
                 小  [1,6,7] 或两表固定比例|R|=10×|S|和|R|=|S| [2,4,8] , 这种固定负载固化了连接优化的覆盖范围, 不同的表大小及选择
                 率都极大地影响连接性能特征            (如文献  [7] 中在  TPC-H  负载中的连接性能特性出现偏差). 另一方面, |R|=|S|或
                 |S|=10×|R|的连接负载只关注了软件维度上连接表的大小关系, 没有考虑连接表大小与                          CPU  的  LLC (last level
                 cache, 最后一级  cache, 通常指  L3 cache) 的关系, 虽然  NPO  算法及向量连接算法在优化技术上的              hardware-
                 oblivious 特性不需要面向   CPU  硬件参数配置调优, 但算法表现为           hardware-adaptive 特性, 即具有与  LLC  容量与
                 效率自适应的硬件优化特征. 在设计连接负载时需要关注硬件技术的发展                          (LLC  容量的持续增长) 与连接算法
                 性能的相关性.
                    基于上述分析, 本文设计了         micro join benchmark (MJB), 主要从软件、硬件、应用这     3  个维度设计了连接负
                 载, 可以更加全面测试      OLAP  负载中连接性能, 具体设计如下.
                    (1) R  表和  S  表采用主外键连接方法. R    表主键为连续整数代理键, 以         shuffle 乱序存储, 模拟异位更新场景及
                 非聚集存储. S   表外键乱序存储.
                    (2) |S|=SF×6M, S  表模拟  TPC-H  和  SSB  中最大的事实表, SF  代表扩展因子.
                           5
                    (3)| R|=  2 –2 log 2 |S| , 取消|R|=|S|负载  (数据仓库等值连接的一一映射通常采用物化策略), 在相对      R  表大小上变
                 化范围更加全面, 相对       LLC  大小的动态变化负载更优. 在绝对          R  表大小上覆盖了代表性的数据库基准             TPC-H、
                 SSB  和  TPC-DS  中各连接表大小.
                                                                                    29
                                                                                5
                    如本文实验中      SF=200, 模拟  12  亿行事实表上的连接操作, R      表变化范围从     2  – 2 行, 能够覆盖最大     17 TB
                 SSB  数据集、3.5 TB TPC-H  数据集和  100 TB TPC-DS  数据集上的连接负载.
                    PRO  算法通过分区操作实现        L1/L2 cache 中的哈希连接操作, 对    LLC  不敏感. NPO  算法和向量连接算法通过
   440   441   442   443   444   445   446   447   448   449   450