使用 AWS DynamoDB 筆記

使用 AWS DynamoDB 主要有幾個原因

1. 需要 Key-Value Datastore
2. 需要 stability, scalability (heavy write)
3. 不想要自己管理Cluster/Sharding、OS tuning、failover、Disaster Recovery等

稍微比較了幾個資料庫，其中 Redis 的設計其實更適合我們，因為我們有部分資料需要 expire  還有 increment，但是單一 Redis instance 很快就會不夠我們用，而 Redis 官方說 Redis Cluster 目前還是 alpha quality ，不太適合我們目前這個以穩定性為第一要務的 project ，我試著參考 DynamoDB、Riak 架構設計做 Redis Sharding Cluster ，但是信心不夠拿來放 persistent data，主要是在 Redis nodes 數量變動的時候，很難確保資料的一致性，所以最後還是決定先使用比較穩定的 DynamoDB，等到 Redis 有依區塊的移動（migrate）資料的功能後，或是AWS支援Redis Cluster 我們就可以考慮離開DynamoDB。

DynamoDB 測試起來有幾個地方比較不習慣

1. 像是一個Table要建很久，下建立Table指令之後大概要等個幾十秒後才能使用這個Table，所以最好預先建立Table，但是動態建立Table卻又很好用，因為可以一次丟掉整個Table，刪除個別資料又慢又貴。
2. 要自己觀察Database大概需要的讀寫量，並且告訴Amazon可能會用到多少，最好能夠自己動態調整DynamoDB的 read/write unit，因為DynamoDB是按使用者宣告的讀寫次數收費，使用量超過宣告時則會出現error，這有點麻煩。
3. 沒有 expire 功能，大概一般Database也很少有這個功能吧，利用不同建立不同時間區分的Table的方式可以達到類似 expire 的概念，作法可以參考http://stackoverflow.com/questions/9343909/how-do-i-expire-keys-in-dynamodb-with-boto/21323698#21323698
4. Rang Key 不是拿來做 Range Query 的，跟我看到這個名稱的第一聯想相左。Range key 是 default sorting attribute，Rang Key也是完整Key的一部分，所以如果將來想依特定時間區間搜尋的話要用別的方法，在儲存的時候就要先處理。