根據docs，我知道 DynamoDB 將獲取提供的磁區鍵的值并通過散列函式來決定資料應該去哪個物理位置。
這是否意味著使用連續但仍然唯一的磁區鍵寫入專案會產生熱磁區鍵？
例如，插入磁區鍵值為 10001、10002、10003、10004 的專案是否允許跨磁區均勻分布資料？
還是會隨機生成一個磁區鍵值，例如 UUID，使其分布更均勻？
uj5u.com熱心網友回復：
DynamoDB 支持兩種不同的主鍵：
- 磁區鍵
- 磁區鍵 排序鍵
磁區鍵
如果你有一個只有一個磁區鍵的主鍵，你永遠不會遇到熱磁區問題，因為在只有一個磁區鍵的表中，沒有兩個專案可以具有相同的磁區鍵值。
您的鍵始終是唯一的，DynamoDB 的內部散列函式將始終輸出唯一的散列，然后您的所有資料將始終均勻分布在邏輯和物理磁區中。
例如，這是 10001 的 MD5 哈希： d89f3a35931c386956c1a402a8e09941
這是 10002 的 MD5 哈希值： 9103c8c82514f39d8360c7430c4ee557
盡管 10001 只增加了 1，但整個散列是不同的，與 10002 的 MD5 散列完全不同。
從一致性哈希的角度來看，UUID 值或增量值之間沒有區別。
磁區鍵 排序鍵
如果您的主鍵也包含排序鍵，如果您不小心，您可能會遇到熱磁區問題，因為現在您可能有重復的磁區鍵值。
具有相同磁區鍵值的所有專案物理存盤在一起，按排序鍵值排序。
如果您沒有盡可能明確的主鍵，您可以創建熱磁區。
讓我給你舉個例子：
一個電子商務網站決定像這樣設計他們的訂單表，當前日期是磁區鍵，排序鍵是專案 ID：
--------------- ----------
| Partition Key | Sort Key |
--------------- ----------
| 19/10/2021 | item3000 |
| 19/10/2021 | item3001 |
| 20/10/2021 | item4000 |
--------------- ----------
在這種規模下，這可能作業得很好——在上面的例子中，他們每天處理 1000 件物品，這作業得很好。
黑色星期五 - 26/11/2021 - 到貨，他們現在一天有超過 20000 個訂單：
--------------- -----------
| Partition Key | Sort Key |
--------------- -----------
| 26/10/2021 | item6000 |
| 26/10/2021 | item15000 |
| 26/10/2021 | item27000 |
| 27/10/2021 | item27100 |
--------------- -----------
這將產生一個巨大的熱磁區問題，因為2021 年 10 月 16 日的所有20000 多個訂單現在只寫入一個單獨的磁區鍵值（正如我提到的，具有相同磁區鍵的專案將存盤在一起）。
該26/11/2021磁區鍵將重金請與熱，減緩資料庫的性能，你將試圖處理訂單，最終，你會失去了收入，由于緩慢的應用程式的性能。
The table should be designed in a way to allow for more distinct primary key values in relation to the total primary key count (total items) - write sharding (random or calculated) would prevent this issue if dates must be used as a partition key.
If you do not have a sort key as part of your primary key, do not worry about hot partitions.
If you do have a sort key as part of your primary key, design your table schema in a way that the combination of your partition sort key is as unique and distinctive as possible to avoid hot partitions.
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/326601.html