背景
1、産品的問題點
- PG 表空間容易達到檔案系統天花闆
2、問題點背後涉及的技術原理
- PG的表空間建立在檔案系統之上, 每個表空間對應1個目錄. 表空間的大小取決于檔案系統的大小.
- 資料庫中占用空間較大的table、index存放在表空間内, 最小粒度為分區粒度.
3、這個問題将影響哪些行業以及業務場景
- 通用
4、會導緻什麼問題?
- 表空間使用率監控比較複雜, 需要監控表空間目錄占用空間, 同時需要監控檔案系統剩餘空間.
-
- 比較難做計劃, 因為檔案系統可能被表空間以外的其他檔案占用.
- 檔案系統使用率達到上限後, 這個表空間也将達到上限, 需要通過挪動表、索引(move tablespace)或者擴充底層檔案系統來增加剩餘空間.
- 如果伺服器的存儲由很多塊盤組成, 要利用所有的存儲空間, 需要為每塊盤建立一個檔案系統, 對應1個表空間.
- 擴充底層檔案系統涉及到增加塊裝置, 檔案系統的resize. 管理比較複雜
- 大表可能超過檔案系統的大小, 隻能通過分區+多個檔案系統(多個表空間)解決.
5、業務上應該如何避免這個坑
- 在塊裝置和檔案系統之間加一層卷管理系統, 例如 lvm , zfs(zpool)
- 每個盤對應一個表空間, 提前規劃好表空間的使用
6、業務上避免這個坑犧牲了什麼, 會引入什麼新的問題
- 每個盤對應1個表空間, 意味着1個表隻能存儲在1個盤上, 沒有充分利用多個塊裝置的并行帶寬.
- 使用lvm或zfs增加了管理複雜度, 線上擴充受限于塊裝置、卷管理、檔案系統是否支援online resize/extend.
- 使用lvm或zfs可以采用條帶形式組織多個塊裝置, 但是增加了一個管理層, 增加了複雜度, 而且并行的帶寬會有一定的損耗.
7、資料庫未來産品疊代如何修複這個坑
- 在表空間和檔案系統之間, 增加一層資料檔案, 在資料檔案内重新組織資料和表(索引)的映射關系.
-
- 類似于Oracle, 但是這個方法也有問題, 例如資料檔案的水位問題, 會導緻空間浪費, 對于一個機器跑多個執行個體會造成較大的磁盤浪費. 适合比較固定的業務.
- 其他方法.