Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 42
....Особенно приятно, что тут с уважением относятся к тем десяткам лет, которые я вложил в диалекты Oracle и Microsoft....
Так 15 лет в ИТ или десятки?
Ну есть о чём задуматься. Я тоже про то, что импортозамещение должно быть про импортозамещение системного ПО, а не про сотен миллионов строк кода прикладного ПО на следующую сотню миллионов лет.
Я правильно понимаю, что Q.DataBase без проблем понимает функции вроде datediff, dateadd, go и прочие из T-SQL, а также oracle-диалект с его varchar2, и при этом это российская СУБД?
DBMS- и UTL-пакеты, например DBMS_LOB и DBMS_OUTPUT, поддерживаются.
Oracle-тема, включая varchar2. Есть даже библиотека, которая эмулирует Oracle Instant Client.А по MS всё на 100%: T-SQL работает, я сам был удивлен. Можно админить даже через SSMS — он думает, что подключен к MS SQL Server. Да, ФСТЭК 4-ка, всё есть.
Из текста выглядит так, что в теории можно, а на практике - универсального готового решения нет и каждый желающий должен либо переписать свое приложение, либо переписать какую-нибудь СУБД с открытым кодом.
Для производителя приложения более логичным выбором тут выглядит переписать свое приложение, т.к. специалисты уже в наличии
Для производителей импортзамещенных СУБД выглядит логичнее просто сертифицировать немного модифицированную СУБД с открытым кодом и зарабатывать деньги не углубляясь в сложные вопросы миграции
Тут скорее рассказ о том, как я встретил Digital Q.DataBase в финсекторе и поделился своим впечатлением с довольно интересными примерами. Для производителя приложения переписывать систему может быть экономически невыгодно, даже при наличии готовой команды - это всё равно трудозатраты, а значит деньги. А для производителей СУБД - Q.DataBase уже в реестре, и это уже решает что-то.
Посмотрим, как далее будет складываться их история.
Зачем так приседать, когда можно просто закорсарить оракл? В чем страх, остаться без поддержки, кого?
Не везде так можно сделать. Кому-то нужна поддержка по ИБ. Быть без поддержки и в какой-то момент понести огромные убытки из-за простоя? Для серьёзных организаций такой подход неприемлем.
Спасибо за вопрос.
1. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных» (152-ФЗ)
2. Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» (187-ФЗ)
Да и в целом, это огромные деньги, там проблемы на холд так просто не поставишь. Сопровождение обязательно нужно: там и аналитика и оптимизация, безопасность, интеграция с др системами и прочее.
Наконец-то появилось внятное решение для миграции без болезненного переписывания кода. Подход с поддержкой диалектов — это именно то, чего не хватало на рынке. Очень обнадеживает, что продукт развивается в правильном направлении.
Интересно. Большинство простых вещей это решит, сложные сильно завязанные на систему конечно нет, но в общем понятно чудес не бывает
Интересно сравнить этот поход с переписыванием с диалекта на диалект с помощью ИИ
Мы пробовали использовать ИИ для миграций. К сожалению, ИИ никак не может заменить отсутствие функционала. Например, отсутствие системной хранимой процедуры или системной же таблицы, вокруг которой была навернута логика в прикладном коде. А в случае с Ораклом - отсутствие соответствующего dbms-пакета.
Самые продвинутые модели пытались подставить аналоги - например заменяли обращения к sys.tables на обращения к INFORMATION_SCHEMA.TABLES, но в итоге часто получался неработоспособный код. Особенно грустно было когда в прикладном коде использовались алиасы таблиц и модель в них путалась, оставляла старые наименования полей. В итоге такие запросы нужно было править вручную и исправлять их за моделью было даже хуже чем самому переписать.
А с Q.DataBase все системные таблицы и представления из MS SQL как будто на своем месте. Можно вообще не менять код.
Что очень радует, они готовы в рамках сопровождения чинить все что работает не так как в оригинале, включая добавление новой функциональности уровня ядра.
Единственное просят подготовить пример на котором видны различия между иностранной СУБД и их.
В большинстве случаев различия в реализации сломают мозг случайными странностями.
Проще перейти на кросс sql платформу.
Конечно лучше, когда есть такая возможность. Просто есть она далеко не всегда.
Кросс-платформа - это когда вся логика в верхних слоях и в базу прилетают только простые DML-запросы. Например, большинство Java-систем такие. А вот если есть продвинутая расчетная логика - что тогда? Тащить данные к вычислениям? Так ведь снизится производительность. Вычисления приземлять в базу? Тогда прощай кросс-платформанность, здравствуйте хранимки. И для старых систем, где вся логика в БД это тоже не всегда возможно - чаще всего на замену системы нет ни денег, ни времени.
В общем совет хороший, но не для всех
Есть у меня большие сомнения в том, что такой подход будет реально работать для большой, нагруженной системы без дотачивания кода. В частности, что там с автономными транзакциями, хинтами, MERGE, вложенными транзакциями, различиями в реализации версионности... Что-то мне подсказывает, что под нагрузкой с кодом, написанным для Oracle без учёта особенностей ядра PostgreSQL, будут проблемы, и придётся его переписывать.
Поделюсь своим опытом: в компании, где я работал, был инструмент, который позволял конвертировать более 90% кода с PL/SQL на PL/pgSQL. Проблемы обычно начинались дальше, уже в эксплуатации, т. к. ядра СУБД отличаются, и какие-то подходы, которые были хороши для Oracle, для PostgreSQL были смерти подобны — и наоборот. В нашем случае мы могли поменять уже код на PL/pgSQL, и мне кажется, это более удобно. К тому же результирующий код можно было исполнять на ванильной версии, т. е. тут, в отличие от Digital Q.DataBase, не было вендор-лока.
Понимаете в чем дело: эти ребята задались целью в мелких подробностях воспроизводить поведение оригинальных MS SQL и Oracle.
Это их принципиально отличает от других форков постгреса.
В случае с конвертацией коду приложения вынуждено приходится подстраиваться под возможности PostgreSQL и рано или поздно встаёт вопрос про его переписывание из-за того, что PostgreSQL чего-то не умеет совсем или делает это иначе чем Оракл.
А эти ребята занимают крайнюю позицию - если Постгрес что-то не умеет или делает не так, как MS SQL или Oracle, то измениться должен код, взятый из PostgreSQL, а не код приложения. Они дорабатывают ядро так, что в эмуляции Оракла оно ведет себя иначе, чем при выполнении обычных постгрессовых запросов.
Вот один конкретный пример, с которым я лично столкнулся в этой СУБД. Он правда про их эмуляцию MS SQL, но для Оракла у них тот же подход. В обычном постгресе курсоры живут лишь в рамках транзакции (явной или неявной), а в MS SQL все время сессии пользователя. Поэтому у нас не работало что с клиента в два разных обращения в рамках одной сессии сначала открываем курсор, а потом во втором делаем апдейт записей в нем. Ко второму обращению курсор уже успевал исчезнуть (неявная транзакция завершалась и он прекращал существовать). Мне кажется, что эта ситуация чем-то похожа на то, что Вы описывали для Оракла - в привычном всем сценарии прикладной код пришлось бы переписать. Но то в обычном сценарии, а нам просто в рамках сопротивления доработали саму СУБД. После установки патча курсоры, которые открываются в рамках T-SQL сессии стали жить до конца сессии. И наш код заработал без переписывания как в оригинальном MS SQL Server.
Занятно что изменение коснулось только эмуляции MS SQL, так как поведение курсоров в рамках постгрессовых пользовательских сессий осталось прежним, никак не изменилось.
Вообще ребята очень по-доброму реагируют на присланные им различия в поведении Q.DataBase и тех зарубежных СУБД, что они пытаются заместить. Просят прислать минимальный фрагмент кода, который иллюстрирует проблему и оперативно (самое долгое в течение недели, а чаще гораздо быстрее) выкатывают патч, устраняющий проблему. И всегда очень благодарят за то, что их ткнули носом в подобного рода отличия.
Наша система в итоге заработала. И все изменения делались только через патчи самой СУБД, что нам присылал Диасофт.
Я понимаю, что звучит непривычно, взрывает мозг, но я потому и захотел тут про них написать, что это реально совершенно другой подход к теме импортозамещения СУБД чем у других российских вендоров. Не менять прикладной код, менять только СУБД.
Это внушает!
Есть немного вопросов.
Я правильно понимаю, что можно одновременно писать как процедуры в формате MSSQL, так и обычного Pg?
Если процедура написана в формате MSSQL, то в ней нельзя уже использовать специфику Pg? Ну для примера LIMIT/OFFSET против LIMIT/FETCH NEXT?
Процедура в формате MSSQL это уже некоторая вещь в себе, то есть там нет какого-то промежуточного Pg-представления чтобы посмотреть во что там реально транслируется код?
Спасибо тебе большое за интересный вопрос!
Процедура в формате MSSQL это уже некоторая вещь в себе, то есть там нет какого-то промежуточного Pg-представления чтобы посмотреть во что там реально транслируется код?
В Q.DataBase можно из процедуры на T-SQL или PL/SQL позвать процедуру написанную на PL/pgSQL или любом другом поддерживаемом диалекте. Можно даже из PL/SQL вызвать процедуру, написанную на T-SQL или наоборот, если кому-то придет в голову ТАК заморочиться.
Нельзя мешать синтаксис внутри процедур - если она на T-SQL, то весь код внутри должен быть в грамматике T-SQL. Если на PL/SQL, то весь код внутри на PL/SQL.
Можно из Постгрес-диалекта обращаться к данным таблиц, созданным из под эмуляции MS SQL или Oracle или наоборот (т.е. таблицы и данные в них видны через любой диалект). Если таблица создана из под эмуляции MS SQL, на ней висел триггер на T-SQL, а я попытаюсь удалить из неё запись из под PostgreSQL-сессии, то триггер отработает как ему положено.
Всякие встроенные функции и другие полезности тоже видны за пределами диалектов, для которых они в первую очередь предназначены. Например, в постгрес-сессии можно звать функции из предназначенных для поддержки совместимости с ораклом dbms-пакетов.
Я не уверен что всем этим нужно пользоваться, по мне такой микс в коде может снизить его переносимость, но оно работает и что важно без потери времени на tds или tns-соединение, все исполняется прямо внутри сервера.
Насчет "промежуточного pg-представления, чтобы посмотреть во что там реально транслируется код" - в том и фокус, что его нет. Код на T-SQL или PL/SQL никуда не транслируется, он напрямую и нативно исполняется в этой СУБД. Интерпретаторы для этих диалектов напрямую вызывают глубокие функция ядра. Они такие же родные для этой СУБД как и интерпретатор оригинального диалекта PostgreSQL. Именно поэтому и работают так быстро, что это не "перекладка в диалект Постгреса и потом исполнение", а "прямое исполнение измененным интерпретатором SQL.
Я не знаю чего ребятам это стоило, но со стороны это очень круто выглядит.
Ну и еще момент - поскольку диалекты зарубежных СУБД исполняются нативно, то нет ограничений уровня "а в Постгресе так нельзя". На том уровне на котором интерпретаторы этих диалектов взаимодействуют с ядром все СУБД уже "условно похожи".
*(в рамках сопровождения)
К сожалению, не всё можно быстро доработать — между ядрами баз есть коренные отличия, которые в конечном счёте влияют на то, как мы пишем код. Приведу простой пример: допустим, у вас есть хранимая функция, которая делает какой-нибудь сложный расчёт в течение, скажем, часа, при этом активно обновляет данные во временной таблице. Такой код будет нормально работать на Oracle, но если его перенести на PostgreSQL, расчёт может не завершиться никогда — из-за bloating. В результате придётся переписывать код под базу.
Или другой пример: допустим, архитектура системы построена на длинных транзакциях, и в коде активно используются конструкции вида begin -- что-то пишем в базу exception end. При переходе на Postgres получим проблемы с LWLock, а возможно, и со счётчиком транзакций. И опять же, нужно будет править код функций.
В общем, для того чтобы быстро показать импортозамещение — вариант очень хороший. А вот для реальной работы под нагрузкой всё равно придётся пилить код — чудес не бывает.
В перспективе развития разработчики обещают: сначала добить самые популярные пакеты, а в горизонте пары лет закрыть и редко используемые.
До серьезной enterprise ready совместимости там пока еще очень далеко, так я понял? И соответственно, реальных миграций проектов с большим объемом stored кода в БД на нее нет ? Или есть ?
А так, ждем, будем посмотреть, как показывает опыт китайцев/корейцев, подход имеет место.
На сайте только 2 кейса, СИНКО-БАНК (причем там написано, что они свой код перевели в синтаксис PostgreSQL, то есть уже не совсем то) и Московская биржа, и там нет ни слова, что использовался вариант , который мы тут обсуждаем, там чисто PostgreSQL. Вообще если начинать углубленно думать, то вопросов конечно масса.
Такие вопросы лучше задавать напрямую разработчикам. Я знаю только что наша Enterprise-система в итоге заработала и мы вообще ничего не меняли в коде.
Все изменения были на уровне СУБД. Но мы были пилотами - Диасофт нас облизывал как мог, выделил нам отдельную команду во главе с персональным менеджером, делал исправления с максимально возможной скоростью - в начале проекта в день могли 2-3 патча выкатить. У нас была база 2Тб, в ней почти 60 тысяч таблиц и 90 тысяч хранимок на T-SQL. Начали проект в конце февраля, закончили в июле.
Насколько я знаю мы у них были первыми после их собственных систем.
Свои банковские системы (одна из них на T-SQL, вторая на PL/SQL) они вроде бы тоже успешно перевели.
Говорить что у ребят 100% совместимость с MS SQL или Oracle я бы пока поостерегся, они продолжают регулярно выпускать патчи. Я думаю пока хотя бы несколько сотен крупных систем на них не переведут, то ошибки при переходах еще будут и много.
Но то что даже сейчас совместимость уже очень высокая - это факт. Я на своем уровне владения SQL-диалектами MS SQL и Oracle уже не могу подобрать пример того, что бы в оригинале работало, а у них нет. Из очевидного только что у них еще не все dbms-пакеты есть, а вот на уровне синтаксиса и конструкций языка мне кажется сходство уже очень и очень высокое.
Мне у них сам подход нравится - если что-то работает не как в MS SQL или Oracle, то это они меняют свою СУБД, а не мы свою систему.
Из статьи не понятно насколько автор аффилирован с Diasoft.
По статье - хотелось бы более детально, что работает, а что нет. Особенно список фич которые не работают.
Пример для Oracle - максимально стерилен и легко переносится средствами миграции - нет состояния пакета, нет блока инициализации, нет ассоциативных массивов, только работа с lob, которая скажем реализована в PGPro. Опять же очень бы хотелось во что этот пример конвертируется.
Отдельный вопрос как решается вопрос с динамическим SQL.
Примеры T-SQL и Oracle я честно увел из Диасофтовской презентации. Конечно они очень простые, но в том и суть - на небольшом примере показать максимальное число вещей, что казалось бы не должны работать в Постгресе и его форках, а вот в Q.DataBase работают.
По списку фич - мысль хорошая, если будет время, то я попробую написать на эту тему отдельную статью -продолжение. А еще хочу сделать более детальное сравнение с TMaxData (Tibero), Amazon Babelfish, IvorySQL и другими проектами, где реализована схожая идея.
Динамический SQL в Q.DataBase поддерживается - и для MSSQL и для Oracle. Можно прямо внутри хранимки собрать текст на T-SQL или PL/SQL, а потом его выполнить. В нашей системе была куча мест где такое используется.
И насчет "опять же очень хотелось понять во что этот пример конвертируется" - не устаю повторять, что ничего никуда не конвертируется. Прямое нативное исполнение измененным (работающим по другой грамматике) SQL-интерпретатором. Я понимаю, что звучит очень непривычно, у многих даже в голове не укладывается что такое возможно, но это так
Вы так и не ответили как Вы аффилированы с Diasoft?!
Прямое нативное исполнение измененным (работающим по другой грамматике) SQL-интерпретатором.
Это понятно, но под капотом то PostgreSQL, мы знаем что в нем, например:
по другому от Oracle ведет себя проверка unique constraint, чем в Oracle (PostgreSQL проверяет ограничение целостности после обновления каждой строки, а Oracle - в конце команды)
нет undo как в Oracle, и долгие транзакции препятствуют очистке
не аналогов пакетов Oracle и их состояния
нет ассоциативных массивов как в Oracle
существенно медленне чем в MS SQL времемнные таблицы
нет хинтов, и не понятно как реализовать что то вида "LEFT HASH JOIN" из MS SQL
Соответственно когда я писал "опять же очень хотелось понять во что этот пример конвертируется" , я хотел понять во что интерпретатор превращает эти конструкции (какие конструкции PostgreSQL использует) в тех же примерах из вашей статьи и тех примеров, что я написал выше.
Тот же конвертер, только динамический, но требующий, по сути, переписать SQL engine и системные хранимые процедуры с трансляцией в язык целевой СУБД. Дальше все это заткнется на ограничениях storage engine. К тормозам самого постгреса добавляем еще и оверхед слоя трансляции "на лету".
Оверхеда слоя трансляции может и не быть, если это сделано на достаточно низком уровне. Выше было сказано, что все это не конвертится в SQL для Pg. То есть синтаксический анализатор свой, оптимизатор возможно тоже. Тут скорее вопрос, чтобы багов не было.
Оверхеда нет лишь в том случае, если родной SQL engine заменяется новым, опираясь на storage API, включая переписанный оптимизатор. Можно ли назвать это постгресом? Вопрос риторический. Далее в исходнике встречается CREATE CLUSTERED INDEX или CREATE PARTITION FUNCTION и на этом эксперимент завершается костылями ввиду ограничений storage.
Нет там никакой трансляции на лету. У них прямое исполнение инструкций из T-SQL и Oracle измененным SQ -интерпретатором. Разбираются и исполняются с той же скоростью , что и оригинальный SQL-диалект постгреса.
См. комментарий выше. По поводу "исполняются с той же скоростью" смешно пошутили.
Самый главный вопрос - как это пощупать можно? Только через запрос от организации? Самим посмотреть оценить никак нельзя? А форма на сайте то рабочая? А то форма "скачать дистрибутив без регистрации" есть только на database-test но не работает тоже кажется.
Реализация оракла выглядит невероятно (если это правда конечно); пакетов побольше бы. А скачать простому смертному где можно на тест? Или только для юр лиц?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Можно ли перейти с Oracle или MS SQL на СУБД из Реестра российского ПО без переписывания всей хранимой логики?