DynamoDB
DynamoDB是AWS託管的商業化的NoSQL數據庫，具有如下特點：
1. 數據存儲基於SSDs：
1. 支持無限擴容：分佈式存儲，水平擴展
1. 低延遲相應：毫秒級的相應延遲
3. 支持高併發：每秒吞吐量可配置
4. 支持高可用：三個數據中心間數據複製
5. 豐富的數據類型支持
DynamoDB的邏輯組織結構
DynamoDB中數據的邏輯組織結構如下圖所示：
數據庫邏輯組織結構
Table：類似於關係型數據庫的表，其內包含多個數據項，表內數據項個數沒有限制。
Item：類似於關係型數據的一行記錄，由主鍵和屬性組成。每個Item的數據大小上限為400 KB。
主鍵：主鍵對一條數據項進行了唯一性標誌，在DyanmoDB中主鍵可以分為兩種組成類型
- 只包含HashKey：HashKey又稱為分區鍵
- 包含HashKey+RangeKey組合，RangeKey是數據項的排序鍵。
屬性：每個Item的屬性可以不一致
DynamoDB支持的數據類型
DynamoDB支持的數據類型如下圖所示
數據類型
1. 只有String、數值型和二進制類型可以用作表的主鍵：分區間或排序鍵。
2. 對於集合類型包括字符串、數值和二進制
DyanmoDB中的二級索引
Dynamodb支持對Table建立二級索引，其支持兩種類型的索引：全局索引和本地索引。
全局索引和本地索引
主鍵選擇:
- 全局索引可以選擇任意屬性作為新的HashKey和RangeKey
- 本地索引只能選擇與表相同的HashKey，不同的RangeKey
存儲容量
- 全局索引獨立存儲，本地索引與表一起存儲，容量上限為10G。如果
單表可建立的索引個數
- 全局二級索引默認為20個，不同區不太一樣，可以調整
- 本地二級索引上限為5個
二級索引為用戶提供靈活的查詢設計。
關係模型在DynamoDB中的映射
1:1關係模型
對於1:1類型的關係模型：
- 設計表格或者GSI時候採用Hash key做主鍵
1:N關係模型
- 設計表格或者GSI時採用Hash key + Range Key做主鍵
1:N關係模型
M:N關係模型
在DynamoDB的表中表述M:N的關係模型，一般採用如下策略：
- 表格採用Hash key + Range Key做主鍵，且
- 選擇反轉的Hash key + RangeKey做GSI
通過主鍵和全局二級索引的反轉來實現M:N關係中兩個方向的查詢。例如系統中的關注功能，每個賬號可能關注（follow）多個其他賬號，該賬號也可能被多個其他賬號關注。則在系統中對於某個賬號而言，可能需要獲取如下情境下的數據：
- 獲取我所關注列表
- 獲取我的粉絲列表
在NoSQL我們做如下簡化設計：
數據庫結構設計示例
基於如上的表設計，可以便捷的查詢當前用戶的粉絲以及其關注的賬號列表。
DynamoDB的一些實踐
Hash Key設計
DynamoDB表中的HashKey分區鍵用來將數據進行分區，在底層存儲中，DynamoDB會基於一致性Hash策略，根據分區鍵計算出來的Hash值，將數據分散到不同的分區。因此，良好的分區鍵設計能夠有效的保證在不同分區鍵的數據存儲均衡，避免發生數據傾斜。
HashKey選擇原則就是取值儘量分散，以保證儘量產生不同的Hash值。例如：
對於用戶賬號而言，我們選擇用戶的登錄賬號ID作為主鍵比較合適，而選擇性別或姓名則不太合適。
大數據項的存儲
如果要存儲的單行數據中存在比較大的數據，則設計要基於數據的實際類型進行慎重考慮。考慮的維度基於如下兩點：
- 單個數據項是否能夠容納
- 數據的熱度
對於第一條，DynamoDB表中一個數據項的上限是400KB，如果存儲比較大的數據將超過400KB，則必須考慮將這些數據分開存儲。
大數據項單獨存儲
分表存儲
我們可以將這些屬性數據存儲到額外的DynamoDB表中，新表與原表選擇同樣的HashKey映射即可。
分佈式文件系統存儲
對於圖片或視頻資源，我們可以將這些數據存儲到第三方系統，如S3或Hdaoop中，DynamoDB表中保存數據的URI即可。
大數據項的分開存儲還有一個好處就是降低成本，減少對DynamoDB吞吐量的消耗。
熱點數據處理
好的HashKey設計有助於將數據均衡的存儲到不同的分區，但不能避免對單個分區數據的熱查詢。例如，一些典型的熱點新聞信息，則會導致對某條新聞的大量查詢。可能導致單個分區具有大數據量的併發查詢，從而撐破DynamoDB的預配置吞吐量。
分區熱點數據
對於熱數據的處理，典型且有效的方式是通過緩存系統來緩解過多的查詢直接打到後端的DB。當然，緩存系統不一定是像Redis一樣的分佈式緩存系統，也可能是不同其他級別的緩存，比如，服務器端的本地緩存，應用服務器的緩存。具體選擇哪種緩存解決方案也具體情況具體分析了。
引入緩存系統也隨之帶來新的問題，如：
- 如何保證緩存一致性
- 如何保證緩存的高可用
- 如何保證緩存系統的高可擴展
- .....
時序型數據處理
時序型數據，例如用戶瀏覽記錄、操作記錄等等，這些數據具有以下特點：
- 持續且大量：數據量比較大，且持續產生。每秒、每天、每週等等
- 冷熱數據：最近的數據訪問率較高，歷史性數據訪問率較低
DynamoDB基於SSD存儲，且單表存儲容量沒有上限，大量的數據，如幾百億行數據可以完全存儲於單表。且，通過合適的主鍵和索引設計，完全可以在毫秒級獲取數據（根據Key，而非全表掃描）。基於這種存儲方式的弊端是：
<code>沒有充分利用時序性數據的冷熱特性，區分新近和歷史數據，造成存儲和吞吐量的浪費/<code>
因此，基於時序型數據的表設計一般採取如下策略：
- 依照時間週期創建多個Table：可以每天、每週、每月或其他週期定期生成新的Table用於存儲當前週期內產生的時序數據。
- 對歷史數據歸檔，降低DynamoDB的存儲浪費：對於近期的熱數據，提高Table吞吐量。對於冷數據，歸檔到第三方系統，如HBase、S3等等
基於組合鍵進行多屬性條件查詢
表中可以基於主鍵進行查詢，但如何應對其他的多屬性條件下的查詢呢？- 組合鍵
DynamoDB表支持建立全局二級索引
DynamoDB Stream
DynamoDB Stream可以捕獲表中的修改事件，並已流記錄的形式近實時的寫入到流系統中。具體可捕獲的事件有：
- Item修改事件：能夠獲得已修改屬性的修改前和修改後的數據
- Item新增事件：獲取新增數據項的所有屬性數據
- Item刪除事件：在刪除前捕獲該條數據項
基於DynamoDB Stream的特性，一般應用中會結合AWS Lambda服務設計出發器。在Lambda代碼中實現捕獲後的業務處理。
Lambda直接處理Stream數據
最後
DyanmoDB是商業化的分佈式NoSQL數據庫，基於AWS的全面託管，對於用戶而言不需要關注分佈式集群運營和維護的成本以及風險，只關注應用的業務實現。另外，DynamoDB是分佈式存儲系統的一種實現，肯定要解決分佈式存儲系統所面臨的核心問題，如高性能、高可用、可擴展等。
閱讀更多 瘋狂架構 的文章
