2011-05-24 313 views
17

我正在对包含时态数据的非常大的表进行分区,并考虑应该使分区达到什么粒度。 Postgres partition documentation声称“大量的分区可能会大大增加查询计划时间”,并建议将分区与“高达大约一百个”分区一起使用。Postgres中有多少个表分区太多?

假设我的表格包含十年的数据,如果按星期划分,我最终会有超过500个分区。在我排除此问题之前,我想更好地了解分区数量对查询计划时间的影响。有没有人对此进行过基准测试,或者是否有人了解这是如何在内部工作的?

+0

我不能评论Postgres,但不会每月分区更有意义吗? – 2011-05-24 01:17:40

+0

他们几乎肯定会;我每周都会选择一个更实际的数字。人们可以考虑20年以上的每月分区。我主要对约束感兴趣,以及它们之间有什么区别,即50个Vs. 100个分区。 – DNS 2011-05-24 01:42:35

+0

基于每个分区的行数,RBDMS经常存在“经验法则”。对于SQL服务器,它大约有2000万行 – 2011-05-24 01:50:03

回答

10

的查询规划必须做的查询中使用的表的每个分区的约束信息的线性搜索,找出哪些实际参与 - 具有所需的请求的数据行的人。计划者考虑的查询计划数随着您加入更多表而呈指数增长。因此,线性搜索加起来足够麻烦的确切时间取决于查询的复杂性。联接越多,就越会受到这个影响。 “高达一百”的数字来自于指出查询规划时间即使在围绕该点的简单查询中也增加了不少的时间。特别是在Web应用程序中,响应时间延迟很重要,这是一个问题;从而警告。

你能支持500吗?当然。但是您将搜索每个涉及该优化器考虑的表的每个查询计划的500个检查约束中的每一个。如果查询计划时间不是您关心的问题,那么也许您不在乎。但是大多数网站最终不喜欢花费在用多个分区进行查询计划上的时间比例,这就是为什么每月分区是大多数数据集标准的原因之一。您可以轻松存储10年的数据,每月进行分区,然后再开始进入计划开销明显的地方。

0

如果您不想信任编写代码的PostgreSQL开发人员,那么我建议您自己亲自尝试一下,并运行一些示例查询,并使用不同的分区方案对其进行解释分析和计时。任何情况下,您的特定硬件和软件配置都可能主导任何答案。

我假设查询优化器用来确定要使用的连接和限制的行优化缓存与每个分区一起存储,因此它可能需要加载和读取每个分区的部分来计划查询。

+1

我相信开发者,但他们的警告非常模糊,所以我想更好地理解它。我的问题,就像大多数Stack Overflow一样,被问到如果有人已经知道答案,我不必花费数小时建立一个代表性的测试设置来重现他们的工作。 – DNS 2011-05-24 03:42:40

+1

@DNS它很模糊,因为它取决于您的硬件和软件配置,数据和查询。一个人适合的答案不适合另一个人。 SQL很微妙。 – 2011-05-24 03:57:46

1

每个表分区在文件系统上占用一个inode。 “非常大”是一个相对术语,取决于您选择的文件系统的性能特征。如果你想要明确的性能基准,你可以从操作系统和FS选择的邮件系统的各种性能基准。一般来说,我不会担心它,直到你进入成千上万到数十万个表空间(在FreeBSD的UFS2上使用dirhash会获胜)。还要注意,这个相同的限制适用于PostgreSQL中的DATABASES,TABLES或任何其他文件系统支持的数据库对象。

4

“大量的分区可能会大大增加查询计划时间”,并建议将分区与“最多一百个”分区一起使用。

因为每个额外的分区通常都与检查约束有关,这将导致规划者想知道哪些分区需要查询。在最好的情况下,计划者会发现你只打到一个分区,并且完全摆脱了步骤append

行的方面,并作为DNS和赛斯指出,你milage将与硬件的不同而不同。一般来说,虽然,有查询1M行的表和一个10M行的表之间没有显著差异 - 使用你最该指数特别是如果你的硬盘驱动器允许快速随机访问,如果它的集群(见cluster语句)经常打。