Привет, Хабр! Меня зовут Слава, я развиваю 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 в статье - реферальные. Сервисами пользуюсь сам и смело рекомендую, а бонусы пойдут на оплату серверов проекта.

🚨 Мы в 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

🔹 Всем привет. Сегодня хочу рассказать Вам о том, как мы склонировали у себя один из самых "прикладных" сервисов из поставки 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

Рег.облако обновил сервис управляемых баз данных. Теперь для PostgreSQL и MySQL хранится семь ежедневных резервных копий — все видны в личном кабинете, восстановление запускается самостоятельно и разворачивается в новый кластер с параметрами на момент бэкапа. Исходный кластер при этом продолжает работать, так что можно спокойно проверить восстановленные данные перед переключением. Для PostgreSQL дополнительно доступен Point-in-Time Recovery — восстановление состояния базы максимально близко к моменту сбоя. В итоге пользователи быстрее восстанавливают данные, спокойнее переживают сбои и гибче управляют своей инфраструктурой.

Параллельно подключили вторую московскую локацию — дата-центр в Медведково. Функциональность и тарифы в Москве-1 и Москве-2 одинаковые, но появляется выбор: распределить нагрузку между ЦОДами, выполнить требования по локализации данных и повысить отказоустойчивость инфраструктуры.

Подробности — на сайте Рег.облака.

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

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

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

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

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

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

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

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

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

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

Зачем это нужно аналитику и как вписывается в архитектуру, я описал в своем Telegram-канале Selena (powered by StarRocks). Здесь — технические детали и результаты тестирования.

На схеме два потока данных между языковой моделью и базой данных:

Синий (вверху) — LLM → База через MCP (4.0). Пользователь задаёт вопрос на обычном языке. Агент сам формулирует SQL-запрос, отправляет его в StarRocks через MCP-протокол и возвращает ответ. Об этом я также подробно писал в нашем сообществе.

Зелёный (внизу) — База → LLM через ai_query() (4.1). Аналитик пишет SELECT с вызовом ai_query(). StarRocks на каждом сервере кластера отправляет запрос к языковой модели и возвращает её ответ как обычную текстовую колонку.

В версии 4.0 появилось первое направление, в 4.1 — второе. Полный цикл.

Что такое ai_query()

Функция принимает два аргумента: текстовый промпт и JSON с параметрами модели. Возвращает текстовую колонку — результат можно фильтровать, группировать и соединять с другими таблицами.

Обязательные параметры: model (название модели) и api_key (ключ доступа). Дополнительно можно указать адрес сервера модели, температуру, максимальную длину ответа и таймаут.

Функция работает с любым сервисом, совместимым с протоколом OpenAI: это и сам OpenAI, и локальные модели через Ollama, и DeepSeek, и vLLM.

Как тестировали:

Функция планируется к релизу в версии 4.1. Когда пришло время её проверить, привычный способ — развернуть готовый образ в Docker — не сработал. В образе обнаружился небольшой баг: функция была скомпилирована и лежала внутри сервера, но сервер о ней не знал. Исправление заняло одну строку в исходном коде. Но чтобы её применить, пришлось собирать BE из исходников.

Среда тестирования: виртуальная машина (8 CPU, 32 ГБ RAM), StarRocks 4.1.0-rc01 (собранный из исходников), языковая модель Ollama gemma3:1b (работает локально на процессоре). Тестовые данные — шесть отзывов о товарах.

Тест 1. Анализ тональности

Задача: определить, позитивный отзыв или негативный.

(SQL код по каждому тестированию я напишу в комментариях)

Вывод: четыре из шести точных.

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

Время: ~три секунды на шесть строк.

Не тот объем данных, чтобы экстраполировать на большие продакшн системы, но я тестировал не производительность, а работоспособность.

Тест 2. Суммаризация

Задача: сжать отзыв в одно предложение.
Вывод: адекватные резюме на русском языке. Длину ответа стоит контролировать параметром max_tokens.
Время: ~одна секунда на строку.

Тест 3. Извлечение характеристик

Задача: вытащить из текста ключевые свойства товара.
Вывод: характеристики извлекаются
Время: ~1 секунда на строку.

Тест 4. Классификация

Задача: определить категорию товара по тексту отзыва.
Вывод: категории определены верно. MacBook, монитор, наушники — «Электроника», мышь — «Периферия».
Время: ~0.5 секунды на строку.

Тест 5. Перевод

Задача: перевести отзыв с русского на английский.
Вывод: качественный перевод даже на модели в один миллиард параметров.
Время: ~1 секунда на строку.

Ограничения:

1. Нельзя задать роль модели (нет системного промпта) — только сообщение от пользователя

2. Нет повторных попыток при ошибке — если сервис модели вернул ошибку, это сразу ошибка SQL-запроса

3. Кеш хранится на каждом сервере отдельно и теряется при перезапуске

Итого:

ai_query() — простая обёртка над протоколом языковых моделей с кешем и дедупликацией. Не революция, но именно такие простые интеграции оказываются самыми полезными.

Функция появится в StarRocks 4.1.

В документации StarRocks появились release notes для 4.1 с пометкой RC (release candidate) — это предварительная версия перед финальным релизом. Посмотреть, куда движется проект, самое время. Я изучил release notes, связанные issues и PR, и выбрал четыре самых значимых изменения.

Ссылка на описание релиза: https://docs.starrocks.io/releasenotes/release-4.1/

Актуальные версии на сегодня: Stable — 3.5.14, Latest — 4.0.6.

1. Автоматическое управление распределением данных

Раньше при создании таблицы в shared-data кластере нужно было вручную выбирать ключ распределения и рассчитывать количество бакетов. Если ошибся — часть узлов перегружена, а часть простаивает, и исправление требует пересоздания таблицы.

В 4.1 для shared-data кластеров появляется range-based распределение: таблеты содержат метаданные диапазонов ключей, и система сама следит за их размером — автоматически разделяет слишком большие или объединяет недоиспользуемые. Без изменения схемы и без перезагрузки данных.

На практике: меньше ручной настройки при создании таблиц, меньше проблем с неравномерной нагрузкой. Issue #64986 (https://github.com/StarRocks/starrocks/issues/64986)

2. DELETE для Iceberg-таблиц

До 4.1 StarRocks мог только читать данные из Iceberg и добавлять новые (INSERT). Удалять было нельзя. А это серьёзное ограничение: удаление персональных данных по требованиям регуляторов, исправление ошибочных записей, очистка устаревших данных — всё приходилось делать через Spark или Trino.

Теперь DELETE FROM (механизм Iceberg position delete) работает напрямую из StarRocks. При этом delete-файлы совместимы с другими движками — Spark, Trino и Flink корректно их прочитают. StarRocks становится ещё более полноценным SQL-движком для Iceberg: SELECT + INSERT + DELETE. Issue #66944 (https://github.com/StarRocks/starrocks/issues/66944)

3. Рекурсивные CTE (WITH RECURSIVE)

Одна из самых запрашиваемых фич — сообщество просило с 2023 года. Рекурсивные CTE позволяют писать запросы, которые ссылаются сами на себя — это нужно для обхода иерархий (оргструктуры, категории товаров, вложенные комментарии), заполнения пропусков во временных рядах и графовых задач. Если вы мигрируете с PostgreSQL, MySQL или Trino — больше не нужно переписывать рекурсивные запросы. PR #65932 (https://github.com/StarRocks/starrocks/pull/65932)

4. Инкрементальное обновление Materialized Views на Iceberg

До 4.1 materialized views на Iceberg-таблицах обновлялись полным пересчётом — даже если в источнике добавилось несколько строк. Теперь StarRocks умеет обновлять MV инкрементально — обрабатывается только новая порция данных. Особенно заметно на append-heavy сценариях: логи, события, IoT-данные. Ограничение первой версии — работает только с таблицами, в которые данные добавляются, но не обновляются. Issue #61789 (https://github.com/StarRocks/starrocks/issues/61789)

Что ещё интересного: 

• Полнотекстовый поиск в shared-data кластерах (inverted index, beta)

• Таблеты до 100 ГБ

• Меньше мелких файлов, проще эксплуатация

• Поддержка Iceberg V3 и тип VARIANT для полуструктурированных данных

• ai_query()

• вызов LLM-моделей прямо из SQL-запроса

• sum_map() — нативная агрегация MAP по ключам

• Мониторинг потоков FE через SQL без внешних инструментов

Больше постов про StarRocks и Lakehouse — в Telegram-канале @starrocks_selena

OAuth на практике: что оказалось удобным, а что отпугнуло пользователей

Мы запустили молодую платформу с двумя типами аккаунтов: обычные пользователи и разработчики (публикуют PWA и управляют приложениями).

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

С чего начали

Для обычных пользователей:
• Email / пароль
• Google
• GitHub

Для разработчиков — жёстче:
• Обязательная привязка Google
• Обязательная привязка GitHub

Логика казалась разумной:
«Разработчик = есть GitHub»
«Двойная верификация = меньше спама»

На практике это не сработало.

Первые тревожные сигналы

Регистрация разработчиков шла крайне медленно, несмотря на интерес к публикации приложений.

Сначала списывали на:
• новый продукт
• низкое доверие
• отсутствие аудитории

Но после общения с разработчиками (в том числе через Habr) картина прояснилась.

Что отпугивало разработчиков

1. Новый сервис → нежелание делиться данными

Даже если это «просто email», психологический барьер остаётся.

Когда с первого шага нужно:
• линковать внешние аккаунты
• проходить несколько этапов подтверждения
• подключать сторонние сервисы

это воспринимается как лишний фрикцион.

Особенно для соло-разработчиков и небольших команд.

2. Git ≠ GitHub

Ключевой инсайт.

Мы обнаружили, что:
• не все хотят логиниться через GitHub
• часть использует GitLab или Bitbucket
• некоторые принципиально не хотят связывать GitHub с новым сервисом

Обязательная привязка GitHub стала серьёзным барьером.

А мнение стандартных пользователей разделилось:

Часть говорила:

«Чем больше OAuth-кнопок, тем солиднее выглядит платформа».

Логика простая:
• если есть Google / Facebook / Discord — значит не ноунейм
• интеграции с крупными сервисами повышают доверие

Это не про безопасность — это про ощущение легитимности.

Другие говорили ровно противоположное:

«Слишком много кнопок — ощущение перегруженности».

И это тоже справедливый аргумент.

Что мы изменили

1. Упростили форму для пользователей

Оставили:
• Google
• Facebook
• Discord

Достаточно выбора для доверия, без визуального шума.

2. Git-провайдеры вынесли в отдельную группу

Под отдельной кнопкой:
• GitHub
• GitLab
• Bitbucket

Для разработчиков это стало понятнее и логичнее.

3. Убрали обязательный GitHub

Теперь для developer-аккаунта нужно подключить любой Git-аккаунт, если ни один не подключён.

Без принудительного GitHub.

Первые цифры (осторожно)

Прошла всего неделя, выборка маленькая, платформа всё ещё молодая.

Тем не менее:
• Зарегистрированные пользователи: +13%
(было 0–6% в неделю)
• Зарегистрированные разработчики: +16%
(было 0–3%)

Похоже, это те разработчики, которые знали о платформе, но их останавливало требование GitHub.

Выводы (пока не финальные)
• OAuth — это не только безопасность, но и психология доверия
• Жёсткие требования на старте почти всегда бьют по росту
• Git ≠ GitHub — и это важно
• Много провайдеров могут как повышать доверие, так и перегружать UI

Для молодой платформы даже такие ранние сигналы уже показательны.

Интересно услышать опыт коллег:
добавляли ли вы OAuth-провайдеров после запуска?
были ли случаи, когда обязательная авторизация через конкретный сервис тормозила рост?

Меня зовут Жуйков Андрей, и если будет время - буду рад, если посмотрите запись 👀

«Импортозамещение СУБД по-новому: интеллектуальный подход к замене MS SQL и Oracle»

🔹 Установка и первый запуск Digital Q.DataBase
• развёртывание Digital Q.DataBase в Docker-контейнере
• установка и настройка Digital Q.DataBase на Ubuntu 24.04
• архитектура, ключевые преимущества и типовые сценарии использования в российских компаниях

🔹 Новые возможности Digital Q.DataBase для импортозамещения
• инструменты, упрощающие миграцию с MS SQL и Oracle
• как сократить риски и сроки перехода без переписывания приложений

🔹 Практика внедрения и реальные кейсы
• Владимир Авсеев показал, как система «Босс-Кадровик», изначально заточенная под MS SQL, успешно работает на Digital Q.DataBase
• Анастасия Коршунова (отдел разработки) продемонстрировала примеры успешной интеграции Digital Q.DataBase с 1С и Delphi-приложениями

🔹 Ответы на вопросы
• практические нюансы миграции и эксплуатации
• ответы на вопросы из реальных проектов от разработчиков Digital Q.DataBase и команды «Босс-Кадровик»

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

📘 Часть 1. Теория и философия Digital Q.DataBase 
Разбираем фундаментальные вопросы: 
• Как Digital Q.DataBase объединяет три SQL-диалекта
(T-SQL, PL/SQL, PL/pgSQL) в одном ядре? 
• Как продукт обеспечивает простоту и высокую скорость миграции? 
• Что входит в базовый состав коробочной версии? 

🛠 Часть 2. Практика: установка и работа с диалектами 
• скачиваем и устанавливаем Digital Q.DataBase, 
• получаем документацию, 
• выполняем практику по SQL-диалектам на демостендах. 

Да, это тот самый момент, когда теория превращается в конкретику - и вы сами видите, как работает гибридная архитектура продукта. 

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

Вчера мне посчастливилось побывать на MariaDB Meetup с участием самого Майкла «Монти» Видениуса в Тель-Авиве. Это событие стало не только ценной возможностью услышать о стратегических и технических планах развития MariaDB, но и позволило укрепить партнерские связи между проектом и нашей образовательной платформой.

Делюсь ключевыми тезисами и анонсами с митапа, которые будут интересны всем, кто работает с базами данных и Open Source.

1. Стратегический вектор: Open Source и миграция с Oracle

Майкл Видениус в своем докладе однозначно обозначил стратегию MariaDB: курс на безоговорочную победу открытого кода над проприетарными гигантами. Основной акцент был сделан на преимуществах миграции с Oracle на MariaDB.

Преимущества и миграция:

• Экономическая эффективность: Монти открыто говорил о несопоставимой стоимости использования и владения MariaDB по сравнению с Oracle, что является критическим фактором для многих корпоративных пользователей.

• Совместимость синтаксиса: MariaDB активно развивает режим совместимости с Oracle (Oracle Compatibility Mode), который значительно упрощает процесс перехода, позволяя использовать привычный синтаксис SQL. Это резко снижает затраты времени и ресурсов на переписывание существующего кода.

• Производительность MariaDB 11.8: Были продемонстрированы тесты, подтверждающие рост производительности более чем в 2,5 раза по сравнению с предыдущими версиями за счет архитектурных улучшений.

2. MariaDB, AI и Векторные базы данных

Сергей Голубчик представил глубокий технический обзор поддержки векторного типа данных в последних версиях MariaDB. Это важнейший шаг, который ставит MariaDB в один ряд с современными решениями, адаптированными для задач искусственного интеллекта.

• Векторный тип данных (Векторная БД): Встроенная поддержка векторов позволяет использовать MariaDB как полноценную векторную базу данных, что критически важно для работы с embeddings, семантическим поиском и RAG-системами (Retrieval-Augmented Generation).

• Производительность и точность (Tradeoff): Сергей Голубчик подробно остановился на ключевом вопросе производительности векторных операций и компромиссе между скоростью поиска и точностью (performance vs. precision of search). Он продемонстрировал, как тонкая настройка конфигурации и индексов (например, использование HNSW-индексов) позволяет добиться наилучшего баланса, обеспечивая высокую скорость без существенной потери точности результатов.

3. Видение будущего и сотрудничество

Анна Видениус (CEO MariaDB Foundation) представила стратегический обзор развития проекта, подчеркнув фокус на стабильности, высокой производительности и укреплении позиции MariaDB в корпоративном сегменте.

🤝 Новые горизонты: Планы сотрудничества с sqlize.online

Самой продуктивной частью митапа стало личное общение с Майклом и Анной Видениус, которое вылилось в конкретные договоренности:

1. Расширение поддержки версий: Платформа sqlize.online расширит поддержку MariaDB до трех актуальных версий, включая последнюю — MariaDB 11.8 — с акцентом на тестирование ее векторных возможностей.

2. Новый учебный контент: На sqltest.online будет запущен новый набор практических заданий, разработанных совместно с командой MariaDB, для глубокого освоения последних функций и особенностей этой СУБД.

Это сотрудничество поможет ускорить процесс обучения и внедрения инноваций MariaDB среди разработчиков и аналитиков.

❓ Дискуссия: Готовы ли вы использовать векторы в MariaDB?

MariaDB смело интегрирует технологии будущего, делая ставку на миграцию и ИИ.

Уважаемые читатели Хабра, вопрос к вам:

Как вы относитесь к появлению нативной поддержки векторного типа данных в MariaDB? Готовы ли вы использовать эту функцию в своих новых проектах и рассматривать MariaDB как альтернативу специализированным векторным базам данных?

Делитесь мнениями в комментариях!

Если вы ищете надёжный движок для сайта, защищённую CMS или систему управления с повышенной безопасностью, HyperFlow 1.2 — это решение, которому можно доверять.

https://hyper-flow.ru/news/info/hyperflow-12-novaya-versiya-bezopasnogo-dvizhka-saytov

Когда люди слышат «QA-инженер», они обычно думают: «А, это тот человек, который нажимает все кнопки подряд и заносит баг-репорты в Jira». Ха-ха, мимо.

Всем привет! Я Настя, QA-инженер в «Финаме». Мой путь в тестировании начался с эксплуатации торгово-клиринговой системы «СПБ Биржи», а последние несколько лет я тестирую бэк-офисные и торговые системы. И за это время я убедилась: QA в финансовой компании — это отдельная вселенная.

Сегодня я хочу поделиться чек-листом навыков выживания и развития, которые просто необходимы любому QA в финтехе, — три кота, на которых всё держится.

Кот Смыслюня — с умным видом объясняет, что лимитка не равно рыночка, и спокойно может мурлыкать лекцию про хеджирование в три часа ночи.

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

Поэтому знание предметной области — основа QA в финансовой сфере. Здесь важно понимать терминологию, специфику работы и все бизнес-процессы: как проходят сделки, что такое дисконтирование, и почему неправильный расчет одного показателя может стать причиной ошибки на миллионы. Я пришла в IT из финансов, работала с брокерами и депозитариями, поэтому мне было немного проще.

Как прокачать предметку? Изучите бизнес-процессы. Разберите базовые термины. И не ленитесь изучать теорию финансов, а не только учебники по Java и Python.

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

Без знания SQL вы потеряетесь в финансовом секторе. Тут лучше иметь продвинутые SQL-навыки, например:

• агрегаты (COUNT, SUM, AVG) — быстро сворачивают кучу данных в удобный формат;

• временные таблицы — магический инструмент. Данные не лежат «готовыми», их нужно поймать, сохранить и присоединить к основной таблице;

• JOIN’ы — мостики между таблицами. Без них ваши данные просто стоят отдельно, как несогласованные депозиты на разных счетах;

• типы данных и кастинг — часто разные источники хранят одно и то же по-разному. Не забудьте привести к одному виду.

И не храните текст — ID гораздо быстрее. Умение работать с SQL в финтехе — не просто навык, а мастхэв для QA: чем лучше владеете этим языком, тем увереннее двигаетесь в мире цифр и транзакций.

Кот Скриптик — ленивый, но гениальный: «Зачем делать руками, если я могу запустить автотесты и спать дальше?» Избавляет QA от рутины, оставляя время на умные проверки и кофе.

Без автотестов в финтехе никуда, слишком много данных и проверок. Для меня топ — Python, идеален для тестирования SQL-запросов. Конечно, можно и на других языках, всё зависит от задач. Но если только начинаете, Python, простой и с кучей бесплатных курсов, будет вашим спасательным кругом. Я, кстати, стартовала на «Питонтьюторе» — и ничего, выжила!

Пара фишек: 

• pytest — швейцарский нож для автотестов. Параметризация позволяет запускать кучу тестов с разными данными, не плодя сотни копий кода; 

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

Мой главный совет — выбирайте одну-две рутинные проверки и автоматизируйте их хотя бы по одной в неделю. Через месяц вы не только прокачаете свои навыки, но и покрытие тестами вырастет, и ваша жизнь станет на порядок проще.

Что мы поняли из истории про трех котов? Предметка рулит. Для работы в финтехе нужно знать термины, процессы и специфику инструментов. SQL — ваш супергерой. Без него вы потеряетесь в горах таблиц и хранимок. Автотесты спасают ваши нервы и время. Даже пара тестов в неделю увеличит покрытие и прокачает навыки.

В следующих постах мы с коллегами расскажем больше о работе в финтехе. До скорых встреч!

Если вы изучаете базы данных или давно не работали с ними и хотите проверить знания, приглашаем пройти наш новый квиз. Ответьте на несколько теоретических вопросов и попробуйте расшифровать SQL-запросы — в конце получите промокод на 1000 бонусов в панели Selectel.

Пройти квиз

Не забудьте поделиться результатами в комментариях!

В продакшене миграции могут идти только вперед. Какого? Откат миграции во время ролбека (при неудачном деплое) во-первых сильно усложняет всю процедуру, во-вторых, в теории, может ее некисло замедлить, уже не говоря про потенциальные локи на время отката. На фоне этого возможны ошибки, которые приведут всю систему в неконсистентное состояние.

Ролбек, в идеале, это просто переключение с одной версии кода на другую. Но ведь тогда возможны ошибки связанные с изменениями в базе? Если делать через жопу, то возможны. При правильном подходе, база всегда обратно совместима как минимум на одну версию. Только в этом случае мы можем обеспечить и бесшовный деплой (zero downtime deploy) и практически моментальный откат.

А это значит, что нельзя менять тип у колонок (если тип сужается), нельзя менять именования таблиц и полей. Если это все таки нужно, то существует немало техник, позволяющих сделать переход через создание новых сущностей и синхронизацией либо через код либо через саму базу (например с помощью триггеров). По этой теме даже написали целую книгу "Refactoring Databases: Evolutionary Database Design".

Получается, что любые ошибки в базе будут только накапливаться? Не совсем. Обратная совместимость обычно нужна только на текущую и следующую версию. Если у нас не коробка, а облачное решение, то одновременно могут работать только две версии. В таком случае, мы без проблем можем писать любые миграции, которые удаляют и меняют все что угодно, что уже не используется. Заметьте, это не откат, а новые миграции.

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

Больше про разработку в моем телеграм-канале организованное программирование

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

✔️ Гарантируем интересные задачи
✔️Для каждого нового сотрудника есть наставник
✔️ Центр компетенций помогает прокачивать навыки
✔️ С нами ты можешь работать из любой точки мира
✔️ Для экстравертов у нас есть уютные офисы в Москве и Томске
✔️ Оптимальный Work Life Balance

🎁 Наши плюшки: ДМС со стоматологией, обучение от компании и бонусная программа.

📢 Мы ищем:

1️⃣Аналитика 1C (https://tomsk.hh.ru/vacancy/123248946?from=employer&hhtmFrom=employer)

2️⃣Системного аналитика (https://tomsk.hh.ru/vacancy/122192419?from=employer&hhtmFrom=employer)

3️⃣ Аналитика DWH (https://tomsk.hh.ru/vacancy/122295631?from=employer&hhtmFrom=employer)

👉 присылай резюме в ЛС нашему HR Lead https://t.me/AONikitina
Подробности о вакансиях читай на ХХ.ру (https://hh.ru/employer/5648224?hhtmFrom=vacancy)
Ждем тебя в команду SSP SOFT!

Привет, сообщество!

У меня есть невероятно крутые новости!

Благодаря вашей потрясающей щедрости и пожертвованиям, которые мы получили, мы собрали средства, необходимые для восстановления и продолжения интеграции ChatGPT на нашей платформе! 🥳

Ваша поддержка значит для меня очень много. Она напрямую покрывает расходы на API OpenAI, гарантируя, что такие функции, как генерация запросов на естественном языке и умная помощь по SQL, остаются доступными для всех.

Мы запустили sqlize.online как доступный инструмент для изучения и работы с SQL, и возможности ИИ являются ключевой частью этого проекта. Знание того, что многие из вас ценят этот сервис и помогли поддерживать его работу, по-настоящему мотивирует.

Это доказательство силы сообщества! Спасибо вам за веру в sqlize.online и за помощь в поддержке ресурсов для блага всех энтузиастов и профессионалов SQL.

Мы обязуемся продолжать совершенствовать sqlize.online и расширять ваши возможности в работе с данными.