NoSQL(NoSQL = Not Only SQL )，「不僅僅是SQL」，泛指 非關係型的資料庫 。隨著網際網路web2.0網站的興起，傳統的關係數據庫在處理web2.0網站，特別是超大規模和高並發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題，而非關係型的資料庫則由於其本身的特點得到了非常迅速的發展。NoSQL資料庫的產生就是為了解決大規模數據集合多重數據種類帶來的挑戰，尤其是大數據應用難題，包括超大規模數據的存儲。（例如谷歌或Facebook每天為他們的用戶收集萬億比特的數據）。這些類型的數據存儲不需要固定的模式，無需多餘操作就可以橫向擴展。
在以前，一個網站的訪問量一般都不大，用單個資料庫完全可以輕鬆應付。在那個時候，更多的都是靜態網頁，動態交互類型的網站不多。上述架構下，我們來看看數據存儲的瓶頸是什麼？
後來，隨著訪問量的上升，幾乎大部分使用MySQL架構的網站在資料庫上都開始出現了性能問題，web程序不再僅僅專注在功能上，同時也在追求性能。程式設計師們開始大量的使用 緩存技術 來緩解資料庫的壓力，優化資料庫的結構和索引。開始比較流行的是通過 文件緩存 來緩解資料庫壓力，但是當訪問量繼續增大的時候，多台web機器通過文件緩存不能共享，大量的小文件緩存也帶了了比較高的IO壓力。在這個時候，Memcached就自然的成為一個非常時尚的技術產品。
Memcached作為一個 獨立的分布式的緩存伺服器 ，為多個web伺服器提供了一個共享的高性能緩存服務，在Memcached伺服器上，又發展了根據hash算法來進行多台Memcached緩存服務的擴展，然後又出現了一致性hash來解決增加或減少緩存伺服器導致重新hash帶來的大量緩存失效的弊端
由於資料庫的寫入壓力增加，Memcached只能緩解資料庫的讀取壓力。讀寫集中在一個資料庫上讓資料庫不堪重負，大部分網站開始 使用主從複製技術來達到讀寫分離，以提高讀寫性能和讀庫的可擴展性 。 Mysql的master-slave模式 成為這個時候的網站標配了。
在Memcached的高速緩存，MySQL的主從複製，讀寫分離的基礎之上，這時MySQL主庫的寫壓力開始出現瓶頸，而數據量的持續猛增，由於 MyISAM 使用 表鎖 ，在高並發下會出現嚴重的鎖問題，大量的高並發MySQL應用開始使用 InnoDB 引擎代替MyISAM。
同時，開始流行 使用分表分庫來緩解寫壓力和數據增長的擴展問題 。這個時候，分表分庫成了一個熱門技術，是面試的熱門問題也是業界討論的熱門技術問題。也就在這個時候，MySQL推出了還不太穩定的表分區，這也給技術實力一般的公司帶來了希望。雖然MySQL推出了MySQL Cluster集群，但性能也不能很好滿足網際網路的要求，只是在高可靠性上提供了非常大的保證。
MySQL資料庫也經常存儲一些大文本欄位，導致資料庫表非常的大，在做資料庫恢復的時候就導致非常的慢，不容易快速恢復資料庫。比如1000萬4KB大小的文本就接近40GB的大小，如果能把這些數據從MySQL省去，MySQL將變得非常的小。關係數據庫很強大，但是它並不能很好的應付所有的應用場景。MySQL的擴展性差（需要複雜的技術來實現），大數據下IO壓力大，表結構更改困難，正是當前使用MySQL的開發人員面臨的問題。
今天我們可以通過第三方平台（如：Google,Facebook等）可以很容易的 訪問和抓取數據 （爬蟲私密信息有風險哈）。用戶的個人信息，社交網絡，地理位置，用戶生成的數據和用戶操作日誌已經成倍的增加。我們如果要對這些用戶數據進行挖掘，那SQL資料庫已經不適合這些應用了, NoSQL資料庫的發展也不能很好的處理這些大的數據。
新浪：BerkeleyDB+redis
美團：redis+tair
阿里、百度：memcache+redis
CouchDB
MongoDB：MongoDB 是一個基於分布式文件存儲的資料庫。由 C++ 語言編寫。旨在為 WEB 應用提供可擴展的高性能數據存儲解決方案。MongoDB 是一個介於關係數據庫和非關係數據庫之間的產品，是非關係數據庫當中功能最豐富，最像關係數據庫的。
Cassandra, HBase
分布式文件系統
它不是放圖形的，放的是關係比如:朋友圈社交網絡、廣告推薦系統、社交網絡，推薦系統等。專注於構建關係圖譜
Neo4J, InfoGrid
A (Atomicity) 原子性
C (Consistency) 一致性
I (Isolation) 獨立性
D (Durability) 持久性
C (Consistency) 強一致性——所有節點在同一時間具有相同的數據
A (Availability) 可用性——保證每個請求不管成功或者失敗都有響應
P (Partition tolerance) 分區容錯性——系統中任意信息的丟失或失敗不會影響系統的繼續運作
CAP理論的核心是： 一個分布式系統不可能同時很好的滿足一致性，可用性和分區容錯性這三個需求，最多只能同時較好的滿足兩個 。而由於當前的網絡硬體肯定會出現延遲丟包等問題，所以 分區容忍性是我們必須需要實現的 。我們稱之為**CAP的3進2，**所以我們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。
因此，根據 CAP 原理將 NoSQL 資料庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三大類：
注意
分布式架構的時候必須做出取捨：一致性和可用性之間取一個平衡。多餘大多數web應用，其實並不需要強一致性。因此犧牲C換取P，這是目前分布式資料庫產品的方向
一致性與可用性的決擇：對於web2.0網站來說，關係數據庫的很多主要特性卻往往無用武之地
資料庫事務一致性需求：很多web實時系統並不要求嚴格的資料庫事務，對讀一致性的要求很低， 有些場合對寫一致性要求並不高。允許實現最終一致性。
資料庫的寫實時性和讀實時性需求：對關係數據庫來說，插入一條數據之後立刻查詢，是肯定可以讀出來這條數據的，但是對於很多web應用來說，並不要求這麼高的實時性，比方說發一條消息之 後，過幾秒乃至十幾秒之後，我的訂閱者才看到這條動態是完全可以接受的。
對複雜的SQL查詢，特別是多表關聯查詢的需求：任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及複雜的數據分析類型的報表查詢，特別是SNS類型的網站，從需求以及產品設計角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
BASE就是為了解決關係數據庫強一致性引起的的可用性降低問題而提出的方案。
BASE其實是下面三個術語的縮寫：
它的思想是通過讓系統放鬆對某一時刻數據一致性的要求來換取系統整體伸縮性和性能上改觀。為什麼這麼說呢，緣由就在於大型系統往往由於地域分布和極高性能的要求，不可能採用分布式事務來完成這些指標，要想獲得這些指標，我們必須採用另外一種方式來完成，這裡BASE就是解決這個問題的辦法
分布式系統（distributed system）
由多台計算機和通信的軟體組件通過計算機網絡連接（本地網絡或廣域網）組成。分布式系統是建立在網絡之上的軟體系統。正是因為軟體的特性，所以分布式系統具有高度的內聚性和透明性。因此，網絡和分布式系統之間的區別更多的在於高層軟體（特別是作業系統），而不是硬體。分布式系統可以應用在在不同的平台上如：PC、工作站、區域網和廣域網上等。