在 Greenplum DB [大数据] 上选择分区策略的更好实践

Question

我想知道是否有人有任何通用指南（除了反复试验），用于为 Greenplum 中的一系列查询类型定义最佳分区/索引的良好策略？

Greenplum 对他们的管理指南有一些建议......但事实是，这几乎是 postgres 文档的复制粘贴，虽然其中一些建议似乎很明显（IE：当表太大而无法放入内存时进行分区)，仅仅定义一个好的策略来实现这一点是不够的。

通常 Greenplum 数据库有非常大的表（超过数百 GB），虽然硬件是专门为这种用途选择的，但大多数时候我在处理非常大的数据库时遇到了麻烦（IE：曾经有一个包含 60 个字段的表和超过 2 亿行的数据库，每天增加 4-8 百万个注册表）。

我知道选择合适的分区有一些技巧，比如选择可预测的范围，这些范围将以几乎相等的大小分隔（如日期范围）。但还有一个事实是，当我尝试依赖索引的任何其他数据库时，Greenplum 通过给予某些设置更大的权重来完全不鼓励它们，比如它的随机页面成本，因此根本不使用索引。

但我读过一些完全适得其反的情况：假设您有三个节点，每个节点 64GB 内存，根据 GP，您不应该分区，直到表超过 192，但由于不使用索引，您最终将 seq 扫描每个节点高达 64gb！ --- 虽然这仍然可以很快，但如果你强制使用索引，你可以从 20 多秒减少到几毫秒。

另一种已知情况是，在分区时，开销使查询比应有的速度慢很多。

那么，回到原来的问题：
有人对如何定义分区/索引策略有任何好的、坚定的建议吗？
使用我们的一些 ETL，来自源的测试查询可能需要半小时到一整小时，因此跟踪和错误确实会降低生产力。

谢谢。

Answer 1

我认为您的问题的答案不太依赖于数学，而更多地取决于您的用户将如何访问该表。对于日期范围分区，如果用户通常会查找一天的数据，那么每日分区是有意义的。如果用户通常查询更长的日期范围，那么每日分区只会增加开销。 Greenplum DB 表中的每个分区或子分区都被视为一个单独的表（因此文件系统上的一个单独文件），因此您必须扫描的分区越多以满足查询，您需要访问的打开文件就越多。了解您的用户希望如何访问数据，这将为您提供有关可能的分区策略的更好线索。

混合分区策略也很有用。某些用例会支持一个表，其中有最近一周/一个月的每日分区，然后让较旧的分区覆盖更长的时间范围，因为它们访问频率较低，通常用于报告/分析查询而不是行查找或类似查询。

就索引而言，虽然 Greenplum DB 的优化器偏爱表扫描而不是索引访问，但在某些地方索引是有意义的。在某些情况下，我对位图索引很幸运。

不幸的是，GPDB 的调优与其他数据库一样仍然是一种艺术形式，因此可能不可避免地需要进行一定程度的反复试验。