NoSQL太火,冒出太多產(chǎn)品了,保守估計(jì)也成百上千了。
創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設(shè),石阡企業(yè)網(wǎng)站建設(shè),石阡品牌網(wǎng)站建設(shè),網(wǎng)站定制,石阡網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,石阡網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè),幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭力??沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿,時(shí)刻以成就客戶成長自我,堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己,讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。
互聯(lián)網(wǎng)公司常用的基本集中在以下幾種,每種只舉一個(gè)比較常見或者應(yīng)用比較成功的例子吧。
1. In-Memory KV Store : Redis
in memory key-value store,同時(shí)提供了更加豐富的數(shù)據(jù)結(jié)構(gòu)和運(yùn)算的能力,成功用法是替代memcached,通過checkpoint和commit log提供了快速的宕機(jī)恢復(fù),同時(shí)支持replication提供讀可擴(kuò)展和高可用。
2. Disk-Based KV Store: Leveldb
真正基于磁盤的key-value storage, 模型單一簡單,數(shù)據(jù)量不受限于內(nèi)存大小,數(shù)據(jù)落盤高可靠,Google的幾位大神出品的精品,LSM模型天然寫優(yōu)化,順序?qū)懕P的方式對(duì)于新硬件ssd再適合不過了,不足是僅提供了一個(gè)庫,需要自己封裝server端。
3. Document Store: Mongodb
分布式nosql,具備了區(qū)別mysql的最大亮點(diǎn):可擴(kuò)展性。mongodb 最新引人的莫過于提供了sql接口,是目前nosql里最像mysql的,只是沒有ACID的特性,發(fā)展很快,支持了索引等特性,上手容易,對(duì)于數(shù)據(jù)量遠(yuǎn)超內(nèi)存限制的場(chǎng)景來說,還需要慎重。
4. Column Table Store: HBase
這個(gè)富二代似乎不用贅述了,最大的優(yōu)勢(shì)是開源,對(duì)于普通的scan和基于行的get等基本查詢,性能完全不是問題,只是只提供裸的api,易用性上是短板,可擴(kuò)展性方面是最強(qiáng)的,其次坐上了Hadoop的快車,社區(qū)發(fā)展很快,各種基于其上的開源產(chǎn)品不少,來解決諸如join、聚集運(yùn)算等復(fù)雜查詢。
對(duì)此,前Google工程師,Milo(本地商店搜索引擎)創(chuàng)始人Ted Dziuba最近發(fā)表標(biāo)題驚人的博客“I Can't Wait for NoSQL to Die”,對(duì)NoSQL的適用范圍進(jìn)行了分析。他認(rèn)為, NoSQL也會(huì)帶來一連串的新問題,并不會(huì)成為主流,無法取代關(guān)系型數(shù)據(jù)庫。 他的理由是:Cassandra等NoSQL數(shù)據(jù)庫在使用上并不方便,比如,修改column family定義時(shí)就需要重啟。而且NoSQL更適合Google那樣的規(guī)模,而一般的互聯(lián)網(wǎng)公司都不是Google,早早地去考慮Google那樣的規(guī)模的可擴(kuò)展性,純粹是浪費(fèi)時(shí)間,存在巨大的商業(yè)風(fēng)險(xiǎn)。 他還透露,即使在Google,AdWords這樣的關(guān)鍵產(chǎn)品也是基于MySQL實(shí)現(xiàn)的。 他在文中最后表示,NoSQL當(dāng)然死不了,但是 它最終會(huì)被邊緣化,就像Rails被NoSQL邊緣化一樣 Dziuba的文章因?yàn)檠赞o激烈,在社區(qū)里引起了強(qiáng)烈反應(yīng)。 SQL數(shù)據(jù)庫陣營贊同者大有人在。craigslist工程師、著名的MySQL專家Jeremy Zawodny表示,在讀此文的時(shí)候,不時(shí)會(huì)心一笑。他說, NoSQL運(yùn)動(dòng)只是軟件不斷進(jìn)化進(jìn)程中的正?,F(xiàn)象 。關(guān)系型數(shù)據(jù)庫也會(huì)繼續(xù)發(fā)展,MySQL社區(qū)不斷推出的XtraDB或InnoDB插件, PBXT, Drizzle都是證據(jù)。各種技術(shù)競(jìng)爭的結(jié)果是,我們獲得了更多解決問題的選擇。 drizzle項(xiàng)目開發(fā)者Eric Day也表示,NoSQL有很多值得學(xué)習(xí)的,但是目前大部分實(shí)際項(xiàng)目的最佳選擇還是關(guān)系型數(shù)據(jù)庫。 NoSQL陣營當(dāng)然不會(huì)坐視不理,Cassandra項(xiàng)目組的Eric Evans表示,Dziuba提到Cassandra修改column family定義的問題其實(shí)很容易解決。而且,NoSQL并不是要取代MySQL,事實(shí)上Twitter仍然在用MySQL。如果關(guān)系型數(shù)據(jù)庫能夠承擔(dān)負(fù)荷,那就用好了;如果不行,請(qǐng)考慮NoSQL。 而德國知名博客Code Monkeyism則嘲笑Dziuba看起來并沒有用MySQL做過真實(shí)項(xiàng)目,因?yàn)镸ySQL如果沒有memcache,基本上無法應(yīng)付網(wǎng)站項(xiàng)目。他認(rèn)為,NoSQL將使SQL數(shù)據(jù)庫邊緣化,而且一個(gè)重要理由恰恰是可以節(jié)省DBA的開銷。 digg的前任首席架構(gòu)師現(xiàn)在也在創(chuàng)業(yè)的Joe Stump說,自己現(xiàn)在的創(chuàng)業(yè)項(xiàng)目就是用NoSQL,而且列舉了一系列問題挑戰(zhàn)SQL陣營。
NoSQL泛指非關(guān)系型數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)行業(yè)的興起與發(fā)展,傳統(tǒng)的數(shù)據(jù)庫結(jié)構(gòu)已經(jīng)很難適應(yīng)大規(guī)模數(shù)據(jù)、非結(jié)構(gòu)性數(shù)據(jù)帶來的挑戰(zhàn),也就是現(xiàn)在大數(shù)據(jù)行業(yè)的發(fā)展對(duì)傳統(tǒng)的數(shù)據(jù)庫發(fā)出了挑戰(zhàn),而為了應(yīng)對(duì)大規(guī)模的非結(jié)構(gòu)性數(shù)據(jù)的處理,非關(guān)系型數(shù)據(jù)庫才會(huì)在計(jì)算機(jī)、軟件、數(shù)據(jù)庫等方面得到飛速的發(fā)展。
本文將從單機(jī)MySQL的場(chǎng)景出發(fā),簡述一下隨著網(wǎng)站的訪問量越來越大,數(shù)據(jù)庫部署的演進(jìn)過程,到為什么要用MySQL的必要性。
大數(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)用場(chǎ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,這里就不一 一 介紹了。