Приглашаем на вебинар «СУБД + AI: векторные операции, LLM и полиглотная архитектура в Digital Q.DataBase»
10 августа в 13:00 (мск) компания «Диасофт» проведет практический вебинар о новых возможностях Digital Q.DataBase «СУБД + AI: векторные операции, LLM и полиглотная архитектура в Digital Q.DataBase».
Вебинар «СУБД + AI: векторные операции, LLM и полиглотная архитектура в Digital Q.DataBase»
Ключевые темы:
Полиглотная архитектура Digital Q.DataBase. Как в единой среде работать с базами PostgreSQL, Microsoft SQL Server и Oracle
Симбиоз СУБД и AI. Поддержка векторных операций и интеграция с большими языковыми моделями (LLM) под капотом СУБД
Высокая скорость работы с данными. Архитектура и новые возможности встроенного KV-хранилища DGrid для сверхбыстрого доступа к информации
Развитие RuDB. Обзор новой функциональности и обновленных пакетов платформы
Как реализовать семантический поиск для RAG-архитектуры в PostgreSQL без усложнения инфраструктуры?
Ситуация: вы разрабатываете чат-бота для техподдержки на базе RAG-архитектуры. Используете PostgreSQL как хранилище знаний и делаете поиск по текстовым полям, но качество ответов нестабильное: система плохо справляется с синонимами, профессиональным сленгом и переформулировками запросов. Обязательно ли внедрять отдельную векторную базу данных, или можно реализовать семантический поиск прямо в PostgreSQL? Возможна ли простая проверка продуктовой гипотезы без усложнения архитектуры?
Да, семантический поиск в RAG-сценариях можно реализовать прямо в PostgreSQL без выделенной векторной базы данных (ClickHouse, Opensearch, Qdrant, Milvus и т. д).
Для этого используется PostgreSQL + расширение pgvector, которое добавляет поддержку хранения эмбеддингов (векторов) и поиск по расстоянию до ближайших соседей (KNN) прямо внутри SQL-движка. Разберем, как это работает на практике.
В RAG-пайплайне текст документов и запрос пользователя преобразуются в векторные представления. PostgreSQL хранит эти векторы в таблице и позволяет выполнять поиск по смысловой близости, а не по точному совпадению слов.
Для этой задачи будем использовать pgvector — это расширение к PostgreSQL, которое добавляет тип данных vector и операторы поиска по расстоянию до ближайших соседей (KNN).
Поддерживаются три основные метрики сравнения векторов:
L2 (евклидово расстояние) — классическое расстояние между двумя точками в многомерном пространстве. Хорошо работает, если векторы не нормализованы и распределение значений относительно равномерное.
Cosine similarity (косинусное сходство). В отличие от предыдущей метрики измеряет не абсолютное расстояние, а угол между двумя векторами. Подходит для текстовых эмбеддингов, где важна направленность, а не масштаб. Требует нормализации векторов.
Inner product (внутреннее произведение) — скалярное произведение двух векторов. Может использоваться как прокси для оценки «сходства» при обучении моделей и в задачах ранжирования.
Допустим, мы получаем на наш запрос именно такой вектор от модели OpenAI. Для хранения создаем таблицу с типом VECTOR:
CREATE TABLE items (
id SERIAL PRIMARY KEY,
title TEXT,
embedding VECTOR(1536)
);
Добавим данные для нескольких векторов разных объектов:
Теперь сравним их попарно и отсортируем по расстоянию:
SELECT
a.title AS title_a,
b.title AS title_b,
a.embedding <-> b.embedding AS distance
FROM items a
JOIN items b ON a.id < b.id
ORDER BY distance;
Оператор <-> здесь вычисляет расстояние между двумя векторами. Таким образом, мы можем оценивать степень семантической близости любых объектов, представленных векторами. Какая именно метрика используется, зависит от операторного класса, заданного при создании индекса.
В подобных RAG-сценариях нет необходимости сразу вводить отдельный класс инфраструктуры типа векторная БД. Семантический поиск можно реализовать эволюционно поверх существующего PostgreSQL.
А если вы не хотите самостоятельно заниматься настройкой индексов, тюнингом памяти и производительности, а также обновлением версии PostgreSQL, то воспользуйтесь DBaaS от Selectel. Мы предоставим вам кластер PostgreSQL с преднастроенными расширениями, готовый к эксплуатации под нагрузкой. Это позволит сосредоточиться на RAG-логике и качестве поиска, а не на инфраструктурной оптимизации.
Как разрешить пользователю реплики удаленно подключаться к Master-серверу PostgreSQL?
Вы настраиваете отказоустойчивый кластер баз данных. При попытке синхронизировать реплику с мастер-сервером соединение обрывается с ошибками сетевого доступа. В каком конфигурационном файле и как именно нужно прописать доступы, чтобы Master принял входящее подключение?
По умолчанию PostgreSQL придерживается строгой политики безопасности и блокирует любые удаленные попытки подключения, если они не разрешены в подсистеме авторизации.
Чтобы решить эту проблему, необходимо отредактировать конфигурационный файл клиентской аутентификации pg_hba.conf на стороне Master-сервера и явно разрешить репликацию для IP-адреса вашей реплики.
Для доступа к реплицируемым данным у пользователя replicator должна быть привилегия replication:
ALTER ROLE replicator WITH REPLICATION;
Предварительно ознакомьтесь с порядком применения правил в pg_hba.conf в официальной документации.
Чтобы PostgreSQL применил изменения в конфигурации авторизации, выполните reload службы в терминале:
systemctl reload postgresql
В качестве альтернативы можно отправить сигнал процессу postmaster с помощью pg_ctl reload, вызовом SQL-функции pg_reload_conf() или используя kill -HUP.
После применения изменений Master-сервер начнет принимать входящие пакеты от указанного IP-адреса, и процесс репликации сможет успешно инициализироваться.
На первый взгляд, настройка репликации в PostgreSQL кажется простой задачей: достаточно открыть доступ в pg_hba.conf и подключить standby-сервер.
Но в production-инфраструктуре за этой «простой настройкой» скрывается целый стек инженерных задач: необходимо следить за консистентностью WAL-журнала, контролировать лаг между репликами, обеспечивать безопасную сетевую доступность между узлами, настраивать резервное копирование, регулярно тестировать сценарии аварийного переключения и быть готовым вручную восстанавливать кластер в случае деградации одного из серверов.
Поэтому в ряде сценариев современные команды переходят от self-managed PostgreSQL к PaaS-решениям вроде Managed Databases, где отказоустойчивость, репликация и обслуживание кластера уже реализованы на уровне платформы.
Это позволяет сократить операционные расходы на сопровождение инфраструктуры и снизить риск простоев критичных сервисов.
Приглашаем на пятилетие «Тантор Лабс». 10 сентября - Tantor JAM 2026
Первый юбилей Tantor — пять лет с момента основания компании. За это время мы прошли путь от стартапа до технологического лидера, одного из ведущих российских разработчиков в области управления и хранения данных, создали собственную экосистему продуктов и собрали вокруг себя сообщество, которое сегодня во многом определяет развитие российского рынка СУБД.
Программу скоро представим. Среди главных премьер:
Новое поколение Платформы Tantor, основанное на AI-first подходе. Представим ИИ-администратора БД с целым роем специализированных ИИ-агентов, которые возьмут на себя рутинные операции по работе с СУБД.
Результаты испытаний МБД Tantor XData Gen3 на различных профилях нагрузки. Покажем, как enterprise-технологии, ранее доступные только в зарубежных решениях, — независимое масштабирование Compute и Storage, RDMA, распределенная файловая система и полноценный HTAP — становятся доступны в российском ПАКе.
Подробнее расскажем о Tantor Polar — новой распределенной СУБД, открывающей следующий этап развития российских PostgreSQL-технологий с полным сохранением совместимости с экосистемой Postgres.
Вас ждут выступления руководителей разработки, общение с инженерами, архитекторами, заказчиками и партнерами, а также праздничная программа в честь пятилетия компании.
1 июля мы провели вебинар, посвящённый новым возможностям Digital Q.DataBase 18.2.
В рамках вебинара я, Андрей Жуйков, амбассадор компании «Диасофт», рассказал о ключевых возможностях Digital Q.DataBase 18.2 — масштабном обновлении, направленном на развитие совместимости с корпоративными СУБД и упрощение миграции существующих систем.
Изменения коснулись Microsoft SQL Server-направления: расширена поддержка T-SQL, Service Broker, CLR-сборок, механизма CDC, а также появилась служба отчётов Digital Q.DataBase, совместимая с SQL Server Reporting Services (SSRS).
Отдельное внимание уделено Oracle-направлению: расширена поддержка Oracle-совместимых пакетов, курсоров и Bind-переменных, улучшена работа JDBC-драйвера, доработаны средства миграции Oracle-объектов, а также появилась новая технология автоматизированного перевода Oracle Forms в современные приложения.
На вебинаре рассмотрим ключевые изменения релиза, покажем их практическое применение и расскажем, как новые возможности помогают ускорить миграцию корпоративных систем и снизить затраты на переход на российскую СУБД.
В программе:
🔹 Обзор Digital Q.DataBase 18.2 Ключевые изменения релиза. Развитие совместимости с Microsoft SQL Server и Oracle. Новые возможности для миграции корпоративных систем.
🔹 Новая версия CDC Обновлённый механизм Change Data Capture. Новый веб-интерфейс управления. Сценарии применения и преимущества.
🔹 Новые возможности миграции и совместимости Расширение совместимости с Microsoft SQL Server. Новые Oracle-пакеты и развитие Oracle-диалекта. Поддержка CLR-сборок. Развитие Service Broker.
🔹 Служба отчётов Digital Q.DataBase Аналог SQL Server Reporting Services (SSRS). Поддержка RDL-отчётов. Формирование отчётов в HTML и PDF.
🔹 Новая технология перевода Oracle Forms Автоматизированный перевод Oracle Forms в современные приложения. Архитектура решения. Демонстрация технологии.
► Бесплатная полнофункциональная версия дистрибутива (до 8 ядер) с возможностью использования в том числе в коммерческих целях.
В этом докладе Илья Виссарионов рассказывает о практическом опыте компании «Диасофт» по импортозамещению крупной автоматизированной банковской системы, которая десятилетиями работала на Microsoft SQL Server.
Главной особенностью проекта стало то, что значительная часть бизнес-логики была реализована в виде хранимых процедур. Полное переписывание миллионов строк SQL-кода оказалось бы слишком дорогим и длительным, поэтому был выбран другой путь — развитие Digital Q.DataBase с максимальной совместимостью с Microsoft SQL Server и сохранением существующих приложений.
В докладе подробно рассматриваются реальные технические проблемы, с которыми столкнулась команда при переносе банковской системы на PostgreSQL-совместимую платформу: различия в типах данных, работе процедур, оптимизаторе запросов, производительности, временных таблицах, пользовательских типах данных и других механизмах СУБД.
Отдельное внимание уделено нагрузочному тестированию. Автор показывает, как поэтапная оптимизация Digital Q.DataBase позволила добиться производительности, сравнимой с Microsoft SQL Server, а по ряду операций — превзойти её, при этом сохранив существующую бизнес-логику без масштабного переписывания.
В этом видео вы узнаете:
🔹 почему импортозамещение крупных банковских систем требует особого подхода; 🔹 с какими проблемами столкнулась команда при переносе АБС с Microsoft SQL Server; 🔹 почему стандартного PostgreSQL оказалось недостаточно; 🔹 какие механизмы совместимости были реализованы в Digital Q.DataBase; 🔹 как удалось сохранить существующий T-SQL-код без его переписывания; 🔹 какие доработки были выполнены для повышения производительности; 🔹 как проводилось нагрузочное тестирование на реальных банковских сценариях; 🔹 каких результатов удалось добиться по сравнению с Microsoft SQL Server.
Если вас интересуют вопросы импортозамещения СУБД, миграции корпоративных систем или построения PostgreSQL-совместимых платформ корпоративного уровня — этот доклад будет полезен разработчикам, архитекторам, администраторам баз данных и техническим руководителям.
Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений. Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.
Как мы воспроизводим функциональность Oracle и создаем аналоги DBMS-пакетов.
В предыдущем посте я рассказывал о технологии «Полиглот» в Digital Q.DataBase — возможности исполнять T-SQL "на лету" наряду с родным PL/pgSQL, что позволяет мигрировать приложения с Microsoft SQL Server.
Но полиглотность Digital Q.DataBase этим не ограничивается.
Сегодня хочу поделиться выступлением моего коллеги Ильи Лебедева, посвящённым Oracle-направлению. В докладе он подробно рассказывает о поддержке PL/SQL и о том, как Digital Q.DataBase помогает переносить системы с Oracle, сохраняя серверную бизнес-логику и клиентские приложения без дорогостоящей переработки.
В этом выступлении обсуждаются:
🔹 Как Digital Q.DataBase реализует полноценную поддержку Oracle-диалекта, включая пакеты, DBMS-пакеты и PL/SQL-код. 🔹 Почему SQL- и PL/SQL-код может выполняться без изменений. 🔹 Как работает мастер переноса баз данных и какие скорости миграции можно получить на практике. 🔹 Каким образом обеспечивается бесшовное подключение существующих приложений через OCI и JDBC. 🔹 Почему переход с Oracle на Digital Q.DataBase может занять месяцы вместо лет. 🔹 Как накопленный опыт миграций позволяет ускорять последующие проекты и снижать объем доработок.
В докладе также показаны реальные сценарии переноса корпоративных систем, демонстрация работы клиентских приложений после замены СУБД и подход компании к развитию совместимости с Oracle на основе запросов заказчиков.
Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений. Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.
В этом докладе я (Жуйков Андрей, амбассадор компании «Диасофт») рассказываю о подходе Digital Q.DataBase к импортозамещению зарубежных СУБД и миграции корпоративных систем без переписывания прикладного кода.
В видео рассмотрены:
🔹 архитектура и возможности Digital Q.DataBase; 🔹 технология Polyglot и поддержка нескольких SQL-диалектов в одной СУБД; 🔹 совместимость с Microsoft SQL Server и Oracle; 🔹 исполнение T-SQL и PL/SQL без изменения бизнес-логики приложений; 🔹 поддержка протокола TDS и работа со стандартными драйверами Microsoft; 🔹 миграция 1С с Microsoft SQL Server на Digital Q.DataBase; 🔹 демонстрация работы через DBeaver, SQL Server Management Studio и Python; 🔹 поддержка Service Broker, Reporting Services и CLR-сборок; 🔹 примеры реальных проектов и опыт внедрения у заказчиков.
Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений.
Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.
Определяет представление планировщика об эффективном размере дискового кеша, доступном для одного запроса. Это представление влияет на оценку стоимости использования индекса; чем выше это значение, тем больше вероятность, что будет применяться сканирование по индексу, чем ниже, тем более вероятно, что будет выбрано последовательное сканирование.
Вот прямо с первых строк мозги выносит: при чём тут оценка (ОЦЕНКА!) размера дискового кэша и выбор между индексным или полным сканированием? Не знаю, кому как, но лично мне совсем непонятно. Следующее, если effective_cache_size показывает оценку размера ДИСКОВОГО кеша (для меня одного словосочетание “дисковый кэш” означает “кэш файловой системы”?), то откуда взялась рекомендация в значение 3/4 размера оперативной памяти, если 1/4 - это shared_buffers? Рекомендатели, ау! 1/4 + 3/4 = 1, арифметика, начальная школа. А где СУБД должна выполнять манипуляции с данными? В свопе? Всё остальное описание совершенно не добавляет ясности по использованию данного параметра, увы нам, постгресовым администраторам баз данных.
Кратко. Главное. Данный параметр показывает ОБЩИЙ размер кэша: постгресовый shared_buffersплюс (плюс выделен жирным шрифтом в оригинальной статье!) кэш файловой системы. С этим уточнением рекомендация в 3/4 размера оперативной памяти выглядит приемлемой. Следующее. Обсуждаемый параметр применяется для вычисления вероятности того, что однажды прочитанные данные будут находиться в кэше при повторном обращении в рамках ОДНОГО запроса. Т.е. для предпочтения соединения таблиц вложенным циклом (Nested loop join) при выборе методов соединения. Если высока вероятность того, что данных при повторном запросе в кэше не окажется, то будет выбрано либо полное сканирование таблиц(ы), либо сканирование по битовой маске, либо соединение хешем (hash join), либо соединение слиянием (merge join). Далее. Этот параметр - верхняя оценка, завышенное значение не приводит к серьёзным проблемам (по крайней мере в статье об этом говорится). Ограничение. effective_cache_size должен быть больше shared_buffers, ибо меньшее значение является бессмысленным (по статье).
30 июня эксперты «Тантор Лабс» представят разбор Tantor XData Gen3 — третьего поколения машины баз данных для высоконагруженных корпоративных систем, реализующей ряд технологий, ранее доступных в таких западных продуктах как Oracle Exadata, SAP HANA и IBM Netezza.
В программе:
эволюция архитектуры Tantor XData и ключевые изменения в Gen3: независимое масштабирование подсистем вычислений и хранения, полноценная обработка смешанной нагрузки (HTAP) на едином наборе данных;
новые возможности платформы и сценарии их применения;
устройство и особенности распределенной СУБД Tantor Polar;
организация вычислительных ресурсов и ресурсов хранения;
инструменты управления и мониторинга.
Отдельный блок будет посвящён практической работе с машиной баз данных. Пройдем интерактив с реальным ситуациями, демонстрирующими преимущества новой машины баз данных перед классическими СУБД.
Эксперты мероприятия:
Вадим Яценко, генеральный директор «Тантор Лабс»
Сергей Серегин, руководитель технического пресейл «Тантор Лабс».
Мой опыт с Supabase: 8 неочевидных костылей, о которых молчат в красивых туториалах.
Все вокруг хвалят Supabase за скорость. И да, я тоже повелся. Как бэкендера меня поначалу знатно корежило от того, что фронт ходит тупо прямиком в базу. Но ради быстрой доставки фичей я зажмурился.
Спойлер: пилится-то всё реально быстро. Только потом ты ловишь тихие баги, пропадающие логи и жесткий вендор-лок. Я собрал на Supabase уже несколько проектов и успел поседеть.
Короче, вот за что вы будете страдать на бесплатном тарифе (да и не только на нем).
Логи. Их просто нет Точнее, они живут ровно 24 часа. Упало что-то в пятницу вечеро - в понедельник с утра ты дебажишь святым духом. Встроенный поиск это вообще кровь из глаз. Без какого-нибудь Datadog или Logflare там тупо не выжить.
Edge-функции и проклятые холодные старты Это отдельный котел. Писать надо на Deno, так что половина привычных npm-пакетов идет лесом. Лимиты на вызовы жесткие, долгую таску не запустить. Но самое бесячее — холодные старты. Пока поднимется пул коннектов к базе, проходит до трех секунд. В моем сервисе post-cooler.ruedge-функция отдает HTML для линк-страничек. Я смотрю в метрики и плачу: кликов куча, а дожидаются загрузки единицы. Конверсия просто умирает на этапе бесконечного лоадера.
Палево с доменами в OAuth Юзер логинится через Google, а в окне авторизации торчит <project-id>.supabase.co. Я когда делал photo math, целый час дебажил эту хрень. Думал, что сам где-то накосячил — на локалке-то всё выглядело нормально! Оказалось, не баг, а фича. Хочешь свой домен? Плати.
Хаос со схемами БД Экспорт схем из дашборда выпилили еще в 2025 году. Сейчас помогаю проекту the-signal переехать на селф-хост. До этого код там писали vibe-кодеры, которые вообще не парились про миграции. Вытащить дамп схемы из облака было той еще болью. Без жесткой дисциплины база очень быстро превращается в неуправляемую помойку.
Тормоза локальной разработки Я постоянно прыгаю между проектами. И каждый гребаный раз supabase start лезет тянуть свежие Docker-образы. Поднимает 10+ контейнеров, а ты сидишь и тупишь в терминал. Весь кайф от "быстрой" разработки улетучивается.
Тихие RLS-ошибки RLS (Row Level Security) ошибается молча. Накосячил в политиках? БД тебе не скажет. UPDATE просто вернет 0 affected rows, а SELECT подтянет половину данных.
Транзакции и боль SQL-функций Через REST API нельзя сделать нормальную транзакцию на несколько таблиц. Нужно атомарно создать юзера, профиль и настройки? Обломись. У меня пока ничего не отвалилось, но я с ужасом жду, когда в базе начнут копиться "осиротевшие" записи. Чтобы это обойти, приходится писать логику на PL/pgSQL прямо в базе. Редактор там примитивный, автокомплита толком нет и дебажить то еще удовольствие.
Вендор-лок Клиентский SDK намертво завязан на специфичный синтаксис PostgREST и их собственные токены. Если однажды решишь переехать на нормальный самописный бэк: придется рефакторить вообще весь клиентский код.
Короче. Для MVP или пет-проекта, чтобы просто проверить гипотезу на коленке - это топ. Да, часть этих костылей можно вылечить, если закинуть денег и перейти на платную версию. Но возникает резонный вопрос: за те же 25 баксов в месяц можно спокойно поднять Supabase на нормальной VPS-ке и вообще забыть про лимиты.
Кто еще сидит на Supabase или Firebase? С чем боретесь? И есть тут те, кто уже психанул и переехал на свой бэк?
Сегодня к вечеру я совсем обленился и решил доверить нейронке storege создать к коннектору в библиотеку redb.route используя redb Изучала дольше чем писала. 😊 Накидала в одну сессию за один проход с тестами. __ Аудитория: разработчики уже подключают DSL-маршруты к redb.Route, которые хотят, чтобы LLM был полноценным пользователем конвейера - с памятью, бюджетом, разрешениями и аудиторским журналом, а не HTTP—вызовом без сохранения состояния, который ничего не оставляет после себя. единый линейный маршрут.Услуги.AddRedbLlmStorage() — переключает цикл работы агента с "забывает все при перезапуске" на постоянную систему по умолчанию. Все пять поверхностей (расшифровки, утверждения, бюджеты, идемпотентность, аудит) перемещаются в redb. Ни одна строка кода маршрута не меняется — ваш существующий .To("llm://claude") начинает сохраняться сам по себе.
Тут в ленту прилетела новость, которая касается всех постгресменов, кто пользуется pgbackrest-ом для создания резервных копий. Либо собирается им пользоваться. А именно, создатель и разработчик проекта закончил работу над ним: https://github.com/pgbackrest/pgbackrest#notice-of-obsolescence. Грусть, печаль, тоска, тлен и безысходность. :( И статью править, и исходный материал в ЖЖ.
Вебинар о том, как обеспечить стабильность баз данных при росте проекта и нагрузок
Самостоятельное администрирование баз данных может превратиться в рутину: постоянные обновления, бэкапы, мониторинг и работа с нагрузкой. С ростом проекта стандартных настроек уже не хватает, а риск просадок и простоев из-за ошибок в конфигурации становится выше.
Это третий вебинар из большого трека про эволюцию приложения в облаке. На этот раз разберем, как передать обслуживание PostgreSQL управляемому сервису в облаке и настроить архитектуру Master/Replica для стабильной работы при высоких нагрузках.
О чем будем говорить:
сравним управляемую и self-hosted СУБД PostgreSQL: выясним, когда пора задуматься о переезде;
разберем ключевые метрики БД: на что обращать внимание в мониторинге, чтобы не доводить до инцидента;
обсудим, как архитектура Master/Replica повышает отказоустойчивость приложения.
После теории будет насыщенное демо, на котором покажем, как добавить в сервис поддержку нескольких реплик и разгрузить базу на чтении. Затем проведем нагрузочное тестирование и сравним показатели до и после оптимизации. Еще покажем, как организовать резервное копирование, разделить трафик на чтение и запись и повысить отказоустойчивость приложения.
Вебинар будет полезен бэкенд-разработчикам, DevOps- и SRE-инженерам, архитекторам и тимлидам, которые отвечают за стабильность базы данных, производительность сервисов и развитие приложения под растущей нагрузкой.
Мировой лидер по добыче алмазов АЛРОСА перевел DIrectum RX на СУБД Tantor Postgres, проект занял всего 5 месяцев. При этом бизнес-процессы работали в штатном режиме, сроки не сместились, бюджет не увеличился.
В результате компания получила обновленный ИТ-контур, он обеспечивает безопасность критически важных данных и стабильную производительность корпоративных систем.
23 апреля в 11:00 мск на бесплатном вебинаре эксперты АЛРОСА, «Тантор Лабс», «СТАРКОВ Групп» и Directum поделятся подробностями кейса.
Для участия нужна только регистрация. Встретимся на вебинаре!
Встраивание вычислений в PostgreSQL: PL*, extensions, а теперь и WASM
В рамках выступления на PG BootCamp Russia 2026 Дмитрий Дорофеев, главный конструктор Luxms, рассказал о том, как сегодня развивается встраивание вычислений в PostgreSQL: от классических процедурных языков (PL/pgSQL, PL/Python и других) до новых возможностей с использованием WebAssembly (WASM).
В PostgreSQL исторически поддерживается несколько десятков языков программирования. Если этого недостаточно, можно воспользоваться готовым расширением из огромной экосистемы либо написать своё. Прогресс не стоит на месте, и теперь для выполнения стороннего кода в PostgreSQL можно использовать WASM.
На примере Luxms BI я расскажу, как мы автоматически генерируем Swagger-документацию прямо внутри PostgreSQL с помощью open-source технологий и WASM.
🚨 Мы в Diasoft запускаем свою серию мероприятий по СУБД. Первое — уже 21 апреля 2026: конференция о промышленной эксплуатации и архитектуре корпоративных данных.
❯ Место проведения — Москва, Кибердом.
Я выступлю с двумя докладами:
🔥 Как мы воспроизводим функциональность MS SQL и переносим решения без переписывания 🔥 Digital Q.CDC — когда критична синхронизация изменений данных.
❯ В нашей программе намечается много интересного, в том числе обсудим:
🔹 как мы воспроизводим функциональность Oracle 🔹 практика импортозамещения и работа с высоконагруженными системами на базе Digital Q.DataBase 🔹 Low-Code подходы и замещение зарубежных платформ 🔹 единая работа данных для OLTP и OLAP 🔹 развитие инструментов управления СУБД 🔹 как формируется СУБД за счет объединения компетенций и технологий
Наши профессионалы подробно объяснят реальные кейсы и практику внедрения.
🔹 Всем привет. Сегодня хочу рассказать Вам о том, как мы склонировали у себя один из самых "прикладных" сервисов из поставки Microsoft SQL Server.
➡️ Речь пойдет об SQL Server Reporting Services (SSRS) - механизме, который позволяет получать разнообразные отчеты, запрашивая их построение по API или по расписанию.
➡️ Представьте ситуацию: Вы использовали Microsoft SQL Server и у Вас было несколько сотен разнообразных отчетов, что ранее строились на основе данных в Ваших БД. И тут импортозамещение! Надо переходить на российское решение из Реестра Минцифры. Для замены СУБД самый легкий вариант такого перехода - Digital Q.DataBase. Мастер переноса БД поможет перенести данные, Мастер сравнения БД проверит корректность переноса, Digital Q.CDC обеспечит синхронизацию данных в обеих СУБД, что позволит сократить до нескольких минут сам момент перехода. Но что делать с сотнями отчётов, что привыкли получать Ваши пользователи?
Оставить как есть, пусть строятся при помощи зарубежного инструмента? Вряд-ли это приемлемо. Какое-то очень кусочное импортозамещение получается!
Переписать на другом инструменте? Даже из расчета по дню на отчёт это сотни человеко-дней "ручного труда", а потом тестирование, выгребание ошибок, восстановление порушенных интеграций (построение некоторых отчетов могло запрашиваться извне, через API). Тоже так себе вариант!
➡️ Мы предлагаем более живую альтернативу: воспользоваться нашей реинкарнацией службы отчетов.
На приложенных скриншотах два отчёта. Один построен в оригинальном инструменте, второй у нас. Как видите, они очень похожи, более того построены по одному и тому же шаблону, что был перенесен из оригинала к нам при замене СУБД.
Внешний вид и API - все сохранено. Как говорят наши "заокеанские партнеры" - настоящий "drop-in replacement" (безшовная замена одного инструмента другим). Именно так и должно выглядеть хорошо проработанное импортозамещение.
Худший бэкап — не тот, что не восстановился. А тот, что положил прод.
Что, если post-script не отработал? Моргнула сеть или случился таймаут. Внешний оркестратор просто пишет в лог failed и снимает задачу. А вот PostgreSQL об этом не знает. База остается в режиме бэкапа и начинает непрерывно копить WAL-файлы, ожидая команды на завершение.
Получается, что инструмент для защиты бизнеса от даунтайма, своими руками этот даунтайм и устроил.
Уметь дернуть pg_backup_start( ) — мало. Если СРК не имеет встроенного watchdog-механизма для сброса зависших сессий, резервное копирование превращается в угрозу доступности. Разделение ответственности — правильный архитектурный подход, но он означает, что защита базы от переполнения диска полностью ложится на ваши плечи.
О зависшем backup mode, разрывах PITR и других неудобных вопросах эксплуатации PostgreSQL совместно с Акурой поговорим врежиме live-демо на вебинаре 26 марта в 11:00 (МСК).
Регистрация по ссылке. Приносите в комментарии свои вопросы.
