資料庫專家分析：NoSQL 仍未能取代 RDBMS

即使我們已經清楚自己的需求，仍然需要通過深入的研究和學習來掌握NoSQL。大家可能無法對這麼多解決方案進行一一評估。畢竟其數量實在太過龐大。更糟糕的是，我們還被迫閱讀大量說明文件，從而瞭解要如何借助NoSQL來達到自己的預期效果，筆者認為使用者高度關注的是有關聯式資料或者是ACID。相比之下，關聯式SQL資料庫就擁有非常突出的優勢，它能夠在任何產品當中發揮同樣的作用。

NoSQL的最大吸引力源自其向外擴展的方便性與資料的接收能力。儘管能夠擁有可以與RDBMS互相媲美的擴展性，但現實告訴我們、99%的應用程式在執行流程中根本不會對擴展性提出任何要求。大家可以看看Stack Exchange,他們是世界上現存最繁忙網站，並且利用商用伺服器運行資料庫。為了承載這樣的Workload，該網站直接購買了一台擁有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路線。