PgSQL · 性能優化 · 如何潇灑的處理每天上百TB的資料增量

本文主要介紹postgresql 在中高端x86伺服器上的資料插入速度（目标表包含一個時間字段的索引），幫助企業使用者了解postgresql在這類場景下的性能表現。

平均每條記錄長度360位元組（比較常見的長度）；

時間字段建立索引；

每輪測試插入12tb資料，插入完12t後清除資料繼續插入。循環；

測試滿24小時停止測試；

統計24小時插入的記錄數；

24小時一共完成12輪測試，平均每輪測試耗時7071秒。

506萬行/s，1.78 gb/s，全天插入4372億，154tb資料。

<a href="https://github.com/digoal/pgsql_admin_script/blob/master/pgsql_perf_tuning.md" target="_blank">pgsql_perf_tuning</a>

<a href="https://yq.aliyun.com/articles/8482" target="_blank">postgresql支援hugepage的方法</a>

參數

建立測試表 :

每32k的block存儲89條記錄, 每條記錄360位元組。

分别在3個實體塊裝置上建立3個表空間目錄，同時在資料庫中建立表空間。

tbs1, tbs2, tbs3.

建立多個分表，用于減少 block extend 沖突。

這裡使用的是brin範圍索引，postgresql 針對物聯網流式資料的黑科技。

生成測試腳本, 一個連接配接一次插入178條記錄，占用2個32kb的block :

開始測試前清除資料：

測試方法：

每輪測試插入12tb資料。通過以下方式控制：

使用128個并行連接配接，每個連接配接執行1572864個事務；

一共執行201326592個事務（每個事務插入178條記錄）；

一共插入35836133376條記錄（358.36 億記錄）（共計12tb 資料，索引空間另算）。

進行下一輪測試前，輸出日志，并truncate所有的資料，然後重複以上測試。直到測試滿24小時，輸出統計資料。

測試腳本如下 :

測試

這個case主要的應用場景是實時的大資料入庫，例如物聯網的應用場景，大量的傳感器會産生龐大的資料。

又比如傳統的營運商網關，也會有非常龐大的流量資料或業務資料需要實時的入庫。索引方面，用到了postgresql黑科技brin。

瓶頸, 還是在io上面 , 有幾個表現，top大量程序處于d(front io)狀态 。

所有塊裝置的使用率均達100% 。

清理資料時 ：

插入資料時：

io層面的性能問題，可以通過優化代碼（例如 postgresql bgwriter 在寫出資料時，盡量順序寫出），便于os層進行io合并，來緩解io壓力，從這個資訊來看，單次寫io的大小還可以再大點。

有幾個工具你可能用得上，perf、systemtap和goprof。如果要較全面的分析，建議把 postgresql –enable-profiling 打開用于診斷。