我需要知道是否有人有任何一般指导（超出试验和错误），为Greenplum中的一系列查询类型定义一个优化的分区/索引策略？
Greenplum对他们的管理指南有一些建议...但事实是，它几乎是来自postgres文档的复制粘贴，虽然它的一些建议似乎很明显（IE：分区，当一个表太大而不适合内存），仅仅定义一个实现这一目标的良好策略是不够的。
通常Greenplum数据库有非常大的表（超过数百GB），虽然硬件是专门为这种用途选择的，但大多数时候我遇到了很大的数据库（IE：一次）有一个包含60个字段表和超过20亿行的数据库，每天增加4-8百万个注册表的数量。）
我知道有一些技术可以选择合适的分区，例如选择可以分隔几乎相同大小的可预测范围（如日期范围）。但事实上，虽然我试图依赖于任何其他数据库索引，但Greenplum通过对某些设置给予更大的权重（例如随机页面成本）来完全劝阻它们，以便根本不使用索引。
但是我已经阅读了一些完全适得其反的情况：想象一下你有三个节点，每个64GB内存，根据GP你不应该分区，直到表超过192，但由于索引没有使用你'' ll最终seq扫描每个节点高达64gb！ ---虽然这仍然很快，但如果你强制使用索引，你可以从20秒以上下降到几毫秒。
另一个已知的情况是，在分区时，开销会使查询慢得多。
所以，回到最初的问题：
有没有人对如何定义分区/索引策略有任何好的，坚定的建议？
对于我们的一些ETL来说，来自源代码的测试查询可能需要半个小时到一个小时，因此跟踪和错误确实会提高生产力。
感谢。
答案 0 :(得分：0)
我认为你的问题的答案更多地取决于数学和数学。更多关于用户访问表的方式。对于日期范围分区，如果用户通常查找一天的数据，那么每日分区就有意义。如果用户通常在较长的日期范围内进行查询，那么每日分区只会增加开销。 Greenplum数据库表中的每个分区或子分区都被视为一个单独的表（因此文件系统上是一个单独的文件），因此，为了满足查询需要扫描的分区越多，您需要访问的文件就越多。了解用户如何访问数据，这将为您提供有关可能的分区策略的更好线索。
混合分区策略也很有用。某些用例会支持最近一周/每月有每日分区的表，然后旧分区覆盖更长的时间范围，因为它们的访问频率较低，通常用于报告/分析查询与行查找或类似情况。
就索引而言，虽然Greenplum DB的优化器倾向于通过索引访问进行表扫描，但索引才有意义。在某些情况下，我对位图索引运气不错。
不幸的是，调整GPDB仍然是一种艺术形式，就像其他数据库一样，因此需要进行一定数量的试验。错误可能是不可避免的。