IE 如果我们有一个有 400 万行的表。
其中有一个STATUS
可以采用以下值的字段:TO_WORK
,BLOCKED
或WORKED_CORRECTLY
.
您是否会在一个只会更改一次的字段上进行分区(大多数时候从 to_work 到 working_correctly)?你会创建多少个分区?
IE 如果我们有一个有 400 万行的表。
其中有一个STATUS
可以采用以下值的字段:TO_WORK
,BLOCKED
或WORKED_CORRECTLY
.
您是否会在一个只会更改一次的字段上进行分区(大多数时候从 to_work 到 working_correctly)?你会创建多少个分区?
分区中的绝对行数不是最有用的指标。你真正想要的是一个随着表的增长而稳定的列,并且它提供了分区的潜在好处。它们是:可用性、表空间管理和性能。
例如,您的示例列具有三个值。这意味着您可以拥有三个分区,这意味着您可以拥有三个表空间。因此,如果表空间损坏,您将丢失三分之一的数据。分区是否使您的表更可用?并不真地。
添加或删除分区可以更轻松地管理大量数据。但是您是否有可能删除所有状态为的行WORKED_CORRECTLY
?不大可能。分区是否使您的表更易于管理?并不真地。
分区的性能优势来自查询修剪,优化器可以立即对表的块进行折扣。现在每个分区有 130 万行。所以即使你查询STATUS='WORKED_CORRECTLY'
你仍然有大量的记录要筛选。而且很有可能,任何不涉及 STATUS 的查询的性能都会比未分区表的性能差。分区是否让您的表更高效?可能不是。
到目前为止,我一直假设您的分区是均匀分布的。但你的最后一个问题表明情况并非如此。大多数行 - 如果不是全部 - 行将在WORKED_CORRECTLY
. 因此,与其他分区相比,该分区将变得巨大,而从分区中受益的机会变得更加渺茫。
最后,您提出的方案不是弹性的。作为当前卷,每个分区将有 130 万行。当您的表总共增长到 4000 万行时,每个分区将容纳 1330 万行。这是不好的。
那么,什么是分区键的好候选呢?一种产生大量分区,一种是分区大小大致相等,一种是键的值不太可能改变,一种是值在底层对象的生命周期中具有某种意义,最后一种是在针对表运行的大量查询中很有用。
这就是为什么像 DATE_CREATED 这样的数据仓库中事实表分区的流行选择。它在一系列粒度(通常选择日、月或年)中生成合理数量的分区。在给定的时间跨度内,我们得到的记录数量大致相同。数据加载和数据归档通常是根据年龄(即创建日期)来完成的。BI 查询几乎总是包含 TIME 维度。
表中的行数通常不是用于确定是否以及如何对表进行分区的重要指标。
你想解决什么问题?您是否正在尝试提高查询性能?数据加载的性能?清除数据的性能?
假设您正在尝试提高查询性能?您的所有查询是否在列上都有谓词STATUS
?他们是在做单行查找吗?或者您是否希望您的查询扫描整个分区?