《NoSQL精粹》讀書筆記

NoSQL數據庫數據模型的通常分類：

1. 鍵值數據模型
2. 文檔數據模型
3. 列族數據模型
4. 圖數據模型

常見NoSQL數據庫：

Redis, Cassandra, MongoDB, Neo4J, Riak...

數據庫應用趨勢：

1. 因爲數據量愈來愈大，大型系統的擴展方式由數據庫在單一計算機上的縱向擴展->在計算機集羣中的橫向擴展

2. 混合持久化(關係型數據庫 + NoSQL數據庫)

 

第一部分

第1章 爲何使用NoSQL

* 關係型數據庫和應用程序之間的「阻抗不匹配」。關係模型和應用程序程序中內存數據結構的不一致致使這種情況，所以涌現出不少對象-關係映射(ORM)框架，但濫用ORM可能會致使性能問題。

* 「集成數據庫」和「應用程序數據庫」，前者是一種多應用程序分享使用同一數據庫的方式，特色是全部應用程序均可以得到本身想要的東西，但因爲要兼容全部應用程序，所以數據庫的設計可能會過度複雜致使很差維護，而且也須要應對系型數據庫和應用程序之間的「阻抗不匹配」。後者衍生除了web服務，應用程序之間以接口的方式進行交互，一般使用XML或JSON來交換數據，此時就可使用結構豐富的數據格式(數組、嵌套結構等)了。

* web服務常用傳輸文本信息的HTTP協議，對一些性能要求較高的狀況，可使用二進制協議。

* 關係型數據庫和計算機集羣的格格不入。關係型數據庫能把數據劃分爲幾個集合，分別部署在各自獨立的服務器上運行，這能夠有效地對數據庫分片。但這麼作也有缺點，應用程序必須控制全部分片，它要知道數據庫中的每份小數據存放在哪裏才行。並且，查詢、參照完整性、事務、一致性控制等操做也沒法再跨分片的環境下執行。

* 在集羣中使用關係型數據庫有可能遇到成本的問題(商用關係型數據庫通常按服務器臺數計費)。

* 出現了以谷歌和亞馬遜爲首的典型計算機集羣用戶，爲此谷歌研發了BigTable，亞馬遜則是Dynamo。

* 混合持久化須要把集成數據庫遷移到應用程序數據庫上，通常來講，應用程序數據庫均可以採用NoSQL數據庫，但集成數據庫不適合使用NoSQL數據庫。企業能夠考慮把原來存放在集成數據庫中的數據轉移到各個應用程序數據庫，而後使用web服務來鏈接這些系統。這既下降了應用之間的耦合度，也下降了成本和維護難度。

* 選用NoSQL數據庫的兩個主要緣由：

1. 待處理的數據量很大，對數據訪問的效率要求很高，從而必須把數據放在集羣上。
2. 但願採用一種更爲方便的數據交互方式來提升應用程序的開發效率。

* NoSQL的特徵：

1. 不使用關係模型
2. 在集羣中運行良好
3. 開源
4. 適用於21世紀的互聯網公司
5. 無模式

第2章 聚合數據模型

* 聚合結構能夠把關聯數據直接嵌入在某個聚合中，從而方便查找。聚合使數據庫在集羣上管理數據存儲更爲方便。

* 對某些數據交互有用的聚合結構，可能會阻礙另外一些數據交互。在對數據建模時，須要考慮到哪一種場景占主導地位，據此來設計數據聚合的方式。

* 選用面向聚合模型的決定性因素，就是它很適合在集羣上運行。咱們須要把採集數據時所需的節點數將至最小。若是在數據庫中明確包含聚合結構，那麼數據庫就知道這些數據就會被一塊兒操做，並放在同一節點中。

* 一般狀況下，面向聚合的數據庫不支持跨越多個聚合的ACID事務。聚合是做爲交互單元的數據集合，數據庫中的ACID操做以聚合爲界。

* 鍵值數據庫、文檔數據庫、列族數據庫都屬於面向聚合的數據庫。

* 若是數據交互大都在同一聚合內執行，則應使用面向聚合的數據庫；若是數據交互操做須要使用多種不一樣格式的數據，那麼最好選用「聚合無知式數據庫」。

 

第3章 數據模型詳解

圖數據庫

* 常見的圖數據庫有：FlockDB, Neo4J, Infinite Graph。

* 圖數據庫對於處理複雜關係的場景較爲理想，例如社交網絡、產品偏好、資格認定規則等包含複雜關係的數據。

* 對關係型數據庫來講，操做內部相互關係比較緊密的數據模型一般須要使用不少JOIN語句，效率也較差。使用圖數據庫遍歷關係，則很是迅速。主要緣由是因爲圖數據庫會多花一些時間用於插入關係數據，以此來縮短遍歷關係時所需的時間。在一些查詢效率高於插入效率的場合，這種權衡很是重要。

* 圖數據庫使用邊和節點來存儲數據，使用圖數據庫時，大部分時候都是在瀏覽各類關係。

* 圖數據庫和麪向聚合的數據庫的明顯差異，在於圖數據庫重視數據間的「關係」，這種數據模型上的差別也致使了其餘一些區別。圖數據庫通常運行在單一服務器上而非集羣中。爲了使數據保持一致，ACID事務須要涵蓋多個節點與邊。類似之處是，它們都不適用關係模型。

無模式數據庫

* 各類形式的NoSQL都有一個特性，就是它們都是無模式的。在關係型數據庫中，咱們首先要定義好模式，就是用一種預約義結構向數據庫說明，有哪些表，表中有哪些列，每列存放什麼類型的數據，必須先定義好模式，才能使用數據庫。相反，無模式數據庫就顯得至關隨意了，能夠在一個鍵下存聽任意數據。

* 無模式數據庫沒有關係型數據庫的那麼多限制，可是它自己也存在一些問題，無論數據庫無模式到什麼程度，它都存在「隱含模式」，它是指在編寫數據操做代碼時，對數據結構所作的一系列假設。雖然咱們能夠在無模式數據庫中以合法名稱的鍵值存放數據，可是這也就假定了程序須要知道這些字段，除非咱們只是無腦地遍歷數據結構依次打印鍵值對，然而這基本沒有什麼意義。

* 應用程序代碼中的隱含模式也會帶來一些問題，它意味着要想理解數據庫中的數據，必須深刻研究應用程序的代碼才行，若是代碼很清晰易懂，那麼你能夠根據它推斷出數據的模式，然而這一點卻沒法保證，由於這徹底取決於你的代碼是否清晰。舉個簡單的例子，某個字段，在一些聚合中保存爲字符串，在另外一些聚合中保存爲對象(由於數據庫是無模式的，理論上徹底可能出現這種狀況)，若是你不知曉代碼的邏輯，基本沒法判斷出這個字段的這兩種數據類型究竟有什麼區別。並且，因爲數據庫感知不到模式，也就沒法自行驗證數據，這就少了一道保障。不一樣應用程序可能也會以徹底不一樣的方式使用某個字段。固然了，在驗證數據方面，咱們還必須在全部使用這個數據庫的應用程序中都加上徹底相同的驗證邏輯來確保數據正確性和安全性。

* 從本質上說，無模式數據庫是把模式交由訪問其數據的應用程序代碼來處理，若是有多個應用程序須要訪問同一個數據庫，可能會出現問題。一種緩解此問題的方法是把數據互動操做封裝成獨立的應用程序，並經過web服務的形式將它和其餘應用程序集成。另外一種方法是在聚合中明確劃分出不一樣應用程序的區域。

物化視圖

* 關係型數據庫能夠利用視圖來展現一些須要複雜計算才能給出的數據，視圖就比如一張關係表，只不過它是經過基表計算得來的，在訪問視圖時，數據庫會計算出視圖中的數據，這種形式的封裝很方便。有了視圖這種機制，客戶端不須要擔憂它訪問到的是基本數據仍是派生數據，不過生成視圖須要大量計算，比較消耗性能。

* 物化視圖是一種事先計算好並緩存起來的視圖，若是數據讀取頻繁，且對實時性要求不高的話，可使用物化視圖來優化性能。在NoSQL中，能夠利用物化視圖來處理這種需求。面向聚合的數據庫更強調這個問題，由於大多數應用程序都要處理某種與聚合機構不相符的查詢操做。

* 構建物化視圖有兩種方法，第一種是在每次基礎數據變動的時候都去更新物化視圖，若是讀取物化視圖的次數遠比寫入的多，且想得到更爲實時的數據，那麼這種方法比較合適。第二種是經過批處理來定時更新物化視圖，這須要根據業務需求來制定方案，須要考察業務能容忍過期多久的數據。

* 面向聚合的數據庫一般可以用不一樣方式重組主聚合的數據，以計算出各類物化視圖，計算過程通常使用map-reduce的方式。

構建數據存儲模型

* 使用列族數據庫建模時，應該按照查詢需求而不是寫入需求來處理。建模的通則是要便於查詢，並且在寫入數據時要對其執行「反規範化」操做。

 

第4章 分佈式模型

* 面向聚合數據庫很是適合於橫向擴展方式，由於聚合此時就天然成了數據分佈單元。

* 數據分佈有兩條途徑：

1. 複製
2. 分片

* 複製，就是將同一份數據拷貝至多個節點。分片，就是將不一樣數據存放在不一樣節點中。複製和分片是兩項正交的技術，它們既能夠選其一使用，也能夠結合使用。

單一服務器

* 在大多數狀況下，最簡單的分佈形式就是沒有分佈，採用單一服務器的形式，特色是簡單。

分片

* 分片是把數據的各個部分放在不一樣的服務器(節點)中，以此實現橫向擴展。分片技術能有效實現負載均衡。爲了最大程度地利用分片技術，咱們必須保證須要同時訪問的數據都存放在同一個節點上，而且節點必須排布好這些數據塊，使訪問速度最優。這些措施包括，使服務器服務於地理位置上較近的用戶、最大程度實現負載均衡，某些狀況下能夠把須要依次讀取的聚合放在一塊兒。

* 常常有人經過應用程序來處理分片，好比把用戶姓氏首字母按照A-D，E-G之類的方式存放在不一樣分片中，但這樣作就把編程模型複雜化了，由於應用程序須要把查詢操做分佈到多個分片上。若是想調整分片，就須要修改應用程序的相關邏輯並遷移數據。不少NoSQL數據庫都提供了「自動分片」來讓數據庫本身負責把數據分佈到各分片，並將查詢請求路由至適當分片中。

* 單一使用分片技術在應對數據庫故障時比較力不從心，一旦某個節點崩潰，則該分片上的數據就不可訪問，雖然說可能只是其中一個分片出問題，但比較已經沒法對外提供完整的服務了。後面會看到採用分片結合複製的技術構造冗餘能夠緩解此問題。

主從複製

* 在主從複製中，有一個節點叫節點，其他的叫從節點。主節點存放權威數據，複製操做就是要讓從節點和主節點的數據保持同步。

* 主節點負責處理數據的讀寫，從節點只負責數據讀。這樣只要增長從節點就能夠實現橫向擴展。

* 能夠採用手動指定主節點和自動選擇主節點兩種模式，手動指定須要咱們本身配置集羣，自動選擇比較簡單，會讓它們自動選舉出主節點，若是以後這個主節點崩潰了，會自動指派新的主節點，減小故障時間，手動指定則無此福利。

* 主從複製有助於加強讀取操做的故障恢復能力。

* 主從複製對於寫入操做很是頻繁的場合，雖然能將讀取操做分流，稍稍緩解主節點寫入數據的壓力，但對寫入操做的性能並無什麼顯著的提高。

* 複製技術再帶來好處的同時也有一個致命弱點，就是數據的不一致。若是主節點更新了一個數據，但還未通知從節點，那麼用戶從從節點讀出的數據就不是最新的，甚至因爲各從節點同步速度的快慢數據仍是各異的。更極端的狀況是，主節點崩潰了，此時有部分數據還沒有同步到從節點，這部分數據就會丟失。

* 主節點仍然是系統的瓶頸和弱點。

對等複製

* 對等複製中的全部節點都是平等的，不存在主從節點一說，全部節點均可以接受讀寫請求，節點會將自身的寫入操做通知給其餘全部節點。

* 增長節點能夠輕易提高性能。

* 對等複製也存在數據一致性問題，因爲兩個不一樣節點能夠同時處理寫入操做，因此可能出現兩位用戶同時對同一條記錄的狀況，這就致使「寫入衝突」。數據讀取的不一致性也存在，但持續時間相對較短，由於最終都會歸於一致，寫入不一致卻老是存在。

* 寫入不一致的幾種解決方案思路：

1. 無論什麼時候寫入數據，各副本之間總能相互協調，確保不發生衝突，這須要花費必定的網絡流量來協調寫入操做。
2. 設法處理這些不一致的寫入操做，好比合並這些操做。

結合分片和複製技術

* 每一個系統有多個主節點，但對於每項數據來講，負責它的主節點又只有一個。根據配置的須要，同一個節點既能夠做爲某些數據的主節點，也能夠充當其餘數據的從節點，也能夠指派全職的主節點和從節點。

 

第5章 一致性

* 面向集羣的NoSQL數據庫須要面對一致性的問題，關係型數據庫試圖經過「強一致性」來避免各類不一致問題，在NoSQL領域中，須要咱們本身思考系統須要何種一致性。

更新一致性

* 多個請求同時更新同一條數據會產生寫衝突問題，在併發環境下維護數據一致性通常有兩種方式：悲觀方式和樂觀方式。

1. 悲觀方式，就是要避免衝突。常見作法是使用寫入鎖，確保同一時間只有一個請求能夠獲取該鎖。但注意可能致使死鎖問題。
2. 樂觀方式，就是容許衝突發生，而後檢測衝突並對發生衝突的操做排序，再進一步處理。一般使用「條件更新」，就是任意用戶在執行更新操做前，都要先檢測數據的當前值和上一次讀入的是否相同。若是相同，就更新，若是不一樣，則更新失敗，此時須要先更新到最新在作更新。可參考git等分佈式版本管理系統處理衝突的方式。

* 悲觀和樂觀的方式，都有一個先決條件，就是更新順序必須一致，這在單機環境下顯然成立，但在分佈式集羣下，可能兩個節點會以不一樣的順序執行操做，最終數據就會不一致。

* 在分佈式系統的併發問題上，須要有「順序一致性」，就是全部節點都要保證以相同的次序執行操做。

讀取一致性

* 數據庫必須具備更新一致性，但就這樣還不夠，它未必能保證用戶所提交的訪問請求老是能獲得一致的響應。典型場景是一個用戶A的一個更新動做須要順序操做兩張表的數據，若是是面向聚合的數據庫則此處沒法使用ACID事務，所以是依次更新。若是在更新完第一張表但還未更新第二張表時，用戶B訪問了第二張表的那條數據，就會看到一個不一致的數據。這種一致性叫「邏輯一致性」。

* 並非全部NoSQL數據庫都不支持ACID事務，只有面向聚合的數據庫不支持，圖數據庫是支持ACID事務的。

* 面向聚合數據庫能夠「原子地」更新一個聚合的數據，但僅限於單一聚合內部。因此說，「邏輯一致性」能夠在某個聚合內部保持，但各聚合之間則不行。在多個聚合之間更新數據就存在一個時間空檔，在此空檔內讀出的相關數據不知足「邏輯一致性」，這個空檔叫「不一致窗口」。NoSQL系統的「不一致窗口」通常很短暫。

* 在引入複製的場景下，就會遭遇一種全新的不一致問題，叫「複製不一致」。若是有多個節點，在個節點上更新了數據，在全部節點還沒有所有同步數據前，就會有部分用戶訪問到過時的數據。但最終，更新仍是會傳播到全部節點上，這叫「最終一致性」。

* 「複製一致性」和「邏輯一致性」雖然說是兩個獨立的問題，不過若是「複製」過程當中的「不一致窗口」太長，就會加重「邏輯不一致」問題。兩個時間間隔很短且內容不一樣的更新操做，在主節點中留下的「不一致窗口」也就幾毫秒而已，但因爲網絡延遲，這個「不一致窗口」在從節點上會比在主節點上長得多。

* 「會話一致性」是指在用戶會話內部保持「照原樣讀出所寫內容的一致性」。要確保「會話一致性」，其中一種方法是使用「粘性會話」，就是把會話綁定到某個固定的節點，但缺點是會下降負載均衡器的效率。另外一種方法是使用「版本戳」，這個以後會詳述。

放寬「一致性」約束

* 一致性很重要，不過有時必須捨棄它。在設計系統時，咱們常常須要犧牲一致性來換取其餘特性。

* 關係型數據庫通常用事務來增強一致性，可是事務會影響系統性能。

* CAP定理，其中CAP的意思是

1. 一致性(Consistency)，具體含義以前說過。
2. 可用性(Availability)，這裏能夠指響應的效率，或者說延時。
3. 分區耐受性(Partition tolerance)，若是發生通訊故障，致使整個集羣被分割成多個沒法通訊的分區時(也叫腦裂)，集羣仍然可用。

CAP定理所表述的是，給定一致性、可用性和分區耐受性這三個屬性，咱們只能同時知足其中兩個屬性。

放寬「持久性」約束

* 某些數據能夠不持久化或延遲持久化，好比用戶session或者一些臨時數據能夠保存在redis中，生成和更新很是頻繁但又不是那麼重要的數據能夠延遲持久化，好比定時持久化寫入。

* 是否放寬「持久化」約束須要根據具體需求來肯定。

仲裁

* 假設某份數據須要複製到3個節點中，爲了保證"強一致性"，不須要全部節點都確認寫入操做，只需其中兩個節點(超過半數)確認便可。就是說若是發生兩個發生衝突的寫入操做，那麼只有其中一個操做能爲超過半數的節點所承認(W>N/2)。這就叫寫入仲裁。

* 讀取仲裁，是指想要讀取保證可以讀到最新的數據，必須聯繫多少個節點才行。

* 在採用「複製」技術的分佈式模型中執行數據操做時，無需聯繫全部副本，只要爲足夠多的副本所承認，就能保持「強一致性」了。

* 執行讀取操做時所需聯繫的節點數(R)、確認寫入操做時須要聯繫的節點數(W)和複製因子(N)之間能夠用一個不等式來表達：R+W>N。

 

第6章 版本戳

* 版本戳用戶標識數據的版本，典型狀況是使用計數器版本戳，若是當前數據庫中某條數據的版本戳是3，而用戶請求更新的數據版本戳是2，說明在用戶上一次讀取到更新之間，該條數據發生了一次更新，多是有其餘人在此時更新了數據，因此這個用戶的更新會失敗。

* 版本戳通常可使用計數器、GUID、內容哈希值、上一次更新的時間戳來表示，這幾種方案各有優劣。也能夠結合起來使用，好比CouchDB的版本戳就結合使用了內容哈希和計數器。

* 除了能夠避免「更新衝突」以外，版本戳也有助於維護「會話一致性」。

* 在分佈式環境中，可使用「由版本戳構成的數組」，來檢測不一樣節點之間是否發生了「相互衝突的更新操做」。

 

第7章 Map-reduce(映射-化簡)

* 映射-化簡是一種在集羣上執行併發計算所用的模式。

* 映射操做從聚合中讀出數據，將之縮減爲相關鍵值對。映射操做每次只能讀取一條記錄，因此可在存放記錄的節點上併發執行。

* 映射任務會生成不少具有同一關鍵字的值，而化簡任務則將它們化簡爲單一的輸出值。每一個化簡函數只操做與單個鍵相關的映射結果，因此多個化簡函數能夠根據關鍵字執行併發化簡。

* 輸入數據與輸出數據形式相同的多個「化簡函數」可歸併爲「管道」，以提升併發執行能力，並減小所需傳輸的數據量。

* 若某個「化簡輸出」的結果是下一個「映射操做」的輸入，那麼能夠用「管道」組合映射-化簡操做。

* 若是須要普遍使用映射-化簡的計算結果，那麼能夠將其存儲爲「物化視圖」。

* 可以使用增量式映射-化簡操做來更新「物化視圖」，這樣作只須要計算視圖中發生改變的那部分數據便可，無需把所有數據從頭算一遍。

 

第8章 鍵值數據庫

鍵值數據庫和關係型數據庫的對比

Oracle	Raik
數據庫實例	Raik集羣
表	存儲區
行	鍵值對
rowid	鍵

 

什麼是「鍵值數據庫」

* 從API的角度來看，鍵值數據庫是最簡單的NoSQL數據庫。客戶端能夠根據鍵查詢值，設置鍵所對應的值。

* Redis等鍵值數據庫中，所存儲的數據不必定非要是領域對象，任何數據結構都行。Redis能夠存儲list、set、hash等數據結構，還能夠求差集、並集、交集和獲取某個範圍內的數值。

鍵值數據庫特性

* 一致性，只有針對單個鍵的操做才具有一致性，通常就是set、get或del。

* 事務，不一樣鍵值數據庫其事務規範不一樣，通常沒法保證寫入一致性。好比Raik採用仲裁。

* 查詢功能，全部鍵值數據庫均可以按照關鍵字來查詢，但沒法根據列值來查詢。

* 數據結構，鍵值數據庫通常不關心值，值能夠是二進制、文本、JSON等。

* 可擴展性，不少鍵值數據庫均可以採用分片技術。採用這種技術後，鍵的名字決定了負責存儲該鍵的節點。像Raik這樣的數據庫，能夠控制「CAP」定理中的參數，N(存放鍵值對的副本節點數)、R(順利完成讀取操做所需的最小節點數)和W(順利完成寫入操做所需的最小節點數)。

適用案例

* 存放會話信息

* 用戶配置信息

* 購物車數據

不適用場合

* 數據間關係

* 含有多項操做的事務

* 查詢數據

* 操做關鍵字集合

 

第9章 文檔數據庫

文檔數據庫和關係型數據庫的對比

Oracle	MongoDB
數據庫實例	MongoDB實例
模式	數據庫
表	集合
行	文檔
rowid	_id
join	DBRef

 

特性

* 一致性，爲了在MongoDB數據庫中確保一致性，能夠配置副本集，也能夠規定寫入操做必須等待所寫數據複製到所有或是給定數量的從節點後，才能返回。提高一致性會下降寫入效率。能夠配置以增長副本集的讀取效率。

* 事務，只支持單文檔級別的事務，即原子事務。

* 可用性，文檔數據庫試圖用主從式數據複製技術來加強可用性。多個節點保有同一份數據，即便主節點故障，客戶端也依然能夠獲取數據，應用程序通常不須要檢測主節點是否可用。全部請求都由主節點處理，而其數據會複製到從節點。若是主節點故障，副本集中剩餘的節點會在其自身範圍內選舉出新的主節點。副本集一般用於處理數據冗餘、自動故障切換、災難恢復等事項。

* 查詢功能，文檔數據庫能夠查詢文檔中的數據，而不用像鍵值數據庫那樣，必須根據關鍵字獲取整個文檔，而後再檢視其內容。MongoDB還能夠基於「內嵌子文檔」來查詢。

* 可擴展性，增長更多的「讀取從節點」，將所有讀取操做都引導至從節點上，這樣能夠擴展數據庫應對頻繁讀取的能力了。若是想擴展寫入能力，則能夠把數據分片，分片操做根據特定字段來劃分數據(該字段的選擇很重要)，這些數據要移動到不一樣的節點中。爲了讓各分片負載保持均衡，須要在節點之間動態轉移數據，向集羣中加入更多節點，並提升可寫入的節點數，就能夠橫向擴展寫入能力。把每一個分片都作成副本集能夠提升讀取效率。

適用案例

* 事件記錄

* 內容管理系統和博客平臺

* 網站分析和實時分析

* 電子商務應用程序

不適用場合

* 包含多項操做的復瑣事務

* 查詢持續變化的聚合結構

 

第10章 列族數據庫

關係型數據庫	Cassandra
數據庫實例	集羣
數據庫	鍵空間
表	列族
行	行
列	列

 

特性

* 一致性，Cassandra收到寫入請求後，會先將待寫入數據記錄到「提交日誌」中，而後將其寫入內存中一個名爲「內存表」的結構中。寫入操做在寫入「提交日誌」和「內存表」後就算成功了。寫入請求成批堆積在內存中，並按期寫入一種叫作「SSTable」的結構中，該結構中的緩存一旦寫入數據庫，就不會再向其繼續寫入了。若其數據變更，則需新寫一張SSTable。無用的SSTable可由「壓縮」操做回收。

* 事務，Cassandra沒有傳統意義上的事務，它的寫入操做在行級別的原子的。

* 可用性，Cassandra具有高可用性，由於集羣中沒有主節點，減小操做請求的一致性便可提示集羣的可用性。可用性受制於 R+W>N 這一公式。W是成功執行寫入操做所需的最小節點數，R是順利執行讀取操做所需獲取的最小應答節點數，N是參與數據複製的節點數。

* 查詢功能，Cassandra沒有功能豐富的查詢語言。在列族插入數據後，每行中的數據都會按照列名排序。若是一列的獲取次數比其餘列更加頻繁，能夠考慮將其值用做行健以提升性能。

* 基本查詢，有GET、SET和DEL。

* 高級查詢和索引編訂，Cassandra列族能夠用關鍵字之外的其餘列當索引。這些索引以位映射圖的形式出現，在列中頻繁出現重複值的狀況下效果較好。

* Cassandra查詢語言(CQL)，提供查詢功能，但未包含SQL的所有功能。

* 可擴展性，因爲沒有主節點，因此只要向Cassandra集羣中新增節點就能改善其服務能力。

適用案例

* 事件記錄

* 內容管理系統和博客平臺

* 計數器

* 限期使用

不適用場合

* 須要以「ACID事務」執行寫入和讀取操做的系統。

* 根據查詢結構聚合數據的場景。

* 開發早期、原型期和技術初探期。開發初期沒法肯定查詢模式的變化狀況，查詢模式一旦變化，列族的設計也要隨之修改。注意，關係型數據庫改變數據模式的成本很高，但查詢模式的修改爲本較低，Cassandra則相反。

 

第11章 圖數據庫

特性

* 一致性，因爲圖數據庫操做互相鏈接的節點，因此大部分圖數據庫一般不支持把節點分佈在不一樣服務器上。圖數據庫經過事務來保證一致性，它們不容許出現「懸掛關係」：全部關係必須具有起始節點和終止節點，並且在刪除節點前，必須先移除其上的關係。

* 事務，Neo4J是兼容ACID事務的數據庫，修改節點或向現有節點新增關係前，必須先啓動事務。

* 可用性，Neo4J從1.8開始，支持「副本從節點」，這些從節點能夠處理寫入操做，向其寫入後，它會先將所寫數據同步至當前主節點，而後主節點再同步至其餘從節點。也能夠配合ZooKeeper來記錄每一個叢節點和當前主節點中最新的事務ID。

* 查詢功能，圖數據庫可使用Gremlin等查詢語言，Neo4J還可使用Cypher語言來查詢圖。

* 可擴展性，圖數據庫要運用分片技術比較難，由於它並非面向聚合的，而是面向關係的。因爲任何節點都有可能關聯其餘節點，所以把相關節點放在同一臺機器上，遍歷圖時比較方便，放在多臺機器上性能很差。擴展圖數據庫通常有三種方式：

1. 給服務器配置足量內存，使之徹底能夠容納「工做集」中的所有節點和關係。只有在這些內存量的數值比較合理時，這項技術纔有用。
2. 增長僅能讀取數據的從節點，便可改善數據的讀取能力，全部寫入操做仍由主節點負責。
3. 若數據集太大，致使多節點複製不大現實，可採用「領域特定知識」在應用程序端對其分片，好比按照地理位置分片等。

適用案例

* 互聯數據

* 安排運輸路線、分派貨物和基於位置的服務

* 推薦引擎

不適用的場合

* 更新所有或某個子集內實體的場合

* 涉及整張圖的操做

 

第12章 模式遷移

* 若要遷移關係型數據庫等「強模式」的數據庫，可將歷次模式變動及其數據遷移操做保存於「版本控制序列」中。

* 因程序代碼要依照「隱含模式」來訪問無模式數據庫的數據，故其數據遷移仍需謹慎處理。

* 無模式數據庫亦可借用強模式數據庫的遷移技術。

* 無模式數據庫可以使用「增量遷移」技術更新數據，以便在不影響應用程序讀取數據的前提下，修改數據的隱含模式。

 

第13章 混合持久化

* 混合持久化旨在使用不一樣數據庫技術處理多種數據存儲需求。

* 混合持久化既可爲企業中多個程序所用，也能夠運用在單個應用程序中。

* 將數據訪問封裝成服務，能夠減小數據庫變更對系統其它部分的影響。

* 新增數據庫技術會讓編程和操做更復雜，因此要權衡引入新數據庫帶來的好處和引入它帶來的複雜度的利弊。

 

第14章 超越NoSQL

* 文件系統

* 事件溯源

* 內存映像

* 版本控制

* XML數據庫

* 對象數據量

 

第15章 選擇合適的數據庫

* 經過使用更符合應用程序需求的數據庫來改善程序員的工做效率。

* 以能處理大數據量、下降延遲且增進數據吞吐量的某種技術組合來改善數據訪問性能。

* 在決定使用某個NoSQL技術以前，必定要測試其是否如預期般改善了程序員工做效率和數據訪問性能。

* 用服務來封裝數據庫，即能在需求變動或技術成熟後改換其所封裝的數據庫技術。可將應用程序各部分劃分到不一樣服務中，以便爲既有程序引入NoSQL數據庫。

* 大部分應用程序，尤爲是「非戰略性的」應用程序，應該繼續使用關係型數據庫技術，至少在NoSQL技術環節還沒有更加成熟時是如此。