注：此處爲上課筆記
這裏寫目錄標題
NoSQL
NOSQL(Not Only SQL)是對不同於傳統的關係數據庫的數據庫管理系統的統稱。
允許部分數據使用SQL系統存儲，而其他數據允許使用NOSQL系統存儲。其數據存儲可以不需要固定的表格模式以及中介數據(metadata)，也經常會避免使用SQL的JOIN操作，一般有水平可擴展性的特徵。
主要的四大類
- 鍵值存儲數據庫
- 列存儲數據庫
- 文檔型數據庫
- 圖形數據庫
NoSQL共同特徵：
-
不需要預定義模式：
不需要事先定義數據模式，預定義表結構。
數據中的每條記錄都可能有不同的屬性和格式，當插入數據時，並不需要預先定義它們的模式； -
無共享架構：
相對於將所有數據存儲的存儲區域網絡中的全共享架構，NoSQL往往將數據劃分後存儲在各個本地服務器上。因爲從本地磁盤讀取數據的性能往往好於通過網絡傳輸讀取數據的性能，從而提高了系統的性能； -
彈性可擴展：
-
分區：
相對於將數據存放於同一個節點，NoSQL數據庫需要將數據進行分區，將記錄分散在多個節點上面。並且通常分區的同時還要做複製。這樣既提高了並行性能，又能保證沒有單點失效的問題； -
異步複製：
和RAID存儲系統不同的是，NoSQL中的複製，往往是基於日誌的異步複製。這樣，數據就可以儘快地寫入一個節點，而不會被網絡傳輸引起遲延。缺點是並不總是能保證一致性，這樣的方式在出現故障的時候，可能會丟失少量的數據； -
BASE：
相對於事務嚴格的ACID特性，NoSQL數據庫保證的是BASE特性。
NoSQL適用情況：
1）數據模型比較簡單：字段很多，而且外鍵很多，比如訂單主表等
2）需要靈活性更強的IT系統：需求多變，表多變等
3）對數據庫性能要求較高：讀取或者更新壓力高，瞬間併發高（限時搶購），關係數據庫性能沒有太多優勢
4）不需要高度的數據一致性
理論
CAP理論
CAP解釋爲一致性（consistency）、可用性（availability）和分區容忍性（partition tolerance）。
上面三個性質不可能都做到
一致性：一個數據系統如何處理讀寫操作的一致性問題。分佈式系統對於一致性的要求爲當更新寫入操作完成時，其餘讀取操作需要及時看到數據的更新；
可用性：一個系統能夠持續不間斷使用的問題。嚴格定義上的高性能可用性意味着一個系統從設計到實施都應該能夠提供可持續的操作；
分區容忍性：如果分佈式系統的部分斷裂，形成一個一個孤立的分區，系統還能否提供服務。
BASE理論：
BASE思想實際上是CAP理論中AP的衍伸。
它通過犧牲高一致性，保證高可用性和分區容忍性。
BASE思想的組成有以下3個部分：
基本可用：首先完成基本工作
軟狀態：對數據一致狀態的要求是“軟”的
最終一致性：數據一致性最終是保證的
ACID和BASE：互相補充，而不是替代。
Basically Available(基本可用)
Soft State（軟狀態）
Eventually Consistent（最終一致性）
BASE是相對於DBMS中的ACID所提出來的新思想。
ACID理論
ACID指的是傳統數據庫對於數據特性的要求。
ACID屬性保證了數據庫的一致性，如銀行系統中，付款就是一個事務。
ACID特性對於大型的分佈式系統來說，與高性能是不兼容的。
如在線購買商品的時候，任何一個人購物的過程都爲一個原子操作，不允許存在兩個人同時進行購物的情況。
很明顯對於絕大多數在線商城，這個方法並不適用。
- 原子性：即事務執行作爲原子，不可再分離，整個語句要麼執行，要麼不執行，不可能停在中間某個環節；
- 一致性：在事務開始之前和事務結束之後，數據庫的完整性約束沒有被破壞；
- 隔離性：兩個事務的執行互不干擾，也不會發生交互，一個事務不可能看到其他事務運行時中某一時刻的數據；
- 持久性：在事務完成以後，該事務對數據庫所做的更改便持久地保存在數據庫之中，並不會被回滾。
區別
四種主要詳解
一丶鍵值存儲數據庫
鍵值存儲典型實現的數據結構一般爲數組鏈表：
先通過通過hash算法得出hashcode，
找到數組的某一個位置，
然後插入鏈表的第一個位置。
適用的場景
儲存用戶信息，比如會話、配置文件、參數、購物車等等。這些信息一般都和ID（鍵）掛鉤，這種情景下鍵值數據庫是個很好的選擇。
不適用場景
1）取代通過鍵查詢，而是通過值來查詢。Key-Value數據庫中根本沒有通過值查詢的途徑。
2）需要儲存數據之間的關係。在Key-Value數據庫中不能通過兩個或以上的鍵來關聯數據。
3）事務的支持。在Key-Value數據庫中故障產生時不可以進行回滾。
Redis
一個開源的使用C語言編寫的一個kv存儲系統，是一個速度非常快的非關係內存數據庫。它支持包括String、List、Set、Zset、hash五種數據結構。
二丶列存儲數據庫
列數據庫是對應並區別於行數據庫的概念。
行數據庫就是我們所熟知的傳統關係型數據庫，即數據按記錄存儲，每一條記錄的所有屬性都存儲在一起，如果要查詢一條記錄的一個屬性值，需要先讀取整條記錄的數據。
而列數據庫是按數據庫記錄的列來組織和存儲數據的，數據庫中每個表由一組頁鏈的集合組成，每條頁鏈對應表中的一個存儲列，而該頁鏈中每一頁存儲的是該列的一個或多個值。
適用的場景
1）日誌。因爲我們可以將數據儲存在不同的列中，每個應用程序可以將信息寫入自己的列族中。比如讀取時間的日誌
2）博客平臺。我們儲存每個信息到不同的列族中。舉個例子，標籤可以儲存在一個，類別可以在一個，而文章則在另一個。
不適用場景
1）如果需要ACID事務。Vassandra就不支持事務；
2）原型設計。如果我們分析Cassandra的數據結構，我們就會發現結構是基於我們期望的數據查詢方式而定。在模型設計之初，我們根本不可能去預測它的查詢方式，而一旦查詢方式改變，我們就必須重新設計列族。
Apache Cassandra
Cassandra 是一種開源列式數據庫，專門處理多個商用服務器之間的大量數據。與關係數據庫中的表不同的是，同一表中的不同行 (列系列) 不必共享相同的列集合。
Apache HBase
Apache HBase 是一種開源、列式、分佈式 NoSQL 數據庫。HBase 在 Apache Hadoop 框架中運行。HBase 爲您提供了一種用列式壓縮和存儲方式來存儲大量稀疏數據的高效容錯方法。
三丶文檔型數據庫
鍵值型的值做了一定的約束
文檔型數據庫的靈感是來自於Lotus Notes辦公軟件的，而且它同第一種鍵值存儲相類似。該類型的數據模型是版本化的文檔、半結構化的文檔以特定的格式存儲，例如JSON。
文檔型數據庫可以看作是鍵值數據庫的升級版，允許之間嵌套鍵值。而文檔型數據庫比鍵值數據庫的查詢效率更高，如：CouchDB，MongoDb。國內也有文檔型數據庫SequoiaDB，已經開源。
適用的場景
1）日誌。企業環境下，每個應用程序都有不同的日誌信息。Document-Oriented數據庫並沒有固定的模式，所以我們可以使用它儲存不同的信息。
2）分析。鑑於它的弱模式結構，不改變模式下就可以儲存不同的度量方法及添加新的度量。
不適用場景
在不同的文檔上添加事務。文檔型數據庫並不支持文檔間的事務，如果對這方面有需求則不應該選用這個解決方案。
MongoDB
MongoDB是10gen公司研發的面向文檔的開源的NoSQL數據庫系統，用C++語言編寫。
它提供一種強大、靈活、可擴展的數據存儲方式。
它擴展了關係型數據庫的衆多功能，如輔助索引、範圍查詢和排序。
MongoDB的功能非常豐富，比如內置的對MapReduce聚合的支持，以及對地理空間索引的支持。
MongoDB的主要特性
- 數據類型豐富。MongoDB是面向文檔的數據庫，放棄關係模型的一個主要原因是爲了獲得更加靈活的擴展性。它是無模式的，文檔的鍵不會事先定義也不會固定不變，應用層可以方便地處理新增的鍵或丟失的鍵，爲開發者變更數據模型提供極大的便利；
- 功能豐富。支持輔助索引、存儲JavaScript和MapReduce等其他聚合工具的獨特功能；
- 容易擴展。MongoDB在設計時考慮了系統擴展的問題，面向文檔的數據模型可以自動在多臺服務器之間進行分割。通過其Auto-Sharding機制，可以自動實現集羣的數據和負載均衡；
- 性能卓越。MongoDB對文檔進行自動動態填充，預分配數據文件，用空間換取性能的穩定。默認的存儲引擎中使用了內存映射文件，將內存的管理工作交給操作系統去處理。
- 管理簡便。儘可能的讓服務器自動配置，通過複製機制來提升系統的可靠性。
MongoDB的核心概念是文檔，多個鍵及其相應的值有序地存放在一起組成文檔，文檔類似於關係型數據庫中的元組。多個文檔組成集合，集合如同關係型數據庫中的表。多個集合組成數據庫，一個MongoDB的實例可以承載多個數據庫，每個數據庫之間是完全獨立的。
MongoDB的文檔採用BSON格式存儲，BSON是Binary JSON的簡寫，是一種類似於JSON文檔的二進制序列化方案。
四丶圖形數據庫
圖形數據庫就是將數據存儲在圖（Graph）結構中。圖示是一個簡單的有向無環圖。
其中，節點表示一個實體。例如人或商品。邊表示點與點之間的連接關係，可以是有方向和無向的。如用戶Ａ買了商品Ｂ表示Ａ→Ｂ；如果用戶Ａ與用戶Ｃ相互都認識，這種關係就是雙向的，表示爲 Ａ←→Ｃ。屬性表示點和邊所附帶的屬性。例如用戶姓名、年齡等。需要注意的是每個點或邊的屬性是動態可變的。
圖形數據庫可以看作是結點與關係的集合，圖形數據庫就是將數據存儲在擁有屬性的結點中，並用關係將這些結點組織起來。
數據存儲的重要目的是爲了檢索。圖的查找與搜索可以通過遍歷算法完成，根據算法，從開始結點到與之相連的結點查詢諸如“我好友的好友是哪些人”等問題。所以通過遍歷算法可以對圖進行導航與操作，從而確定結點之間的路徑。
適用的場景
1）在一些關係性強的數據中；
2）推薦引擎。如果我們將數據以圖的形式表現，那麼將會非常有益於推薦的制定。
不適用場景
不適合的數據模型。圖數據庫的適用範圍很小，因爲很少有操作涉及到整個圖。