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。