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。

　　via：http://www.itworld.com/big-data/428717/nosql-no-go-once-again