<em>Mac</em>Book项目 2009年学校开始实施<em>Mac</em>Book项目,所有师生配备一本<em>Mac</em>Book,并同步更新了校园无线网络。学校每周进行电脑技术更新,每月发送技术支持资料,极大改变了教学及学习方式。因此2011
2021-06-01 09:32:01
PostgreSQL中,由於其多版本的特性,當我們進行資料更新時,實際上並不是直接修改後設資料,而是通過新插入一行資料來進行間接的更新。而當表上存在索引時,由於新插入了資料,那麼索引必然也需要同步進行更新,這在索引較多的情況下,對於更新的效能影響必然很大。
為了解決這一問題,pg從8.3版本開始就引入了HOT(Heap Only Tuple)機制。其原理大致為,當更新的不是索引欄位時,我們通過將舊元組指向新元組,而原先的索引不變,仍然指向舊元組,但是我們可以通過舊元組作為間接去存取到新的元組,這樣就不用再去更新索引了。
要使用HOT進行更新,需要滿足兩個前提:
當我們進行HOT更新時,首先是分別設定舊元組的t_informask2標誌位為HEAP_HOT_UPDATED和新元組為HEAP_ONLY_TUPLE。
更新如下圖所示:
我們更新tuple1為tuple2,分別設定這兩行元組的t_informask2標誌位,然後tuple1的ctid指向tuple2,而tuple2指向自己。
但是這樣存在一個明顯的問題,我們都知道pg會定期進行vacuum清理那些死元組,那麼我們這裡如果通過tuple1去存取tuple2的話,tuple1這個死元組被清理了又該怎麼辦呢?
所以pg會在合適的時機進行行指標的重定向,將舊元組的行指標指向新元組的行指標,這一過程稱為修剪。於是在修剪之後,我們通過HOT機制存取資料便成了這樣:
1、通過索引元組找到舊元組的行指標1;
2、通過重定向的行指標1找到行指標2;
3、通過行指標2找到新元組tuple2。
這樣即使舊元組tuple1被清理掉也沒有影響了。
HOT對應的wal紀錄檔實現:
對於HOT的update操作,其wal紀錄檔中記錄的資訊主要是由xl_heap_update結構儲存。
如果新的元組儲存在 block_id 為 0 的塊上,如果不是 XLOG_HEAP_HOT_UPDATE,那麼舊的元組將會儲存在 block_id 為 1 的塊上。反之如果block_id 為 1 的塊沒有被使用,那麼則認為是 XLOG_HEAP_HOT_UPDATE。
前面我們提到了,舊行的行指標會重定向到新行的行指標,這一過程稱之為修剪。那麼什麼時候會發生修剪呢?
一般來說,當我們執行select、update、insert、delete這些命令時均有可能觸發修剪,其觸發機制大致有兩種情況:
除此之外,當進行修剪時,還會選擇合適的時機進行死元組的清理,這一操作稱為碎片整理。碎片整理髮生在當我們對元組進行檢索時發現空閒空間少於10%時,和修剪不同的是,碎片整理不會發生在insert時,因為該操作並不會檢索行。
相較於普通的vacuum操作,碎片清理並不涉及索引元組的清理,開銷相對於常規的清理要小很多,是通過PageRepairFragmentation函數來實現的。
這也是為什麼HOT要求新舊元組需要在同一個page中,雖然從理論上來說我們可以將行指標的連結串列指向不同page,但是這樣我們便不能使用page-local的操作來進行碎片清理了。
前面我們提到了HOT的前提條件之一就是:更新的列不能是索引列。需要注意,當更新的列是索引列時並不僅僅是會修改該列上的索引,整張表上所有的索引均會被修改。
例子:
建立測試表:
bill=# create table a(id int, c1 int, c2 int, c3 int); CREATE TABLE bill=# insert into a select generate_series(1,10), random()*100, random()*100, random()*100; INSERT 0 10 bill=# create index idx_a_1 on a (id); CREATE INDEX bill=# create index idx_a_2 on a (c1); CREATE INDEX bill=# create index idx_a_3 on a (c2); CREATE INDEX
觀察索引頁內容:
bill=# SELECT * FROM bt_page_items('idx_a_1',1); itemoffset | ctid | itemlen | nulls | vars | data | dead | htid | tids ------------+--------+---------+-------+------+-------------------------+------+--------+------ 1 | (0,1) | 16 | f | f | 01 00 00 00 00 00 00 00 | f | (0,1) | 2 | (0,2) | 16 | f | f | 02 00 00 00 00 00 00 00 | f | (0,2) | 3 | (0,3) | 16 | f | f | 03 00 00 00 00 00 00 00 | f | (0,3) | 4 | (0,4) | 16 | f | f | 04 00 00 00 00 00 00 00 | f | (0,4) | 5 | (0,5) | 16 | f | f | 05 00 00 00 00 00 00 00 | f | (0,5) | 6 | (0,6) | 16 | f | f | 06 00 00 00 00 00 00 00 | f | (0,6) | 7 | (0,7) | 16 | f | f | 07 00 00 00 00 00 00 00 | f | (0,7) | 8 | (0,8) | 16 | f | f | 08 00 00 00 00 00 00 00 | f | (0,8) | 9 | (0,9) | 16 | f | f | 09 00 00 00 00 00 00 00 | f | (0,9) | 10 | (0,10) | 16 | f | f | 0a 00 00 00 00 00 00 00 | f | (0,10) | (10 rows) bill=# SELECT * FROM bt_page_items('idx_a_2',1); itemoffset | ctid | itemlen | nulls | vars | data | dead | htid | tids ------------+-----------+---------+-------+------+-------------------------+------+--------+------------------- 1 | (0,5) | 16 | f | f | 00 00 00 00 00 00 00 00 | f | (0,5) | 2 | (0,4) | 16 | f | f | 05 00 00 00 00 00 00 00 | f | (0,4) | 3 | (0,8) | 16 | f | f | 0e 00 00 00 00 00 00 00 | f | (0,8) | 4 | (0,9) | 16 | f | f | 25 00 00 00 00 00 00 00 | f | (0,9) | 5 | (16,8194) | 32 | f | f | 30 00 00 00 00 00 00 00 | f | (0,1) | {"(0,1)","(0,3)"} 6 | (0,10) | 16 | f | f | 58 00 00 00 00 00 00 00 | f | (0,10) | 7 | (0,6) | 16 | f | f | 60 00 00 00 00 00 00 00 | f | (0,6) | 8 | (0,7) | 16 | f | f | 62 00 00 00 00 00 00 00 | f | (0,7) | 9 | (0,2) | 16 | f | f | 63 00 00 00 00 00 00 00 | f | (0,2) | (9 rows) bill=# SELECT * FROM bt_page_items('idx_a_3',1); itemoffset | ctid | itemlen | nulls | vars | data | dead | htid | tids ------------+--------+---------+-------+------+-------------------------+------+--------+------ 1 | (0,6) | 16 | f | f | 03 00 00 00 00 00 00 00 | f | (0,6) | 2 | (0,3) | 16 | f | f | 12 00 00 00 00 00 00 00 | f | (0,3) | 3 | (0,5) | 16 | f | f | 15 00 00 00 00 00 00 00 | f | (0,5) | 4 | (0,9) | 16 | f | f | 1a 00 00 00 00 00 00 00 | f | (0,9) | 5 | (0,4) | 16 | f | f | 33 00 00 00 00 00 00 00 | f | (0,4) | 6 | (0,7) | 16 | f | f | 3d 00 00 00 00 00 00 00 | f | (0,7) | 7 | (0,10) | 16 | f | f | 4e 00 00 00 00 00 00 00 | f | (0,10) | 8 | (0,1) | 16 | f | f | 4f 00 00 00 00 00 00 00 | f | (0,1) | 9 | (0,2) | 16 | f | f | 5c 00 00 00 00 00 00 00 | f | (0,2) | 10 | (0,8) | 16 | f | f | 5d 00 00 00 00 00 00 00 | f | (0,8) | (10 rows)
更新索引列c2:
bill=# update a set c2=c2+1 where id=1 returning ctid,*; ctid | id | c1 | c2 | c3 --------+----+----+----+---- (0,11) | 1 | 19 | 66 | 86 (1 row) UPDATE 1
再觀察索引內容:
可以看到3個索引的索引頁均發生了變化。
bill=# SELECT * FROM bt_page_items('idx_a_1',1); itemoffset | ctid | itemlen | nulls | vars | data | dead | htid | tids ------------+--------+---------+-------+------+-------------------------+------+--------+------ 1 | (0,1) | 16 | f | f | 01 00 00 00 00 00 00 00 | f | (0,1) | 2 | (0,11) | 16 | f | f | 01 00 00 00 00 00 00 00 | f | (0,11) | 3 | (0,2) | 16 | f | f | 02 00 00 00 00 00 00 00 | f | (0,2) | 4 | (0,3) | 16 | f | f | 03 00 00 00 00 00 00 00 | f | (0,3) | 5 | (0,4) | 16 | f | f | 04 00 00 00 00 00 00 00 | f | (0,4) | 6 | (0,5) | 16 | f | f | 05 00 00 00 00 00 00 00 | f | (0,5) | 7 | (0,6) | 16 | f | f | 06 00 00 00 00 00 00 00 | f | (0,6) | 8 | (0,7) | 16 | f | f | 07 00 00 00 00 00 00 00 | f | (0,7) | 9 | (0,8) | 16 | f | f | 08 00 00 00 00 00 00 00 | f | (0,8) | 10 | (0,9) | 16 | f | f | 09 00 00 00 00 00 00 00 | f | (0,9) | 11 | (0,10) | 16 | f | f | 0a 00 00 00 00 00 00 00 | f | (0,10) | (11 rows) bill=# SELECT * FROM bt_page_items('idx_a_2',1); itemoffset | ctid | itemlen | nulls | vars | data | dead | htid | tids ------------+--------+---------+-------+------+-------------------------+------+--------+------ 1 | (0,6) | 16 | f | f | 04 00 00 00 00 00 00 00 | f | (0,6) | 2 | (0,9) | 16 | f | f | 0b 00 00 00 00 00 00 00 | f | (0,9) | 3 | (0,1) | 16 | f | f | 13 00 00 00 00 00 00 00 | f | (0,1) | 4 | (0,11) | 16 | f | f | 13 00 00 00 00 00 00 00 | f | (0,11) | 5 | (0,2) | 16 | f | f | 19 00 00 00 00 00 00 00 | f | (0,2) | 6 | (0,5) | 16 | f | f | 1d 00 00 00 00 00 00 00 | f | (0,5) | 7 | (0,8) | 16 | f | f | 1e 00 00 00 00 00 00 00 | f | (0,8) | 8 | (0,4) | 16 | f | f | 21 00 00 00 00 00 00 00 | f | (0,4) | 9 | (0,3) | 16 | f | f | 28 00 00 00 00 00 00 00 | f | (0,3) | 10 | (0,10) | 16 | f | f | 3a 00 00 00 00 00 00 00 | f | (0,10) | 11 | (0,7) | 16 | f | f | 4d 00 00 00 00 00 00 00 | f | (0,7) | (11 rows) bill=# SELECT * FROM bt_page_items('idx_a_3',1); itemoffset | ctid | itemlen | nulls | vars | data | dead | htid | tids ------------+--------+---------+-------+------+-------------------------+------+--------+------ 1 | (0,2) | 16 | f | f | 17 00 00 00 00 00 00 00 | f | (0,2) | 2 | (0,7) | 16 | f | f | 18 00 00 00 00 00 00 00 | f | (0,7) | 3 | (0,5) | 16 | f | f | 33 00 00 00 00 00 00 00 | f | (0,5) | 4 | (0,6) | 16 | f | f | 37 00 00 00 00 00 00 00 | f | (0,6) | 5 | (0,4) | 16 | f | f | 38 00 00 00 00 00 00 00 | f | (0,4) | 6 | (0,1) | 16 | f | f | 41 00 00 00 00 00 00 00 | f | (0,1) | 7 | (0,11) | 16 | f | f | 42 00 00 00 00 00 00 00 | f | (0,11) | 8 | (0,9) | 16 | f | f | 4d 00 00 00 00 00 00 00 | f | (0,9) | 9 | (0,8) | 16 | f | f | 58 00 00 00 00 00 00 00 | f | (0,8) | 10 | (0,3) | 16 | f | f | 62 00 00 00 00 00 00 00 | f | (0,3) | 11 | (0,10) | 16 | f | f | 63 00 00 00 00 00 00 00 | f | (0,10) | (11 rows)
這也意味著當我們無法使用HOT更新時,每更新一條資料都會更新所有的索引,那麼這個對效能的影響可想而知。而我們簡單想想其實並沒有這個必要,因為對於沒有被更新的索引列而言,只是ctid發生了變化,其索引列指向的值並沒有變化。那麼有沒有辦法讓我們更新索引列時只修改該索引列的索引呢?PHOT應運而生。
PHOT(Partial Heap Only Tuples),正如我們前面所說,PHOT是為了解決HOT更新索引列時會修改索引列的弊端。目前,PG中還不支援該功能,不過社群中已經有相關的討論了,預計可能會在PG15中和大家見面。
PHOT的設計思路主要是:通過在t_infomask2標誌位新加入兩種型別HEAP_HOT_UPDATED 和HEAP_ONLY_TUPLE用來表示PHOT更新,類似於HOT。當我們對索引列進行修改時,通過一個PHOT的bitmap點陣圖來記錄哪些索引列被更新了,然後,當我們對索引列修改時,只需要修改這個bitmap點陣圖中的列即可。
#define HEAP_HOT_UPDATED 0x4000 /* tuple was HOT-updated */ #define HEAP_ONLY_TUPLE 0x8000 /* this is heap-only tuple */
我們通過下面的例子來看看PHOT和HOT的不同之處。
構建環境:
CREATE TABLE test (a INT, b INT, c INT); CREATE INDEX ON test (a); CREATE INDEX ON test (b); CREATE INDEX ON test (c); INSERT INTO test VALUES (0, 0, 0); UPDATE test SET a = 1, b = 1; UPDATE test SET b = 2, c = 2; UPDATE test SET a = 2; UPDATE test SET a = 3, c = 3;
不使用PHOT:
可以看到,不使用PHOT的情況下,每次更新都會產生新的索引元組。
在這些更新之後,有 15 個索引元組、5 個行指標和 5 個堆元組。
test_a_idx 0 1 1 2 3 test_b_idx 0 1 2 2 2 test_c_idx 0 0 2 2 3 lp 1 2 3 4 5 heap (0,0,0) (1,1,0) (1,2,2) (2,2,2) (3,2,3)
PHOT:
在使用PHOT後,通過增加了一個bitmap點陣圖來記錄被更新的列。當執行完上述更新後,有 10 個索引元組、5 個行指標、5 個堆元組和 4 個點陣圖。
test_a_idx 0 1 2 3 test_b_idx 0 1 2 test_c_idx 0 2 3 lp 1 2 3 4 5 heap (0,0,0) (1,1,0) (1,2,2) (2,2,2) (3,2,3) bitmap xx- -xx x-- x-x
而前面的例子我們使用PHOT更新又是什麼結果呢?
可以看到下圖中,左邊是使用PHOT進行更新的,只是被更新的索引列發生了變化,而右邊非PHOT進行更新則是所有的索引列均發生變化。
效能測試:
通過簡單的pgbench測試,TPS 提高了約 34%,其中每個表都有 5 個額外的文字列和每列上的索引。有了額外的索引和列,理論上 TPS 的提升應該會更高。對於沒有表修改的短期 pgbench 執行,使用 PHOT 觀察到 TPS 增加了約 2%,表明常規 pgbench 執行沒有受到顯著影響。
PostgreSQL使用HOT機制來避免因為其多版本特性導致的每次更新資料均需要修改索引的情況。而當前的HOT機制,對於索引列的更新仍然存在比較明顯的效能問題,因為所有的索引均需要發生修改,不過預計在PG15中,將會加入更為強大的PHOT功能,更新索引列再也不會影響其它索引了。
參考連結:
到此這篇關於PostgreSQL HOT與PHOT有哪些區別的文章就介紹到這了,更多相關PostgreSQL HOT與PHOT內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com!
相關文章
<em>Mac</em>Book项目 2009年学校开始实施<em>Mac</em>Book项目,所有师生配备一本<em>Mac</em>Book,并同步更新了校园无线网络。学校每周进行电脑技术更新,每月发送技术支持资料,极大改变了教学及学习方式。因此2011
2021-06-01 09:32:01
综合看Anker超能充系列的性价比很高,并且与不仅和iPhone12/苹果<em>Mac</em>Book很配,而且适合多设备充电需求的日常使用或差旅场景,不管是安卓还是Switch同样也能用得上它,希望这次分享能给准备购入充电器的小伙伴们有所
2021-06-01 09:31:42
除了L4WUDU与吴亦凡已经多次共事,成为了明面上的厂牌成员,吴亦凡还曾带领20XXCLUB全队参加2020年的一场音乐节,这也是20XXCLUB首次全员合照,王嗣尧Turbo、陈彦希Regi、<em>Mac</em> Ova Seas、林渝植等人全部出场。然而让
2021-06-01 09:31:34
目前应用IPFS的机构:1 谷歌<em>浏览器</em>支持IPFS分布式协议 2 万维网 (历史档案博物馆)数据库 3 火狐<em>浏览器</em>支持 IPFS分布式协议 4 EOS 等数字货币数据存储 5 美国国会图书馆,历史资料永久保存在 IPFS 6 加
2021-06-01 09:31:24
开拓者的车机是兼容苹果和<em>安卓</em>,虽然我不怎么用,但确实兼顾了我家人的很多需求:副驾的门板还配有解锁开关,有的时候老婆开车,下车的时候偶尔会忘记解锁,我在副驾驶可以自己开门:第二排设计很好,不仅配置了一个很大的
2021-06-01 09:30:48
不仅是<em>安卓</em>手机,苹果手机的降价力度也是前所未有了,iPhone12也“跳水价”了,发布价是6799元,如今已经跌至5308元,降价幅度超过1400元,最新定价确认了。iPhone12是苹果首款5G手机,同时也是全球首款5nm芯片的智能机,它
2021-06-01 09:30:45