三年前在infoq發表的一篇關于兩種特別有代表性的分布式存儲的設計思路解析，三年過去了，今天再來總結看看這幾年的變化。

實際上，這三年，還是兩個東西，一直沒有冒出來更牛x的東西。

[[74528]]

一、dynamo代表作riak特點

早幾年以cassandra為代表此類項目，固定特點為：水平擴展、無中心節點、多備份、最終一致性、性能一般、適合海量數據。因為cassandra在業界的使用失敗案例太多，讓大家避而遠之。這兩年，以erlang開發的riak又冒出水面。

1.1 erlang

這作為riak的最大特點一點也不為過，因為語言在分布式領域的獨特能力，使得riak的源代碼十分簡潔干凈。不過一萬多行的代碼，在第一次讀到它的代碼時，我也感嘆，幾年前，傻希希的用java代碼堆了十幾萬行的nuclear代碼，真是太笨了。

1.2 完整的dynamo實現

在cassandra的年代，許多東西不方便實現，版本控制的向量時鐘使用了timestamp代替，vnode在cassandra上是非常大的區塊，在進行負載均衡時有很大可能不均勻。到了riak的時代，所有的特點，在erlang的支持下，完成了各種細節。并且增加了：1.http存取的支持。2.雙向索引。3.搜索支持。4.m/r支持。

二、bigtable代表作hbase特點

與dynamo對應的解決方案bigtable的歷史更加悠久一些，開源項目也進行了很多年，hbase社區也正在不斷地完善。

1.1 偷懶地依賴hdfs

嚴格說來hbase的實現，只主要關心了regionServer（中心節點所在，用來分配數據所在位置），所以說偷懶地在底下使用了hdfs完成備份工作。

1.2 列簇

在借用hdfs之后，在其上實現的存儲格式讓hbase可以滿足各式各樣的需求，當然了，這么復雜的交互，最好還是使用ssd之類的高速度的存儲介質。

三、發展方向及特點

在回顧了兩大陣營的各自特點之后，再來看看未來。

3.1 mysql時代

招一堆的mysql dba，指哪打哪，哪壞修哪。工作得很好!

3.2 nosql時代

開發工程師了解了dba的苦逼，以及老板招不到dba的苦逼，決定將數據結構化，簡化代碼的數據結構。

典型的代表key-value系統。

再基于這些單一的結構，做一堆的自動加機器自動轉數據的功能。riak在此列。hbase略高于此。

3.3 未來時代

不僅是存儲，整個運維工作，都應該是自動化演進，你可以想象：一個晴朗的下午，工程師帶著耳機聽著歌，將需求模型輸入之后，一個紅按鈕一按，代碼已經寫好，test自動開始，AB test，staging，一切OK，自動分發到了各處。上線五分鐘，某處開始報警，中央自動判斷如何添加機器，執行添加。

－－寫在32位服務器已經過時了的日子，紀念一下，中國都應該記住。

原文鏈接：http://www.54chen.com/architecture/distributed-auto-ops.html