資料庫分區分表以及讀寫分離

Oracle資料庫分區是作為Oracle資料庫性能優化的一種重要的手段和方法，做手頭的項目以前，隻聆聽過分區的大名，感覺特神秘，看見某某高手在讨論會上誇誇其談時，真是罵自己學藝不精，最近作GPS方面的項目，處理的資料量達到了幾十GB，為了滿足系統的實時性要求，必須提高資料的查詢效率，這樣就必須通過分區，以解燃眉之急!

先說說分區的好處吧!

1) 增強可用性：如果表的某個分區出現故障，表在其他分區的資料仍然可用;

2) 維護友善：如果表的某個分區出現故障，需要修複資料，隻修複該分區即可;

3) 均衡I/O：可以把不同的分區映射到磁盤以平衡I/O，改善整個系統性能;

4) 改善查詢性能：對分區對象的查詢可以僅搜尋自己關心的分區，提高檢索速度。

Oracle資料庫提供對表或索引的分區方法有三種：

ü 範圍分區

ü Hash分區(散列分區)

ü 複合分區

一、範圍分區詳細說明

範圍分區就是對資料表中的某個值的範圍進行分區，根據某個值的範圍，決定将該資料存儲在哪個分區上。如根據序号分區，根據時間等來進行分區。根據序号，比如小于2000000的放在part01,  2000000~4000000的放在part02。。。

space01\ space02\ space03為建立的三個表空間，相當于把建立的一個大的表分在了3個不同的表空間的分區上了。

二、Hash分區(散列分區)詳細說明

散列分區為通過指定分區編号來均勻分布資料的一種分區類型，因為通過在I/O裝置上進行散列分區，使得這些分區大小一緻。也就是隻命名分區名稱，這樣均勻進行資料分布。

三、複合分區詳細說明

有時候我們需要根據範圍分區後，每個分區内的資料再散列地分布在幾個表空間中，這樣我們就要使用複合分區。複合分區是先使用範圍分區，然後在每個分區内再使用散列分區的一種分區方法。

四、分區表操作

1、插入記錄：insert into AAA values(1 ,sysdate);

2、查詢分區表記錄：select * from AAA partition(part_01);

3、更新分區表的記錄：update AAA partition(part_01) t set indate=’’where id=1;  但是當更新的時候指定了分區，而根據查詢的記錄不在該分區中時，将不會更新資料

4、删除分區表記錄：delete from AAA partition(part_02) t where id=4;  如果指定了分區，而條件中的資料又不在該分區中時，将不會删除任何資料。

5、增加一個分區：alter table AAA add partition part_04 values less   than(to_date(’2012-01-01’,’yyyy-mm-dd’)) tablespace dinya_spa ce03;   增加一個分區的時候，增加的分區的條件必須大于現有分區的最大值，否則系統将提示ORA-14074 partition bound must collate  higher than that of the last partition 錯誤。

6、合并一個分區：alter table AAA merge partitions part_01,part_02 into partition  part_02; ,如果在合并的時候把合并後的分區定為part_01的時候，系統将提示ORA-14275 cannot reuse lower-bound  partition as resulting partition 錯誤。

7、删除分區：alter table AAA drop partition part_01;  删除分區表的一個分區後，查詢該表的資料時顯示，該分區中的資料已全部丢失，是以執行删除分區動作時要慎重，確定先備份資料後再執行，或将分區合并。

五、建立索引

分區表和一般表一樣可以建立索引，分區表可以建立局部索引和全局索引。當分區中出現許多事務并且要保證所有分區中的資料記錄的唯一性時采用全局索引。

1. 局部索引分區的建立：

2. 全局索引建立時global 子句允許指定索引的範圍值，這個範圍值為索引字段的範圍值：

當然也可以不指定索引分區名直接對整個表建立索引:

資料庫的垂直切分和水準切分

資料切分可以是實體上的，對資料通過一系列的切分規則将資料分布到不同的DB伺服器上，通過路由規則路由通路特定的資料庫，這樣一來每次通路面對的就不是單台伺服器了，而是N台伺服器，這樣就可以降低單台機器的負載壓力。

資料切分也可以是資料庫内的，對資料通過一系列的切分規則，将資料分布到一個資料庫的不同表中，比如将article分為article_001,article_002等子表，若幹個子表水準拼合有組成了邏輯上一個完整的article表，這樣做的目的其實也是很簡單的。   舉個例子說明，比如article表中現在有5000w條資料，此時我們需要在這個表中增加(insert)一條新的資料，insert完畢後，資料庫會針對這張表重建立立索引，5000w行資料建立索引的系統開銷還是不容忽視的。但是反過來，假如我們将這個表分成100   個table呢，從article_001一直到article_100，5000w行資料平均下來，每個子表裡邊就隻有50萬行資料，這時候我們向一張隻有50w行資料的table中insert資料後建立索引的時間就會呈數量級的下降，極大了提高了DB的運作時效率，提高了DB的并發量。當然分表的好處還不知這些，還有諸如寫操作的鎖操作等，都會帶來很多顯然的好處。

綜上，分庫降低了單點機器的負載;分表，提高了資料操作的效率，尤其是Write操作的效率。 

<a href="http://s5.51cto.com/wyfs02/M02/8E/A2/wKiom1jHfKKD5X6_AACXQCfN8wM985.jpg-wh_651x-s_659678760.jpg" target="_blank"></a>

資料庫的讀寫分離

讀寫分離，基本的原理是讓主資料庫處理事務性增、改、删操作(INSERT、UPDATE、DELETE)，而從資料庫處理SELECT查詢操作。資料庫複制被用來把事務性操作導緻的變更同步到叢集中的從資料庫。

為什麼要分庫、分表、讀寫分?

單表的資料量限制，當單表資料量到一定條數之後資料庫性能會顯著下降。資料多了之後，對資料庫的讀、寫就會很多。分庫減少單台資料庫的壓力。接觸過幾個分庫分表的系統，都是通過主鍵進行散列分褲分表的。這類資料比較特殊，主鍵就是唯一的擷取該條資訊的主要途徑。比如：京東的訂單、财付通的交易記錄等。。。該類資料的用法，就是通過訂單号、交易号來查詢該筆訂單、交易。

還有一類資料，比如使用者資訊，每個使用者都有系統内部的一個userid，與userid對應的還有使用者看到的登入名。那麼如果分庫分表的時候單純通過userid進行散列分庫，那麼根據登入名來擷取使用者的資訊，就無法知道該使用者處于哪個資料庫中。

或許有朋友會說，我們可以維護一個email----userid的映射關系，根據email先查詢到userid，在根據userid的分庫分表規則到對應庫的對應表來擷取使用者的記錄資訊。這麼做是可以的，但是這個映射關系的條數本身也是個瓶頸，原則上是沒有減少單表内資料的條數，算是一個單點。并且要維護這個映射關系和使用者資訊的一緻性(修改登入名、多登入名等其他特殊需求)，最大一個原因，其實使用者資訊是一個讀大于寫的庫，web2.0都是以使用者為中心，所有資訊都和使用者資訊相關聯，是以對使用者資訊拆分還是有一定局限性的。

對于這類讀大于寫并且資料量增加不是很明顯的資料庫，推薦采用讀寫分離+緩存的模式，試想一下一個使用者注冊、修改使用者資訊、記錄使用者登入時間、記錄使用者登入IP、修改登入密碼，這些是寫操作。但是以上這些操作次數都是很小的，是以整個資料庫的寫壓力是很小的。唯一一個比較大的就是記錄使用者登入時間、記錄使用者登入IP這類資訊，隻要把這些經常變動的資訊排除在外，那麼寫操作可以忽略不計。是以讀寫分離首要解決的就是經常變化的資料的拆分，比如：使用者登入時間、記錄使用者登入IP。這類資訊可以單獨獨立出來，記錄在持久化類的緩存中(可靠性要求并不高，登陸時間、IP丢了就丢了，下次來了就又來了)

以oracle為例，主庫負責寫資料、讀資料。讀庫僅負責讀資料。每次有寫庫操作，同步更新cache，每次讀取先讀cache在讀DB。寫庫就一個，讀庫可以有多個，采用dataguard來負責主庫和多個讀庫的資料同步。

<a href="http://s2.51cto.com/wyfs02/M00/8E/A2/wKiom1jHfN7j7KvCAABHrC798iw220.jpg" target="_blank"></a>

本文轉自xiaocao1314051CTO部落格，原文連結：http://blog.51cto.com/xiaocao13140/1929873 ，如需轉載請自行聯系原作者