NoSQL入門概述（一）
作者 ： Stanley 羅昊
【轉載請注明出處和署名，謝謝！】
什么是NoSQL
NoSQL(NoSQL - Not Only SQL),意“不僅僅是SQL”；
泛指非關系型的數據庫；
隨着互聯網web2.0網站的興起，傳統的關系數據庫在應對web2.0網站，特別是超大規模和高並發的SNS類型的web2.0純動態網站以及顯得力不從心，暴露了很多難以克服的問題，而非關系型的數據庫則由於其本身的特點得到了非常迅速的發展；
NoSQL數據庫的產生就是為了解決大規模數據集合，多重復數據種類帶來的挑戰，尤其是大數據應用難題，包括大規模數據的存儲。
（例如谷歌或Facebook每天為澳門的用戶手機萬億比特的數據），這些類型的數據存儲不需要固定的模式，無需多余操作就可以橫向擴展；
為什么用NoSQL
在最早的項目研發時期，是單機MySQL的美好年代，無非就是三層架構，dao層直接訪問數據庫獲取數據后響應給客戶即可，非常簡單；
但是隨着時代的改變，以及互聯網用戶越來越多，大規模的互聯網公司興起，數據量急劇增加，再用最早的開發模式，已經完全滿足不了現在時代的需求了；
所以就nosql（非關系型數據庫）橫空出世，來解決大數據量情況下提高數據庫讀取效率，從而提升系統性能以及客戶體驗；
在早期的系統，dao層直接訪問數據庫獲取數據，但是現在時代的變遷，這樣的方式在數據量大的情況下，效率非常非常的查，你無論怎么優化都是徒勞；
nosql出現后，猶如在數據庫前面加了一堵牆，dao層先訪問Redis，Redis再訪問數據庫；
數據庫讀出來的數據先存入Redis，獲取數據的時候，直接從Redis中獲取即可，不用再通過數據庫從內存中讀寫；
今天我們可以通過第三方平台（如：Google,Facebook等）可以很容易的訪問和抓取數據，用戶的個人信息，社交網絡，地理位置，用戶產生的數據和用戶操作日志以及成倍的增加；
我們如果要對這些用戶數據進行挖掘，MySQL數據庫以及不合適這些應用了，NoSQL數據庫發展卻能很好的出列這些大數據；
單機MySQL的美好年代
在最早的javaweb開發應用程序中，無非就是JSP跳JSP，一個JSP處理用戶並且響應，另外一個JSP發出請求，請求別的JSP，再往后，JSP跳Serclet，Serclet掉業務邏輯層的方法，業務邏輯掉數據訪問層，數據訪問層去請求數據庫發起事物；
在90年代，一個網站的訪問量都不大，用單個數據庫完全可以輕松應付；
在那個時候，更多的都是靜態網頁，動態交互類型的網站不多；
在那個時候程序的划分也非常簡單：
隨着時代的變遷，數據的總量總有一天會撐破這個機器，數據庫讀取也就是查詢效率講會變得非常非常低；
建立索引也是會占用磁盤空間的，數據量越大，你索引越多，時間久了機器就是受不了你這樣折騰了；
還有一個訪問量（讀寫混合）一個數據庫是受不了的，你讀取跟插入數據都是在同一個數據庫，這樣數據庫也是承受不了的（數據量大的情況下）；
所以，問題已經列出來了，我們就要解決，要去優化這些問題，提高性能；
在以上這種開發模式，數據量在小於1w是可以滿足的，自己用用，或訪問量不大的情況下是沒有問題的，自己做練習什么的都可以，但是進入企業，就不可以再這么用了；
Redis（緩存）+MySQL+垂直拆分
隨着數據量大，讀寫都是在同一台機器上，扛不住了以后呢，項目架構也就進行了改變：
跟上一張圖標對比，是只有一個MySQL數據庫，並且現在我們還在MySQL前面檔了一層Cache（這里理解成Redis【緩存】）,換句話說，之前是DAO層直接去訪問數據庫，現在DAO層直接去Redis里面；
是不是有點像替數據庫擋了一層，大家都指定，對數據庫傷害比較大的就是頻繁的查詢，如果頻繁查詢的剛好還是一些固定的順序，我們是不是可以把他摘出來放到緩存里面（Redis）；
mysql還有一個垂直拆分，言下之意就是，你一個數據裝不住了，你拆開了以后，例如，買家跟賣家被分成兩個庫，這樣的話，數據庫的壓力就被分擔了一些；
MySQL主從讀寫分離
舉個例子，現在是一台機器一個數據庫，我現在要求一台機器變成五個數據庫，那么，其中的一台數據庫作為主庫，另外四台作為從庫，我插入一條數據是給主庫，主庫這個時候需要同步另外四個從庫，比如我主庫里面有 a b c，這個時候我向里面查一個d，這個時候主庫就需要向另外四個從庫也添加一個d來保持同步；
也可以理解為主從復制，主表里面有什么東西，我從表需要迅速的復制粘貼進來；
讀寫分離，顧名思義，讀就是查詢，寫就是增 刪 改，在我們自己做練習的時候，增刪改查一直都是同一台機器或同一個數據庫，但是在實際開發當中，這種情況是不允許的，因為非常影響效率；
所以又有一個數據庫是只做查詢，另外一個數據庫是只做增 刪 改，這就是讀寫分離，所以就造成了下面這張圖：
由於數據庫的寫入壓力增加，Redis只能緩解數據庫的讀取壓力，讀寫集中在一個數據庫上讓數據庫不堪重負，大部分網站開始使用主從賦值技術來達到讀寫分離，提高讀寫性能和讀庫的可擴展性；
之前是光在mysql前面檔了一個緩存，現在，在緩存背后又出現了數據庫的拆分，變成了讀寫分離了，M代表主表，S代表從表；
什么概念呢？
就是，對於一個數據庫的信息，寫的操作都放到M（主）庫了，讀的操作都去從庫去度，這樣的話，存載的數據被分割以后，就可以大大的緩解數據庫的壓力；
分庫分表+水平拆分+mysql集群
經過前幾次的拆分，改變，讀寫分離，往后發現又扛不住了，這個時候，集群就出來了；
在Redis的高速緩存，MySQL的主從復制，讀寫分離的基礎上，這時，MySQL主庫的讀寫壓力開始出現瓶頸，而數據量的持續猛增，由於MyISAM使用表鎖，在高並發下會出現嚴重的鎖問題，大量的高並發MySQL應用開始使用InnoDB引擎代替MyISAM；
同時，開始流行使用分表分庫來緩解寫壓力和數據庫增長的擴展問題，這個時候，分表分庫就成了一個熱門的技術，是面試的熱門問題也是業界討論的熱門技術問題；
也就是在這個時候MySQL推出了還不太穩定的表分區，這也給技術實力一般的公司帶來了希望，雖然MySQL推出MySQL Cluster集群，但性能也不能很好滿足互聯網的需求，只是在高可靠性上提供非常大的保障；
我們可以發現，以上圖就用了數據庫的集群，三個數據庫各司其職，每個數據庫存放的是整個項目數據的3分之1，頻繁查詢的數據庫單獨列出一個庫，經常不用的數據也獨立出來放在一個數據庫中；
如今的項目結構
首先，三個藍色的小人人就點客戶，通過企業防火牆Linux，往后就是負載均衡的主備Nginx，做這個負載均衡、反向代理的一個；
所以說在真正的項目研發的時候，你是不可能先經過服務器的，而是先經過Nginx；
后面就是一大堆應用服務器的集群，也可以理解為tomcat的集群，一只貓帶不動這個項目，那么就一群貓來帶，這樣就實現了高可用，負載均衡以及服務器的集群；
再往后，就是數據庫的集群了；
今日感悟：
當一個人可以輕松做一件事情的時候，你自己也這么認為自己也可以；
那么你就大錯特錯了