Перемещение схемы в базе данных Production?

Question

Я начал изучать веб-разработки (особенно для Flask и Django), и везде, где я вижу, тема баз данных всегда начинается с миграции.

Из того, что я понял, для обновления баз данных следует

1. запустить «что-то, чтобы произвести перенастройки сценария», чтобы создать миграционный скрипт, который будет Diff текущих моделей файла и текущая базы данных.
2. Проверьте сценарий миграции в локальной базе данных.
3. Зафиксируйте сценарий миграции, чтобы он достиг вашей рабочей среды, в которой снова запускается сценарий для обновления ваших производственных баз данных.

Но чтение Schema Migrations в Википедии по этой ссылке Schema Migration я наткнулся на следующий текст:

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

В нем говорится, что следует избегать миграции в prodution, тогда как вы должны обновлять свои базы данных?

Answer 1

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

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

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

Обновление: Я обновил страницу Википедии, давайте посмотрим, как долго длится редактировать :-)

Answer 2

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

Например, в MySQL до 5.6 нет изменений в онлайновой схеме, поэтому у вас обязательно будет блокировка таблицы при запуске ALTER TABLE. Если это небольшая таблица или тестовая среда с сгенерированными данными, это обычно не проблема - малый будет быстро завершен, и вы можете отказаться от тестовой таблицы и регенерировать данные, - но большая таблица в производственной среде может быть заблокирована в течение нескольких часов, если не дней или недель, что делает систему недоступной для любых взаимодействий с этой таблицей.Вы должны использовать альтернативные методы миграции для выполнения изменений с минимальным временем простоя, и они не просто или безопасны для автоматизации.

Answer 3

Да, это абсурдно. Миграции схемы все время производятся на производственных базах данных. По мере изменения потребностей часто требуется также изменить базовую базу данных. У Django и Flask есть пути для обновления баз данных, Django - это встроенная команда mirgrate в текущих версиях и South в предыдущих версиях. Для обработки изменений схемы Flask/SQLAlchemy имеет alembic. Это, как говорится, все равно может быть больно и может быть опасным, поэтому тестовый тестовый тест и план отката.

Answer 4

Независимо от того, применяются ли автоматические изменения схемы посредством миграции в процессе производства или нет, в основном это вопрос политики организации. Более новые организации с менее ценными данными и/или меньшими базами данных, как правило, используют их, пока они не попадут в ситуацию, когда их миграция занимает день или больше и даже может упасть. Если жизненно важные данные теряются, довольно часто политики для изменений в базе данных становятся более консервативными и менее вероятными могут быть вызваны разработчиками, которые написали приложение и многое другое администраторами баз данных или DevOps после слоев обзора. Поэтому ИМХО, эти утверждения являются отражением организационного опыта и зрелости, чем абсолюты. Другими словами, это делается до тех пор, пока это не сработает, тогда будет применен другой процесс.