本文將從單機(jī)MySQL的場景出發(fā),簡述一下隨著網(wǎng)站的訪問量越來越大,數(shù)據(jù)庫部署的演進(jìn)過程,到為什么要用MySQL的必要性。
創(chuàng)新互聯(lián)公司是專業(yè)的貴陽網(wǎng)站建設(shè)公司,貴陽接單;提供成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì),網(wǎng)頁設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行貴陽網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來合作!
大數(shù)據(jù)時(shí)代的數(shù)據(jù)有3V的特點(diǎn):海量Volume、多樣Variety、實(shí)時(shí)Velocity。
互聯(lián)網(wǎng)網(wǎng)站需求的3高的特點(diǎn):高并發(fā)、高可擴(kuò)、高性能。
一、單機(jī)MySql
當(dāng)一個(gè)網(wǎng)站的訪問量不大時(shí),用單個(gè)數(shù)據(jù)庫完全可以輕松應(yīng)付。
在那個(gè)時(shí)候,更多的都是靜態(tài)網(wǎng)頁,動(dòng)態(tài)交互類型的網(wǎng)站不多。
上述架構(gòu)下,我們來看看數(shù)據(jù)存儲(chǔ)的瓶頸是什么?
1.數(shù)據(jù)量的總大小 一個(gè)機(jī)器放不下時(shí)
2.數(shù)據(jù)的索引(B+ Tree)一個(gè)機(jī)器的內(nèi)存放不下時(shí)
3.訪問量(讀寫混合)一個(gè)實(shí)例不能承受
如果滿足了上述1 or 3個(gè),進(jìn)化......
二、Memcached(緩存)+Mysql+垂直拆分
后來,隨著訪問量的上升,幾乎大部分使用MySQL架構(gòu)的網(wǎng)站在數(shù)據(jù)庫上都開始出現(xiàn)了性能問題,web程序不再僅僅專注在功能上,同時(shí)也在追求性能。程序員們開始大量的使用緩存技術(shù)來緩解數(shù)據(jù)庫的壓力,優(yōu)化數(shù)據(jù)庫的結(jié)構(gòu)和索引。開始比較流行的是通過文件緩存來緩解數(shù)據(jù)庫壓力,但是當(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算法來進(jìn)行多臺(tái)Memcached緩存服務(wù)的擴(kuò)展,然后又出現(xiàn)了一致性hash來解決增加或減少緩存服務(wù)器導(dǎo)致重新hash帶來的大量緩存失效的弊端
三、MySql主從復(fù)制讀寫分離
由于數(shù)據(jù)庫的寫入壓力增加,Memcached只能緩解數(shù)據(jù)庫的讀取壓力。讀寫集中在一個(gè)數(shù)據(jù)庫上讓數(shù)據(jù)庫不堪重負(fù),大部分網(wǎng)站開始使用主從復(fù)制技術(shù)來達(dá)到讀寫分離,以提高讀寫性能和讀庫的可擴(kuò)展性。Mysql的master-slave模式成為這個(gè)時(shí)候的網(wǎng)站標(biāo)配了。
四、分庫分表+水平拆分+Mysql集群
在Memcached的高速緩存,MySQL的主從復(fù)制,讀寫分離的基礎(chǔ)之上,這時(shí)MySQL主庫的寫壓力開始出現(xiàn)瓶頸,而數(shù)據(jù)量的持續(xù)猛增,由于MyISAM使用表鎖,在高并發(fā)下會(huì)出現(xiàn)嚴(yán)重的鎖問題,大量的高并發(fā)MySQL應(yīng)用開始使用InnoDB引擎代替MyISAM。
同時(shí),開始流行使用分表分庫來緩解寫壓力和數(shù)據(jù)增長的擴(kuò)展問題。這個(gè)時(shí)候,分表分庫成了一個(gè)熱門技術(shù),是面試的熱門問題也是業(yè)界討論的熱門技術(shù)問題。也就在這個(gè)時(shí)候,MySQL推出了還不太穩(wěn)定的表分區(qū),這也給技術(shù)實(shí)力一般的公司帶來了希望。雖然MySQL推出了MySQL Cluster集群,但性能也不能很好滿足互聯(lián)網(wǎng)的要求,只是在高可靠性上提供了非常大的保證。
五、Mysql的擴(kuò)展性瓶頸
MySQL數(shù)據(jù)庫也經(jīng)常存儲(chǔ)一些大文本字段,導(dǎo)致數(shù)據(jù)庫表非常的大,在做數(shù)據(jù)庫恢復(fù)的時(shí)候就導(dǎo)致非常的慢,不容易快速恢復(fù)數(shù)據(jù)庫。比如1000萬4KB大小的文本就接近40GB的大小,如果能把這些數(shù)據(jù)從MySQL省去,MySQL將變得非常的小。關(guān)系數(shù)據(jù)庫很強(qiáng)大,但是它并不能很好的應(yīng)付所有的應(yīng)用場景。MySQL的擴(kuò)展性差(需要復(fù)雜的技術(shù)來實(shí)現(xiàn)),大數(shù)據(jù)下IO壓力大,表結(jié)構(gòu)更改困難,正是當(dāng)前使用MySQL的開發(fā)人員面臨的問題。
六、為什么用Nosql
今天我們可以通過第三方平臺(tái)(如:Google,Facebook等)可以很容易的訪問和抓取數(shù)據(jù)。用戶的個(gè)人信息,社交網(wǎng)絡(luò),地理位置,用戶生成的數(shù)據(jù)和用戶操作日志已經(jīng)成倍的增加。我們?nèi)绻獙?duì)這些用戶數(shù)據(jù)進(jìn)行挖掘,那SQL數(shù)據(jù)庫已經(jīng)不適合這些應(yīng)用了, NoSQL數(shù)據(jù)庫的發(fā)展也卻能很好的處理這些大的數(shù)據(jù)。下面給大家看一下,web應(yīng)用數(shù)據(jù)量的增長圖:
七、Nosql是什么
NoSQL(NoSQL = Not Only SQL ),意即“不僅僅是SQL”,
泛指非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起,傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站,特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心,暴露了很多難以克服的問題,而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點(diǎn)得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重?cái)?shù)據(jù)種類帶來的挑戰(zhàn),尤其是大數(shù)據(jù)應(yīng)用難題,包括超大規(guī)模數(shù)據(jù)的存儲(chǔ)。
(例如谷歌或Facebook每天為他們的用戶收集萬億比特的數(shù)據(jù))。這些類型的數(shù)據(jù)存儲(chǔ)不需要固定的模式,無需多余操作就可以橫向擴(kuò)展。
八、Nosql的優(yōu)勢(shì)
1.易擴(kuò)展
NoSQL數(shù)據(jù)庫種類繁多,但是一個(gè)共同的特點(diǎn)都是去掉關(guān)系數(shù)據(jù)庫的關(guān)系型特性。
數(shù)據(jù)之間無關(guān)系,這樣就非常容易擴(kuò)展。也無形之間,在架構(gòu)的層面上帶來了可擴(kuò)展的能力。
2.大數(shù)據(jù)量,高性能
NoSQL數(shù)據(jù)庫都具有非常高的讀寫性能,尤其在大數(shù)據(jù)量下,同樣表現(xiàn)優(yōu)秀。
這得益于它的無關(guān)系性,數(shù)據(jù)庫的結(jié)構(gòu)簡單。一般MySQL使用Query Cache,每次表的更新Cache就失效,是一種大粒度的Cache,在針對(duì)web2.0的交互頻繁的應(yīng)用,Cache性能不高。而NoSQL的Cache是記錄級(jí)的,是一種細(xì)粒度的Cache,所以NoSQL在這個(gè)層面上來說就要性能高很多了。
3.多樣靈活的數(shù)據(jù)模型
NoSQL無需事先為要存儲(chǔ)的數(shù)據(jù)建立字段,隨時(shí)可以存儲(chǔ)自定義的數(shù)據(jù)格式。而在關(guān)系數(shù)據(jù)庫里,增刪字段是一件非常麻煩的事情。如果是非常大數(shù)據(jù)量的表,增加字段簡直就是一個(gè)噩夢(mèng)。
九、Nosql數(shù)據(jù)庫的四大分類
鍵值(Key-Value)存儲(chǔ)
列存儲(chǔ)
文檔存儲(chǔ)
圖形存儲(chǔ)
常見的有:Redis、Memcache、MongoDB,這里就不一 一 介紹了。
關(guān)系數(shù)據(jù)庫在數(shù)據(jù)庫領(lǐng)域長期占有主導(dǎo)地位,一直是高等院校數(shù)據(jù)庫課程的主要內(nèi)容。而隨著Web2.0 的興起,在海量數(shù)據(jù)的環(huán)境下,NoSQL(非關(guān)系型的數(shù)據(jù)庫) 技術(shù)得到了廣泛的應(yīng)用,它對(duì)數(shù)據(jù)庫技術(shù)的發(fā)展產(chǎn)生了強(qiáng)烈的影響,同時(shí)也對(duì)當(dāng)前數(shù)據(jù)庫課程教學(xué)產(chǎn)生了深遠(yuǎn)的影響。探討了NoSQL技術(shù)及其主要特點(diǎn),分析了NoSQL技術(shù)對(duì)數(shù)據(jù)庫教學(xué)的挑戰(zhàn),將關(guān)系數(shù)據(jù)庫和NoSQL進(jìn)行對(duì)比,指明了使用NoSQL的原因,并提出有關(guān)NoSQL的啟發(fā)式教學(xué)方法。
MongoDB和CouchDB都是面向文檔的數(shù)據(jù)庫。MongoDB和CouchDB都是開源NoSQL數(shù)據(jù)庫的最典型代表。
除了都以文檔形式存儲(chǔ)外它們沒有其他的共同點(diǎn)。MongoDB和CouchDB在數(shù)據(jù)模型實(shí)現(xiàn)、接口、對(duì)象存儲(chǔ)以及復(fù)制方法等方面有很多不同。
NewSQL是對(duì)一類現(xiàn)代關(guān)系型數(shù)據(jù)庫的統(tǒng)稱,這類數(shù)據(jù)庫對(duì)于一般的OLTP讀寫請(qǐng)求提供可橫向擴(kuò)展的性能,同時(shí)支持事務(wù)的ACID保證。這些系統(tǒng)既擁有NoSQL數(shù)據(jù)庫的擴(kuò)展性,又保持傳統(tǒng)數(shù)據(jù)庫的事務(wù)特性。NewSQL重新將“應(yīng)用程序邏輯與數(shù)據(jù)操作邏輯應(yīng)該分離”的理念帶回到現(xiàn)代數(shù)據(jù)庫的世界,這也驗(yàn)證了歷史的發(fā)展總是呈現(xiàn)出螺旋上升的形式。
在21世紀(jì)00年代中,出現(xiàn)了許多數(shù)據(jù)倉庫系統(tǒng) (如 Vertica,Greeplum 和AsterData),這些以處理OLAP 請(qǐng)求為設(shè)計(jì)目標(biāo)的系統(tǒng)并不在本文定義的NewSQL范圍內(nèi)。OLAP 數(shù)據(jù)庫更關(guān)注針對(duì)海量數(shù)據(jù)的大型、復(fù)雜、只讀的查詢,查詢時(shí)間可能持續(xù)秒級(jí)、分鐘級(jí)甚至更長。
NoSQL的擁躉普遍認(rèn)為阻礙傳統(tǒng)數(shù)據(jù)庫橫向擴(kuò)容、提高可用性的原因在于ACID保證和關(guān)系模型,因此NoSQL運(yùn)動(dòng)的核心就是放棄事務(wù)強(qiáng)一致性以及關(guān)系模型,擁抱最終一致性和其它數(shù)據(jù)模型?(如 key/value,graphs 和Documents)。
兩個(gè)最著名的NoSQL數(shù)據(jù)庫就是Google的BigTable和Amazon的Dynamo,由于二者都未開源,其它組織就開始推出類似的開源替代項(xiàng)目,包括Facebook的 Cassandra (基于BigTable和Dynamo)、PowerSet的 Hbase(基于BigTable)。有一些創(chuàng)業(yè)公司也加入到這場NoSQL運(yùn)動(dòng)中,它們不一定是受BigTable和Dynamo的啟發(fā),但都響應(yīng)了NoSQL的哲學(xué),其中最出名的就是MongoDB。
在21世紀(jì)00年代末,市面上已經(jīng)有許多供用戶選擇的分布式數(shù)據(jù)庫產(chǎn)品。使用NoSQL的優(yōu)勢(shì)在于應(yīng)用開發(fā)者可以更關(guān)注應(yīng)用邏輯本身,而非數(shù)據(jù)庫的擴(kuò)展性問題;但與此同時(shí)許多應(yīng)用,如金融系統(tǒng)、訂單處理系統(tǒng),由于無法放棄事務(wù)的一致性要求被拒之門外。
一些組織,如Google,已經(jīng)發(fā)現(xiàn)他們的許多工程師將過多的精力放在處理數(shù)據(jù)一致性上,這既暴露了數(shù)據(jù)庫的抽象、又提高了代碼的復(fù)雜度,這時(shí)候要么選擇回到傳統(tǒng)DBMS時(shí)代,用更高的機(jī)器配置縱向擴(kuò)容,要么選擇回到中間件時(shí)代,開發(fā)支持分布式事務(wù)的中間件。這兩種方案成本都很高,于是NewSQL運(yùn)動(dòng)開始醞釀。
NewSQL數(shù)據(jù)庫設(shè)計(jì)針對(duì)的讀寫事務(wù)有以下特點(diǎn):
1、耗時(shí)短。
2、使用索引查詢,涉及少量數(shù)據(jù)。
3、重復(fù)度高,通常使用相同的查詢語句和不同的查詢參考。
也有一些學(xué)者認(rèn)為NewSQL系統(tǒng)是特指實(shí)現(xiàn)上使用Lock-free并發(fā)控制技術(shù)和share-nothing架構(gòu)的數(shù)據(jù)庫。所有我們認(rèn)為是NewSQL的數(shù)據(jù)庫系統(tǒng)確實(shí)都有這樣的特點(diǎn)。
個(gè)人不認(rèn)為nosql在少量數(shù)據(jù)存儲(chǔ)上有啥優(yōu)勢(shì)。nosql主要解決的是auto sharding的問題,你不需要sharding,搞啥nosql. 作者:方圓 鏈接:
noSQL,泛指非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起,傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站,特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心,暴露了很多難以克服的問題,而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點(diǎn)得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重?cái)?shù)據(jù)種類帶來的挑戰(zhàn),尤其是大數(shù)據(jù)應(yīng)用難題。itjoB