【51CTO獨家特稿】在那篇文章收到的評論當中，很多讀者朋友都糾結于對NoSQL的評估難題身上——相關利基解決方案數以百萬計，因此實際效果如何“取決于用戶的實際需求。”即使我們已經明確了自己的需求，仍然需要通過深入的研究與學習來掌握特定NoSQL引擎是否有能力滿足這類需求。大家可能無法對這么多解決方案進行一一評估，畢竟其數量實在太過龐大。更糟糕的是，我們還被迫閱讀大量特定引擎的說明文檔，從而了解自己要如何借助NoSQL達到自己的預期效果——而其中大部分內容似乎是在高度關注用戶是否擁有關系型數據或者是否喜愛ACID事務處理方式。

[[117279]]

相比之下，關系型SQL數據庫就擁有非常突出的優勢，大家很清楚該引擎能夠在任何產品當中發揮同樣的作用。我們需要面對的選擇數量也更少，而且這類選項往往更成熟也經過了時間的檢驗。也就是說，大家作出糟糕判斷的可能性要遠遠低于RDBMS。

NoSQL的***吸引力源自其向外擴展的便捷性與強大的數據吞吐能力。盡管能夠擁有可以與RDBMS相媲美的可擴展性確實令人心動，但現實告訴我們、99%的應用程序在執行流程中根本不會對擴展性提出任何要求。大家可以看看Stack Exchange，他們是世界上現存的最繁忙的站點，并且利用商用服務器運行數據庫系統。為了承載這樣的工作負載，該網站直接購買了一臺擁有60核心服務器并配備6TB的內存容量，事實上我們很難想象這樣的設備還需要什么后續擴展。因此，請大家認真考慮這樣一個問題：我們是否真能從NoSQL的可擴展能力身上獲得實際收益？

NoSQL無存儲模式成弊端？

起初筆者認為NoSQL文檔存儲的無模式特性會成為一大優勢，然而筆者在隨后的調查當中逐漸改變了自己的觀點。至少就關系Web應用程序而言，無模式機制只會造成代碼復雜程度的提升、并沒有任何其它貢獻。更進一步，筆者喜歡結構、特別是清晰的數據結構。誠然，如果大家打算構建一套特殊類型的數據庫，用于處理數據歸檔、文件存儲或者事件日志之類任務，那么無模式機制確實有其獨特優勢。但對于無此需求的Web應用程序來說，NoSQL則顯得無甚意義——畢竟這不是社交網絡。

與關系型數據庫相比，采用文檔存儲機制會讓大家的軟件在各個層面上迎來更突出的復雜性難題。我們可以將NoSQL視為一套單純的文件存儲系統，其中文件名代表鍵、而文件內容則代表值。大家可以在這些文件當中保存任何內容，并快速對其進行讀取與寫入，然而存儲背后并不存在任何處理能力。（當然，在這里筆者要歸納一下，NoSQL引擎在對這些文件進行管理與優化方面表現優異，但卻對數據內容本身一無所知。）關系型數據庫當中的內容認知特性全部消失，這迫使大家只能自行完成SQL代碼能夠自動處理的各項事務……而且是針對每一款應用程序。這樣的日常成本對于大多數應用程序而言都是不必要也是不可接受的。

即使是那些有能力創建NoSQL引擎的卓越技術人才自己也很難對自己的產品進行用例描述。通過相關評論可以看到，不少開發者都在努力宣傳自己的產品、但卻無法給出讓用戶選擇NoSQL的真正有說服力的理由。SaaS應用程序其實基本不可能徹底擺脫與關系數據的交集。在這種情況下，大家從RDBMS系統當中獲得的功能特性要遠遠勝過NoSQL系統。筆者認為NoSQL引擎現在需要高度關注那些過去被嚴重忽略的層面與問題。盡管目前充斥著大量NoSQL能夠為關系型應用程序帶來突出性能表現的宣傳，但實際效果恐怕還要讓各位用戶親身驗證。能夠切實從NoSQL身上受益的應用程序在數量上明顯少于能夠從SQL身上受益的應用。一旦宣傳炒作風頭漸消、NoSQL引擎的數量也降低到合理的水平，筆者認為到那時NoSQL才會真正在特定場景中成為一款優秀的工具。筆者還認為，NoSQL未來更可能成為SQL系統的一種有效補充而非替代方案。就目前而言，筆者將繼續堅持自己的SQL路線不動搖。

原文鏈接：

http://www.itworld.com/big-data/428717/nosql-no-go-once-again?source=ITWNLE_nlt_tonight_2014-07-25

原文標題：NoSQL is a No Go Once Again