大資料: 發展還是變革？

無論你是使用關聯式資料庫系統、雜湊表，還是其它結構來維護資料，你肯定對NoSQL和大資料有所耳聞。 目前，谷歌、雅虎和亞馬遜等公司都已經在開發或者使用大資料/NoSQL的解決方案。 但除了一些非常具體的案例外，這些大資料的實現方案真的那麼有用嗎？ 在近期的一篇文章中，凱捷諮詢公司的史蒂夫·鐘斯甚至指出有時候大資料可能就是一大騙局，或者至少還不能完全成為一種萬能藥，可以解決原有關系型資料庫管理系統實現方案中的各種問題，這些你可能都已經注意到了：

我注意到市場上對大資料的宣傳已成氾濫之勢。 有些公司將這種容量的爆炸式增長看作是歷史、新技術、新方法延續的一部分，只是發展而不是變革。 誠然，Map Reduce技術很酷，但它的技術難度也遠勝於SQL和資料庫設計，因此這也意味著該技術遠不能成為一種商業上的萬能藥。

史蒂夫接著指出，可用於存儲極為重要且有一定規模資料集的記憶體資料庫技術（基於關聯式資料庫管理系統）不久將成為現實。 他通過引用一篇文章來闡述自己的觀點，該文章討論了數年前，雅虎是如何使用一種經過重大修改的HTTP://www.aliyun.com/zixun/aggregation/14171.html"> Postgres實現來存儲2PB資料的：

下面是大資料的要點：它95%以上都只是以指數級持續增長的資料，這是與增強的處理能力和存儲容量相匹配的，或者至少是隨之增長的。 （...... ）當然，對索引的優化可能更難，並且你可能要將資料來回移動到固態硬碟上，但嚴格來說，這樣資料量就變得「更大」了，而不是一次簡單的資料移動。

我們過去也從Mike Stonebraker這些人那裡聽說過類似的事情，他表示許多使用者都將受益于諸如重新構建的關聯式資料庫管理系統和列存儲等方法，從而盡可能多地利用主存和固態硬碟，同時仍能保持傳統較強的一致性、ACID語義 ，並在某些情況下可以使用SQL。 但史蒂夫接著重新強調了Map Reduce技術，並且認為這一實現方案背後的模型需要你就如何存儲、查詢和運算元據有一種不同的思維方式，在某種程度上，使用者要將這種解決方案集成到他們現有的投資環境中就變得更加困難了。

就像不會有那麼多人能夠準確地用多執行緒的方式思考一樣，也不會有那麼多人能夠用Map Reduce的方式思考。

當我們經常聽到新的實現方案，或者廠商指望著能鼓動我們採用他們的解決方案時，這又把大資料置於何地呢？ 根據史蒂夫的觀點：

我們發現人們使用大資料的方式和使用SOA一樣，貼個標籤，然後就宣稱 「集成了Hadoop」或「集成了社交媒體（social media）」，或者換個說法，「我們已經建立了一個連接器」。 看看剛剛那個讓你大跌眼鏡的說法吧。 它只是一種老式的學校企業應用集成（EAI）連接器，不過連接到新資料來源或新ETL連接器而已。

這可能算是一種籠統的說法，但也說明了一些事實。 因為現在有過多的炒作，並且太多的廠商都在自己的實現方案上貼上了NoSQL/大資料的標籤，但其實這些實現方案對於手頭上的任務並不適合，那麼在這種「新的資料解決方案」的背後是否有丟失核心資訊的風險呢？ 正如史蒂夫所指出的，這種狀況可能跟SOA的早期應用狀況相似，那時各廠商都在自己的解決方案上貼上SOA的標籤，但實際上大多數方案都根本不是SOA。 那麼你如何準確衡量你需要的是大資料的解決方案，還是提供給你的是場大騙局（正如史蒂夫所言）呢？ 史蒂夫提出了一些建議，至少可以在評估廠商的解決方案時使用。 其中包括：

你可以用「大資料庫（Big Database）」來代替「大資料」嗎？ 如果可以，那它就只是一次更新。 「高級」可以簡化成「我們剛剛獲得一個企業應用集成連接器」嗎？ 是否與2009年的產品基本相同，只不過在新產品上貼上了大資料/NoSQL的標籤？ 有什麼方法可以將處理流程移動到資料上進行，而不是到處移動資料嗎？ 這是過去包括Jim Grey在內的很多人都建議的做法。

不幸的是這些「規則」都不具有科學性，並且都需要某種程度的主觀判斷。 那麼還有其它規則可用嗎？ 如果你已經從傳統的關聯式資料庫管理系統遷移到別的平臺上，那麼你是使用什麼來決定遷移的必要性，以及如何選擇要遷移到的具體實現方案呢？ 這種遷移工作是否成功？ 如果不成功，又是為什麼呢？

(作者 Mark Little 譯者 黎偉 )

(責任編輯：蒙遺善)