PostgreSQL和oracle表分割槽對比

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE        PostgreSQL是開源資料庫，完全免費，oracle是有強大廠商支援和維護的資料庫，把這兩個的表分割槽特性放在一起對比，似乎有些勉強。但對於我們多瞭解一些特性，在實際開發中可以更好地進行理性選擇和快速入手。

	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONEPostgreSQL	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONEOracle	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE說明
概念	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE把邏輯上的一個大表分割成物理上的幾塊	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE表進行分割槽後，邏輯上表仍然是一張完整的表，只是將表中的資料在物理上存放到多個表空間(物理檔案上)	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE在概念上，兩者是一致的。分割槽表對外部使用者可以說是透明的，都是單個資料表的形態呈現，可以不用瞭解具體的儲存方式。
作用	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE提高效能 增加系統的可用性	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONEOracle的表分割槽功能通過改善可管理性、效能和可用性，從而為各式應用程式帶來了極大的好處。通常，分割槽可以使某些查詢以及維護操作的效能大大提高。此外,分割槽還可以極大簡化常見的管理任務，分割槽是構建千兆位元組資料系統或超高可用性系統的關鍵工具	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE表分割槽的作用對兩者來說基本是一樣的，都是為了效能上的優化，提高可用性。
原理	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE基於表繼承的特性來進行分割槽實現，有父表和子表。 Pgsql的分割槽表其實是一個個的真實的資料表，在pg_tables中可以查詢到分割槽的資料表名字。	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE只有一個大表存在。每個分割槽都屬於這個大表，但每個分割槽都是單獨的segment，如果查詢限制了分割槽鍵值，那麼查詢只落在特定的segment，可以減少資料的訪問	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONEOracle沒有繼承的概念，分割槽表的實現是由oracle自身的儲存機制實現的，不需要過多的資料表定義。
使用時機	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE大表的資料量很大，並有明顯的可分割槽欄位。	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE1、表的大小超過2GB。 2、表中包含歷史資料，新的資料被增加到新的分割槽中。	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE在單表的資料量大，並不是所有的資料都是熱點資料時，可考慮分割槽表。但不能一概而論，需要對具體的應用進行仔細分析，並不是說用了分割槽表效能就能夠得到提升。
建立方式	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE分割槽型別有範圍分割槽、列表分割槽等。較常用的是範圍分割槽。在建立分割槽表時比較複雜，需要經過： 1、  建立父表； 2、  建立子表，用父表上繼承，用關鍵字INHERITS； 3、  給子表增加約束check； 4、  基於分割槽鍵值建立索引； 定義一個規則，把對主表的修改重定向到適當的分割槽表。	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE分割槽型別較多，有範圍分割槽、列表分割槽、雜湊分割槽、複合分割槽等，最常用的是範圍分割槽。在建立分割槽表時，比較簡單： 在create table時，就直接建立為分割槽表create table xx() partition by range(sysdate)。	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONEOracle的分割槽表建立很簡單，只要把表直接建為分割槽表就ok，減少了很多工作量。在這一方面oracle完勝。
索引	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONEPgsql的分割槽資料表是一個個獨立存在的表，需要為每一個分割槽子表建立索引，所以一個邏輯上的大表會有很多索引。	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE分割槽表可使用的索引型別較多，在範圍分割槽的前提下，效能比較好的是區域性字首索引。針對資料表建立此索引，用一個語句就可以搞定，新建的分割槽表都會自動應用索引，一勞永逸。	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONEOracle分割槽表的索引應用方式簡單，在建立時建立一次就ok。其實，這都是因為分割槽機制的不同，pgsql的分割槽表其實是一個個的單獨的資料表。
DML	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE需要設定SET constraint_exclusion = on;才可以是DML操作對使用者透明。並，在進行copy命令時，需要指明要copy到哪個分割槽子表中。	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONEDML操作對使用者來說是透明的，只要操作的過濾條件中包含分割槽鍵值，就可以直接定位到具體的分割槽表。也可以顯式的寫明從哪個分割槽表中進行操作。	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE對DML操作來說，oracle是完全透明的，自動定位到了分割槽表，減少了使用人員的參與。
Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE已有錶轉化為分割槽表	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE資料庫不提供自動轉換的機制	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONEOracle可以用線上重定義的方式進行轉換。不過，既然要轉換為分割槽表，可預計原表的資料量是比較大的，在轉換時需要時間很長，對線上裝置來說，也不是很合適。	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONEOracle自身的方式優勢不明顯。這兩種資料庫都可以用原表匯出，再匯入到分割槽表的方式進行，從實際執行來看，所用時間可以接受。
Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE儲存策略	Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE都可以在儲存過程中，對分割槽表進行動態建立和管理，提高了分割槽表的可用性。在儲存過程寫好後，後期都不需要經常維護。

總結，資料庫的表分割槽特性優點很多，比如：
Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE1、改善查詢效能：對分割槽物件的查詢可以僅搜尋自己關心的分割槽，提高檢索速度。

2、增強可用性：如果表的某個分割槽出現故障，表在其他分割槽的資料仍然可用；

3、維護方便：如果表的某個分割槽出現故障，需要修復資料，只修復該分割槽即可；

4、均衡I/O：可以把不同的分割槽對映到磁碟以平衡I/O，改善整個系統效能。

5、將很少用的資料可以移動到便宜的、慢一些地儲存介質上。

這兩種資料庫的分割槽表都具有這些優點。

對比來說，Oracle的分割槽建立和管理更加方便，很多工作是由oracle的內部機制來實現的。postgreSQL的分割槽表其實是一個個實際存在的資料表，分割槽的建立和管理都需要我們用語言來控制，增加了應用人員的工作量。

但，由於oracle自身的“侵佔式”硬碟儲存，對過期資料進行清除時，即便是drop分割槽表，也不能直接釋放硬碟空間，屬於“佔了就佔了”，這個管理起來就比較麻煩，除非對每個分割槽表都建立各個獨立的tablespace，放在獨立的物理檔案上，刪除過期分割槽表時，可以同時drop tablespace including contents。而postgreSQL在truncate 分割槽表時，可以直接釋放硬碟，會看到硬碟使用率下降了，這一點對硬碟資源緊張時，就非常好了。

兩種資料庫的分割槽表使用，各有利弊，但總的來說，比較偏向postgreSQL，畢竟硬碟有限。而且，oracle收費。

Ps，在資料量很大時，任何關係型資料庫都有效能上的瓶頸，不屬於我們這兩種資料庫分割槽表對比的範圍了。