Lambda with DynamoDB觸發器在表上具有超過500000個不同值的分區鍵

Question

我們目前正在設計一個dynamodb表來存儲某些文件屬性。 有2個主要欄目

1. 日期： - 包含YYMMDD格式的日期，例如：-20190618
2. FileName： - xxxxxxxxxxx.json

目前，分區鍵是Date，排序鍵是FileName。 我們預計每天大約有500000個文件具有不同的文件名（這可能會在一段時間內增加）。 文件名將每天重復相同，即典型的模式如下所示

Date FileName 20190617 abcd.json 20190618 abcd.json

我們有一系列基於Date和dynamodb觸發器的查詢。 查詢工作得很好。 目前我們觀察到的是並發lambda執行的數量限制為2，因為我們是按日期分區。 在嘗試改善lambda的並發性時，我們遇到了兩個解決方案

1）參考以下鏈接（ https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-sharding.html ），一個想法是為Date Field添加固定數量的隨機后綴，即（20190617.1到20190617.500）將數據拆分為500個分區，每個分區有1000條記錄。 這將確保一定程度的並發性，並且對查詢的更改也很少

2）第二個選項是更改表的分區，如下所示：分區鍵： - FileName和SortKey： - Date。 這將導致大約500000個分區（可以增加）。 對於按日期查詢，我們需要添加一個GSI，但我們將在Lambda中實現更多的並發性

我們還沒有創建一個包含500000個分區的表（可以增加）。 任何機構都有這樣的經歷......如果有，請評論

任何幫助表示贊賞

Answer 1

您似乎錯誤地認為分區鍵和分區之間存在一對一的對應關系。

不是這種情況。

分區數由表大小和吞吐量驅動。 分區鍵由DDB進行散列，數據存儲在特定分區中。

您可以擁有100k分區密鑰，只有一個分區。

如果你正在推動DDB的限制，那么你可能最終只能在一個分區中使用一個分區鍵...但這不是典型的。

DDB白皮書提供了DDB如何工作的一些細節......

Answer 2

如果您的訪問模式是按日期查詢，則按文件名分區並沒有多大意義。

相反，通過添加后綴來增加每個日期的分區數的想法似乎很好。 但是，您可以考慮根據文件名添加穩定的后綴，而不是添加隨機后綴：

你可以使用文件名的第一個字母來獲得大約30個分區 - 假設文件名是隨機的。 唯一的麻煩是某些字母可能比其他字母更為常見，從而產生偏差的子分區

或者，您可以獲取文件名的哈希值，並將其用作分區鍵的后綴。 散列函數可以是一個相對簡單的散列函數，它產生一個目標數值，該值對應於您希望為每個日期分配的子分區數。

如果每個分區最終得到大約10000-50000個項目，那么它可能會很棒。

希望這可以幫助