Как использовать ограничение graphQL в aws ampify

Question

Я новичок в использовании aws -amplify, и у меня есть функция, аналогичная этой, которая выполняет запрос с именем listItems и возвращает элементы, для которых isEnbled истинно (из DynamoDB). Я хочу, чтобы это отфильтровало всю таблицу, которая может быть огромной. Поэтому я не могу просто установить предел вроде 1000 и оставить его на этом уровне. Есть ли способ указать безграничный запрос и сканировать все в таблице? Или есть другое свойство, которое я должен использовать вместо этого?

 import { API } from 'aws-amplify'

 export async function getAllEnabledListItems() {
      const { data } = await API.graphql({
      query: queries.listItems,
      variables: { filter: { isEnabled: { eq: true } }, limit: 10000 },
      authMode: 'AMAZON_COGNITO_USER_POOLS' 
    })
 return data
 }

Answer 1

DynamoDB Scan vs Query

Вместо того, чтобы сканировать каждый элемент и затем фильтровать, вам следует подумать о добавлении GSI к «включенным» элементам в таблице, а затем запросить его. Это будет намного более эффективным (то есть быстрее и дешевле) при выполнении запросов за счет немного более высоких затрат на запись и хранение. Обычно это хороший компромисс.

Разбивка на страницы

Независимо от того, запрашиваете вы или сканируете, вам придется иметь дело с разбивкой на страницы DynamoDB, когда размер набора результатов станет слишком большим (не более 1 МБ). Если набор результатов достигает порогового значения, вы получите эту первую страницу результатов и LastEvaluatedKey. Затем вам нужно будет снова запросить, передав значение LastEvaluatedKey как ExclusiveStartKey. Вы продолжаете делать это, пока не получите обратно LastEvaluatedKey.

Если вы обновите схему AppSyn c и преобразователь, чтобы передать этот LastEvaluatedKey обратно как paginationToken (или как вы хотите его называть ), то вы можете повторно запрашивать из своего приложения, передавая последний токен, чтобы получить следующую страницу результатов. Если вам не нужны все результаты сразу, вы можете лениво вызывать их, чтобы запрашивать другую страницу или результаты только тогда, когда они вам понадобятся.

Другие соображения

Есть и другие подходы.

Если вы знаете, что отфильтрованный набор результатов всегда будет <1 МБ, можно было бы заменить источник данных DynamoDB на Lambda и постепенно сканировать и фильтровать (или запрашивать) страницы DynamoDB в al oop внутри лямбда-выражения перед возвратом отфильтрованных результатов в ваш распознаватель AppSyn c, а оттуда вернитесь в ваше приложение. </p>

Проблемы включают:

• Как гарантировать, что отфильтрованные результаты установленное значение всегда будет меньше 1 МБ (ограничение AppSyn c)
• Как гарантировать, что лямбда вернется вовремя (AppSyn c ограничение времени)
• Вы сканируете всю таблицу (если вы просматриваете, а не запрашиваете), но вас интересует только подмножество этих элементов (элементы "isEnabled")

В качестве альтернативы, если вы можете сегментировать Разделите свои элементы (или элементы «isEnabled») на несколько групп, вы можете разложить сканирование (или запрос), чтобы реализовать параллельное сканирование (или запросы) перед накоплением результатов, как раньше. Это может обеспечить более быстрое сканирование, но вы по-прежнему будете ограничены по времени и размеру полезной нагрузки, поэтому это по-прежнему проблематично c для сканирования огромных таблиц.

Сводка

• DynamoDB принудительно разбивает результаты на страницы (макс. 1 МБ)
• AppSyn c ограничивает размер полезной нагрузки (макс. 1 МБ, меньше, если вы также собираетесь использовать подписки)
• Сканирование DynamoDB менее эффективно, чем запросы. Подумайте о добавлении GSI, чтобы вы могли запрашивать вместо сканирования / фильтрации.
• Хаки для накопления страниц результатов внутри Lambda или AppSyn c VTL - это fr agile, и, вероятно, не будут работать для огромных таблицы
• Для реализации разбивки на страницы в вашем приложении потребуется обновление схемы AppSyn c для передачи «токенов разбиения на страницы» DynamoDB (LastEvaluatedKey / ExclusiveStartKey) внутрь и наружу.

Добавление GSI, его запрос (а не сканирование), а затем добавление разбивки на страницы в схему и приложение AppSyn c - наиболее надежное решение.