Глобальные и локальные вторичные индексы

Первичный ключ DynamoDB определяет единственный эффективный путь выполнения запросов к таблице. Если Вам нужно выполнять запросы по другому атрибуту — например, найти все заказы для идентификатора продукта, когда ключом раздела таблицы является CustomerId, — без вторичного индекса пришлось бы выполнять затратную операцию Scan.

Вторичные индексы решают эту проблему, поддерживая отдельную автоматически обновляемую копию данных, организованную вокруг другого ключа. DynamoDB предлагает два типа: Global Secondary Indexes (GSI) и Local Secondary Indexes (LSI), каждый со своими компромиссами.

Global Secondary Index позволяет определить полностью отличный от базовой таблицы ключ раздела (и, при необходимости, ключ сортировки). GSI действительно является глобальным: он охватывает все разделы базовой таблицы. Вы можете выполнять запросы к GSI, чтобы находить элементы по любому атрибуту, заданному в качестве ключа раздела GSI.

GSI имеют собственную выделенную пропускную способность (или наследуют режим On-Demand), независимую от базовой таблицы. Для одной таблицы можно создать до 20 GSI, а добавлять или удалять GSI можно в любое время в уже существующей таблице.

Local Secondary Index использует тот же ключ раздела, что и базовая таблица, но другой ключ сортировки. LSI называются «локальными», поскольку запросы к ним выполняются только в пределах одного раздела (элементов с одинаковым ключом раздела). Поэтому LSI идеально подходят для запросов заказов конкретного клиента с сортировкой по различным атрибутам.

LSI необходимо определить при создании таблицы — позднее добавить или удалить их нельзя. Каждая таблица может содержать до 5 LSI. LSI используют выделенную пропускную способность базовой таблицы (отдельная пропускная способность не предоставляется) и подпадают под ограничение хранения 10 GB на ключ раздела для совокупности данных базовой таблицы и LSI.

Для ясности на экзамене приведём сравнение бок о бок:

• Ключ партиции: у GSI может отличаться от ключа базовой таблицы, а у LSI должен совпадать с ним
• Ключ сортировки: оба индекса поддерживают ключ сортировки, отличный от ключа базовой таблицы
• Когда создаётся: GSI можно создать в любое время, а LSI — только при создании таблицы
• Пропускная способность: у GSI есть собственная пропускная способность, а LSI использует пропускную способность базовой таблицы
• Согласованность: чтение из GSI поддерживает только итоговую согласованность, а чтение из LSI может быть строго согласованным
• Ограничения: до 20 GSI и до 5 LSI на таблицу

При создании индекса Вы выбираете, какие атрибуты будут спроецированы (скопированы) в него:

• KEYS_ONLY: только первичный ключ базовой таблицы и ключ индекса — самый маленький индекс, для неключевых атрибутов требуются дополнительные вызовы GetItem
• INCLUDE: ключевые атрибуты и определённый Вами список дополнительных атрибутов — компромисс между размером и способом доступа
• ALL: в индекс проецируются все атрибуты — наиболее гибкий вариант, но с более высокими затратами на хранение и запись

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

Для запроса к GSI используется тот же API Query, но указывается параметр --index-name. Запрос выполняется по схеме ключей GSI, а не базовой таблицы. Запросы к GSI всегда используют итоговую согласованность: GSI обновляется асинхронно после записи в базовую таблицу, поэтому возможна небольшая задержка.

Если у элемента базовой таблицы отсутствует атрибут ключа партиции GSI, этот элемент вообще не включается в GSI (шаблон разреженного индекса). Это мощный приём для индексации только подмножества элементов, например всех заказов со статусом PENDING, если ключом партиции GSI является Status.

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

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

Перегрузка GSI — это продвинутый приём проектирования одной таблицы, при котором в одной таблице хранятся разные типы сущностей, а для них используется общий атрибут ключа GSI (например, GSI1PK и GSI1SK), заполняемый по разным шаблонам в зависимости от типа элемента. Благодаря этому каждый тип сущности получает собственный эффективный путь выполнения запросов через один GSI.

Пример: для элементов User задайте GSI1PK = 'COUNTRY#US' и GSI1SK = username, а для элементов Order — GSI1PK = 'STATUS#PENDING' и GSI1SK = orderDate. Запрос к GSI с соответствующим префиксом эффективно возвращает нужный тип сущности.

Ограничение скорости GSI происходит независимо от базовой таблицы. Если выделенных для GSI WCU недостаточно, записи элементов, проецируемых в GSI, будут ограничиваться — даже если у базовой таблицы достаточно пропускной способности. Отслеживайте показатели ConsumedWriteCapacityUnits и ThrottledRequests отдельно для каждого GSI.

Распространённая ошибка — выделить GSI меньшую пропускную способность, чем у базовой таблицы, а затем столкнуться с ограничением скорости при резком увеличении интенсивности записи в GSI. Используйте автоматическое масштабирование для GSI или выберите режим по требованию, чтобы избежать этого.

Рекомендации для экзамена SAA-C03:

• Нужно выполнять запросы по совершенно другому атрибуту → GSI
• Нужно выполнять запросы в той же партиции, но с другой сортировкой, и это известно во время создания → LSI
• Нужно строго согласованное чтение по альтернативному ключу сортировки → LSI (единственный вариант, поскольку GSI используют итоговую согласованность)
• Есть десять или более разных шаблонов запросов → рассмотрите проектирование одной таблицы с перегрузкой GSI вместо множества отдельных таблиц
• Нужно только получать все элементы для анализа → ещё раз оцените, подходит ли DynamoDB в качестве базы данных

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

Отслеживать ход заполнения можно в консоли или через API DescribeTable, проверяя поле IndexStatus индекса: во время заполнения оно имеет значение CREATING, а после завершения — ACTIVE. Не выполняйте запросы к GSI, пока его статус не станет ACTIVE.

Проверьте, насколько Вы поняли концепции AWS Solutions Architect (SAA-C03) из этого урока.

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