Лямбда с DynamoDB Trigger на ключе раздела таблицы с более чем 500000 различных значений - PullRequest
Новая
       40

Лямбда с DynamoDB Trigger на ключе раздела таблицы с более чем 500000 различных значений

1 голос
/ 19 июня 2019

В настоящее время мы разрабатываем таблицу DynamodB для хранения определенных атрибутов файла.Есть 2 основных столбца

  1. Дата: - Содержит дату в формате ГГММДД, например: -20190618
  2. Имя файла: - xxxxxxxxxxx.json

В настоящее время ключом раздела является Дата, а ключом сортировки - FileName.Мы ожидаем около 500000 файлов с различными именами файлов в каждый день (это может увеличиться с течением времени).Имена файлов будут повторяться каждый день, то есть типичная схема будет такой, как показано ниже

Дата Имя файла 20190617 abcd.json 20190618 abcd.json

У нас есть серия запросов, основанная на Дата и триггер динамодаба.Запросы работают отлично.В настоящее время мы наблюдаем, что число одновременных лямбда-казней ограничено до 2, поскольку мы делимся по дате.Пытаясь улучшить параллелизм лямбды, мы столкнулись с двумя решениями

1). Ссылаясь на следующую ссылку (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-sharding.html)), одной из идей является добавление фиксированного числа случайных суффиксов для поля даты, т. Е. (20190617.1 к20190617.500) для разделения данных на 500 разделов с 1000 записями в каждом. Это обеспечит количество параллелизма, а также будет минимальное изменение для запроса

2) Второй вариант - изменить разбиение таблицы следующим образом. РазделКлюч: - FileName и SortKey: - Дата.Это приведет примерно к 500000 разделам (которые могут увеличиться).Для запросов по дате нам нужно будет добавить GSI, но мы достигнем большего параллелизма в Lambda

. Мы не создали таблицу с 500000 разделами (которая может увеличиться).Любое тело имеет такой опыт ... Если это так, пожалуйста, прокомментируйте

Любая помощь приветствуется

Ответы [ 2 ]

2 голосов
/ 19 июня 2019

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

Это не так.

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

Вы можете иметь ключи раздела 100 КБ и только один раздел.

Если вы раздвигаете пределы DDB, то да, у вас может получиться только один ключ раздела в разделе ... но это не типично.

Белая книга DDB содержит некоторые подробности о том, как работает DDB ...

1 голос
/ 19 июня 2019

Разделение по имени файла не имеет большого смысла, если ваш шаблон доступа должен запрашивать по дате.

Вместо этого идея увеличения количества разделов для каждой даты путем добавления суффикса кажется вполне приемлемой. Но вместо добавления случайного суффикса вы можете подумать о добавлении стабильного суффикса на основе имени файла:

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

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

Если у вас будет около 10000-50000 предметов на раздел, это, вероятно, будет замечательно.

Надеюсь, это поможет

...