NoSQL поощряет проектирование базы данных на основе шаблонов доступа. Что делать, если шаблоны меняются?

Question

NoSQL поощряет проектирование базы данных на основе шаблонов доступа и может выполнять те запросы, для которых она была разработана, очень быстро.Для других запросов производительность не так хороша.Но для программного обеспечения изменение является нормой.Итак, когда появляются новые требования и нам нужно добавлять новые функции, как могут адаптироваться базы данных nosql?Или, что еще лучше, как я могу спроектировать базы данных nosql (предпочтительно, Dynamodb), которые позволят мне адаптироваться к новым функциям.

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

Ссылки:

Рик Хулихан говорит о разработке таблицы динамодб на основе шаблонов доступа

Лучшие практики проектирования Dynamodb из документации aws

Answer 1

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

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

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