NoSQL 再次敗北——我堅持使用 SQL 的原因

【編者按】NoSQL擁有可擴展性和超高吞吐量的能力，然而這卻沒有發揮實際的優勢，同時它不具備關系數據庫所有的智能操作，雖然具有無模式存儲的優勢，卻無形中增加了代碼的復雜度。更多的應用證明使用NoSQL如此困難，它僅能成為SQL系統的構件而不是替代品。

這是我第二次為新項目深入調研NoSQL，也是第二次決定放棄NoSQL。跟我上次發表的“為什么選擇使用NoSQL如此困難”的結論一樣，我們最終決定放棄NoSQL，使用傳統關系型數據庫。

我從上個帖子的許多評論中得出評估NoSQL的一大問題——其解決方案指向的核心是“取決于你的需求”。但盡管需求明確，仍需要花時間調研并搞清楚 一個特定的NoSQL引擎是否正是你所需。有太多方面，你不可能評估所有的。更糟的是，你得費力的從engine-specific文檔中解讀出它是否能 夠實現你的目標，那些文檔大多是類似選擇關系型數據或者ACID的解決方案。

相比之下，如果使用關系型SQL數據庫，大多數情況下，不管是哪種特定產品，你都能知道它的工作方式，不需要反復比對選擇，也比較成熟穩定。選擇RDBMS能大大降低做錯誤決定的風險。

NoSQL的吸引力在于擁有可擴展性和超高吞吐量的能力。就算其擴展性真的優于RDBMS，然而現實世界的事實是，99%的應用程序都不會變更數據 模型。比如Stock Exchange，它是訪問量最大的網站之一，它們的商品服務器是運行在MSSQL上的。而且很難想象NoSQL需要多么巨大的存儲空間，購買一個60- core、高達6TB內存的服務器基本是不可能的。所以使用NoSQL的實際好處又是什么？

起初我認為無模式存儲是NoSQL的一個優勢，但我已經改變了我這個觀點。至少對于關系型頁面應用程序，無模式只不過是在增加代碼復雜度。此外，我 喜歡結構，特別是數據結構。在數據歸檔、文件存儲、或事件日志這類數據處理中無模式是很有用的，但是對于非社交類的頁面應用程序卻沒有任何優勢。

與關系數據庫比起來，文檔存儲會使程序的每個部分都變得更加復雜。對于那種可以將文件名作為key，文件內容作為value的平行文件存儲 （key-value數據庫），NoSQL是很有優勢的，你可以在這類文件中存儲任何所需內容，讀取的時候也會很方便，但這種存儲很腦殘。我的結論 是，NoSQL在管理和優化所存儲的文件時是非常復雜的，對于存儲的數據內容它一無所知。關系數據庫所有的智能操作NoSQL全都沒有，你必須用代碼來實 現那些SQL自帶的功能，這對大多數應用程序來說都是不合理的。

即使是建造NoSQL引擎的人也很難描述自己產品的用例，NoSQL的很多評論都在推銷自己的產品，卻并沒有提供任何特別令人信服的理由。很少有 SaaS應用程序用非關系型數據，現實情況是，RDBMS系統要比NoSQL系統多的多，一旦所有的炒作逐漸停止，NoSQL引擎的數量降到合理的范 圍，NoSQL將會成為這些合理應用范圍內的有用工具。在未來，我認為NoSQL能夠成為SQL系統的構件而不是替代品，現在我依然堅持使用SQL。

原文鏈接：    NoSQL is a no go once again——Why I'll be sticking with SQL for now