NoSQL再度面臨失敗危機
譯文【51CTO獨家特稿】在那篇文章收到的評論當中,很多讀者朋友都糾結于對NoSQL的評估難題身上——相關利基解決方案數(shù)以百萬計,因此實際效果如何“取決于用戶的實際需求。”即使我們已經(jīng)明確了自己的需求,仍然需要通過深入的研究與學習來掌握特定NoSQL引擎是否有能力滿足這類需求。大家可能無法對這么多解決方案進行一一評估,畢竟其數(shù)量實在太過龐大。更糟糕的是,我們還被迫閱讀大量特定引擎的說明文檔,從而了解自己要如何借助NoSQL達到自己的預期效果——而其中大部分內(nèi)容似乎是在高度關注用戶是否擁有關系型數(shù)據(jù)或者是否喜愛ACID事務處理方式。
相比之下,關系型SQL數(shù)據(jù)庫就擁有非常突出的優(yōu)勢,大家很清楚該引擎能夠在任何產(chǎn)品當中發(fā)揮同樣的作用。我們需要面對的選擇數(shù)量也更少,而且這類選項往往更成熟也經(jīng)過了時間的檢驗。也就是說,大家作出糟糕判斷的可能性要遠遠低于RDBMS。
NoSQL的***吸引力源自其向外擴展的便捷性與強大的數(shù)據(jù)吞吐能力。盡管能夠擁有可以與RDBMS相媲美的可擴展性確實令人心動,但現(xiàn)實告訴我們、99%的應用程序在執(zhí)行流程中根本不會對擴展性提出任何要求。大家可以看看Stack Exchange,他們是世界上現(xiàn)存的最繁忙的站點,并且利用商用服務器運行數(shù)據(jù)庫系統(tǒng)。為了承載這樣的工作負載,該網(wǎng)站直接購買了一臺擁有60核心服務器并配備6TB的內(nèi)存容量,事實上我們很難想象這樣的設備還需要什么后續(xù)擴展。因此,請大家認真考慮這樣一個問題:我們是否真能從NoSQL的可擴展能力身上獲得實際收益?
NoSQL無存儲模式成弊端?
起初筆者認為NoSQL文檔存儲的無模式特性會成為一大優(yōu)勢,然而筆者在隨后的調(diào)查當中逐漸改變了自己的觀點。至少就關系Web應用程序而言,無模式機制只會造成代碼復雜程度的提升、并沒有任何其它貢獻。更進一步,筆者喜歡結構、特別是清晰的數(shù)據(jù)結構。誠然,如果大家打算構建一套特殊類型的數(shù)據(jù)庫,用于處理數(shù)據(jù)歸檔、文件存儲或者事件日志之類任務,那么無模式機制確實有其獨特優(yōu)勢。但對于無此需求的Web應用程序來說,NoSQL則顯得無甚意義——畢竟這不是社交網(wǎng)絡。
與關系型數(shù)據(jù)庫相比,采用文檔存儲機制會讓大家的軟件在各個層面上迎來更突出的復雜性難題。我們可以將NoSQL視為一套單純的文件存儲系統(tǒng),其中文件名代表鍵、而文件內(nèi)容則代表值。大家可以在這些文件當中保存任何內(nèi)容,并快速對其進行讀取與寫入,然而存儲背后并不存在任何處理能力。(當然,在這里筆者要歸納一下,NoSQL引擎在對這些文件進行管理與優(yōu)化方面表現(xiàn)優(yōu)異,但卻對數(shù)據(jù)內(nèi)容本身一無所知。)關系型數(shù)據(jù)庫當中的內(nèi)容認知特性全部消失,這迫使大家只能自行完成SQL代碼能夠自動處理的各項事務……而且是針對每一款應用程序。這樣的日常成本對于大多數(shù)應用程序而言都是不必要也是不可接受的。
即使是那些有能力創(chuàng)建NoSQL引擎的卓越技術人才自己也很難對自己的產(chǎn)品進行用例描述。通過相關評論可以看到,不少開發(fā)者都在努力宣傳自己的產(chǎn)品、但卻無法給出讓用戶選擇NoSQL的真正有說服力的理由。SaaS應用程序其實基本不可能徹底擺脫與關系數(shù)據(jù)的交集。在這種情況下,大家從RDBMS系統(tǒng)當中獲得的功能特性要遠遠勝過NoSQL系統(tǒng)。筆者認為NoSQL引擎現(xiàn)在需要高度關注那些過去被嚴重忽略的層面與問題。盡管目前充斥著大量NoSQL能夠為關系型應用程序帶來突出性能表現(xiàn)的宣傳,但實際效果恐怕還要讓各位用戶親身驗證。能夠切實從NoSQL身上受益的應用程序在數(shù)量上明顯少于能夠從SQL身上受益的應用。一旦宣傳炒作風頭漸消、NoSQL引擎的數(shù)量也降低到合理的水平,筆者認為到那時NoSQL才會真正在特定場景中成為一款優(yōu)秀的工具。筆者還認為,NoSQL未來更可能成為SQL系統(tǒng)的一種有效補充而非替代方案。就目前而言,筆者將繼續(xù)堅持自己的SQL路線不動搖。
原文鏈接:
http://www.itworld.com/big-data/428717/nosql-no-go-once-again?source=ITWNLE_nlt_tonight_2014-07-25
原文標題:NoSQL is a No Go Once Again