寫在前面
本文主要是從學術而非商業數據庫實踐的角度來介紹分佈式DBMS H-Store。H-Store是由Brown，MIT，CMU聯合開發並在MIT的實驗室成功部署實現的。
H-Store的研究者對外界公佈的關於H-Store的論文主要是以下兩篇：
The end of an architectural era, VLDB’07
H-Store: A High-Performance, Distributed Main Memory Transaction Processing System, PVLDB’08
其中第一篇是在分析和總結了面向磁盤數據庫管理系統的種種弊端，從架構設計這一角度，高屋建瓴地提出了DBMS面臨改革的必須，而引出了可能的新型內存數據庫系統的設計，也成爲了H-Store的原型；在第二篇文章中，研究者在前一個工作的基礎上，對H-Store的設計做了更清晰的描述，每一部分的功能也更加具體化了，進而成爲廣受學術界歡迎和使用的關係數據庫管理系統。順帶一提，H-Store有一個商業化的版本，叫做voltDB。
本文是結合第二篇論文來進行講解的，因此篇幅也會比較短。如果想閱讀更多關於H-Store的內容，歡迎閱讀官方的介紹和源碼：
背景介紹
在H-Store, voltDB, Redis等一系列內存數據庫管理系統問世以前，主流的DBMS是基於R系統1的，因此如H-Store研究者所言，因其太過“通用和廣泛”，在性能上存在極大地瓶頸。尤其是對於TPC-C2這一類事務具有高度重複性及短壽性的benchmark來說，執行開銷眼中，可用組件被多餘的組件掣肘，不能發揮全部的功效。研究者認爲，必須通過橫向擴展系統，分割事務及處理職能給多個無共享架構（shared-nothing architecture）3的主機節點，纔能有效提高DBMS的性能。
另外，面向數據庫的DBMS存在着嚴重的IO開銷，尤其是對於併發控制來說，鎖機制會導致high skew（即事務多次重複訪問相同部分的數據）下性能受阻。
因此，H-Store被開發爲一個分佈式的內存數據庫系統。
系統概述
H-Store的系統設計架構如上圖所示。
先列出幾個H-Store的術語名詞：
- H-Store實例(instance): 由同一管理域部署的H-Store節點的集合；
- H-Store節點(node)：一個部署了一個或多個H-Store站點的單機系統；
- H-Store站點(site)：基本的操作實體，在多處理器系統中，通常一個處理器負責一個站點，它是一個單線程的守護進程，連接到外部的應用
每一個站點與其他站點（無論是否在同一主機節點上）都是相互獨立的，既不共享數據結構也不共享內存。
數據庫中每一個關係（relation）都被劃分爲一個或多個子集（partition），（由administrator控制管理）分佈在多個站點中，形成replica集合。這就是說，一個relation可能分佈在好幾個不同的站點上（
由圖1可以看出，H-Store的整個框架可以分爲部署時和運行時兩個部分。部署部分是在運行transaction之前就已經執行的。H-Store提供了一個帶有cluster部署框架的管理器，它將存儲程序、數據庫schema、採樣負載和cluster中的可靠站點作爲輸入，輸出一系列用來引用運行時程序的獨特的調用句柄。
此處值得注意的是，存儲程序是H-Store設計者爲了更高效執行transaction而採取的特殊手段。簡單理解的話，可以把存儲程序當做transaction本身。當一個transaction來臨時，H-Store不是針對transaction本身去運行，而是執行transaction喚醒的存儲程序，從而使得執行效率得到提高。
部署部分使用了兩個階段的query優化，具體細節我沒有讀，應該在第一篇論文裏提及了。
運行時部分相對來講更容易解釋一些，OLTP應用與H-Store實例進行交互，通過API傳入transaction。無論transaction所需要的數據是否在交互站點上，該站點都可以執行OLTP應用。比如OLTP應用隨機地選擇站點1進行交互，要求執行任務，但是transaction請求的數據大部分不在站點1，而是分佈在站點2，3及5。這個時候，站點1就會與2、3、5進行通信，傳達transaction任務。當transaction執行完畢後，各個站點會回送完成或失敗信號給站點1，站點1再與應用交互。
數據庫特性
與面向磁盤的數據庫相仿，分佈式內存數據庫的性能也依賴於數據放置策略和物理數據庫設計的支撐數據結構。但是由於OLTP的transaction具有高重複性，單任務短暫性的特點，可以對整個設計進行優化。
Transaction分類
- 單站點transaction： 包含的所有的queries可以由H-Store cluster中的一個站點來執行；
- One-shot transaction：所包含的queries不能由一個站點來執行完畢，但其中每個query都可以由一個站點來執行（說明該query所請求的數據全部在同一個站點上）
對於以上兩種類型的OLTP Transaction，H-Store選擇的優化方案是將transaction或者query交由特定的站點來執行，最小化節點之間的通信，從而提高系統性能。
容錯與負載
由於H-Store不在磁盤上存儲任何（數據庫）數據，它就必須依賴一種數據分佈策略來保證可靠性。它採用的是k-安全策略，這一點我們在前述部分已經講過，即是將相同的partition分佈在k個不同的站點上，這樣當其中k-1個站點故障時，該partition的數據仍然可以使用。
另一方面，由於某些數據的訪問頻度較高，也就是存儲該數據的站點訪問頻度也會隨之增高。這可能會造成H-Store各節點工作負載不均衡的情況。一旦負載不均衡的情形超出控制器的監視指標，則H-Store的管理器需要對各partition的數據進行調整和分配。
總結與思考
H-Store是一個比較老的內存數據庫系統，但是無論在今天還是今後的研究中，它都對我們具有十分重要的價值。無論是它本身分佈式設計的理念，內存數據庫分割數據，可靠性保證的方法，還是研究者在後來幾年基於它所設計的Anti-Caching系統，都非常具有啓發性。
我目前想做的是圍繞H-Store系統，結合非易失內存NVM，針對數據logging和可靠性保證做出一點新意。結合上次的NVWAL，也許H-Store在修改的地方與SQLite會有較大的不同，這也是我可以插上一手展現自己創新工作的點。