关于表分区
Apache Cloudberry 允许您通过表分区将大型表逻辑地划分为更小、更易于管理的部分。这可以显著提高查询性能,因为查询优化器可以只扫描必要的数据,而不是整个表。分区是一种逻辑划分;它不会改变表数据在段上的物理分布。
有关如何创建和管理分区表,请参阅创建和管理分区表。
为什么使用表分区
分区可以提供多项优势,特别是对于超大型表(例如,超出数据库服务器物理内存的表):
- 提高查询性能:当大部分频繁访问的行位于单个分区或少量分区中时,查询运行速度会快得多。分区就像索引的更高层级,使得索引的关键部分更可能驻留在内存中。
- 高效扫描:当查询或更新访问单个分区的很大一部分时,对该分区的顺序扫描可能比使用索引更高效,因为使用索引会涉及对整个表的随机访问读取。
- 更快的数据管理:通过添加或删除分区,可以快速执行批量加载和删除操作。
DROP TABLE
分区或ALTER TABLE DETACH PARTITION
等操作比批量DELETE
操作快得多,并且避免了VACUUM
的开销。 - 数据分层:通过管理分区,可以将很少使用的数据迁移到更便宜、更慢的存储介质。
分区方法
Apache Cloudberry 支持以下表分区方法:
- 范围分区:表被划分为由一个或多个键列定义的“范围”。分配给不同分区的值范围之间没有重叠。例如,您可以按日期范围或业务对象标识符范围进行分区。每个范围的下限是包含的,上限是独占的。
- 列表分区:表通过明确列出每个分区中出现的键值进行分区。例如,按销售区域或产品线进行分区。
- 哈希分 区:表通过为每个分区指定模数和余数进行分区。每个分区都包含其分区键的哈希值除以模数后产生指定余数的行。
这些方法可以组合成多级分区设计,例如,在第一级使用日期范围分区,并在子级使用列表分区。(源文档中的一个示例图说明了使用日期范围和列表分区的多级设计)。
分区表结构
在 Apache Cloudberry 中对表进行分区时:
- 您定义的主表(分区表)是一个“虚拟”表;它本身不存储数据。
- 实际数据存储在各个分区中,这些分区是与分区表关联的普通表。每个分区根据其分区边界存储数据的子集。
- 插入到分区表中的行会根据分区键列自动路由到正确的分区。如果某行的分区键被更新,使其不再符合其原始分区的边界,Apache Cloudberry 将尝试将其移动到正确的分区。
- 您在使用
CREATE TABLE
命令中的PARTITION BY
子句创建表时定义分区。这将创建一个顶级根分区表,它可以有一个或多个级别的子表(分区)。紧邻子表上方的表是它的父表。叶分区位于层次结构的底部并保存数据;同一层次结构中的叶分区可以位于不同的深度。 - Apache Cloudberry 会自动为每个分区创建不同的分区约束,限制它可以包含的数据。查询优化器使用这些约束来确定要为给定查询扫描哪些分区。
- 分区本身可以定义为分区表,从而导致子分区。
- 所有分区必须与其父分区具有相同的列,但它们可以拥有自己的不同索引、约束和默认值。
- 分区也可以是外部表或外表,但您必须确保其内容满足分区规则。外表还有其他限制。
决定分区策略
考虑以下问题以确定分区是否是可行的策略:
- 表是否足够大? 分区有利于包含数百万或数十亿记录的大型事实表。对于小表,管理开销可能超过收益。
- 您是否遇到不令人满意的性能? 如果查询速度低于预期,则应考虑分区。
- 您的查询谓词是否有可识别的访问模式? 查找在
WHERE
子句中一致使用的列。例如,如果查询经常按日期过滤,日期分区设计可能是有益的。如果按区域访问,请考虑列表分区。 - 您的数据仓库是否维护历史数据窗口? 如果您需要保留特定时期的数据(例如,最近十二个月),分区(例如,按月)允许您轻松删除最旧的分区并添加新分区。
- 数据是否可以分成大致相等的部分? 选择尽可能均匀地划分数据的标准。如果分区具有大致相等的记录,则查询性能可以与分区数量成比例地提高(假设设计支持查询条件)。
提示
- 避免过度分区:创建过多分区可能会降低管理和维护任务(如清理、段恢复和集群扩展)的速度。
- 确保分区消除:除非查询优化器可以根据查询谓词消除分区,否则分区不会提高查询性能。扫描每个分区的查询将运行得更慢。务必检查
EXPLAIN
计划。 - 多级分区注意事项:对多级分区要小心,因为分区文件的数量会非常快速地增长,这可能会影响系统可管理性。例如,按 1000 天和 1000 个城市进行分区会创建一百万个分区。如果表有 100 列并且是列式存储,这可能意味着每个段有 1 亿个文件。考虑使用带有位图索引的单级分区作为替代方案,并始终测试性能。
分区设计的最佳实践
精心设计分区非常重要,否则可能会对查询规划和执行性能产生负面影响。
-
分区键选择:
- 选择最常出现在查询
WHERE
子句中的列,以启用分区裁剪。 - 考虑
PRIMARY KEY
或UNIQUE
约束的要求,这可能会影响键的选择。 - 考虑数据删除需求;设计分区时,应将要一起删除的数据放在单个分区中,以便快速分离。
- 选择最常出现在查询
-
分区数量:
- 分区过少:可能导致索引过大、数据局部性差以及缓存命中率低。
- 分区过多