要對當下的大數(shù)據(jù)解決方案進行分類評估可著實不是易事。首先，大數(shù)據(jù)工具似乎是在一夜之間就如雨后春筍般涌現(xiàn)出來，因此大家自然會對它們抱有一絲懷疑，畢竟像Hadoop與NoSQL這樣的大項目也才剛剛付諸實際應用。

這個嘛……各位的顧慮及審慎的態(tài)度當然值得贊賞，不過實際上大多數(shù)此類解決方案早就已經實際服務于生產生活了；另外，某些舊有方法（例如企業(yè)搜索）也是可以為大數(shù)據(jù)業(yè)務服務的。

Brian Proffitt是一位Linux及開源項目記者兼分析師，他撰寫了一篇相當精彩的文章，詳細闡述了當今IT業(yè)界中較有影響的幾種大數(shù)據(jù)技術。在這里我要向大家鄭重推薦這篇文章，甚至最好把它保存下來，用作日后參考。

首先，Proffitt介紹了NoSQL數(shù)據(jù)庫的特色，并講述了它與關系類數(shù)據(jù)庫有何不同之處。他結合實例概括了以下五種NoSQL（請注意是非關系類）數(shù)據(jù)庫類型：

分布式鍵-值存儲（簡稱DKVS）數(shù)據(jù)庫，又名最終一致性鍵-值存儲數(shù)據(jù)庫。這種數(shù)據(jù)庫在設計上主要是為了處理大量服務器上的數(shù)據(jù)存儲問題。此處的關鍵字是“Dynamo平臺”，因為大多數(shù)DKVS數(shù)據(jù)庫都采用Dynamo平臺或是以Dynamo平臺為基礎。

鍵-值存儲（簡稱KVS）數(shù)據(jù)庫，它將數(shù)據(jù)存儲在硬盤或是內存中，并將鍵與值加以映射。此類解決方案包括開源方案Redis、Berkeley DB以及Memcache DB。

列式存儲數(shù)據(jù)庫，作者將其描述為一套“單獨的、巨大的數(shù)據(jù)庫列表，內部還充滿嵌入式數(shù)據(jù)列表。”Hadoop、Cassandra以及谷歌的BigTable都是列式存儲數(shù)據(jù)庫的典型代表。

文檔式存儲數(shù)據(jù)庫，顧名思義，存儲并對整套文檔數(shù)據(jù)價值進行排序。這類數(shù)據(jù)庫并沒有使用像列表、行、列等常見的方法，而是傾向于使用“非shema類JSON型對象即文檔”方式，這與常規(guī)XML文檔截然相反，他指出。此類數(shù)據(jù)庫中的佼佼者包括MongoDB以及CouchDB。

圖形式存儲數(shù)據(jù)庫。這種類型我不太熟悉，也很難快速掌握其特性，在這里就直接援引原作者的表述：“數(shù)據(jù)操作在一套面向對象的架構中完成，利用圖形來映射鍵、值以及二者之間的關系，而不是通過常見的列表，”他寫道。Neo4j、HypergraphDB以及Bigdata（沒錯，的確有這么一種大數(shù)據(jù)解決方案就叫‘Bigdata’——大家是不是在懊惱自己沒有搶先使用這么好的名字？）都屬于這一類型。

好了，這就是能在網上搜羅到的全部信息了，解釋得也很清楚。不過我們要怎么利用它們處理業(yè)務中的數(shù)據(jù)呢？別擔心，Proffitt同樣精心給出了幾種選擇，朋友們放心，這份清單比上面的要短得多。熟悉關系類數(shù)據(jù)庫的朋友們有福了，因為這些方案都可以直接創(chuàng)建在原有數(shù)據(jù)庫內部。NoSQL就悲劇了，沒有什么能夠直接契合的選項。這里Proffitt給出的方案是：

MapReduce，這款產品在使用上比較復雜，而且常常需要我們進行手動編碼。不過CouchDB與Hadoop也差不多，都比較難用。

企業(yè)搜索產品，這類方案在處理大量文檔及日常業(yè)務等結構化數(shù)據(jù)方面表現(xiàn)極為出色。他列出的備選產品有Apache Lucene、Apache Solr以及ElasticSearch。

就這些，一共兩種選擇。信息量似乎不大，但好處還在后面：Proffitt在他的文章中列出了長達兩頁半的大數(shù)據(jù)服務供應商及解決方案選項。