Базы данных *

В предыдущих постах Разбираемся в in-memory базах и Выбираем базу и думаем о данных.

Взлетаем, создал репозиторий под проект https://github.com/mathter/memifydb.git

План

План общий такой:

• Изначально строю некоторый каркас, который буду достраивать и наполнять содержанием. Это будет удобно для прототипирования.

• Для работы с данными создам некоторый дополнительный уровнь абстракции, что бы не привязываться к конкретному формату данных/библиотеке и менять его налету для сравнения.

Сделано

• Данные клиента будут храниться в space’ах - это будет аналог таблиц в БД. Для начала будет только key-value space что бы можно было подумать уже сейчас о WAL клиенской библиотеке для java и сетевом уровне в целом и конечно же о транзакциях.

• Тестовая реализация WAL, которая в проекте будет называться Log.

Run.

Как я запускал российское зеркало для SQL-песочниц: гибридное облако и блокировки Composer

Привет, Хабр! Меня зовут Слава, я развиваю SQL-платформы sqltest.online и sqlize.online для бесплатной тренировки запросов на реальных СУБД (PostgreSQL, Oracle, MariaDB 12.3, MS SQL 2025).

Зачем понадобилось зеркало?

От 30% моей аудитории из РФ стали приходить сообщения: «Сайт открывается только через VPN».

Переносить бэкенд целиком - дорого, сервер завязан на тяжелые СУБД в Docker. Поэтому я выбрал гибридную модель: поднять фронтенд в зоне .ru, оставив бэкенд в Германии.

Архитектура: Фронт в РФ, мозг в Германии

Фронтенд: PHP без фреймворков

Нативный PHP, HTML и JS. Меньше зависимостей - проще деплой. Для RU-зеркала я выбрал SpaceWeb*, где есть отличные бюджетные тарифы и классная поддержка.

sqltest-online.ru (SpaceWeb, РФ)
├── PHP (без фреймворков) + HTML/JS
└── Минимум зависимостей

Бэкенд: Docker Compose

Мощный сервер в Германии у Contabo*, где в контейнерах крутятся MySQL, PostgreSQL, ClickHouse и другие базы. Серьезные СУБД требуют ресурсов, так что всё живет на одной полноценной машине.

Как они общаются?

Пользователь отправляет запрос -> браузер делает AJAX-вызов к .ru серверу -> фронт делает HTTP-запрос к бэкенду в Германии (server-to-server) -> бэкенд выполняет SQL и возвращает результат.

Плюсы схемы:

• CORS не нужен: браузер общается только со своим доменом.

• Бэкенд закрыт: принимает запросы только от white-list IP.

• Задержка минимальна: интерфейс грузится из РФ, тяжелые запросы идут по быстрому каналу серверов.

Резервного бэкенда нет - проект бесплатный, на второй сервер пока нет бюджета. Если падает Германия, ложится всё.

Проблемы деплоя: Composer «ушел в отказ»

С git pull всё прошло гладко, но установка зависимостей зависла намертво.

Проблема: Composer не мог достучаться до packagist.org. Просто бесконечный таймаут, вызванный нестабильностью сетевых маршрутов.

Решение: Поддержка SpaceWeb не стала отписываться «проблема на вашей стороне», а сразу дала адрес HTTP-прокси.

Дело одной команды:

export HTTPS_PROXY=http://proxy.host:port
composer install

(Для Windows: set HTTPS_PROXY=...)

Мораль: При деплое на российские площадки проверяйте доступность packagist.org (curl -v https://packagist.org). Если висит - просите прокси у хостера, не тратьте время на Composer.

Итоги

Зеркало sqltest-online.ru работает. Гибридная схема спасает: пользователи получают быстрый интерфейс без VPN, а запросы улетают на проверенный бэкенд.

Я верю, что образование должно быть доступным. Если для практики SQL нужно включать VPN и ждать по 10 секунд - человек не будет учиться. Зеркало .ru - мой способ сказать: «Продолжайте практиковаться».

А как вы деплоите зависимости на RU-площадки? Используете прокси, зеркала или есть решения изящнее?

* P.S. Ссылки на SpaceWeb и Contabo в статье - реферальные. Сервисами пользуюсь сам и смело рекомендую, а бонусы пойдут на оплату серверов проекта.

Вебинар о том, как обеспечить стабильность баз данных при росте проекта и нагрузок

Самостоятельное администрирование баз данных может превратиться в рутину: постоянные обновления, бэкапы, мониторинг и работа с нагрузкой. С ростом проекта стандартных настроек уже не хватает, а риск просадок и простоев из-за ошибок в конфигурации становится выше.

Это третий вебинар из большого трека про эволюцию приложения в облаке. На этот раз разберем, как передать обслуживание PostgreSQL управляемому сервису в облаке и настроить архитектуру Master/Replica для стабильной работы при высоких нагрузках.

О чем будем говорить:

• сравним управляемую и self-hosted СУБД PostgreSQL: выясним, когда пора задуматься о переезде;

• разберем ключевые метрики БД: на что обращать внимание в мониторинге, чтобы не доводить до инцидента;

• обсудим, как архитектура Master/Replica повышает отказоустойчивость приложения.

После теории будет насыщенное демо, на котором покажем, как добавить в сервис поддержку нескольких реплик и разгрузить базу на чтении. Затем проведем нагрузочное тестирование и сравним показатели до и после оптимизации. Еще покажем, как организовать резервное копирование, разделить трафик на чтение и запись и повысить отказоустойчивость приложения.

Вебинар будет полезен бэкенд-разработчикам, DevOps- и SRE-инженерам, архитекторам и тимлидам, которые отвечают за стабильность базы данных, производительность сервисов и развитие приложения под растущей нагрузкой.

📅 Встречаемся во вторник, 28 апреля, в 11:00 мск

Зарегистрироваться на вебинар

Терабайты данных из Teradata в Trino — эффективный способ передачи

В Data Ocean Nova был добавлен новый Trino Teradata Connector, который упрощает ad hoc-доступ к данным из Teradata и позволяет выгружать терабайты данных без кратного роста нагрузки на источник. Коллеги в новой статье объясняют, почему привычная параллельная выгрузка через несколько запросов плохо масштабируется, и показывают более правильный подход: распределять чтение по AMP’ам Teradata так, чтобы каждый из них читался только один раз.

Авторы разбирают архитектуру Teradata, типичные ошибки при многопоточном извлечении данных и принцип работы федеративного доступа через Trino. Отдельно показывают, как коннектор в Data Ocean Nova помогает организовать эффективную многопоточную передачу данных и использовать push-down для фильтрации, агрегаций и join’ов, когда это действительно уменьшает объем выборки.

Как всегда, в статье много полезных советов. Читайте и комментируйте!

🔌Форматы обмена и хранения данных

В предыдущих постах Разбираемся в in-memory базах и Выбираем базу я написал, что собираюсь сделать исследовательский проект по in-memory базам данных  и имя ему MemifyDB. Так же выбрал направление движения: это key-value хранилище, которое потом доработаю до документо-ориентированной системы.

Теперь ключевой вопрос: как клиенты будут с ней общаться?

Протокол обмена — это мост между сервером и клиентом. От его дизайна зависит скорость, удобство и даже то, какие фичи мы сможем реализовать.

Human readable (JSON, XML and etc.)

В современных системах активно используется как для транспорта так и для хранения текстовый формат данных, а точнее json и его вариации. У этого подхода есть несколько несомненных плюсов, например:

• Простота реализации: не нужно поддерживать разные типы на уровне протокола, всё передаётся как строки, а клиент сам разбирается.

• Гибкость: строкой можно закодировать что угодно — число, JSON, бинарные данные.

Но у этого подхода есть обратная сторона:

• ❌ Нет нативной поддержки типов: Клиент сам должен сериализовать/десериализовать.

• ❌ Оверхед на парсинг: Каждый раз нужно преобразовывать “42” в число и обратно.

• ❌ Неэффективное использование памяти: Число 123456 занимает 6 байт как строка, хотя в бинарном виде — 4 или 8.

• ❌ Невозможность частичного обновления сложных структур: Чтобы изменить одно поле в JSON-объекте, приходится переписывать весь объект (можно конечно поспорить).

## 🎯 Наш подход: типизированные данные с рождения В MemifyDB мы пойдём другим путём.
Мы будем хранить данные в памяти в типизированном виде: строки, числа, списки, хеши, документы — каждый тип со своим внутренним представлением.

И протокол обмена с клиентом должен это отражать.
Мы не хотим, чтобы клиент упаковывал число в строку только потому, что так проще.
Мы хотим передавать по сети те же бинарные структуры, которые лежат в памяти.

Это даст:

1. Типизированность Формат должен явно различать типы данных: строки, числа (разной разрядности), булевы значения, null, массивы, объекты (документы).
   Это позволит серверу правильно интерпретировать данные без дополнительных метаданных.

2. Компактность Формат не должен раздувать данные. Число 42 должно занимать 8 байт (или 4, если это int32), а не 2 символа ASCII.

3. Быстрая навигация Мы должны иметь возможность быстро «прыгнуть» к определённому полю документа без полного парсинга.
   Это важно для частичных обновлений и запросов.

4. Потоковость Формат должен допускать частичную отправку/приём, чтобы можно было обрабатывать большие документы по частям.

5. Самодостаточность Данные должны содержать всю информацию для интерпретации, но при этом не дублировать имена полей без необходимости (как в JSON).

🔍 Что дальше?

Существуют несколько бинарных: CBOR, BSON, FlatBuffer и пр. Если у вас есть опыт работы с этим форматами, пишите в комментариях какие у них есть плюсы, минусы и подводные камни.

🧠 MemifyDB: прежде всего — видение (vision).

Прежде чем погружаться в код, нужно чётко ответить на вопрос: а что именно мы строим?
Этот пост — не про хардкорный кодинг, а про так называемое видение системы (system vision).
Мы разберём, какие вообще бывают in-memory базы данных, чем они отличаются и почему наш путь будет таким: key-value → документная БД.

Поехали!

📚 Типы in-memory баз данных

1. Key-Value хранилища

Самый простой и быстрый вид. Данные хранятся как пары «ключ — значение», где значение — обычно строка, число или бинарный объект.

• Примеры: Redis, Memcached, DragonflyDB.

• Сценарии: кэширование, сессии пользователей, счётчики, очереди задач.

• Плюсы: максимальная скорость, минимальный оверхед, простота масштабирования (шардирование по ключу).

• Минусы: ограниченная модель данных — нет сложных запросов, только операции по ключу.

2. Документо-ориентированные БД

Значение — структурированный документ (JSON, BSON, XML). Внутри документа можно индексировать поля и выполнять запросы по содержимому.

• Примеры: MongoDB (in-memory storage engine), Couchbase.

• Сценарии: хранение сложных объектов (профили, каталоги), где важна гибкость схемы.

• Плюсы: удобство для разработчика, естественное представление данных, возможность частичного обновления.

• Минусы: чуть более высокий оверхед по сравнению с key-value (парсинг, индексация).

3. Колоночные (Columnar) in-memory БД

Данные хранятся не по строкам, а по колонкам. Это даёт огромное преимущество при аналитических запросах (суммы, средние, группировки).

• Примеры: SAP HANA, MemSQL (SingleStore) в колоночном режиме, Apache Arrow (формат, но не БД).

• Сценарии: аналитика реального времени, отчёты, BI.

• Плюсы: сверхбыстрая агрегация, высокая степень сжатия.

• Минусы: медленные точечные обновления (OLTP-нагрузка), сложность реализации.

4. Графовые БД

Хранят сущности (узлы) и связи между ними (рёбра). Оптимизированы для обходов графа.

• Примеры: RedisGraph (модуль Redis), Neo4j (с in-memory режимом).

• Сценарии: социальные сети, рекомендательные системы, сети связей.

• Плюсы: эффективные запросы связей, интуитивная модель для связанных данных.

• Минусы: узкая ниша, сложность шардирования.

5. Time-series БД

Специализированы для временных рядов — метрик, логов, событий. Оптимизированы для записи и запросов по временным интервалам.

• Примеры: InfluxDB, TimescaleDB (in-memory части).

• Сценарии: мониторинг, IoT, финансовые тикеры.

• Плюсы: высокая скорость записи, сжатие старых данных, встроенные функции по времени.

• Минусы: слабо подходят для произвольных данных.

…## 🧭 Наш курс: от Key-Value к документам

Для MemifyDB я выбрал путь, который кажется самым прагматичным:

1. Создаём ядро Key-Value
   Это фундамент. Мы реализуем:

   • потокобезопасное in-memory хранилище;

   • поддержку разных типов значений (строки, списки, хеши, числа);

   • механизмы TTL и эвикшена (LRU);

   • бинарный протокол, близкий к внутреннему представлению.

   Key-value движок даст нам максимальную скорость и стабильность, а также позволит отточить все низкоуровневые механизмы (аллокаторы, сериализацию, сетевое взаимодействие).

2. Надстраиваем документный слой
   Поверх key-value ядра мы добавляем возможность интерпретировать значение как JSON-подобный документ:

   • индексация по полям;

   • поддержка частичного обновления;

   • запросы с фильтрацией по содержимому.

При этом сами документы будут храниться в key-value хранилище как обычные значения, а индексы — как дополнительные структуры (хеш-таблицы, B-деревья) в памяти.

Такая двухслойная архитектура даёт:

• гибкость — можно работать и как с обычным кэшем, и как с документной БД;

• производительность — key-value ядро остаётся быстрым, а документные операции добавляются без потери эффективности;

• расширяемость — позже можно добавить другие модели (например, колоночные агрегаты) как отдельные слои.

Мировой лидер по добыче алмазов АЛРОСА перевел DIrectum RX на СУБД Tantor Postgres, проект занял всего 5 месяцев. При этом бизнес-процессы работали в штатном режиме, сроки не сместились, бюджет не увеличился.

В результате компания получила обновленный ИТ-контур, он обеспечивает безопасность критически важных данных и стабильную производительность корпоративных систем.

23 апреля в 11:00 мск на бесплатном вебинаре эксперты АЛРОСА, «Тантор Лабс», «СТАРКОВ Групп» и Directum поделятся подробностями кейса.

Для участия нужна только регистрация. Встретимся на вебинаре!

🧠 Разбираемся, как устроены in-memory БД: пишем MemifyDB с нуля.

Redis быстр, но не всегда удобен. SAP HANA — мощь, но ценник…
А что, если заглянуть под капот и создать свою enterprise in-memory СУБД?
Не чёрный ящик, а полностью прозрачную, современную, open-source — и при этом готовую к высоким нагрузкам. Разбираемся как это работает!

Знакомьтесь — MemifyDB.

📌 Что это будет?
Настоящая in-memory система уровня enterprise, в которой мы разберёмся до винтика:

• живёт в RAM, отвечает за микросекунды;

• сохраняет данные на диск (RDB + WAL) — никакой потери после ребута;

• реплицируется и шардируется «из коробки»;

• поддерживает транзакции (не хуже MULTI/EXEC, но с возможным rollback);

• и при этом не просит продать почку за лицензию.

Весь код — open source, все решения — с объяснениями.

🛠 Технический фундамент (выбираем стек вместе)
Платформа — JVM. Я сейчас выбираю между Java 21 (Loom) и Scala 3 (ZIO / Akka).

• Сеть: Netty или виртуальные потоки — посмотрим на бенчмарках.

• Память: off-heap + собственный slab-аллокатор на ByteBuffer. GC не мешает, фрагментация под контролем.

• Конкурентность: Lock-Free структуры данных, чтобы не блокировать потоки.

• Протокол: RESP-совместимость — redis-cli сможет общаться с нами.

🗺 Дорожная карта: что и когда разберём

1. Ядро: потокобезопасное KV-хранилище в памяти. Как работают LRU и TTL?

2. Persistence: снапшоты и WAL. Как не потерять данные при краше?

3. Сеть: пишем TCP-сервер. Netty vs Loom — кто быстрее?

4. Транзакции: реализуем MULTI/EXEC, WATCH. Нужен ли MVCC?

5. Репликация и Raft: как достичь консенсуса в распределённой системе?

Каждый этап — открытый код, пост с разбором, грабли и профит.

🤔 Зачем я это делаю публично?
Во‑первых, разобраться самому и дать шанс разобраться другим.
Во‑вторых, фидбек сообщества ловит ошибки на берегу.
В‑третьих, хочется сделать реально полезный инструмент, а не очередной pet‑project.

💬 Вопрос к залу:
Какой стек предпочтительнее для enterprise in‑memory БД — Java 21 + Loom или Scala + ZIO/Akka?
Какие фичи вы бы добавили в дорожную карту?
Пишите в комментариях — лучшие идеи уйдут в реализацию!

👉 Подписывайтесь, чтобы не пропустить:

• глубокий разбор off‑heap аллокатора;

• сравнение моделей конкурентности на реальных бенчмарках;

• историю о том, как одна строка unsafe кода валила прод три дня.

Selectel начисляет до 30 000 бонусов на облачные сервисы

Привет, Хабр! Если вы ИП или юрлицо и ранее не использовали облачные базы данных или Managed Kubernetes в Selectel — можете получите до 30 000 бонусных рублей на тест этих продуктов.

Сервисы позволяют:

✔️ повысить стабильность высоконагруженных сервисов,

✔️ сократить время на релиз новых продуктов,

✔️ уменьшить расходы на IT-инфраструктуру.

Чтобы получить грант, нужно создать тикет от юридического лица или ИП с описанием нужной конфигурации — и мы начислим до 30 000 бонусов на облачные базы данных и Managed Kubernetes в Selectel.

Экосистема с бесшовной интеграцией эффективнее, чем набор разрозненных решений

Елена Будерацкая, лидер функции Data Governance в Дирекции управления данными ОТП Банка, выступила на панельной дискуссии Дата-саммита 2026 «Вся правда о платформе данных: статика или пластичность», где рассказала о внедрении цифровых экосистем. В обсуждении также приняли участие ведущие игроки рынка. Делимся основными мыслями.

1. Бизнес должен исходить из собственных задач при выборе технологий, поскольку новые решения появляются практически ежедневно и нужно четко понимать цель их внедрения. И честно задать вопросы: для чего мне это необходимо и что я хочу получить для моей компании. В текущих реалиях, если компания работает с большими данными и хочет оставаться конкурентоспособной, то без современных платформ уже не обойтись.

«Платформа данных — это не просто программное решение, которое кто-то поставляет и устанавливает. На нее нужно смотреть с точки зрения пользователя и его ожиданий. В первую очередь, ему необходимо, чтобы данные были корректными и находились в одном месте, и было понятно, что это за данные, чтобы на их основе можно было принимать решения и использовать их в других процессах. При этом пользователю хотелось бы, чтобы работать с этими данными было просто и удобно», — поделилась Елена.

2. Однако уже недостаточно внедрить отдельную дорогую технологию. Необходима целостная экосистема, которую невозможно выстроить без культуры работы с данными в компании, data governance, а также четких процессов и фреймворков. При этом не имеет принципиального значения, реализуется ПО внутри компании или с привлечением вендоров.

3. У производителей платформ всегда остаются пробелы, которые компаниям приходится закрывать самостоятельно. Однако сейчас ведущие вендоры разрабатывают не просто отдельные решения, а создают из них экосистему. Такой подход дает лучший результат, поскольку в сочетании с бесшовной интеграцией работает эффективнее, чем набор разрозненных инструментов.

🚨 Мы в Diasoft запускаем свою серию мероприятий по СУБД.
Первое — уже 21 апреля 2026: конференция о промышленной эксплуатации и архитектуре корпоративных данных.

❯ Место проведения — Москва, Кибердом.

Я выступлю с двумя докладами:

🔥 Как мы воспроизводим функциональность MS SQL и переносим решения без переписывания
🔥 Digital Q.CDC — когда критична синхронизация изменений данных.

❯ В нашей программе намечается много интересного, в том числе обсудим:

🔹 как мы воспроизводим функциональность Oracle
🔹 практика импортозамещения и работа с высоконагруженными системами
на базе Digital Q.DataBase
🔹 Low-Code подходы и замещение зарубежных платформ
🔹 единая работа данных для OLTP и OLAP
🔹 развитие инструментов управления СУБД
🔹 как формируется СУБД за счет объединения компетенций и технологий

Наши профессионалы подробно объяснят реальные кейсы и практику внедрения.

Обязательно регистрируйтесь

https://dbd.diasoft.ru/?utm_source=andrei#programme

Увидимся! 🚀

📎 Полезные ссылки 
🔹 Бесплатное получение дистрибутива: https://database.diasoft.ru/?utm_source=andrei
🔹 Документация: доступна внутри дистрибутива 
🔹 Telegram-сообщество Digital Q.DataBase: https://t.me/dqdatabase
🔹 Канал в MAX: https://max.ru/join/orlthIssLJbjj37mjlEEYARWFyuJk5yMixLlGPISIzc

Управляемые базы данных и почему это тоже про машинное обучение — расскажем на GoCloud 2026 ☁️

Покажем, почему ML-системы начинаются не с моделей, а с дата-инфраструктуры. Разберем роль PostgreSQL, Kafka, Redis, ClickHouse и OpenSearch в реальных сценариях машинного обучения клиентов. Обсудим, как управляемые дата-сервисы становятся фундаментом ИИ-нагрузок, и какие продуктовые требования меняются — превращая дата-платформу в IaaS-слой для машинного обучения.

Спикер: Сергей Геворкян — менеджер продукта, Cloud.ru

Трек: Данные и аналитика

📅 Когда: 9 апреля в 15:35–16:05 мск
👉 Зарегистрироваться

А пока ждете выступление, загляните в блог: Как мы разгрузили базу данных в проде и не сломали систему

Как компании будут управлять данными дальше

Привет, Хабр! В этом посте расскажем про ключевые тренды Data Governance на 2026 год на основе исследований Gartner, McKinsey, Deloitte, EY и отраслевой аналитики. А также расскажем, как меняется роль Data Governance в банках и крупных компаниях, почему управление данными становится частью управленческой модели и какие фокусы уже закладывают в стратегии на ближайшие годы.

Data Governance становится «невидимой инфраструктурой»

DG перестаёт быть отдельной инициативой К 2026 году Data Governance всё реже существует в формате отдельного проекта или программы. По данным Gartner, более 70% крупных организаций встраивают DG не как функцию, а как часть операционной модели: риск-менеджмента, комплаенса, управления продуктами, аналитики и AI.

Усиление персональной ответственности

Роль Data Owner становится критической. К 2026 году роль Data Owner окончательно перестаёт быть формальной. По данным BCG, компании: с чётко закреплённой ответственностью за данные и вовлечёнными бизнес-владельцами принимают решения быстрее на 30–40% и реже сталкиваются с регуляторными замечаниями.

От «Качества данных» к «Качеству решений»

Фокус смещается с данных на результат. В 2026 году компании будут оценивать Data Governance не по наличию каталогов и политик, а по тому, как данные влияют на управленческие решения. Исследование McKinsey показывает: организации, которые связывают DG с бизнес-метриками, повышают эффективность решений на 20–25%. Ключевой сдвиг: Вопрос «данные корректны?» меняется на вопрос «можно ли на основе этих данных принимать решения?»

Data Governance — это не «про документы», а про деньги и эффективность.

Регуляторы переходят к проверке «по сути»

Формальные политики больше не работают. Отчёты Deloitte и EY показывают общий тренд, что регуляторы в 2026 году будут оценивать: реальные процессы владения данными, сквозную трассируемость, связь данных с отчётностью и решениями.

Источники и исследования, на которые мы опирались:

• Gartner-аналитика и прогнозы Gartner Predicts 80% of Data & Analytics Governance Initiatives Will Fail by 2027

• Gartner: Internal Auditors to Focus on Data Governance and Regulatory Compliance in 2026

• Gartner Identifies the Top Strategic Technology Trends for 2026

• 2026 Strategic Roadmap for Data and Analytics Governance

• Отраслевые тренды и практики Forbes: The 8 Data Trends That Will Define 2026 () Dataversity: Data Management Trends in 2026

• Murdio: Top Data Governance Trends — The Future of Data in 2026

• Статистика и экономика данных Data Governance Statistics & Market Data

🔹 Всем привет. Сегодня хочу рассказать Вам о том, как мы склонировали у себя один из самых "прикладных" сервисов из поставки Microsoft SQL Server.

➡️ Речь пойдет об SQL Server Reporting Services (SSRS) - механизме, который позволяет получать разнообразные отчеты, запрашивая их построение по API или по расписанию.

➡️ Представьте ситуацию: Вы использовали Microsoft SQL Server и у Вас было несколько сотен разнообразных отчетов, что ранее строились на основе данных в Ваших БД. И тут импортозамещение! Надо переходить на российское решение из Реестра Минцифры.
Для замены СУБД самый легкий вариант такого перехода - Digital Q.DataBase. Мастер переноса БД поможет перенести данные, Мастер сравнения БД проверит корректность переноса, Digital Q.CDC обеспечит синхронизацию данных в обеих СУБД, что позволит сократить до нескольких минут сам момент перехода.
Но что делать с сотнями отчётов, что привыкли получать Ваши пользователи?

Оставить как есть, пусть строятся при помощи зарубежного инструмента?
Вряд-ли это приемлемо. Какое-то очень кусочное импортозамещение получается!

Переписать на другом инструменте? Даже из расчета по дню на отчёт это сотни человеко-дней "ручного труда", а потом тестирование, выгребание ошибок, восстановление порушенных интеграций (построение некоторых отчетов могло запрашиваться извне, через API). Тоже так себе вариант!

➡️ Мы предлагаем более живую альтернативу: воспользоваться нашей реинкарнацией службы отчетов. 

На приложенных скриншотах два отчёта. Один построен в оригинальном инструменте, второй у нас. Как видите, они очень похожи, более того построены по одному и тому же шаблону, что был перенесен из оригинала к нам при замене СУБД.

Внешний вид и API - все сохранено. Как говорят наши "заокеанские партнеры" - настоящий "drop-in replacement" (безшовная замена одного инструмента другим).
Именно так и должно выглядеть хорошо проработанное импортозамещение.

Благодарю за внимание к этому посту!

📎 Полезные ссылки
🔹 Бесплатное получение дистрибутива: https://database.diasoft.ru/?utm_source=andrei
🔹 Документация: доступна внутри дистрибутива
🔹 Telegram-сообщество Digital Q.DataBase: https://t.me/dqdatabase
🔹 Канал в MAX: https://max.ru/join/orlthIssLJbjj37mjlEEYARWFyuJk5yMixLlGPISIzc

Автоматизируем жизненный цикл баз данных: вебинар про DBaaS в Deckhouse

Database as a Service — подход, в котором базами данных управляют как платформенным сервисом: с автоматизацией и предсказуемым жизненным циклом. Вместо ручного администрирования каждой БД по отдельности — единый процесс от создания и развёртывания до обновлений и оптимизации.

Мы реализовали этот подход в Deckhouse Kubernetes Platform. На вебинаре 3 апреля покажем, как он работает, и расскажем:

• что Cloud Native-подход меняет в управлении сервисами данных;

• как устроен DBaaS в Deckhouse: жизненный цикл БД и платформенные модули;

• как реализовать облачные принципы управления БД в закрытом контуре.

Регистрируйтесь и подключайтесь 3 апреля в 12:00 по Москве, если используете БД или хотите применить DBaaS-подход в своей инфраструктуре.

Друзья, Digital Q.DataBase позволяет Вам не только сохранить прикладную логику СУБД Microsoft и Oracle.

🔹 В связке с другим нашим продуктом, предназначенным для замены SAP NetWeaver, Вы получаете возможность уйти от использования продуктов SAP без переписывания систем и без переписывания бизнес-логики.

Что это означает на практике:

🔹 ABAP-приложения продолжают работать на новой платформе
🔹 Данные и обработка переносятся в Digital Q.DataBase
🔹 Вся бизнес-логика сохраняется без изменений
🔹 Формируется импортонезависимый стек из отечественного ПО

🔹 В этом видео: 

ABAP-код → сохранение → активация → преобразование в C++ → компиляция → установка на сервер → запуск

📎 Полезные ссылки
🔹 Отдельный лендинг по замене SAP: renovation.diasoft.ru
🔹 Бесплатное получение СУБД дистрибутива: database.diasoft.ru
🔹 Документация: доступна внутри дистрибутива
🔹 Telegram-сообщество Digital Q.DataBase: t.me/dqdatabase

Что будет на конференции GoCloud 2026: трек «Данные и аналитика»

GoCloud — ежегодная конференция Cloud.ru про ИИ и облака. В этом году она пройдет в кинотеатре «КАРО 11 Октябрь» на Новом Арбате в Москве. Формат смешанный — можно прийти офлайн или подключиться удаленно. Выступят больше 40 экспертов. Вас ждут 15 демозон, практические сессии, тематические круглые столы и, конечно, вечеринка после.

Один из треков будет посвящен данным и аналитике — разберем, какие инструменты позволяют сделать управление данными эффективным и не переплачивать, также расскажем, куда движутся тренды в 2026 году. Вот что запланировано:

• Evolution Data Platform: эволюция платформы данных — куда движется дата-платформа Cloud.ru и что изменилось за год.

• Как обрабатывать потоковые данные с помощью Evolution Managed Flink — архитектура, компоненты, сценарии использования.

• Evolution Managed ArenadataDB в облаке: что изменилось с момента запуска — обновления, анонсы новых функций и клиентский кейс.

• Управляемые базы данных и почему это тоже про машинное обучение — почему все начинается не с моделей, а с инфраструктуры для работы с данными.

• Управление Evolution Managed Spark с AI: инновации и эффективность — как ИИ помогает оптимизировать Spark-задачи.

Завершит трек круглый стол «Тренды развития дата-сервисов в 2026 году» — про дата-стратегию, суверенные облака, управление данными и как дата-инженерия становится основой для ИИ в реальных проектах.

​Встречаемся уже 9 апреля, успейте зарегистрироваться на сайте. 

🔹 Стоит ещё раз подчеркнуть важную мысль: переход на российскую СУБД не обязательно означает полное переписывание системы.

До сих пор многие не воспринимают это как реальную возможность.
Крупные системы на Oracle или Microsoft можно переводить иначе. Без многолетней переработки всего кода. Достаточно перенести данные и изменить настройки.

При этом важно понимать условие: такой подход работает, если выбранная СУБД изначально к этому подготовлена. В ней должны быть реализованы необходимые доработки для совместимости, включая клонирование функциональности систем Microsoft и Oracle.

Традиционный путь — это огромные команды разработчиков, длительная проверка корректности переписанного кода, принятие сложных архитектурных решений. Более того, в процессе такого переписывания зачастую приходится менять саму архитектуру системы и фактически перестраивать её заново.

🔹 Мы предлагаем другой подход. В нашем подходе меняется само представление о миграции: не обязательно адаптировать приложение под PostgreSQL. Можно пойти другим путём, реализовать в СУБД функциональность, совместимую с зарубежными системами.

🔹 Если бы такой подход начали применять раньше, страна могла бы сэкономить колоссальные ресурсы.

Речь идёт о миллиардах рублей, которые уже ушли и продолжают сегодня уходить на переписывание систем.

📎 Полезные ссылки
🔹 Бесплатное получение дистрибутива: database.diasoft.ru
🔹 Документация: доступна внутри дистрибутива
🔹 Telegram-сообщество Digital Q.DataBase: t.me/dqdatabase

Как Купер перенес 40 ТБ аналитических данных в облако без остановки процессов

🛒 Что за компания

Купер — сервис доставки из магазинов и ресторанов, работающий в 360 городах России. Аналитическая инфраструктура компании обрабатывает данные для управленческой отчетности и ситуативной аналитики — как внутренней, так и для внешних партнеров.

⚡ Задача

С ростом объемов данных старое решение перестало справляться. Нужно было:

• найти управляемую СУБД в облаке аналогичную Greenplum по функциям, с поддержкой подключения к внешним источникам;

• провести нагрузочное тестирование на реальных OLAP-запросах до миграции;

• перенести 40 ТБ бизнес-критичных данных вместе с контуром разработки, не останавливая аналитические процессы.

☁️ Что сделали

Провайдер предложил Evolution Managed ArenadataDB — управляемую СУБД на базе Greenplum с открытым исходным кодом. Команда во время пилота:

• развернула отказоустойчивый кластер и настроила процесс миграции;

• подключила PXF-коннекторы к внешним источникам данных;

• установила нестандартные JDBC-драйверы и оптимизировала использование памяти для крупных запросов;

• настроила автоочистку и автоанализ — механизмы автоматического обслуживания СУБД для устойчивой работы под нагрузкой.

🦾 Что получили в итоге

40 ТБ данных и тестовый контур перенесены без остановки процессов. Инфраструктура работает оперативно: данные за вчера доступны уже на следующий день. Выросла скорость выполнения запросов, появилась гибкость масштабирования и прозрачность мониторинга.

В планах — оптимизация резервного копирования, архивация данных и бесшовная интеграция инструментов ИИ и машинного обучения.

Все детали кейса — на сайте Cloud.ru

Неудобные вопросы про бэкап PostgreSQL: открытый разбор на вебинаре

Вокруг бэкапа PostgreSQL легко создать иллюзию, что все уже решено. Достаточно добавить в текст WAL, PITR, пару слов про консистентность и назвать агент «умным». Проблема в том, что в проде такие формулировки мало что гарантируют.

Можно ли вообще считать решение PostgreSQL-aware, если оно не живет внутри логики самой СУБД? Где проходит граница между нативными механизмами PostgreSQL и внешней платформой? Что происходит, если не доехал WAL-сегмент, не завершился post-script или восстанавливать нужно не весь инстанс, а один объект?

Из таких вопросов и вырос отдельный вебинар про PostgreSQL в Акуре, в формате открытого инженерного разбора: что здесь должна делать сама СУБД, что имеет смысл выносить во внешний слой, где начинаются реальные эксплуатационные проблемы и какие ограничения в таком подходе нельзя замалчивать.

План такой:

• отдельно пройтись по WAL, PITR и консистентности;

• обсудить, где файловый агент уместен, а где уже нет;

• разобрать сценарии с ошибками pre/post-скриптов;

• поговорить про восстановление в безопасную локацию и ручной recovery;

• отдельно затронуть вопрос масштаба: почему на двух базах хватает shell-скриптов, а на пятидесяти уже начинается совсем другая жизнь.

26 марта 2026, 11:00 (МСК) Регистрация по ссылке. Приносите в комментарии вопросы, которые особенно хочется поднять в эфире.