NoSQL資料庫大比拼: Cassandra, HBase, MongoDB, Riak的測試結果可以得出：根據不同的應用特點選擇不同的NoSQL，沒有萬能的NoSQL資料庫。

主要選擇依據是讀寫比例，但是這個讀寫比例操作起來有難度，很多時候只有等到系統完成上線執行後才能知道這個讀寫比例。但是這時更換資料庫相當於更換底層設施，不亞於在新馬路上打洞。

有沒有在寫程式碼前完成正確的選型呢？

使用CQRS架構。

CQRS也是一種讀寫分離的架構，寫的操作是命令，讀的操作是查詢，寫和讀是兩條路線，很顯然，寫路線的儲存採取寫能力特別快的NoSQL如HBase或Cassandra；而讀路線採取讀能力比較快，比如Sharded MySQL或MongoDB。

關鍵是兩者同步，結合Event Sourcing，寫路線儲存的應該是寫事件，那麼通過一個定時Job，不斷從寫儲存資料庫中讀取寫事件，通過邏輯播放，將結果再寫入讀資料庫中即可。當然邏輯播放是一種批處理機制。如下圖：

可參考NOSQL儲存的基於事件的事務實現：

在這種情況下，由此誕生了相對於ORM的一種新的持久化方式：面向事件資料庫Event Oriented Databases，文章

Event Oriented Databases : a New Kind of Persistence Paradigm對此進行詳細描述。

文章首先對描述事實的資料進行了定義：

資料是一種概念的關係和其度量measure，度量主要由一種型別組成：量化特性，比如重量 總數和年齡，以及定性描述，名稱 城市和日期。幾種資料的在結構上組合形成了事實的描述。

例如：使用者瀏覽電子商務網站並與它進行互動：她增加了一些商品到購物車，並去除了其中一些商品，最後當她已經完成了購買，進行訂單驗證，並隨後支付。每個使用者的操作是由系統處理。系統必須保證使用者操作的ACID屬性：原子性，一致性，完整性和耐用性。

關於最後一點，耐用性，是必不可少的環節，但是在非常複雜的情況下又會失敗。耐用性是通過冗餘機制實現的，比如持久化寫磁碟等，以防止電子裝置掉電。

這個案例中有兩個視角：

1. 從購物車的這個視角看： 它跟隨使用者的動作改變(add a product, remove one, modify its quantity, recalculate the balance, etc.). 購物車總是處於一致的狀態：帶有總數的商品列表，總金額等(不能增加商品，總數和總金額不變，就破壞了購物車自身的一致性)。從這點來看，這個視角根據類似OO正規化中“物件和狀態”視角。

2. 如果從使用者的視角看：使用者發生了一系列動作(add, remove, change quantity, etc.). 當然，每個動作都會被購物車接受，產生了購物車的狀態變化。這個視角更加面向函式FP一些。事件觸發函式，函式改變了狀態。事件是一種確定性的 可定義的 具有不變性的定義，這非常類似FP正規化中的 « function » 視角。

待續..