Хочу поделиться записью моего последнего вебинара - в преддверии следующего. Буду рад всем, кто посмотрит.
📘 Часть 1. Теория и философия Digital Q.DataBase Разбираем фундаментальные вопросы: • Как Digital Q.DataBase объединяет три SQL-диалекта (T-SQL, PL/SQL, PL/pgSQL) в одном ядре? • Как продукт обеспечивает простоту и высокую скорость миграции? • Что входит в базовый состав коробочной версии?
🛠 Часть 2. Практика: установка и работа с диалектами • скачиваем и устанавливаем Digital Q.DataBase, • получаем документацию, • выполняем практику по SQL-диалектам на демостендах.
Да, это тот самый момент, когда теория превращается в конкретику - и вы сами видите, как работает гибридная архитектура продукта.
Почему у PWA до сих пор нет полноценного «магазина приложений» — возможно ли это вообще?
Всем привет.
В течение последних месяцев, работая с PWA-приложениями, мы постоянно сталкивались с одним и тем же вопросом:
Почему в 2025 году у PWA до сих пор нет настоящего App Store?
Не просто каталога ссылок, а полноценного магазина приложений — знакомого, вызывающего доверие и понятного обычным пользователям.
При изучении существующих PWA-магазинов и каталогов обнаруживаются одни и те же повторяющиеся проблемы.
⸻
Установка остаётся непонятной для пользователей
Даже сегодня установка PWA вызывает затруднения у обычных пользователей.
Большинство из них не понимают: • когда приложение действительно можно установить, • почему инструкции по установке не совпадают с реальными шагами в их браузере или на устройстве.
Во многих PWA-каталогах всё ограничивается текстовой инструкцией — и на этом взаимодействие с сервисом фактически заканчивается.
⸻
Отсутствие доверия
Со стороны пользователя это проявляется в следующем: • нет содержательных отзывов, • отсутствует история установок, • нет ощущения личной библиотеки приложений.
Со стороны разработчиков наблюдаются крайности: • либо любой может опубликовать приложение без подтверждения права собственности, • либо проверка обязательна, но сложна и ограничена одним способом (например, через DNS-записи).
В итоге доверие не формируется ни у одной из сторон.
⸻
Разработчики — второстепенные участники экосистемы
Распространённые проблемы: • медленные и неудобные процессы публикации, • почти полное отсутствие автоматического заполнения данных из манифеста, • нехватка инструментов, которые были бы полезны разработчику ещё до установки приложения пользователем.
Экосистема не стимулирует разработчиков поддерживать и развивать свои PWA.
⸻
Интерфейс не воспринимается как «нативный»
Это тонкий, но важный момент.
Если магазин: • выглядит как обычный веб-сайт, • не вызывает ассоциаций с App Store или Google Play,
пользователи инстинктивно доверяют ему меньше — даже если сами приложения качественные.
⸻
При этом сами PWA как технология за последние годы заметно повзрослели: офлайн-режим, push-уведомления, installability, Web APIs. Однако именно слой распространения и доверия остаётся самым слабым звеном.
⸻
Главный вопрос, к которому мы пришли
Возможно ли вообще создать PWA-магазин, который: • пользователи будут воспринимать как настоящий магазин приложений, • не станет источником боли для разработчиков, • сможет устойчиво развиваться, а не быть заброшенным через несколько месяцев?
Или же сама идея магазина PWA в текущей экосистеме изначально ошибочна?
Будет интересно узнать ваш опыт.
Вы публиковали PWA-приложения в существующих магазинах или каталогах? Что вызывало наибольшие сложности — у разработчиков или у пользователей?
Открываем доступ по запросу к Yandex Managed Service for Sharded PostgreSQL — сервису на базе технологии SPQR для горизонтального масштабирования PostgreSQL
PostgreSQL по умолчанию не имеет нативной поддержки горизонтального масштабирования — и это вызывает сложности при достижении пределов единственного экземпляра Postgres. В качестве решения часто используют разделение таблиц по ключам и установку рядом с приложением координатора, который знает, на какой шард направить запрос.
Однако у такого подхода множество недостатков: сложность миграций, проблемы с масштабированием метаданных и балансировкой и не только.
Сегодня мы открываем доступ по запросу к управляемому сервису Yandex Managed Service for Sharded PostgreSQL. Новый инструмент создан на базе SPQR (Stateless Postgres Query Router) — это опенсорс‑решение для горизонтального масштабирования PostgreSQL, которое разработано инженерами из команды платформы данных Yandex Cloud и оптимизировано под OLTP‑нагрузки и плавные миграции.
Управляемый сервис на основе SPQR позволит клиентам облачной платформы Yandex Cloud ускорить обработку миллионов транзакций: так, с Sharded PostgreSQL банки и компании из сферы электронной коммерции могут запускать новые ИТ‑продукты в 3–4 раза быстрее. Надёжность технологии шардированного PostgreSQL проверена на проектах Яндекса.
Команда активно развивает технологии PostgreSQL: каждый год в релиз базы данных попадает множество доработок от контрибьюторов из Yandex Cloud:
Инкрементальное улучшение любой популярной технологии зачастую имеет негативные последствия. Построить что‑то новое, ничего не сломав, бывает трудно и в чистом поле, а ядро PostgreSQL в этом смысле — лабиринт с граблями.
Но большинство незавершённых проектов создают инфраструктуру для того, чтобы какие‑то другие проекты могли завершиться и причинить пользу.
Андрей Бородин, руководитель команды разработки СУБД с открытым исходным кодом Yandex Cloud, Major Contributor PostgreSQL
Запустить в Dimension-UI мониторинг данных PostgreSQL с помощью запроса с интервалом 3 сек.
WITH params AS (
SELECT
15 AS total_frames,
20 AS canvas_height,
3 AS frame_duration_sec
),
animation_state AS (
SELECT
(CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP) AS INTEGER) / frame_duration_sec) % total_frames AS frame_idx
FROM params
),
tree_definition AS (
SELECT
frame_id,
y_pos,
CASE
-- ═══════════════════════════════════════
-- ЗВЕЗДА на верхушке
-- ═══════════════════════════════════════
WHEN y_pos = 20 AND frame_id = 7 THEN '*'
-- ═══════════════════════════════════════
-- ВЕРХУШКА елки (острая)
-- ═══════════════════════════════════════
WHEN y_pos = 19 AND frame_id = 7 THEN 'G'
-- ═══════════════════════════════════════
-- ЯРУС 1 (y=16-18) — расширяется книзу
-- ═══════════════════════════════════════
WHEN y_pos = 18 AND frame_id BETWEEN 6 AND 8 THEN 'G'
WHEN y_pos = 17 AND frame_id BETWEEN 5 AND 9 THEN 'G'
WHEN y_pos = 16 AND frame_id BETWEEN 4 AND 10 THEN 'G' -- широкий низ яруса
-- Сужение перед ярусом 2
WHEN y_pos = 15 AND frame_id BETWEEN 5 AND 9 THEN 'G'
-- ═══════════════════════════════════════
-- ЯРУС 2 (y=12-14)
-- ═══════════════════════════════════════
WHEN y_pos = 14 AND frame_id BETWEEN 4 AND 10 THEN 'G'
WHEN y_pos = 13 AND frame_id BETWEEN 3 AND 11 THEN 'G'
WHEN y_pos = 12 AND frame_id BETWEEN 2 AND 12 THEN 'G' -- широкий низ яруса
-- Сужение перед ярусом 3
WHEN y_pos = 11 AND frame_id BETWEEN 4 AND 10 THEN 'G'
-- ═══════════════════════════════════════
-- ЯРУС 3 (y=8-10)
-- ═══════════════════════════════════════
WHEN y_pos = 10 AND frame_id BETWEEN 3 AND 11 THEN 'G'
WHEN y_pos = 9 AND frame_id BETWEEN 2 AND 12 THEN 'G'
WHEN y_pos = 8 AND frame_id BETWEEN 1 AND 13 THEN 'G' -- широкий низ яруса
-- Сужение перед ярусом 4
WHEN y_pos = 7 AND frame_id BETWEEN 3 AND 11 THEN 'G'
-- ═══════════════════════════════════════
-- ЯРУС 4 — нижний, самый широкий (y=4-6)
-- ═══════════════════════════════════════
WHEN y_pos = 6 AND frame_id BETWEEN 2 AND 12 THEN 'G'
WHEN y_pos = 5 AND frame_id BETWEEN 1 AND 13 THEN 'G'
WHEN y_pos = 4 AND frame_id BETWEEN 0 AND 14 THEN 'G' -- во всю ширину!
-- ═══════════════════════════════════════
-- СТВОЛ (y=1-3)
-- ═══════════════════════════════════════
WHEN y_pos BETWEEN 1 AND 3 AND frame_id BETWEEN 6 AND 8 THEN 'T'
-- Всё остальное — фон
ELSE 'S'
END AS pixel_char
FROM generate_series(0, 14) AS frame(frame_id)
CROSS JOIN generate_series(1, 20) AS y(y_pos)
),
pixel_data AS (
SELECT td.*
FROM tree_definition td
JOIN animation_state ast ON td.frame_id = ast.frame_idx
),
layers_logic AS (
SELECT
y_pos,
pixel_char,
MAX(CASE WHEN pixel_char IN ('T', 'G', '*') THEN y_pos ELSE 0 END) OVER () as max_obj_height
FROM pixel_data
)
SELECT
CURRENT_TIMESTAMP as dt,
CASE
WHEN pixel_char = 'T' THEN '4_Trunk'
WHEN pixel_char = 'G' THEN '3_Tree'
WHEN pixel_char = '*' THEN '2_Star'
WHEN pixel_char = 'S' THEN
CASE WHEN y_pos > max_obj_height
p.s. Данные по запросу любезно предоставлены Claude Opus 4.5.
Привет, друзья! Мой коллега Марк, ведущий архитектор GlowByte, поделился в новой статье результатами тестирования YMatrix.
Сразу оговорюсь, что это дополнение к предыдущей статье, для того, чтобы сформировать понимание сравнимости результатов различных форков GreenPlum, поэтому акцентировать внимание будем только на YMatrix. Детали по методике тестирования и как были получены результаты для GP6, GP7 и Cloudberry 1.6, можно прочитать в предыдущей статье по ссылке выше.
Добро пожаловать в статью! Комментарии приветствуются.
Новый курс «Платформа Tantor 6.x» на «Астра Знания»!
Мы подготовили новый курс «Платформа Tantor 6.х», посвященный новым функциям платформы управления любыми Postgres-like СУБД и возможностям, доступным DBA после выхода обновления. Размещен курс на платформе «Астра Знания». Он сочетает структурированный теоретический материал и практические задания, которые помогают закрепить приобретенные знания и навыки.
В программе: ▪️архитектура Платформы и ее возможности ▪️интеграция и работа со Swagger UI ▪️инструменты мониторинга, конфигурирования и обслуживания PostgreSQL ▪️браузер БД ▪️анонимайзер ▪️работа с уведомлениями
Приглашаем на вебинар «Платформа Tantor 6.1. Умный центр администрирования СУБД на основе PostgreSQL».
Управляете парком PostgreSQL-совместимых СУБД и хотите сократить рутину и повысить надёжность? 11 декабря в 11:00 наши эксперты представят актуальный релиз Платформы Tantor 6.1. Платформа Tantor — интеллектуальный центр управления базами данных, который берет на себя массу актуальных задач DBA. На вебинаре покажем, как платформа решает ключевые из них:
Автоматизация вместо рутины: умные алерты, подсказки и встроенный ИИ-ассистент для помощи в повседневной работе;
Безопасность под контролем: централизованный аудит и визуальное управление настройками доступа (pg_hba, pg_ident);
Оптимизация «одной кнопкой»: анализ конфигураций, подбор оптимальных настроек под нагрузку и их групповое применение;
Всё на виду: наглядная топология кластеров, пространств и тенантов;
Лёгкое масштабирование: создание кластеров Tantor XData за пару кликов.
В финале — эксклюзивный анонс: дорожная карта развития Платформы Tantor на 2026 год.
Кому будет полезно: DBA, архитекторам, DevOps-инженерам и руководителям ИТ-направлений, которые работают с БД на основе PostgreSQL.
Этот пост — необычный. Он не о новом инструменте или результате исследования, а о процессе научной (и околонаучной) работы, ценности peer review, даже в его минимальной форме, и о том, как важно уметь признавать и исправлять ошибки.
Peer review (от англ. peer — «равный, коллега», review — «рецензия») — процесс экспертной оценки научных работ независимыми экспертами из той же области знаний. Эти эксперты (рецензенты) не работают в том же учреждении, что и автор, и не имеют с ним конфликта интересов. Их задача — беспристрастно проанализировать исследование и дать заключение о его качестве.
В сценарии действительно была допущена методологическая ошибка, которая исказила результаты и, как следствие, выводы.
Научная и исследовательская честность требует исправления ошибок, а не их сокрытия. Поэтому, предприняты следующие шаги:
Статья по эксперименту "Анализ вариантов оптимизации ресурсоёмкого SQL-запроса: Вариант-4 «Временная таблица»" ( https://habr.com/p/972276/ ) - исправлена, эксперимент откорректирован.
Выводы в статье по итогам цикла экспериментов "Итоги анализа вариантов оптимизации ресурсоёмкого SQL-запроса" (https://habr.com/p/973126/) - исправлены. Результат цикла экспериментов - изменен.
Статья "Прогноз vs Реальность: прогноз нейросети «Временная таблица vs CTE в многопользовательской среде PostgreSQL»" - снята с публикации. Статья была построена вокруг вопроса к нейросети, который, как выяснилось, был сформулирован на шатком фундаменте (из-за той самой ошибки в сценарии).Постановка вопроса была признана некорректной, что делает всю статью и ее анализ невалидными. Во избежание распространения ложной информации, статья - удалена. Это более ответственный шаг, чем исправление, так как ее основная предпосылка была ошибочна.
Выводы и благодарность
Этот случай стал для мощным напоминанием о нескольких важных принципах:
Ценность открытости. Публикация методологии позволяет сообществу ее проверить.
Сила сообщества. Один вдумчивый комментарий может быть ценнее десятков часов самостоятельной работы «в слепую».
Процесс важнее результата. Настоящее исследование — это не путь от гипотезы к красивому графику, а итеративный процесс проверки, сомнения и корректировки. Ошибаться — нормально. Гораздо важнее, как ты исправляешь ошибки.
Огромная благодарность@khalimonas , за потраченное время и внимательность, чтобы указать на неточность.
Этот опыт только укрепил убеждение в важности диалога с техническим сообществом. Я продолжу делиться своими экспериментами, и буду рад любой конструктивной критике, которая помогает приблизиться к более точному пониманию исследуемой темы.
Все указанные выше изменения внесены. Первая статья обновлена, вторая — откорректирована, третья — удалена.
Честно сравним два подхода и разберем, с какими сложностями и скрытыми рисками можно столкнуться при переходе с on-premise на Managed PostgreSQL в облаке. И, главное, как их избежать.
Поговорим о разделении ответственности за кибербезопасность между облачным провайдером и клиентом. Расскажем, какие задачи лежат на каждой из сторон и как модель разделенной ответственности помогает избежать инцидентов.
Сложное развертывание, тонкая настройка и постоянная зависимость от IT-специалистов растягивают внедрение бизнес-аналитики. На вебинаре покажем, как развернуть полнофункциональную BI-систему в облаке за день.
«Тантор Лабс» активно поддерживает российское сообщество открытой СУБД PostgreSQL. Наши специалисты уже много раз выступали спикерами на официальных комьюнити-мероприятиях PG BootCamp Russia, проводили лекции и мастер-классы.
Делимся с вами подборкой наших выступлений, темы которых можно условно разделить на несколько ключевых направлений.
Внутренности PostgreSQL и оптимизация ядра — для тех, кто хочет понимать СУБД «под капотом»
Кстати, на весенний PG BootCamp Russia 2026, который пройдет в Москве, открыт прием заявок на выступления! Это отличный шанс поделиться знаниями с одним из самых сильных профессиональных сообществ.
Продолжается набор на авторизованный курс по СУБД Tantor Postgres!
Авторизованный курс по администрированию СУБД Tantor Postgres будет полезен администраторам БД, DevOps-инженерам, системным аналитикам и разработчикам. Вы получите практические навыки работы с популярной СУБД напрямую от экспертов «Тантор Лабс», безлимитный доступ к тестовому стенду и всем материалам курса, включая записи.
По окончании курса слушатели курса получат удостоверение о повышении квалификации государственного образца.
Содержание курса построено на балансе 50% теории / 50% практики. Проходит курс под наблюдением преподавателя – эксперта«Тантор Лабс».
Курсы пройдут в онлайн-формате:
с 8 по 12 декабря —в «Сетевой академии Ланит»;
с 22 по 26 декабря — в учебном центре «Микротест».
Блог Tantor на Habr: наша коллекция знаний по Tantor и PostgreSQL для вас 🐘
Друзья, наш блог на Хабре появился полгода назад, и за это время мы опубликовали целую библиотеку материалов. Мы не только пишем код и рассказываем о новинках, но и делимся тем новым, что изучаем и узнаем. Собрали для вас все статьи в тематические подборки:
🧑💻 Решение конкретных задач для администраторов БД и DevOps-инженеров
Узнавайте новое и бесплатно практикуйтесь в панели управления Selectel
Привет, Хабр! Обычно (хоть и не всегда) по пятницам я приношу подборки полезных материалов для начинающих специалистов. Но в этот раз у меня кое-что новое. Сегодня я расскажу не только о том, что почитать, но и как бесплатно отточить полученные знания, не тратя кровно заработанные на аренду IT-инфраструктуры.
При изучении полезных материалов вы можете запросить промокод на 500 бонусных рублей, чтобы попрактиковаться в панели управления бесплатно. Подробные условия и инструкции по получению бонусов находятся на страницах с подборками статей:
Go — практический гайд по работе с Go. С ним вы научитесь писать простые сервисы и использовать этот язык в некоторых рабочих задачах, а еще получите большую подборку материалов для погружения в тему.
Python — как настраивать инструменты, работать с базами данных, создавать программы с интерфейсом и использовать Python для парсинга. А еще интересные задачи для практики (вот тут-то точно пригодятся бонусы).
Расширения PostgreSQL — самые полезные с объяснением, как применять их без лишней теории.
Docker — что такое Docker, как запускать контейнеры, собирать образы и использовать Docker Compose. А еще — чем технология отличается от Kubernetes.
Сети — научитесь настраивать базовые сетевые схемы, поднимать выделенные и облачные серверы, разбираться в связанности, публичных IP и облачных маршрутизаторах.
Кстати, все статьи в подборках, как обычно, полностью бесплатны и доступны без регистрации и вот этого всего. Читайте, узнавайте новое и практикуйтесь бесплатно.
Работа с векторами, временными рядами и геоданными в PostgreSQL требует специальных расширений. И мы наконец их добавили.
Теперь можно создать кластер с pgVector, PostGis и TimescaleDB. Дополнительно появилась возможность управления локалями и некоторыми другими параметрами.
Подборка бесплатных обучающих материалов о PostgreSQL
Привет, Хабр! Новая пятница — новая порция обучающих статей. Сегодня собрал публикации, которые помогут тем, кто хочет лучше разобраться в PostgreSQL. По классике: все бесплатно. Чтобы прочитать подборки, даже регистрироваться нигде не нужно. Бонусом в конце поста будет ссылка на курс. Он тоже не стоит ни копейки, но там все же нужно зарегистрироваться. Итак, поехали.
PostgreSQL для новичков
В подборке 14 статей на два с половиной часа чтения. Здесь база: установка и настройка PostgreSQL, нюансы управления, резервного копирования и репликации. Для ленивых — что делать, если администрировать самим БД не хочется.
Средний уровень
В девяти статьях за полтора с небольшим часа рассматриваем настройку PostgreSQL в Docker и для работы с 1С. Вы разберетесь в командах, триггерах, индексах и организации мониторинга.
PostgreSQL на максималках: практикум по расширениям
Пять статей и чуть больше часа на их изучение. Эта подборка — ваш гид по расширениям PostgreSQL: от безопасности и оптимизации до работы с геоданными. Вы познакомитесь со всеми этими pgcrypto, jsquery и т. д., а заодно научитесь применять их без лишней теории.
Бонус. Бесплатный онлайн-курс для новичков «Погружение в PostgreSQL»
В семи уроках вы освоите основы SQL, научитесь создавать и связывать таблицы, выполнять базовые операции с данными. Эти знания станут хорошим стартом для дальнейшего изучения PostgreSQL. Курс подойдет начинающим администраторам баз данных, разработчикам, DevOps-инженерам и аналитикам.
Митап от разработчика СУБД Tantor Postgres и машин баз данных Tantor XData пройдет в Москве. Это отличный повод встретиться для всех, кто интересуется развитием российских СУБД и будущим сферы управления корпоративными данными.
Новая версия платформы Tantor — ведущего enterprise-решения для администрирования и мониторинга любых БД на основе PostgreSQL;
Новинки СУБД Tantor Postgres для более высокой производительности и защищённости данных;
Инструментарий для управления интеграциями и загрузкой данных, осуществления миграций с минимумом даунтайма;
Особое внимание будет уделено Tantor XData — первой российской машине баз данных от вендора СУБД, созданной для самых сложных промышленных задач, высоконагруженных защищённых систем и крупномасштабной аналитики в стратегически важных отраслях.
Митап пройдет 19 сентября 2025 г. на 40-м этаже башни Mercury Space по адресу: Москва, 1-й Красногвардейский проезд, 15. Регистрация участников стартует в 12.00.
Вебинар «Low-code разработка на PostgreSQL с XSQUARE»
16 сентября в 17:00 мы проведем вебинар о том, как упростить и ускорить разработку приложений с помощью low-code платформы XSQUARE и PostgreSQL.
Что будет
🔹 Создание приложения за 5 минут. 🔹 Онлайн-таблицы (Google Sheets/Excel) на базе PostgreSQL. 🔹 Превращение PostgreSQL в REST API. 🔹 Импортозамещение Oracle Apex, Forms, MS SQL.
Вебинар будет полезен разработчикам, администраторам и аналитикам. Участие бесплатное, нужна только регистрация.
🎙 Спикеры
Константин Ващенков (CTO XSQUARE) Станислав Погоржельский (технологический евангелист VK Cloud)
Как мы выиграли ProcessTech 2025 с проектом TechSupport 360
В начале сентября Блок ИТ Страхового Дома ВСК, получил награду «Лучший пилотный проект» на премии ProcessTech 2025. Наш проект TechSupport 360 занял первое место в номинации — и мы хотим поделиться, как всего за 4,5 месяца удалось пройти путь от гипотез до результата, который оценили бизнес-заказчики, ИТ-команды и жюри конкурса.
С чего всё началось В начале 2025 года мы поставили себе задачу: проверить, как технологии Process Mining и BI-аналитики могут изменить работу ИТ-поддержки и эксплуатации. Так родился пилотный проект TechSupport 360.
Мы сформулировали три гипотезы:
Process Mining для SLA
Оцифровать карты ИТ-процессов (каталог — 1432 услуги).
Найти избыточные нормативы SLA.
Сократить время решения без потери качества.
Перезаключить SLA с бизнес-подразделениями на новых условиях.
BI-аналитика метрик
Автоматизировать подготовку отчетности по ИТ-поддержке и инфраструктуре.
Снять нагрузку с аналитиков.
Построить дашборды Proceset, позволяющие искать причины отклонений по принципу «от общего к частному».
Автоматизация KPI
Оцифровать и перевести в BI-формат 52 ключевых KPI Центра эксплуатации ИТ.
Как мы это делали Пилот длился всего четыре с половиной месяца — с января по май 2025 года. За это время удалось пройти полный цикл: от выработки гипотез и технических интеграций до демонстрации результатов топ-менеджменту и бизнес-заказчикам. В январе команда определила ключевые направления для проверки и закрепила три гипотезы: управление инцидентами, BI-аналитика ИТ-процессов и автоматизация KPI. Параллельно аналитики прошли самообучение работе с инструментами Proceset и настроили интеграции с системами — Jira Service Desk, Zabbix, vROps и внутренними утилитами. В феврале мы собрали и подготовили массивы данных, разработали техническое задание и методологию для проверки гипотез. Именно на этом этапе началась активная работа с SQL и REST API для подготовки расчетов и моделей. Март стал переломным месяцем: появились первые результаты по всем трем гипотезам. Карты процессов были построены и согласованы с владельцами, первые BI-дашборды прошли апробацию на рабочих группах, а KPI начали отображаться в автоматическом режиме. В апреле мы вынесли итоги пилота на обсуждение с бизнес-заказчиками и топ-менеджментом: Proceset показал свою эффективность, а команды получили прозрачный инструмент для поиска узких мест и принятия решений. Финальной точкой стал май: мы запустили переподписание SLA-соглашений с бизнес-блоками, включили результаты работы в PI-планирование по SAFe и подготовились к выступлению на ProcessTech.
Что получилось
Гипотеза 1. SLA и инциденты
Построены карты 1432 процессов.
Оптимизированы нормативы SLA в 356 процессах (дельта: от 12 до 2 часов).
100% SLA-соглашений переподписаны с бизнес-блоками.
В Proceset разработан калькулятор прогнозных SLA для управления ожиданиями.
Гипотеза 2. BI-аналитика
Автоматизированы 105 метрик (75 по ИТ-поддержке, 30 по инфраструктуре).
Разработан 21 BI-дашборд.
Высвобождено 2048 чел.-часов в год (подготовка отчетности).
В 7 раз ускорено получение данных (с раз в неделю до ежедневного).
Review-сессии и рабочие группы теперь проходят без PowerPoint и Excel — сразу в BI.
Гипотеза 3. KPI
Автоматизированы 52 KPI Центра эксплуатации ИТ.
Высвобождено 315 чел.-часов в год на подготовку.
Почему проект оказался «лучшим пилотом» Пилот показал, что можно изменить мышление внутри ИТ-команд. Если раньше аналитика процессов велась преимущественно в Excel, то теперь Proceset стал целевым инструментом для review-сессий и планерок. Это не только ускорило работу, но и дало общий язык для обсуждения метрик и показателей. В совокупности эти факторы и сделали TechSupport 360 «лучшим пилотом»!
Для нас эта награда — не финиш, а подтверждение того, что цифровая аналитика ИТ-процессов — рабочий инструмент, который помогает делать сервис для бизнеса быстрее, прозрачнее и удобнее.
Лутаем Open Source #24. Они наконец-то починили MongoDB! Перенеся его на PostgreSQL...
DocumentDB – БД от Microsoft, которая состоит из 3-х частей:
PG расширение, добавляющее BSON формат (написанный, на С)
CRUD API поверх него (С)
Сервис трансляции Mongo Query в SQL (Rust)
GitHub - documentdb/documentdb: MongoDB-compatible database engine for cloud-native and open-source workloads. Built for scalability, performance, and developer productivity.
И вроде как: "PG – классная база, а MongoDB Query + BSON популярные технологии" – и можно было бы поразмышлять чем это круто, но сначала важно ответить на один туманный вопрос: "кому такая БД может быть нужна?"
Классический PG
Сначала рассмотрим кейс, когда мы накладываем DocumentDB на обычный PostgreSQL.
Те, кто используют MongoDB если попробуют переехать на такой сэтап столкутся с тем, что:
Там нет шардинга (и насколько бы он не был сложно реализован в MongoDB, он есть и им активно пользуются)
Придется использовать двойной тулинг: Compas, чтобы наблюдать за корректностью данных с MongoDB Query, и SQL если надо посмотреть что там внутри
MongoDB поддерживает Uncommitted Read и Write Majority, что странно накладывается на PG: если разраб достаточно продвинутый и намеренно использовал Uncommitted, то с PG он потеряет скорость и Availability из-за PG Committed, а если он использовал Write Majority, то PG не совсем дает такую гарантию (обвал диска при WAL репликации – менее надежен, чем Write Majority)
А самое главное: когда ты работаешь с MongoDB ты можешь открывать 1000 коннекшенов и он вполне себе все это сожрет, потому что (1) коннекшен это тред, (2) при запросах нет никакой проверки реляционной целостности, да и в целом проверка сильно проще, чем в PG, а значит придется потанцевать с пуллерами и даже менять где-то запросы, чтобы не упасть по скорости
То есть, у mongo-юзеров это заберет все особенные фичи MongoDB и при этом не даст фишки PostgreSQL.
Distributed PG-like
А что, если мы положим DocumentDB на что-нибудь из серии CockroachDB, YugabyteDB, AWS Aurora, Citus или Neon?
Все 3 проблемы решаются:
Шардинг из коробки
Достаточно высокая скорость записи и чтения
Отсутствие проблем с коннектами
В такой ситуации DocumentDB начинает играть новыми красками.
Но если в Neon и Citus (и может YugabyteDB) еще есть шанс добавить текущий DocumentDB BSON плагин, то в для других представителей придется писать его с нуля (причем под каждый свой, потому что они построены каждый на своем KV хранилище).
Переезд в Linux Foundation
А еще они сейчас в процессе переезда из Microsoft в Linux Foundation, из плюсов они будут полностью под MIT лицензией и пейвола, за который будут прятать полезные фичи, из минусов, Microsoft могут и забросить, а никто другой не подхватить.
Итоги
Неоднозначная технология, пока имеет смысл в каких-то тонких кейсах, но в общем и целом, не вижу пока где тут middle-ground, может, вы что-то подскажете?
