NoSQL

NoSQL
1 SQL
結構化的查詢語言。SQL常常會用在咱們的關係型數據庫中（mysql/oracle/sql server/db2）。譬如咱們以前使用的DDL/DML/DQL/DCL..
2 爲何要學習NOSQL
非結構化的查詢語言。NOSQL常常會用在咱們的非關係型的數據中。
談一談這個東西 「互聯網」。
特色： 多樣化、數據量激增、實時變化、……………….
在這樣子的一種互聯網的背景下，對於咱們的軟件來說，它要求咱們軟件具備 高併發。多樣性，還要可以進行海量的數據處理。這個時候咱們就要思考咱們的項目，具不具有高併發，多樣性，還有海量的數據庫處理能力? 若是咱們的項目不知足當中的需求，這個時候咱們就要優化或者重構咱們的項目的架構。
咱們就必須瞭解咱們的互聯網的機構：
阿里巴巴第一代產品，他的項目架構LAMP(Linux + Apache + Mybatis +PHP)

2.1 單一的msql數據庫
瞭解下當前咱們項目的架構：

分析一下：
優勢： 方便，搭建容易。
缺點： 1.倉庫的容器有限。2.數據的總量在不斷的增長，那麼一臺數據庫很明顯不能知足咱們需求。3.這個數據咱們既能夠讀，也能夠寫。這個時候對數據庫的讀寫性能有要求了。
4.當倉庫中的數據量比較多狀況下，對數據庫中的數據進行分類存放。分類存放以後，爲了方便別人去快速的讀取咱們的數據。這個時候咱們的數據庫一般會建立索引（B+TREE）,方便查詢的速度，問題是，你建立了索引拿你就要開闢空間來保存索引，自己空間就有限。你還要對索引進行維護，也要消耗咱們數據庫的性能。
總結：咱們上面的這種架構只能說是「自娛自樂」。知足不了大併發，多樣性，海量數據的需求。
2.2 Memcached(緩存) + mysql + 垂直拆分
隨着咱們數據量的不斷的增長，咱們全部的上面架構的網站，都會開始出現性能降低的問題。
爲了改善當前的狀態，提高系統的性能。程序員就開始思索，我能不能不把全部的數據都放在數據庫中，或者，我能不能把不常常發生改變的數據，第一次從數據庫中取出來以後，我就放入到一個文件中。第二次在去訪問的時候，咱們就直接從文件中去取數據，這樣子一來，數據庫的性能就有必定的改善。

可是呢這種架構存在問題。文件不能進行共享

咱們就要想辦法讓文件中的數據進行數據的共享。會使用一個分佈式的緩存框架，這個緩存框架就叫作memechached./ehcache

我全部的數據都保存到了一個數據庫中，因此數據庫的存儲壓力很是的大，這個時候咱們就能夠進行垂直拆分，咱們對數據庫進行拆分。譬如咱們電子商務網站，按照咱們業務模塊分析，能夠分紅咱們賣家和買家，也能夠分紅咱們的商品，訂單，支付，庫存….等等模塊。
咱們就把之前全部的信息都保存到一個數據庫中，如今我把這個數據庫拆分紅買家庫和買家庫，和商品庫，訂單庫，支付庫……………

2.3 Mysql的主從複製和讀寫分離
隨着咱們數據量爆炸式的增，譬如咱們雙十一的那一天，咱們系統的併發量很是的大，賣家庫承受的鴨梨很是大。這個時候爲了緩解咱們賣家庫的壓力，所以咱們能夠採用主從複製，讀寫分離這樣子的一種思想。
咱們發現買家庫既要讀數據也要寫數據，所以它的性能會受到必定影響，所以咱們爲了解決這樣子的一個問題。咱們就新增兩個數據庫，如今總共有買家庫有了三個，一個主庫，和二個從庫，主庫負責寫數據，從庫負責讀數據。這就是，讀寫分離。。。。

總結一下，爲何至少要兩個從庫。兩個從庫的目的是若是，有一個從庫宕機，另一個從庫還能用。若是個人主庫也宕機了。這個時候還能寫嗎？爲了系統容災備份。保證數據的完整性，以及緩存數據的一致性。

爲了保持數據的一致性，所以咱們就採用了另外的一種方案。叫作主從複製。。

2.4 分庫分表+水平拆分+mysql集羣
雙十一那一天，數據庫很是很是的大，在同一秒中，數據的併發可能會達到幾萬甚至是十幾萬此，很明顯，若是咱們採用上面這種架構的化，仍是不能知足咱們學習，那麼這個時候，咱們又要改善咱們數據庫這一塊的架構。一個知足不了咱們的需求，咱們搞一羣這樣子的東西來知足咱們需求，咱們就稱之爲mysql的集羣。

分表指的是，咱們知道表是數據庫中用來保存數據的地方。表自生有容量大小，一般狀況下，若是表中的數據達到了500萬行數據的化，這個表就已經很大了。這個時候咱們在用select 去查詢數據庫，會要等待很長的時間。因此咱們一般在作設計的時候譬如咱們1億條用戶數據的話。之前咱們把這1億3條數據都保存到了用戶表中，這個時候你要從這裏面查詢zhangsan這個用戶話，時間很是的長。這個時候咱們一般會這樣子作：咱們就作三個表，分別是user1,user2,user3 而後user1保存索引爲0 到3千萬的數據 user1就保存3千萬到6千萬的數據，user3就保存6千萬到咱們1億的數據，這個時候我要查詢時候，你譬如我要查詢索引爲2千萬，這個時候咱們就去user1這個表中去查詢數據。也就是說，user1,user2,user3這三個表能夠在同一個庫中，也可能不在同一個庫中。
分析這樣子的一個問題：
主庫在複製數據到從庫的過程，這個時候有人從，從庫去讀取數據，這個時候會不會形成數據的不一致的問題？
譬如早期的數據採用的myISAM這樣子的數據庫引擎，而這樣子的數據庫的引擎，它採用的是表鎖的概念。主庫在複製數據到表中的時候，它會給這個表上一把鎖。別人就讀不了了。可是這樣子作效率是不高。
後期爲了提高數據庫本省的效率，後面數據庫的引擎變成INNODB引擎，而這個引擎採用的是行鎖，行鎖一般之鎖定一行數據。
結論:能不能避免數據的徹底一致，不能。只能作到相對一致。
2.5 Mysql數據的瓶頸
咱們知道mysql是關係型的數據庫，它採用的是sql（結構化的查詢語言）來進行數據庫的操做。你譬如說建立一個庫，建立一張表。你譬如說建立一個庫，用來保存學生信息的話，咱們常常會在這個庫中，建立一個學生表（students）來保存學生的信息。
可是若是說，遇到下面的場景。譬如咱們要求你保存 視頻信息，和大文本信息到數據到數據庫。若是說數據庫保存了1000部小說，1000部電影。而後咱們在執行select .確定會卡死或者說等待至關長的時間。若是們能有一個保存視頻，大文本的數據，問題也解決了。
遇到下面的場景：要你設計一套數據庫用來描述大家生物機電院系關係。第一個設計不容器把，即便設計出來，查詢也很複雜。我解決這個問題，最好的方法是否是就是畫圖。若是咱們有保存這種圖型的數據問題不就解決了。

場景：咱們電商網站中，常常有用戶，商品，訂單詳情，訂單。這樣子的四張表、
我要描述，某一個用戶下了那些訂單，每一個訂單上面有那些商品。設計到四張表的鏈表查詢。若是併發量很是很是大的時候，10000個用戶通是完成上述操做的話，效率很是的低。數據庫的性能也很是的低。
若是咱們這樣子實現這樣子的一種格式或者說，咱們能從數據庫中，讀取這種格式的數據，咱們問題不就解決了。
{
Username: ‘李科’,
Age: ‘19’,
Sex: ‘男’，
Orders：[
{
orderId: ‘001’,
ordertime: ‘2020-04-20’,
product: [
{
productid: 1
name: ‘籃球’,
price: 30,
num: 1
}
]
}
]
}
總結一下，咱們剛剛所說的幾個場景，很明顯，關係型的數據庫，不能解決上面的問題。
因此爲了解決上面的問題，咱們就引入非關係型數據庫的學習。因此咱們爲了解決上面的問題，咱們就要學習NOSQL數據庫。
做業：
http://try.redis.io/ 這是在線的工具
http://www.redis.cn/ 中文網址