Выполнять это нужно в модуле Onyx (модуль, воспроизводящий функциональность Oracle) на порту 1521 OCI и jar файл можем дать отдельно (Driver Settings - Libraries)
Marble — модуль, воспроизводящий функциональность Microsoft SQL Server;
Каждый модуль получил собственный серверный процесс бэкенда и собственный полный конвейер обработки запроса.
То есть запрос PostgreSQL приходит в Pearl и внутри Pearl проходит свой путь: парсер, мутатор, планирование, оптимизация и исполнение.
Oracle-совместимый запрос приходит уже в Onyx. У него свой менеджер соединений, свой серверный процесс, свой обработчик PL/SQL и свой конвейер выполнения.
То же самое происходит с T-SQL в Marble: TDS-клиент подключается к Marble, и дальше запрос обрабатывается уже внутри собственного серверного процесса этого модуля.
Скоро выложу видео с последнего нашего вибинара. Любые вопросы, пожалуйста.
Кстати, небольшой совет: помимо самой статьи ЛАНИТ, рекомендую заглянуть и в XLS сравнительную таблицу. В нём собрано почти 180 технических критериев сравнения российских СУБД - от поддержки Oracle PL/SQL, JSON_TABLE, Oracle Advanced Queuing, DBMS_LOB, TDE и AWR до возможностей SPLIT/MERGE секций, CDC, логической репликации и многих других функций.
Да, это будут три отдельные инсталляции продукта. При этом каждая из них разворачивается не в полной конфигурации, а только с необходимым функционалом. При необходимости нет никаких ограничений, чтобы разместить несколько модулей на одной виртуальной машине или в одном контейнере.
В QDB 17.4 и 18.1 архитектура выглядела следующим образом:
Диалект Oracle Диалект MS SQL ----> Единый backend Диалект PostgreSQL
С 18.2 (в распределенной инсталляции) теперь вот так:
VM1 (Pearl) PostgreSQL ↓ свой backend
VM2 (Onyx) Oracle ↓ свой backend
VM3 (Marble) T-SQL ↓ свой backend
Каждый продукт содержит собственный экземпляр конвейера обработки, хотя его внутренняя структура (парсер → планирование → оптимизация → исполнение) остаётся общей.
Здравствуйте, бесплатная версия доступна для скачивания с официального сайта https://database.diasoft.ru для личного и коммерческого использования и для образовательных целей. Там можно скачать с использованием личного кабинета или без регистрации, указав ФИО и e-mail. Лицензия до 8 ядер уже вшита в дистрибутив. Внутри вы также найдете как мануалы, так и дополнительные средства для создания кластера. Также при скачивании можно найти лицензионное соглашение, в котором есть пункт 3.2:
3.2. Конечному пользователю на безвозмездной основе предоставляется право воспроизведения неограниченного количества копий Программного Продукта на физических или виртуальных процессорных ядрах (не более 8 (восьми) ядер), придерживаясь условий Соглашения.
PS: не надо делить эти 8. Это просто право запускать все три субмодуля на тачке, где до 8 ядер.
Вы знаете, с момента перевода до даты выхода статьи прошло почти 3 месяца промышленной эксплуатации. Нагрузка на систему и решаемые задачи остались прежними. Никто не жаловался. Наоборот, некоторые операции чисто визуально стали быстрее. Понятно, что такая +-грубая оценка никак не замена строго проведенному нагрузочному тесту, но с другой стороны, было бы что плохое, оно бы уже вылезло. :)
Фраза получилась забавной, но, как мне кажется, Анастасия говорила не о масштабах инсталляций - в смысле терабайтов данных или количества узлов в кластере, - а о разной категории заказчиков. От частных пользователей до организаций, на которые распространяется целый набор требований: 152-ФЗ, КИИ, ФСТЭК, реестр ПО и всё сопутствующее. По крайней мере, именно так я это для себя интерпретировал.
Примеры T-SQL и Oracle я честно увел из Диасофтовской презентации. Конечно они очень простые, но в том и суть - на небольшом примере показать максимальное число вещей, что казалось бы не должны работать в Постгресе и его форках, а вот в Q.DataBase работают.
По списку фич - мысль хорошая, если будет время, то я попробую написать на эту тему отдельную статью -продолжение. А еще хочу сделать более детальное сравнение с TMaxData (Tibero), Amazon Babelfish, IvorySQL и другими проектами, где реализована схожая идея.
Динамический SQL в Q.DataBase поддерживается - и для MSSQL и для Oracle. Можно прямо внутри хранимки собрать текст на T-SQL или PL/SQL, а потом его выполнить. В нашей системе была куча мест где такое используется.
И насчет "опять же очень хотелось понять во что этот пример конвертируется" - не устаю повторять, что ничего никуда не конвертируется. Прямое нативное исполнение измененным (работающим по другой грамматике) SQL-интерпретатором. Я понимаю, что звучит очень непривычно, у многих даже в голове не укладывается что такое возможно, но это так
Конечно лучше, когда есть такая возможность. Просто есть она далеко не всегда. Кросс-платформа - это когда вся логика в верхних слоях и в базу прилетают только простые DML-запросы. Например, большинство Java-систем такие. А вот если есть продвинутая расчетная логика - что тогда? Тащить данные к вычислениям? Так ведь снизится производительность. Вычисления приземлять в базу? Тогда прощай кросс-платформанность, здравствуйте хранимки. И для старых систем, где вся логика в БД это тоже не всегда возможно - чаще всего на замену системы нет ни денег, ни времени. В общем совет хороший, но не для всех
Нет там никакой трансляции на лету. У них прямое исполнение инструкций из T-SQL и Oracle измененным SQ -интерпретатором. Разбираются и исполняются с той же скоростью , что и оригинальный SQL-диалект постгреса.
Такие вопросы лучше задавать напрямую разработчикам. Я знаю только что наша Enterprise-система в итоге заработала и мы вообще ничего не меняли в коде. Все изменения были на уровне СУБД. Но мы были пилотами - Диасофт нас облизывал как мог, выделил нам отдельную команду во главе с персональным менеджером, делал исправления с максимально возможной скоростью - в начале проекта в день могли 2-3 патча выкатить. У нас была база 2Тб, в ней почти 60 тысяч таблиц и 90 тысяч хранимок на T-SQL. Начали проект в конце февраля, закончили в июле. Насколько я знаю мы у них были первыми после их собственных систем.
Свои банковские системы (одна из них на T-SQL, вторая на PL/SQL) они вроде бы тоже успешно перевели.
Говорить что у ребят 100% совместимость с MS SQL или Oracle я бы пока поостерегся, они продолжают регулярно выпускать патчи. Я думаю пока хотя бы несколько сотен крупных систем на них не переведут, то ошибки при переходах еще будут и много.
Но то что даже сейчас совместимость уже очень высокая - это факт. Я на своем уровне владения SQL-диалектами MS SQL и Oracle уже не могу подобрать пример того, что бы в оригинале работало, а у них нет. Из очевидного только что у них еще не все dbms-пакеты есть, а вот на уровне синтаксиса и конструкций языка мне кажется сходство уже очень и очень высокое. Мне у них сам подход нравится - если что-то работает не как в MS SQL или Oracle, то это они меняют свою СУБД, а не мы свою систему.
Процедура в формате 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.
Я не знаю чего ребятам это стоило, но со стороны это очень круто выглядит.
Ну и еще момент - поскольку диалекты зарубежных СУБД исполняются нативно, то нет ограничений уровня "а в Постгресе так нельзя". На том уровне на котором интерпретаторы этих диалектов взаимодействуют с ядром все СУБД уже "условно похожи".
Что очень радует, они готовы в рамках сопровождения чинить все что работает не так как в оригинале, включая добавление новой функциональности уровня ядра.
Единственное просят подготовить пример на котором видны различия между иностранной СУБД и их.
Мы пробовали использовать ИИ для миграций. К сожалению, ИИ никак не может заменить отсутствие функционала. Например, отсутствие системной хранимой процедуры или системной же таблицы, вокруг которой была навернута логика в прикладном коде. А в случае с Ораклом - отсутствие соответствующего dbms-пакета.
Самые продвинутые модели пытались подставить аналоги - например заменяли обращения к sys.tables на обращения к INFORMATION_SCHEMA.TABLES, но в итоге часто получался неработоспособный код. Особенно грустно было когда в прикладном коде использовались алиасы таблиц и модель в них путалась, оставляла старые наименования полей. В итоге такие запросы нужно было править вручную и исправлять их за моделью было даже хуже чем самому переписать.
А с Q.DataBase все системные таблицы и представления из MS SQL как будто на своем месте. Можно вообще не менять код.
через консоль для qclient ничего не нужно.
Выполнять это нужно в модуле Onyx (модуль, воспроизводящий функциональность Oracle) на порту 1521
OCI и jar файл можем дать отдельно (Driver Settings - Libraries)
Здравствуйте,
Да, конечно.
Недавний вебинар от 10 августа, я в нём как раз таки прохожу по слайду архитектуры.
https://habr.com/ru/posts/1070124/
Здравствуйте,
Благодарю за проявленный интерес.
Сразу обмолвлюсью
Мы не занимаемся конвертацией кода, мы исполняем его на лету в ядре (ядрах, модулях)
Pearl — модуль PostgreSQL;
Onyx — модуль, воспроизводящий функциональность Oracle Database.
Marble — модуль, воспроизводящий функциональность Microsoft SQL Server;
Каждый модуль получил собственный серверный процесс бэкенда и собственный полный конвейер обработки запроса.
То есть запрос PostgreSQL приходит в Pearl и внутри Pearl проходит свой путь: парсер, мутатор, планирование, оптимизация и исполнение.
Oracle-совместимый запрос приходит уже в Onyx. У него свой менеджер соединений, свой серверный процесс, свой обработчик PL/SQL и свой конвейер выполнения.
То же самое происходит с T-SQL в Marble: TDS-клиент подключается к Marble, и дальше запрос обрабатывается уже внутри собственного серверного процесса этого модуля.
Скоро выложу видео с последнего нашего вибинара.
Любые вопросы, пожалуйста.
Спасибо за новость, да ну и его скриншот Veeam Removing Backup.
Кстати, небольшой совет: помимо самой статьи ЛАНИТ, рекомендую заглянуть и в XLS сравнительную таблицу. В нём собрано почти 180 технических критериев сравнения российских СУБД - от поддержки Oracle PL/SQL, JSON_TABLE, Oracle Advanced Queuing, DBMS_LOB, TDE и AWR до возможностей SPLIT/MERGE секций, CDC, логической репликации и многих других функций.
Таблица:
https://disk.yandex.ru/d/4gLLvI0x47vaFw
Да, это будут три отдельные инсталляции продукта. При этом каждая из них разворачивается не в полной конфигурации, а только с необходимым функционалом. При необходимости нет никаких ограничений, чтобы разместить несколько модулей на одной виртуальной машине или в одном контейнере.
В QDB 17.4 и 18.1 архитектура выглядела следующим образом:
Диалект Oracle
Диалект MS SQL ----> Единый backend
Диалект PostgreSQL
С 18.2 (в распределенной инсталляции) теперь вот так:
VM1 (Pearl) PostgreSQL ↓ свой backend
VM2 (Onyx) Oracle ↓ свой backend
VM3 (Marble) T-SQL ↓ свой backend
Каждый продукт содержит собственный экземпляр конвейера обработки, хотя его внутренняя структура (парсер → планирование → оптимизация → исполнение) остаётся общей.
Правильно понимаю, что для теста были подняты три отдельные ВМ по 8 ядер каждая (всего 24 vCPU)? Или на каждую ВМ выделялось другое количество ядер?
Здравствуйте, бесплатная версия доступна для скачивания с официального сайта https://database.diasoft.ru для личного и коммерческого использования и для образовательных целей. Там можно скачать с использованием личного кабинета или без регистрации, указав ФИО и e-mail. Лицензия до 8 ядер уже вшита в дистрибутив. Внутри вы также найдете как мануалы, так и дополнительные средства для создания кластера. Также при скачивании можно найти лицензионное соглашение, в котором есть пункт 3.2:
3.2. Конечному пользователю на безвозмездной основе предоставляется право воспроизведения неограниченного количества копий Программного Продукта на физических или виртуальных процессорных ядрах (не более 8 (восьми) ядер), придерживаясь условий Соглашения.
PS: не надо делить эти 8. Это просто право запускать все три субмодуля на тачке, где до 8 ядер.
Вы знаете, с момента перевода до даты выхода статьи прошло почти 3 месяца промышленной эксплуатации. Нагрузка на систему и решаемые задачи остались прежними. Никто не жаловался. Наоборот, некоторые операции чисто визуально стали быстрее. Понятно, что такая +-грубая оценка никак не замена строго проведенному нагрузочному тесту, но с другой стороны, было бы что плохое, оно бы уже вылезло. :)
Фраза получилась забавной, но, как мне кажется, Анастасия говорила не о масштабах инсталляций - в смысле терабайтов данных или количества узлов в кластере, - а о разной категории заказчиков. От частных пользователей до организаций, на которые распространяется целый набор требований: 152-ФЗ, КИИ, ФСТЭК, реестр ПО и всё сопутствующее. По крайней мере, именно так я это для себя интерпретировал.
Примеры T-SQL и Oracle я честно увел из Диасофтовской презентации. Конечно они очень простые, но в том и суть - на небольшом примере показать максимальное число вещей, что казалось бы не должны работать в Постгресе и его форках, а вот в Q.DataBase работают.
По списку фич - мысль хорошая, если будет время, то я попробую написать на эту тему отдельную статью -продолжение. А еще хочу сделать более детальное сравнение с TMaxData (Tibero), Amazon Babelfish, IvorySQL и другими проектами, где реализована схожая идея.
Динамический SQL в Q.DataBase поддерживается - и для MSSQL и для Oracle. Можно прямо внутри хранимки собрать текст на T-SQL или PL/SQL, а потом его выполнить. В нашей системе была куча мест где такое используется.
И насчет "опять же очень хотелось понять во что этот пример конвертируется" - не устаю повторять, что ничего никуда не конвертируется. Прямое нативное исполнение измененным (работающим по другой грамматике) SQL-интерпретатором. Я понимаю, что звучит очень непривычно, у многих даже в голове не укладывается что такое возможно, но это так
Конечно лучше, когда есть такая возможность. Просто есть она далеко не всегда.
Кросс-платформа - это когда вся логика в верхних слоях и в базу прилетают только простые DML-запросы. Например, большинство Java-систем такие. А вот если есть продвинутая расчетная логика - что тогда? Тащить данные к вычислениям? Так ведь снизится производительность. Вычисления приземлять в базу? Тогда прощай кросс-платформанность, здравствуйте хранимки. И для старых систем, где вся логика в БД это тоже не всегда возможно - чаще всего на замену системы нет ни денег, ни времени.
В общем совет хороший, но не для всех
Нет там никакой трансляции на лету. У них прямое исполнение инструкций из T-SQL и Oracle измененным SQ -интерпретатором. Разбираются и исполняются с той же скоростью , что и оригинальный SQL-диалект постгреса.
Такие вопросы лучше задавать напрямую разработчикам. Я знаю только что наша Enterprise-система в итоге заработала и мы вообще ничего не меняли в коде.
Все изменения были на уровне СУБД. Но мы были пилотами - Диасофт нас облизывал как мог, выделил нам отдельную команду во главе с персональным менеджером, делал исправления с максимально возможной скоростью - в начале проекта в день могли 2-3 патча выкатить. У нас была база 2Тб, в ней почти 60 тысяч таблиц и 90 тысяч хранимок на T-SQL. Начали проект в конце февраля, закончили в июле.
Насколько я знаю мы у них были первыми после их собственных систем.
Свои банковские системы (одна из них на T-SQL, вторая на PL/SQL) они вроде бы тоже успешно перевели.
Говорить что у ребят 100% совместимость с MS SQL или Oracle я бы пока поостерегся, они продолжают регулярно выпускать патчи. Я думаю пока хотя бы несколько сотен крупных систем на них не переведут, то ошибки при переходах еще будут и много.
Но то что даже сейчас совместимость уже очень высокая - это факт. Я на своем уровне владения SQL-диалектами MS SQL и Oracle уже не могу подобрать пример того, что бы в оригинале работало, а у них нет. Из очевидного только что у них еще не все dbms-пакеты есть, а вот на уровне синтаксиса и конструкций языка мне кажется сходство уже очень и очень высокое.
Мне у них сам подход нравится - если что-то работает не как в MS SQL или Oracle, то это они меняют свою СУБД, а не мы свою систему.
Спасибо тебе большое за интересный вопрос!
Процедура в формате 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.
Я не знаю чего ребятам это стоило, но со стороны это очень круто выглядит.
Ну и еще момент - поскольку диалекты зарубежных СУБД исполняются нативно, то нет ограничений уровня "а в Постгресе так нельзя". На том уровне на котором интерпретаторы этих диалектов взаимодействуют с ядром все СУБД уже "условно похожи".
*(в рамках сопровождения)
Что очень радует, они готовы в рамках сопровождения чинить все что работает не так как в оригинале, включая добавление новой функциональности уровня ядра.
Единственное просят подготовить пример на котором видны различия между иностранной СУБД и их.
Мы пробовали использовать ИИ для миграций. К сожалению, ИИ никак не может заменить отсутствие функционала. Например, отсутствие системной хранимой процедуры или системной же таблицы, вокруг которой была навернута логика в прикладном коде. А в случае с Ораклом - отсутствие соответствующего dbms-пакета.
Самые продвинутые модели пытались подставить аналоги - например заменяли обращения к sys.tables на обращения к INFORMATION_SCHEMA.TABLES, но в итоге часто получался неработоспособный код. Особенно грустно было когда в прикладном коде использовались алиасы таблиц и модель в них путалась, оставляла старые наименования полей. В итоге такие запросы нужно было править вручную и исправлять их за моделью было даже хуже чем самому переписать.
А с Q.DataBase все системные таблицы и представления из MS SQL как будто на своем месте. Можно вообще не менять код.