PD
Можно хранить версию схемы рядом с записью и обновлять потихоньку. Я так на json под Pg и делал всегда
Size: a a a
2019 December 23
AK
Оч сложно делать миграцию когда у тебя ну оч много данных а downtime не более 4 часа в год с учётом релизов))
PD
Т.е. схема есть и строгая, но на уровне apppserver.
Y
Если те изменения в схему, которые вам нужны, нельзя свести к удалению ненужных колонок и добавлению новых, то это больно в любой СУБД и будет требовать миграции данных в любом случае
PD
Andrew Komiagin
Оч сложно делать миграцию когда у тебя ну оч много данных а downtime не более 4 часа в год с учётом релизов))
А зачем делать миграции всех данных сразу? Потихоньку...
PD
Если те изменения в схему, которые вам нужны, нельзя свести к удалению ненужных колонок и добавлению новых, то это больно в любой СУБД и будет требовать миграции данных в любом случае
Удаление и добавление колонок тоже опасны.
PD
Даже nullable
AK
А зачем делать миграции всех данных сразу? Потихоньку...
К сожалению иногда есть требования все и сразу)
PD
А я делал сложные миграции с изменением структуры данных - и ничего.
PD
Andrew Komiagin
К сожалению иногда есть требования все и сразу)
А откуда они возьмутся, что за кейс?
Y
Кстати для MySQL есть тулза от percona на триггерах, называется pt-online-schema-change. Оно позволяет делать неблокирующие альтеры без даунтайма (почти). Но она тоже имеет ограничения, конечно же.
Y
Приложение в любом случае нужно адаптировать так, чтобы оно могло с обеими схемами работать в процессе миграции.
AE
Нее. Всегда при смене метаинформации есть эксклюзивная блокировка. Которая может привести к остановке всей работы с таблицей
Это может быть очень лёгкая блокировка, чисто чтобы другая транзакция не добавляла/меняла то же поле в таблице метаданных. В частности, добавление поля в Постгресе на чтение/запись из таблицы не влияет.
PD
Там всегда есть блокировка, ее не обойти. И сценарий 'все мелкие задачи ждут мгновенной миграции, а она ждёт толстый запрос' я отлавливал ни раз.
Y
С монгой просто придется поддерживать все ранее существовавшие схемы вдобавок к этому.
Y
Или мигрировать данные каждый раз.
PD
Ну, мне больше трёх последних версий было не нужно держать. Успевало отмигрироваться.
AK
Так и есть. Поддержка сразу кучи схем данных и постепенная миграция самых древних
PD
При хорошей сериализации всерьез нужно поддерживать только сложные изменёния.
AK
Ну так и есть. У нас есть группы обратносовместимых между собой схем