目錄
環境文件用途
詳細資訊
環境系統平台：n/a
版本：10.0,9.6,8.4
文件用途
本文旨在用於指導資料分割槽和資料分割槽方法。
詳細資訊
什麼是資料分割槽？
對於具有極大表的資料庫，分割槽對於資料庫設計人員而言是一種慣用的技巧，可以提高資料庫效能並使維護更加容易。postgresql資料庫中允許的最大表大小為32tb，但是除非它將來在未發明的計算機上執行，否則效能問題可能出現在僅達到總大小的百分之一也就是300gb左右的表上。
分割槽將表拆分為多個表，並且通常以一種訪問表的應用程式注意不到任何差異的方式完成。通過將表拆分為多個表，我們的想法是允許執行查詢必須掃瞄更小的表和索引以查詢所需的資料。無論索引策略的效率如何，掃瞄50gb表的索引總是比500gb表的索引快得多。而且這也適用於表掃瞄，因為有時表掃瞄是不可避免的。
在將分割槽表引入查詢規劃器時，查詢規劃器本身有一些事情需要了解和理解。在實際執行任何查詢之前，查詢規劃器將採用查詢並規劃出訪問資料的最有效方式。通過將資料分成不同的表，規劃器可以根據每個表包含的內容決定要訪問哪些表以及要完全忽略哪些表。
這是通過向分割表新增約束來定義每個表中允許的資料來完成的，並且通過良好的設計，我們可以讓查詢規劃器掃瞄一小部分資料而不是整個資料。
表應該分割槽嗎？
如果做得好，分割槽可以大大提高表上的效能，但如果做錯了或不需要，它可能會使效能變差，甚至無法使用。
表有多大？
在分割槽成為乙個解決方案之前，沒有真正的強硬規則來確定表必須有多大，但是基於資料庫訪問趨勢，資料庫使用者和管理員將開始看到特定表的效能隨著它變大而開始降低。一般來說，只有當有人說「因為錶太大而無法做x」時才應考慮分割槽。對於某些主機，200gb可能是正確的分割槽時間，對於其他主機，可能達到1tb才進行分割槽。
如果確定表「太大」，則應該檢視訪問模式。通過了解訪問資料庫的應用程式，或通過監視日誌和生成類似pdr的查詢報告，我們可以看到如何訪問表，並且根據訪問方式，我們可以選擇良好的分割槽策略。
表膨脹是乙個問題嗎？
更新和刪除的行會導致最終需要清理的dead tuple。無論是手動還是自動vacuum表，都會遍歷表中的每一行，並確定是否要**或單獨使用。表越大，此過程所需的時間越長，使用的系統資源就越多。即使90%的表的資料不變，每次執行vacuum時都必須對其進行掃瞄。對錶進行分割槽有助於減少進行vacuum的表，減少需要掃瞄的不變資料量，減少整體vacuum時間，以及為使用者訪問釋放更多系統資源。
如果有資料，如何刪除資料？
如果按計畫刪除資料，例如刪除並存檔超過4年的資料，這可能會導致大量命中刪除語句，這些語句可能需要執行一段時間才能完成，並且如前所述，建立的dead tuple需要vacuum。如果實現了良好的分割槽策略，則可以將具有vacuum維護的多小時delete語句轉換為舊的月表上的一分鐘的drop table語句，實現0vacuum維護。
表應該如何分割槽？
訪問模式的鍵位於where子句和join條件中。每當查詢指定where和join子句中的列時，它就會告訴資料庫「這是我想要的資料」。與設計針對這些子句的索引非常相似，分割槽策略依賴於將這些列作為目標來分隔資料，並使查詢訪問盡可能少的分割槽。
例子：乙個事務表，其日期列始終在where子句中使用。
包含位置列的客戶表，例如始終在where子句中使用的居住國家/地區
更多詳細資訊請登入【瀚高技術支援平台】檢視
PostgreSQL中的索引
索引是一種快速查詢資料的方法，它記錄了表中一列或多列與其物理位置之間的對應關係。常用的索引有b tree，hash，gist及gin等。1 b tree索引適合處理等值查詢和範圍查詢。2 hash只適合處理簡單的等值查詢。3 gist支援很多不同的索引策略。4 gin反轉索引，可以處理包含多個鍵的值...
PostgreSQL 動態分表 Rotate輪詢
工作中，遇到如下業務需求 使用者可以自定義歷史資料的儲存期限，且對過期資料不作保留 即定期刪除 該類資料表的數量級在6千萬 年。前期處理方案 按月分表，由於在專案前期，限制使用者只能儲存一年的資料量，通過pg的rule分表，並通過一張中間表，進行新月份資料的錄入更替。簡單rotate用法，在月份更替...
spark 中 postgresql資料庫使用
畢竟是號稱世界上最先進的資料庫,還是要會一點的 一 最近是在spark裡面使用,需要從資料庫中直接讀出資料構建dataframe,但是這裡有乙個坑點,我需要拿到每天的資料,但是如果不使用spark.sql 執行sql語句,而是使用其他api,就涉及乙個日期條件怎麼寫的問題,最後解決時是使用spark...