在經曆了長達25年的統治地位後，關系型資料庫正面臨越來越火的“NoSQL”挑戰，而挑戰者是以Hadoop為代表的分布式計算開源架構。可以看到，越來越多的消息表明，不管NoSQL是被解釋為“No SQL”還是“Not Only SQL”，如果你面臨海量資料的挑戰，那麼你最應該選的海量資料架構是Hadoop。
但是Hadoop就能代表一切嗎？答案顯然是否定的，Hadoop的MapReduce在性能上的确是有局限性的：比如MapReduce沒有索引，隻有靠強大的運算能力來處理；此外，MapReduce本身存在一些lower-level實作的問題, 特别是skew和資料交換等等。
是以有些人開始回到關系型資料庫上，因為相比較Hadoop的處理能力，一些SQL架構依然呈現數量級的優勢。
也許，我們現在正處于一個新的“NoHadoop”時代，因為越來越多的企業開始認識到，海量資料處理僅有Hadoop是不夠的。在他們看來，簡單的批處理工具比如MapReduce和Hadoop恐怕并不足以應付将來更大的資料結構。誠然，大多數的比較複雜的海量資料處理我們也許能夠用Hadoop就足以對付——也許更多的是一個無奈選擇。它們可能涉及更複雜的連接配接，比如ACID需求、實時要求、超級計算的算法、圖形計算、互動分析或者連續增量的需求等等。
事實上，Hadoop之是以受到越來越多的人歡迎，原因在于它對于海量資料的處理方式，而且，最重要的是，它是免費的。
但是随着對海量資料處理的應用程式性能需求不斷增加，我們會發現，在很多領域，我們需要除了Hadoop以外的更多的海量資料處理方式。
那麼，我們應該怎樣看待下一代分布式計算架構呢？或者說，“NoHadoop”的架構應該是怎樣的呢？從性能上而言，下一代的架構需要在MapReduce/Hadoop的基礎上有10——10000倍的性能提高。
在每一種應用下，都有新一代的資料架構，可以提供所需的規模和效能。在未來的幾年内，這些架構中的某些也許會成為主流。
1、SQL：資料庫已經有了25年的發展曆史。大量的創新正在圍繞資料庫技術，比如VoltDB、Clustrix等等（也許下一代産品不應該再稱為資料庫），但當你需要處理複雜的連接配接，或需要ACID需求時，資料庫依然是你最好的選擇。
應用場景：複雜的業務查詢、線上交易處理。
2、Cloudscale：在海量資料上的實時分析，它打破了自由批量處理的限制。比如，當你打算分析一台百萬次的伺服器中發生的事件流，你需要一個真正的實時資料流體系結構。而Cloudscale架構提供的這種實時資料分析能力，比Hadoop的批處理系統快了近10000倍。
應用場景：商業算法，欺詐檢測，手機廣告、位置服務、市場情報。
3、MPI和BSP：相當多的超級計算機應用中，需要在海量資料上建立複雜的算法，為了實作規模效應，需要對處理器的直接通路調用以提高計算的速度。在并行計算中，MPI和BSP這些工具是進行高性能計算的必要。
應用場景：模組化與仿真系統，流體動力學。
4、Pregel：當你需要分析一個複雜的社交網，或者是要分析網絡的時候，面對的不是資料的問題，而是一個很大的圖形。我們面臨的現狀是，大規模的動态圖形正成為一些應用的關鍵。Google的Pregel結構采用了BSP模型，以便能夠進行規模化、高效的圖形計算。
應用場景：算法，算法的結構圖，地理位置圖，網絡優化等
5、Dremel：這是一個需要與網絡進行大規模互動的資料集。Google的Dremel的設計原理在于支援幾秒内萬億行指令的執行，并提供即時查詢。而它的查詢執行并沒有采用MapReduce 的功能。自從2006年以來Dremel誕生以來，已經有了成千上萬的使用者。
應用場景：資料搜尋、客戶支援、資料中心監控。
6、Percolator (Caffeine) ：如果需要對龐大的資料增量進行不斷更新，你會發現，Percolator是一種很好的實作方式，這也是Google在新的索引系統上采用的架構，Google的即時搜尋引擎Instant不能沒有它。“由于索引内容可以逐漸增加，采用以Percolator的Google Caffeine系統檢索速度将百倍于之前采用Hadoop的分布式資料處理方式。”
應用場景：實時搜尋
原文連結：http://www.sys-con.com/node/1573226
作者簡介：Bill McColl：Cloudscale創始人和首席執行官，牛津大學計算科學系主任，負責并行計算研究中心。
