Media is too big
VIEW IN TELEGRAM
Как перенести приложение с Oracle Forms в веб, сохранив бизнес-логику и привычное поведение экранных форм?
В видео разбираем технологию автоматизированного переноса на Go и показываем её работу на демонстрационном приложении.
► Рассказываем, почему замены СУБД недостаточно и что усложняет ручной перенос.
Показываем, как из файлов .fmb извлекаются метаданные, SQL и PL/SQL-код, как преобразуются триггеры и как связаны JSON, сервер на Go и браузерный интерфейс.
В представленном решении около 70% работ выполняется автоматически.
Оставшаяся часть — адаптация интерфейса и разработка Go-компонентов для конкретных форм.
В практической части Дмитрий Пшеничный из отдела разработки сравнивает исходное и перенесённое приложения: выполнение SQL-запросов, добавление и обновление записей, вызов хранимых процедур и функций, вывод результатов в интерфейс.
Видео также доступно на (в них есть также и таймкоды):
VK
Dzen
YouTube
#OracleForms #Go #Миграция #БазыДанных #PLSQL
В видео разбираем технологию автоматизированного переноса на Go и показываем её работу на демонстрационном приложении.
► Рассказываем, почему замены СУБД недостаточно и что усложняет ручной перенос.
Показываем, как из файлов .fmb извлекаются метаданные, SQL и PL/SQL-код, как преобразуются триггеры и как связаны JSON, сервер на Go и браузерный интерфейс.
В представленном решении около 70% работ выполняется автоматически.
Оставшаяся часть — адаптация интерфейса и разработка Go-компонентов для конкретных форм.
В практической части Дмитрий Пшеничный из отдела разработки сравнивает исходное и перенесённое приложения: выполнение SQL-запросов, добавление и обновление записей, вызов хранимых процедур и функций, вывод результатов в интерфейс.
Видео также доступно на (в них есть также и таймкоды):
VK
Dzen
YouTube
#OracleForms #Go #Миграция #БазыДанных #PLSQL
Совсем немного осталось до нашего второго Дня СУБД, который пройдёт 27 октября.
Поторопитесь зарегистрироваться на мероприятие!
Вход бесплатный, регистрация по ссылке https://dbd.diasoft.ru/
Мы очень ждём этой встречи и хотим вспомнить, как это было в первый раз.
🐬 21 апреля 2026 года мы провели первый в истории «Диасофт» День СУБД.
Мероприятие посетили более 350 экспертов: представители крупнейших банков, IT-разработчиков и интеграторов, производственных, медицинских, образовательных организаций, ретейлеров и компаний из других отраслей экономики.
На конференции анонсировали бесплатную национальную СУБД RuDB с открытым кодом.
Рассказали о функциональности «Полиглот» Digital Q.DataBase, поддержке диалектов Oracle, MS SQL и PostgreSQL.
Помимо деловой части, гостей ждали фуршет и развлекательная программа, вечер получился очень насыщенным и живым!
️
► Видео с прошлого Дня СУБД:
https://rutube.ru/plst/1623202/
Поторопитесь зарегистрироваться на мероприятие!
Вход бесплатный, регистрация по ссылке https://dbd.diasoft.ru/
Мы очень ждём этой встречи и хотим вспомнить, как это было в первый раз.
Мероприятие посетили более 350 экспертов: представители крупнейших банков, IT-разработчиков и интеграторов, производственных, медицинских, образовательных организаций, ретейлеров и компаний из других отраслей экономики.
На конференции анонсировали бесплатную национальную СУБД RuDB с открытым кодом.
Рассказали о функциональности «Полиглот» Digital Q.DataBase, поддержке диалектов Oracle, MS SQL и PostgreSQL.
Помимо деловой части, гостей ждали фуршет и развлекательная программа, вечер получился очень насыщенным и живым!
️
► Видео с прошлого Дня СУБД:
https://rutube.ru/plst/1623202/
Please open Telegram to view this post
VIEW IN TELEGRAM
От Oracle к Digital Q.DataBase — с привычными приложениями
В предыдущем посте мы рассказали о поддержке диалекта Oracle — PL/SQL.
Продолжим тему: что происходит с приложениями, которые подключаются к базе?
Мы создали библиотеку, которая эмулирует Oracle Instant Client.
Она позволяет переключать приложения с Oracle на Q.DataBase без перекомпиляции и изменений в коде.
Для приложений, использующих поддерживаемые функции «толстого» клиента, переход сводится к замене клиентской библиотеки и настройке подключения.
Приложение продолжает работать через привычный интерфейс.
Есть и другой вариант — подключение через наш JDBC-драйвер.
При этом на стороне Q.DataBase по-прежнему могут выполняться PL/SQL-конструкции.
Можно работать в любимом DBeaver, не замечая разницы и сохраняя привычный подход к работе с базой.
Драйверы скоро будут доступны для скачивания на нашем сайте, а пока выдаём их по запросу.
Достаточно оставить комментарий под постом, написать в личные сообщения или на почту supportqdb@diasoft.ru.
#Oracle #Импортозамещение #JDBC #qdb
В предыдущем посте мы рассказали о поддержке диалекта Oracle — PL/SQL.
Продолжим тему: что происходит с приложениями, которые подключаются к базе?
Мы создали библиотеку, которая эмулирует Oracle Instant Client.
Она позволяет переключать приложения с Oracle на Q.DataBase без перекомпиляции и изменений в коде.
Для приложений, использующих поддерживаемые функции «толстого» клиента, переход сводится к замене клиентской библиотеки и настройке подключения.
Приложение продолжает работать через привычный интерфейс.
Есть и другой вариант — подключение через наш JDBC-драйвер.
При этом на стороне Q.DataBase по-прежнему могут выполняться PL/SQL-конструкции.
Можно работать в любимом DBeaver, не замечая разницы и сохраняя привычный подход к работе с базой.
Драйверы скоро будут доступны для скачивания на нашем сайте, а пока выдаём их по запросу.
Достаточно оставить комментарий под постом, написать в личные сообщения или на почту supportqdb@diasoft.ru.
#Oracle #Импортозамещение #JDBC #qdb
Forwarded from Ассоциация Разработчиков СУБД RuDB
В этом посте я бы хотел кратко рассказать, чем же отличаются Digital Q.DataBase и RuDB и какие задачи решает каждый из этих продуктов.
Digital Q.DataBase — коммерческая СУБД для корпоративных заказчиков. Одна из ключевых задач, которую она решает: как перейти с Oracle и Microsoft SQL Server, сохранив прикладную логику и минимизировав переписывание кода?
У Ассоциации разработчиков СУБД, которая развивает RuDB, другой исходный вопрос: зачем каждому российскому разработчику СУБД на базе PostgreSQL самостоятельно реализовывать одни и те же технологии?
У таких разработчиков много общих задач: безопасность, перенос данных, повышение производительности, совместимость с российскими приложениями.
Если каждую из них все решают отдельно, значительная часть усилий уходит на повторение одной и той же работы.
Идея ассоциации — объединить усилия в этой общей части.
Совместно развивать технологическую основу, на которой участники смогут создавать собственные продукты и конкурентные преимущества.
Здесь важно различать саму ассоциацию и RuDB. Ассоциация объединяет разработчиков, а RuDB — технологический результат их совместной работы.
Подробнее о возможностях RuDB можно прочитать на сайте database.ru.
А сейчас давайте разберём один конкретный пример — совместимость с функциональностью пакетов Oracle.
Представим корпоративное приложение, которое много лет работало на Oracle.
Внутри него есть такой фрагмент PL/SQL-кода, как на слайде (2).
Здесь используется пакет DBMS_AQ — механизм Oracle Advanced Queuing.
Приложение формирует сообщение и вызовом DBMS_AQ.ENQUEUE помещает его в очередь.
Теперь мы хотим перенести это приложение на обычный PostgreSQL.
В стандартной поставке PostgreSQL такого пакета нет.
И задача не сводится к тому, чтобы заменить название процедуры или поправить синтаксис.
За этим вызовом стоит определённое поведение: постановка сообщения в очередь, его последующая обработка, связь с транзакцией.
Разработчику нужно подобрать замену и проверить, что она обеспечивает необходимое приложению поведение.
Это может потребовать изменений в коде, а иногда — и в архитектуре.
Например, если принято решение использовать внешнюю систему обмена сообщениями.
Именно здесь становится понятна ценность таких наработок в RuDB.
В RuDB реализована функциональность работы с очередями, соответствующая этому примеру.
Вместо пакетного вызова DBMS_AQ.ENQUEUE используется функция dbms_aq_enqueue.
Но это не означает, что исходный PL/SQL-код можно перенести без изменений.
Код потребуется адаптировать, а работу с параметрами, типами данных и транзакциями — проверить.
При этом разработчику уже не нужно с нуля создавать сам механизм очереди.
Он может использовать готовую реализацию и сосредоточиться на адаптации приложения.
RuDB сокращает объём работы по воспроизведению необходимой функциональности при миграции.
Digital Q.DataBase идёт дальше в части совместимости с исходным приложением: задача продукта — сохранить не только нужную функциональность, но и исходный код там, где поддерживается соответствующая совместимость.
В примере на слайде (2) это означает сохранение привычного пакетного вызова из PL/SQL.
Таким образом, различие можно сформулировать так:
В RuDB мы используем готовую функциональность и адаптируем под неё код.
В Digital Q.DataBase мы стремимся сохранить и функциональность, и исходный код приложения.
Поэтому RuDB нельзя рассматривать просто как бесплатную версию Digital Q.DataBase.
У них разные задачи:
RuDB даёт разработчикам общую технологическую основу, а Digital Q.DataBase помогает корпоративным заказчикам переносить существующие приложения с минимальными изменениями.
#RuDB #QDB #СУБД #НовостиСУБД #Oracle #PLSQL #Импортозамещение
Digital Q.DataBase — коммерческая СУБД для корпоративных заказчиков. Одна из ключевых задач, которую она решает: как перейти с Oracle и Microsoft SQL Server, сохранив прикладную логику и минимизировав переписывание кода?
У Ассоциации разработчиков СУБД, которая развивает RuDB, другой исходный вопрос: зачем каждому российскому разработчику СУБД на базе PostgreSQL самостоятельно реализовывать одни и те же технологии?
У таких разработчиков много общих задач: безопасность, перенос данных, повышение производительности, совместимость с российскими приложениями.
Если каждую из них все решают отдельно, значительная часть усилий уходит на повторение одной и той же работы.
Идея ассоциации — объединить усилия в этой общей части.
Совместно развивать технологическую основу, на которой участники смогут создавать собственные продукты и конкурентные преимущества.
Здесь важно различать саму ассоциацию и RuDB. Ассоциация объединяет разработчиков, а RuDB — технологический результат их совместной работы.
Подробнее о возможностях RuDB можно прочитать на сайте database.ru.
А сейчас давайте разберём один конкретный пример — совместимость с функциональностью пакетов Oracle.
Представим корпоративное приложение, которое много лет работало на Oracle.
Внутри него есть такой фрагмент PL/SQL-кода, как на слайде (2).
Здесь используется пакет DBMS_AQ — механизм Oracle Advanced Queuing.
Приложение формирует сообщение и вызовом DBMS_AQ.ENQUEUE помещает его в очередь.
Теперь мы хотим перенести это приложение на обычный PostgreSQL.
В стандартной поставке PostgreSQL такого пакета нет.
И задача не сводится к тому, чтобы заменить название процедуры или поправить синтаксис.
За этим вызовом стоит определённое поведение: постановка сообщения в очередь, его последующая обработка, связь с транзакцией.
Разработчику нужно подобрать замену и проверить, что она обеспечивает необходимое приложению поведение.
Это может потребовать изменений в коде, а иногда — и в архитектуре.
Например, если принято решение использовать внешнюю систему обмена сообщениями.
Именно здесь становится понятна ценность таких наработок в RuDB.
В RuDB реализована функциональность работы с очередями, соответствующая этому примеру.
Вместо пакетного вызова DBMS_AQ.ENQUEUE используется функция dbms_aq_enqueue.
Но это не означает, что исходный PL/SQL-код можно перенести без изменений.
Код потребуется адаптировать, а работу с параметрами, типами данных и транзакциями — проверить.
При этом разработчику уже не нужно с нуля создавать сам механизм очереди.
Он может использовать готовую реализацию и сосредоточиться на адаптации приложения.
RuDB сокращает объём работы по воспроизведению необходимой функциональности при миграции.
Digital Q.DataBase идёт дальше в части совместимости с исходным приложением: задача продукта — сохранить не только нужную функциональность, но и исходный код там, где поддерживается соответствующая совместимость.
В примере на слайде (2) это означает сохранение привычного пакетного вызова из PL/SQL.
Таким образом, различие можно сформулировать так:
В RuDB мы используем готовую функциональность и адаптируем под неё код.
В Digital Q.DataBase мы стремимся сохранить и функциональность, и исходный код приложения.
Поэтому RuDB нельзя рассматривать просто как бесплатную версию Digital Q.DataBase.
У них разные задачи:
RuDB даёт разработчикам общую технологическую основу, а Digital Q.DataBase помогает корпоративным заказчикам переносить существующие приложения с минимальными изменениями.
#RuDB #QDB #СУБД #НовостиСУБД #Oracle #PLSQL #Импортозамещение
🔥8
Media is too big
VIEW IN TELEGRAM
Как обрабатывать сотни терабайт данных и развивать корпоративное хранилище после Greenplum?
Игорь Шабанин, заместитель директора по развитию прикладных решений «Диасофт», рассказывает об аналитической СУБД на базе Apache Cloudberry в линейке Digital Q.DataBase.
В докладе — принципы MPP-архитектуры, отличия Cloudberry от Greenplum и результаты тестирования на аналитических задачах.
Спикер показывает, как команда дополнила платформу собственными сервисами онлайн-репликации и миграции данных, и делится опытом синхронизации кластера объёмом 240 ТБ со скоростью до 1,6 ТБ в час.
Вы узнаете, для каких задач подходит решение, как оно помогает при переходе с Greenplum, Teradata и Oracle Exadata и какие возможности предлагает для развития хранилищ данных и BI.
Доклад записан на мероприятии «День СУБД» 21 апреля 2026 года.
Видео с тайм-кодами также доступно на:
VK
RuTube
Dzen
YouTube
#MPP #Greenplum #Cloudberry #QDB
Игорь Шабанин, заместитель директора по развитию прикладных решений «Диасофт», рассказывает об аналитической СУБД на базе Apache Cloudberry в линейке Digital Q.DataBase.
В докладе — принципы MPP-архитектуры, отличия Cloudberry от Greenplum и результаты тестирования на аналитических задачах.
Спикер показывает, как команда дополнила платформу собственными сервисами онлайн-репликации и миграции данных, и делится опытом синхронизации кластера объёмом 240 ТБ со скоростью до 1,6 ТБ в час.
Вы узнаете, для каких задач подходит решение, как оно помогает при переходе с Greenplum, Teradata и Oracle Exadata и какие возможности предлагает для развития хранилищ данных и BI.
Доклад записан на мероприятии «День СУБД» 21 апреля 2026 года.
Видео с тайм-кодами также доступно на:
VK
RuTube
Dzen
YouTube
#MPP #Greenplum #Cloudberry #QDB
🔥7
Улыбнитесь: сегодня день рождения смайлика
19 сентября 1982 года в 11:44 профессор Университета Карнеги-Меллона Скотт Фалман отправил на местную электронную доску объявлений короткое сообщение. В нём он предложил использовать последовательность из двоеточия, дефиса и закрывающей скобки — :-) — для обозначения шуток в текстовой переписке. Так появился первый смайлик. Забавно, но историческое сообщение было найдено в архивах лишь спустя двадцать лет — настоящая цифровая археология.
С тех пор смайлики превратились в эмодзи — универсальный язык, который сегодня понимают без перевода. По данным на 2026 год, около 92% пользователей интернета регулярно используют эмодзи в переписке, а ежедневно по всему миру отправляется более десяти миллиардов таких символов. Самым популярным остаётся «face with tears of joy» (😂) — тот самый смайлик, который заменяет «смешно до слёз».
В PostgreSQL, к слову, хранить эмодзи проще, чем может показаться. База данных по умолчанию использует настоящий UTF-8, который поддерживает все четырёхбайтовые символы. Достаточно типа TEXT — и самый популярный смайлик запишется без проблем. Например, так: INSERT INTO reactions (emoji) VALUES (U&'\+01F602'); — и в таблице окажется тот самый 😂.
Пусть этот маленький жёлтый кружок напоминает: за любыми технологиями, базами данных и строками кода стоят живые эмоции. Улыбайтесь чаще — и пусть в ваших таблицах всегда будет место для радости.
С днём рождения, смайлик! 🙂
19 сентября 1982 года в 11:44 профессор Университета Карнеги-Меллона Скотт Фалман отправил на местную электронную доску объявлений короткое сообщение. В нём он предложил использовать последовательность из двоеточия, дефиса и закрывающей скобки — :-) — для обозначения шуток в текстовой переписке. Так появился первый смайлик. Забавно, но историческое сообщение было найдено в архивах лишь спустя двадцать лет — настоящая цифровая археология.
С тех пор смайлики превратились в эмодзи — универсальный язык, который сегодня понимают без перевода. По данным на 2026 год, около 92% пользователей интернета регулярно используют эмодзи в переписке, а ежедневно по всему миру отправляется более десяти миллиардов таких символов. Самым популярным остаётся «face with tears of joy» (😂) — тот самый смайлик, который заменяет «смешно до слёз».
В PostgreSQL, к слову, хранить эмодзи проще, чем может показаться. База данных по умолчанию использует настоящий UTF-8, который поддерживает все четырёхбайтовые символы. Достаточно типа TEXT — и самый популярный смайлик запишется без проблем. Например, так: INSERT INTO reactions (emoji) VALUES (U&'\+01F602'); — и в таблице окажется тот самый 😂.
Пусть этот маленький жёлтый кружок напоминает: за любыми технологиями, базами данных и строками кода стоят живые эмоции. Улыбайтесь чаще — и пусть в ваших таблицах всегда будет место для радости.
С днём рождения, смайлик! 🙂
🔥5
«База данных»: термин, который придумали военные
Задумывались ли Вы кто первым ввел в наш лексикон словосочетание "база данных"?
Оказывается, что этот термин родился в середине 1950-х годов в недрах Министерства обороны США. Военным нужно было централизованно хранить данные о военнослужащих и технике на их военных базах. Тогда и появились первые документы (изначально доступные лишь военным подрядчикам), в которых фигурировало словосочетание "data base".
В более широкое обращение термин попал в июне 1963 года, когда корпорация SDC (крупный военный подрядчик) провела симпозиум «Development and Management of a Computer-centered Data Base».
Позднее термин эволюционировал: сначала в англоязычных документах было принято писать "data base" (именно так - с пробелом), потом стали писать "data-base", а затем перешли к привычному нам "database". Занятно что в русском языке сохранился именно исходный стиль (с пробелом).
А ещё есть некоторая ирония в том, что инструменты, изначально заказанные для управления комплектованием военных баз, сегодня управляют нашими плейлистами и корзинами на маркетплейсах.
❓А Вы знали, что у термина "базы данных" такое "военное" происхождение?
Задумывались ли Вы кто первым ввел в наш лексикон словосочетание "база данных"?
Оказывается, что этот термин родился в середине 1950-х годов в недрах Министерства обороны США. Военным нужно было централизованно хранить данные о военнослужащих и технике на их военных базах. Тогда и появились первые документы (изначально доступные лишь военным подрядчикам), в которых фигурировало словосочетание "data base".
В более широкое обращение термин попал в июне 1963 года, когда корпорация SDC (крупный военный подрядчик) провела симпозиум «Development and Management of a Computer-centered Data Base».
Позднее термин эволюционировал: сначала в англоязычных документах было принято писать "data base" (именно так - с пробелом), потом стали писать "data-base", а затем перешли к привычному нам "database". Занятно что в русском языке сохранился именно исходный стиль (с пробелом).
А ещё есть некоторая ирония в том, что инструменты, изначально заказанные для управления комплектованием военных баз, сегодня управляют нашими плейлистами и корзинами на маркетплейсах.
❓А Вы знали, что у термина "базы данных" такое "военное" происхождение?
👍4
Сегодня хочу напомнить Вам, что в Digital Q.DataBase есть Центр управления — единое окно для администрирования и мониторинга баз данных.
Когда база начинает «тормозить», DBA часто превращается в детектива: SQL-консоль, логи, мониторинг, скрипты — и всё это одновременно. Центр управления решает эту проблему.
Что доступно в одном интерфейсе:
— состояние экземпляров БД;
— активные сессии и ожидания;
— блокировки и SQL statistics;
— анализ прироста данных;
— диагностика производительности;
— централизованный мониторинг инфраструктуры;
— поиск медленных SQL.
Почему это важно:
— система помогает находить проблему до падения сервиса;
— не создаёт значимой нагрузки на БД;
— поддерживает как Digital Q.DataBase, так и PostgreSQL;
— доступна для бесплатного тестирования.
Хороший мониторинг — это не просто графики, а инструмент оперативной диагностики. Чем быстрее инженер локализует узкое место, тем ниже риск простоя и каскадных проблем в приложениях.
🐠 Скачать дистрибутив можно на официальном сайте https://database.diasoft.ru
⚙️ Вопросы по настройке и внедрению можно направлять на наш адрес службы поддержки: supportqdb@diasoft.ru
Когда база начинает «тормозить», DBA часто превращается в детектива: SQL-консоль, логи, мониторинг, скрипты — и всё это одновременно. Центр управления решает эту проблему.
Что доступно в одном интерфейсе:
— состояние экземпляров БД;
— активные сессии и ожидания;
— блокировки и SQL statistics;
— анализ прироста данных;
— диагностика производительности;
— централизованный мониторинг инфраструктуры;
— поиск медленных SQL.
Почему это важно:
— система помогает находить проблему до падения сервиса;
— не создаёт значимой нагрузки на БД;
— поддерживает как Digital Q.DataBase, так и PostgreSQL;
— доступна для бесплатного тестирования.
Хороший мониторинг — это не просто графики, а инструмент оперативной диагностики. Чем быстрее инженер локализует узкое место, тем ниже риск простоя и каскадных проблем в приложениях.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🔥3
Media is too big
VIEW IN TELEGRAM
В продолжение предыдущего поста о центре администрирования - выкладываю полное видео выступления Андрея Акимова.
Как объединить мониторинг, администрирование и диагностику баз данных в одном веб-интерфейсе?
Андрей, руководитель команды «Центр управления Digital Q.DataBase», рассказывает о возможностях продукта и показывает, как он помогает в повседневной работе администратора БД.
️► В докладе - поддержка Digital Q.DataBase, преимущества для бизнеса и технических специалистов, а также практические сценарии: контроль состояния баз данных, анализ роста таблиц и поиск причин медленной работы запросов с помощью трассировки сессий.
Видео с тайм-кодами доступно на:
VK
Rutube
Dzen
YouTube
#ЦентрУправления #МониторингБД #АдминистрированиеБД #QDB
Как объединить мониторинг, администрирование и диагностику баз данных в одном веб-интерфейсе?
Андрей, руководитель команды «Центр управления Digital Q.DataBase», рассказывает о возможностях продукта и показывает, как он помогает в повседневной работе администратора БД.
️► В докладе - поддержка Digital Q.DataBase, преимущества для бизнеса и технических специалистов, а также практические сценарии: контроль состояния баз данных, анализ роста таблиц и поиск причин медленной работы запросов с помощью трассировки сессий.
Видео с тайм-кодами доступно на:
VK
Rutube
Dzen
YouTube
#ЦентрУправления #МониторингБД #АдминистрированиеБД #QDB
👍10
Друзья, напоминаем, что наш второй День СУБД состоится уже 27 октября!
Если Вы планируете миграцию с MS SQL или Oracle, хотите увидеть живые демо без переписывания кода и пообщаться с командой разработки Digital Q.DataBase — это событие для Вас.
🔥 Помимо деловой части, гостей ждет фуршет и развлекательная программа!
☀️ 27 октября, 14:00–23:00 (МСК)
🤖 Москва, Кибердом (м. «Улица 1905 года», 2-я Звенигородская ул., 12с18)
⚡️ ️ Вход свободный, но количество мест ограничено!
🎯 Занимайте место по ссылке: https://dbd.diasoft.ru/
Хотите узнать, как прошел наш апрельский День СУБД и что нового мы приготовили на осень?
Подписывайтесь на канал мероприятия, там уже ждут фото, видео и анонсы:
Ссылка на Telegram-канал
Ссылка на MAX
До встречи в Кибердоме!🙌
Если Вы планируете миграцию с MS SQL или Oracle, хотите увидеть живые демо без переписывания кода и пообщаться с командой разработки Digital Q.DataBase — это событие для Вас.
Хотите узнать, как прошел наш апрельский День СУБД и что нового мы приготовили на осень?
Подписывайтесь на канал мероприятия, там уже ждут фото, видео и анонсы:
Ссылка на Telegram-канал
Ссылка на MAX
До встречи в Кибердоме!
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥5⚡2
Media is too big
VIEW IN TELEGRAM
Что вокруг СУБД? Разбираем экосистему Digital Q
При замене корпоративной системы нужно перенести данные, восстановить бизнес-процессы, настроить интеграции и дать пользователям привычные возможности для работы.
Как связать эти задачи?
На «Дне СУБД» Александр Сахаров, директор по работе с партнерами «Диасофт», рассказал, как экосистема Digital Q помогает организовать разработку на единой платформе.
Отправная точка - задача замены 80 систем на Lotus (или Oracle APEX).
► Внутри экосистемы наша СУБД Digital Q.DataBase работает вместе с инструментами интеграции, ETL и BI.
Доклад позволяет увидеть эту связку в контексте создания целого приложения: от проектирования процессов до тестирования и выпуска изменений.
► Экосистема Digital Q:
https://q.diasoft.ru/?utm_source=andrei
Видео с тайм-кодами доступно на:
VK
Rutube
Dzen
YouTube
При замене корпоративной системы нужно перенести данные, восстановить бизнес-процессы, настроить интеграции и дать пользователям привычные возможности для работы.
Как связать эти задачи?
На «Дне СУБД» Александр Сахаров, директор по работе с партнерами «Диасофт», рассказал, как экосистема Digital Q помогает организовать разработку на единой платформе.
Отправная точка - задача замены 80 систем на Lotus (или Oracle APEX).
► Внутри экосистемы наша СУБД Digital Q.DataBase работает вместе с инструментами интеграции, ETL и BI.
Доклад позволяет увидеть эту связку в контексте создания целого приложения: от проектирования процессов до тестирования и выпуска изменений.
► Экосистема Digital Q:
https://q.diasoft.ru/?utm_source=andrei
Видео с тайм-кодами доступно на:
VK
Rutube
Dzen
YouTube
👍7
Векторный поиск в Digital Q.DataBase!
Мы реализовали нативную поддержку векторных типов данных и функций для работы с ними. Теперь RAG-системы и семантический поиск работают прямо в СУБД, без необходимости поднимать отдельные векторные базы.
Что поддержали:
► Тип данных: VECTOR;
► VECTOR_SEARCH — быстрый семантический поиск;
► VECTOR_DISTANCE— вычисление расстояния между векторами;
► VECTOR_NORM и VECTOR_NORMALIZE — работа с нормой и нормализацией вектора;
► VECTORPROPERTY — получение свойств вектора (например, размерности)
Краткий пример:
Где применять:
► RAG-системы для LLM
► Семантический поиск по текстам и документам
► Рекомендательные системы
► Анализ изображений и аудио
Новая функциональность войдёт в ближайший релиз Digital Q.DataBase.
Если вы заинтересованы принять участие в пилотировании этой функциональности до её официального выпуска — напишите нам на supportqdb@diasoft.ru
Мы реализовали нативную поддержку векторных типов данных и функций для работы с ними. Теперь RAG-системы и семантический поиск работают прямо в СУБД, без необходимости поднимать отдельные векторные базы.
Что поддержали:
► Тип данных: VECTOR;
► VECTOR_SEARCH — быстрый семантический поиск;
► VECTOR_DISTANCE— вычисление расстояния между векторами;
► VECTOR_NORM и VECTOR_NORMALIZE — работа с нормой и нормализацией вектора;
► VECTORPROPERTY — получение свойств вектора (например, размерности)
Краткий пример:
-- Создаём таблицу с эмбеддингами
CREATE TABLE docs (
id INT PRIMARY KEY,
title VARCHAR(200),
embedding VECTOR(1536)
);
-- Ищем 5 ближайших документов к запросу
SELECT id, title,
VECTOR_DISTANCE(embedding, VECTOR('[0.12, -0.45, ...]')) AS dist
FROM docs
ORDER BY dist
LIMIT 5;
Где применять:
► RAG-системы для LLM
► Семантический поиск по текстам и документам
► Рекомендательные системы
► Анализ изображений и аудио
Новая функциональность войдёт в ближайший релиз Digital Q.DataBase.
Если вы заинтересованы принять участие в пилотировании этой функциональности до её официального выпуска — напишите нам на supportqdb@diasoft.ru
👍8🔥6
Майкл Стоунбрейкер: «Всё это надо переписать»
Майкл Стоунбрейкер — человек, создавший СУБД Ingres и Postgres, лауреат премии Тьюринга за вклад в развитие СУБД — в 2007 году опубликовал статью «The End of an Architectural Era: (It’s Time for a Complete Rewrite)».
Основная мысль этой статьи: традиционные реляционные СУБД проектировались в 70-е годы под медленные диски, дорогую память и одноядерные процессоры. Сейчас «железо» совсем другое, а вот многие архитектурные компромиссы остались до сих пор.
Идеи из этой статьи Стоунбрейкера были развиты в проектах H-Store (распределённая база данных в оперативной памяти) и C-Store (колоночная база данных) и легли в основу последующих архитектурных решений.
H-Store позже превратился в коммерческую СУБД VoltDB, а идеи C-Store — в колоночные аналитические СУБД, без которых сегодня невозможно представить аналитику больших данных.
В 2011 году аналитик Мэтью Аслетт, описывая достижения команды Стоунбрейкера, ввёл в своём отчёте термин NewSQL — для систем, которые совмещают SQL, ACID и горизонтальную масштабируемость.
Забавно, что создатель одной из самых надёжных и консервативных СУБД возглавил её архитектурное переосмысление.
PostgreSQL никуда не делся — он устойчиво занимает 4-е место в мире по популярности, уступая лишь Oracle, MySQL и Microsoft SQL Server.
А вот перспективные NewSQL-системы — CockroachDB, YugabyteDB — заняли нишу миллионов транзакций в секунду с сохранением ACID.
Майкл Стоунбрейкер — человек, создавший СУБД Ingres и Postgres, лауреат премии Тьюринга за вклад в развитие СУБД — в 2007 году опубликовал статью «The End of an Architectural Era: (It’s Time for a Complete Rewrite)».
Основная мысль этой статьи: традиционные реляционные СУБД проектировались в 70-е годы под медленные диски, дорогую память и одноядерные процессоры. Сейчас «железо» совсем другое, а вот многие архитектурные компромиссы остались до сих пор.
Идеи из этой статьи Стоунбрейкера были развиты в проектах H-Store (распределённая база данных в оперативной памяти) и C-Store (колоночная база данных) и легли в основу последующих архитектурных решений.
H-Store позже превратился в коммерческую СУБД VoltDB, а идеи C-Store — в колоночные аналитические СУБД, без которых сегодня невозможно представить аналитику больших данных.
В 2011 году аналитик Мэтью Аслетт, описывая достижения команды Стоунбрейкера, ввёл в своём отчёте термин NewSQL — для систем, которые совмещают SQL, ACID и горизонтальную масштабируемость.
Забавно, что создатель одной из самых надёжных и консервативных СУБД возглавил её архитектурное переосмысление.
PostgreSQL никуда не делся — он устойчиво занимает 4-е место в мире по популярности, уступая лишь Oracle, MySQL и Microsoft SQL Server.
А вот перспективные NewSQL-системы — CockroachDB, YugabyteDB — заняли нишу миллионов транзакций в секунду с сохранением ACID.
🔥4👍2
Две идеи, которые делают NewSQL СУБД такими быстрыми
Продолжая вчерашнюю тему про NewSQL СУБД, давайте разберёмся, как им удаётся совместить SQL и ACID из традиционных реляционных СУБД с горизонтальной масштабируемостью и скоростью из NoSQL. В основе лежат два принципа:
1) Shared-nothing — «ничего общего»
Традиционная реляционная СУБД — это как одна касса в магазине с одной общей очередью. Shared-nothing — это как десять касс в супермаркете, причём каждая автономна: свой набор товаров, свой кассир, своя очередь.
В такой СУБД каждый узел кластера хранит свою часть данных и не зависит от остальных. Нет общей шины — потому масштабирование почти линейное. Каждый узел полностью независим (вплоть до отдельных потоков), что исключает единые точки конкуренции и дорогие протоколы блокировок.
2) Lock-free — «никаких замков»
В традиционных реляционных СУБД есть блокировки: читатель ждёт окончания записи. В концепции lock-free читатели не ждут писателей — они без задержки получают старую или новую версию, но никак не «полуотредактированную». Транзакция либо выполняется целиком, либо откатывается.
Технически это чаще всего реализуется через MVCC (Multi-Version Concurrency Control): система хранит несколько версий данных, и read-only транзакции обращаются к согласованному снимку, не блокируя записи. Совсем строго, «lock-free» в NewSQL не означает полного отсутствия блокировок — некоторые системы комбинируют MVCC с блокировками на запись, но чтение всегда остаётся неблокирующим.
Зачем это нужно?
Классические реляционные базы поощряют вертикальное масштабирование (наращивание числа ядер в одном сервере), но плохо масштабируются горизонтально. NoSQL СУБД хорошо масштабируются горизонтально, но теряют ACID. NewSQL берут shared-nothing для масштабируемости, lock-free для скорости, SQL и ACID для надёжности. В результате получается лучшее из возможных на сегодня решений для распределённой СУБД.
Продолжая вчерашнюю тему про NewSQL СУБД, давайте разберёмся, как им удаётся совместить SQL и ACID из традиционных реляционных СУБД с горизонтальной масштабируемостью и скоростью из NoSQL. В основе лежат два принципа:
1) Shared-nothing — «ничего общего»
Традиционная реляционная СУБД — это как одна касса в магазине с одной общей очередью. Shared-nothing — это как десять касс в супермаркете, причём каждая автономна: свой набор товаров, свой кассир, своя очередь.
В такой СУБД каждый узел кластера хранит свою часть данных и не зависит от остальных. Нет общей шины — потому масштабирование почти линейное. Каждый узел полностью независим (вплоть до отдельных потоков), что исключает единые точки конкуренции и дорогие протоколы блокировок.
2) Lock-free — «никаких замков»
В традиционных реляционных СУБД есть блокировки: читатель ждёт окончания записи. В концепции lock-free читатели не ждут писателей — они без задержки получают старую или новую версию, но никак не «полуотредактированную». Транзакция либо выполняется целиком, либо откатывается.
Технически это чаще всего реализуется через MVCC (Multi-Version Concurrency Control): система хранит несколько версий данных, и read-only транзакции обращаются к согласованному снимку, не блокируя записи. Совсем строго, «lock-free» в NewSQL не означает полного отсутствия блокировок — некоторые системы комбинируют MVCC с блокировками на запись, но чтение всегда остаётся неблокирующим.
Зачем это нужно?
Классические реляционные базы поощряют вертикальное масштабирование (наращивание числа ядер в одном сервере), но плохо масштабируются горизонтально. NoSQL СУБД хорошо масштабируются горизонтально, но теряют ACID. NewSQL берут shared-nothing для масштабируемости, lock-free для скорости, SQL и ACID для надёжности. В результате получается лучшее из возможных на сегодня решений для распределённой СУБД.
👍7
Forwarded from Ассоциация Разработчиков СУБД RuDB
Media is too big
VIEW IN TELEGRAM
День СУБД 2026. Сезон 2 уже близко!
Регистрируйтесь по ссылке:
https://dbd.diasoft.ru
А пока разогреваемся перед новым, вторым сезоном.
Максим Кутузов, коммерческий директор Диасофт, рассказывает, зачем рынку бесплатная открытая СУБД и как развивать её вместе.
В видео обсуждаем, почему разработчики тратят значительную часть ресурсов на одинаковые доработки и как объединение усилий помогает это изменить, что вошло в первую версию RuDB на PostgreSQL 18.2, включая доработки безопасности, in-memory-компоненту и аналоги функций пакетов Oracle.
А ещё разбираем, что открытый исходный код и бесплатное использование дают пользователям, как присоединиться к развитию RuDB и протестировать её на своих задачах.
Видео доступно на:
VK
Rutube
Dzen
YouTube
#ДеньСУБД #RuDB #АссоциацияРазработчиковСУБД
Регистрируйтесь по ссылке:
https://dbd.diasoft.ru
А пока разогреваемся перед новым, вторым сезоном.
Максим Кутузов, коммерческий директор Диасофт, рассказывает, зачем рынку бесплатная открытая СУБД и как развивать её вместе.
В видео обсуждаем, почему разработчики тратят значительную часть ресурсов на одинаковые доработки и как объединение усилий помогает это изменить, что вошло в первую версию RuDB на PostgreSQL 18.2, включая доработки безопасности, in-memory-компоненту и аналоги функций пакетов Oracle.
А ещё разбираем, что открытый исходный код и бесплатное использование дают пользователям, как присоединиться к развитию RuDB и протестировать её на своих задачах.
Видео доступно на:
VK
Rutube
Dzen
YouTube
#ДеньСУБД #RuDB #АссоциацияРазработчиковСУБД
👍6🔥3⚡2
Хорошие новости могут ждать во входящих.
Мы подвели итоги акции по скачиванию - 72 участника выиграли призы.
Теперь отправляем победителям письма на адреса, которые Вы указали при скачивании.
Победителей ждёт добротный мерч - такой, который хочется оставить себе и использовать каждый день.
►Проверьте свою почту.
И папку «Спам» тоже: иногда письма с хорошими новостями сворачивают не туда.
Рассылка ещё идёт, поэтому, если письма пока нет, загляните чуть позже, например завтра.
Нашли письмо о выигрыше?
Ответьте на него - договоримся, как Вам удобнее получить приз.
Спасибо всем, кто участвовал!
Мы подвели итоги акции по скачиванию - 72 участника выиграли призы.
Теперь отправляем победителям письма на адреса, которые Вы указали при скачивании.
Победителей ждёт добротный мерч - такой, который хочется оставить себе и использовать каждый день.
►Проверьте свою почту.
И папку «Спам» тоже: иногда письма с хорошими новостями сворачивают не туда.
Рассылка ещё идёт, поэтому, если письма пока нет, загляните чуть позже, например завтра.
Нашли письмо о выигрыше?
Ответьте на него - договоримся, как Вам удобнее получить приз.
Спасибо всем, кто участвовал!
👍6
This media is not supported in your browser
VIEW IN TELEGRAM