Есть ли какие-либо инструменты для миграции схемы для баз данных NoSQL? [закрытый]
4 ответа
Поскольку база данных nosql может содержать огромные объемы данных, вы не можете перенести ее в обычном режиме rdbms. На самом деле вы не можете сделать это для rdbms, как только ваши данные пройдут некоторый порог размера. Непрактично останавливать свой сайт на день, чтобы добавить поле в существующую таблицу, и поэтому с rdbms вы в конечном итоге делаете уродливые исправления, такие как добавление новых таблиц только для поля и выполнение объединений для доступа к данным. В мире nosql вы можете делать несколько вещей.
- Как предлагали другие, вы можете написать свой код так, чтобы он обрабатывал разные «версии» возможной схемы. это обычно проще, чем кажется. Многие виды изменений схемы легко запрограммировать. например, если вы хотите добавить новое поле в схему, вы просто добавляете его во все новые записи, и оно будет пустым для всех старых записей (вы не получите ошибок типа «поле не существует» или чего-то еще;). если вам нужно значение «по умолчанию» для поля в старых записях, это слишком тривиально делается в коде.
- Другой вариант и фактически единственный разумный вариант в будущем с нетривиальными изменениями схемы, такими как переименование полей и структурные изменения, - это сохранить schema_version в КАЖДОЙ записи и иметь код для переноса данных из любой версии в следующую ПРОЧИТАЙТЕ . т.е. если ваша текущая версия схемы - 10, и вы читаете запись из базы данных с версией 7, то ваш уровень базы данных должен вызывать migrate_8, migrate_9 и migrate_10. Таким образом, данные, к которым осуществляется доступ, будут постепенно перенесены в новую версию.а если к нему нет доступа, то кого волнует, какая это версия;)
Одним из предполагаемых преимуществ этих баз данных является то, что они не имеют схем и поэтому не нуждаются в инструментах миграции схем. Вместо этого вы пишете код для работы с данными, чтобы иметь дело с разнообразием данных, хранящихся в db.
.Если ваши данные достаточно большие, вы, вероятно, обнаружите, что вы не можете EVER перенести данные, или что это не выгодно. Это означает, что когда вы вносите изменения в схему, код должен навсегда оставаться обратно совместимым со старыми форматами.
Конечно, если ваши данные "стареют" и в конце концов истекают, это может сделать миграцию схемы за вас - просто измените формат для вновь добавленных данных, затем дождитесь окончания срока годности всех данных в старом формате - затем вы можете отозвать код обратной совместимости.
.Когда проект нуждается в миграции схемы в отношении базы данных NoSQL, я думаю, что вы все еще думаете в манере реляционной базы данных, но используете базу данных NoSQL.
Если кто-то собирается начать работать с базами данных NoSQL, вы должны понимать, что большинство «правил» для РСУБД (т.е. MySQL) также должны быть выброшены в окно. Такие вещи, как строгие схемы, нормализация, использование множества связей между объектами. NoSQL существует для решения проблем, которые не нуждаются во всех дополнительных «функциях», предоставляемых РСУБД.
Я бы настоятельно рекомендовал вам написать свой код таким образом, чтобы не ожидать или не нуждаться в жесткой схеме для вашей базы данных NoSQL - вы должны поддерживать старую схему и конвертировать запись документа на лету при доступе, если вы действительно хотите больше полей схемы в этой записи.
Пожалуйста, имейте в виду, что хранилище NoSQL работает лучше всего, когда вы думаете и проектируете иначе, чем при использовании РСУБД