У меня есть конечная точка шлюза 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.

Есть ли способ получить это? Большое спасибо.

1
andreybleme 30 Сен 2019 в 21:04

2 ответа

Лучший ответ

Если у вас есть только прямая интеграция api-gw <-> интеграция с Dynamodb, проверьте описание - https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeTable.html и выполните два вызова, чтобы получить нужные данные.

Но я рекомендую использовать лямбда между Api Gateway и DynamoDB, что облегчит нумерацию страниц.

1
Horatiu Jeflea 30 Сен 2019 в 19:53

Это, вероятно, не идеально, но , если вы можете обновить схему таблицы DynamoDB, добавив дополнительный атрибут total для каждого элемента (и внедрив соответствующее управление счетчиком для этого атрибута), тогда это упростит только один запрос к API-шлюзу (по-прежнему нет необходимости в лямбда-вычислении или вычислении уровня хранилища другого типа, как в вопросе).

Я говорю, что, вероятно, не идеально, поскольку сложность управления [в некоторой степени] точным подсчетом total не обязательно тривиальна (> = 0). В зависимости от вашего контекста (например):

  • total может обновляться не часто, поэтому, возможно, сложность менее серьезна
  • Или, может быть, total часто обновляется, так что, возможно, это высокое обновление chattiness делает сложность более серьезной

С этими примерами связана также идея Обновление данных: требование" более свежих "данных было бы тогда, когда я упоминал, что это может привести к большей сложности в общении. При этом, даже если подсчитываемые данные сами обновляются часто, обновление total может быть преднамеренно «устаревшим» (в отличие от свежего) и, следовательно, все же уменьшать болтливость; хотя управление чем-либо, кроме [возможно, относительно] оптимальной свежести, само по себе является аспектом сложности.

Таким образом, в целом, выбор архитектуры решения, включающей этот вид верхнего уровня total, должен быть подтвержден в соответствии с типом сложности управления, который я обсуждал здесь .

1
cellepo 27 Мар 2020 в 03:53