淺入淺出 MySQL & PostgreSQL // Speaker Deck
(speakerdeck.com)
40 則討論
IngramChen
張貼於
Ant
積分 14
( 這裡好酷呀，首波 )
我只是覺得作者 "用 PostgreSQL 的優勢直接對等套用在 MySQL 上，而不考慮 MySQL 特性做修正，然後再說 MySQL 很差"，以藉此推廣 PostgreSQL 比較好的方式很不妥，所以寫了這篇簡報。
PostgreSQL 寫入時，單位是 block，然後會與 page 對齊，所以如果 PK 不是順序寫，那表示會落在很多個不同的 pages，如此在 checkpoint 時雖然是順序寫入，但若順著 PK scan 讀出時，就會變成 random read。但後者對 SSD 效能其實影響不大，只是剛好跟 MySQL 建議的方式有點不同。
使用 UUID 是要看情況，因為 MySQL 的 AUTO_INCREMENT 及 PostgreSQL Sequence 本身依賴的就是 locking，所以若要避用的話，PostgreSQL 天生有優勢，但 MySQL 則要小心不要用到 Random UUID (例如 UUIDv4)，否則效能如你所言會差很多。而 MySQL 要用 INT 還是 UUIDv1 就看個人了，因為 UUID 是標準資料交換時通用的 KEY。
VACUUM 其實就跟程式語言的 GC 一樣，讓人又愛又恨，一旦累積太多，GC 時就要一點有心理準備，抖動會比平常大一些。MongoDB 及 Cassandra 在發生 GC 時，也一樣很令人頭痛。AUTO VACUUM 其實最大的重點就是，依據內部的偵測機制，讓 PostgreSQL 自行決定什麼時候 VACUUM 最好；再者，PostgreSQL 官方也說了，若是定期 VACUUM，要小心累積太多的 dead tuples，而導致碎片嚴重到 VACUUM 修不好，最終只能 VACUUM FULL 而導致 table lock。
我兩個資料庫都用，確實要看應用而選。不然以 PostgreSQL 狂派傳教士而言，好似用 MySQL 的 Google / Facebook / 阿里巴巴都是笨蛋一樣。
這是文章的子討論串，你可以回到上層查看所有討論和文章