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

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

[[74528]]

一、dynamo代表作riak特點(diǎn)

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

1.1 erlang

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

1.2 完整的dynamo實(shí)現(xiàn)

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

二、bigtable代表作hbase特點(diǎn)

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

1.1 偷懶地依賴hdfs

嚴(yán)格說來hbase的實(shí)現(xiàn)，只主要關(guān)心了regionServer（中心節(jié)點(diǎn)所在，用來分配數(shù)據(jù)所在位置），所以說偷懶地在底下使用了hdfs完成備份工作。

1.2 列簇

在借用hdfs之后，在其上實(shí)現(xiàn)的存儲格式讓hbase可以滿足各式各樣的需求，當(dāng)然了，這么復(fù)雜的交互，最好還是使用ssd之類的高速度的存儲介質(zhì)。

三、發(fā)展方向及特點(diǎn)

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

3.1 mysql時代

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

3.2 nosql時代

開發(fā)工程師了解了dba的苦逼，以及老板招不到dba的苦逼，決定將數(shù)據(jù)結(jié)構(gòu)化，簡化代碼的數(shù)據(jù)結(jié)構(gòu)。

典型的代表key-value系統(tǒng)。

再基于這些單一的結(jié)構(gòu)，做一堆的自動加機(jī)器自動轉(zhuǎn)數(shù)據(jù)的功能。riak在此列。hbase略高于此。

3.3 未來時代

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

－－寫在32位服務(wù)器已經(jīng)過時了的日子，紀(jì)念一下，中國都應(yīng)該記住。

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