PostgreSQL DaaS設計注意 - schema與database的抉擇

digoal

2016-10-12

postgresql , daas , 模闆 , schema , database , apply delay , standby

市面上有一些提供daas服務的廠商，例如heroku，可能有上百萬的資料庫服務；

又比如提供paas平台的服務商，資料庫也會有很多，同僚這些資料庫可能也是模闆化的，這些廠商并不一定是為每個客戶都建立一個資料庫叢集來滿足資料庫的需求。

很有可能是使用資料庫或者schema來隔離不同使用者的。

1. 例如将模闆存儲在模闆資料庫中，根據一個模闆資料庫建立新的資料庫提供服務。

2. 有或者将模闆存儲在sql檔案中，使用sql檔案建構新的schema提供服務。

兩種方式構模組化闆的差别

1. 資料庫的方式隔離比較徹底，共用的資源較少。

可以實作存儲的隔離。

可以實作connection的隔離。

可以實作auth的隔離。

可以實作權限的隔離。

但是資料庫與資料庫之間是無法直接通路的，需要的話通過dblink或者fdw插件，當然也可以應用層面跨庫通路。

2. schema的方式，共用資源較多，可以同時操作不同的schema之間的對象，事務都是本地事務。

簡單來說是有schema更便捷，但是權限隔離沒有使用資料庫那麼徹底，可以從pg_class等系統表窺探到沒有權限的對象的定義。

從生成效率來講，使用資料庫模闆的方式會高很多，因為它隻需要copy dir，産生的redo很少，也不需要大量的變更中繼資料。

從删除效率來講，差别也非常大，删除schema與建立schema一樣，會産生大量的redo，甚至會導緻standby劇烈的延遲，後面會有分析。而删除資料庫很快，隻産生少量的redo。

本文将要給大家分析的就是兩者在建立和删除時的大幅差異。

用到兩塊pci-e ssd，分别存放主庫和備庫。

主庫監聽5289,備庫監聽5290

1. postgresql.conf

2. pg_hba.conf

3. recovery.done

進入template1資料庫，準備schema。

主表建表語句如下，為了讓schema盡量大一些，使用這種方法來建立。

100個字段，每個字段都有一個限制。

在資料庫中繼資料中，也會産生一大批系統記錄，例如

每個表至少會新增的中繼資料(沒算序列的，算序列還更多)

同時還會産生很多資料檔案，每個索引，表都會有一個資料檔案，如果算上fork(vm, fsm, init)的話，就更多了。

使用test建立500張一樣的表，會産生較多的中繼資料變動，同時會産生一堆資料檔案。

建完表後，template1就變500多mb了。

等待drop schema結束，并記錄目前xlog位點（很長一段時間後穩定（autovacuum）結束）

在主庫執行

發現備庫apply卡在一個redo rec上很久，如果接下來主庫又産生了大量的redo，那麼備庫的apply就會延遲嚴重。

主機redo發送是沒有延遲的，也就是說redo已經在備機那裡了，但是還沒有被apply。

備機apply延遲嚴重的話，另外一個問題就是備機的xlog會占用較大的空間。

使用pg_xlogdump分析 "堵塞" apply的redo rec

搜尋1/13151e28

這筆redo很大，十幾mb

備庫apply卡住的地方，跟蹤備庫startup程序(用于recovery的程序)在幹什麼

檢視一下template1下面有多少個檔案，（200多個是系統自帶的一些元表的資料檔案）有50954多個檔案。

unlink這些檔案至少也要耗費10幾分鐘。

1. drop schema 産生了多少redo

本例的測試用例，約17mb的redo。

2. 為什麼drop schema會導緻standby apply的延遲嚴重

大量的檔案操作，導緻了apply的延遲。

未發現延遲

分析一下create 和 drop database産生的redo内容

分析從1/168ee5f8到1/168f20e0的内容全部如下

create 和 drop database并沒有産生很多的日志，也沒有那麼多的檔案操作。隻有copy dir和drop dir。

檔案操作少了，比drop schema快多了。

1. schema和database在實體結構上的差别

database是以目錄的形式組織在表空間的目錄下的，而schema是以檔案的形式在資料庫的目錄下的，沒有再細分獨立的目錄。

是以在drop database時系統調用變得更簡單，而drop schema需要挨個檔案來。

2. schema和database在中繼資料上的差别

簡單來說就是比擦屁股的動作, drop database擦屁股很快，因為中繼資料很少隻影響pg_databases。

drop schema擦屁股就很煩了，要挨個清理pg_class, pg_attribute, 等等元表。  元表清理完還需要vacuum。

3. create 和 drop schema的檔案操作很多，是一個個檔案進行的，而且都會記錄在redo中，如果schema中有很對對象并且有很多檔案的話，會非常慢。

4. create 和 drop database産生的日志少，系統調用也更少。

schema不建議作為daas的模闆環境頻繁(新增和删除時)使用，如果要頻繁的建立和删除模闆，建議使用database作為模闆。  

database作為模闆的一個缺點是連接配接複用的問題，因為連接配接複用需要基于user+database，如果有很多db的話，連接配接可能會消耗很多。

把schema放到database下，新增一個目錄存放。删除的時候可以drop dir，但是清理中繼資料還是少不了的。

schema與其他schema之間的一些依賴關系也需要清理(可能涉及中繼資料的清理)。

<a href="http://info.flagcounter.com/h9v1">count</a>