AWS DynamoDB и Lambda: оптимизация сканирования / производительность - PullRequest
Новая
       6

AWS DynamoDB и Lambda: оптимизация сканирования / производительность

0 голосов
/ 12 января 2020

Для хранения веб-сокетов api-gateway я использую таблицу DynamoDB. При публикации в сохраненные соединения я извлекаю соединение с помощью лямбда-функции через: 

const dynamodb = new DynamoDB.DocumentClient();
const { Items, Count } = await dynamodb.scan({ TableName: 'Websocket' }).promise();

// post to connections

Это не очень быстро; запрос занимает около 400 - 800 мс, что может быть лучше, на мой взгляд. Могу ли я что-то изменить в моей реализации, или, может быть, есть еще один aws -сервис, который лучше хранить для хранения этой крошечной информации о websocket-соединении (на самом деле это просто небольшой идентификатор соединения и идентификатор пользователя)?

1 Ответ

0 голосов
/ 12 января 2020

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

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

  1. Вместо сохранения всех идентификаторов веб-сокетов в виде отдельной строки, рассмотрите возможность иметь одну запись, в которой хранятся идентификаторы, чтобы вы могли выполнить один запрос (не сканировать) и продолжить.

    Минусы :

    a. множественные записи в одну и ту же строку приведут к состоянию гонки. и некоторые чтения могут быть потеряны, вы можете использовать условную запись для обновления записи, чтобы решить эту проблему (иметь постоянно увеличивающуюся версию и обновлять запись, только если версия в db = версия, которую вы читаете из db)

    b. Существует ограничение на размер одного документа в DynamodB. На данный момент это 400 КБ.

  2. Сохраните идентификатор websocket как отдельную строку, но сгруппируйте их по разным ключам и создайте вторичный индекс для этих ключей. Храните ключи в одном ряду. При выполнении выборки сначала получите все соответствующие группы, а затем запросите (не сканируйте) все элементы этой группы. Это точно не решит вашу проблему, но вы можете делать интересные вещи, например, скажем, есть 10 групп, каждую секунду отправляются сообщения для 1 группы. это обеспечит сбалансированную нагрузку на инфраструктуру отправки сообщений. И вы можете продолжать увеличивать количество групп по мере увеличения пользователя.

  3. Сохраняйте идентификаторы в кеше, например aws elasti c, кэш и добавляйте / удаляйте идентификаторы по мере создания новых записей в DynamodB с использованием aws лямбда и dyanmodb потоков. Это гарантирует, что вы читаете быстро. В то же время, если кэш выходит из строя, вы можете использовать Dynamodb, чтобы заполнить его снова, выполнив сканирование на DynamodB.

    Минусы:

    a. Дополнительный компонент для обслуживания.

...