只要開好table, 依照預期的使用情境設定需要的throughput, service就能夠完美運轉了嗎?
嗯... 不完全是
如果你的primary key選擇不當或是table的讀寫過度集中在某幾個item的話,
系統很可能會達不到provisioned throughput
以下是你需要特別注意的:
[1] 讓讀寫平均分散在整個table
Amazon DynamoDB會將一個table切成好幾個partition, 而整個table的throughput會平均分配給各個partition.
Total provisioned throughput/partitions = throughput per partition
不過partition
跟思念一樣都是很玄的東西
Amazon DynamoDB的官方文件只輕描淡寫的說是依照hash key來決定item是屬於哪個partition
我們無從得知我們選擇的key是否適當以及table實際上被切成幾個partition
如果table整體的read throughtput是100, 而你的讀取永遠都是落在四個partition中的同一個,
那你對這個table實際上read throughput其實只有25啊!
這是相當嚴重的問題, 錢可不能白花(插腰)
對此有不少人在forum提出相關的問題
*
Partition size/key range info
*
DynamoDB Hash key partition strategy
** DynamoDB currently does not expose information about the number of individual partitions, their size, and the location of the data within them.
As such, it also does not expose any explicit control to tune how partitions are laid out.
It is all done automatically, seamlessly and behind the covers by the service on the user's behalf. This is a big part of our strategy to minimize the user's administrative costs. by Stefano@AWS
** DynamoDB will take the value you supply and hash it internally. Therefore, you do not need to worry about consecutive numbers or keys with a similar prefix.
For example, (the actual hash would be longer, but this is the idea):
| hash-key value |
DynamoDB hash |
| 400234 |
2c15fa5f1 |
| 400235 |
0e2805bcd |
| 400236 |
0dad171e6 |
DynamoDB would partition these three items based on the DynamoDB hash so their placement should be spread amongst the data set. by Bjorn@AWS
看起來不需要擔心使用的hash key是連續的或是擁有相同的prefix,
而是需要考慮我們選擇的hash key是不是會讓整個table的存取不夠平均分散在各個partition.
我們至少可以做的就是讓hash key的base夠大, 降低集中存取某個partition的機率
[2] 瞭解table的存取模式是否具有時間相關性
以電子郵件為例, 通常是照時間排序來呈現所以越久以前的信件被顯示的機率就越低
與其將所有的信件都塞在同一個table, 熱門及冷門資料混雜(可能提高集中存取的可能性)
我們可以週期性的產生新的table, 將新的熱門的資料放在一起, 給予較高的throughput
並逐步調低舊table的throughput以節省花費
如果這些資料在一定的時間內會過期, 使用這個方法我們就可以用刪除整個table來取代單筆資料刪除(需要多一倍的寫入throughput)
最後的最後, 如果想知道table是否能達到設定的throughput最簡單的方法就是實際測測看!
只要在發生ThrottlingException時, 用rps搭配item大小算出throughput是否接近設定值就可以囉~
也可以直接參考cloudwatch的資料, 不過我覺得自己算卡安心
ref:
Guidelines for Working With Tables
更新:
Amazon DynamoDB - Data Modeling and Scaling Best Practices | AWS re:Invent 2014
