1 單機(jī)MySQL的美好年代
在90年代，一個(gè)網(wǎng)站的訪問量一般都不大否灾，用單個(gè)數(shù)據(jù)庫完全可以輕松應(yīng)付卖擅。
在那個(gè)時(shí)候，更多的都是靜態(tài)網(wǎng)頁墨技，動態(tài)交互類型的網(wǎng)站不多惩阶。
上述架構(gòu)下，我們來看看數(shù)據(jù)存儲的瓶頸是什么扣汪？
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)化......
2 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í)候响牛，多臺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)行多臺Memcached緩存服務(wù)的擴(kuò)展，然后又出現(xiàn)了一致性hash來解決增加或減少緩存服務(wù)器導(dǎo)致重新hash帶來的大量緩存失效的弊端
3 Mysql主從讀寫分離
由于數(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)配了。
4 分表分庫+水平拆分+mysql集群
在Memcached的高速緩存暮屡，MySQL的主從復(fù)制撤摸，讀寫分離的基礎(chǔ)之上，這時(shí)MySQL主庫的寫壓力開始出現(xiàn)瓶頸褒纲，而數(shù)據(jù)量的持續(xù)猛增准夷，由于MyISAM使用表鎖，在高并發(fā)下會出現(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)的要求，只是在高可靠性上提供了非常大的保證留夜。
5 MySQL的擴(kuò)展性瓶頸
MySQL數(shù)據(jù)庫也經(jīng)常存儲一些大文本字段匙铡，導(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ā)人員面臨的問題掘猿。
6 今天是什么樣子？唇跨？
7 為什么使用NoSQL ?
今天我們可以通過第三方平臺（如：Google,Facebook等）可以很容易的訪問和抓取數(shù)據(jù)稠通。用戶的個(gè)人信息，社交網(wǎng)絡(luò)买猖，地理位置改橘，用戶生成的數(shù)據(jù)和用戶操作日志已經(jīng)成倍的增加。我們?nèi)绻獙@些用戶數(shù)據(jù)進(jìn)行挖掘玉控，那SQL數(shù)據(jù)庫已經(jīng)不適合這些應(yīng)用了, NoSQL數(shù)據(jù)庫的發(fā)展也卻能很好的處理這些大的數(shù)據(jù)飞主。
8 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純動態(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ù)的存儲惠呼。
（例如谷歌或Facebook每天為他們的用戶收集萬億比特的數(shù)據(jù)）佩番。這些類型的數(shù)據(jù)存儲不需要固定的模式，無需多余操作就可以橫向擴(kuò)展罢杉。
9 NoSQL的用處
a) 易擴(kuò)展
NoSQL數(shù)據(jù)庫種類繁多趟畏，但是一個(gè)共同的特點(diǎn)都是去掉關(guān)系數(shù)據(jù)庫的關(guān)系型特性。
數(shù)據(jù)之間無關(guān)系滩租，這樣就非常容易擴(kuò)展赋秀。也無形之間利朵，在架構(gòu)的層面上帶來了可擴(kuò)展的能力。
b) 大數(shù)據(jù)量高性能
NoSQL數(shù)據(jù)庫都具有非常高的讀寫性能猎莲，尤其在大數(shù)據(jù)量下绍弟，同樣表現(xiàn)優(yōu)秀。
這得益于它的無關(guān)系性著洼，數(shù)據(jù)庫的結(jié)構(gòu)簡單樟遣。
一般MySQL使用Query Cache，每次表的更新Cache就失效身笤，是一種大粒度的Cache豹悬，
在針對web2.0的交互頻繁的應(yīng)用，Cache性能不高液荸。而NoSQL的Cache是記錄級的瞻佛，
是一種細(xì)粒度的Cache，所以NoSQL在這個(gè)層面上來說就要性能高很多了
c) 多樣靈活的數(shù)據(jù)模型
NoSQL無需事先為要存儲的數(shù)據(jù)建立字段娇钱，隨時(shí)可以存儲自定義的數(shù)據(jù)格式伤柄。而在關(guān)系數(shù)據(jù)庫里，
增刪字段是一件非常麻煩的事情文搂。如果是非常大數(shù)據(jù)量的表适刀，增加字段簡直就是一個(gè)噩夢
d) RDBMS(傳統(tǒng)型數(shù)據(jù)庫) vs NoSQL
RDBMS(傳統(tǒng)型數(shù)據(jù)庫)
- 高度組織化結(jié)構(gòu)化數(shù)據(jù)
- 結(jié)構(gòu)化查詢語言（SQL）
- 數(shù)據(jù)和關(guān)系都存儲在單獨(dú)的表中。
- 數(shù)據(jù)操縱語言煤蹭，數(shù)據(jù)定義語言
- 嚴(yán)格的一致性
- 基礎(chǔ)事務(wù)
NoSQL
- 代表著不僅僅是SQL
- 沒有聲明性查詢語言
- 沒有預(yù)定義的模式
- 鍵 - 值對存儲蔗彤，列存儲，文檔存儲疯兼，圖形數(shù)據(jù)庫
- 最終一致性然遏，而非ACID屬性
- 非結(jié)構(gòu)化和不可預(yù)知的數(shù)據(jù)
- CAP定理
- 高性能，高可用性和可伸縮性
