建站
咨詢
售后
建站咨詢
新聞中心
這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)碛嘘P(guān)PostgreSQL 磁盤空間的保護(hù)傘PG_repack及表膨脹的示例分析，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
我們提供的服務(wù)有：成都網(wǎng)站設(shè)計(jì)、做網(wǎng)站、微信公眾號(hào)開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、峰峰礦ssl等。為1000+企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的峰峰礦網(wǎng)站制作公司
PG 最近的使用中，發(fā)現(xiàn)這個(gè)數(shù)據(jù)庫確確實(shí)實(shí)是一個(gè)無底洞，東西太多了，但學(xué)習(xí)一樣?xùn)|西都是通過主干和分支的方式來學(xué)習(xí)，后續(xù)的學(xué)習(xí)其實(shí)有的時(shí)候是靠自覺和運(yùn)氣。
今天要說的pg_repack，這個(gè)插件，PG 的操作沒有ORACLE 或SQL SERVER 那樣簡(jiǎn)單化，因?yàn)镻G 的很多功能是通過插件的方式來進(jìn)行的，當(dāng)然這也和MySQL 插件方式不同。
話歸正題，PG 中通常會(huì)存在一些需要管理的問題如下：
刪除大量記錄后，從表中回收到磁盤的空閑空間
重新構(gòu)建一個(gè)表來重新排序記錄，并將它們壓縮/打包到更少的頁面。這可能讓查詢只從磁盤獲取一個(gè)頁面(或< n個(gè)頁面)，而不是n個(gè)頁面。換句話說，IO越少，性能越好。
從由于不正確的auto vaccum設(shè)置而導(dǎo)致大量膨脹的表中不能回收空閑空間。
安裝 pg_repack 是并不是一件難事，正常的編譯，create extensiton pg_repack ，然后在配置文件中 shared_preload_libraries = 'pg_repack'
重新啟動(dòng)PG 即可
下面我們就是要模擬一個(gè)表膨脹的案例，然后再用 pg_repack 來解決一些問題
1 我們?cè)趐ostgres 數(shù)據(jù)庫中創(chuàng)建一張表
CREATE TABLE large_test (id serial primary key,num1 bigint, num2 double precision, num3 double precision);
2 插入測(cè)試數(shù)據(jù)
INSERT INTO large_test (num1, num2, num3)
SELECT round(random()*10), random(), random()*142
FROM generate_series(1, 2000000) s(i);
3 我們查看這個(gè)表到底在機(jī)器物理那個(gè)文件上體現(xiàn)
select oid,datname from pg_database ;
OK 我們確認(rèn)我們的表的物理文件應(yīng)該在 13287 這個(gè)文件夾里面，在這里我們通過oid2name 命令來查看到底你的這個(gè)表在哪里文件里面，
oid2name -t large_test 下圖中我們可以鎖定物理的表在 16455 這個(gè)文件中
這張表現(xiàn)在有200萬的記錄，大小是115MB
下面我們就開始進(jìn)行一個(gè)表膨脹的操作，我們開啟兩個(gè)事物
1第一個(gè)事物往表里面在插入 200萬的數(shù)據(jù)
2 第二個(gè)事物更新表里面的某個(gè)字段的值
我們可以看一下表的大小瞬間就從 115MB 暴漲到 345 MB
如果按照邏輯來說，其實(shí)表的大小不應(yīng)該是在 230MB 左右，怎么這么夸張的到達(dá)了345MB.
其實(shí)這就的從PG 的表的結(jié)構(gòu)設(shè)計(jì)來說了，（之前寫過一篇文字在4個(gè)月前），主要是PG 的 undo log 其實(shí)是在糅合到表的物理設(shè)計(jì)中，每次UPDATE 其實(shí)都不會(huì)進(jìn)行真正的數(shù)據(jù)修改，而是重新插入一個(gè)新的行，（這然我想起 cassandra），所以，更新了多少行，占用的數(shù)據(jù)的空間就是 *2 ,所以就造成了表膨脹，以及 vaccum 和 auto vaccum 這兩個(gè)事情。（vaccum 也是寫過了，大約是2個(gè)月前），所以有的時(shí)候我們就的祭出我們的神器，（注：請(qǐng)?jiān)诜枪ぷ鲿r(shí)間進(jìn)行維護(hù)操作）PG_REPACK 工具，來收縮一下我們的膨脹過分的表，當(dāng)然auto vaccum 也是可以解決的，但如果你的表膨脹的比較大，并且在非工作時(shí)間，其實(shí)一次性解決這個(gè)問題，也是一個(gè)好的辦法。
我們下面就開始repack
pg_repack -d postgres --table public.large_test;
在經(jīng)過了10幾秒的工作后，我們查看 large_test 表的物理文件在哪里，我看可以看到，在經(jīng)過repack后，物理文件的名字更改了。
我們?cè)诳纯催@個(gè)物理的文件多大 230 MB 對(duì)比剛才的 磁盤占用率嗎，可以很清楚的知道剛才那些被廢棄的行的空間已經(jīng)釋放給了系統(tǒng)。
那么問題來了，repack 到底做了什么，原理是什么，其實(shí)熱 repack 的原理很簡(jiǎn)單， 和 MYSQL 的 alter table table engine=innodb是一個(gè)意思（如果你是MYSQL的 DBA 估計(jì)會(huì)很快明白）。當(dāng)然如果你是 SQL SERVER 的DBA ，shinrk database 的功能 你懂得哈
這相當(dāng)于重新寫了一個(gè)新的文件，將原來的物理文件踢掉，重新對(duì)表進(jìn)行了一次整理。
那這樣的好處不光是表的占用空間變小了，收益的還有訪問表的速度也會(huì)更快。最后這個(gè)命令還可以并行運(yùn)行，后面加參數(shù) J 和你的并行數(shù)。
最后如果你安裝pg_repack 報(bào)了一些莫名奇怪的錯(cuò)誤，你可以嘗試安裝
sudo yum -y install postgresql-static.x86_64
最后如果你想遠(yuǎn)程操作這個(gè)命令，是可以的，但你遠(yuǎn)程的機(jī)器也必須安裝這個(gè)插件，不能說你本地安裝，遠(yuǎn)程操作一個(gè)沒有插件的PG ，那是不可以的。
上述就是小編為大家分享的PostgreSQL 磁盤空間的保護(hù)傘PG_repack及表膨脹的示例分析了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
分享標(biāo)題：PostgreSQL磁盤空間的保護(hù)傘PG_repack及表膨脹的示例分析
當(dāng)前網(wǎng)址：http://ef60e0e.cn/article/gsjeoe.html
