Здравствуйте, rosencrantz, Вы писали:

vsb>>какие-то изменения, которые бы лочили БД надолго (обновление кучи строк) нужно реализовывать через батч-задачи, которые там по 100 строк будут обрабатывать не мешая остальным

R>А как такое оформляется в техническом плане? В каком виде эти миграции будут лежать в репозитории? "На чём" эти батч-задачи запускать?

Тут скорей не технический план, а организационный. В техническом плане всё как обычно — ну к примеру миграции в виде SQL-скриптов flyway, батч-задача в виде scheduled или cronjob какой-нибудь или просто на старте приложения пустить отдельный поток и в нём в цикле делать.

Организационный — имеется в виду, что некоторые DDL-скрипты выполняются мгновенно, а некоторые могут лочить базу, в том числе надолго. К примеру добавить nullable столбец в постгресе это мгновенная операция. А создать уникальный индекс это уже лочит таблицу, постгресу же нужно проверить, что данные действительно уникальные. Если таблица крошечная, то никто не заметит, а если не крошечная, то система встанет колом, пока это происходит. У постгреса есть опция CONCURRENTLY которая этот индекс создаёт не блокируя систему, хотя там тоже есть некоторые нюансы. Как добавить non-null столбец я сходу не скажу, но думаю тоже можно. Быстро погуглил, до 11 версии перезаписывалась вся таблица, так что всё сложно было, после 11 версии он научился онлайн это делать.

А если, к примеру, в DDL скрипте будет написано что-то вроде update table set x = null where a = b, и предполаагется, что этот update будет изменять много строк, то понятно, что это может быть тяжёлая операция, она может залочить много строк и система повиснет на это время. Поэтому такой update нужно делать в каком-то виде, чтобы он работал не за раз, а порциями, не оказывая существенного влияния на работающую систему.

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

Здравствуйте, rosencrantz, Вы писали:

vsb>>какие-то изменения, которые бы лочили БД надолго (обновление кучи строк) нужно реализовывать через батч-задачи, которые там по 100 строк будут обрабатывать не мешая остальным

R>А как такое оформляется в техническом плане? В каком виде эти миграции будут лежать в репозитории? "На чём" эти батч-задачи запускать?

Тут скорей не технический план, а организационный. В техническом плане всё как обычно — ну к примеру миграции в виде SQL-скриптов flyway, батч-задача в виде scheduled или cronjob какой-нибудь или просто на старте приложения пустить отдельный поток и в нём в цикле делать.

Организационный — имеется в виду, что некоторые DDL-скрипты выполняются мгновенно, а некоторые могут лочить базу, в том числе надолго. К примеру добавить nullable столбец в постгресе это мгновенная операция. А создать уникальный индекс это уже лочит таблицу, постгресу же нужно проверить, что данные действительно уникальные. Если таблица крошечная, то никто не заметит, а если не крошечная, то система встанет колом, пока это происходит. У постгреса есть опция CONCURRENTLY которая этот индекс создаёт не блокируя систему, хотя там тоже есть некоторые нюансы. Как добавить non-null столбец я сходу не скажу, но думаю тоже можно. Быстро погуглил, до 11 версии перезаписывалась вся таблица, так что всё сложно было, после 11 версии он научился онлайн это делать.

А если, к примеру, в DDL скрипте будет написано что-то вроде update table set x = null where a = b, и предполаагется, что этот update будет изменять много строк, то понятно, что это может быть тяжёлая операция, она может залочить много строк и система повиснет на это время. Поэтому такой update нужно делать в каком-то виде, чтобы он работал не за раз, а порциями, не оказывая существенного влияния на работающую систему.

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