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
► Продолжаем рассказывать о встроенных пакетах Digital Q.DataBase, обеспечивающих совместимость с PL/SQL-окружением Oracle.
Мы поддержали пакет DBMS_CRYPTO.
Для чего он нужен
► Пакет DBMS_CRYPTO предоставляет функции для шифрования, дешифрования и хэширования данных. В Oracle он пришёл на смену DBMS_OBFUSCATION_TOOLKIT и содержит более широкий набор криптографических алгоритмов .
Основные возможности
· ENCRYPT / DECRYPT — шифрование и дешифрование данных (RAW, BLOB, CLOB);
· HASH — вычисление хэш-значений (MD5, SHA-1, SHA-2);
· MAC — хэширование с секретным ключом для проверки подлинности;
· RANDOMBYTES — генерация криптографически стойкой случайной последовательности.
Пример использования
Области применения
· Шифрование персональных данных и платёжной информации;
· Проверка целостности данных через хэш-значения;
· Аутентификация файлов и сообщений с помощью MAC;
· Генерация случайных ключей для криптографических операций.
Мы поддержали пакет DBMS_CRYPTO.
Для чего он нужен
► Пакет DBMS_CRYPTO предоставляет функции для шифрования, дешифрования и хэширования данных. В Oracle он пришёл на смену DBMS_OBFUSCATION_TOOLKIT и содержит более широкий набор криптографических алгоритмов .
Основные возможности
· ENCRYPT / DECRYPT — шифрование и дешифрование данных (RAW, BLOB, CLOB);
· HASH — вычисление хэш-значений (MD5, SHA-1, SHA-2);
· MAC — хэширование с секретным ключом для проверки подлинности;
· RANDOMBYTES — генерация криптографически стойкой случайной последовательности.
Пример использования
-- Шифрование и дешифрование строки
DECLARE
l_src RAW(128) := UTL_RAW.cast_to_raw('Секретные данные');
l_key RAW(128) := UTL_RAW.cast_to_raw('0123456789abcdef');
l_enc RAW(2048);
l_dec RAW(2048);
BEGIN
l_enc := DBMS_CRYPTO.ENCRYPT(l_src, DBMS_CRYPTO.ENCRYPT_AES256 + DBMS_CRYPTO.CHAIN_CBC + DBMS_CRYPTO.PAD_PKCS5, l_key);
l_dec := DBMS_CRYPTO.DECRYPT(l_enc, DBMS_CRYPTO.ENCRYPT_AES256 + DBMS_CRYPTO.CHAIN_CBC + DBMS_CRYPTO.PAD_PKCS5, l_key);
DBMS_OUTPUT.PUT_LINE(UTL_RAW.cast_to_varchar2(l_dec));
END;
Области применения
· Шифрование персональных данных и платёжной информации;
· Проверка целостности данных через хэш-значения;
· Аутентификация файлов и сообщений с помощью MAC;
· Генерация случайных ключей для криптографических операций.
🔥6⚡1👍1
В Digital Q.DataBase, в модуле Onyx, предназначенном для замены Oracle Database, добавлена поддержка типов ANYDATA и ANYDATASET.
► Для чего они нужны
В Oracle эти типы позволяют хранить данные с динамической типизацией — когда заранее неизвестно, какой именно тип будет использоваться. Это полезно при построении универсальных хранилищ, промежуточных буферов и систем с гибкой структурой данных.
ANYDATA — самоописываемый тип, который содержит как данные, так и информацию о своём типе . Может хранить значения NUMBER, DATE, VARCHAR2, RAW, BLOB, CLOB, объектные типы и коллекции . Для создания значений используются методы ConvertXXX (например, ConvertNumber, ConvertVarchar2), а для извлечения — методы GetXXX .
ANYDATASET — тип для работы с набором данных одного типа . Позволяет хранить несколько экземпляров и последовательно их обрабатывать .
► Пример использования
► Области применения
· Универсальные буферы для обмена данными между системами с разными типами;
· Промежуточное хранение результатов динамических запросов;
· Построение гибких ETL-конвейеров.
► Для чего они нужны
В Oracle эти типы позволяют хранить данные с динамической типизацией — когда заранее неизвестно, какой именно тип будет использоваться. Это полезно при построении универсальных хранилищ, промежуточных буферов и систем с гибкой структурой данных.
ANYDATA — самоописываемый тип, который содержит как данные, так и информацию о своём типе . Может хранить значения NUMBER, DATE, VARCHAR2, RAW, BLOB, CLOB, объектные типы и коллекции . Для создания значений используются методы ConvertXXX (например, ConvertNumber, ConvertVarchar2), а для извлечения — методы GetXXX .
ANYDATASET — тип для работы с набором данных одного типа . Позволяет хранить несколько экземпляров и последовательно их обрабатывать .
► Пример использования
-- Создание и использование ANYDATA
DECLARE
v_data SYS.ANYDATA;
v_num NUMBER;
BEGIN
v_data := SYS.ANYDATA.ConvertNumber(12345);
IF v_data.GetNumber(v_num) = DBMS_TYPES.SUCCESS THEN
DBMS_OUTPUT.PUT_LINE('Число: ' || v_num);
END IF;
END;
► Области применения
· Универсальные буферы для обмена данными между системами с разными типами;
· Промежуточное хранение результатов динамических запросов;
· Построение гибких ETL-конвейеров.
🔥5👍2⚡1
Пишем функции для PostgreSQL на… BASIC? 😳
Сегодня, в качестве "поста выходного дня" хочу рассказать Вам об одном довольно необычном расширении для СУБД на базе PostgreSQL.
Сейчас уже никого не удивить тем, что хранимую логику в PostgreSQL можно писать не только на PL/pgSQL, но и на Java или C#. Однако иногда сообщество PostgreSQL создаёт воистину необычные вещи, от которых у старшего поколения разработчиков наворачивается ностальгическая слеза, а у младшего — удивленно округляются глаза.
Встречайте: PL/CBMBASIC — расширение, которое позволяет писать функции для PostgreSQL на Commodore 64 BASIC V2.
Внутри расширения работает настоящий интерпретатор BASIC образца 1982 года, извлеченный из ПЗУ Commodore 64. Каждый вызов функции — это, по сути, «перезагрузка» виртуального компьютера: обнуляется 64 КБ памяти, сбрасываются регистры, и управление передаётся по адресу $E394. Всё это занимает около 15–20 микросекунд — примерно в тысячу раз быстрее, чем на настоящем C64.
Номера строк обязательны, а на имена переменных действуют в точности те же ограничения, что и в "оригинале".
Выглядит это так:
Если хотите сильно удивить коллег или подшутить над ними — «запилите» кусочек хранимой логики столь экзотическим образом. Правда, есть риск, что в качестве «ответки» Вам прилетит хранимая функция на языке BrainF*ck 🤦
Сегодня, в качестве "поста выходного дня" хочу рассказать Вам об одном довольно необычном расширении для СУБД на базе PostgreSQL.
Сейчас уже никого не удивить тем, что хранимую логику в PostgreSQL можно писать не только на PL/pgSQL, но и на Java или C#. Однако иногда сообщество PostgreSQL создаёт воистину необычные вещи, от которых у старшего поколения разработчиков наворачивается ностальгическая слеза, а у младшего — удивленно округляются глаза.
Встречайте: PL/CBMBASIC — расширение, которое позволяет писать функции для PostgreSQL на Commodore 64 BASIC V2.
Внутри расширения работает настоящий интерпретатор BASIC образца 1982 года, извлеченный из ПЗУ Commodore 64. Каждый вызов функции — это, по сути, «перезагрузка» виртуального компьютера: обнуляется 64 КБ памяти, сбрасываются регистры, и управление передаётся по адресу $E394. Всё это занимает около 15–20 микросекунд — примерно в тысячу раз быстрее, чем на настоящем C64.
Номера строк обязательны, а на имена переменных действуют в точности те же ограничения, что и в "оригинале".
Выглядит это так:
CREATE EXTENSION plcbmbasic;
CREATE FUNCTION hello(who text) RETURNS text AS $$
10 PRINT "HELLO, ";WHO$;"!"
$$ LANGUAGE plcbmbasic;
Если хотите сильно удивить коллег или подшутить над ними — «запилите» кусочек хранимой логики столь экзотическим образом. Правда, есть риск, что в качестве «ответки» Вам прилетит хранимая функция на языке BrainF*ck 🤦
🔥6👍3⚡2
Расширение, которое ломает PostgreSQL... чтобы проверить выживет ли он 💥
В сегодняшем «посте выходного дня» я продолжу начатую вчера тему о необычных расширениях для СУБД на базе PostgreSQL и расскажу Вам о pg_kaboom.
Это, пожалуй, самый «разрушительный» и одновременно полезный для тестирования DR проект. Название обыгрывает англоязычное подражание звуку взрыва. По-русски это было бы «бабах!».
Это расширение намеренно «крашит» сервер PostgreSQL самыми разными способами. Цель отнюдь не вредительство, а тестирование отказоустойчивости: можно симулировать нехватку места на диске, segfault, разрушение данных и другие катастрофы прямо из SQL-запроса. Это удобно для проверки систем автоматического переключения (failover) и отработки действий при сбоях.
⚠️ Критически важные предупреждения
Никогда не используйте это расширение на production-средах. Оно предназначено исключительно для тестовых или изолированных сред.
Защита «от дурака» также присутствует. Функции не сработают, пока вы не установите специальный параметр pg_kaboom.disclaimer в значение 'I can afford to lose this data and server'. Для некоторых способов уничтожить сервер дополнительно требуется pg_kaboom.execute = on.
🛠️ Установка и использование
1. Установка расширения в БД (предполагается, что само расширение уже скомпилировано):
2. Установка «предохранителя» (обязательно в каждой сессии):
3. Вызов основной функции: pg_kaboom(text) с названием выбранного Вами «оружия».
4. Вспомогательная функция pg_kaboom_arsenal() возвращает таблицу со списком всех доступных «оружий».
☠️ Арсенал «оружия»
Это расширение — мощный инструмент в руках инженера, который хочет убедиться, что его система готова к худшему. Но, как и любой мощный инструмент, он требует предельной осторожности.
В сегодняшем «посте выходного дня» я продолжу начатую вчера тему о необычных расширениях для СУБД на базе PostgreSQL и расскажу Вам о pg_kaboom.
Это, пожалуй, самый «разрушительный» и одновременно полезный для тестирования DR проект. Название обыгрывает англоязычное подражание звуку взрыва. По-русски это было бы «бабах!».
Это расширение намеренно «крашит» сервер PostgreSQL самыми разными способами. Цель отнюдь не вредительство, а тестирование отказоустойчивости: можно симулировать нехватку места на диске, segfault, разрушение данных и другие катастрофы прямо из SQL-запроса. Это удобно для проверки систем автоматического переключения (failover) и отработки действий при сбоях.
⚠️ Критически важные предупреждения
Никогда не используйте это расширение на production-средах. Оно предназначено исключительно для тестовых или изолированных сред.
Защита «от дурака» также присутствует. Функции не сработают, пока вы не установите специальный параметр pg_kaboom.disclaimer в значение 'I can afford to lose this data and server'. Для некоторых способов уничтожить сервер дополнительно требуется pg_kaboom.execute = on.
🛠️ Установка и использование
1. Установка расширения в БД (предполагается, что само расширение уже скомпилировано):
CREATE EXTENSION pg_kaboom;
2. Установка «предохранителя» (обязательно в каждой сессии):
SET pg_kaboom.disclaimer = 'I can afford to lose this data and server';
-- При необходимости:
SET pg_kaboom.execute = on;
3. Вызов основной функции: pg_kaboom(text) с названием выбранного Вами «оружия».
4. Вспомогательная функция pg_kaboom_arsenal() возвращает таблицу со списком всех доступных «оружий».
☠️ Арсенал «оружия»
· break-archive — устанавливает нерабочую команду archive_command и заставляет сервер перезапуститься, что приводит к сбою архивации WAL.
· fill-log — заполняет всё доступное пространство в каталоге логов (log_directory).
· fill-pgdata — заполняет всё доступное пространство в основном каталоге данных ($PGDATA).
· fill-pgwal — заполняет всё
доступное пространство в каталоге WAL ($PGDATA/pg_wal), что быстро приводит к остановке сервера.
· mem — выделяет большой объём оперативной памяти, провоцируя OOM-killer или сбой.
· restart — выполняет немедленный перезапуск сервера.
· rm-pgdata — выполняет rm -Rf $PGDATA. Самый разрушительный вариант.
· segfault — вызывает segmentation fault в работающем бэкенд-процессе.
· signal — отправляет сигнал SIGKILL процессу Postmaster.
· xact-wrap — быстро вызывает переполнение счётчика транзакций.
· random — выбирает случайное «оружие» из списка и применяет его. Отличный способ проверить устойчивость инфраструктуры к заранее неизвестному сбою сервера.
· null — не делает ничего.
Это расширение — мощный инструмент в руках инженера, который хочет убедиться, что его система готова к худшему. Но, как и любой мощный инструмент, он требует предельной осторожности.
🔥4👍3