無論你是使用關(guān)系型數(shù)據(jù)庫系統(tǒng)、哈希表，還是其它結(jié)構(gòu)來維護數(shù)據(jù)，你肯定對NoSQL和大數(shù)據(jù)有所耳聞。 目前，谷歌、雅虎和亞馬遜等公司都已經(jīng)在開發(fā)或者使用大數(shù)據(jù)/NoSQL的解決方案。但除了一些非常具體的案例外，這些大數(shù)據(jù)的實現(xiàn)方案真的那么有用嗎？在近期的一篇文章中，凱捷咨詢公司的史蒂夫·瓊斯甚至指出有時候大數(shù)據(jù)可能就是一大騙局，或者至少還不能完全成為一種萬能藥，可以解決原有關(guān)系型數(shù)據(jù)庫管理系統(tǒng)實現(xiàn)方案中的各種問題，這些你可能都已經(jīng)注意到了：
我注意到市場上對大數(shù)據(jù)的宣傳已成泛濫之勢。有些公司將這種容量的爆炸式增長看作是歷史、新技術(shù)、新方法延續(xù)的一部分，只是發(fā)展而不是變革。誠然，Map Reduce技術(shù)很酷，但它的技術(shù)難度也遠勝于SQL和數(shù)據(jù)庫設(shè)計，因此這也意味著該技術(shù)遠不能成為一種商業(yè)上的萬能藥。
史蒂夫接著指出，可用于存儲極為重要且有一定規(guī)模數(shù)據(jù)集的內(nèi)存數(shù)據(jù)庫技術(shù)（基于關(guān)系型數(shù)據(jù)庫管理系統(tǒng)）不久將成為現(xiàn)實。他通過引用一篇文章來闡述自己的觀點，該文章討論了數(shù)年前，雅虎是如何使用一種經(jīng)過重大修改的Postgres實現(xiàn)來存儲2PB數(shù)據(jù)的：
下面是大數(shù)據(jù)的要點：它95%以上都只是以指數(shù)級持續(xù)增長的數(shù)據(jù)，這是與增強的處理能力和存儲容量相匹配的，或者至少是隨之增長的。（……）當然，對索引的優(yōu)化可能更難，并且你可能要將數(shù)據(jù)來回移動到固態(tài)硬盤上，但嚴格來說，這樣數(shù)據(jù)量就變得“更大”了，而不是一次簡單的數(shù)據(jù)移動。
我們過去也從Mike Stonebraker這些人那里聽說過類似的事情，他表示許多用戶都將受益于諸如重新構(gòu)建的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)和列存儲等方法，從而盡可能多地利用主存和固態(tài)硬盤，同時仍能保持傳統(tǒng)較強的一致性、ACID語義，并在某些情況下可以使用SQL。但史蒂夫接著重新強調(diào)了Map Reduce技術(shù)，并且認為這一實現(xiàn)方案背后的模型需要你就如何存儲、查詢和操作數(shù)據(jù)有一種不同的思維方式，在某種程度上，用戶要將這種解決方案集成到他們現(xiàn)有的投資環(huán)境中就變得更加困難了。
就像不會有那么多人能夠準確地用多線程的方式思考一樣，也不會有那么多人能夠用Map Reduce的方式思考。
當我們經(jīng)常聽到新的實現(xiàn)方案，或者廠商指望著能鼓動我們采用他們的解決方案時，這又把大數(shù)據(jù)置于何地呢？根據(jù)史蒂夫的觀點：
我們發(fā)現(xiàn)人們使用大數(shù)據(jù)的方式和使用SOA一樣，貼個標簽，然后就宣稱 “集成了Hadoop”或“集成了社交媒體（social media）”，或者換個說法，“我們已經(jīng)建立了一個連接器”?？纯磩倓偰莻€讓你大跌眼鏡的說法吧。它只是一種老式的學校企業(yè)應用集成（EAI）連接器，不過連接到新數(shù)據(jù)源或新ETL連接器而已。
這可能算是一種籠統(tǒng)的說法，但也說明了一些事實。因為現(xiàn)在有過多的炒作，并且太多的廠商都在自己的實現(xiàn)方案上貼上了NoSQL/大數(shù)據(jù)的標簽，但其實這些實現(xiàn)方案對于手頭上的任務并不適合，那么在這種“新的數(shù)據(jù)解決方案”的背后是否有丟失核心信息的風險呢？正如史蒂夫所指出的，這種狀況可能跟SOA的早期應用狀況相似，那時各廠商都在自己的解決方案上貼上SOA的標簽，但實際上大多數(shù)方案都根本不是SOA。那么你如何準確衡量你需要的是大數(shù)據(jù)的解決方案，還是提供給你的是場大騙局（正如史蒂夫所言）呢？史蒂夫提出了一些建議，至少可以在評估廠商的解決方案時使用。其中包括：
- 你可以用“大數(shù)據(jù)庫（Big Database）”來代替“大數(shù)據(jù)”嗎？如果可以，那它就只是一次更新。
- “高級”可以簡化成“我們剛剛獲得一個企業(yè)應用集成連接器”嗎？
- 是否與2009年的產(chǎn)品基本相同，只不過在新產(chǎn)品上貼上了大數(shù)據(jù)/NoSQL的標簽？
- 有什么方法可以將處理流程移動到數(shù)據(jù)上進行，而不是到處移動數(shù)據(jù)嗎？這是過去包括Jim Grey在內(nèi)的很多人都建議的做法。
不幸的是這些“規(guī)則”都不具有科學性，并且都需要某種程度的主觀判斷。那么還有其它規(guī)則可用嗎？如果你已經(jīng)從傳統(tǒng)的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)遷移到別的平臺上，那么你是使用什么來決定遷移的必要性，以及如何選擇要遷移到的具體實現(xiàn)方案呢？這種遷移工作是否成功？如果不成功，又是為什么呢？
(作者 Mark Little 譯者 黎偉 )