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

Isar — это NoSQL база данных, которую когда-то разработали создатели Hive. Про все плюсы этой БД мы уже писали. Однако однажды нашей Flutter-команде достался проект, который заставил их в корне изменить отношение к Isar и отказаться от этой технологии раз и навсегда.

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

Но специфика приложения накладывала на нас и вполне себе конкретные технические требования: оно должно было бесперебойно работать в офлайне — поля всё-таки бывают далековато от вышек мобильных операторов. Для реализации офлайн-режима как раз и был выбран Isar — это решение казалось удобным.

Как же мы ошибались! Так как у приложения был офлайн-режим, на старте оно загружало большие объемы данных, среди которых, например, было гигантского видео. И это создавало проблемы. В приложении добавлялись новые справочники, но документации на миграцию в Isar не было. К тому же на Android 32-ой архитектуры в базе вылезли баги.

Как исправить эти нюансы, мы не поняли. Писали письма разработчикам Isar, смотрели, что пишут об этом в сообществах. Но в итоге махнули рукой: решили всё переписать на SQL. Выбрали Drift, так как уже имели опыт работы с ним. Взяли уже готовый интерфейс и добавили его в приложение. Вскоре поняли, что Drift отвечает нашим запросам. Isar же использовать в проектах больше не планируем.

Кстати, этот проект в целом оказался судьбоносным для нашей команды Flutter. Какие еще уроки они вынесли после работы над приложением — в отдельной статье.

Изначально статья была выложена на своём сервере https://ast-1c.kz/almasoft/?p=1443

Ничего сверхъестественного, но может кому пригодится:)

В процессе работы с сервером 1С, который в качестве сервера баз данных использует MSSQL сервер, очень часто приходится решать задачу по очистке логов базы. Сама по себе задача достаточно тривиальная и решается исполнением скрипта (при полной модели восстановления):

USE база_данных;  
GO  
-- Изменяем модель восстановления базы данных на SIMPLE.  
ALTER DATABASE база_данных
SET RECOVERY SIMPLE;  
GO  
-- Обрезаем LOG файл до 1 мегабайта.  
DBCC SHRINKFILE (база_данных_log, 1);  
GO  
-- Возвращаем модель восстановления базы данных на FULL.  
ALTER DATABASE база_данных
SET RECOVERY FULL;  
GO

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

USE база_данных;  
GO  
-- Обрезаем LOG файл до 1 мегабайта.  
DBCC SHRINKFILE (база_данных_log, 1);  
GO  

Всё, просто и хорошо, но вот если на сервере скажем 100 баз, писать такой скрипт для каждой в отдельности — это не очень приятное задание, да и времени уйдет предостаточно. А ещё есть одно неудобство — если в последствии будет добавлена очередная база, то Вы не должны забыть и для неё прописать отдельный скрипт. Очень часто базы добавляют программисты 1С, а вот слежение за состоянием сервера ложится на плечи системного администратора. Ну и тут главное не просмотреть этот момент. В общем не очень удобная штука.

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

Declare @name varchar(100)
declare @qu as varchar(1200)
declare icur cursor fast_forward for

SELECT name
FROM sys.databases
WHERE name NOT IN ('master', 'model', 'msdb', 'tempdb')
--and recovery_model_desc = 'FULL'

open icur
 fetch next from icur into @name
 While @@Fetch_Status = 0 

Begin
  Set @qu='use [' + @name + '] Declare @logname varchar(64), @size int'
  Set @qu=@qu + ' Set @logname = (SELECT [name] FROM [sys].[database_files]  where type_desc=''LOG'')'
  Set @qu=@qu + ' Set @size = (SELECT max_size FROM [sys].[database_files]  where type_desc=''LOG'') * 0.7/128'
  Set @qu=@qu +  ' ALTER DATABASE [' + @name + ']  SET RECOVERY SIMPLE DBCC SHRINKFILE (@logname, 7)'
  Set @qu=@qu + ' ALTER DATABASE [' + @name + ']  SET RECOVERY FULL'
  Exec (@qu) 
  Set @qu = '' 
  fetch next from icur into @name
END
close icur

SELECT name
FROM sys.databases
WHERE name NOT IN ('master', 'model', 'msdb', 'tempdb')
--and recovery_model_desc = 'SIMPLE'

open icur
 fetch next from icur into @name
 While @@Fetch_Status = 0 

Begin
  Set @qu='use [' + @name + '] Declare @logname varchar(64), @size int'
  Set @qu=@qu + ' Set @logname = (SELECT [name] FROM [sys].[database_files]  where type_desc=''LOG'')'
  Set @qu=@qu + ' Set @size = (SELECT max_size FROM [sys].[database_files]  where type_desc=''LOG'') * 0.7/128'
  Set @qu=@qu +  ' ALTER DATABASE [' + @name + ']  SET RECOVERY SIMPLE DBCC SHRINKFILE (@logname, 7)'
  Exec (@qu) 
  Set @qu = '' 
  fetch next from icur into @name
END
close icur
deallocate icur

DBCC SHRINKDATABASE (TEMPDB);

Скачать готовый на GitHub Gist

Сегодня хочу рассказать о GIN индексах в PostgreSQL. Это один из мощных инструментов, которые есть в БД PostgreSQL. Но почему-то очень многие незаслуженно обходят его стороной.

Что такое GIN индекс

GIN (Generalized Inverted Index) – это инвертированный индекс, который предназначен для ускорения поиска в структурах данных, содержащих составные типы. Он имеет встроенную оптимизацию, позволяющую искать по элементам внутри сложных структур. По своей сути, это обратный индекс, где для каждого уникального элемента хранится список указателей на записи, в которых он встречается. Это дает возможность быстро находить записи, соответствующие запросу.

Для каких типов данных используется GIN индексы

GIN-индексы особенно эффективны для следующих типов данных:

• Массивы

  • Хранение списков значений

  • Быстрый поиск по элементам массива

  • Пример: теги, категории, списки ID

• JSONB

  • Хранение полуструктурированных данных

  • Быстрый поиск по ключам и значениям

  • Поддержка сложных запросов к JSON-документам

• Полнотекстовый поиск

  • Индексация текстовых полей

  • Быстрый поиск по словам и фразам

  • Поддержка различных языков

Преимущества GIN индексов

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

• Поддержка различных типов данных: Работает с различными типами - строки, числа, массивы, объекты JSONB и даже геопространственные данные.

• Подходит для оптимизации полнотекстового поиска: Улучшает производительность запросов с использованием операторов @@ и функций вроде to_tsvector() и to_tsquery(). Особенно полезен там, где требуются операции пересечения (&&), включения (@>), проверки существования элементов массива (?, ?&) и другие специфические условия.

Недостатки GIN индексов

• Обновление: Каждый раз, когда изменяется запись, содержащая поля, входящих в GIN индекс, индекс обновляется целиком. Это увеличивает нагрузку на систему при частых изменениях данных.

• Больший размер: GIN индекс занимает больше места на диске по сравнению с традиционными B-tree индексами, так как хранит список всех значений, содержащихся в колонке.

• Низкая производительность на малых объемах данных: При небольших объемах данных GIN индекс может быть менее эффективным.

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

Заключение

При работе с массивами, JSONB полями и полнотекстовым поиском стоит рассмотреть использование GIN индексов для данных полей. Это позволит повысить эффективность и производительность БД PostgreSQL. Но, в то же время, стоит учитывать особенности его обслуживания и требования к системе. Очень аккуратно применять к часто изменяемым данным.
Очень хорошая статья о GIN индексах https://habr.com/ru/companies/postgrespro/articles/340978/

Более подробно с примерами у меня в телеграмм

Спасибо за внимание!

Я люблю кофе, но, как и у некоторых других людей, у меня повышается давление и сильно учащается пульс от большого количества выпитого кофе, а 2..3 порции порции на меня уже не действуют. На дворе 21 Век в разгаре и существование аналогов кофеина без раздражающих побочных эффектов весьма вероятно.

Я попросил помощи у ChatGPT и он успешно создал очень сложную таблицу с легальными аналогами кофеина и даже с вычисляемым столбцом на основе НЕЧЁТКИХ критериев (если вы это сможете на SQL - Вы гений!), но плохо справился с сортировкой в этой таблице.

Внимание: ниже изображение, ссылки некликабельные. Я ничего не продаю.

В первом цифровом столбце не удалось отсортировать числа по убыванию. Пытался примерно 15-20 минут. Пробовал разные промпты и пояснения. Это странно.

Этот инструмент (ChatGPT) отлично понимает команды манипуляции таблицей, в данном пример я попросил создать таблицу на основе данных с крупных магазинов, указал какие столбцы нужны и какая в них должна быть информация, указал порядок столбцов, в том числе относительный, типа столбец с такими данным добавь перед таким-то столбцом.

ChatGPT смог создать СВОДНЫЙ столбец на основе ранее созданных столбцов.Это столбец со взвешенными суммами весов веществ в других столбцах и коэффициенты взвешивания ОН сам нашел и нашел весьма точно.

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

ChatGPT даже частично смог отсортировать по взвешенной сумме. Но выполнив так много сложной работы в сортировке он немного ошибся.

Знание SQL — мастхэв при работе с базами данных в большинстве современных компаний. У нас в Сравни дата-специалисты используют SQL, взаимодействуя с множеством технологий и инструментов, от Snowflake, Greenplum и ClickHouse до Superset. При найме стажёров в наши технические команды, тестовое задание в большинстве случаев включает в себя проверку знаний по SQL.

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

Чтобы помочь вам с этим, наш дата-инженер Владимир Шустиков подготовил цикл из 5 видео, в которых рассмотрел ключевые вопросы об SQL на собеседованиях. Материал составлен по мотивам прохождения десятков собеседований в ИТ-команды компаний. С его помощью можно не только подготовиться к интервью (как морально, так и практически), но и проверить себя: сопоставить свои знания про SQL с тем, что на самом деле ожидают от специалиста. 

Полезно будет дата-инженерам, аналитикам, а также бэкенд-разработчикам. 

Каждое видео посвящено отдельному блоку вопросов по SQL:

1. Топ вопросов на собеседовании по SQL — порядок выполнения запроса, виды команд, типы данных

• YouTube

• RUTUBE

2. Топ вопросов на собеседовании по SQL — логические и физические виды JOIN, оконные функции, EXPLAIN

• YouTube

• RUTUBE

3. Топ вопросов на собеседовании по SQL — NULL, Агрегация

• YouTube

• RUTUBE

4. Топ вопросов на собеседовании по SQL — задачи на JOIN, различие между TRUNCATE, DROP, DELETE

• YouTube

• RUTUBE

5. Топ вопросов на собеседовании по SQL — WHERE, HAVING, QUALIFY; подзапросы и CTE; сочетания запросов

• YouTube

• RUTUBE

Смотрите, углубляйте свои знания в SQL, получайте офферы!

ТГ-канал нашего инженерного сообщества Sravni Tech

Что такое суперапп?

Суперапп — это мобильное приложение, объединяющее множество сервисов и функций в одном месте. 

В России ярким примером успешного супераппа служит Яндекс Go. Самым известным представителем в мире является китайский WeChat, которым пользуется около миллиарда человек и в котором собраны практически все необходимые сервисы для жизни.

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

1️⃣ Неоспоримым преимуществом является синергия и обширная база пользователей. Даже новым фичам и продуктам внутри супераппа практически не стоит беспокоиться о том, откуда взять трафик. Например, “Самокаты” были запущены сразу в рамках Яндекс Go, поскольку там уже находилась целевая аудитория этого сервиса.

2️⃣ Супераппы генерируют море данных о самых разных аспектах жизни пользователей, и для аналитика это – рай! У вас будет возможность анализировать поведение пользователей в комплексе, выявлять скрытые взаимосвязи и находить инсайты, которые невозможно получить, работая в компании, специализирующейся на одном узком направлении. Это просто кладезь для персонализации, настройки рекомендаций и CRM-коммуникаций. 

3️⃣ Расширение границ. Супераппы позволяют попробовать себя в разных сферах и бизнесах, оставаясь в одной компании. Даже работая в одной команде, для выполнения ряда задач необходимо погружаться в контексты бизнесов других команд, а если захочется сменить сферу, достаточно просто ротироваться.

Но есть и другая сторона.

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

2️⃣ Сложность атрибуции эффектов. В рамках супераппа каждая команда хочет оценивать своё влияние, и здесь перед аналитиком встает логичная задача: как и к кому атрибуцировать активность пользователей. На рынке существует много практик (last/first click, position-based и т. д.), но внедрить и обосновать конкретную методологию — крайне непростая задача, а спрогнозировать и доказать долгосрочное влияние, чтобы положить его в цели/бюджеты... ну, вы поняли)

3️⃣ Всегда необходимо учитывать влияние новых решений на другие продукты и сервисы, входящие в экосистему супераппа. Например, оценивать, как размещение точки входа в ваш продукт на главной странице повлияет на остальные продукты, и в случае негативного влияния предоставить аргументы и цифры, нивелирующие его. Это требует включения “helicopter view” — понимания взаимосвязией сервисов, ключевых метрик, процессов и инструментов на уровне всей платформы.

А что вы думаете, какой опыт интереснее и ценнее: в больших мультикатегорийных сервисах или в командах, сфокусированных на одном сервисе/продукте?

Еще больше про аналитику в td data dreamen

Новые релизы:

• Arenadata DB (ADB) — v6.27.1.59;

• Arenadata DB Backup Manager (ADBM) — v2.3.2;

• Arenadata DB Control (ADBC) — v4.11.0;

• Arenadata Streaming (ADS) — v3.6.2.2.b1;

• Arenadata Catalog (ADC) — v0.8.0;

• Arenadata Cluster Manager (ADCM) — v2.5.0.

Обновления компонентов Arenadata Cluster Manager (ADCM):

• Arenadata Monitoring (ADM) — v4.1.0;

• Arenadata Enterprise Tools (ADET) — v2024121800.

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

⛓ Текст обзора и ссылки на полное описание релизов здесь.

Вы только что были приняты на работу в качестве Data Scientist в таинственную организацию Squid Game. Фронтмен, управляющий Squid Games, пообещал вам полностью удаленную работу. Но, как это обычно бывает в индустрии, вас подставили и обманули. Оказалось, что роль больше связана с аналитикой продуктов на SQL, а работа не полностью удаленная, а гибридная: 5 дней в офисе, 2 дня удаленно. Вы даже не успели пожаловаться на эту работу, как фронтмен приставил к вашей голове пистолет и начал требовать ответы на различные бизнес‑вопросы. Вы должны написать SQL‑запросы, чтобы ответить ему — иначе пуля.

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

В YDB появилась новая функциональность: теперь СУБД Яндекса поддерживает работу со сложными аналитическими запросами (OLAP). Благодаря этому компании смогут не только хранить и обрабатывать в YDB сотни терабайт транзакционных данных, но и выполнять над этими данными запросы и создавать системы для поддержки принятия решений — корпоративные хранилища данных.

Система горизонтально масштабируется за счёт шардирования — автоматического партиционирования по объёму и нагрузке, — а также обеспечивает быстрое выполнение запросов благодаря массивно‑параллельной архитектуре (МРР).

Аналитическая функциональность компонента YDB DWH включает колоночные таблицы с консистентным хранением данных и управление смешанной нагрузкой. В платформу СУБД Яндекса также входит движок выполнения запросов со спиллингом данных на диск, стоимостный оптимизатор, федеративные SQL‑запросы к внешним источникам данных (S3, PostgreSQL, Greenplum, Oracle, Microsoft SQL), что позволяет создавать корпоративные хранилища данных. В планах реализация поддержки SQL-диалекта PostgreSQL для интеграции как в OLAP‑, так и в OLTP‑сценарии.

Платформа распространяется по коммерческой лицензии. Её можно и установить в собственной инфраструктуре (on‑premise), и использовать как управляемый сервис в Yandex Cloud.

Собрали статьи, которые будут интересны начинающим аналитикам. Если вы только начинаете знакомство с SQL или хотите освежить знания, эта подборка для вас.

Типы данных SQL — что о них нужно знать начинающему аналитику. Разбираем, какими они бывают и как с ними работать.

Таблицы в SQL: типы и операции — различные типы таблиц и основные операции, которые можно выполнять над ними.

SQL-запросы — основные команды для управления базами данных.

Оконные функции в SQL — что это и как использовать.

Основные ошибки SQL — список распространённых ошибок в работе с запросами баз данных SQL и лучших практик, о которых забывают некоторые пользователи. Рассказываем, как найти ошибки и исправить их.

Потренироваться и решить 70 задач в тренажёре можно на бесплатном курсе «Основы работы с базами данных и SQL».

Чтобы изменить такую объектную модель, например, добавить или удалить атрибут, нужно внести изменения в схему базы данных, то есть выполнить DDL‑операцию. Она сопровождается блокировками таблиц и увеличением времени простоя при работе с данными. Кроме того, при увеличении числа атрибутов можно превысить ограничение на количество колонок в таблице. Например, в Postgres их можно создать не более 1600.

Эти проблемы можно устранить, используя хранение данных в формате JSON. Основные преимущества такого подхода:

• отказ от фиксированной структуры таблиц;

• гибкость без необходимости изменения схемы.

Обращение к динамическим полям может осложниться при работе с Hibernate до версии 6.2. Более ранние версии не позволяют обращаться к полям внутри JSON на уровне HQL, что ограничивает возможности фильтрации и сортировки. Поэтому оптимальный вариант — использовать Native SQL. Hibernate позволяет регистрировать SQL‑функции, чтобы вызывать их из HQL‑запросов. Пример регистрации такой функции для Postgres приведен ниже:

registerFunction("jsonQuery",
    new SQLFunctionTemplate(StandardBasicTypes.STRING,
        "jsonb_path_query_first(?1, ?2)::varchar"));

• Первый параметр — колонка в БД, внутри которой хранится JSON, выполняющий запрос.

• Второй параметр — запрос в виде JSON Path, который позволяет добраться до определенных полей.

Пример структуры JSON и использования на ней SQL-функции в запросе:

{
  "CPU_Brand": "Intel",
  "CPU_Model": "Xeon 8380",
  "RAM_Size_GB": 64
}

SELECT obj.id
FROM userObject obj
WHERE jsonQuery(obj.json, '$.CPU_Brand') = 'Intel'

При работе с более сложными вещами, например, фильтрация объектов с вложенными данными, SQL Server требует применения конструкций CROSS APPLY и openjson.

Третья лекция нашего курса «Deep dive into SQL and DWH» прошла 21 ноября — делимся видеозаписью!

Дата-архитектор Павел Ковалёв рассказал о внутреннем устройстве систем Greenplum и Clickhouse и возможностях, которые они предоставляют с точки зрения оптимизации запросов.

Посмотреть запись можно здесь:

• YouTube

• RUTUBE

• VK

Оставшиеся два занятия курса пройдут в формате очной практики. Видеозаписи трёх прошедших лекций доступны в отдельном плейлисте.

Делимся лекциями курса «Deep dive into SQL and DWH» от Павла Ковалёва, дата-архитектора Сравни.

Вторая лекция прошла 14 ноября; предлагаем посмотреть её видеозапись.

Внутри — обзор инструментов построения DWH/Data Lake, в том числе: Hadoop, Spark, Trino, Databricks, Amazon Athena, Amazon Redshift и Google BigQuery.

Посмотреть можно здесь:

✅YouTube

✅RUTUBE

✅VK

Следующая лекция курса будет посвящена техникам оптимизации аналитических SQL-запросов и состоится уже в ближайший четверг, 21 ноября, с 17:25 до 19:00.

Присоединяйтесь в зуме!

Делимся лекциями курса «Deep dive into SQL and DWH» от Павла Ковалёва, дата-архитектора Сравни.

Первая лекция прошла 7 ноября — предлагаем посмотреть её видеозапись.

Внутри лекции:

• Обзор основных понятий курса (OLTP и OLAP, хранилище данных, его базовые слои, архитектуры обработки данных и т.д.)

• Устройство DWH — на примере компании Сравни

• Основы оптимизации аналитических SQL-запросов

• Как решать проблемы с неэффективными запросами: практические кейсы

Посмотреть запись можно здесь:

✅YouTube

✅RUTUBE

✅VK

Следующая лекция курса, посвященная архитектурному обзору инструментов для построения DWH, пройдёт уже в ближайший четверг, 14 ноября, с 17:25 до 19:00. Присоединяйтесь в онлайне!

***

Больше информации о наших лекциях, митапах, статьях и других полезных материалах про ИТ, в тг-канале Sravni Tech.

Я — робот-осьминог и талисман ИЦ, который иллюстрирует разносторонность и многозадачность нашей команды. Мои 8 щупалец представляют различные направления работы, а 3 сердца обеспечивают высокую эффективность. Отсутствие скелета позволяет гибко адаптироваться к изменениям, а более 1000 рецепторов на щупальцах помогают мне воспринимать малейшие колебания в окружении.

Я способен погружаться глубоко в изучение вопросов, что помогает развиваться и искать новые решения. Подписывайтесь на обновления, и давайте вместе исследовать мир технологий!

Опубликовали запись доклада секции «Разработка» с Ural Digital Weekend 2024.

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

Ссылка на запись доклада в ВКонтакте.

Ссылка на презентацию: https://goo.su/qHW9

• запуск модели;

• полный перезапуск модели;

• компилирование модели с выводом в новый буфер;

• генерация yaml-описания модели с выводом в новый буфер;

• отображение зависимостей модели в Телескопе.

Установка и доступные команды доступны в репозитории. Если есть пожелания и рекомендации — пишите в гит или телеграм.

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

Это же так просто и в общем то лежит на поверхности - сделал изменение , собери статистику влияния и оцени характер полученных результатов по совокупности опытов. Нужно подчеркнуть - не картинки, не "кажется" , "наверное" , "скорее всего", "может быть" , а цифры. И цифры взятые не с потолка , а рассчитанные математически. И даже не надо ничего нового придумывать и изобретать - медиана, мода , стандартное отклонение , дисперсия , корреляция - 3й курс КАИ, если не ошибаюсь. Вполне достаточно , для получения объективных результатов анализа, а не гаданий и шаманских танцев с бубнами.

Почему DBA не используют математику ? Риторический вопрос ....

В дополнении к теме:

Размышления о мониторинге производительности отдельного SQL запроса

Для возможного варианта решения задачи:

https://habr.com/ru/posts/833162/

если производительность отдельного SQL запроса в настоящее время не мониторится.

Предположение.

Для того, чтобы оценить производительность отдельного SQL запроса необходимо и достаточно получить отношение стоимости запроса (EXPLAIN ANALYSE) к актуальному времени выполнения запроса .

Важное следствие и ограничение:

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

Данное весьма существенное ограничение , вообще говоря, влечет реальные проблемы для использования данной методики в промышленной эксплуатации СУБД(запрос может быть весьма ресурсоемким). Но с другой стороны, позволяет очень чётко и однозначно отследить причины изменения производительности запроса при изменении текста запроса и/или, что важнее - при изменении входящих параметров запроса .

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

Друзья! У Петра вышло продолжение серии обзорных статей про ClickHouse — open-source OLAP базу данных, ориентированную на колонки. В новой статье наш DevOps-инженер рассказывает про особенности репликации в этой СУБД.

Из этой части вы узнаете:

• как работают сервисы координации Zookeeper и ClickHouse Keeper;

• по какой причине может произойти падение репликации;

• почему не следует очищать Keeper вручную.

Чтобы вспомнить, о чём Пётр рассказывал в первой части — нажмите сюда.

А чтобы ознакомиться с новой частью — сюда.