postgresql中的数据分区

目录

环境

文档用途

详细信息

环境

系统平台：N/A

版本：10.0,9.6,8.4

文档用途

本文旨在用于指导数据分区和数据分区方法。

详细信息

什么是数据分区？
对于具有极大表的数据库，分区对于数据库设计人员而言是一种惯用的技巧，可以提高数据库性能并使维护更加容易。PostgreSQL数据库中允许的最大表大小为32TB，但是除非它将来在未发明的计算机上运行，否则性能问题可能出现在仅达到总大小的百分之一也就是300GB左右的表上。
分区将表拆分为多个表，并且通常以一种访问表的应用程序注意不到任何差异的方式完成。通过将表拆分为多个表，我们的想法是允许执行查询必须扫描更小的表和索引以查找所需的数据。无论索引策略的效率如何，扫描50GB表的索引总是比500GB表的索引快得多。而且这也适用于表扫描，因为有时表扫描是不可避免的。
在将分区表引入查询规划器时，查询规划器本身有一些事情需要了解和理解。在实际执行任何查询之前，查询规划器将采用查询并规划出访问数据的最有效方式。通过将数据分成不同的表，规划器可以根据每个表包含的内容决定要访问哪些表以及要完全忽略哪些表。
这是通过向分割表添加约束来定义每个表中允许的数据来完成的，并且通过良好的设计，我们可以让查询规划器扫描一小部分数据而不是整个数据。

表应该分区吗？
如果做得好，分区可以大大提高表上的性能，但如果做错了或不需要，它可能会使性能变差，甚至无法使用。

表有多大？
在分区成为一个解决方案之前，没有真正的强硬规则来确定表必须有多大，但是基于数据库访问趋势，数据库用户和管理员将开始看到特定表的性能随着它变大而开始降低。一般来说，只有当有人说“因为表太大而无法做X”时才应考虑分区。对于某些主机，200GB可能是正确的分区时间，对于其他主机，可能达到1TB才进行分区。
如果确定表“太大”，则应该查看访问模式。通过了解访问数据库的应用程序，或通过监视日志和生成类似PDR的查询报告，我们可以看到如何访问表，并且根据访问方式，我们可以选择良好的分区策略。

表膨胀是一个问题吗？
更新和删除的行会导致最终需要清理的dead tuple。无论是手动还是自动vacuum表，都会遍历表中的每一行，并确定是否要回收或单独使用。表越大，此过程所需的时间越长，使用的系统资源就越多。即使90%的表的数据不变，每次运行vacuum时都必须对其进行扫描。对表进行分区有助于减少进行vacuum的表，减少需要扫描的不变数据量，减少整体vacuum时间，以及为用户访问释放更多系统资源。

如果有数据，如何删除数据？
如果按计划删除数据，例如删除并存档超过4年的数据，这可能会导致大量命中删除语句，这些语句可能需要运行一段时间才能完成，并且如前所述，创建的dead tuple需要vacuum。如果实现了良好的分区策略，则可以将具有vacuum维护的多小时DELETE语句转换为旧的月表上的一分钟的DROP TABLE语句，实现0vacuum维护。

表应该如何分区？
访问模式的键位于WHERE子句和JOIN条件中。每当查询指定WHERE和JOIN子句中的列时，它就会告诉数据库“这是我想要的数据”。与设计针对这些子句的索引非常相似，分区策略依赖于将这些列作为目标来分隔数据，并使查询访问尽可能少的分区。
例子：
一个事务表，其日期列始终在where子句中使用。
包含位置列的客户表，例如始终在where子句中使用的居住国家/地区

更多详细信息请登录【瀚高技术支持平台】查看

https://support.highgo.com/#/index/docContent/1200e2540430e8ac