Когда стоит компенсировать использование локального вторичного индекса в DynamoDB?

Question

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

Я сохраняю данные о прогрессе игры для пользователей. PK - это идентификатор пользователя. Мне нужно уметь:

1. Узнайте о прогрессе пользователя в конкретной игре.

2. Получить все готовые / в процессе игры для пользователя.

Таким образом, я могу спроектировать свой SK как progress_{состояние}, чтобы можно было быстро запрашивать все игры по прогрессу (состояние представляет начало / окончание), или я могу спроектировать свой SK как progress_{gameId}, чтобы иметь возможность запрашивать ход выполнения данной игры. быстро. Тем не менее, я не могу использовать оба только SK. Когда я выбрал один, для другой операции потребуется сканирование.

Поэтому я думал об использовании LSI, который добавит накладные расходы ко всей таблице, как отмечает Amazon здесь:

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

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

У кого-нибудь есть реальный опыт с такой проблемой? Я не смог ничего найти по этой теме.

Answer 1

Когда вы разрабатываете таблицы DynamoDB, основным фактором стоимости является IOPS для чтения и записи.

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

Затем, возвращаясь к вашему сценарию использования SK для прогресса, было бы лучше использовать атрибуты и определить вторичные индексы, так как вам потребуется обновить состояние позже (что невозможно с PK и SK в таблице).

Таким образом, основываясь на вашем сценарии использования и информации, приведенной в вопросе, вы можете определить схему как;

PK- UserID SK- GameID GSI- Прогресс (ПК)

Быстрый запрос всех игр по прогрессу GSI Progress (PK)

Примечание: если это для конкретного пользователя; Вы можете изменить его на LSI Progress.

Быстрый запрос прогресса данной игры (при условии, что для данного пользователя) Запрос с использованием UserID (PK) и GameID (SK) таблицы