關於在Greenplum DB上選擇分區策略的更好實踐[大數據]

Question

我需要知道任何人是否有任何一般指導原則（超出試驗和錯誤），爲一系列查詢類型定義優化分區/索引的好策略Greenplum的？

Greenplum的，對他們的管理指南的一些建議。但事實是，它幾乎從Postgres的文檔複製粘貼，而它的一些建議似乎很明顯（IE：分區表時會太大，不適合在記憶），但僅僅定義一個好的策略來實現這一點還不夠。

通常Greenplum數據庫具有非常大的表格（數百GB），雖然硬件是專門爲這種用途選擇的，但我在大型數據庫（IE：曾經擁有一個擁有60個現場表的數據庫和超過2千萬行的數據庫，每天的數據庫規模將增加400萬到800萬個註冊表）。

我知道在選擇合適的分區方面有一些技巧，比如選擇將以幾乎相同大小分隔的可預測範圍（如日期範圍）。但也有一個事實是，儘管在其他數據庫中我試圖依賴索引，但Greenplum通過給予某些設置更大的權重，如隨機頁面成本，從而完全不鼓勵它們，因此索引根本不被使用。

但我已經讀過一些情況，這是完全反生產的：假設你有三個節點，每個64GB內存，根據GP，你不應該分區，直到表超過192，但由於索引不使用你將結束seq掃描每節點高達64GB！ ---雖然這仍然可以很快，但如果您強制使用索引，則可以從20秒減少到幾毫秒。

另一個已知的情況是，在分區時，開銷使得查詢比應該慢很多。

所以，回到原來的問題：
有沒有人對如何定義分區/索引策略有什麼好的，可靠的諮詢意見？
隨着我們的一些ETL的源測試查詢可能需要半小時到一個小時，所以跟蹤和錯誤真的會推高生產力。

謝謝。

Answer 1

我認爲你的問題的答案更多取決於數學&更多關於你的用戶如何訪問表。對於日期範圍分區，如果用戶通常會查找一天的數據，那麼日常分區可能有意義。如果用戶通常查詢較長的日期範圍，那麼每日分區只會增加開銷。 Greenplum數據庫表中的每個分區或子分區都被視爲一個單獨的表（因此在文件系統上是一個單獨的文件），因此您必須掃描以滿足查詢的分區越多，需要訪問的打開的文件就越多。瞭解用戶想要訪問數據的方式，這將爲您提供有關可能的分區策略的更好線索。

混合分區策略也很有用。某些使用案例會傾向於最近一週/每月有日常分區的表格，然後讓較舊的分區覆蓋更長的時間範圍，因爲它們的訪問頻率較低，而且通常用於報告/分析查詢與行查找或類似查詢。

就索引而言，雖然Greenplum DB的優化器支持對索引訪問進行表掃描，但索引有意義的地方。在某些情況下，我已經有了位圖索引的好運氣。

不幸的是，調整GPDB與其他數據庫一樣仍然是一種藝術形式，所以一定量的&錯誤可能是不可避免的。