尧图网页设计 
缓存KV存储消息队列流处理后端【免费下载链接】hazelcastHazelcast is a unified real-time data platform combining stream processing with a fast data store, allowing customers to act instantly on>项目地址https://gitcode.com/gh_mirrors/ha/hazelcast点击查看免费下载导读本文以 Hazelcast 仓库设计文档 docs/design/sql/20-sql-partition-pruning.md 为核心骨架系统讲解 SQL 引擎如何利用 IMap 的分区信息在优化阶段判定查询是否可剪枝prunable并把过滤条件转换为精确的分区 ID 集合从而只扫描必要的分区与成员、显著降低网络与 IO 开销。文章覆盖分区剪枝的术语体系、RelNode 可剪枝性规则、Filter 分析与变换算法、SqlConnector接口扩展以及 EXPLAIN PLAN 与测试标准并结合hazelcast-sql模块源码如HazelcastRelMdPrunability、PartitionStrategyConditionExtractor、IMapSqlConnector与端到端测试进行佐证。读完本文你将掌握 Hazelcast SQL 分区剪枝的完整原理、适用边界与底层调用链可直接用于理解与排查相关 SQL 执行计划。背景与动机在实际业务中针对大数据集的查询往往并不需要扫描全部数据。数据通常按分区组织查询只涉及其中一小部分分区同时Join、聚合等操作也能从数据如何分区这一信息中获益。利用该知识可以让查询运行得更快、消耗更少的资源网络、IO使具备分区剪枝资格的 SQL 查询在性能上可比肩使用PartitionPredicate的 Predicate API 查询。此外知道需要哪些分区还能把与查询无关的成员member从查询执行中完全剔除——这些成员上没有任何与查询相关的数据。这既减少了执行 DAG 的规模也降低了跨成员通信的开销。目标与非目标目标提升使用AttributePartitioningStrategy且过滤条件涉及其中定义属性的 IMap 查询性能。非目标明确不在本设计范围之内对使用 IMap__key但不满足转换为IMapSelectPlan条件、必须创建 Jet job 的查询做性能提升为除 IMap 之外的其它数据源提供分区剪枝未来可考虑对过滤条件做复杂的表达式变换以提取分区信息复杂场景下用户必须把谓词写成受支持的形式追踪属性之间的函数依赖由组成属性构造__key例如__key包含两个属性时将__key.a1X and __key.a2Y转换为__key(X,Y)。术语术语定义item / entry / row被视为整体的单个数据元素prunable有资格进行分区剪枝优化以下三个术语是整个设计的基石分区列Partitioning column影响给定 item 被分配到哪个分区的列/属性。分区键Partitioning key足以确定给定 item 所属分区的最小的分区列集合按包含关系最小。分区键集合Set of partitioning keys包含两类分区键的集合——由AttributePartitioningStrategy定义的分区键如果有以及__key。澄清说明对于 IMap分区列只能是 IMap key 的属性IMap value 的属性不能作为分区列。若 IMap 使用了AttributePartitioningStrategy分区列在函数上依赖于整个__key但为了简化SQL 优化器当前不追踪函数依赖而是假设__key与AttributePartitioningStrategy都定义了一个分区键。分区 ID 的计算会考虑这一点并对给定 IMap 使用正确的策略。分区完备表达式Partition-complete expression表达式E是分区完备的当存在分区键PK {partColumn1, ..., partColumnM}使表达式可变换为E partKeyExp1 OR partKeyExp2 OR ... OR partKeyExpN其中每个partKeyExpN的形式为partKeyExpN partColumn1Expr AND partColumn2Expr AND ... AND partColumnMExpr AND residualFilter要求对组成PK的每一个分区列都有一个子表达式partColumnMExpr的形式为partColumnM operator arguments支持的operator包括等值SEARCH带SargBETWEEN仅限整数类型首个版本不支持——只有对合理小范围才有意义arguments允许是字面量literal查询参数query parameter仅由上述参数和任意确定性函数构成的复杂表达式尤其不允许引用其它列residualFilter可以是任意表达式尤其可以为TRUE它可以引用任意列包括分区列本身。几点澄清范围分区如order_date between day1 and day2当前不支持只支持哈希/等值类分区E的每个 OR 分支可能使用不同分区键该场景当前不支持partCol1 partCol2 AND partCol2 constantX不属于分区完备但可通过常量传播变换为partCol1 constantX AND partCol2 constantX——这类变换超出本文档范围但可由 SQL 优化器现在或未来独立执行。技术设计等值分区与元数据等值分区假设IMap 本质是哈希表因此分区剪枝只支持基于等值equality的分区。范围分区如日期范围不支持这与哈希表的分区语义保持一致。提供给 SQL 优化器的分区元数据Calcite SQL 优化器需要知道 IMap 是如何分区的。IMap 的AttributePartitioningStrategy所包含的列清单将在 PartitionedMapTable 中可用注意__key是特殊情况需要通过对AttributePartitioningStrategy的扩展、或单独的专门 Partitioning Strategy 来处理——后者会在整个 key 对象实现PartitionAware接口时显式忽略该情况。在源码中PartitionedMapTable.java 以partitioningAttributes和supportsPartitionPruning两个字段承载上述元数据前者记录参与分区策略的属性名列表见 partitioningAttributes()后者标记该表是否支持分区剪枝见 supportsPartitionPruning()。这两个标志由IMapSqlConnector在建表时计算并传入。RelNode 的分区信息传播对于某些/全部 RelNode优化器将使用其输入的分区信息输入是否分区哪些字段输入/输出行中的索引定义分区键为每个分区键生成分区键值列表的表达式该表达式可引用查询参数RexDynamicParam可使用SEARCH与Sarg特殊算子。RelNode 可剪枝性规则RelNode 可分为单输入与多输入两类单输入节点FullScanPhysicalRel、IndexScanMapPhysicalRel未来使用多输入节点JoinPhysicalRel、UnionPhysicalRel包装/支撑节点CalcPhysicalRel、AggregatePhysicalRel一般规则如下分析自上而下进行只有整条查询才能被标记为 Member Prunable 或不可剪枝更细粒度的让 DAG 的部分只在小范围集群上执行的优化大概率要等到 Jet 核心功能变更后再引入分析的最低层是 Scan 关系其可剪枝性取决于它的 Filter 与输入表Scan 的 Filter 把扫描限制在优化期可计算出的有限行数内时该 Scan 可剪枝聚合查询的可剪枝性取决于其 Scan 输入——因为聚合之上的 Filter 在聚合执行前就已应用所以聚合执行在已过滤的 Scan 之上若聚合的输入 Scan 可剪枝则聚合也可剪枝Join 只有在两个输入 Scan或嵌套 Join 或其它 rel都可剪枝时才可剪枝只有一个输入可剪枝则整条查询不可剪枝Union 与 Join 类似所有输入都必须可剪枝查询才可剪枝Calc 及其它支撑关系被视为 FullScan 的包装器其可剪枝性由 Scan 决定。各 Rel 可剪枝性汇总Rel可剪枝性FullScanPhysicalRel基于其 filter 可剪枝见 Filter Analysis 一节IndexScanPhysicalRel当前不支持未来按与 FullScanPhysicalRel 类似语义规划JoinPhysicalRel两个输入都可剪枝则可剪枝UnionPhysicalRel所有输入都可剪枝则可剪枝CalcPhysicalRelScan 输入可剪枝则可剪枝AggregatePhysicalRelScan 输入可剪枝则可剪枝这一规则表在源码中有直接对应实现HazelcastRelMdPrunability.java 是 Calcite 的 metadata handlerMetadataHandlerPrunabilityMetadata对每种 Rel 提供extractPrunability实现FullScanPhysicalRel只有当目标表是PartitionedMapTable且supportsPartitionPruning()为真时才继续分析分区列集合在无partitioningAttributes时退化为QueryPath.KEY即__key否则由表的partitioningAttributes映射到列名见 extractPrunability(FullScanPhysicalRel)IndexScanMapPhysicalRel与Aggregate代码中留有TODO: Implement当前返回空不可剪枝见 L118-L121 与 L130-L133Join暂时不传播可剪枝性返回空集合见 L144-L147Union遍历所有输入只要有一个输入返回空不可剪枝就中断并返回空否则合并各输入的表级候选见 L150-L169Sort、RelSubset转发输入的可剪枝性其余未提及的 Rel 默认不可剪枝见 L172-L182。从源码结构可以看出当前实现的完整度高于文档中标注的 MVPUnion 与整键__key场景已在元数据层落地而 Join 与 Aggregate 的可剪枝传播仍是 TODO。EXPLAIN PLAN 中的分区信息EXPLAIN PLAN 应当在扫描操作中包含两类谓词信息分区列如有不含表达式过滤器用于分区选择的表达式应单独报告此功能可能稍后实现。以文档示例 SQL 为例select count(*), sum(amount), priority from orders WHERE customerIdC2 group by priority当前未剪枝执行计划CalcPhysicalRel(expr#0..2[{inputs}], EXPR$0[$t1], EXPR$1[$t2], priority[$t0]) AggregateCombineByKeyPhysicalRel(group[{0}], EXPR$0[COUNT()], EXPR$1[SUM($1)]) AggregateAccumulateByKeyPhysicalRel(group[{0}]) FullScanPhysicalRel(table[[hazelcast, public, orders[projects[$7, $4], filter($1, _UTF-16LEC2)]]], discriminator[0])期望剪枝后执行计划CalcPhysicalRel(expr#0..2[{inputs}], EXPR$0[$t1], EXPR$1[$t2], priority[$t0]) AggregateCombineByKeyPhysicalRel(group[{0}], EXPR$0[COUNT()], EXPR$1[SUM($1)]) AggregateAccumulateByKeyPhysicalRel(group[{0}]) FullScanPhysicalRel(table[[hazelcast, public, orders[projects[$7, $4], filter($1, _UTF-16LEC2)]]], partitioningKey[$1], partitioningKeyValues[_UTF-16LEC2], discriminator[0])可以看到剪枝后的计划在FullScanPhysicalRel上新增了两个属性partitioningKey[$1]指明参与分区的字段与partitioningKeyValues[_UTF-16LEC2]指明具体的分区键值。执行计划测试可在 ExplainStatementTest.java 与 RelPrunabilityTest.java 中进一步查看验证方式。Filter 分析与变换Filter AnalysisFilter Analysis 与 Transformation 指对输入 Filter 进行变换与分析以判定 Filter 是否把查询天然限制到有限数量的分区若是则把 Filter 的相应部分提取并变换为能让其它 SQL 执行逻辑产出具体分区 ID 的形式。重要说明本章描述的是未来完整功能的设计方案。Member Pruning 的 MVP 阶段仅包含对使用AttributePartitioningStrategy的基础 filter 的支持且不支持 Aggregation、Join、Union对合取单个AND内的系列表达式filter 也仅有限支持。本章描述的是完整 Filter Analysis 的提议设计。Filter Analysis 术语Branch分支分支条件的结果如 OR、IN、BETWEEN、、 及其它可能匹配多行的算子。例如(comp1 IN (1,2,3))有三个分支comp1 1、comp1 2、comp1 3。Variant / Filtering Variant变体/过滤变体产生单个匹配的 filter 或一系列条件由 AND 连接或以其它方式无歧义地产生单个匹配例如comp1 1产生一个变体。FAFilter Analysis即分析输入 filter 的分区有界性并从中提取变体的整个过程的俗称。该过程本身可能不会严格按此顺序执行为了便于分析变换会在分析之前执行。Partition Boundness分区有界性SQL filter 把底层查询限制到有限数量分区的特性。它基于有限数量的 key 将产生有限数量的分区这一假设因此要判断 filter 是否有界需分析它允许通过过滤进来的离散 key 数量。总体设计主要目标是把输入 filter 变换为分区完备的 filter 对。第一步是把 filter 归一化为围绕 key 组件__key或从属性策略配置中提取的组件的析取/合取系列。例如a BETWEEN 1 AND 2 AND b BETWEEN 3 AND 4应变成输入的笛卡尔积如(A1,B1)、(A1,B2)、(A2,B1)、(A2,B2)——注意 A、B 在产生的元组中是有位置的依据策略中的指定。替代方案是以数值范围为基础因此用 BETWEEN 而非 EQUALS 作为基础算子。除基础功能外未来可考虑函数解包function unwrapping但floor、to_lower、ceiling等函数拥有开放式的输入集合难以确定或不适合迭代例如floor(__key) 1.0拥有近乎无穷的具体__key值。额外的步骤可以是消减重叠/取反表达式例如a IN (1,2,3,4,5) AND a 2应自动消除 1 作为 a 的可能变体。数据类型在 Filter Analysis 中的作用数据类型对分区有界性影响重大整数Integer整数范围天然有限除非显式把范围边界声明为 Infinity因此任何闭区间都会产生闭区间分区集合。但更大的范围会降低产出少于完整分区表的概率——默认情况下应限制为271若超过 271 个 key 受 filter 影响将实际覆盖整个集群除非终端用户把分区数设置得更高。浮点数Floating Point分区有界性分析理论可行但极易出 bug——FP 数不精确1.0最终可能是1.0000000096其二进制表示完全不同由于分区逻辑对 FP 数没有特殊处理1.000000096与1.00000095可能产生完全不同的分区 ID。日期时间DateTime分析与整数类似因为内部表示应为整数精确到微秒但比整数类型需要更高级的分析逻辑。字符串String对有限字符串和可能的有限字符串模式如正则^tes\w{1,1}$可进行分析。此外带有某种字符串长度限制算子的更高级正则也可分析例如LEN(__key) 9 AND __key LIKE test[0-9]est最多产生 10 个 keytest0est、test1est…test9est。算子Operator在 Filter Analysis 中的作用算子作用分析AND每个 AND 实例可能产生一个完整变体或开始一个变体OR分支的起点若所有子条件有界或与更高层条件共同形成有界条件则最终可能产生多个变体IN与 OR 类似可变换为一系列 ORBETWEEN与 IN 相同本质上是合并为一个算子的一系列 OR大于自身无界但与匹配的小于号连接后可形成有界条件仅限整数类型。即便不考虑 FP 表示问题 1.0 AND 2.0技术上也无限小于与大于号相同二者可共同形成有界条件等号对任何类型都是有界条件FP 类型除外LIKE若底层 filter 有界则可能有界分析大概率需要复杂逻辑Filter Analysis 的通用算法将 filter 反归一化为析取范式的合取系列例如从a 1 AND b IN (1,2)变为(a 1 AND b 1) OR (a 1 AND b 2)分析每个合取表达式的分区有界性——若 filter 限制了 key 的每个分区强制组件可以是完整 key或依据AttributePartitioningStrategy使用的部分组件则该 filter 被视为分区有界若所有合取表达式都有界——把它们变换为RexInputRef/RexDynamicParam表达式列表并与表名和 key/组件名关联把每个结果三元组Tuple3TableName, ColumnName, RexNode变换为一系列分区 ID并作为参数传给 Jet。Filter 反归一化Denormalization规则Filter 中的任意表达式可能产生 0 到 N 个变体取决于它是否包含 key 列OR 应形成析取式顶层 OR 本质上是系列 filterAND 形成单个合取组反归一化后展开为 1 个组。该组内每个成员都会被遍历并为每个成员产生若干变体完成后从每个成员组内的每个变体创建组合列表。例如对a 1 AND b IN (1,2)处理应得到 a[1] 与 b[1,2] 变体因此可产生的组合是a1b1和a1b2任何嵌套 OR 或 OR 类条件应产生基于 EQUALS 的变体系列例如b IN (1,2,3)产生b 1、b 2、b 3子级条件应产生局部变体随后与更高层条件连接。例如a 1 AND ((b 1) AND (c IN (1,2)))在最低层产生c 1、c 2进而产生(b 1 AND c 1)与(b 1 AND c 2)组合再与a 1组合不涉及分区 key 列的 AND 条件应从结果变换中排除。例如a 1 AND b 2 AND someCol 3中someCol 3可安全丢弃从变体列表中因为它无关紧要若 key 条件引用另一个列该子条件也应作为无效丢弃——例如a 1 AND b someCol是无界 filter任何 OR 的子条件也会使分支失效——例如a 1 AND (b 1 OR someCol 2)中someCol使b1作为有效 key filter 失效由于顶层存在完备性分析(b 1 OR someCol 2)为 b 产生零个子变体因此顶层也不会产生完整的 a-b 变体可能的变换把同一合取级别AND上的 与 算子合并为 OR 类条件例如b 20 AND b 23变成b 21 OR b 22。但这会限制对b 20 AND (b 25 OR b 21)这类查询的优化可能性处理 、 及其它无界算子的替代方案以范围range作为提取的产物而非 EQUALS 条件并按底层条件规则合并相应范围。例如对 ANDa 20 AND a 30就是把[20, inf)与(-inf, 30]合并为b [20, 30]。源码中的 Filter 提取实现当前 MVP 阶段的条件提取实现在 PartitionStrategyConditionExtractor.java 中。该类注释明确说明只支持简单的顶层 AND 算子以及单算子 filter例如keyComp1 ? AND keyComp2 ?__key ?其核心逻辑见 extractSubCondition仅处理AND与EQUALS两种SqlKind对 AND 逐操作数提取等值条件并合并为一个 variant对 EQUALS 则提取输入引用 常量/动态参数二元组见 extractEqualityCondition一侧必须是RexInputRef另一侧必须是RexDynamicParam或RexLiteral且列名必须在分区列集合内。最终在 extractCondition 中校验任何一个 variant 若未覆盖全部分区列则整个 filter 视为无界返回空集合。这正是文档中分区完备定义在代码层面的落地每个 variant 保证只产生单个分区键。该类文档注释也指出随着更复杂 filter 支持引入此类将会显著变化。针对提取器的单元测试见 PSConditionExtractorTest.java。SQL 侧支持扫描处理器的分区剪枝目标是对结果计划中所有可剪枝的FullScan得到精确的分区扫描集合。为达成此目标同时隔离每个具体连接器connector的实现计算过程被移到SqlConnector层扩展了SqlConnector接口的fullScanReader方法使其接受提取出的全部分区剪枝候选作为参数并以连接器专属方式计算Override Nonnull public Vertex fullScanReader( Nonnull DagBuildContext context, Nullable HazelcastRexNode predicate, Nonnull ListHazelcastRexNode projection, Nullable ListMapString, Expression? partitionPruningCandidates, // -- 新增参数 Nullable FunctionExExpressionEvalContext, EventTimePolicyJetSqlRow eventTimePolicyProvider)新参数partitionPruningCandidates是一个 map 列表其中对 filter 中出现的每一列列名映射到提取出的比较表达式。连接器专属实现应检查分区策略是否一般性适用若适用则把输入变换为表达式内层列表的列表每个内层表达式列表包含若干比较表达式若分区策略 key 是简单的该列表为单元素若 key 是复合的则为多元素。若有多个可剪枝 filter 谓词外层列表为多元素。该列表随后传给支持分区剪枝的对应扫描处理器 meta supplier。当前仅在 IMap 连接器上实现且所有表达式均受支持。IMap 连接器的具体实现IMap 侧的剪枝能力在 IMapSqlConnector.java 中体现剪枝能力判定supportsPartitionPruning若 MapConfig 配置了PartitioningAttributeConfigs即AttributePartitioningStrategy返回 true否则检查PartitioningStrategyConfig——未配置、或配置为DefaultPartitionStrategy实例或类名均可时为 true其余自定义策略为 false。这从代码层面印证了文档中支持AttributePartitioningStrategy、__key特殊处理的设计。候选回退分析fullScanReader若传入的partitionPruningCandidates为 null 但表存在分区属性说明查询未能用于 member pruning此时仍可尝试 scan 级分区剪枝——代码通过CalciteSqlOptimizerImpl.partitionStrategyCandidates重新获取候选并注释指出未来应复用各 RelNode 上的分析结果避免重复计算。生成扫描顶点L272-L281computeRequiredPartitionsToScan依据候选表达式列表计算出分区策略 分区表达式内层列表若内层列表非空被剪枝使用mapReader带所需分区信息否则退化为readMapP全量读取。随后与rowProjector顶点以isolated边相连。成员级剪枝LazyDefiningSpecificMemberPms见 LazyDefiningSpecificMemberPms.java是只会在持有给定分区键的节点上使用给定ProcessorSupplier的 meta-supplier它通过分区键表达式partitionKeyExprSupplier或参数索引partitionArgIndex从执行上下文求值出分区键再经getOwnerAddress解析出该分区的 owner 地址从而把处理器只部署到相关成员上见 L72-L75。这正是文档消除与查询无关成员目标的落地实现其注释还提示SQL 使用它时ExpectNothingProcessorSupplier可能被分区剪枝消除。成功案例示例假设有一个 IMapmap使用复合键{comp1, comp2, comp3}并应用了以comp1和comp2为属性的分区策略。有如下合成查询其 filter 与分区策略匹配SELECT * FROM map WHERE __key.comp1 1 AND __key.comp2 2IMap 专属fullScanReader收到如下 map 列表参数[{__key.comp1 Expression(__key.comp1 1)}, {__key.comp2 Expression(__key.comp2 2)}]经上述计算后fullScanReader实现应向支持分区剪枝的对应扫描处理器 meta supplier 传递如下表达式列表[[Expression(__key.comp1 1)], [Expression(__key.comp2 2)]]说明设计文档 20-sql-partition-pruning.md 的示例输出文本中两个表达式均为__key.comp1 2从上下文与源码推导应为分别对应comp1与comp2的两个等值表达式——此处按语义给出整理后的形式。由于comp1、comp2构成复合分区键外层列表包含两个内层列表每个内层列表对应一个分区列的等值条件。外层列表多元素两个分区列每个内层列表因等值条件而只有一个元素两个分区列都被等值约束因此查询被精确限制到唯一一个分区。端到端验证与测试标准执行计划测试单元测试将保证分区剪枝生成关于查询执行所需成员与分区的预期信息。对应测试位于RelPrunabilityTest.java验证各 Rel 的可剪枝性元数据PSConditionExtractorTest.java验证 filter 条件提取ExplainStatementTest.java验证 EXPLAIN PLAN 输出。端到端测试5 成员集群SqlPartitionPruningE2ETest.java 在 5 个成员的集群上见 beforeClass覆盖了丰富的剪枝场景简单剪枝键WHERE f0 2仅命中 1 个分区when_scanWithSimplePruningKey_then_prunable序列化格式同一场景对 Java 序列化、Portable、Compact 三种 key 格式分别验证when_scanWithSimplePortablePruningKey_then_prunable、when_scanWithSimpleCompactPruningKey_then_prunable未配置策略preparePrunableMap(emptyList(), ...)时查询不可剪枝when_scanWithoutDefinedStrategy_then_nonPrunable与源码supportsPartitionPruning判定一致复合剪枝键WHERE f0 2 AND f1 2命中 1 个分区when_scanWithCompoundPruningKey_then_prunablePartitionAware key整键实现PartitionAware时同样可剪枝when_keyWithNestedPartitionAwareKey_then_prunable、when_fullyComparePartitionAwareKeyWithNestedPAKey_then_prunable并验证了 NULL 键参数场景不可剪枝when_compoundSingleFieldNullKey_nonPrunableUNION ALL 传播自连接与两张表的 UNION ALL 均可剪枝并合并候选when_selfUnionAllForOrPredicateAndCompoundPruningKey_then_prunable、when_unionAllTwoMapsWithCompoundPruningKey_then_prunable只要有一张表不可剪枝整个查询即不可剪枝when_unionAllTwoMapsAndOneMapIsNotPrunable_then_nonPrunable与文档Union 所有输入都必须可剪枝规则一致。测试断言assertPrunability不仅校验命中分区数量还通过KEY_REQUIRED_PARTITIONSJobConfig 参数与 JobCoordinationService 反馈校验实际参与的分区与成员集合印证了精确分区集 成员消除两条目标。性能性能对比将在相同集群拓扑尤其多于 1 个成员理想情况 3-5 个、相同 IMap、相同数据与数据布局即相同分区策略下进行对同一批查询分别在有/无分区剪枝优化的情况下执行比较吞吐与延迟。Soak 测试SQL 查询的 Soak 测试应包含若干可进行分区剪枝的查询用例以检验它们在并发分区迁移等场景下的稳定性。进一步阅读设计文档原文docs/design/sql/20-sql-partition-pruning.md可剪枝性元数据HazelcastRelMdPrunability.java条件提取器PartitionStrategyConditionExtractor.java表元数据PartitionedMapTable.javaIMap 连接器IMapSqlConnector.java成员级剪枝 meta-supplierLazyDefiningSpecificMemberPms.java端到端测试SqlPartitionPruningE2ETest.java赞分享缓存KV存储消息队列流处理后端【免费下载链接】hazelcastHazelcast is a unified real-time data platform combining stream processing with a fast data store, allowing customers to act instantly on>项目地址https://gitcode.com/gh_mirrors/ha/hazelcast点击查看免费下载相关推荐Hazelcast Jet 分区剪枝Partition Pruning设计解析从成员剪枝到扫描分区剪枝Hazelcast Jet 分区剪枝Partition Pruning设计解析从成员剪枝到扫描分区剪枝 本文基于 docs/design/jet/025缓存KV存储消息队列流处理后端TiDB 表分区Table Partition设计与实现解析TiDB 表分区Table Partition设计与实现解析 表分区是 MySQL 用户广泛使用的一项核心能力本文基于 TiDB 仓库中的设计提案文档 d数据库分布式数据库后端OLAPMovement Pruning 细剪枝实战基于 Transformers 的 BERT 极端稀疏化微调剪枝全解析Movement Pruning 细剪枝实战基于 Transformers 的 BERT 极端稀疏化微调剪枝全解析 Movement Pruning运动剪枝推理引擎大模型上一篇3分钟掌握QKeyMapper解决游戏手柄与键鼠互转的终极指南下一篇TanStack Form React 中 useSelector从 Store 精确订阅表单状态的核心 Hook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Hazelcast SQL 分区剪枝（Partition Pruning）优化：设计与实现全解析
缓存KV存储消息队列流处理后端【免费下载链接】hazelcastHazelcast is a unified real-time data platform combining stream processing with a fast data store, allowing customers to act instantly on>项目地址https://gitcode.com/gh_mirrors/ha/hazelcast点击查看免费下载导读本文以 Hazelcast 仓库设计文档 docs/design/sql/20-sql-partition-pruning.md 为核心骨架系统讲解 SQL 引擎如何利用 IMap 的分区信息在优化阶段判定查询是否可剪枝prunable并把过滤条件转换为精确的分区 ID 集合从而只扫描必要的分区与成员、显著降低网络与 IO 开销。文章覆盖分区剪枝的术语体系、RelNode 可剪枝性规则、Filter 分析与变换算法、SqlConnector接口扩展以及 EXPLAIN PLAN 与测试标准并结合hazelcast-sql模块源码如HazelcastRelMdPrunability、PartitionStrategyConditionExtractor、IMapSqlConnector与端到端测试进行佐证。读完本文你将掌握 Hazelcast SQL 分区剪枝的完整原理、适用边界与底层调用链可直接用于理解与排查相关 SQL 执行计划。背景与动机在实际业务中针对大数据集的查询往往并不需要扫描全部数据。数据通常按分区组织查询只涉及其中一小部分分区同时Join、聚合等操作也能从数据如何分区这一信息中获益。利用该知识可以让查询运行得更快、消耗更少的资源网络、IO使具备分区剪枝资格的 SQL 查询在性能上可比肩使用PartitionPredicate的 Predicate API 查询。此外知道需要哪些分区还能把与查询无关的成员member从查询执行中完全剔除——这些成员上没有任何与查询相关的数据。这既减少了执行 DAG 的规模也降低了跨成员通信的开销。目标与非目标目标提升使用AttributePartitioningStrategy且过滤条件涉及其中定义属性的 IMap 查询性能。非目标明确不在本设计范围之内对使用 IMap__key但不满足转换为IMapSelectPlan条件、必须创建 Jet job 的查询做性能提升为除 IMap 之外的其它数据源提供分区剪枝未来可考虑对过滤条件做复杂的表达式变换以提取分区信息复杂场景下用户必须把谓词写成受支持的形式追踪属性之间的函数依赖由组成属性构造__key例如__key包含两个属性时将__key.a1X and __key.a2Y转换为__key(X,Y)。术语术语定义item / entry / row被视为整体的单个数据元素prunable有资格进行分区剪枝优化以下三个术语是整个设计的基石分区列Partitioning column影响给定 item 被分配到哪个分区的列/属性。分区键Partitioning key足以确定给定 item 所属分区的最小的分区列集合按包含关系最小。分区键集合Set of partitioning keys包含两类分区键的集合——由AttributePartitioningStrategy定义的分区键如果有以及__key。澄清说明对于 IMap分区列只能是 IMap key 的属性IMap value 的属性不能作为分区列。若 IMap 使用了AttributePartitioningStrategy分区列在函数上依赖于整个__key但为了简化SQL 优化器当前不追踪函数依赖而是假设__key与AttributePartitioningStrategy都定义了一个分区键。分区 ID 的计算会考虑这一点并对给定 IMap 使用正确的策略。分区完备表达式Partition-complete expression表达式E是分区完备的当存在分区键PK {partColumn1, ..., partColumnM}使表达式可变换为E partKeyExp1 OR partKeyExp2 OR ... OR partKeyExpN其中每个partKeyExpN的形式为partKeyExpN partColumn1Expr AND partColumn2Expr AND ... AND partColumnMExpr AND residualFilter要求对组成PK的每一个分区列都有一个子表达式partColumnMExpr的形式为partColumnM operator arguments支持的operator包括等值SEARCH带SargBETWEEN仅限整数类型首个版本不支持——只有对合理小范围才有意义arguments允许是字面量literal查询参数query parameter仅由上述参数和任意确定性函数构成的复杂表达式尤其不允许引用其它列residualFilter可以是任意表达式尤其可以为TRUE它可以引用任意列包括分区列本身。几点澄清范围分区如order_date between day1 and day2当前不支持只支持哈希/等值类分区E的每个 OR 分支可能使用不同分区键该场景当前不支持partCol1 partCol2 AND partCol2 constantX不属于分区完备但可通过常量传播变换为partCol1 constantX AND partCol2 constantX——这类变换超出本文档范围但可由 SQL 优化器现在或未来独立执行。技术设计等值分区与元数据等值分区假设IMap 本质是哈希表因此分区剪枝只支持基于等值equality的分区。范围分区如日期范围不支持这与哈希表的分区语义保持一致。提供给 SQL 优化器的分区元数据Calcite SQL 优化器需要知道 IMap 是如何分区的。IMap 的AttributePartitioningStrategy所包含的列清单将在 PartitionedMapTable 中可用注意__key是特殊情况需要通过对AttributePartitioningStrategy的扩展、或单独的专门 Partitioning Strategy 来处理——后者会在整个 key 对象实现PartitionAware接口时显式忽略该情况。在源码中PartitionedMapTable.java 以partitioningAttributes和supportsPartitionPruning两个字段承载上述元数据前者记录参与分区策略的属性名列表见 partitioningAttributes()后者标记该表是否支持分区剪枝见 supportsPartitionPruning()。这两个标志由IMapSqlConnector在建表时计算并传入。RelNode 的分区信息传播对于某些/全部 RelNode优化器将使用其输入的分区信息输入是否分区哪些字段输入/输出行中的索引定义分区键为每个分区键生成分区键值列表的表达式该表达式可引用查询参数RexDynamicParam可使用SEARCH与Sarg特殊算子。RelNode 可剪枝性规则RelNode 可分为单输入与多输入两类单输入节点FullScanPhysicalRel、IndexScanMapPhysicalRel未来使用多输入节点JoinPhysicalRel、UnionPhysicalRel包装/支撑节点CalcPhysicalRel、AggregatePhysicalRel一般规则如下分析自上而下进行只有整条查询才能被标记为 Member Prunable 或不可剪枝更细粒度的让 DAG 的部分只在小范围集群上执行的优化大概率要等到 Jet 核心功能变更后再引入分析的最低层是 Scan 关系其可剪枝性取决于它的 Filter 与输入表Scan 的 Filter 把扫描限制在优化期可计算出的有限行数内时该 Scan 可剪枝聚合查询的可剪枝性取决于其 Scan 输入——因为聚合之上的 Filter 在聚合执行前就已应用所以聚合执行在已过滤的 Scan 之上若聚合的输入 Scan 可剪枝则聚合也可剪枝Join 只有在两个输入 Scan或嵌套 Join 或其它 rel都可剪枝时才可剪枝只有一个输入可剪枝则整条查询不可剪枝Union 与 Join 类似所有输入都必须可剪枝查询才可剪枝Calc 及其它支撑关系被视为 FullScan 的包装器其可剪枝性由 Scan 决定。各 Rel 可剪枝性汇总Rel可剪枝性FullScanPhysicalRel基于其 filter 可剪枝见 Filter Analysis 一节IndexScanPhysicalRel当前不支持未来按与 FullScanPhysicalRel 类似语义规划JoinPhysicalRel两个输入都可剪枝则可剪枝UnionPhysicalRel所有输入都可剪枝则可剪枝CalcPhysicalRelScan 输入可剪枝则可剪枝AggregatePhysicalRelScan 输入可剪枝则可剪枝这一规则表在源码中有直接对应实现HazelcastRelMdPrunability.java 是 Calcite 的 metadata handlerMetadataHandlerPrunabilityMetadata对每种 Rel 提供extractPrunability实现FullScanPhysicalRel只有当目标表是PartitionedMapTable且supportsPartitionPruning()为真时才继续分析分区列集合在无partitioningAttributes时退化为QueryPath.KEY即__key否则由表的partitioningAttributes映射到列名见 extractPrunability(FullScanPhysicalRel)IndexScanMapPhysicalRel与Aggregate代码中留有TODO: Implement当前返回空不可剪枝见 L118-L121 与 L130-L133Join暂时不传播可剪枝性返回空集合见 L144-L147Union遍历所有输入只要有一个输入返回空不可剪枝就中断并返回空否则合并各输入的表级候选见 L150-L169Sort、RelSubset转发输入的可剪枝性其余未提及的 Rel 默认不可剪枝见 L172-L182。从源码结构可以看出当前实现的完整度高于文档中标注的 MVPUnion 与整键__key场景已在元数据层落地而 Join 与 Aggregate 的可剪枝传播仍是 TODO。EXPLAIN PLAN 中的分区信息EXPLAIN PLAN 应当在扫描操作中包含两类谓词信息分区列如有不含表达式过滤器用于分区选择的表达式应单独报告此功能可能稍后实现。以文档示例 SQL 为例select count(*), sum(amount), priority from orders WHERE customerIdC2 group by priority当前未剪枝执行计划CalcPhysicalRel(expr#0..2[{inputs}], EXPR$0[$t1], EXPR$1[$t2], priority[$t0]) AggregateCombineByKeyPhysicalRel(group[{0}], EXPR$0[COUNT()], EXPR$1[SUM($1)]) AggregateAccumulateByKeyPhysicalRel(group[{0}]) FullScanPhysicalRel(table[[hazelcast, public, orders[projects[$7, $4], filter($1, _UTF-16LEC2)]]], discriminator[0])期望剪枝后执行计划CalcPhysicalRel(expr#0..2[{inputs}], EXPR$0[$t1], EXPR$1[$t2], priority[$t0]) AggregateCombineByKeyPhysicalRel(group[{0}], EXPR$0[COUNT()], EXPR$1[SUM($1)]) AggregateAccumulateByKeyPhysicalRel(group[{0}]) FullScanPhysicalRel(table[[hazelcast, public, orders[projects[$7, $4], filter($1, _UTF-16LEC2)]]], partitioningKey[$1], partitioningKeyValues[_UTF-16LEC2], discriminator[0])可以看到剪枝后的计划在FullScanPhysicalRel上新增了两个属性partitioningKey[$1]指明参与分区的字段与partitioningKeyValues[_UTF-16LEC2]指明具体的分区键值。执行计划测试可在 ExplainStatementTest.java 与 RelPrunabilityTest.java 中进一步查看验证方式。Filter 分析与变换Filter AnalysisFilter Analysis 与 Transformation 指对输入 Filter 进行变换与分析以判定 Filter 是否把查询天然限制到有限数量的分区若是则把 Filter 的相应部分提取并变换为能让其它 SQL 执行逻辑产出具体分区 ID 的形式。重要说明本章描述的是未来完整功能的设计方案。Member Pruning 的 MVP 阶段仅包含对使用AttributePartitioningStrategy的基础 filter 的支持且不支持 Aggregation、Join、Union对合取单个AND内的系列表达式filter 也仅有限支持。本章描述的是完整 Filter Analysis 的提议设计。Filter Analysis 术语Branch分支分支条件的结果如 OR、IN、BETWEEN、、 及其它可能匹配多行的算子。例如(comp1 IN (1,2,3))有三个分支comp1 1、comp1 2、comp1 3。Variant / Filtering Variant变体/过滤变体产生单个匹配的 filter 或一系列条件由 AND 连接或以其它方式无歧义地产生单个匹配例如comp1 1产生一个变体。FAFilter Analysis即分析输入 filter 的分区有界性并从中提取变体的整个过程的俗称。该过程本身可能不会严格按此顺序执行为了便于分析变换会在分析之前执行。Partition Boundness分区有界性SQL filter 把底层查询限制到有限数量分区的特性。它基于有限数量的 key 将产生有限数量的分区这一假设因此要判断 filter 是否有界需分析它允许通过过滤进来的离散 key 数量。总体设计主要目标是把输入 filter 变换为分区完备的 filter 对。第一步是把 filter 归一化为围绕 key 组件__key或从属性策略配置中提取的组件的析取/合取系列。例如a BETWEEN 1 AND 2 AND b BETWEEN 3 AND 4应变成输入的笛卡尔积如(A1,B1)、(A1,B2)、(A2,B1)、(A2,B2)——注意 A、B 在产生的元组中是有位置的依据策略中的指定。替代方案是以数值范围为基础因此用 BETWEEN 而非 EQUALS 作为基础算子。除基础功能外未来可考虑函数解包function unwrapping但floor、to_lower、ceiling等函数拥有开放式的输入集合难以确定或不适合迭代例如floor(__key) 1.0拥有近乎无穷的具体__key值。额外的步骤可以是消减重叠/取反表达式例如a IN (1,2,3,4,5) AND a 2应自动消除 1 作为 a 的可能变体。数据类型在 Filter Analysis 中的作用数据类型对分区有界性影响重大整数Integer整数范围天然有限除非显式把范围边界声明为 Infinity因此任何闭区间都会产生闭区间分区集合。但更大的范围会降低产出少于完整分区表的概率——默认情况下应限制为271若超过 271 个 key 受 filter 影响将实际覆盖整个集群除非终端用户把分区数设置得更高。浮点数Floating Point分区有界性分析理论可行但极易出 bug——FP 数不精确1.0最终可能是1.0000000096其二进制表示完全不同由于分区逻辑对 FP 数没有特殊处理1.000000096与1.00000095可能产生完全不同的分区 ID。日期时间DateTime分析与整数类似因为内部表示应为整数精确到微秒但比整数类型需要更高级的分析逻辑。字符串String对有限字符串和可能的有限字符串模式如正则^tes\w{1,1}$可进行分析。此外带有某种字符串长度限制算子的更高级正则也可分析例如LEN(__key) 9 AND __key LIKE test[0-9]est最多产生 10 个 keytest0est、test1est…test9est。算子Operator在 Filter Analysis 中的作用算子作用分析AND每个 AND 实例可能产生一个完整变体或开始一个变体OR分支的起点若所有子条件有界或与更高层条件共同形成有界条件则最终可能产生多个变体IN与 OR 类似可变换为一系列 ORBETWEEN与 IN 相同本质上是合并为一个算子的一系列 OR大于自身无界但与匹配的小于号连接后可形成有界条件仅限整数类型。即便不考虑 FP 表示问题 1.0 AND 2.0技术上也无限小于与大于号相同二者可共同形成有界条件等号对任何类型都是有界条件FP 类型除外LIKE若底层 filter 有界则可能有界分析大概率需要复杂逻辑Filter Analysis 的通用算法将 filter 反归一化为析取范式的合取系列例如从a 1 AND b IN (1,2)变为(a 1 AND b 1) OR (a 1 AND b 2)分析每个合取表达式的分区有界性——若 filter 限制了 key 的每个分区强制组件可以是完整 key或依据AttributePartitioningStrategy使用的部分组件则该 filter 被视为分区有界若所有合取表达式都有界——把它们变换为RexInputRef/RexDynamicParam表达式列表并与表名和 key/组件名关联把每个结果三元组Tuple3TableName, ColumnName, RexNode变换为一系列分区 ID并作为参数传给 Jet。Filter 反归一化Denormalization规则Filter 中的任意表达式可能产生 0 到 N 个变体取决于它是否包含 key 列OR 应形成析取式顶层 OR 本质上是系列 filterAND 形成单个合取组反归一化后展开为 1 个组。该组内每个成员都会被遍历并为每个成员产生若干变体完成后从每个成员组内的每个变体创建组合列表。例如对a 1 AND b IN (1,2)处理应得到 a[1] 与 b[1,2] 变体因此可产生的组合是a1b1和a1b2任何嵌套 OR 或 OR 类条件应产生基于 EQUALS 的变体系列例如b IN (1,2,3)产生b 1、b 2、b 3子级条件应产生局部变体随后与更高层条件连接。例如a 1 AND ((b 1) AND (c IN (1,2)))在最低层产生c 1、c 2进而产生(b 1 AND c 1)与(b 1 AND c 2)组合再与a 1组合不涉及分区 key 列的 AND 条件应从结果变换中排除。例如a 1 AND b 2 AND someCol 3中someCol 3可安全丢弃从变体列表中因为它无关紧要若 key 条件引用另一个列该子条件也应作为无效丢弃——例如a 1 AND b someCol是无界 filter任何 OR 的子条件也会使分支失效——例如a 1 AND (b 1 OR someCol 2)中someCol使b1作为有效 key filter 失效由于顶层存在完备性分析(b 1 OR someCol 2)为 b 产生零个子变体因此顶层也不会产生完整的 a-b 变体可能的变换把同一合取级别AND上的 与 算子合并为 OR 类条件例如b 20 AND b 23变成b 21 OR b 22。但这会限制对b 20 AND (b 25 OR b 21)这类查询的优化可能性处理 、 及其它无界算子的替代方案以范围range作为提取的产物而非 EQUALS 条件并按底层条件规则合并相应范围。例如对 ANDa 20 AND a 30就是把[20, inf)与(-inf, 30]合并为b [20, 30]。源码中的 Filter 提取实现当前 MVP 阶段的条件提取实现在 PartitionStrategyConditionExtractor.java 中。该类注释明确说明只支持简单的顶层 AND 算子以及单算子 filter例如keyComp1 ? AND keyComp2 ?__key ?其核心逻辑见 extractSubCondition仅处理AND与EQUALS两种SqlKind对 AND 逐操作数提取等值条件并合并为一个 variant对 EQUALS 则提取输入引用 常量/动态参数二元组见 extractEqualityCondition一侧必须是RexInputRef另一侧必须是RexDynamicParam或RexLiteral且列名必须在分区列集合内。最终在 extractCondition 中校验任何一个 variant 若未覆盖全部分区列则整个 filter 视为无界返回空集合。这正是文档中分区完备定义在代码层面的落地每个 variant 保证只产生单个分区键。该类文档注释也指出随着更复杂 filter 支持引入此类将会显著变化。针对提取器的单元测试见 PSConditionExtractorTest.java。SQL 侧支持扫描处理器的分区剪枝目标是对结果计划中所有可剪枝的FullScan得到精确的分区扫描集合。为达成此目标同时隔离每个具体连接器connector的实现计算过程被移到SqlConnector层扩展了SqlConnector接口的fullScanReader方法使其接受提取出的全部分区剪枝候选作为参数并以连接器专属方式计算Override Nonnull public Vertex fullScanReader( Nonnull DagBuildContext context, Nullable HazelcastRexNode predicate, Nonnull ListHazelcastRexNode projection, Nullable ListMapString, Expression? partitionPruningCandidates, // -- 新增参数 Nullable FunctionExExpressionEvalContext, EventTimePolicyJetSqlRow eventTimePolicyProvider)新参数partitionPruningCandidates是一个 map 列表其中对 filter 中出现的每一列列名映射到提取出的比较表达式。连接器专属实现应检查分区策略是否一般性适用若适用则把输入变换为表达式内层列表的列表每个内层表达式列表包含若干比较表达式若分区策略 key 是简单的该列表为单元素若 key 是复合的则为多元素。若有多个可剪枝 filter 谓词外层列表为多元素。该列表随后传给支持分区剪枝的对应扫描处理器 meta supplier。当前仅在 IMap 连接器上实现且所有表达式均受支持。IMap 连接器的具体实现IMap 侧的剪枝能力在 IMapSqlConnector.java 中体现剪枝能力判定supportsPartitionPruning若 MapConfig 配置了PartitioningAttributeConfigs即AttributePartitioningStrategy返回 true否则检查PartitioningStrategyConfig——未配置、或配置为DefaultPartitionStrategy实例或类名均可时为 true其余自定义策略为 false。这从代码层面印证了文档中支持AttributePartitioningStrategy、__key特殊处理的设计。候选回退分析fullScanReader若传入的partitionPruningCandidates为 null 但表存在分区属性说明查询未能用于 member pruning此时仍可尝试 scan 级分区剪枝——代码通过CalciteSqlOptimizerImpl.partitionStrategyCandidates重新获取候选并注释指出未来应复用各 RelNode 上的分析结果避免重复计算。生成扫描顶点L272-L281computeRequiredPartitionsToScan依据候选表达式列表计算出分区策略 分区表达式内层列表若内层列表非空被剪枝使用mapReader带所需分区信息否则退化为readMapP全量读取。随后与rowProjector顶点以isolated边相连。成员级剪枝LazyDefiningSpecificMemberPms见 LazyDefiningSpecificMemberPms.java是只会在持有给定分区键的节点上使用给定ProcessorSupplier的 meta-supplier它通过分区键表达式partitionKeyExprSupplier或参数索引partitionArgIndex从执行上下文求值出分区键再经getOwnerAddress解析出该分区的 owner 地址从而把处理器只部署到相关成员上见 L72-L75。这正是文档消除与查询无关成员目标的落地实现其注释还提示SQL 使用它时ExpectNothingProcessorSupplier可能被分区剪枝消除。成功案例示例假设有一个 IMapmap使用复合键{comp1, comp2, comp3}并应用了以comp1和comp2为属性的分区策略。有如下合成查询其 filter 与分区策略匹配SELECT * FROM map WHERE __key.comp1 1 AND __key.comp2 2IMap 专属fullScanReader收到如下 map 列表参数[{__key.comp1 Expression(__key.comp1 1)}, {__key.comp2 Expression(__key.comp2 2)}]经上述计算后fullScanReader实现应向支持分区剪枝的对应扫描处理器 meta supplier 传递如下表达式列表[[Expression(__key.comp1 1)], [Expression(__key.comp2 2)]]说明设计文档 20-sql-partition-pruning.md 的示例输出文本中两个表达式均为__key.comp1 2从上下文与源码推导应为分别对应comp1与comp2的两个等值表达式——此处按语义给出整理后的形式。由于comp1、comp2构成复合分区键外层列表包含两个内层列表每个内层列表对应一个分区列的等值条件。外层列表多元素两个分区列每个内层列表因等值条件而只有一个元素两个分区列都被等值约束因此查询被精确限制到唯一一个分区。端到端验证与测试标准执行计划测试单元测试将保证分区剪枝生成关于查询执行所需成员与分区的预期信息。对应测试位于RelPrunabilityTest.java验证各 Rel 的可剪枝性元数据PSConditionExtractorTest.java验证 filter 条件提取ExplainStatementTest.java验证 EXPLAIN PLAN 输出。端到端测试5 成员集群SqlPartitionPruningE2ETest.java 在 5 个成员的集群上见 beforeClass覆盖了丰富的剪枝场景简单剪枝键WHERE f0 2仅命中 1 个分区when_scanWithSimplePruningKey_then_prunable序列化格式同一场景对 Java 序列化、Portable、Compact 三种 key 格式分别验证when_scanWithSimplePortablePruningKey_then_prunable、when_scanWithSimpleCompactPruningKey_then_prunable未配置策略preparePrunableMap(emptyList(), ...)时查询不可剪枝when_scanWithoutDefinedStrategy_then_nonPrunable与源码supportsPartitionPruning判定一致复合剪枝键WHERE f0 2 AND f1 2命中 1 个分区when_scanWithCompoundPruningKey_then_prunablePartitionAware key整键实现PartitionAware时同样可剪枝when_keyWithNestedPartitionAwareKey_then_prunable、when_fullyComparePartitionAwareKeyWithNestedPAKey_then_prunable并验证了 NULL 键参数场景不可剪枝when_compoundSingleFieldNullKey_nonPrunableUNION ALL 传播自连接与两张表的 UNION ALL 均可剪枝并合并候选when_selfUnionAllForOrPredicateAndCompoundPruningKey_then_prunable、when_unionAllTwoMapsWithCompoundPruningKey_then_prunable只要有一张表不可剪枝整个查询即不可剪枝when_unionAllTwoMapsAndOneMapIsNotPrunable_then_nonPrunable与文档Union 所有输入都必须可剪枝规则一致。测试断言assertPrunability不仅校验命中分区数量还通过KEY_REQUIRED_PARTITIONSJobConfig 参数与 JobCoordinationService 反馈校验实际参与的分区与成员集合印证了精确分区集 成员消除两条目标。性能性能对比将在相同集群拓扑尤其多于 1 个成员理想情况 3-5 个、相同 IMap、相同数据与数据布局即相同分区策略下进行对同一批查询分别在有/无分区剪枝优化的情况下执行比较吞吐与延迟。Soak 测试SQL 查询的 Soak 测试应包含若干可进行分区剪枝的查询用例以检验它们在并发分区迁移等场景下的稳定性。进一步阅读设计文档原文docs/design/sql/20-sql-partition-pruning.md可剪枝性元数据HazelcastRelMdPrunability.java条件提取器PartitionStrategyConditionExtractor.java表元数据PartitionedMapTable.javaIMap 连接器IMapSqlConnector.java成员级剪枝 meta-supplierLazyDefiningSpecificMemberPms.java端到端测试SqlPartitionPruningE2ETest.java赞分享缓存KV存储消息队列流处理后端【免费下载链接】hazelcastHazelcast is a unified real-time data platform combining stream processing with a fast data store, allowing customers to act instantly on>项目地址https://gitcode.com/gh_mirrors/ha/hazelcast点击查看免费下载相关推荐Hazelcast Jet 分区剪枝Partition Pruning设计解析从成员剪枝到扫描分区剪枝Hazelcast Jet 分区剪枝Partition Pruning设计解析从成员剪枝到扫描分区剪枝 本文基于 docs/design/jet/025缓存KV存储消息队列流处理后端TiDB 表分区Table Partition设计与实现解析TiDB 表分区Table Partition设计与实现解析 表分区是 MySQL 用户广泛使用的一项核心能力本文基于 TiDB 仓库中的设计提案文档 d数据库分布式数据库后端OLAPMovement Pruning 细剪枝实战基于 Transformers 的 BERT 极端稀疏化微调剪枝全解析Movement Pruning 细剪枝实战基于 Transformers 的 BERT 极端稀疏化微调剪枝全解析 Movement Pruning运动剪枝推理引擎大模型上一篇3分钟掌握QKeyMapper解决游戏手柄与键鼠互转的终极指南下一篇TanStack Form React 中 useSelector从 Store 精确订阅表单状态的核心 Hook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考