2012-11-12 84 views
1

我有一個關於時間字段partitoned的表。我有25個分區。現在我考慮使用對象類型字段進一步分割它。我有十個對象類型,所以它將導致250個分區。根據我所讀到的,建議的分區數量是幾十個,但在我的情況下,這個模式非常簡單,並且不包含任何聯接,所以我想知道它是否是o.k.定義多個分區。我正在使用postgres版本9.1.2Postgres的分區號

CREATE TABLE metric_store.lc_aggregated_data_master_10_minutes 
(
    from_time integer, 
object_id integer, 
object_type integer, 
latencies_client_fetch_sec_sum bigint, 
latencies_client_rttsec_sum bigint, 
latencies_db_bci_res_sec_sum bigint, 
latencies_net_infrastructure_ttlb_sec_sum bigint, 
latencies_retransmissions_sec_sum bigint, 
latencies_ttfbsec_sum bigint, 
latencies_ttlbsec_sum bigint, 
latencies_ttlbsec_sumsqr bigint, 
latencies_ttlbsec_histogram_level0 integer, 
latencies_ttlbsec_histogram_level1 integer, 
latencies_ttlbsec_histogram_level2 integer, 
latencies_ttlbsec_histogram_level3 integer, 
latencies_ttlbsec_histogram_level4 integer, 
latencies_ttlbsec_histogram_level5 integer, 
latencies_ttlbsec_histogram_level6 integer, 
latencies_ttlbsec_histogram_level7 integer, 
usage_bytes_total bigint, 
usage_hits_total integer, 
latencies_server_net_ttlbsec_sum bigint, 
latencies_server_rttsec_sum bigint, 
avaiability_errors_total integer 
) 
    WITH (
    OIDS=FALSE 
); 
    ALTER TABLE metric_store.lc_aggregated_data_master_10_minutes 
    OWNER TO postgres; 


CREATE TABLE metric_store.lc_aggregated_data_10_minutes_from_1353070800 
(
    CONSTRAINT lc_aggregated_data_10_minutes_from_1353070800_pkey PRIMARY KEY (from_time , object_id), 
    CONSTRAINT lc_aggregated_data_10_minutes_from_1353070800_from_time_check CHECK (from_time >=  1353070800 AND from_time < 1353190800) 
    ) 
    INHERITS (metric_store.lc_aggregated_data_master_10_minutes) 
    WITH (
    OIDS=FALSE 
); 
ALTER TABLE metric_store.lc_aggregated_data_10_minutes_from_1353070800 
OWNER TO postgres; 


CREATE INDEX lc_aggregated_data_10_minutes_from_1353070800_obj_typ_idx 
ON metric_store.lc_aggregated_data_10_minutes_from_1353070800 
USING btree 
(from_time , object_type); 
+0

有多少行?你確定未分區表的查詢是否儘可能好? (分區對於良好的索引是一個不好的替代品。)更快的硬件是更好的解決方案嗎? (分區對於一個足夠的服務器來說也是一個糟糕的替代品。) –

+0

它大約有1000萬行。我有對象類型的索引,但對超過100個時間點的許多對象ID的查詢很慢,因爲很多隨機訪問尋找磁盤。將數據分解爲較小的分區會產生性能提升,因爲我通常在查詢中查詢相同的對象類型。 – user1817686

+0

1000萬行不是一個巨大的表。如果我是你,我會先尋求調整未分區表的建議。此外,版本9.2只有索引掃描,但我認爲這不會對您有所幫助。 –

回答

1

當前版本(9.2)有這個guidance about the number of partitions。 (這一指導方針以來就沒有改變8.3)

在主表的所有分區的所有限制約束排除過程中進行檢查 ,所以大量的分區有可能 增加查詢規劃的時間相當。使用這些 技術進行分區將可能適用於多達100個分區; 不要嘗試使用數千個分區。

從閱讀PostgreSQL郵件列表,我相信增加查詢計劃的時間是您面臨的主要問題。

如果你的分區可以從隔離冷數據熱數據,或者如果你的分區,你能經常查詢,你可能會確定羣聚集的數據集。但測試是你最好的選擇。 EXPLAIN ANALYZE未分區表中的代表性查詢,然後在分區後執行相同操作。在分析其中的任何一個之前選擇代表性查詢。

+0

什麼意思是從冷數據中分離熱點數據? ,模式複雜性是否對查詢計劃器計算複雜性有任何影響?因爲在我的情況下,scheam非常簡單,沒有任何需要加入的查詢。 – user1817686

+0

時間戳經常查詢的「當前」或「最近」的數據,以及較少(也許很少)查詢數據一個多月歲或大於一歲多。 「當前」或「最近」數據是熱的(經常查詢的)數據;超過一個月或一年的數據是冷的(很少查詢)數據。 Id's也可以有冷熱數據的子集。需要多次連接的模式增加了查詢計劃員必須執行的工作,但計劃連接的時間通常會因優化訪問一千個分區的時間而變得不足。 (因爲規劃人員檢查每個分區上的每個約束。) –