從需求角度看NOSQL發(fā)展
早先當640kb就足夠使用的觀點流行的時候，數(shù)據(jù)處理規(guī)模很小，需求也不多，于是簡單的文件存儲即可滿足需求，發(fā)展一段時間之后ISAM之類的簡單存儲就可滿足需求，再之后sql流行，當sql為了適應各種需求變得越來越龐大的時候，效率也止步不前，在將緩存和多線程性能榨取完了之后，sql各項性能還只停留在滿足常規(guī)應用的地步，難于處理1秒萬次以上的讀寫操作，也難于解決萬個以上的并發(fā)連接，一般的企業(yè)不可能動不動就上硬件，所以nosql發(fā)展是時代的需要是需求的推動。當然一般sql對傳統(tǒng)企業(yè)還是足夠滿足的，所以我們在nosql的發(fā)展上沒看到傳統(tǒng)企業(yè)的身影，只看到當前發(fā)展最快的SNS公司積極推動nosql不斷發(fā)展，著名的如：Facebook 推動Cassandra發(fā)展，Linkedin推動Voldemort發(fā)展，這都是最大的一類sns網(wǎng)站，這些網(wǎng)站都有幾千萬以上的用戶，巨量數(shù)據(jù)讀寫，所以這些數(shù)據(jù)庫都是極其強調(diào)分布式應用的，并不單純的強調(diào)每個點的讀寫性能。再看小一點的mixi推動的Tokyo Cabinet和Tokoy Tyrant，green.jp推動Flare的發(fā)展，這些數(shù)據(jù)庫都滿足于幾千萬條數(shù)據(jù)的高速訪問，也沒看到特別的強調(diào)并發(fā)性，只強調(diào)他們的速度，當然幾千萬條數(shù)據(jù)還是有可能全放在內(nèi)存里面的，就算放不下全部數(shù)據(jù)也至少可完全放下全部索引，這樣讀寫當然快了，據(jù)說tt到億條之后寫性能急劇下降，大概就是這個原因吧。純內(nèi)存式數(shù)據(jù)庫也必須要提一下，典型的如LiveJournal開發(fā)的memcached以及另一個新秀Redis等，前面提到的tt也支持memcached的協(xié)議，雖然這類數(shù)據(jù)庫有很多局限，但在某些場合的確又很適合，memcahced其實連持續(xù)存儲都不支持，為了解決持續(xù)存儲問題，又有人發(fā)展了一些，如tt其實就是一個支持存儲的memcached，國內(nèi)新浪團隊也給memcached加上berkeleydb支持持續(xù)存儲。
上面說了這么多，無非想說一句話，需求推動技術(shù)進步，每一個技術(shù)進步其實都是為了滿足某種需求的結(jié)果，就如google的三大基石bigtable、gfs、map/reduce都是為了解決它的巨量數(shù)據(jù)而折騰出來的東西，google也正是靠這幾個核心技術(shù)把持了互聯(lián)網(wǎng)近十年的風光。同理我們可以想見，雖然百度沒有大力的宣傳他們的底層技術(shù)，但我們很容易想到，他們一定也是需要這些技術(shù)的，而且他們內(nèi)部就算沒有這些技術(shù)，但一定有類似的接替代產(chǎn)品，否則支撐不了他們那么巨量的數(shù)據(jù)，雖然替代產(chǎn)品未必有google的產(chǎn)品那么好，但大概是略差一點或相當?shù)乃桨伞鴥?nèi)互聯(lián)網(wǎng)巨頭騰訊支持了國內(nèi)最大的im應用 10億級，最大的棋牌游戲近億在線，加上他們布局網(wǎng)絡門戶，布局qzone等，都是巨量用戶，可以想見他們一定有類似的方案，早先聽說他們棋牌游戲是通過很多mysql + proxy來完成的，雖然這個方式現(xiàn)在看起來也不是很完美，但至少是一個可行的解決方案，臆測下可以這樣使用，proxy有個巨大的hash表，每個qqid計算一下就知道在哪個區(qū)段，重定向到哪個區(qū)段讀寫數(shù)據(jù)即可，說起來容易做起來難啊，就算我玩種菜都不知道遇到多少次他們數(shù)據(jù)出故障了，說明他們的系統(tǒng)面對巨大數(shù)據(jù)壓力的時候還是碰到了很多問題。國內(nèi)還有個公司不得不提，阿里巴巴淘寶，馬云團隊發(fā)跡很快，淘寶每年不知道要成交多少筆，但他們的數(shù)據(jù)也是一個天量，看了下他們dba團隊的主頁，牛一點的dba都籠絡了不少，就是自己開發(fā)能力稍弱了一點，縱觀國內(nèi)對巨量數(shù)據(jù)需求最迫切的也就這幾家公司了，雖然之后的51、開心網(wǎng)、盛大等也有類似需求，但數(shù)據(jù)量總歸還是沒有超過前面幾家公司。
在需求的推動下，國內(nèi)的nosql、key-value應用也慢慢發(fā)展了一些，如張宴在新浪搞的memcachedb，到金山之后搞的dbcached，豆瓣開發(fā)的beansdb等，還有一些沒開源沒介紹不大為外界知道的應該也有一些，但總的來看水平還是比較低，有點不成氣候的樣子，靠的大多是1-2個牛人支撐，離開了這么幾個人就不行了，東西也沒人維護，的確，離開了巨量數(shù)據(jù)的需求一般的企業(yè)用sql就能滿足也不會去研究這些東西，少數(shù)小一點的互聯(lián)網(wǎng)企業(yè)有這個需求又沒有相應的人才有能力去研究，年輕一點的開發(fā)人員都在玩概念想做也做不出這些東西，畢竟做這些東西沒有很深厚的數(shù)據(jù)結(jié)構(gòu)知識，沒有3-5年的深入編程磨練是不可能真正做好一個像樣東西的，矛盾啊。
最后說下我最近在做的一個東西，分布式md5計算，這個東西網(wǎng)上隨便查一下就知道做的人不少，提供網(wǎng)站服務的都不少，但搜了幾篇文章，看了幾個網(wǎng)站www.cmd5.com www.md5.com.cn就知道，水平之低下超出了我的想象，基本上還是停留在用sql數(shù)據(jù)庫的層次上，根據(jù)這些網(wǎng)站寫的時間節(jié)點感覺他們大多數(shù)時間就是在制造數(shù)據(jù)，速度大概是幾個月制造幾十億條數(shù)據(jù)，都號稱有幾萬億條數(shù)據(jù)，但事實上提供公開查詢的數(shù)據(jù)只有區(qū)區(qū)幾億條，其他都要收費才能查詢，天知道到底有沒有那幾萬億條記錄，看上很吸引人，其實用處不算很大，用我最近整的md5數(shù)據(jù)制造方法1秒制造100w條數(shù)據(jù)，1億條數(shù)據(jù)也就在2分鐘內(nèi)搞定，幾億條數(shù)據(jù)也不過10分鐘左右就生成好了，1億條記錄耗費空間1.5G左右，不過10G左右空間即可，技術(shù)含量可見并不是很高。 其實我做這個項目并不是想做個類似的網(wǎng)站，主要是覺得這個東西玩技術(shù)很有意思，可大可小，一臺機器也可玩，1T硬盤放600億數(shù)據(jù)沒問題，1萬臺機器也不多，全字母遍歷到10位就算是上1w臺機器也不夠用，分布式存儲分布式計算典型云計算概念，client可p2p可不p2p，很多技術(shù)元素都可參與其中，很有玩性的一個程序，所以就較上勁了，也好，正好練練技術(shù)，玩玩nosql的概念。
各種新興技術(shù)出來都看到國內(nèi)有深入分析，就說nosql系列的吧，深入分析memcached，深入分析tt，深入分析Cassandra的文章不計其數(shù)，到底也沒看到有幾個國人能寫類似的東西，分析得頭頭是道，做的時候白癡一樣，就算是使用都難用好，更別說自己動手做個這方面的好產(chǎn)品了，國情如此，略感欣慰的是國內(nèi)現(xiàn)在也有一些公司和一些高水平的人真正參與其中，未來還是有可能有所突破的，正入本文所說，需求會推動技術(shù)發(fā)展，但短期肯定還是國外為主，國內(nèi)的產(chǎn)品最多是一絲點綴。