當前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

postgresql修炼之道_PostgreSQL的TOAST技术

發布時間：2024/7/19 数据库 44 豆豆

生活随笔收集整理的這篇文章主要介紹了 postgresql修炼之道_PostgreSQL的TOAST技术小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

本文參考：

PostgreSQL TOAST 技術理解
《PostgreSQL修煉之道》

一、TOAST是什么？

TOAST是“The Oversized-Attribute Storage Technique”（超尺寸屬性存儲技術）的縮寫，主要用于存儲一個大字段的值。

要理解TOAST，我們要先理解頁（BLOCK）的概念。在PG中，頁是數據在文件存儲中的基本單位，其大小是固定的且只能在編譯期指定，之后無法修改，默認的大小為8KB。同時，PG不允許一行數據跨頁存儲。那么對于超長的行數據，PG就會啟動TOAST，將大的字段壓縮或切片成多個物理行存到另一張系統表中（TOAST表），這種存儲方式叫行外存儲。

二、使用TOAST

只有特定的數據類型支持TOAST，因為那些整數、浮點數等不太長的數據類型是沒有必要使用TOAST的。

另外，支持TOAST的數據類型必須是變長的。在變長類型中：

前4字節（32bit）稱為長度字，長度字后面存儲具體的內容或一個指針。
長度字的高2bit位是標志位，后面的30bit是長度值（表示值的總長度，包括長度字本身，以字節計）。
由長度值可知TOAST數據類型的邏輯長度最多是30bit，即1GB(2^30-1字節）之內。
前2bit的標志位，一個表示壓縮標志位，一個表示是否行外存儲，如果兩個都是零，那么表示既未壓縮也未行外存儲。
如果設置了壓縮標志標志位，表示該數值被壓縮過（使用的是非常簡單且快速的LZ壓縮方法），使用前必須先解壓縮。
如果設置了行外存儲標志位，則表示該數值是在行外存儲的。此時，長度字后面的部分只是一個指針，指向存儲實際數據的TOAST表中的位置。如果兩個標志位都設置了，那么這個行外數據也會被壓縮。不管是哪種情況，長度字里剩下的30bit的長度值都表示數據的實際尺寸，而不是壓縮后的長度。

在 PG 中每個表字段有四種 TOAST 的策略：

PLAIN —— 避免壓縮和行外存儲。只有那些不需要 TOAST 策略就能存放的數據類型允許選擇（例如 int 類型），而對于 text 這類要求存儲長度超過頁大小的類型，是不允許采用此策略的。
EXTENDED —— 允許壓縮和行外存儲。一般會先壓縮，如果還是太大，就會行外存儲。這是大多數可以TOAST的數據類型的默認策略。
EXTERNAL —— 允許行外存儲，但不許壓縮。這讓在text類型和bytea類型字段上的子串操作更快。類似字符串這種會對數據的一部分進行操作的字段，采用此策略可能獲得更高的性能，因為不需要讀取出整行數據再解壓。
MAIN —— 允許壓縮，但不許行外存儲。不過實際上，為了保證過大數據的存儲，行外存儲在其它方式（例如壓縮）都無法滿足需求的情況下，作為最后手段還是會被啟動。因此理解為：盡量不使用行外存儲更貼切。

首先創建一張 blog 表，查看它的各字段的TOAST策略：

可以看到，interger 默認 TOAST 策略為 PLAIN ，而 text 為 EXTENDED 。

另外可以修改某個字段系統默認分配的TOAST策略，假如要將上面blog表中的content字段的TOAST策略改成EXTERNAL，就可以這樣：

ALTER TABLE blog ALTER content SET STORAGE EXTERNAL;

三、TOAST表的結構

如果一個表中有任何一個字段是可以TOAST的，那么PostgreSQL會自動為該表建一個相關聯的TOAST表，其OID存儲在pg_class系統表的reltoastrelid記錄里，行外的內容保存在TOAST表里。

查看blog表對應的TOAST表的OID：

postgres=# select relname,relfilenode,reltoastrelid from pg_class where relname='blog';relname | relfilenode | reltoastrelid ---------+-------------+---------------blog | 16441 | 16444 (1 row)

通過上述語句，我們查到 blog 表的 oid 為16441，其對應 TOAST 表的 oid 為16444（關于 oid 和 pg_class 的概念，請參考PG官方文檔），那么其對應 TOAST 表名則為： pg_toast.pg_toast_16441（注意這里是 blog 表的 oid ）。

行外存儲被切成了多個Chunk塊，每個Chunk塊大約是一個BLOCK的四分之一大小，如果塊大小為8KB（默認就是8KB），則Chunk大約為2KB（比2KB略小一點），每個Chunk都作為獨立的行存儲在TOAST表中。

TOAST表有三個字段：

chunk_id —— 用來表示特定 TOAST 值的 OID ，可以理解為具有同樣 chunk_id 值的所有行組成原表（這里的 blog ）的 TOAST 字段的一行數據。
chunk_seq —— 用來表示該行數據在整個數據中的位置。
chunk_data —— 該Chunk實際的數據。

我們看下上面的TOAST表pg_toast.pg_toast_16441的定義：

在chunk_id和chunk_seq上有一個唯一的索引，提供對數值的快速檢索。

因此，一個表示行外存儲的指針數據中包括了要查詢的TOAST表的OID和特定數值的chunk_id（也是一個OID類型）。為了方便，指針數據還存儲了邏輯數據的尺寸（原始的未壓縮的數據長度）及實際存儲的尺寸（如果使用了壓縮，則兩者不同）。加上頭部的長度字，一個TOAST指針數據的總尺寸是20字節。

四、TOAST技術實踐

現在我們來實際驗證下TOAST:

postgres=# insert into blog values(1, 'title', '0123456789'); INSERT 0 1 postgres=# select * from blog;id | title | content ----+-------+------------1 | title | 0123456789 (1 row)postgres=# select * from pg_toast.pg_toast_16441;chunk_id | chunk_seq | chunk_data ----------+-----------+------------ (0 rows)

可以看到因為 content 只有10個字符，所以沒有壓縮，也沒有行外存儲。然后我們使用如下 SQL 語句增加 content 的長度，每次增長1倍，同時觀察 content 的長度，看看會發生什么情況？

postgres=# update blog set content=content||content where id=1; UPDATE 1 postgres=# select id,title,length(content) from blog;id | title | length ----+-------+--------1 | title | 20 (1 row) postgres=# select * from pg_toast.pg_toast_16441;chunk_id | chunk_seq | chunk_data ----------+-----------+------------ (0 rows)

反復執行如上過程，直到 pg_toast_16441 表中有數據：

可以看到，直到 content 的長度為327680時（已遠遠超過頁大小 8K），對應 TOAST 表中才有了2行數據，且長度都是略小于2K，這是因為 extended 策略下，先啟用了壓縮，然后才使用行外存儲。

下面我們將 content 的 TOAST 策略改為 EXTERNAL ，以禁止壓縮。

然后我們再插入一條數據：

然后重復以上步驟，直到 pg_toast_16441 表中有數據：

postgres=# update blog set content=content||content where id=2; UPDATE 1 postgres=# select id,title,length(content) from blog;id | title | length ----+-------+--------2 | title | 3276801 | title | 327680 (2 rows)postgres=# select chunk_id,chunk_seq,length(chunk_data) from pg_toast.pg_toast_16441;chunk_id | chunk_seq | length ----------+-----------+--------16447 | 0 | 199616447 | 1 | 177316448 | 0 | 199616448 | 1 | 199616448 | 2 | 1996....（省略）16448 | 164 | 1996 (167 rows)

因為不允許壓縮，所以新的操作在TOAST表中生成了更多Chunk塊行記錄。通過以上操作得出以下結論：

如果策略允許壓縮，則TOAST優先選擇壓縮。
不管是否壓縮，一旦數據超過2KB左右，就會啟用行外存儲。
修改TOAST策略，不會影響現有數據的存儲方式。

五、TOAST技術總結

TOAST比那些更直接的方法（比如允許行值跨越多個頁面）有更多優點。假設查詢通常是用相對比較短的鍵值進行匹配的，那么執行器的大多數工作都將使用主行項完成。TOAST過的屬性的大值只是在把結果集發送給客戶端的時候才被抽出來（如果它被選中）。因此，主表要小得多，并且它的能放入到共享緩沖區中的行要比沒有任何行外存儲的方案更多。排序集也縮小了，并且排序將更多地在內存里完成。一個小測試表明，一個典型的保存 HTML 頁面以及它們的 URL 的表占用的存儲（包括TOAST表在內）大約只有裸數據的一半，而主表只包含全部數據的 10%（URL和一些小的 HTML 頁面）。與在一個非TOAST的對照表里面存儲（把全部 HTML 頁面裁剪成 7Kb 以匹配頁面大小）同樣的數據相比，運行時沒有任何區別。

總結

以上是生活随笔為你收集整理的postgresql修炼之道_PostgreSQL的TOAST技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：软件需求分析文档模板_小议管理软件需求分
下一篇： linux mint 图标主题_如何在