在大數據引起業界廣泛關注的同時，Hadoop、非結構化數據、分布式計算等新名詞也引發IT人士的討論和研究。其中，傳統關系型數據庫對大數據處理的局限，使得NoSQL這一技術廣受追捧。

在NoSQL的更快數據存儲速度讓人們倍感興奮和陶醉之后，如今NoSQL的蜜月期已經結束，熱情散去之后，我們需要以冷靜的目光審視那些難以接受的真相。

請不要誤會。我們目前仍然在不斷地嘗試創建一個簡單的數據存儲機制，也仍然在挖掘MongoDB、CouchDB、Cassandra、Riak和其他NoSQL數據庫的深層次價值。我們仍然在規劃將最重要的數據存儲在NoSQL數據庫中，因為它們正在日益強大，越來越經得起考驗。

不過，我們也開始察覺到了一些問題，NoSQL似乎沒有我們想像中的那么完美，它們甚至經常令人感到惱火。明智的開發者明白這一切只是剛剛開始。他們沒有扔掉SQL操作手冊，也沒有中斷與他們曾經信任的SQL數據庫供應商之間的聯系。他們將NoSQL理解為“Not Only SQL”。

以下是NoSQL目前面臨問題的列表，這些問題或大或小，我們這樣做的目的是向公眾展現實際的情況并澄清事實。只有坦然面對這些問題，才能夠更好地理解NoSQL的優勢與不足。

真相1：一致性困擾

人們對SQL系統的一個不滿意地方是，在兩個表單間執行一個連接（JOIN）所需的計算成本。其理念是在一個，即唯一的一個地方存儲數據。如果你保存一個客戶名單，將他們的住址保存在一張表單上，在其他的每一張表單上使用客戶的ID。當你拖動數據時，JOIN將所有ID與住址連接在一起，讓所有的數據保持一致性。

問題是JOIN非常昂貴，一些DBA（數據庫管理員）使用極為復雜的JOIN命令，它們能讓最好的硬件也會變成垃圾。NoSQL開發者是這么解決JOIN不足的：讓我們將客戶的地址像其他所有的東西一樣都存儲在相同的表單上。NoSQL的做法是存儲與每個人配對的鍵值。在需要時，你可以檢索到它們。

不幸的是，希望讓自己的表單保持一致的人們仍然需要JOIN。一旦開始存儲客戶的地址，你需要經常將這些地址的多個拷貝保存在每張表單中。你擁有多個拷貝，并且需要同時升級它們。如果你沒有這么做，那么NoSQL將不會幫你進行交易。

真相2：交易復雜性

如果說你能夠習慣沒有JOIN的表單，因為你希望獲得更高的速度。這種取舍還是可以接受的。有時候，SQL的數據庫管理員就是出于這種原因才使用非規范化表單的。問題是NoSQL難以保持各種條目的一致性。很多時候，沒有一個交易可以確保能同時對多個表單做出調整。出于這種原因，你只有依靠你自己，一個崩潰將會導致表單變得前后矛盾。

最早的NoSQL部署無視這些交易。除非沒有設定一致性，否則它們將提供保持一致性的數據列表。換句話說，他們追求的是最低價值的數據。在這種情下，錯誤不會導致任何重大差異。

真相3：靈活性怪圈

許多NoSQL程序員喜歡吹噓他們的代碼如何簡潔，工作機制運行的速度有多快，等等。當任務像NoSQL那樣簡單時，通常他們的說法是對的，但是當問題復雜之后，情況就改變了。

我們應該考慮到JOIN的挑戰。一旦NoSQL程序員開始在他們自己的邏輯中加入自己的JOIN命令，他們就會開始嘗試更為有效地做這項工作。SQL數據庫開發者花了數十年的時間開發巧妙的引擎，以便讓JOIN命令盡可能地高效化。一個SQL數據庫開發者告訴我，他正在嘗試讓自己的代碼與硬盤轉速同步。這樣一來，他就能夠僅在磁頭處于正確位置時請求數據。這看起來有些極端，但是SQL數據庫開發者為此已經努力了十余年的時間。

毫無疑問，程序員們已經絞盡腦汁組織他們的SQL查詢，以利用所有的潛在優勢。其中的過程可能很艱辛，但是當程序員找到了解決辦法，這些數據庫就能夠真正煥發出活力。

真相4：訪問模式過多

在理論上，SQL被認為是一種標準的語言。如果你在一個數據庫中使用SQL，你應該能夠在另外一個兼容版本中執行相同的查詢。這一說法可能僅對一些簡單的查詢有效，但是每個DBA都清楚，他們需要花上數年時間才能掌握不同版本數據庫的SQL的特點。關鍵詞被重新定義，在一個版本中正常運行的查詢，在另一個版本中可能就無法正常運行。

NoSQL更為神秘莫測，它們就如同通天塔一樣。從一開始，NoSQL開發者就在竭盡全力地想要設計出最佳語言，但是他們的設想有著很大的差別。起初實驗效果還是不錯的，但是當你嘗試在工具間切換時情況就變了。CouchDB查詢被表述為用于映射與約簡的JavaScript功能。Cassandra早期版本使用了一個原始而低級的API（應用編程接口），即Thrift。新版本推出了CQL，一種與SQL類似的查詢語言，它必須要被服務器所解析和理解。每一個的設計原理都不盡相同。

真相5：綱要靈活性存在問題

NoSQL的一個重要理念是不需要綱要。換句話說，程序員不需要提前決定表單中的每一個行需要使用哪個列。一個條目可能有20個相關的字符串，另一個可能有12個整數類型，另一個可能完全是空白。程序員能夠在他們需要存儲時隨時做出決定。他們不需要獲得DBA的許可，他們也不需要填寫所有的文檔，以增加一個新的列。

這些自由聽起來非常具有誘惑力，并且能夠加快開發速度。但是對于需要三個開發團隊的數據庫來說，這真的是一個好主意嗎？對于可能持續六個月以上時間的數據庫來說，它們是否可行？

換句話說，開發者可能希望利用這些自由將老的Pair（對）加入到數據庫中。但是，在四名開發者已經選擇了他們自己的鍵后，你希望成為了第五名開發者嗎？我們可以想象一下“birthday”（生日）的多種表達方式。在添加用戶生日進入條目中時，每名開發者都會選擇他們自己的表示方式。一個開發團隊幾乎可能會想到所有的表示形式，例如“bday”、“b-day”和“birthday”。NoSQL架構并不支持限制這一問題，因為這意味著要重新設計綱要。它們不希望對個性化的開發者加以限制。

真相6：沒有附加功能

你不希望把所有的數據存儲在所有的行中。你希望得到單選索引的總數。SQL用戶能夠通過SUM操作執行一個查詢，然后向你反饋一個數字。NoSQL用戶則將所有的數據反饋至他們那里，然后自己進行添加。添加并不是問題，因為在任何機器上增加數字都需要花上相同的時間。但是數據反饋卻非常慢。反饋所有數據所需要的帶寬也非常的昂貴。

NoSQL數據庫中幾乎沒有附加功能。除了存儲和檢索數據外，如果你想做任何事情，你可能需要自己動手。在許多案例中，通過完整的數據復制，你可以在不同的機器上做這些事情。真正的問題是，它對在保留有數據的機器上進行計算有幫助，因為可以省去數據反饋的時間，但是對于你來說卻是非常的困難。

MongoDB提供的映射與約簡查詢架構可以讓你通過任意的JavaScript架構來簡化數據。在擁有數據的機器間分發計算方面，Hadoop是一個強大的機制。它是一個快速演進的架構，可以為創建復雜的分析快速提供改良的工具。這聽起來非?？幔荋adoop技術本身卻非常新。盡管Hadoop與NoSQL之間的差別正在消失，但是在技術上，Hadoop是一個與NoSQL完全不同的東西。

真相7：工具太少

你能夠在服務器上部署NoSQL并運行它們。當然，你也能夠編寫你自己自定義代碼以讀寫數據。但是如果你希望做更多的事，那它們會怎么樣呢？如果你想購買一個報告套件，一個繪圖套件或是下載一些用于創建圖表的開源工具，它們又會怎么樣呢？

很不幸，大多數工具都是針對SQL數據庫編寫的。如果你想生成報告，創建圖表，或是利用NoSQL堆棧中的數據做一些事情，你需要重新進行編寫。目前已經有了用于處理來自甲骨文數據庫、微軟SQL Server、MySQL和Postgres等SQL數據庫中數據的標準工具。你的數據是NoSQL類型的嗎？目前工具制造商們正在努力解決這些問題。

目前有20多個不同的NoSQL選擇，這些選擇都擁有自己的理念和處理數據的方式。對于工具制造商而言，他們難以支持SQL的特點和不一致性。然而與之相比，為NoSQL解決方案制造相關工具則更為困難。

當然，這一問題會慢慢消滅。開發者們已經意識到了NoSQL的優勢，他們將修改自己的工具，以適合這些新的系統，不過這要花上些時間。或許他們會針對MongoDB開發出一些工具，但是這對于使用Cassandra的用戶而言沒有絲毫的幫助。在這種情況下，標準就顯得尤為重要，但是在這一方面，NoSQL并不擅長。

傳統關系型數據庫在處理結構化數據上依然有著不可比擬的優勢，NoSQL能否成為關系型數據庫的終結者尚有待時間來見證，這也將影響到大數據的火種能燃燒多大的能量。