您好,很高興為您解答。

創(chuàng)新互聯(lián)公司2013年成立,是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司,擁有項(xiàng)目網(wǎng)站建設(shè)、成都網(wǎng)站制作網(wǎng)站策劃,項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命,1280元合江做網(wǎng)站,已為上家服務(wù),為合江各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:13518219792
第一先限制Innodb的并發(fā)處理.如果innodb_thread_concurrency = 0 可以先改成 16或是64 看機(jī)器壓力,如果
非常大,先改成16讓機(jī)器的壓力下來(lái),然后慢慢增達(dá),適應(yīng)自已的業(yè)務(wù).
處理方法: set global innodb_thread_concurrency=16;
第二: 對(duì)于連接數(shù)已經(jīng)超過600或是更多的情況,可以考慮適當(dāng)?shù)南拗埔幌逻B接數(shù),讓前端報(bào)一下錯(cuò),也別讓DB掛了.
DB在了,總是可以用來(lái)加載一下數(shù)據(jù),當(dāng)數(shù)據(jù)加載到了nosql里了,慢慢的DB壓力也會(huì)降下來(lái)的.
限制單用戶連接數(shù)在500以下. 如:
set global max_user_connections=500;
(MySQL隨著連接數(shù)的增加性能會(huì)是下降的,這也是thread_pool出現(xiàn)的原因)
另外對(duì)于有的監(jiān)控程序會(huì)讀取information_schema下面的表的程序可以考慮關(guān)閉下面的參數(shù)
innodb_stats_on_metadata=0
set global innodb_stats_on_metadata=0;
這個(gè)參數(shù)主要防止對(duì)讀取information_schema時(shí)造成大量讀取磁盤進(jìn)行信息統(tǒng)計(jì)(如果慢查詢中出現(xiàn)關(guān)于information_schema中表時(shí),也可以考慮禁用該參數(shù))
處理依據(jù):
當(dāng)學(xué)校的一個(gè)食堂一分鐘只能為兩個(gè)打飯, 忽然來(lái)了100個(gè)時(shí)人來(lái)打飯,又沒排隊(duì), 不出會(huì)現(xiàn)了打飯的師傅要用點(diǎn)時(shí)間
去選擇為那個(gè)用戶服務(wù)了, 人越多,場(chǎng)面就越亂, 難免出現(xiàn)用戶大吼該他的場(chǎng)面, 最后有可能就出現(xiàn)不是打飯了,而時(shí)之間相互
打架了,打飯的師傅也將收到同時(shí)有90個(gè)以上的Server too busy. 如果能排一下隊(duì).最多也就50分鐘能處理完了.
以前辦法,應(yīng)該可以讓MySQLD不會(huì)掛掉.如果業(yè)務(wù)支撐受到限制,還是想辦法處理一下.
這次的NoSQL專欄系列將先整體介紹NoSQL,然后介紹如何把NoSQL運(yùn)用到自己的項(xiàng)目中合適的場(chǎng)景中,還會(huì)適當(dāng)?shù)胤治鲆恍┏晒Π咐M谐晒κ褂肗oSQL經(jīng)驗(yàn)的朋友給我提供一些線索和信息。
NoSQL概念隨著web2.0的快速發(fā)展,非關(guān)系型、分布式數(shù)據(jù)存儲(chǔ)得到了快速的發(fā)展,它們不保證關(guān)系數(shù)據(jù)的ACID特性。NoSQL概念在2009年被提了出來(lái)。NoSQL最常見的解釋是“non-relational”,“Not Only SQL”也被很多人接受。(“NoSQL”一詞最早于1998年被用于一個(gè)輕量級(jí)的關(guān)系數(shù)據(jù)庫(kù)的名字。)
NoSQL被我們用得最多的當(dāng)數(shù)key-value存儲(chǔ),當(dāng)然還有其他的文檔型的、列存儲(chǔ)、圖型數(shù)據(jù)庫(kù)、xml數(shù)據(jù)庫(kù)等。在NoSQL概念提出之前,這些數(shù)據(jù)庫(kù)就被用于各種系統(tǒng)當(dāng)中,但是卻很少用于web互聯(lián)網(wǎng)應(yīng)用。比如cdb、qdbm、bdb數(shù)據(jù)庫(kù)。
傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)的瓶頸
傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)具有不錯(cuò)的性能,高穩(wěn)定型,久經(jīng)歷史考驗(yàn),而且使用簡(jiǎn)單,功能強(qiáng)大,同時(shí)也積累了大量的成功案例。在互聯(lián)網(wǎng)領(lǐng)域,MySQL成為了絕對(duì)靠前的王者,毫不夸張的說(shuō),MySQL為互聯(lián)網(wǎng)的發(fā)展做出了卓越的貢獻(xiàn)。
在90年代,一個(gè)網(wǎng)站的訪問量一般都不大,用單個(gè)數(shù)據(jù)庫(kù)完全可以輕松應(yīng)付。在那個(gè)時(shí)候,更多的都是靜態(tài)網(wǎng)頁(yè),動(dòng)態(tài)交互類型的網(wǎng)站不多。
到了最近10年,網(wǎng)站開始快速發(fā)展。火爆的論壇、博客、sns、微博逐漸引領(lǐng)web領(lǐng)域的潮流。在初期,論壇的流量其實(shí)也不大,如果你接觸網(wǎng)絡(luò)比較早,你可能還記得那個(gè)時(shí)候還有文本型存儲(chǔ)的論壇程序,可以想象一般的論壇的流量有多大。
Memcached+MySQL
后來(lái),隨著訪問量的上升,幾乎大部分使用MySQL架構(gòu)的網(wǎng)站在數(shù)據(jù)庫(kù)上都開始出現(xiàn)了性能問題,web程序不再僅僅專注在功能上,同時(shí)也在追求性能。程序員們開始大量的使用緩存技術(shù)來(lái)緩解數(shù)據(jù)庫(kù)的壓力,優(yōu)化數(shù)據(jù)庫(kù)的結(jié)構(gòu)和索引。開始比較流行的是通過文件緩存來(lái)緩解數(shù)據(jù)庫(kù)壓力,但是當(dāng)訪問量繼續(xù)增大的時(shí)候,多臺(tái)web機(jī)器通過文件緩存不能共享,大量的小文件緩存也帶了了比較高的IO壓力。在這個(gè)時(shí)候,Memcached就自然的成為一個(gè)非常時(shí)尚的技術(shù)產(chǎn)品。
Memcached作為一個(gè)獨(dú)立的分布式的緩存服務(wù)器,為多個(gè)web服務(wù)器提供了一個(gè)共享的高性能緩存服務(wù),在Memcached服務(wù)器上,又發(fā)展了根據(jù)hash算法來(lái)進(jìn)行多臺(tái)Memcached緩存服務(wù)的擴(kuò)展,然后又出現(xiàn)了一致性hash來(lái)解決增加或減少緩存服務(wù)器導(dǎo)致重新hash帶來(lái)的大量緩存失效的弊端。當(dāng)時(shí),如果你去面試,你說(shuō)你有Memcached經(jīng)驗(yàn),肯定會(huì)加分的。
Mysql主從讀寫分離
由于數(shù)據(jù)庫(kù)的寫入壓力增加,Memcached只能緩解數(shù)據(jù)庫(kù)的讀取壓力。讀寫集中在一個(gè)數(shù)據(jù)庫(kù)上讓數(shù)據(jù)庫(kù)不堪重負(fù),大部分網(wǎng)站開始使用主從復(fù)制技術(shù)來(lái)達(dá)到讀寫分離,以提高讀寫性能和讀庫(kù)的可擴(kuò)展性。Mysql的master-slave模式成為這個(gè)時(shí)候的網(wǎng)站標(biāo)配了。
分表分庫(kù)隨著web2.0的繼續(xù)高速發(fā)展,在Memcached的高速緩存,MySQL的主從復(fù)制,讀寫分離的基礎(chǔ)之上,這時(shí)MySQL主庫(kù)的寫壓力開始出現(xiàn)瓶頸,而數(shù)據(jù)量的持續(xù)猛增,由于MyISAM使用表鎖,在高并發(fā)下會(huì)出現(xiàn)嚴(yán)重的鎖問題,大量的高并發(fā)MySQL應(yīng)用開始使用InnoDB引擎代替MyISAM。同時(shí),開始流行使用分表分庫(kù)來(lái)緩解寫壓力和數(shù)據(jù)增長(zhǎng)的擴(kuò)展問題。這個(gè)時(shí)候,分表分庫(kù)成了一個(gè)熱門技術(shù),是面試的熱門問題也是業(yè)界討論的熱門技術(shù)問題。也就在這個(gè)時(shí)候,MySQL推出了還不太穩(wěn)定的表分區(qū),這也給技術(shù)實(shí)力一般的公司帶來(lái)了希望。雖然MySQL推出了MySQL Cluster集群,但是由于在互聯(lián)網(wǎng)幾乎沒有成功案例,性能也不能滿足互聯(lián)網(wǎng)的要求,只是在高可靠性上提供了非常大的保證。
MySQL的擴(kuò)展性瓶頸
在互聯(lián)網(wǎng),大部分的MySQL都應(yīng)該是IO密集型的,事實(shí)上,如果你的MySQL是個(gè)CPU密集型的話,那么很可能你的MySQL設(shè)計(jì)得有性能問題,需要優(yōu)化了。大數(shù)據(jù)量高并發(fā)環(huán)境下的MySQL應(yīng)用開發(fā)越來(lái)越復(fù)雜,也越來(lái)越具有技術(shù)挑戰(zhàn)性。分表分庫(kù)的規(guī)則把握都是需要經(jīng)驗(yàn)的。雖然有像淘寶這樣技術(shù)實(shí)力強(qiáng)大的公司開發(fā)了透明的中間件層來(lái)屏蔽開發(fā)者的復(fù)雜性,但是避免不了整個(gè)架構(gòu)的復(fù)雜性。分庫(kù)分表的子庫(kù)到一定階段又面臨擴(kuò)展問題。還有就是需求的變更,可能又需要一種新的分庫(kù)方式。
MySQL數(shù)據(jù)庫(kù)也經(jīng)常存儲(chǔ)一些大文本字段,導(dǎo)致數(shù)據(jù)庫(kù)表非常的大,在做數(shù)據(jù)庫(kù)恢復(fù)的時(shí)候就導(dǎo)致非常的慢,不容易快速恢復(fù)數(shù)據(jù)庫(kù)。比如1000萬(wàn)4KB大小的文本就接近40GB的大小,如果能把這些數(shù)據(jù)從MySQL省去,MySQL將變得非常的小。
關(guān)系數(shù)據(jù)庫(kù)很強(qiáng)大,但是它并不能很好的應(yīng)付所有的應(yīng)用場(chǎng)景。MySQL的擴(kuò)展性差(需要復(fù)雜的技術(shù)來(lái)實(shí)現(xiàn)),大數(shù)據(jù)下IO壓力大,表結(jié)構(gòu)更改困難,正是當(dāng)前使用MySQL的開發(fā)人員面臨的問題。
NOSQL的優(yōu)勢(shì)易擴(kuò)展NoSQL數(shù)據(jù)庫(kù)種類繁多,但是一個(gè)共同的特點(diǎn)都是去掉關(guān)系數(shù)據(jù)庫(kù)的關(guān)系型特性。數(shù)據(jù)之間無(wú)關(guān)系,這樣就非常容易擴(kuò)展。也無(wú)形之間,在架構(gòu)的層面上帶來(lái)了可擴(kuò)展的能力。
大數(shù)據(jù)量,高性能
NoSQL數(shù)據(jù)庫(kù)都具有非常高的讀寫性能,尤其在大數(shù)據(jù)量下,同樣表現(xiàn)優(yōu)秀。這得益于它的無(wú)關(guān)系性,數(shù)據(jù)庫(kù)的結(jié)構(gòu)簡(jiǎn)單。一般MySQL使用Query Cache,每次表的更新Cache就失效,是一種大粒度的Cache,在針對(duì)web2.0的交互頻繁的應(yīng)用,Cache性能不高。而NoSQL的Cache是記錄級(jí)的,是一種細(xì)粒度的Cache,所以NoSQL在這個(gè)層面上來(lái)說(shuō)就要性能高很多了。
靈活的數(shù)據(jù)模型
NoSQL無(wú)需事先為要存儲(chǔ)的數(shù)據(jù)建立字段,隨時(shí)可以存儲(chǔ)自定義的數(shù)據(jù)格式。而在關(guān)系數(shù)據(jù)庫(kù)里,增刪字段是一件非常麻煩的事情。如果是非常大數(shù)據(jù)量的表,增加字段簡(jiǎn)直就是一個(gè)噩夢(mèng)。這點(diǎn)在大數(shù)據(jù)量的web2.0時(shí)代尤其明顯。
高可用NoSQL在不太影響性能的情況,就可以方便的實(shí)現(xiàn)高可用的架構(gòu)。比如Cassandra,HBase模型,通過復(fù)制模型也能實(shí)現(xiàn)高可用。
總結(jié)NoSQL數(shù)據(jù)庫(kù)的出現(xiàn),彌補(bǔ)了關(guān)系數(shù)據(jù)(比如MySQL)在某些方面的不足,在某些方面能極大的節(jié)省開發(fā)成本和維護(hù)成本。
MySQL和NoSQL都有各自的特點(diǎn)和使用的應(yīng)用場(chǎng)景,兩者的緊密結(jié)合將會(huì)給web2.0的數(shù)據(jù)庫(kù)發(fā)展帶來(lái)新的思路。
本質(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)致不能滿足需要。
具體則需要對(duì)比關(guān)系型數(shù)據(jù)庫(kù)與Nosql之間的區(qū)別可以得出
關(guān)系型數(shù)據(jù)庫(kù)
關(guān)系型數(shù)據(jù)庫(kù)把所有的數(shù)據(jù)都通過行和列的二元表現(xiàn)形式表示出來(lái)。
關(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ù)來(lái)實(shí)現(xiàn)規(guī)模化,但是數(shù)據(jù)的寫入?yún)s完全沒有簡(jiǎn)單的方法來(lái)解決規(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ù)來(lái)處理。
第二,可以考慮把數(shù)據(jù)庫(kù)分割開來(lái),分別放在不同的數(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ù)器上的表之間無(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ù)變更、更新、插入、刪除等都是無(wú)法進(jìn)行的。如果需要進(jìn)行一些耗時(shí)操作,例如為數(shù)據(jù)量比較大的表創(chuàng)建索引或是變更其表結(jié)構(gòu),就需要特別注意,長(zhǎng)時(shí)間內(nèi)數(shù)據(jù)可能無(wú)法進(jìn)行更新。
--字段不固定時(shí)的應(yīng)用
如果字段不固定,利用關(guān)系型數(shù)據(jù)庫(kù)也是比較困難的,有人會(huì)說(shuō),需要的時(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語(yǔ)言進(jìn)行數(shù)據(jù)讀取的,它需要對(duì)sql與越南進(jìn)行解析,同時(shí)還有對(duì)表的鎖定和解鎖等這樣的額外開銷,這里并不是說(shuō)關(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)存中,所以無(wú)法操作超出內(nèi)存容量的數(shù)據(jù),舊數(shù)據(jù)會(huì)丟失。總結(jié)來(lái)說(shuō):
。在內(nèi)存中保存數(shù)據(jù)
。可以進(jìn)行非常快速的保存和讀取處理
。數(shù)據(jù)有可能丟失
(2)永久性
所謂永久性就是數(shù)據(jù)不會(huì)丟失,這里的鍵值存儲(chǔ)是把數(shù)據(jù)保存在硬盤上,與臨時(shí)性比起來(lái),由于必然要發(fā)生對(duì)硬盤的IO操作,所以性能上還是有差距的,但數(shù)據(jù)不會(huì)丟失是它最大的優(yōu)勢(shì)。總結(jié)來(lái)說(shuō):
。在硬盤上保存數(shù)據(jù)
。可以進(jìn)行非常快速的保存和讀取處理(但無(wú)法與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ù)的處理速度,又可以通過寫入硬盤來(lái)保證數(shù)據(jù)的永久性,這種類型的數(shù)據(jù)庫(kù)特別適合處理數(shù)組類型的數(shù)據(jù)。總結(jié)來(lái)說(shuō):
。同時(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ù)雜的查詢條件來(lái)獲取數(shù)據(jù),雖然不具備事務(wù)處理和Join這些關(guān)系型數(shù)據(jù)庫(kù)所具有的處理能力,但初次以外的其他處理基本上都能實(shí)現(xiàn)。
三、?面向列的數(shù)據(jù)庫(kù)
Cassandra、HBae、HyperTable屬于這種類型,由于近年來(lái)數(shù)據(jù)量出現(xiàn)爆發(fā)性增長(zhǎng),這種類型的NoSQL數(shù)據(jù)庫(kù)尤其引入注目。
普通的關(guān)系型數(shù)據(jù)庫(kù)都是以行為單位來(lái)存儲(chǔ)數(shù)據(jù)的,擅長(zhǎng)以行為單位的讀入處理,比如特定條件數(shù)據(jù)的獲取。因此,關(guān)系型數(shù)據(jù)庫(kù)也被成為面向行的數(shù)據(jù)庫(kù)。相反,面向列的數(shù)據(jù)庫(kù)是以列為單位來(lái)存儲(chǔ)數(shù)據(jù)的,擅長(zhǎng)以列為單位讀入數(shù)據(jù)。
面向列的數(shù)據(jù)庫(kù)具有搞擴(kuò)展性,即使數(shù)據(jù)增加也不會(huì)降低相應(yīng)的處理速度(特別是寫入速度),所以它主要應(yīng)用于需要處理大量數(shù)據(jù)的情況。另外,把它作為批處理程序的存儲(chǔ)器來(lái)對(duì)大量數(shù)據(jù)進(jìn)行更新也是非常有用的。但由于面向列的數(shù)據(jù)庫(kù)跟現(xiàn)行數(shù)據(jù)庫(kù)存儲(chǔ)的思維方式有很大不同,故應(yīng)用起來(lái)十分困難。
總結(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ǔ)。
即非關(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)來(lái)擴(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ù)來(lái)提供高可靠性的,除非遇到特別大的瓶頸,不然也別貿(mào)然嘗試NoSQL。
然而,在WEB2.0的網(wǎng)站中,關(guān)系數(shù)據(jù)庫(kù)大部分都出現(xiàn)了瓶頸。在磁盤IO、數(shù)據(jù)庫(kù)可擴(kuò)展上都花費(fèi)了開發(fā)人員相當(dāng)多的精力來(lái)優(yōu)化,比如做分表分庫(kù)(database sharding)、主從復(fù)制、異構(gòu)復(fù)制等等,然而,這些工作需要的技術(shù)能力越來(lái)越高,也越來(lái)越具有挑戰(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)附上原文出處鏈接及本聲明。
原文鏈接:
因?yàn)樗饕唷M粭l個(gè)數(shù)據(jù),NOSQL占用空間是一般SQL數(shù)據(jù)庫(kù)的3-5倍。
你可以理解成NOSQL默認(rèn)開啟全字段索引和全文索引什么的。
其實(shí)在十萬(wàn)級(jí)以下的數(shù)據(jù),只要SQL建好索引的情況并不比NOSQL慢。NOSQL主要是用于千萬(wàn)上億級(jí)的時(shí)候。
NoSQL 數(shù)據(jù)庫(kù)因其功能性、易于開發(fā)性和可擴(kuò)展性而廣受認(rèn)可,它們?cè)絹?lái)越多地用于大數(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 年代后期以來(lái)就已經(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)有硬件來(lái)“擴(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ì)象來(lái)更好地捕獲這些信息。
傳統(tǒng)的 RDBMS 使用 SQL(結(jié)構(gòu)化查詢語(yǔ)言)語(yǔ)法來(lái)存儲(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 的語(yǔ)言或與 SQL 數(shù)據(jù)庫(kù)并列。SQL 和 NoSQL DBMS 之間的一個(gè)區(qū)別是 JOIN 功能。SQL 數(shù)據(jù)庫(kù)使用 JOIN 子句來(lái)組合來(lái)自兩個(gè)或多個(gè)表的行,因?yàn)?NoSQL 數(shù)據(jù)庫(kù)本質(zhì)上不是表格的,所以這個(gè)功能并不總是可行或相關(guān)的。
但是,一些 NoSQL DBMS 可以執(zhí)行類似于 JOIN的操作——就像 MongoDB 一樣。這并不意味著不再需要 SQL DBMS,相反,NoSQL 和 SQL 數(shù)據(jù)庫(kù)傾向于以不同的方式解決類似的問題。
一般來(lái)說(shuō),在以下情況下,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ù)是指太大而無(wú)法通過傳統(tǒng)處理系統(tǒng)處理的數(shù)據(jù)集,實(shí)時(shí)存儲(chǔ)和檢索大數(shù)據(jù)的系統(tǒng)在分析 歷史 數(shù)據(jù)的同時(shí)使用流處理來(lái)攝取新數(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ò)的嵌入式軟件和傳感器,能夠在無(wú)需人工干預(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ù)百萬(wàn)個(gè)請(qǐng)求,同時(shí)還處理用戶數(shù)據(jù)并提供天氣更新。
本文題目:包含Nosql數(shù)據(jù)更新會(huì)很慢的詞條
當(dāng)前URL:http://chinadenli.net/article31/dsggdsd.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站策劃、網(wǎng)站設(shè)計(jì)、網(wǎng)站維護(hù)、品牌網(wǎng)站制作、ChatGPT、網(wǎng)站內(nèi)鏈
聲明:本網(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í)需注明來(lái)源: 創(chuàng)新互聯(lián)