SSD 上的 Postgres 堆表性能

對於相同的模式/查詢，我已經閱讀了 MySQL 和 PostgreSQL 之間的性能差異。. 它仍然與固態驅動器的外觀有關嗎？

那篇文章說 Postgres 更適合複雜的查詢和子查詢，而對於通過 ids 和順序掃描的簡單查詢更差。

Postgres 對於某些查詢來說更差/更慢，因為每個表都是一個堆，意味著沒有聚集索引，意味著行沒有通過它們的主鍵在硬碟驅動器上進行物理排序。因此，如果您想從 Postgres 讀取大部分記錄（據我所知，通過 id ）-與 MySQL 相比，這將導致許多隨機 I/O 和較差的性能。

問題：

1. 但是SSD呢？Postgres 和 MySQL 的順序讀取性能是否相同？
2. 使用 SSD 而不是 HHD 和 RDBM 是否有意義？

更新：與 Rick James 的回答有關

1. MySQL 使用Plan A和 Postgres 使用Plan B，對嗎？
2. *Plan A意味著聚集索引，對吧？*該表按物理排序lastName + firstName。
3. Plan A在 HDD 上的性能可能比Plan B在 SSD 上更好，所以 Postgres + SSD 不是靈丹妙藥。您需要選擇 MySQL 來查詢聚集索引，對吧？
4. *請詳細了解您所說的 I/O 綁定是指哪些查詢？*在我的理解any call to database == I/O bound operation中。

“計算磁碟命中數。”

讓我們建構一個簡單的表並對其進行查詢。然後讓我們討論兩個數據庫引擎將如何執行該查詢。

我們有一個包含姓氏和名字的表格，以及其他內容。桌子很大；大到無法記憶體在 RAM 中。該查詢需要查找所有具有給定姓氏和一些首字母的人：

SELECT * FROM tbl
   WHERE lastname = 'James'
     AND firstname LIKE 'R%';

計劃 A：該表使用 B+樹按姓+名排序。操作工作如下：

1. 找到第一行 (James,R)。這需要向下鑽取深度可能為 4 的 B+Tree 的層。這種樹中的所有非葉節點很可能都將保持記憶體狀態。但是葉節點不會（因為表的大小）。成本（到目前為止）：非葉節點的 0 個磁碟命中，加上葉節點的 1 個磁碟命中。
2. 通過 B+Tree 向前掃描。假設樹中的典型塊包含 100 條記錄。假設有 300 個匹配的名稱。成本：大約 3 個磁碟命中。

總成本：~4 個磁碟命中。

計劃 B：有一個INDEX(lastname, firstname)指向雜湊指針，然後指向數據。

1. 遍歷該索引以查找所有 300 個匹配的名稱。如果 INDEX 類似於 BTree，也就是大約 4 次磁碟命中。
2. 對於 300 個名稱中的每一個，在數據中進行雜湊查找以獲取SELECT *. 由於查找涉及雜湊，因此記錄將分散在各處。而且，由於我假設該表太大而無法記憶體，因此需要 300 次以上的磁碟命中才能找到記錄。

總成本：介於 4 到 304 之間；讓我們慷慨地說100。

此外，假設整個查詢有 1ms 的 CPU。假設 HDD 磁碟命中為 10 毫秒，SDD 磁碟命中為 0.5 毫秒。

Plan             HDD (ms)   SDD (ms)   RAM (ms, if the table were fully cached)
Plan A: B+Tree    41          3          1
Plan B: Hash    1001         51          1

（旁注：在任何數據庫引擎中對 UUID 進行索引就像丟棄 BTree 並僅使用雜湊一樣。）

在 SSD 變得與 RAM 一樣快之前，將存在性能差距。

正如您的問題 2（使用 SSD 是否有意義）：如果您受 I/O 限制，那麼可以。否則，它可能不會“划算”。RDBMS 嘗試記憶體所有內容，從而消除 I/O（用於讀取）；如果數據足夠小，則 I/O 速度無關緊要。

另一方面，寫入更可能依賴於 I/O 速度。但這是另一個討論（結論相似）。

回應問題更新：

1. 披露：我對 MyISAM 非常熟悉；Plan A 非常接近 MySQL 的 InnoDB。我對 Postgres很*陌生；*我不知道 B 計劃是否與此有關。
2. 是的。
3. 是的。
4. 這取決於。SELECT它需要的一切都記憶體在 ram 中：沒有 I/O 。設置為最大安全性的事務中的寫入：始終為 I/O。並且有很多“介於兩者之間”。

引用自：https://dba.stackexchange.com/questions/148991