使用 AWS API 網關 + DynamoDB 進行分頁

Question

我有一個 API 網關GET端點，它掃描 DynamoDB 表並根據 Limit 參數檢索結果：

requestTemplates:
          application/json: >-
            {
              "TableName": "employee",
              "Limit": 2
            }

它工作正常，當我發送limit = 2時，對此請求的響應是：

{
   "Count":2,
   "Items":[
      {
         "id":{
            "S":"18"
         },
         "department":{
            "S":"sales"
         },
         "name":{
            "S":"Roger"
         }
      },
      {
         "id":{
            "S":"16"
         },
         "department":{
            "S":"technology"
         },
         "name":{
            "S":"Petterson"
         }
      }
   ],
   "LastEvaluatedKey":{
      "id":{
         "S":"16"
      }
   },
   "ScannedCount":2
}

問題是：我在這個表中存儲了 20 條記錄，並且ScannedCount和Count都等於 2。

我真的需要知道我存儲的記錄總數才能使分頁前端組件正常工作。

我查看了文檔並看到此請求的預期結果將是ScannedCount = 2和Count = 20 。

有沒有辦法擁有它？ 非常感謝。

Answer 1

如果您只有直接集成 api-gw <-> dynamodb 集成，請檢查 describe - https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeTable.html並執行兩次調用以獲取所需的數據。

但我建議在 Api 網關和 DynamoDB 之間使用 Lambda，這將有助於分頁。

Answer 2

這可能並不理想，但如果您可以更新您的 DynamoDB 表架構以在每個項目上包含一個額外的total屬性（並實現該屬性的相應計數管理），那么這將促進一個 API 網關請求（仍然沒有 Lambda 或如問題中所需的其他類型的存儲庫層計算）。

我說可能並不理想，因為管理 [在某種程度上] 准確total的復雜性不一定是微不足道的 (>= 0)。 根據您的上下文（例如）：

• total可能不會經常更新，因此復雜性可能不那么嚴重
• 否則可能total更新頻繁，所以可能高更新的閑聊使復雜性更加嚴重

與這些示例相關的還有數據新鮮度的想法：當我提到時，需要“更新鮮”的數據會更加復雜。 話雖如此，即使被計算的基礎數據本身經常更新，更新total也可能故意“陳舊”（而不是新鮮），因此仍然會減少閑聊； 盡管除了 [也許相對] 最佳新鮮度之外的任何東西的管理本身就是復雜性的一個方面。

所以一般來說，選擇構建一個涉及這種頂級total的解決方案應該被確認值得我在這里討論的管理復雜性類型。