Спасибо за статью, не смотря на то что от нее прям разит ИИ генерацией было интересно. Основной вопрос, а что с генерацией скриптов миграции на основании изменения модели в ArchDB?
ут проблема в том, что общая статья это будет, скорее всего, агитка от разного рода помогаторов, а статья с личным опытом будет близка только определённому кругу людей. И личных статей будет больше от тех, кому легче переехать, то есть от тех, кто знает английский, работает удалённо и т.п. Хотя, конечно, есть и другие варианты переезда. У меня, например, есть знакомая, которая переехала 15 лет назад без знания языка и удалённой работы, на мой взгляд, на это нужна была нереальная решимость, но такие люди обычно не пишут статьи.
В общем, в переезде всё очень индивидуально. Кстати, насчёт того, что с удалённой работой везде «зашибись», тут есть интересная штука: вот у меня удалённая работа, и от того, что я из России переехал куда-то, сумма заработка не поменялась. И, соответственно, в одном месте будет уже «зашибись» — минус 35% на налоги, а в другом — просто «зашибись», но без госшкол и бесплатной медицины. И вот пойми, где же оно лучше :)
А что именно обозначают на вашем графике показатели «Операционная скорость» и «Точка наблюдения»? Что вы хотели продемонстрировать данной статьёй? Сам вопрос о том, что лучше — коррелированный подзапрос или JOIN, некорректен, поскольку для каждого запроса и каждого распределения данных ответ может быть разным. Как будут вести себя ваши запросы, если количество клиентов увеличится? А если база данных будет размещена не на SSD, а на HDD, и данные не будут находиться в памяти? А если, помимо подсчёта количества, потребуется вычислять сумму по заказам или появятся дополнительные условия отбора заказов, из‑за которых одного обращения к индексу окажется недостаточно?
К сожалению, не всё можно быстро доработать — между ядрами баз есть коренные отличия, которые в конечном счёте влияют на то, как мы пишем код. Приведу простой пример: допустим, у вас есть хранимая функция, которая делает какой-нибудь сложный расчёт в течение, скажем, часа, при этом активно обновляет данные во временной таблице. Такой код будет нормально работать на Oracle, но если его перенести на PostgreSQL, расчёт может не завершиться никогда — из-за bloating. В результате придётся переписывать код под базу.
Или другой пример: допустим, архитектура системы построена на длинных транзакциях, и в коде активно используются конструкции вида begin -- что-то пишем в базу exception end. При переходе на Postgres получим проблемы с LWLock, а возможно, и со счётчиком транзакций. И опять же, нужно будет править код функций.
В общем, для того чтобы быстро показать импортозамещение — вариант очень хороший. А вот для реальной работы под нагрузкой всё равно придётся пилить код — чудес не бывает.
Есть у меня большие сомнения в том, что такой подход будет реально работать для большой, нагруженной системы без дотачивания кода. В частности, что там с автономными транзакциями, хинтами, MERGE, вложенными транзакциями, различиями в реализации версионности... Что-то мне подсказывает, что под нагрузкой с кодом, написанным для Oracle без учёта особенностей ядра PostgreSQL, будут проблемы, и придётся его переписывать.
Поделюсь своим опытом: в компании, где я работал, был инструмент, который позволял конвертировать более 90% кода с PL/SQL на PL/pgSQL. Проблемы обычно начинались дальше, уже в эксплуатации, т. к. ядра СУБД отличаются, и какие-то подходы, которые были хороши для Oracle, для PostgreSQL были смерти подобны — и наоборот. В нашем случае мы могли поменять уже код на PL/pgSQL, и мне кажется, это более удобно. К тому же результирующий код можно было исполнять на ванильной версии, т. е. тут, в отличие от Digital Q.DataBase, не было вендор-лока.
То что не видно не значит что этого нет :). Мы мигрировали не АБС конечно, но ERP/MES систему в которой вся бизнес логика была на PL/SQL (порядка 4 тыс пакетов) по итогам конвертации получилось больше 500 тыс строк кода. И да такое конечно не через ora2pg делается у нас был свой инструмент для конвертации кода (без всякого AI только православный yacc), и сам код под Oracle пришлось адаптировать там где автоматическая конвертация не справлялась. Думаю и АБС таким же образом можно перевести тут дело не сколько в коде на сервере сколько в объемах и дальнейшей эксплуатации ибо нюансов много и обычно да же после хорошего тестирования оно все уже под нагрузкой начинает лезть.
Спасибо за статью, не смотря на то что от нее прям разит ИИ генерацией было интересно. Основной вопрос, а что с генерацией скриптов миграции на основании изменения модели в ArchDB?
ут проблема в том, что общая статья это будет, скорее всего, агитка от разного рода помогаторов, а статья с личным опытом будет близка только определённому кругу людей. И личных статей будет больше от тех, кому легче переехать, то есть от тех, кто знает английский, работает удалённо и т.п. Хотя, конечно, есть и другие варианты переезда. У меня, например, есть знакомая, которая переехала 15 лет назад без знания языка и удалённой работы, на мой взгляд, на это нужна была нереальная решимость, но такие люди обычно не пишут статьи.
В общем, в переезде всё очень индивидуально. Кстати, насчёт того, что с удалённой работой везде «зашибись», тут есть интересная штука: вот у меня удалённая работа, и от того, что я из России переехал куда-то, сумма заработка не поменялась. И, соответственно, в одном месте будет уже «зашибись» — минус 35% на налоги, а в другом — просто «зашибись», но без госшкол и бесплатной медицины. И вот пойми, где же оно лучше :)
А что именно обозначают на вашем графике показатели «Операционная скорость» и «Точка наблюдения»?
Что вы хотели продемонстрировать данной статьёй?
Сам вопрос о том, что лучше — коррелированный подзапрос или
JOIN, некорректен, поскольку для каждого запроса и каждого распределения данных ответ может быть разным.Как будут вести себя ваши запросы, если количество клиентов увеличится?
А если база данных будет размещена не на SSD, а на HDD, и данные не будут находиться в памяти?
А если, помимо подсчёта количества, потребуется вычислять сумму по заказам или появятся дополнительные условия отбора заказов, из‑за которых одного обращения к индексу окажется недостаточно?
К сожалению, не всё можно быстро доработать — между ядрами баз есть коренные отличия, которые в конечном счёте влияют на то, как мы пишем код. Приведу простой пример: допустим, у вас есть хранимая функция, которая делает какой-нибудь сложный расчёт в течение, скажем, часа, при этом активно обновляет данные во временной таблице. Такой код будет нормально работать на Oracle, но если его перенести на PostgreSQL, расчёт может не завершиться никогда — из-за bloating. В результате придётся переписывать код под базу.
Или другой пример: допустим, архитектура системы построена на длинных транзакциях, и в коде активно используются конструкции вида
begin -- что-то пишем в базу exception end. При переходе на Postgres получим проблемы с LWLock, а возможно, и со счётчиком транзакций. И опять же, нужно будет править код функций.В общем, для того чтобы быстро показать импортозамещение — вариант очень хороший. А вот для реальной работы под нагрузкой всё равно придётся пилить код — чудес не бывает.
Есть у меня большие сомнения в том, что такой подход будет реально работать для большой, нагруженной системы без дотачивания кода. В частности, что там с автономными транзакциями, хинтами, MERGE, вложенными транзакциями, различиями в реализации версионности... Что-то мне подсказывает, что под нагрузкой с кодом, написанным для Oracle без учёта особенностей ядра PostgreSQL, будут проблемы, и придётся его переписывать.
Поделюсь своим опытом: в компании, где я работал, был инструмент, который позволял конвертировать более 90% кода с PL/SQL на PL/pgSQL. Проблемы обычно начинались дальше, уже в эксплуатации, т. к. ядра СУБД отличаются, и какие-то подходы, которые были хороши для Oracle, для PostgreSQL были смерти подобны — и наоборот. В нашем случае мы могли поменять уже код на PL/pgSQL, и мне кажется, это более удобно. К тому же результирующий код можно было исполнять на ванильной версии, т. е. тут, в отличие от Digital Q.DataBase, не было вендор-лока.
То что не видно не значит что этого нет :). Мы мигрировали не АБС конечно, но ERP/MES систему в которой вся бизнес логика была на PL/SQL (порядка 4 тыс пакетов) по итогам конвертации получилось больше 500 тыс строк кода. И да такое конечно не через ora2pg делается у нас был свой инструмент для конвертации кода (без всякого AI только православный yacc), и сам код под Oracle пришлось адаптировать там где автоматическая конвертация не справлялась. Думаю и АБС таким же образом можно перевести тут дело не сколько в коде на сервере сколько в объемах и дальнейшей эксплуатации ибо нюансов много и обычно да же после хорошего тестирования оно все уже под нагрузкой начинает лезть.