Media is too big
VIEW IN TELEGRAM
В этом видео показываю Digital Q.CDC (Change Data Capture) - инструмент для захвата и передачи изменений между СУБД.
Разберём, как CDC позволяет переносить данные без длительного простоя: пока пользователи продолжают работать с исходной системой, изменения фиксируются и передаются в целевую базу.
Такой подход позволяет вынести основную работу за пределы окна переключения и существенно сократить время финальной миграции.
► Основные сценарии использования Digital Q.CDC:
🔹 миграция промышленных баз данных с минимальным окном переключения;
🔹 поддержание актуальной копии данных на резервной площадке;
🔹 передача изменений из транзакционной СУБД в аналитические системы и хранилища;
🔹 консолидация данных из нескольких распределённых систем в единой базе.
Отдельно показываю новый веб-интерфейс Digital Q.CDC.
Через браузер можно создавать и настраивать задачи репликации, контролировать их состояние, просматривать статистику и графики, управлять запуском и остановкой процессов, работать с журналом аудита и уведомлениями.
Digital Q.CDC поддерживает двустороннюю репликацию между Digital Q.DataBase и Oracle Database, PostgreSQL и Microsoft SQL Server.
В видео также показываю настройку репликации СУБД Digital Q.DataBase → Oracle, мониторинг обработки изменений, журнал работы, аудит, SMTP-уведомления и разграничение доступа пользователей по ролям.
Видео также доступно на:
VK
RuTube
Dzen
YouTube
#DigitalQCDC #CDC #ChangeDataCapture #СУБД #МиграцияДанных
Разберём, как CDC позволяет переносить данные без длительного простоя: пока пользователи продолжают работать с исходной системой, изменения фиксируются и передаются в целевую базу.
Такой подход позволяет вынести основную работу за пределы окна переключения и существенно сократить время финальной миграции.
► Основные сценарии использования Digital Q.CDC:
🔹 миграция промышленных баз данных с минимальным окном переключения;
🔹 поддержание актуальной копии данных на резервной площадке;
🔹 передача изменений из транзакционной СУБД в аналитические системы и хранилища;
🔹 консолидация данных из нескольких распределённых систем в единой базе.
Отдельно показываю новый веб-интерфейс Digital Q.CDC.
Через браузер можно создавать и настраивать задачи репликации, контролировать их состояние, просматривать статистику и графики, управлять запуском и остановкой процессов, работать с журналом аудита и уведомлениями.
Digital Q.CDC поддерживает двустороннюю репликацию между Digital Q.DataBase и Oracle Database, PostgreSQL и Microsoft SQL Server.
В видео также показываю настройку репликации СУБД Digital Q.DataBase → Oracle, мониторинг обработки изменений, журнал работы, аудит, SMTP-уведомления и разграничение доступа пользователей по ролям.
Видео также доступно на:
VK
RuTube
Dzen
YouTube
#DigitalQCDC #CDC #ChangeDataCapture #СУБД #МиграцияДанных
Давайте чуть подробнее про DGrid.
Мы привыкли, что СУБД работает с таблицами: строки, столбцы, индексы, SQL-запросы.
Но далеко не для всех задач нужна полноценная реляционная модель.
Иногда нужно просто очень быстро сохранить значение по ключу и так же быстро его получить.
Например, состояние пользовательской сессии, параметр приложения, промежуточный результат расчёта или часто используемое значение.
Для таких задач используется модель key-value, «ключ - значение».
Знаем ключ, сразу получаем связанное с ним значение.
В Digital Q.DataBase эту задачу решает DGrid.
Использовать его можно в двух вариантах.
► Первый - внутреннее KV-хранилище Digital Q.DataBase.
Оно работает отдельным процессом под контролем СУБД, и обращаться к нему можно непосредственно из SQL.
► Второй - DGrid как самостоятельный сервис.
Его можно вынести за пределы конкретного экземпляра СУБД и использовать в распределённой конфигурации с автоматическим перераспределением данных между нодами.
При этом DGrid не ограничивается простым key-value.
Он поддерживает и табличные структуры, а работать с данными можно через SQL-функции, собственный API, а также Redis- и Memcached-совместимые протоколы.
Данные могут храниться на уровне сеанса, пользователя или глобально.
Практические сценарии - хранение Web-сессий, кэширование результатов тяжёлых расчётов и промежуточный кэш между компонентами приложения.
► В составе Digital Q.DataBase DGrid также заменил ранее использовавшийся Tarantool DB.
То есть DGrid не заменяет обычное реляционное хранилище, а дополняет его там, где нужен быстрый доступ к данным и другой способ их хранения.
#СУБД #DGrid #KeyValue #Redis
Мы привыкли, что СУБД работает с таблицами: строки, столбцы, индексы, SQL-запросы.
Но далеко не для всех задач нужна полноценная реляционная модель.
Иногда нужно просто очень быстро сохранить значение по ключу и так же быстро его получить.
Например, состояние пользовательской сессии, параметр приложения, промежуточный результат расчёта или часто используемое значение.
Для таких задач используется модель key-value, «ключ - значение».
Знаем ключ, сразу получаем связанное с ним значение.
В Digital Q.DataBase эту задачу решает DGrid.
Использовать его можно в двух вариантах.
► Первый - внутреннее KV-хранилище Digital Q.DataBase.
Оно работает отдельным процессом под контролем СУБД, и обращаться к нему можно непосредственно из SQL.
► Второй - DGrid как самостоятельный сервис.
Его можно вынести за пределы конкретного экземпляра СУБД и использовать в распределённой конфигурации с автоматическим перераспределением данных между нодами.
При этом DGrid не ограничивается простым key-value.
Он поддерживает и табличные структуры, а работать с данными можно через SQL-функции, собственный API, а также Redis- и Memcached-совместимые протоколы.
Данные могут храниться на уровне сеанса, пользователя или глобально.
Практические сценарии - хранение Web-сессий, кэширование результатов тяжёлых расчётов и промежуточный кэш между компонентами приложения.
► В составе Digital Q.DataBase DGrid также заменил ранее использовавшийся Tarantool DB.
То есть DGrid не заменяет обычное реляционное хранилище, а дополняет его там, где нужен быстрый доступ к данным и другой способ их хранения.
#СУБД #DGrid #KeyValue #Redis
Марафон совместимости СУБД Digital Q.DataBase продолжается...
Его цель обозначил Алексей Татаринов, руководитель Digital Q.DataBase: "Каждое успешное тестирование совместимости СУБД Digital Q.DataBase с решениями других разработчиков расширяет возможности создания импортонезависимых программных комплексов, востребованных организациями из различных сфер для импортозамещения системного ПО"
5 партнеров, 5 отраслей, 1 СУБД. Детали:
1️⃣ Documino от "АйДи – Технологии управления" – один из лидеров российского рынка современных СЭД. Совместимость с Digital Q.DataBase позволяет организациям из любых отраслей выстраивать импортонезависимый и безопасный контур корпоративного документооборота.
2️⃣ SmartWay от PST – платформа для цифровизации сложных бизнес-правил и стратегий принятия решений. Digital Q.DataBase обеспечивает необходимый уровень производительности и надежности для таких систем. Подтверждена готовность решений к совместной промышленной эксплуатации в контурах крупных предприятий, фин.организаций и компаниях госсектора.
3️⃣ Продукты компании "Альта-Софт" широко используются участниками внешнеэкономической деятельности (ВЭД) и таможенными представителями на территории всей России. Для них критична надежность и безопасность работы с данными. Совместимость программного комплекса "Альта-ГТД" с Digital Q.DataBase позволяет предложить участникам ВЭД импортонезависимый программный стек.
4️⃣ Подтверждена корректная и стабильная совместная работа Digital Q.DataBase и телемедицинской платформы "Медтера.Телемедицина" от "Медлайнсофт". Такие платформы работают со сведениями, составляющими врачебную тайну, и специальными категориями персональных данных. Подтвержденная совместимость позволяет мед.организациям выстраивать телемедицинские сервисы на импортонезависимом программном стеке.
5️⃣ Подтвержденная совместимость платформы OpenBPM от Хоулмонт и Digital Q.DataBase позволяет организациям использовать российскую СУБД в составе решений для автоматизации бизнес-процессов и создавать надежную технологическую основу для корпоративных BPM-систем.
Его цель обозначил Алексей Татаринов, руководитель Digital Q.DataBase: "Каждое успешное тестирование совместимости СУБД Digital Q.DataBase с решениями других разработчиков расширяет возможности создания импортонезависимых программных комплексов, востребованных организациями из различных сфер для импортозамещения системного ПО"
5 партнеров, 5 отраслей, 1 СУБД. Детали:
Please open Telegram to view this post
VIEW IN TELEGRAM
Onyx - модуль Digital Q.DataBase, воспроизводящий функциональность Oracle Database.
И это не только поддержка PL/SQL.
В Onyx реализована функциональность системных пакетов DBMS_* и UTL_*, которые используются в Oracle-приложениях.
Несколько интересных примеров:
DBMS_AQ / DBMS_AQADM - очереди сообщений внутри СУБД: отправка, получение и управление очередями.
DBMS_CRYPTO - хеширование, шифрование/расшифрование и MAC.
DBMS_LOCK - пользовательские блокировки для синхронизации процессов.
DBMS_PARALLEL_EXECUTE - разбиение больших операций на части и их параллельное выполнение.
DBMS_PIPE - обмен сообщениями между сессиями через именованные каналы.
DBMS_SCHEDULER - планирование и выполнение фоновых заданий.
DBMS_SQL - расширенная работа с динамическим SQL: курсоры, параметры, выполнение и получение результатов.
И это только часть реализованных Oracle-пакетов.
Digital Q.DataBase: меняем СУБД, а не приложение.
Скоро по каждому из этих пакетов мы выпустим отдельный видеоурок: разберём, для чего он нужен, как работает и покажем его применение на практических примерах в Digital Q.DataBase.
#ЗаменаOracle #OracleDB #Импортозамещение #СУБД
И это не только поддержка PL/SQL.
В Onyx реализована функциональность системных пакетов DBMS_* и UTL_*, которые используются в Oracle-приложениях.
Несколько интересных примеров:
DBMS_AQ / DBMS_AQADM - очереди сообщений внутри СУБД: отправка, получение и управление очередями.
DBMS_CRYPTO - хеширование, шифрование/расшифрование и MAC.
DBMS_LOCK - пользовательские блокировки для синхронизации процессов.
DBMS_PARALLEL_EXECUTE - разбиение больших операций на части и их параллельное выполнение.
DBMS_PIPE - обмен сообщениями между сессиями через именованные каналы.
DBMS_SCHEDULER - планирование и выполнение фоновых заданий.
DBMS_SQL - расширенная работа с динамическим SQL: курсоры, параметры, выполнение и получение результатов.
И это только часть реализованных Oracle-пакетов.
Digital Q.DataBase: меняем СУБД, а не приложение.
Скоро по каждому из этих пакетов мы выпустим отдельный видеоурок: разберём, для чего он нужен, как работает и покажем его применение на практических примерах в Digital Q.DataBase.
#ЗаменаOracle #OracleDB #Импортозамещение #СУБД
🦆 Как утка по имени Уилбур дала название для DuckDB – самой скачиваемой аналитической СУБД в мире
В 2018 году двое амстердамских учёных из CWI (того самого научного центра, где в 1989-м Гвидо ван Россум начал писать Python) — старший научный сотрудник Ханнес Мюлайзен и его аспирант Марк Расвельдт — начали проект без бюджета, роадмапа и заказчика. Они задались вопросом: почему дата-сайентисты мучаются с медленными dataframe-движками вместо нормальной СУБД? И решили написать свою.
Идея проекта формулировалась просто — «нужна легкая СУБД вроде SQLite, но только для аналитики»: встраиваемый движок без сервера и сложной установки, но оптимизированный под аналитические запросы.
Первое демо с результатами проекта они провели в 2019-м на конференции SIGMOD. Именно тогда мир узнал о СУБД DuckDB - названной так в честь утки по имени Уилбур, принадлежавшей Ханнесу.
В 2021-м Ханнес и Марк основали DuckDB Labs. А 2024-м вышла версия 1.0 с кодовым именем Snow Duck. Сегодня DuckDB — одна из самых популярных аналитических СУБД: миллионы загрузок в месяц и десятки тысяч звёзд на GitHub.
История DuckDB — редкий пример того, как исследовательский проект стал востребованным инструментом для крупнейших корпораций, тысяч стартапов и миллионов специалистов по анализу данных. Просто два умных человека заметили реальную боль data-аналитиков и не стали никого ждать: взяли и сами написали инструмент для решения проблемы. Ну а утка по имени Уилбур им в этом помогла.
В 2018 году двое амстердамских учёных из CWI (того самого научного центра, где в 1989-м Гвидо ван Россум начал писать Python) — старший научный сотрудник Ханнес Мюлайзен и его аспирант Марк Расвельдт — начали проект без бюджета, роадмапа и заказчика. Они задались вопросом: почему дата-сайентисты мучаются с медленными dataframe-движками вместо нормальной СУБД? И решили написать свою.
Идея проекта формулировалась просто — «нужна легкая СУБД вроде SQLite, но только для аналитики»: встраиваемый движок без сервера и сложной установки, но оптимизированный под аналитические запросы.
Первое демо с результатами проекта они провели в 2019-м на конференции SIGMOD. Именно тогда мир узнал о СУБД DuckDB - названной так в честь утки по имени Уилбур, принадлежавшей Ханнесу.
В 2021-м Ханнес и Марк основали DuckDB Labs. А 2024-м вышла версия 1.0 с кодовым именем Snow Duck. Сегодня DuckDB — одна из самых популярных аналитических СУБД: миллионы загрузок в месяц и десятки тысяч звёзд на GitHub.
История DuckDB — редкий пример того, как исследовательский проект стал востребованным инструментом для крупнейших корпораций, тысяч стартапов и миллионов специалистов по анализу данных. Просто два умных человека заметили реальную боль data-аналитиков и не стали никого ждать: взяли и сами написали инструмент для решения проблемы. Ну а утка по имени Уилбур им в этом помогла.
С Днём программиста!
Это праздник людей, которые умеют превращать идеи в работающие вещи.
Тех, кто часами смотрит в монитор, чтобы в итоге всё просто работало - и никто не задумывался, сколько за этим стоит...
Мы видим программистов каждый день: они пишут то, что потом живёт в банках, больницах, на транспорте, в магазинах.
Без них любые системы это просто железо.
Спасибо Вам за Вашу работу!
За терпение, за любопытство, за умение не сдаваться, когда что-то не собирается с первого раза.
С праздником!
Пусть будет больше интересных задач, удобных инструментов и решений, которые приятно находить.
Это праздник людей, которые умеют превращать идеи в работающие вещи.
Тех, кто часами смотрит в монитор, чтобы в итоге всё просто работало - и никто не задумывался, сколько за этим стоит...
Мы видим программистов каждый день: они пишут то, что потом живёт в банках, больницах, на транспорте, в магазинах.
Без них любые системы это просто железо.
Спасибо Вам за Вашу работу!
За терпение, за любопытство, за умение не сдаваться, когда что-то не собирается с первого раза.
С праздником!
Пусть будет больше интересных задач, удобных инструментов и решений, которые приятно находить.
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