DynamoDB: Стоит ли индексировать таблицу для одноразовой миграции?

Question

Мы переносим тонну различных таблиц с разными атрибутами в другую таблицу, используя скрипт для преобразования в новые форматы таблиц DynamoDB.

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

Одна мысль, которая возникла, состояла в том, что мы могли бы добавить глобальный вторичный индекс к таблице с использованием primaryKey + флаг переноса, чтобы мы могли просто использовать это для определения того, что необходимо для ускорения переноса.

Однако для одноразовой миграции (которая может быть запущена несколько раз в случае сбоев) я не уверен, стоит ли это затрат на создание индекса? Таблица содержит сотни миллионов элементов, и мне трудно оправдать создание огромного индекса только для ускорения сканирования. Мысли?

Answer 1

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

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