(轉)從對資料訪問扭曲的適應性評價PostgreSQL與InnoDB

原文作者：風輕揚

出處：http://wangyuanzju.blog.163.com/blog/static/1302920070245344752/

前兩篇文章中已經透過介紹Falcon的架構和對面向Web 2.0的儲存引擎的討論引出資料訪問扭曲這一話題，對於我接觸更多，也是最為流行的兩大開源DBMS：PostgreSQL和MySQL，自然忍不住按它 來比較一把了。由於這一問題只與DBMS的儲存系統有關，因此這裡實際上比較的是PostgreSQL與MySQL的事務型儲存引擎InnoDB。

PostgreSQL與InnoDB都採用多版本併發控制技術，但兩者在儲存的實現機制上仍然有以下兩個重大差別：

1. PostgreSQL用堆儲存記錄，而InnoDB用按主鍵為鍵值的B+樹索引儲存記錄，即受限的索引組織表
2. PostgreSQL公平對待一個記錄的所有索引版本，儲存是不加以區分，而InnoDB的資料儲存主體只儲存最新的版本，老版本儲存在回滾段中，類似於Oracle。

這兩個實現策略的不同，對PostgreSQL和InnoDB對資料訪問扭曲的利用程度都有相當大的影響。[@more@]

首先對比堆儲存和主鍵聚簇儲存。堆儲存的優點在於在某些情況下空間利用率會比主鍵聚簇好，因為按主鍵聚簇時記錄的儲存位置是受限的，而堆儲存時則可以利用 所有的空閒空間。正是基於這一點，大部分資料庫中堆儲存都是預設的儲存方式。但在資料訪問扭曲面前，堆儲存這一完全自由選擇記錄儲存位置的優點卻成了問 題。由於應用無法以任何方式控制記錄的儲存位置和聚簇特性，頻繁訪問的記錄在物理上的儲存連續性完全沒有保障。相對來說，主鍵聚簇儲存就使得應用對資料聚 簇特性有了一些控制權，如根據一個自增的ID聚簇就可以按將資料外掛和順序進行聚簇，對於那些最近的記錄訪問頻繁的應用（很多應用是這樣的）就利用了資料 訪問扭曲的好處；根據userid+id（實際上id完全可以唯一標識一個記錄，使用userid+id作為主鍵純粹是為了改變資料聚簇性質）聚簇就可以 將資料按使用者進行聚簇，對於那些少量使用者的記錄訪問頻繁的應用也有利（對於更新也比較頻率的應用，這一方法也會有點問題）。

PostgreSQL 不加區分的儲存所有版本的策略對利用資料訪問扭曲也是不利的。這裡先要了解一下PostgreSQL裡儲存多版本的策略。簡化來說，PostgreSQL 在每條記錄的每個版本頭部都會記錄兩個事務ID：一個是產生事務ID，一個是消亡事務ID（實際上還有兩個另兩個語句ID，用於實現低於可序列化的隔離級 別，其作用與原理與事務ID是類似的）。PostgreSQL處理多版本的簡單邏輯是這樣的：一個事務更新一個記錄時產生一個新版本，並設定新版本的產生 事務ID和和原版本的消亡事務ID為該事務ID。新舊版本除被組織成一個連結串列外，其物理儲存沒有任何其它聯絡，就好像是兩個記錄一般。事務在讀取到一個版 本時，透過這兩個事務ID與當前事務ID之間的關係來判斷它是否應該看到這個版本。這一實現策略相當簡潔（對索引的多版本儲存尤其是如此），透過索引訪問 時更不會有對回滾段的額外訪問，可以消除事務回滾的代價（在PostgreSQL中事務回滾時除將事務標識為已經回滾外，不用幹什麼事），也不會有 Oracle中繁人的回滾段大小設定問題。

然而這一實現帶來的一個問題是：資料更新不是本地（in place）進行的，即更新產生的新版本不是替換掉原版本，而是插入在別處。等將來舊版本被回收後，就會產生一個儲存上的空洞，為提高儲存空間利用率，就 會用新資料來填補這個空洞。這就使得新插入的記錄的儲存位置更加隨機，從而更無法利用最近的記錄最常被訪問這一常見的資料訪問扭曲行為。對於update 比較頻繁的資料，PostgreSQL的這一策略是有負面引影的。

總之，從對資料訪問扭曲的適用性來看，似乎InnoDB都更勝一籌。PostgreSQL儲存層採用的兩個策略--堆儲存和資料更新的非本地性--對利用資料訪問扭曲都有不良影響。

當 然評價一個儲存引擎絕非這麼簡單的事情，很多其它的設計抉擇甚至是實現細節都會非常大的影響一個儲存引擎的效率，另外儲存引擎只是DBMS的其中一個組 件，而本文討論的資料訪問扭曲也只是資料庫應用的一個方面而已。因此PostgreSQL與MySQL仍有各自適用的場合，即便只是用作Web 2.0應用的資料庫儲存。另外說明特別說明的是PostgreSQL中資料更新的非本地性理論上只有在update操作比較多時才會有影響。很多應用大部 分是insert操作外加少量delete，update極少，這時完全不用考慮這一點。