Существуют ли какие-либо инструменты для миграции схемы для баз данных NoSQL?

Ответ 1

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

• Как и другие, вы можете написать свой код, чтобы он обрабатывал разные "версии" возможной схемы. это обычно проще, чем кажется. Многие виды изменений схемы тривиальны для кода. например, если вы хотите добавить новое поле в схему, вы просто добавляете его ко всем новым записям, и оно будет пустым на всех старых записях (вы не получите ошибок "ничего не существует" или чего-то еще;). если вам нужно значение "по умолчанию" для поля в старых записях, это слишком тривиально сделано в коде.
• Еще одна опция и фактически единственная нормальная опция, идущая вперед с нетривиальными изменениями схемы, такими как переименования полей и структурные изменения, заключается в том, чтобы хранить schema_version в записи EACH и иметь код для переноса данных из любой версии в другую на READ. то есть если ваша текущая версия схемы равна 10, и вы читаете запись из базы данных с версией 7, тогда ваш уровень db должен вызывать migrate_8, migrate_9 и migrate_10. Таким образом, данные, к которым осуществляется доступ, будут постепенно перенесены в новую версию. и если он не доступен, то кто заботится о том, какая версия это;)

Ответ 2

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

Ответ 3

Если ваши данные достаточно велики, вы, вероятно, обнаружите, что не можете ПЕРЕДАТЬ миграцию данных или что это не выгодно. Это означает, что при изменении схемы код должен продолжать быть обратно совместимым со старыми форматами навсегда.

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

Ответ 4

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

Если кто-то начнет работать с базами данных NoSQL, вам нужно понять, что большинство "правил" для РСУБД (т.е. MySQL) необходимо выходить из окна. Такие вещи, как строгие схемы, нормализация, использование многих взаимосвязей между объектами. NoSQL существует для решения проблем, которым не нужны все дополнительные функции, предоставляемые СУРБД.

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

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