資料庫專家分析：NoSQL 仍未能取代 RDBMS
即使我們已經清楚自己的需求，仍然需要通過深入的研究和學習來掌握NoSQL是否有滿足的能力。大家可能無法對這麼多解決方案進行一一評估。畢竟其數量實在太過龐大。更糟糕的是，我們還被迫閱讀大量說明文件，從而瞭解自己的行動要如何借助NoSQL來達到自己的預期效果，筆者認為使用者高度關注的是有關聯式資料或者是否喜愛ACID。相比之下，關聯式SQL資料庫就擁有非常突出的優勢，它能夠在任何產品當中發揮同樣的作用。我們選擇的數量將會更少，而且這類形的選項往往更成熟也能經過了時間的檢驗。也就是說，大家作出較差判斷的可能性要遠遠低於RDBMS。
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路線。
以上資訊由www.hkitblog.com提供
