誤區
非關系,意思就是沒有關系，沒有關系,怎么做關聯,怎么提取數據?
NoSQL(NoSQL = Not Only SQL )，意即"不僅僅是SQL"。其實指的就是關系型數據庫以外的數據庫。
總結
mysql就像老式拖拉機，皮實，穩定，可靠性好，能裝很多貨物。但是現在社會高速發展，大家速度有了一定要求，nosql就像是一臺跑車，華麗、速度快。但是可靠性并不好，容量也不夠大。所以就將redis(nosql)+mysql，即跑車拉著拖拉機。這樣速度容量都有了。
關系型數據庫
1.所謂關系模型就是“一對一、一對多、多對多”等關系模型，關系模型就是指二維表格模型,因而一個關系型數據庫就是由二維表及其之間的聯系組成的一個數據組織。
2.關系型數據可以很好地存儲一些關系模型的數據，比如一個老師對應多個學生的數據（“多對多”），一本書對應多個作者（“一對多”），一本書對應一個出版日期（“一對一”）
3.關系模型是我們生活中能經常遇見的模型，存儲這類數據一般用關系型數據庫
關系型（sql）數據庫的缺點
互聯網的不斷發展，用戶的不斷增多導致傳統關系型數據庫遇到了性能瓶頸，具體表現在以下幾個方面
1.對數據庫高并發讀寫的需求(High performance)
關系數據庫應付上萬次SQL查詢還勉強頂得住，但是應付上萬次SQL寫數據請求，硬盤IO就已經無法承受了。比如微博的實時統計在線用戶狀態，記錄熱門帖子的點擊次數，投票計數等。
2.對海量數據的高效率存儲和訪問的需求(Huge Storage)
類似Facebook，twitter，Friendfeed這樣的SNS網站，每天用戶產生海量的用戶動態，以Friendfeed為例，一個月就達到了2.5億條用戶動態，對于關系數據庫來說，在一張2.5億條記錄的表里面進行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網站的用戶登錄系統，例如騰訊，盛大，動輒數以億計的帳號，關系數據庫也很難應付
3.對數據庫的高可擴展性和高可用性的需求
在基于web的架構當中，數據庫是最難進行橫向擴展的，當一個應用系統的用戶量和訪問量與日俱增的時候，你的數據庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務節點來擴展性能和負載能力。對于很多需要提供24小時不間斷服務的網站來說，對數據庫系統進行升級和擴展是非常痛苦的事情，往往需要停機維護和數據遷移
nosql的優點
1.大數據量，高性能
NoSQL數據庫都具有非常高的讀寫性能，尤其在大數據量下，同樣表現優秀。這得益于它的無關系性，數據庫的結構簡單。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說就要性能高很多了
2.易擴展
NoSQL數據庫種類繁多，但是一個共同的特點都是去掉關系數據庫的關系型特性(去掉了“一對一、一對多、多對多”等關系模型)。數據之間無關系，這樣就非常容易擴展。也無形之間，在架構的層面上帶來了可擴展的能力
3.高可用
NoSQL在不太影響性能的情況，就可以方便的實現高可用的架構。比如Cassandra，HBase模型，通過復制模型也能實現高可用。
為什么nosql支持分布式
1.nosql本身就不支持事務，外鍵，而事務的問題在于要支持ACID特性（原子性，一致性），即要么全部成功要么全部失敗。但是你如何保證一個事務的一致性。一次大的事務操作由不同的小操作組成，這些小的操作分布在不同的服務器上，且屬于不同的應用，分布式事務需要保證這些小操作要么全部成功，要么全部失敗。這一點很難做，nosql由于本身沒有事務的限制，不妨礙它在多個節點上操作。
既然支持分布式，大部分NoSQL為什么不提供分布式事務？
如果要支持分布式事務，那么在分布式事務中實現原子性需要彼此協調，而協調是耗費時間的，每臺機器在一個大事務過程中必須依次確認，這就需要一種協議確保一個事務中沒有任何一臺機器寫操作失敗。而類似redis等nosql數據庫是以性能、快速著稱，所以從性能考慮。大部分NoSQL數據庫因為性能問題就選擇不提供分布式事務
為什么新的分布式數據庫又開始支持關系模型了？
之所以新的分布式數據庫又開始支持關系模型了，是因為大部分程序員的數據庫水平太糟糕。
https://www.zhihu.com/question/51158165
mysql如何實現分布式事務？
1.基于XA協議的兩階段提交，XA是一個分布式事務協議，由Tuxedo提出。XA中大致分為兩部分：事務管理器和本地資源管理器。其中本地資源管理器往往由數據庫實現，比如Oracle、DB2這些商業數據庫都實現了XA接口，而事務管理器作為全局的調度者，負責各個本地資源的提交和回滾。
XA事務，即所謂的分布式事務卻令人感到云里霧里。一是資料很少，網上的各種配置資料都是流于表面；二是可能實際應用的人也少。二階段提交（Two-phase Commit）
首先，XA事務是基于二階段提交（Two-phase Commit）實現的。二階段提交本身并沒有什么令人疑惑的地方。看wiki就可以知道是怎么回事了。
簡而言之，有二種角色，事務管理者（DM, Transaction Manager），資源管理器（RM, Resource Manager），通常即數據庫或者JMS服務器。
為什么會出現這些數據庫的演進？
歷史背景的變化
1.早期數據庫還有層級數據庫、網狀數據庫。早期程序員出了些sql語句還得考慮數據物理存放方式來決定怎么執行查詢更高效。泰國繁瑣和麻煩。
2.后來出現了關系模型，徹底改變了數據庫程序員的生活：不用管數據怎么存了，你只要用SQL寫好查詢，然后查詢優化器會幫你把面向業務的查詢邏輯轉換成可以高效在數據的物理結構上執行的物理查詢。這簡直就像一下從匯編時代跨越到了高級語言的時代啊。早期的數據庫還需要大家自己思考怎么建索引，相當于告訴查詢優化器哪些列是在查詢中有用，后來數據庫已經可以自動提示你該加什么索引了，大部分程序員終于可以歡樂地徹底扔掉數據庫存儲引擎的知識了。
3.分布式出現后原本的關系型數據庫不管用了。分布式最大的問題是網絡延遲問題，而網絡延遲是物理問題，沒這么容易解決。跨機事務做不了啊，查詢優化器再牛逼也優化不了跨網絡的join。
4.就出現了nosql這種不需要事務，可擴展性強的產品
5.但是nosql太難用了，就像回到了以前匯編的時代，所以基于這種情況下，新的分布式數據庫又開始支持關系模型了。
