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

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

0 голосов
/ 31 декабря 2018

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

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

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

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

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

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

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

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

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

1 Ответ

0 голосов
/ 31 декабря 2018

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

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

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

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

PK- UserID SK- GameID GSI- Progress (PK)

Запросить всеигры по прогрессу быстро GSI Progress (PK)

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

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

...