1. Redis 1.1. 2009年首次發佈 1.1.1. 更註重原始性能和簡單性，而不是數據安全性和一致性 1.2. 主要吸引力在於它能夠同時充當分散式緩存和數據存儲 1.3. 維護一個記憶體中的數據存儲，也稱為數據結構存儲(data structure store) 1.4. 配置Redis將每 ...
1. Redis
1.1. 2009年首次發佈
- 1.1.1. 更註重原始性能和簡單性，而不是數據安全性和一致性
1.2. 主要吸引力在於它能夠同時充當分散式緩存和數據存儲
1.3. 維護一個記憶體中的數據存儲，也稱為數據結構存儲(data structure store)
1.4. 配置Redis將每個命令記錄到一個只能追加的文件(Append-Only File，AOF)中
1.5. 數據模型和API
-
1.5.1. Redis是一個鍵值存儲
-
1.5.2. 提供了一小部分數據結構，應用程式可以使用它們來創建與唯一鍵關聯的數據對象
-
1.5.3. 字元串
-
1.5.3.1. 能夠存儲最大長度為512 MB的文本和二進位數據
-
1.5.4. 鏈表
-
1.5.4.1. 鏈表(linked list)是字元串列表，允許操作列表頭部、尾部和主體中的元素
-
1.5.5. 集合和有序集合
-
1.5.5.1. 集合(set)是一系列唯一的字元串類型元素的集合
-
1.5.5.2. 有序集合(scored set)將分數(score)值與每個元素相關聯，並按分數升序維護字元串
-
1.5.6. 哈希
-
1.5.6.1. Redis哈希(hash)將字元串的鍵值映射到一個或多個字元串值
1.6. 數據分發和複製
-
1.6.1. 在初始版本中，Redis是一個單伺服器的數據存儲，這在一定程度上限制了它的可擴展性
-
1.6.2. 2015年，隨著Redis Cluster發佈，它支持跨多個節點對數據存儲進行分區和複製
-
1.6.3. Redis Cluster為一個集群定義了16384個哈希槽
-
1.6.4. 客戶端可以連接到集群中的任意節點，並提交命令來操作指定的鍵
-
1.6.5. Redis不具備對駐留在不同哈希槽和不同節點中的對象執行命令的能力
1.7. 優缺點分析
-
1.7.1. 性能
-
1.7.1.1. Redis專為低延遲響應和高吞吐量而設計
-
1.7.1.2. 主要的數據存儲是記憶體，可實現快速數據對象訪問
-
1.7.2. 數據安全性
-
1.7.2.1. Redis以數據安全性換取性能
-
1.7.2.2. 如果應用程式不能接受數據丟失，你可能不會使用Redis（或任何記憶體資料庫）作為主要的數據存儲
-
1.7.3. 可擴展性
-
1.7.3.1. Redis Cluster是Redis的主要擴展機制
-
1.7.3.2. 允許多達1000個節點來托管跨16384個哈希槽分佈的分片資料庫
-
1.7.4. 一致性
-
1.7.4.1. Redis的副本是非同步複製的，提供了最終一致性
-
1.7.5. 可用性
-
1.7.5.1. Redis Cluster為單個資料庫分片實現了一個久經考驗的主副本架構
2. MongoDB
2.1. 2009年首次發佈
-
2.1.1. 早期版本中的底層存儲引擎，稱為MMAPv1
-
2.1.2. 具有更豐富的功能集，適用於需要適應未來增長的廣泛業務應用程式
-
2.1.3. 最初流行起來是因為它易於編程和使用
2.2. 在本質上協調資料庫模型與對象模型，直接解決了眾所周知的對象關係阻抗不匹配問題
2.3. 2015年前後，開發團隊對MongoDB進行了重新設計，支持可插拔的存儲引擎架構
-
2.3.1. 新的存儲引擎WiredTiger成為MongoDB v3.2的預設引擎
-
2.3.2. WiredTiger解決了MMAPv1的許多問題
2.4. 數據模型和API
-
2.4.1. 文檔基本上是JSON對象，帶有一組在BSON（二進位JSON）規範中定義的擴展類型
-
2.4.2. 文檔由名稱-值對組成，其中欄位的值可以是任何BSON數據類型
-
2.4.3. 文檔還可以合併其他文檔（稱為嵌入文檔或嵌套文檔，以及值或文檔的數組）
-
2.4.4. 從4.0版本開始，MongoDB支持ACID，實現了多文檔事務
-
2.4.5. 事務採用二階段提交演算法，並利用底層WiredTiger存儲引擎的快照隔離功能
2.5. 數據分發和複製
-
2.5.1. 使用哈希函數產生分片鍵的結果，並映射到相應分片
-
2.5.2. 存儲鍵落在特定分片鍵範圍內，由該範圍的分片存儲
-
2.5.3. 在每個分片中，MongoDB將文檔存儲在塊(chunk)中
-
2.5.3.1. 預設情況下，一個塊最大為64 MB
-
2.5.3.2. 塊拆分是元數據更改，由插入或更新操作觸發，不涉及任何數據移動
-
2.5.4. 隨著集群中數據的增長，分片之間的數據分佈可能會變得不平衡
-
2.5.5. 每個主分片可以有多個分片副本，分片副本統稱為副本集
-
2.5.5.1. 副本集中的節點定期發送心跳消息，預設情況下每兩秒發送一次，以確認成員可用性
-
2.5.6. 支持可調節一致性
2.6. 優缺點分析
-
2.6.1. 性能
-
2.6.1.1. 最初版本的MongoDB的寫入性能不佳
-
2.6.1.2. WiredTiger存儲層推動，得到了顯著改善
-
2.6.2. 數據安全性
-
2.6.2.1. write concern的預設設置majority確保更新在副本集中的法定數節點上持久
-
2.6.3. 可擴展性
-
2.6.3.1. 使用分片和部署多個mongos查詢路由器進程來水平擴展數據收集能力
-
2.6.4. 一致性
-
2.6.4.1. 跨多個分片集合的ACID事務為開發人員提供了事務一致性功能
-
2.6.5. 可用性
-
2.6.5.1. 副本集是保證數據可用性的主要機制
3. DynamoDB
3.1. Amazon的DynamoDB是AWS雲中的核心服務產品
-
3.1.1. Dynamo是為使用Amazon網站而構建的
-
3.1.2. 需要根據使用的存儲量和應用程式的DynamoDB使用量付費
-
3.1.3. 原則是你要求DynamoDB為你做得越多，支付的費用就越多
-
3.1.4. 如果你要將系統部署到AWS，DynamoDB可能是持久層的絕佳選擇
-
3.1.5. DynamoDB的日益普及與AWS雲的應用的日益增長相得益彰
3.2. 在2012年演變為公開可用的、完全托管的DynamoDB資料庫服務
- 3.2.1. 是一種完全托管的服務，支持鍵值的低延遲查找
3.3. 作為一個完全托管的資料庫，DynamoDB最大限度地減少了應用程式所需的資料庫管理工作
-
3.3.1. DynamoDB利用其自適應容量功能來確保資料庫部署能夠滿足性能和可擴展性要求
-
3.3.2. 還有許多可選功能，能讓你更輕鬆地編寫應用程式，併為你的應用程式提供更高級別的自動化管理
3.4. 數據模型和API
-
3.4.1. 單個項目的大小限製為400 KB
-
3.4.2. 項目的主鍵值充當分區鍵，它被散列並將每個項目映射到不同的資料庫分區
-
3.4.3. 本地二級索引必須具有與基表相同的分區鍵和不同的排序鍵
-
3.4.4. 經典API使用4個核心操作（PutItem、GetItem、DeleteItem和UpdateItem操作）的變體來提供單項和多項的CRUD功能
-
3.4.5. DynamoDB最近提供替代API，稱為PartiQL，是SQL的派生語言
-
3.4.5.1. 可以使用ExecuteStatement和BatchExecuteStatement API提交SQL語句
-
3.4.5.2. DynamoDB將你的SQL語句轉換為經典API中定義的單個API調用
3.5. 數據分發和複製
-
3.5.1. DynamoDB對該鍵進行哈希處理並存儲每個項目的三個副本
-
3.5.2. 每個分區都有一個領導者和兩個追隨者
-
3.5.3. 自適應容量功能自動重新分區數據，同時保持可用性的場景
-
3.5.3.1. 分區超過了分區大小限制，約為10 GB
-
3.5.3.2. 增加了表的預配置吞吐量容量，需要支持比現有分區更高的性能
-
3.5.3.3. 配置為使用按需容量的表遇到超出其能維持的吞吐量的請求峰值
3.6. 優缺點分析
-
3.6.1. 性能
-
3.6.1.1. DynamoDB API相對簡單，可以以非常低的延遲執行
-
3.6.2. 數據安全性
-
3.6.2.1. 當領導者分區持久化修改後，更新被確認，並且表中的所有項目都被覆制到本地區域的三個分區中
-
3.6.3. 可擴展性
-
3.6.3.1. DynamoDB的自適應容量旨在重新平衡大型資料庫，以提供足夠的分區來滿足觀察到的需求
-
3.6.3.2. 預配置容量是按表分配的，意味著如果你的應用程式有10個分區，每個分區將獲得總表容量的十分之一
-
3.6.4. 一致性
-
3.6.4.1. 副本是最終一致的，因此從非領導者副本讀取過時數據是可能的
-
3.6.4.2. 可以使用強一致讀取來獲取最新的副本值，但代價是額外的容量單位和延遲
-
3.6.5. 可用性
-
3.6.5.1. DynamoDB為用戶提供服務級別協議(SLA)
-
3.6.5.2. 基本保證了全局表99.999%的可用性，單區域表99.99%的可用性
