NoSQL數據庫的爆紅給了很多人信心,有些人認為NoSQL將會在不遠的未來碾壓傳統數據庫一統江湖,但是也有人認為NoSQL只是曇花一現,傳統數據庫仍會穩坐霸主寶座,還有人認為NoSQL與SQL最終必將走向融合......眾說紛紜,究竟NoSQL與SQL是怎樣的一種存在,本文將客觀的對比NoSQL與SQL,希望能夠對大家正確認識SQL和NoSQL有所贊助.

什么是NoSQL?

簡單來說,NoSQL是一個不遵循關系數據庫模型的新的數據存儲后端,這意味著我們所說的“容器”與傳統的基于SQL后端的有區別.

NoSQL技術正在隨著需求的變化不斷發展,而傳統數據庫技術已經基本成熟,近幾年,應用程序對數據庫的要求越發高了,尤其是對大數據、集群和文件存儲庫,新的高要求對傳統數據庫提出了挑戰,同時也為NoSQL的發展提供了機遇.

NoSQL支持：

• 應用程序處理大量數據(大數據)；

• 應用程序快速轉換數據關系和數據類型(半結構化,非結構化和多態數據)；

• 開發人員使用敏捷辦法進行團隊工作：相比瀑布式和迭代式開發,敏捷開發的周期更短；

• 應用程序作為服務,可以在網上發布；

• 應用程序可以交付給成千上萬的用戶,不只是公司內的少數人；

• 應用程序的未來負載無需確定：如果需要擴展,基礎軟件可以再后端集群中輕松完成動態擴展.

市面上有很多NoSQL辦理方案的,有開源的也有不開源的,有些NoSQL是專門未辦理某些問題而設計的,但是無論NoSQL有多少種,它們都有一個共同的特點那就是是提供更好的可擴展性和性能,為了實現這一目標,NoSQL放棄了RDBMS的一些功能,同時引入了一些新的功能.

NoSQL的實現

SQL DB的一個突破性變化是SQL后端是通用存儲系統,而NoSQL專注于特定類型的數據,所以NoSQL數據庫在范圍上更高效,并且允許具有更高性能的系統,NoSQL也可以與SQL結合使用從而獲得更好的性能.

文檔型數據庫

這種類型的數據庫不需要具有一致的數據結構,所以適用于多態數據或數據結構不斷變化的場景,它可以將標準化實體(如鍵值數據集或EAV模型)轉換為簡單文檔集.

• 目標：存儲非類型化數據集

• 示例：MongoDB,CouchDB

• 目的：異構數據,面向工作,敏捷開發

圖數據庫

NoSQL數據庫往往會刪除關系來實現更好的性能,但是圖數據庫卻正好是相反的,它反而是在加強實體之間的關系.

• 目標：描述數據關系

• 示例：Neo4j,GiraffeDB.

• 目的：數據挖掘

鍵值存儲

這是一種設計用于存儲大量鍵值對數據的數據庫.鍵值數據庫適用于那些頻繁讀寫,擁有簡單數據模型的應用.

• 目標：以鍵值形式存儲數據

• 示例：Redis,Cassandra,MemcacheDB

• 目的：鍵值存儲

NOSQL的優點

我們都知道NoSQL數據庫具有傳統RDBMS沒有的優勢,能夠辦理RDBMS不能辦理的問題.如今NoSQL在很多關鍵系統中也有很多應用,如在一些大型云系統和SaaS產品.所以現在的問題是企業是否要遷移?遷移之后是否有利可圖?我們不能只憑供應商的宣傳就做決定,我們需要客觀的來看待NoSQL有哪些有優勢,適用于哪些場景.

NoSQL數據庫是為了彌補傳統關系數據庫技術的限制而創建的,所以這就意味著NoSQL數據庫中會有一些傳統RDBMS沒有的功能或是對RDBMS的相關功能做了改進.

NoSQL操作便捷,以下方面都很擅長：

• 大數據：包括大量數據的數據集.

• 可變數據：數據結構可以是結構化、半結構化和非結構化,NoSQL還可以轉換數據類型.

• 動態開發：在需要敏捷沖刺、快速迭代、頻繁代碼推送以及總結響應變化的上下文中擁有動態性的數據庫是非常有贊助的.

• 面向對象：易于使用和靈活的編程.

• 可擴展：可以輕松實現高效、可擴展的架構,這一點雖然傳統RDBMS也可以做到,但是它們實現起來難度較高.

• 開源：大多數辦理方案都是開源的,所以沒有許可證的費用.

發展進行時

NoSQL數據庫提供更好的性能并更具可擴展性,其數據模型更接近應用程序中使用的域模型.如今基于NoSQL數據庫的初創公司正在飛速發展,大多數的NoSQL數據庫都是開源的,這意味著開發、實施和共享軟件的本錢較低.

NOSQL的局限

在對NoSQL數據庫評估時有一點很值得注意,NoSQL是一個多樣的生態系統,所有不是所有的NoSQL產品都有一樣的缺點,這一特點雖然對我們總結造成了一定的難度,但是對企業來說卻不見得是一件壞事.因為它意味著企業可以對很多不同的NoSQL辦理方案進行利弊權衡,從而選擇一個就符合自己需求的方案.

平安

平安是每個產品都想要達到的,但是理論上沒有絕對的平安,任何一種技術都可能存在平安問題,不只是NoSQL技術,SQL技術也不例外.平安和產品的發展是相輔相成的,平安提升一個檔次,產品自然也就會受追捧.一個年輕的產品可能會有許多未知的平安問題,因為還沒有足夠的時間和經驗對其進行測試,很多平安約束都會被忽略.目前,大多是NoSQL平臺都是年輕的產品,所以我們建議企業在選擇時盡量選擇比較成熟的產品或是業內知名供應商提供的產品.

數據一致性

我們剛開始學習數據庫時,應該就被告知ACID是傳統RDBMS在事務過程中保證數據一致性的最佳選擇,但是大多數NoSQL技術都不支持ACID,它們遵循的是最終一致性原則,簡單來說就是過程松、結果緊,最終結果必須保證一致性.這樣做雖然擁有一定的一致性風險,但是我們獲得了一些性能提升.

JOIN

當我們和NoSQL技術人員交談時,經常會聽到NoSQL因為刪除了關系,性能得到了大幅的提升.我們承認關系可能會帶來性能的下降,但是放棄關系來換取性能一定是值得的嗎?不一定吧,就像你爬上背的行囊一樣,行囊可能會拖慢你的步伐,但是到達山頂后你能夠吃好睡好,在接著走更長的路.

RDBMS使用關系將數據從一個表鏈接到另一個表,以便將數據保留在單個位置,并且不進行數據復制.Join允許將不同表的數據連接起來進行操作,表之間的連接也是需要額外計算的成本.雖然Join可能會帶來一些額外的開銷,但是這種開銷還是在可以接受的范圍內.所以NoSQL聲稱沒有Join功能并不一定是優勢,有時,我們只需要刪除一些不必要的關系或重組數據也可以得到一些性能的提升.

還有一個問題就是一致性,假設我們有一個類別的嵌套樹,許多產品作為樹的葉. 在傳統RDMS中,更改類別樹只需對類別表上的外鍵進行更新,然后這個更改會自動反映在所有子類別和產品上.而在NoSQL中,我們需要對大量的子元素進行更新.

棘手的交易

如果說我們放棄Join來換取速度,這是我們可以接受的,但是在NoSQL實現中難以堅持各種條目一致性就可能會造成嚴重的后果.當你按順序執行交易操作時,中間遇到一些問題,很可能會得到不一致的數據,尤其是第一次實現的NoSQL技術.如果應用程序管理事務時出現錯誤,事務回滾產生的臟數據也是很難處理的.

缺少技術標準

SQL是一種標準語言,即使在大家實現的是不同的數據庫技術,只要不是基于ORM層生成的查詢,大多數的代碼都可以被其他人重新利用,這樣就有助于開發人員快速適應不同的數據庫辦理方案,并且使得遷移更容易.

而NoSQL則恰恰相反,NoSQL每個供應商都有本身特定的語法,沒有任何共享的標準,所以更加混亂.這種混亂也意味著不同的NoSQL之間要實現應用程序的遷移會更加困難,因為很難能找到一個精通多種NoSQL技術的程序員.

模式的靈活性可能會是個麻煩

NoSQL系統的一個特性是它們不需要模式,程序員往往是在保留數據結構的那一刻來決定數據結構,所以數據結構的意義體現的就不是很明顯,所以你可以利用一些自動化工具輕松的創建一個數據庫模型.但是如果發生代碼錯誤,傳統RDBMS是結構化的,你要切換一些字段或錯誤的字段模式,它會有不一致保護,但是NoSQL因為沒有定義任何模式,所以沒有關于數據的信息保留,往往不知道所有的過程和結構,所以出現錯誤時很難避免,更為糟糕的是,它可能會給開發人員帶來更多的責任和工作量.

此外,所有項目都不是一蹴而就的,而是不斷迭代生成的,尤其是有些公司會將部分項目委托給供應商,這時就必須考慮項目結束時要容易切換,所以結構化的數據可能會更容易.另一個問題是團隊成員不可能永遠開發一個項目,團隊成員的工作交換是平常的,但是并不是所有的人都了解數據結構的所有知識.

分析

如果將多個嵌套數據保留在單個文檔中,那么很可能會丟失“SUM”,“COUNT”等分析功能,這也許在應用程序的第一次開發過程中不會是一個大的問題,但是之后可能會需要一些數據來做報告,那么應該怎么辦呢?數據庫在填寫完畢之后,數據結構就很難改變了,如果定義好的數據結構發生泄漏,那么就有可能發生不可預測的結果,所以分析是NoSQL的難點.有些NoSQL的商業工具可能會連接到傳統數據庫的管理分析部分,但這種支持還是有限的.

另外一種解決方法是復制NoSQL數據庫中非結構化數據庫的某種“關系”,也許會需要創建許多集合和連接對象,如果你依照這種路徑進行報告分析的話,那么它的性能可能和SQL差不多,但是如果數據庫中需要分析和計數的部分較少,這種方法還是值得一試.

工具匱乏

NoSQL查詢語言和語法缺乏標準化可能也反映在工具,大多數的NoSQL平臺都是很年輕的,這里所說的查詢工具指的是在數據庫之間進行數據遷移,管理備份等工作的工具.

NoSQL項目還處在發展階段,預計工具也會隨著項目的發展而成長,相信在不久的未來這個問題就會得以辦理.

缺乏標準化也使得第三方供應商難以構建可以支持多種NoSQL辦理方案的工具.此外,年輕的平臺意味著更少的用戶,而用戶數量也會對成熟工具的開發造成一定的影響.

性能比較

性能比較最重要的就是在相同的環境和條件下進行比較,如使用相同的硬件和相同的調諧水平.這里我們選擇的是在同一臺機器上安裝了MongoDB和SQLServer Express,使用基于標準框架的C#代碼構建了基準,通過這種兩種方式來保留數據,為了確保公平,一切都是共享的(實體,邏輯,數據生成).

我們用來作對比的操作包含：插入、查詢、分析和事務.

對單個實體進行批量操作

該測試進行的在相同的對象集合的情況下,哪個數據庫能夠在更短的時間內進行插入,該測試采用的對象集合逐步增大以檢測兩個系統的性能縮放.

搜索

該測試的主要目的是檢測查詢功能,我們將測試分為以下幾個部分：

CASE 1使用主鍵獲取一個實體：此模式是使用唯一標識符從db獲取單個實體.

CASE 2全掃描：假設你在尋找一個已被刪除的元素,數據庫必須掃描完所有索引,然后回復“no”.

CASE 3分頁查詢：通過過濾器和順序條件進行復雜查詢,查詢完畢之后只獲取一頁數據.

我們模擬了各種不同比例的模式的測試,具體情況如下表：

第一次測試我們采用的一個小數據集,包括有250萬行數據.

第二次測試我們采用的是一個較大的數據集,包括有500萬行數據.

從以上我們可以看出NoSQL不及SQL,但是隨著數據量的增加和全掃描比例的減少,NoSQL的性能逐步趨于穩定.

交易

大家都知道大多數NoSQL是不支持事務,很多人也認為放棄交易可能會對性能有所贊助,但是我們可以從中獲益多少呢?

分析

export：所有數據樹上的Join

report：匯總所有類別中的所有項目

KPI：匯總所有總和

我們采用的是數據集有400萬行數據

興趣點

每一次新技術的興起必將帶來一些革命性的功能,但是首先要打破開發者先入為主的觀點,所以有時候問題的爆發反而是成長的契機.

真正的創新要避免本身成為以下兩種人：

“激進派”：無條件擁抱變革,隨時準備和過去的技術做切割.

“保守派”：痛恨改變,拒絕任何新技術.

在實際的生活中,我們要對新技術堅持一個中立清醒的態度,要了解什么樣的新技術是可以為我們所用的,在使用新技術之前要對項目進行評估,如果我們對工作一直秉持著批判的態度,那么可能就會有不好的結果.

NoSQL技術也是同樣的道理,如果十分了解NoSQL的優劣勢,那么我們就可以揚長避短,學習、理解和應用才是進步之法.

NoSQL數據庫的應用場景

上文闡述了這么多,相信大家都會明白NoSQL的出現不是為了替代SQL,而是彌補SQL的不足,不同的存儲系統有不同的功能,并且在某些特定領域會有本身特殊的功能,數據庫的性能好壞大部分取決于項目的特點.

一般企業在有以下需求的時候NoSQL會成為最佳辦理方案：

• 當你的項目在未來可能會需要擴展.

• 當你的項目需要處理大量數據,或者是在不遠的未來需要處理大量數據.

• 當分析組件在應用程序中的重要性不是很高.

• 當你的應用程序需要NoSQL數據庫相關功能,而RDBMS無法滿足時.

在有些情況下,NoSQL可以是一個很好的替代方案,如果你的需求有99%符合NoSQL辦理方案,那么肯定非NoSQL莫屬,但如果你的需求需要事務、關系或者是其他的標準RDBMS特性,那么你就可以讓NoSQL和RDBMS結合使用.

NoSQL的性能有多好?

NoSQL的性能評估要取決于具體的用例,如果我們的使用場景是數據量大,那么NoSQL性能提升很明顯,但如果是在小數據集上,并且包含很多查詢功能,那么NoSQL的性能可能會有所下降.NoSQL可以很好的在數據庫層加速,但是最終用戶體驗還是有很多因素控制的,如緩存、網絡延遲等.假設一個頁面使用傳統數據庫需要500ms,使用NoSQL需要50ms,頁面渲染需要200ms,網絡數據傳輸需要1s,所以我們看到它在數據庫層性能提升了90%,但對最終用戶來說,性能提升只有26%.從這個例子中我們可以看出系統的改進是很復雜的,有些情況下NoSQL是不足以辦理性能問題的.

NoSQL系統是否已經成熟應用于生產環境?

如果是從企業需求或者是項目需求的角度來看,我們可以說NoSQL已經成熟了,您可以大膽的使用.但是其實現實中并不是所有的企業都有NoSQL的需求,因為不是所有的項目都需要處理大數據或是需要大規模擴展,即使是大多數的SaaS產品也都是很簡單的.據我所知,現在的數據庫中很難找到超過10萬行的表,所以在這種情況下,傳統RDBMS是完全足夠應對的.

SQL是否過時?

當我們發明了飛機,那么汽車就過時了嗎?當然不是,雖然飛機的速度比汽車快,但它們都是主流的交通工具,擁有不同的應用場景.NoSQL和SQL也是一樣,它們只是用兩種不同的方式來存儲數據,具有不同的特性,需要用戶根據實際情況來決定用哪一個.

SQL不適合大數據項目,就像你要去一個島需要乘坐飛機,而不是開車,而SQL也有本身的優勢,就像去超市買牛奶開車就行,不需開飛機.NoSQL不是要取代SQL,它們之間更像是一種互補的關系.

NoSQL市場準備好了嗎?

要回答這個問題的關鍵是開發人員的經驗,大多數的數據庫程序員都已經習慣了關系型數據庫,甚至有的已經在關系型數據庫領域工作或培訓了較長時間,所以如安在較短的時間內轉變思維方式是一個問題.

很多DBA已經在RDBMS掌握了辦法技巧,不愿意放棄,重新來學習NoSQL.所以NoSQL的繁榮更多的要把希望寄托在新一代DBA身上.另外,NoSQL工具的短缺也是一個問題,但是隨著NoSQL項目的增長,工具不會成為一個永久性的問題.

什么是最佳方案?

這個問題其實很難也很簡單,適合本身的就是最佳方案,無需糾結于SQL還是NoSQL..