Разве django с mongodb делает миграцию прошлым?

Ответ 1

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

Посмотрим на некоторые общие действия по миграции:

• Добавить поле: Mongo делает это очень просто. Просто добавьте поле, и все готово.
• Удалить поле: В теории вы фактически не привязаны к своей схеме, поэтому "удаление" здесь относительное. Если вы удалите "свойство" и больше не загружаете это поле, то на самом деле не имеет значения, находится ли это поле в данных. Поэтому, если вы не заботитесь о "очистке" базы данных, удаление этого поля не влияет на базу данных. Если вы сделаете заботиться об очистке БД, вам в основном нужно запустить гигант для цикла для БД.
• Изменить имя поля: Это также сложная проблема. Когда вы переименовываете поле "where", вы его переименовываете? Если вы хотите, чтобы БД отражала новое имя поля, вам в основном нужно выполнить гигантский цикл для БД. Чтобы быть в безопасности, вам, вероятно, придется "добавить" данные, затем нажмите код, затем "отменить" старое поле.

Некоторые морщины

Однако понятие имени поля в тандеме с объектом ActiveRecord немного искажено. Объект ActiveRecord эффективно обеспечивает сопоставление свойств объектов с реальными полями базы данных.

В типичной РСУБД "размер" имени поля не имеет особого значения. Однако в Mongo имя поля фактически занимает пространство данных, и это имеет большое значение с точки зрения производительности.

Теперь, если вы используете какую-либо "объект данных", например ActiveRecord, почему вы пытаетесь сохранить полные имена полей в данных? Вероятно, БД должна хранить все поля в алфавитном порядке с картой на стороне Объекта. Таким образом, у документа может быть 8 полей/свойств, а имена БД будут "a", "b"... "j", но имена объектов будут читаемыми, такими как "Имя", "Цена", "Количество".

Я объясняю это тем, что он добавляет еще одну морщину для изменения имени поля. Если вы выполняете сопоставление, то изменение имени поля действительно не вызывает миграции вообще.

Еще несколько морщин

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

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

Если вы удалите большое поле из большого количества документов, вы захотите сделать ремонт или проверить новый на месте compact.

Ответ 2

Нет серебряной пули. Добавление или удаление полей проще с нереляционными db (просто не используйте ненужные поля или используйте новые поля), проще переименовать поле с помощью традиционного db (обычно вам придется менять много данных в случае переименования поля в schemaless db), миграция данных находится на уровне - в зависимости от задачи.

Ответ 3

Как выглядит процесс миграции с нереляционным db?

Зависит от необходимости обновлять все существующие данные или нет.

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

Что-то вроде переименования полей (тривиальное в реляционном db, потому что вам нужно только обновить каталог и не касаться каких-либо данных) является важным делом в MongoDB (вам нужно переписать все документы).

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