Масштабируемость DynamoDB: как спроектировать ключ партиции против индекса
Как описано в https://aws.amazon.com/blogs/database/choosing-the-right-dynamodb-partition-key/, ключ раздела должен быть уникальным.
Я создаю приложение, которое должно хранить подписки на тему (например, приложение для чата). Миллионы этих подписок должны быть сохранены в базе данных, и когда сообщение отправляется подписчикам, приложение должно получать всех подписчиков из таблицы.
Наивный подход
Наивный подход заключается в разработке первичного ключа, такого как:
SUBSCRIPTIONS|<topic>
Сортировка затем упорядочит все подписки для <topic> по времени подписки, региону и нескольким другим критериям.
К сожалению, ключ раздела является далеко не уникальным, но он позволяет получить все подписки в одно мгновение.
Кроме того, учитывая максимальный размер таблицы, устанавливается жесткое ограничение на количество подписок, которое может храниться в разделе, и, следовательно, на максимальное количество подписок в целом для этой схемы. Таким образом, это предназначено для отказа масштабируемости.
альтернатива
Другим способом разработки было бы использовать что-то вроде
SUBSCRIPTIONS|<clientId>
провести каждую подписку отдельно для каждого клиента и переместить <topic> в сортировку. Это позволило бы гораздо лучше масштабировать таблицу (разбиение на разделы), но потребовалось бы сканирование, чтобы найти всех подписчиков для определенного <topic>,
Здесь может помочь индекс, но как индекс масштабируется по нескольким разделам? и как это будет работать?