Миграция схемы в производственной базе данных?

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

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

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

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

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

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


python web database database-migration web-frameworks
person Kartik Anand    schedule 16.04.2015    source источник

Ответы (4)


arrow_upward
3
arrow_downward

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

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

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

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

person Aaron Digulla    schedule 16.04.2015
comment
Очевидно, что автор имеет в виду только автоматические изменения схемы, инициированные фиксацией или развертыванием. Лучше отредактировать статью в Википедии, чтобы сделать это явным, вместо того, чтобы удалять комментарий. Это не произвольное ограничение. - person Pedro Werneck; 16.04.2015
comment
Программные миграции базы данных происходят постоянно, то есть с помощью таких инструментов, как south, alembic и django migrate. Так и должно быть, вероятность ошибок гораздо меньше, чем при использовании команд SQL, написанных вручную. - person reptilicus; 16.04.2015
comment
@reptilicus попробуйте выполнить миграцию схемы в таблице с миллиардами строк, в производственной базе данных без встроенной поддержки онлайн-изменений схемы, используя автоматизированный инструмент, такой как south или alembic, без значительного простоя. - person Pedro Werneck; 16.04.2015
comment
Вопрос не в этом. Программные миграции схемы почти никогда не выполняются в производственной среде по той же причине. Это неправда. - person reptilicus; 16.04.2015
comment
Что касается вашей точки, вы все равно можете использовать south / alembic, зная, что невозможно будет выполнить обновление в реальном времени для таблицы с 1B строками, это просто нужно принять во внимание с разработчиками. - person reptilicus; 16.04.2015

arrow_upward
2
arrow_downward

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

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

person Pedro Werneck    schedule 16.04.2015

arrow_upward
0
arrow_downward

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

person reptilicus    schedule 16.04.2015

arrow_upward
0
arrow_downward

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

person Nitin    schedule 28.07.2017