大表 Postgresql 的索引性能

Question

我一直在搜索有關 PostgreSQL 上的索引基准測試的好信息，但沒有發現任何真正好的信息。

我需要了解 PostgreSQL 在處理大量記錄時的行為。 假設一個非分區表上有 2000M 條記錄。

從理論上講，b-trees 是 O(log(n)) 用於讀取和寫入，但實際上我認為這是一個理想的場景，不考慮像 HUGE 索引這樣的東西不完全適合 memory （交換？），也許其他的東西我不是眼見為實。

沒有 JOIN 操作，這很好，但請注意，這不是一個分析數據庫，並且需要低於 150 毫秒的響應時間（越少越好）。 當然，所有搜索都應該使用索引來完成。 我們有 2-3 個索引：

• UUID PK 索引
• 時間戳索引
• VARCHAR(20) 索引（非唯一但高基數）

我擔心的是一旦表達到預期的最高容量（2500M 記錄），寫入和讀取將如何執行

...所以具體問題可能是：

• 在這種情況下，“加鐵”能否達到合理的表現？ 注意這是非集群數據庫，所以這是垂直縮放。
• 讀寫時間消耗的主要來源是什么？
• 對於 PostgreSql（無集群、無分區、無分片）上的此標准設置，我們可以認為“太多”的表上的記錄數量是多少？

我知道這么多的記錄建議采取一些替代方案（分片、分區等），但這個問題是關於學習和理解 PostgreSQL 的能力而不是其他東西。

Answer 1

插入或從表中選擇應該不會降低性能，即使它很大。 索引訪問的開銷隨着表大小的對數而增長，但是對數的底很大，索引不應該有索引的深度不能超過5或6。索引的上層是可能已緩存，因此在每次索引掃描訪問單個表行時，您最終會讀取少量塊。 請注意，您不必緩存整個索引。