本質(zhì)是因?yàn)椋弘S著互聯(lián)網(wǎng)的進(jìn)一步發(fā)展與各行業(yè)信息化建設(shè)進(jìn)程加快、參與者的增多,人們對(duì)軟件有了更多更新的要求,需要軟件不僅能實(shí)現(xiàn)功能,而且要求保證許多人可以共同參與使用,因而軟件所需承載的數(shù)據(jù)量和吞吐量必須達(dá)到相應(yīng)的需求。而目前的關(guān)系型數(shù)據(jù)庫(kù)在某些方面有一些缺點(diǎn),導(dǎo)致不能滿足需要。

公司主營(yíng)業(yè)務(wù):成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作、外貿(mào)網(wǎng)站建設(shè)、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳,提高企業(yè)的競(jìng)爭(zhēng)能力。創(chuàng)新互聯(lián)公司是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化,感謝他們對(duì)我們的高要求,感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn),讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)公司推出渾源免費(fèi)做網(wǎng)站回饋大家。
具體則需要對(duì)比關(guān)系型數(shù)據(jù)庫(kù)與Nosql之間的區(qū)別可以得出
關(guān)系型數(shù)據(jù)庫(kù)
關(guān)系型數(shù)據(jù)庫(kù)把所有的數(shù)據(jù)都通過行和列的二元表現(xiàn)形式表示出來。
關(guān)系型數(shù)據(jù)庫(kù)的優(yōu)勢(shì):
1.?保持?jǐn)?shù)據(jù)的一致性(事務(wù)處理)
2.由于以標(biāo)準(zhǔn)化為前提,數(shù)據(jù)更新的開銷很小(相同的字段基本上都只有一處)
3.?可以進(jìn)行Join等復(fù)雜查詢
其中能夠保持?jǐn)?shù)據(jù)的一致性是關(guān)系型數(shù)據(jù)庫(kù)的最大優(yōu)勢(shì)。
關(guān)系型數(shù)據(jù)庫(kù)的不足:
不擅長(zhǎng)的處理
1.?大量數(shù)據(jù)的寫入處理(這點(diǎn)尤為重要)
2.?為有數(shù)據(jù)更新的表做索引或表結(jié)構(gòu)(schema)變更
3.?字段不固定時(shí)應(yīng)用
4.?對(duì)簡(jiǎn)單查詢需要快速返回結(jié)果的處理
--大量數(shù)據(jù)的寫入處理
讀寫集中在一個(gè)數(shù)據(jù)庫(kù)上讓數(shù)據(jù)庫(kù)不堪重負(fù),大部分網(wǎng)站已使用主從復(fù)制技術(shù)實(shí)現(xiàn)讀寫分離,以提高讀寫性能和讀庫(kù)的可擴(kuò)展性。
所以在進(jìn)行大量數(shù)據(jù)操作時(shí),會(huì)使用數(shù)據(jù)庫(kù)主從模式。數(shù)據(jù)的寫入由主數(shù)據(jù)庫(kù)負(fù)責(zé),數(shù)據(jù)的讀入由從數(shù)據(jù)庫(kù)負(fù)責(zé),可以比較簡(jiǎn)單地通過增加從數(shù)據(jù)庫(kù)來實(shí)現(xiàn)規(guī)模化,但是數(shù)據(jù)的寫入?yún)s完全沒有簡(jiǎn)單的方法來解決規(guī)模化問題。
第一,要想將數(shù)據(jù)的寫入規(guī)模化,可以考慮把主數(shù)據(jù)庫(kù)從一臺(tái)增加到兩臺(tái),作為互相關(guān)聯(lián)復(fù)制的二元主數(shù)據(jù)庫(kù)使用,確實(shí)這樣可以把每臺(tái)主數(shù)據(jù)庫(kù)的負(fù)荷減少一半,但是更新處理會(huì)發(fā)生沖突,可能會(huì)造成數(shù)據(jù)的不一致,為了避免這樣的問題,需要把對(duì)每個(gè)表的請(qǐng)求分別分配給合適的主數(shù)據(jù)庫(kù)來處理。
第二,可以考慮把數(shù)據(jù)庫(kù)分割開來,分別放在不同的數(shù)據(jù)庫(kù)服務(wù)器上,比如將不同的表放在不同的數(shù)據(jù)庫(kù)服務(wù)器上,數(shù)據(jù)庫(kù)分割可以減少每臺(tái)數(shù)據(jù)庫(kù)服務(wù)器上的數(shù)據(jù)量,以便減少硬盤IO的輸入、輸出處理,實(shí)現(xiàn)內(nèi)存上的高速處理。但是由于分別存儲(chǔ)字不同服務(wù)器上的表之間無法進(jìn)行Join處理,數(shù)據(jù)庫(kù)分割的時(shí)候就需要預(yù)先考慮這些問題,數(shù)據(jù)庫(kù)分割之后,如果一定要進(jìn)行Join處理,就必須要在程序中進(jìn)行關(guān)聯(lián),這是非常困難的。
--為有數(shù)據(jù)更新的表做索引或表結(jié)構(gòu)變更
在使用關(guān)系型數(shù)據(jù)庫(kù)時(shí),為了加快查詢速度需要?jiǎng)?chuàng)建索引,為了增加必要的字段就一定要改變表結(jié)構(gòu),為了進(jìn)行這些處理,需要對(duì)表進(jìn)行共享鎖定,這期間數(shù)據(jù)變更、更新、插入、刪除等都是無法進(jìn)行的。如果需要進(jìn)行一些耗時(shí)操作,例如為數(shù)據(jù)量比較大的表創(chuàng)建索引或是變更其表結(jié)構(gòu),就需要特別注意,長(zhǎng)時(shí)間內(nèi)數(shù)據(jù)可能無法進(jìn)行更新。
--字段不固定時(shí)的應(yīng)用
如果字段不固定,利用關(guān)系型數(shù)據(jù)庫(kù)也是比較困難的,有人會(huì)說,需要的時(shí)候加個(gè)字段就可以了,這樣的方法也不是不可以,但在實(shí)際運(yùn)用中每次都進(jìn)行反復(fù)的表結(jié)構(gòu)變更是非常痛苦的。你也可以預(yù)先設(shè)定大量的預(yù)備字段,但這樣的話,時(shí)間一長(zhǎng)很容易弄不清除字段和數(shù)據(jù)的對(duì)應(yīng)狀態(tài),即哪個(gè)字段保存有哪些數(shù)據(jù)。
--對(duì)簡(jiǎn)單查詢需要快速返回結(jié)果的處理? (這里的“簡(jiǎn)單”指的是沒有復(fù)雜的查詢條件)
這一點(diǎn)稱不上是缺點(diǎn),但不管怎樣,關(guān)系型數(shù)據(jù)庫(kù)并不擅長(zhǎng)對(duì)簡(jiǎn)單的查詢快速返回結(jié)果,因?yàn)殛P(guān)系型數(shù)據(jù)庫(kù)是使用專門的sql語言進(jìn)行數(shù)據(jù)讀取的,它需要對(duì)sql與越南進(jìn)行解析,同時(shí)還有對(duì)表的鎖定和解鎖等這樣的額外開銷,這里并不是說關(guān)系型數(shù)據(jù)庫(kù)的速度太慢,而只是想告訴大家若希望對(duì)簡(jiǎn)單查詢進(jìn)行高速處理,則沒有必要非使用關(guān)系型數(shù)據(jù)庫(kù)不可。
NoSQL數(shù)據(jù)庫(kù)
關(guān)系型數(shù)據(jù)庫(kù)應(yīng)用廣泛,能進(jìn)行事務(wù)處理和表連接等復(fù)雜查詢。相對(duì)地,NoSQL數(shù)據(jù)庫(kù)只應(yīng)用在特定領(lǐng)域,基本上不進(jìn)行復(fù)雜的處理,但它恰恰彌補(bǔ)了之前所列舉的關(guān)系型數(shù)據(jù)庫(kù)的不足之處。
優(yōu)點(diǎn):
易于數(shù)據(jù)的分散
各個(gè)數(shù)據(jù)之間存在關(guān)聯(lián)是關(guān)系型數(shù)據(jù)庫(kù)得名的主要原因,為了進(jìn)行join處理,關(guān)系型數(shù)據(jù)庫(kù)不得不把數(shù)據(jù)存儲(chǔ)在同一個(gè)服務(wù)器內(nèi),這不利于數(shù)據(jù)的分散,這也是關(guān)系型數(shù)據(jù)庫(kù)并不擅長(zhǎng)大數(shù)據(jù)量的寫入處理的原因。相反NoSQL數(shù)據(jù)庫(kù)原本就不支持Join處理,各個(gè)數(shù)據(jù)都是獨(dú)立設(shè)計(jì)的,很容易把數(shù)據(jù)分散在多個(gè)服務(wù)器上,故減少了每個(gè)服務(wù)器上的數(shù)據(jù)量,即使要處理大量數(shù)據(jù)的寫入,也變得更加容易,數(shù)據(jù)的讀入操作當(dāng)然也同樣容易。
典型的NoSQL數(shù)據(jù)庫(kù)
臨時(shí)性鍵值存儲(chǔ)(memcached、Redis)、永久性鍵值存儲(chǔ)(ROMA、Redis)、面向文檔的數(shù)據(jù)庫(kù)(MongoDB、CouchDB)、面向列的數(shù)據(jù)庫(kù)(Cassandra、HBase)
一、 鍵值存儲(chǔ)
它的數(shù)據(jù)是以鍵值的形式存儲(chǔ)的,雖然它的速度非常快,但基本上只能通過鍵的完全一致查詢獲取數(shù)據(jù),根據(jù)數(shù)據(jù)的保存方式可以分為臨時(shí)性、永久性和兩者兼具 三種。
(1)臨時(shí)性
所謂臨時(shí)性就是數(shù)據(jù)有可能丟失,memcached把所有數(shù)據(jù)都保存在內(nèi)存中,這樣保存和讀取的速度非常快,但是當(dāng)memcached停止時(shí),數(shù)據(jù)就不存在了。由于數(shù)據(jù)保存在內(nèi)存中,所以無法操作超出內(nèi)存容量的數(shù)據(jù),舊數(shù)據(jù)會(huì)丟失。總結(jié)來說:
。在內(nèi)存中保存數(shù)據(jù)
。可以進(jìn)行非常快速的保存和讀取處理
。數(shù)據(jù)有可能丟失
(2)永久性
所謂永久性就是數(shù)據(jù)不會(huì)丟失,這里的鍵值存儲(chǔ)是把數(shù)據(jù)保存在硬盤上,與臨時(shí)性比起來,由于必然要發(fā)生對(duì)硬盤的IO操作,所以性能上還是有差距的,但數(shù)據(jù)不會(huì)丟失是它最大的優(yōu)勢(shì)。總結(jié)來說:
。在硬盤上保存數(shù)據(jù)
。可以進(jìn)行非常快速的保存和讀取處理(但無法與memcached相比)
。數(shù)據(jù)不會(huì)丟失
(3) 兩者兼?zhèn)?/p>
Redis屬于這種類型。Redis有些特殊,臨時(shí)性和永久性兼具。Redis首先把數(shù)據(jù)保存在內(nèi)存中,在滿足特定條件(默認(rèn)是?15分鐘一次以上,5分鐘內(nèi)10個(gè)以上,1分鐘內(nèi)10000個(gè)以上的鍵發(fā)生變更)的時(shí)候?qū)?shù)據(jù)寫入到硬盤中,這樣既確保了內(nèi)存中數(shù)據(jù)的處理速度,又可以通過寫入硬盤來保證數(shù)據(jù)的永久性,這種類型的數(shù)據(jù)庫(kù)特別適合處理數(shù)組類型的數(shù)據(jù)。總結(jié)來說:
。同時(shí)在內(nèi)存和硬盤上保存數(shù)據(jù)
。可以進(jìn)行非常快速的保存和讀取處理
。保存在硬盤上的數(shù)據(jù)不會(huì)消失(可以恢復(fù))
。適合于處理數(shù)組類型的數(shù)據(jù)
二、面向文檔的數(shù)據(jù)庫(kù)
MongoDB、CouchDB屬于這種類型,它們屬于NoSQL數(shù)據(jù)庫(kù),但與鍵值存儲(chǔ)相異。
(1)不定義表結(jié)構(gòu)
即使不定義表結(jié)構(gòu),也可以像定義了表結(jié)構(gòu)一樣使用,還省去了變更表結(jié)構(gòu)的麻煩。
(2)可以使用復(fù)雜的查詢條件
跟鍵值存儲(chǔ)不同的是,面向文檔的數(shù)據(jù)庫(kù)可以通過復(fù)雜的查詢條件來獲取數(shù)據(jù),雖然不具備事務(wù)處理和Join這些關(guān)系型數(shù)據(jù)庫(kù)所具有的處理能力,但初次以外的其他處理基本上都能實(shí)現(xiàn)。
三、?面向列的數(shù)據(jù)庫(kù)
Cassandra、HBae、HyperTable屬于這種類型,由于近年來數(shù)據(jù)量出現(xiàn)爆發(fā)性增長(zhǎng),這種類型的NoSQL數(shù)據(jù)庫(kù)尤其引入注目。
普通的關(guān)系型數(shù)據(jù)庫(kù)都是以行為單位來存儲(chǔ)數(shù)據(jù)的,擅長(zhǎng)以行為單位的讀入處理,比如特定條件數(shù)據(jù)的獲取。因此,關(guān)系型數(shù)據(jù)庫(kù)也被成為面向行的數(shù)據(jù)庫(kù)。相反,面向列的數(shù)據(jù)庫(kù)是以列為單位來存儲(chǔ)數(shù)據(jù)的,擅長(zhǎng)以列為單位讀入數(shù)據(jù)。
面向列的數(shù)據(jù)庫(kù)具有搞擴(kuò)展性,即使數(shù)據(jù)增加也不會(huì)降低相應(yīng)的處理速度(特別是寫入速度),所以它主要應(yīng)用于需要處理大量數(shù)據(jù)的情況。另外,把它作為批處理程序的存儲(chǔ)器來對(duì)大量數(shù)據(jù)進(jìn)行更新也是非常有用的。但由于面向列的數(shù)據(jù)庫(kù)跟現(xiàn)行數(shù)據(jù)庫(kù)存儲(chǔ)的思維方式有很大不同,故應(yīng)用起來十分困難。
總結(jié):關(guān)系型數(shù)據(jù)庫(kù)與NoSQL數(shù)據(jù)庫(kù)并非對(duì)立而是互補(bǔ)的關(guān)系,即通常情況下使用關(guān)系型數(shù)據(jù)庫(kù),在適合使用NoSQL的時(shí)候使用NoSQL數(shù)據(jù)庫(kù),讓NoSQL數(shù)據(jù)庫(kù)對(duì)關(guān)系型數(shù)據(jù)庫(kù)的不足進(jìn)行彌補(bǔ)。
NoSQL 數(shù)據(jù)庫(kù)因其功能性、易于開發(fā)性和可擴(kuò)展性而廣受認(rèn)可,它們?cè)絹碓蕉嗟赜糜诖髷?shù)據(jù)和實(shí)時(shí) Web 應(yīng)用程序,在本文中,我們通過示例討論 NoSQL、何時(shí)使用 NoSQL 與 SQL 及其用例。
NoSQL是一種下一代數(shù)據(jù)庫(kù)管理系統(tǒng) (DBMS)。NoSQL 數(shù)據(jù)庫(kù)具有靈活的模式,可用于構(gòu)建具有大量數(shù)據(jù)和高負(fù)載的現(xiàn)代應(yīng)用程序。
“NoSQL”一詞最初是由 Carlo Strozzi 在 1998 年創(chuàng)造的,盡管自 1960 年代后期以來就已經(jīng)存在類似的數(shù)據(jù)庫(kù)。然而,NoSQL 的發(fā)展始于 2009 年初,并且發(fā)展迅速。
在處理大量數(shù)據(jù)時(shí),任何關(guān)系數(shù)據(jù)庫(kù)管理系統(tǒng) (RDBMS) 的響應(yīng)時(shí)間都會(huì)變慢。為了解決這個(gè)問題,我們可以通過升級(jí)現(xiàn)有硬件來“擴(kuò)大”信息系統(tǒng),這非常昂貴。但是,NoSQL 可以更好地橫向擴(kuò)展并且更具成本效益。
NoSQL 對(duì)于非結(jié)構(gòu)化或非常大的數(shù)據(jù)對(duì)象(例如聊天日志數(shù)據(jù)、視頻或圖像)非常有用,這就是為什么 NoSQL 在微軟、谷歌、亞馬遜、Meta (Facebook) 等互聯(lián)網(wǎng)巨頭中特別受歡迎的原因。
一些流行的 NoSQL 數(shù)據(jù)庫(kù)包括:
隨著企業(yè)更快地積累更大的數(shù)據(jù)集,結(jié)構(gòu)化數(shù)據(jù)和關(guān)系模式并不總是適合。有必要使用非結(jié)構(gòu)化數(shù)據(jù)和大型對(duì)象來更好地捕獲這些信息。
傳統(tǒng)的 RDBMS 使用 SQL(結(jié)構(gòu)化查詢語言)語法來存儲(chǔ)和檢索結(jié)構(gòu)化數(shù)據(jù),相反,NoSQL 數(shù)據(jù)庫(kù)包含廣泛的功能,可以存儲(chǔ)和檢索結(jié)構(gòu)化、半結(jié)構(gòu)化、非結(jié)構(gòu)化和多態(tài)數(shù)據(jù)。
有時(shí),NoSQL 也被稱為“ 不僅僅是 SQL ”,強(qiáng)調(diào)它可能支持類似 SQL 的語言或與 SQL 數(shù)據(jù)庫(kù)并列。SQL 和 NoSQL DBMS 之間的一個(gè)區(qū)別是 JOIN 功能。SQL 數(shù)據(jù)庫(kù)使用 JOIN 子句來組合來自兩個(gè)或多個(gè)表的行,因?yàn)?NoSQL 數(shù)據(jù)庫(kù)本質(zhì)上不是表格的,所以這個(gè)功能并不總是可行或相關(guān)的。
但是,一些 NoSQL DBMS 可以執(zhí)行類似于 JOIN的操作——就像 MongoDB 一樣。這并不意味著不再需要 SQL DBMS,相反,NoSQL 和 SQL 數(shù)據(jù)庫(kù)傾向于以不同的方式解決類似的問題。
一般來說,在以下情況下,NoSQL 比 SQL 更可取:
許多行業(yè)都在采用 NoSQL,取代關(guān)系數(shù)據(jù)庫(kù),從而為某些業(yè)務(wù)應(yīng)用程序提供更高的靈活性和可擴(kuò)展性,下面給出了 NoSQL 數(shù)據(jù)庫(kù)的一些企業(yè)用例。
內(nèi)容管理是一組用于收集、管理、傳遞、檢索和發(fā)布任何格式的信息的過程,包括文本、圖像、音頻和視頻。NoSQL 數(shù)據(jù)庫(kù)可以通過其靈活和開放的數(shù)據(jù)模型為存儲(chǔ)多媒體內(nèi)容提供更好的選擇。
例如,福布斯在短短幾個(gè)月內(nèi)就構(gòu)建了一個(gè)基于 MongoDB 的定制內(nèi)容管理系統(tǒng),以更低的成本為他們提供了更大的敏捷性。
大數(shù)據(jù)是指太大而無法通過傳統(tǒng)處理系統(tǒng)處理的數(shù)據(jù)集,實(shí)時(shí)存儲(chǔ)和檢索大數(shù)據(jù)的系統(tǒng)在分析 歷史 數(shù)據(jù)的同時(shí)使用流處理來攝取新數(shù)據(jù),這是一系列非常適合 NoSQL 數(shù)據(jù)庫(kù)的功能。
Zoom使用 DynamoDB(按需模式)使其數(shù)據(jù)能夠在沒有性能問題的情況下進(jìn)行擴(kuò)展,即使該服務(wù)在 COVID-19 大流行的早期使用量激增。
物聯(lián)網(wǎng)設(shè)備具有連接到互聯(lián)網(wǎng)或通信網(wǎng)絡(luò)的嵌入式軟件和傳感器,能夠在無需人工干預(yù)的情況下收集和共享數(shù)據(jù)。隨著數(shù)十億臺(tái)設(shè)備生成數(shù)不清的數(shù)據(jù),IoT NoSQL 數(shù)據(jù)庫(kù)為 IoT 服務(wù)提供商提供了可擴(kuò)展性和更靈活的架構(gòu)。
Freshub就是這樣的一項(xiàng)服務(wù),它從 MySQL 切換到 MongoDB,以更好地處理其大型、動(dòng)態(tài)、非統(tǒng)一的數(shù)據(jù)集。
擁有數(shù)十億智能手機(jī)用戶,可擴(kuò)展性正成為在移動(dòng)設(shè)備上提供服務(wù)的企業(yè)面臨的最大挑戰(zhàn)。具有更靈活數(shù)據(jù)模型的 NoSQL DBMS 通常是完美的解決方案。
例如,The Weather Channel使用 MongoDB 數(shù)據(jù)庫(kù)每分鐘處理數(shù)百萬個(gè)請(qǐng)求,同時(shí)還處理用戶數(shù)據(jù)并提供天氣更新。
建議先在查詢(Query)中把幾個(gè)表鏈起來,然后再在里面改,這樣可以減少出錯(cuò)的機(jī)會(huì)。
下面這個(gè)是我開發(fā)的一個(gè),用的JOIN不一樣,但是語法是相同的,你參考一下。
SELECT qry_LineCode.fKMInvNo, qry_LineCode.fDebitNo, tInvoice.fYM, tInvoice.fConsignee, "" AS fSupplier,
tInvoice.fVia, tInvoice.fVINO, tInvoice.fInvoiceNo, Mid(tInvoice.fVanningDate,6,2) AS fShtMth,
qry_LineCode.fLinecode, Left([fLineCode],1) AS fItemType, Left([fLineCode],2) AS fItemType1,
qry_LineCode.fItem, Right([fLineCode],2) AS fItemType3, qry_LineCode.fFeeName, qry_LineCode.fAmount,
BD_CC.fFactory, BD_CC.fRoute, BD_CC.fNature, BD_ShgCny.fShgType, [BD_Class.fItem]+[BD_Class.fTransportType] AS fItem_Trans,
BD_CC.fFreight, BD_Info_CBM_AMT.fReferCBMInfo, BD_Info_CBM.fReferAmtInfo, tInvoice.f40HQ, tInvoice.f45FT, tInvoice.f40FT,
tInvoice.f20FT, tInvoice.f24T, tInvoice.f12T, tInvoice.f10T, tInvoice.f8T, tInvoice.f5T, tInvoice.f3T, tInvoice.f15HT, "" AS fConsl,
tInvoice.fPackage, tInvoice.fGrossWeight, tInvoice.fVolume, [fShtMth]+1 AS fPayMonth, tInvoice.fShgCny, "" AS fShgCny2,
qry_LineCode.fCC, qry_LineCode.fSheetName
FROM (((((qry_LineCode LEFT JOIN BD_Info_CBM_AMT ON qry_LineCode.fItem = BD_Info_CBM_AMT.fItem)
LEFT JOIN tInvoice ON (qry_LineCode.fYM = tInvoice.fYM) AND (qry_LineCode.fDebitNo = tInvoice.fDebitNo))
LEFT JOIN BD_ShgCny ON qry_LineCode.fItem = BD_ShgCny.fItem)
LEFT JOIN BD_CC ON qry_LineCode.fItem = BD_CC.fItem)
LEFT JOIN BD_Class ON qry_LineCode.fItem = BD_Class.fItem)
LEFT JOIN BD_Info_CBM ON BD_Info_CBM_AMT.fReferCBMInfo = BD_Info_CBM.fReferCBMInfo
WHERE (((qry_LineCode.fDebitNo)""));
不支持,redis是key-value形式的數(shù)據(jù)庫(kù),是非關(guān)系型數(shù)據(jù)庫(kù)。join操作大部分都是在關(guān)系型數(shù)據(jù)庫(kù)中。
即非關(guān)系型數(shù)據(jù)庫(kù)和關(guān)系型數(shù)據(jù)庫(kù)。
MySQL的優(yōu)點(diǎn):事務(wù)處理—保持?jǐn)?shù)據(jù)的一致性;由于以標(biāo)準(zhǔn)化為前提,數(shù)據(jù)更新的開銷很小(相同的字段基本上只有一處);可以進(jìn)行Join等復(fù)雜查詢
NoSQL的優(yōu)點(diǎn):首先它是基于內(nèi)存的,也就是數(shù)據(jù)放在內(nèi)存中,而不是像數(shù)據(jù)庫(kù)那樣把數(shù)據(jù)放在磁盤上,而內(nèi)存的讀取速度是磁盤讀取速度的幾十倍到上百倍,所以NoSQL工具的速度遠(yuǎn)比數(shù)據(jù)庫(kù)讀取速度要快得多,滿足了高響應(yīng)的要求。即使NoSQL將數(shù)據(jù)放在磁盤中,它也是一種半結(jié)構(gòu)化的數(shù)據(jù) 格式,讀取到解析的復(fù)雜度遠(yuǎn)比MySQL要簡(jiǎn)單,這是因?yàn)镸ySQL存儲(chǔ)的是經(jīng)過結(jié)構(gòu)化、多范式等有復(fù)雜規(guī)則的數(shù)據(jù),還原為內(nèi)存結(jié)構(gòu)的速度較慢。NoSQL在很大程度上滿足了高并發(fā)、快速讀/和響應(yīng)的要求,所以它也是Java互聯(lián)網(wǎng)系統(tǒng)的利器。
簡(jiǎn)單的擴(kuò)展:典型例子是Cassandra,由于其架構(gòu)是類似于經(jīng)典的P2P,所以能通過輕松地添加新的節(jié)點(diǎn)來擴(kuò)展這個(gè)集群;
低廉的成本:這是大多數(shù)分布式數(shù)據(jù)庫(kù)共有的特點(diǎn),因?yàn)橹饕际情_源軟件,沒有昂貴的License成本;
NoSQL的缺點(diǎn):大多數(shù)NoSQL數(shù)據(jù)庫(kù)都不支持事務(wù),也不像 SQL Server和Oracle那樣能提供各種附加功能,比如BI和報(bào)表等; 不提供對(duì)SQL的支持
那么該如何選擇?
如果規(guī)模和性能比24小時(shí)的數(shù)據(jù)一致性更重要,那NoSQL是一個(gè)理想的選擇 (NoSQL依賴于BASE模型——基本可用、軟狀態(tài)、最終一致性)。
但如果要保證到“始終一致”,尤其是對(duì)于機(jī)密信息和財(cái)務(wù)信息,那么MySQL很可能是最優(yōu)的選擇(MySQL依賴于ACID模型——原子性、一致性、獨(dú)立性和耐久性)。
如果關(guān)系數(shù)據(jù)庫(kù)在你的應(yīng)用場(chǎng)景中,完全能夠很好的工作,而你又是非常善于使用和維護(hù)關(guān)系數(shù)據(jù)庫(kù)的,那么我覺得你完全沒有必要遷移到NoSQL上面,除非你是個(gè)喜歡折騰的人。如果你是在金融,電信等以數(shù)據(jù)為王的關(guān)鍵領(lǐng)域,目前使用的是Oracle數(shù)據(jù)庫(kù)來提供高可靠性的,除非遇到特別大的瓶頸,不然也別貿(mào)然嘗試NoSQL。
然而,在WEB2.0的網(wǎng)站中,關(guān)系數(shù)據(jù)庫(kù)大部分都出現(xiàn)了瓶頸。在磁盤IO、數(shù)據(jù)庫(kù)可擴(kuò)展上都花費(fèi)了開發(fā)人員相當(dāng)多的精力來優(yōu)化,比如做分表分庫(kù)(database sharding)、主從復(fù)制、異構(gòu)復(fù)制等等,然而,這些工作需要的技術(shù)能力越來越高,也越來越具有挑戰(zhàn)性。如果你正在經(jīng)歷這些場(chǎng)合,那么我覺得你應(yīng)該嘗試一下NoSQL了。
具體問題具體分析
MySQL體積小、速度快、成本低、結(jié)構(gòu)穩(wěn)定、便于查詢,可以保證數(shù)據(jù)的一致性,但缺乏靈活性。
NoSQL高性能、高擴(kuò)展、高可用,不用局限于固定的結(jié)構(gòu),減少了時(shí)間和空間上的開銷,卻又很難保證數(shù)據(jù)一致性。
————————————————
版權(quán)聲明:本文為CSDN博主「蒟蒻熊」的原創(chuàng)文章,遵循CC 4.0 BY-SA版權(quán)協(xié)議,轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接:
什么是NoSQL
大家有沒有聽說過“NoSQL”呢?近年,這個(gè)詞極受關(guān)注。看到“NoSQL”這個(gè)詞,大家可能會(huì)誤以為是“No!SQL”的縮寫,并深感憤怒:“SQL怎么會(huì)沒有必要了呢?”但實(shí)際上,它是“Not Only SQL”的縮寫。它的意義是:適用關(guān)系型數(shù)據(jù)庫(kù)的時(shí)候就使用關(guān)系型數(shù)據(jù)庫(kù),不適用的時(shí)候也沒有必要非使用關(guān)系型數(shù)據(jù)庫(kù)不可,可以考慮使用更加合適的數(shù)據(jù)存儲(chǔ)。
為彌補(bǔ)關(guān)系型數(shù)據(jù)庫(kù)的不足,各種各樣的NoSQL數(shù)據(jù)庫(kù)應(yīng)運(yùn)而生。
為了更好地了解本書所介紹的NoSQL數(shù)據(jù)庫(kù),對(duì)關(guān)系型數(shù)據(jù)庫(kù)的理解是必不可少的。那么,就讓我們先來看一看關(guān)系型數(shù)據(jù)庫(kù)的歷史、分類和特征吧。
關(guān)系型數(shù)據(jù)庫(kù)簡(jiǎn)史
1969年,埃德加?6?1弗蘭克?6?1科德(Edgar Frank Codd)發(fā)表了劃時(shí)代的論文,首次提出了關(guān)系數(shù)據(jù)模型的概念。但可惜的是,刊登論文的《IBM Research Report》只是IBM公司的內(nèi)部刊物,因此論文反響平平。1970年,他再次在刊物《Communication of the ACM》上發(fā)表了題為“A Relational Model of Data for Large Shared Data banks”(大型共享數(shù)據(jù)庫(kù)的關(guān)系模型)的論文,終于引起了大家的關(guān)注。
科德所提出的關(guān)系數(shù)據(jù)模型的概念成為了現(xiàn)今關(guān)系型數(shù)據(jù)庫(kù)的基礎(chǔ)。當(dāng)時(shí)的關(guān)系型數(shù)據(jù)庫(kù)由于硬件性能低劣、處理速度過慢而遲遲沒有得到實(shí)際應(yīng)用。但之后隨著硬件性能的提升,加之使用簡(jiǎn)單、性能優(yōu)越等優(yōu)點(diǎn),關(guān)系型數(shù)據(jù)庫(kù)得到了廣泛的應(yīng)用。
通用性及高性能
雖然本書是講解NoSQL數(shù)據(jù)庫(kù)的,但有一個(gè)重要的大前提,請(qǐng)大家一定不要誤解。這個(gè)大前提就是“關(guān)系型數(shù)據(jù)庫(kù)的性能絕對(duì)不低,它具有非常好的通用性和非常高的性能”。毫無疑問,對(duì)于絕大多數(shù)的應(yīng)用來說它都是最有效的解決方案。
突出的優(yōu)勢(shì)
關(guān)系型數(shù)據(jù)庫(kù)作為應(yīng)用廣泛的通用型數(shù)據(jù)庫(kù),它的突出優(yōu)勢(shì)主要有以下幾點(diǎn):
保持?jǐn)?shù)據(jù)的一致性(事務(wù)處理)
由于以標(biāo)準(zhǔn)化為前提,數(shù)據(jù)更新的開銷很小(相同的字段基本上都只有一處)
可以進(jìn)行JOIN等復(fù)雜查詢
存在很多實(shí)際成果和專業(yè)技術(shù)信息(成熟的技術(shù))
這其中,能夠保持?jǐn)?shù)據(jù)的一致性是關(guān)系型數(shù)據(jù)庫(kù)的最大優(yōu)勢(shì)。在需要嚴(yán)格保證數(shù)據(jù)一致性和處理完整性的情況下,用關(guān)系型數(shù)據(jù)庫(kù)是肯定沒有錯(cuò)的。但是有些情況不需要JOIN,對(duì)上述關(guān)系型數(shù)據(jù)庫(kù)的優(yōu)點(diǎn)也沒有什么特別需要,這時(shí)似乎也就沒有必要拘泥于關(guān)系型數(shù)據(jù)庫(kù)了。
關(guān)系型數(shù)據(jù)庫(kù)的不足
不擅長(zhǎng)的處理
就像之前提到的那樣,關(guān)系型數(shù)據(jù)庫(kù)的性能非常高。但是它畢竟是一個(gè)通用型的數(shù)據(jù)庫(kù),并不能完全適應(yīng)所有的用途。具體來說它并不擅長(zhǎng)以下處理:
大量數(shù)據(jù)的寫入處理
為有數(shù)據(jù)更新的表做索引或表結(jié)構(gòu)(schema)變更
字段不固定時(shí)應(yīng)用
對(duì)簡(jiǎn)單查詢需要快速返回結(jié)果的處理
。。。。。。
NoSQL數(shù)據(jù)庫(kù)
為了彌補(bǔ)關(guān)系型數(shù)據(jù)庫(kù)的不足(特別是最近幾年),NoSQL數(shù)據(jù)庫(kù)出現(xiàn)了。關(guān)系型數(shù)據(jù)庫(kù)應(yīng)用廣泛,能進(jìn)行事務(wù)處理和JOIN等復(fù)雜處理。相對(duì)地,NoSQL數(shù)據(jù)庫(kù)只應(yīng)用在特定領(lǐng)域,基本上不進(jìn)行復(fù)雜的處理,但它恰恰彌補(bǔ)了之前所列舉的關(guān)系型數(shù)據(jù)庫(kù)的不足之處。
易于數(shù)據(jù)的分散
如前所述,關(guān)系型數(shù)據(jù)庫(kù)并不擅長(zhǎng)大量數(shù)據(jù)的寫入處理。原本關(guān)系型數(shù)據(jù)庫(kù)就是以JOIN為前提的,就是說,各個(gè)數(shù)據(jù)之間存在關(guān)聯(lián)是關(guān)系型數(shù)據(jù)庫(kù)得名的主要原因。為了進(jìn)行JOIN處理,關(guān)系型數(shù)據(jù)庫(kù)不得不把數(shù)據(jù)存儲(chǔ)在同一個(gè)服務(wù)器內(nèi),這不利于數(shù)據(jù)的分散。相反,NoSQL數(shù)據(jù)庫(kù)原本就不支持JOIN處理,各個(gè)數(shù)據(jù)都是獨(dú)立設(shè)計(jì)的,很容易把數(shù)據(jù)分散到多個(gè)服務(wù)器上。由于數(shù)據(jù)被分散到了多個(gè)服務(wù)器上,減少了每個(gè)服務(wù)器上的數(shù)據(jù)量,即使要進(jìn)行大量數(shù)據(jù)的寫入操作,處理起來也更加容易。同理,數(shù)據(jù)的讀入操作當(dāng)然也同樣容易。
提升性能和增大規(guī)模
下面說一點(diǎn)題外話,如果想要使服務(wù)器能夠輕松地處理更大量的數(shù)據(jù),那么只有兩個(gè)選擇:一是提升性能,二是增大規(guī)模。下面我們來整理一下這兩者的不同。
首先,提升性能指的就是通過提升現(xiàn)行服務(wù)器自身的性能來提高處理能力。這是非常簡(jiǎn)單的方法,程序方面也不需要進(jìn)行變更,但需要一些費(fèi)用。若要購(gòu)買性能翻倍的服務(wù)器,需要花費(fèi)的資金往往不只是原來的2倍,可能需要多達(dá)5到10倍。這種方法雖然簡(jiǎn)單,但是成本較高。
另一方面,增大規(guī)模指的是使用多臺(tái)廉價(jià)的服務(wù)器來提高處理能力。它需要對(duì)程序進(jìn)行變更,但由于使用廉價(jià)的服務(wù)器,可以控制成本。另外,以后只要依葫蘆畫瓢增加廉價(jià)服務(wù)器的數(shù)量就可以了。
不對(duì)大量數(shù)據(jù)進(jìn)行處理的話就沒有使用的必要嗎?
NoSQL數(shù)據(jù)庫(kù)基本上來說為了“使大量數(shù)據(jù)的寫入處理更加容易(讓增加服務(wù)器數(shù)量更容易)”而設(shè)計(jì)的。但如果不是對(duì)大量數(shù)據(jù)進(jìn)行操作的話,NoSQL數(shù)據(jù)庫(kù)的應(yīng)用就沒有意義嗎?
答案是否定的。的確,它在處理大量數(shù)據(jù)方面很有優(yōu)勢(shì)。但實(shí)際上NoSQL數(shù)據(jù)庫(kù)還有各種各樣的特點(diǎn),如果能夠恰當(dāng)?shù)乩眠@些特點(diǎn)將會(huì)是非常有幫助。具體的例子將會(huì)在第2章和第3章進(jìn)行介紹,這些用途將會(huì)讓你感受到利用NoSQL的好處。
希望順暢地對(duì)數(shù)據(jù)進(jìn)行緩存(Cache)處理
希望對(duì)數(shù)組類型的數(shù)據(jù)進(jìn)行高速處理
希望進(jìn)行全部保存
多樣的NoSQL數(shù)據(jù)庫(kù)
NoSQL數(shù)據(jù)庫(kù)存在著“key-value存儲(chǔ)”、“文檔型數(shù)據(jù)庫(kù)”、“列存儲(chǔ)數(shù)據(jù)庫(kù)”等各種各樣的種類,每種數(shù)據(jù)庫(kù)又包含各自的特點(diǎn)。下一節(jié)讓我們一起來了解一下NoSQL數(shù)據(jù)庫(kù)的種類和特點(diǎn)。
NoSQL數(shù)據(jù)庫(kù)是什么
NoSQL說起來簡(jiǎn)單,但實(shí)際上到底有多少種呢?我在提筆的時(shí)候,到NoSQL的官方網(wǎng)站上確認(rèn)了一下,竟然已經(jīng)有122種了。另外官方網(wǎng)站上也介紹了本書沒有涉及到的圖形數(shù)據(jù)庫(kù)和對(duì)象數(shù)據(jù)庫(kù)等各個(gè)類別。不知不覺間,原來已經(jīng)出現(xiàn)了這么多的NoSQL數(shù)據(jù)庫(kù)啊。
本節(jié)將為大家介紹具有代表性的NoSQL數(shù)據(jù)庫(kù)。
key-value存儲(chǔ)
這是最常見的NoSQL數(shù)據(jù)庫(kù),它的數(shù)據(jù)是以key-value的形式存儲(chǔ)的。雖然它的處理速度非常快,但是基本上只能通過key的完全一致查詢獲取數(shù)據(jù)。根據(jù)數(shù)據(jù)的保存方式可以分為臨時(shí)性、永久性和兩者兼具三種。
臨時(shí)性
memcached屬于這種類型。所謂臨時(shí)性就是 “數(shù)據(jù)有可能丟失”的意思。memcached把所有數(shù)據(jù)都保存在內(nèi)存中,這樣保存和讀取的速度非常快,但是當(dāng)memcached停止的時(shí)候,數(shù)據(jù)就不存在了。由于數(shù)據(jù)保存在內(nèi)存中,所以無法操作超出內(nèi)存容量的數(shù)據(jù)(舊數(shù)據(jù)會(huì)丟失)。
在內(nèi)存中保存數(shù)據(jù)
可以進(jìn)行非常快速的保存和讀取處理
數(shù)據(jù)有可能丟失
永久性
Tokyo Tyrant、Flare、ROMA等屬于這種類型。和臨時(shí)性相反,所謂永久性就是“數(shù)據(jù)不會(huì)丟失”的意思。這里的key-value存儲(chǔ)不像memcached那樣在內(nèi)存中保存數(shù)據(jù),而是把數(shù)據(jù)保存在硬盤上。與memcached在內(nèi)存中處理數(shù)據(jù)比起來,由于必然要發(fā)生對(duì)硬盤的IO操作,所以性能上還是有差距的。但數(shù)據(jù)不會(huì)丟失是它最大的優(yōu)勢(shì)。
在硬盤上保存數(shù)據(jù)
可以進(jìn)行非常快速的保存和讀取處理(但無法與memcached相比)
數(shù)據(jù)不會(huì)丟失
兩者兼具
Redis屬于這種類型。Redis有些特殊,臨時(shí)性和永久性兼具,且集合了臨時(shí)性key-value存儲(chǔ)和永久性key-value存儲(chǔ)的優(yōu)點(diǎn)。Redis首先把數(shù)據(jù)保存到內(nèi)存中,在滿足特定條件(默認(rèn)是15分鐘一次以上,5分鐘內(nèi)10個(gè)以上,1分鐘內(nèi)10000個(gè)以上的key發(fā)生變更)的時(shí)候?qū)?shù)據(jù)寫入到硬盤中。這樣既確保了內(nèi)存中數(shù)據(jù)的處理速度,又可以通過寫入硬盤來保證數(shù)據(jù)的永久性。這種類型的數(shù)據(jù)庫(kù)特別適合于處理數(shù)組類型的數(shù)據(jù)。
同時(shí)在內(nèi)存和硬盤上保存數(shù)據(jù)
可以進(jìn)行非常快速的保存和讀取處理
保存在硬盤上的數(shù)據(jù)不會(huì)消失(可以恢復(fù))
適合于處理數(shù)組類型的數(shù)據(jù)
面向文檔的數(shù)據(jù)庫(kù)
MongoDB、CouchDB屬于這種類型。它們屬于NoSQL數(shù)據(jù)庫(kù),但與key-value存儲(chǔ)相異。
不定義表結(jié)構(gòu)
面向文檔的數(shù)據(jù)庫(kù)具有以下特征:即使不定義表結(jié)構(gòu),也可以像定義了表結(jié)構(gòu)一樣使用。關(guān)系型數(shù)據(jù)庫(kù)在變更表結(jié)構(gòu)時(shí)比較費(fèi)事,而且為了保持一致性還需修改程序。然而NoSQL數(shù)據(jù)庫(kù)則可省去這些麻煩(通常程序都是正確的),確實(shí)是方便快捷。
可以使用復(fù)雜的查詢條件
跟key-value存儲(chǔ)不同的是,面向文檔的數(shù)據(jù)庫(kù)可以通過復(fù)雜的查詢條件來獲取數(shù)據(jù)。雖然不具備事務(wù)處理和JOIN這些關(guān)系型數(shù)據(jù)庫(kù)所具有的處理能力,但除此以外的其他處理基本上都能實(shí)現(xiàn)。這是非常容易使用的NoSQL數(shù)據(jù)庫(kù)。
不需要定義表結(jié)構(gòu)
可以利用復(fù)雜的查詢條件
面向列的數(shù)據(jù)庫(kù)
Cassandra、Hbase、HyperTable屬于這種類型。由于近年來數(shù)據(jù)量出現(xiàn)爆發(fā)性增長(zhǎng),這種類型的NoSQL數(shù)據(jù)庫(kù)尤其引人注目。
面向行的數(shù)據(jù)庫(kù)和面向列的數(shù)據(jù)庫(kù)
普通的關(guān)系型數(shù)據(jù)庫(kù)都是以行為單位來存儲(chǔ)數(shù)據(jù)的,擅長(zhǎng)進(jìn)行以行為單位的讀入處理,比如特定條件數(shù)據(jù)的獲取。因此,關(guān)系型數(shù)據(jù)庫(kù)也被稱為面向行的數(shù)據(jù)庫(kù)。相反,面向列的數(shù)據(jù)庫(kù)是以列為單位來存儲(chǔ)數(shù)據(jù)的,擅長(zhǎng)以列為單位讀入數(shù)據(jù)。
高擴(kuò)展性
面向列的數(shù)據(jù)庫(kù)具有高擴(kuò)展性,即使數(shù)據(jù)增加也不會(huì)降低相應(yīng)的處理速度(特別是寫入速度),所以它主要應(yīng)用于需要處理大量數(shù)據(jù)的情況。另外,利用面向列的數(shù)據(jù)庫(kù)的優(yōu)勢(shì),把它作為批處理程序的存儲(chǔ)器來對(duì)大量數(shù)據(jù)進(jìn)行更新也是非常有用的。但由于面向列的數(shù)據(jù)庫(kù)跟現(xiàn)行數(shù)據(jù)庫(kù)存儲(chǔ)的思維方式有很大不同,應(yīng)用起來十分困難。
高擴(kuò)展性(特別是寫入處理)
應(yīng)用十分困難
最近,像Twitter和Facebook這樣需要對(duì)大量數(shù)據(jù)進(jìn)行更新和查詢的網(wǎng)絡(luò)服務(wù)不斷增加,面向列的數(shù)據(jù)庫(kù)的優(yōu)勢(shì)對(duì)其中一些服務(wù)是非常有用的,但是由于這與本書所要介紹的內(nèi)容關(guān)系不大,就不進(jìn)行詳細(xì)介紹了。
總結(jié):
NoSQL并不是No-SQL,而是指Not Only SQL。
NoSQL的出現(xiàn)是為了彌補(bǔ)SQL數(shù)據(jù)庫(kù)因?yàn)槭聞?wù)等機(jī)制帶來的對(duì)海量數(shù)據(jù)、高并發(fā)請(qǐng)求的處理的性能上的欠缺。
NoSQL不是為了替代SQL而出現(xiàn)的,它是一種替補(bǔ)方案,而不是解決方案的首選。
絕大多數(shù)的NoSQL產(chǎn)品都是基于大內(nèi)存和高性能隨機(jī)讀寫的(比如具有更高性能的固態(tài)硬盤陣列),一般的小型企業(yè)在選擇NoSQL時(shí)一定要慎重!不要為了NoSQL而NoSQL,可能會(huì)導(dǎo)致花了冤枉錢又耽擱了項(xiàng)目進(jìn)程。
NoSQL不是萬能的,但在大型項(xiàng)目中,你往往需要它!
本文標(biāo)題:nosql不支持join,nosql不支持事務(wù)
URL網(wǎng)址:http://chinadenli.net/article29/dsihjjh.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供企業(yè)網(wǎng)站制作、全網(wǎng)營(yíng)銷推廣、域名注冊(cè)、網(wǎng)站收錄、手機(jī)網(wǎng)站建設(shè)、
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)