1 為什么用 NoSQL？
- 單機 MySQL 的美好時代
在90年代，一個網站的訪問量一般都不大，用單個數據庫完全可以輕松應付。
在那個時候，更多的都是靜態網頁，動態交互類型的網站不多。
上述架構下，我們來看看數據存儲的瓶頸是什么？
DAL : Data Access Layer（數據訪問層 – Hibernate，MyBatis）
數據量的總大小一個機器放不下時。
數據的索引（B+ Tree）一個機器的內存放不下時。
訪問量(讀寫混合)一個實例不能承受。
如果滿足了上述1 or 3個時，只能對數據庫的整體架構進行重構。
- Memcached(緩存)+MySQL+垂直拆分
后來，隨着訪問量的上升，幾乎大部分使用MySQL架構的網站在數據庫上都開始出現了性能問題，web程序不再僅僅專注在功能上，同時也在追求性能。程序員們開始大量的使用緩存技術來緩解數據庫的壓力，優化數據庫的結構和索引。開始比較流行的是通過文件緩存來緩解數據庫壓力，但是當訪問量繼續增大的時候，多台web機器通過文件緩存不能共享，大量的小文件緩存也帶了了比較高的IO壓力。在這個時候，Memcached就自然的成為一個非常時尚的技術產品。
Memcached作為一個獨立的分布式的緩存服務器，為多個web服務器提供了一個共享的高性能緩存服務，在Memcached服務器上，又發展了根據hash算法來進行多台Memcached緩存服務的擴展，然后又出現了一致性hash來解決增加或減少緩存服務器導致重新hash帶來的大量緩存失效的弊端。
- Mysql主從讀寫分離
由於數據庫的寫入壓力增加，Memcached只能緩解數據庫的讀取壓力。讀寫集中在一個數據庫上讓數據庫不堪重負，大部分網站開始使用主從復制技術來達到讀寫分離，以提高讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成為這個時候的網站標配了。
- 分庫分表+水平拆分+mysql集群
在Memcached的高速緩存，MySQL的主從復制，讀寫分離的基礎之上，這時MySQL主庫的寫壓力開始出現瓶頸，而數據量的持續猛增，由於MyISAM在寫數據的時候會使用表鎖，在高並發寫數據的情況下會出現嚴重的鎖問題，大量的高並發MySQL應用開始使用InnoDB引擎代替MyISAM。
ps：這就是為什么 MySQL 在 5.6 版本之后使用 InnoDB 做為默認存儲引擎的原因 – MyISAM 寫會鎖表，InnoDB 有行鎖，發生沖突的幾率低，並發性能高。
同時，開始流行使用分表分庫來緩解寫壓力和數據增長的擴展問題。這個時候，分表分庫成了一個熱門技術，是面試的熱門問題也是業界討論的熱門技術問題。也就在這個時候，MySQL推出了還不太穩定的表分區，這也給技術實力一般的公司帶來了希望。雖然MySQL推出了MySQL Cluster集群，但性能也不能很好滿足互聯網的要求，只是在高可靠性上提供了非常大的保證。
- MySQL的擴展性瓶頸
MySQL數據庫也經常存儲一些大文本字段，導致數據庫表非常的大，在做數據庫恢復的時候就導致非常的慢，不容易快速恢復數據庫。比如1000萬4KB大小的文本就接近40GB的大小，如果能把這些數據從MySQL省去，MySQL將變得非常的小。關系數據庫很強大，但是它並不能很好的應付所有的應用場景。MySQL的擴展性差（需要復雜的技術來實現），大數據下IO壓力大，表結構更改困難，正是當前使用MySQL的開發人員面臨的問題。
- 今天是什么樣子？
最前面的是企業級防火牆，后面通過負載均衡主機（軟負載：Nginx，硬負載：F5）在 web 服務器集群之間進行調度，再由具體的 web 服務器（Tomcat）去訪問緩存，訪問數據庫。
- 為什么用NoSQL?
今天我們可以通過第三方平台（如：Google,Facebook等）可以很容易的訪問和抓取數據。用戶的個人信息，社交網絡，地理位置，用戶生成的數據和用戶操作日志已經成倍的增加。我們如果要對這些用戶數據進行挖掘，那SQL數據庫已經不適合這些應用了, NoSQL數據庫的發展也卻能很好的處理這些大的數據。
2. 什么是NoSQL？
- NoSQL 概述
NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，
泛指非關系型的數據庫。隨着互聯網web2.0網站的興起，傳統的關系數據庫在應付web2.0網站，特別是超大規模和高並發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題，而非關系型的數據庫則由於其本身的特點得到了非常迅速的發展。NoSQL數據庫的產生就是為了解決大規模數據集合多重數據種類帶來的挑戰，尤其是大數據應用難題，包括超大規模數據的存儲。
（例如谷歌或Facebook每天為他們的用戶收集萬億比特的數據）。這些類型的數據存儲不需要固定的模式，無需多余操作就可以橫向擴展。
- NoSQL代表
MongDB、 Redis、Memcache
3. 關系型數據庫與NoSQL的區別？
- RDBMS
高度組織化結構化數據
結構化查詢語言（SQL）
數據和關系都存儲在單獨的表中。
數據操縱語言，數據定義語言
嚴格的一致性
基礎事務
ACID
關系型數據庫遵循ACID規則
事務在英文中是transaction，和現實世界中的交易很類似，它有如下四個特性：
A (Atomicity) 原子性
原子性很容易理解，也就是說事務里的所有操作要么全部做完，要么都不做，事務成功的條件是事務里的所有操作都成功，只要有一個操作失敗，整個事務就失敗，需要回滾。比如銀行轉賬，從A賬戶轉100元至B賬戶，分為兩個步驟：1）從A賬戶取100元；2）存入100元至B賬戶。這兩步要么一起完成，要么一起不完成，如果只完成第一步，第二步失敗，錢會莫名其妙少了100元。
C (Consistency) 一致性
一致性也比較容易理解，也就是說數據庫要一直處於一致的狀態，事務的運行不會改變數據庫原本的一致性約束。
I (Isolation) 獨立性
所謂的獨立性是指並發的事務之間不會互相影響，如果一個事務要訪問的數據正在被另外一個事務修改，只要另外一個事務未提交，它所訪問的數據就不受未提交事務的影響。比如現有有個交易是從A賬戶轉100元至B賬戶，在這個交易還未完成的情況下，如果此時B查詢自己的賬戶，是看不到新增加的100元的
D (Durability) 持久性
持久性是指一旦事務提交后，它所做的修改將會永久的保存在數據庫上，即使出現宕機也不會丟失。
- NoSQL
代表着不僅僅是SQL
沒有聲明性查詢語言
沒有預定義的模式
鍵 - 值對存儲，列存儲，文檔存儲，圖形數據庫
最終一致性，而非ACID屬性
非結構化和不可預知的數據
CAP定理
高性能，高可用性和可伸縮性
分布式數據庫中的CAP原理(了解)
CAP定理：
Consistency(一致性), 數據一致更新，所有數據變動都是同步的
Availability(可用性), 好的響應性能
Partition tolerance(分區容錯性) 可靠性
P: 系統中任意信息的丟失或失敗不會影響系統的繼續運作。
定理：任何分布式系統只可同時滿足二點，沒法三者兼顧。
CAP理論的核心是：一個分布式系統不可能同時很好的滿足一致性，可用性和分區容錯性這三個需求，
因此，根據 CAP 原理將 NoSQL 數據庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類：
CA - 單點集群，滿足一致性，可用性的系統，通常在可擴展性上不太強大。
CP - 滿足一致性，分區容忍性的系統，通常性能不是特別高。
AP - 滿足可用性，分區容忍性的系統，通常可能對一致性要求低一些。
CAP理論就是說在分布式存儲系統中，最多只能實現上面的兩點。
而由於當前的網絡硬件肯定會出現延遲丟包等問題，所以分區容忍性是我們必須需要實現的。
所以我們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。
說明：C：強一致性 A：高可用性 P：分布式容忍性
舉例：
CA：傳統Oracle數據庫
AP：大多數網站架構的選擇
CP：Redis、Mongodb
注意：分布式架構的時候必須做出取舍。
一致性和可用性之間取一個平衡。多余大多數web應用，其實並不需要強一致性。
因此犧牲C換取P，這是目前分布式數據庫產品的方向。
4. 當下NoSQL的經典應用
當下的應用是 SQL 與 NoSQL 一起使用的。
代表項目：阿里巴巴商品信息的存放。
去 IOE 化。
ps：I 是指 IBM 的小型機，很貴的，好像好幾萬一台；O 是指 Oracle 數據庫，也很貴的，好幾萬呢；M 是指 EMC 的存儲設備，也很貴的。
難點：
數據類型多樣性。
數據源多樣性和變化重構。
數據源改造而服務平台不需要大面積重構。
————————————————
版權聲明：本文為CSDN博主「曲健磊」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/a909301740/java/article/details/80149552