Базы данных *

«Поднятие» унаследованного Postgres без специнструментов быстро превращается в головную боль: вас ждет ручной разбор схем, перелопачивание десятков таблиц и прочая невеселая археология - где лежат персональные данные, что за колонки, как это всё соотносится с 152-ФЗ… Один неверный шаг – и можно запросто упустить что-то важное. Встроенного защитного преобразования данных на диске нет, приходится либо городить огород на уровне приложений, либо создавать триггеры. Хранить ключи, тестировать производительность, поддерживать это всё, руками выставлять фильтры, думать, куда писать логи, как следить за аномалиями и так далее. Всё, что связано с безопасностью – проверять вручную. Любое изменение схемы — снова садись и аудируй заново. Времени уходить будет очень много, и неизвестно, какие грабли вылезут.

В СУБД Tantor Certified то, что обычно делается на коленке, превращается в понятный и безопасный процесс, который подробно описывается в статье.

В этой статье мы разберём, как PostgreSQL обрабатывает запросы, изучим работу планировщика запросов и освоим анализ отчётов EXPLAIN ANALYZE — важнейшего инструмента оптимизации запросов. Эти знания помогут вам находить и устранять узкие места в производительности, оптимизировать запросы и предотвращать проблемы, из-за которых СУБД может работать медленнее.

Салют, Хабр!

Я Паша, вхожу в группу обеспечения производительности интерфейсов. Эту статью мы написали с Сергеем @TrueNort — руководителем группы. В SberDevices её называют командой «Скорость». Под надзором «Скорости» более двадцати веб-сервисов, каждый из которых должен работать быстро и точно. А значит, нужна система мониторинга производительности с гибкими настройками, чуткой реакцией на изменения и оперативными сообщениями о проблемах.  

В статье расскажем, зачем мы нормируем метрики логарифмами, как скрипт превращает данные из ClickHouse в алёрты и как удобнее отображать данные. Словом, поделимся нашим опытом контроля производительности веб-ресурсов.

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

Когда речь заходит об оптимизации базы данных, разработчики обычно перечисляют привычный набор приёмов: слегка переписать запрос, накинуть индекс на колонку, денормализовать, сделать analyze, vacuum, cluster, и так по кругу. Классические техники, конечно, работают, но иногда креативный подход даёт гораздо больше.

В этой статье Haki Benita показывает нетипичные техники оптимизации в PostgreSQL.

Привет, Хабр! Меня зовут Александр, я DevRel команды Selena Lakehouse. Пишу про СУБД StarRocks, архитектуры Lakehouse и Streamhouse в Telegram-канале @starrocks_selena (https://t.me/starrocks_selena).

Полгода назад термин Streamhouse начал всплывать на конференциях и в блогах. При этом многие русскоязычные источники, которые я читал, сводят его к «замене Iceberg на Paimon и обновлению Flink» или путают с обычным Lakehouse. На самом деле за Streamhouse стоит интересная архитектурная логика. Конкретный набор компонентов, где каждый решает свою задачу: Apache Flink для вычислений, Apache Fluss как горячий потоковый слой, Apache Paimon как холодное хранилище. Вместе они дают потоковый Lakehouse с задержкой в секунды вместо минут.

Мне стало интересно: можно ли на этом стеке построить полноценный аналитический конвейер? Не на слайдах, а руками в Docker Compose, с SQL и реальным сценарием.

В этой статье:

ClickHouse быстрый. Настолько быстрый, что первые полгода можно жить без оптимизаций вообще — агрегации по миллиарду строк отрабатывают за секунды. Потом данных становится больше, запросов тоже, дашборд начинает подтормаживать, и вы задумываетесь: «а можно ли считать агрегаты заранее?»

Можно. В ClickHouse для этого есть два механизма: materialized views и проекции (projections). Оба пересчитывают данные на этапе вставки. Оба ускоряют чтение. Но работают по-разному.

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

вот пример:

SELECT
price * quantity AS total_price,
(price * quantity) * 0.15 AS tax,
((price * quantity) + ((price * quantity) * 0.15)) AS grand_total
...

Здесь price * quantity вычисляется несколько раз, и tax вычисляется дважды. Но это выглядит еще ок, в реальности это зачастую всякие монструозные свитч-кейсы с NULLIF, COALESCE и прочими ребятами.

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

Long story short, это делается так:

Data Mesh, Data Fabric, Lakehouse: разбираем модные термины

Data Mesh, Fabric, Lakehouse – все говорят, но никто толком не объясняет, чем они отличаются и можно ли их использовать вместе. Разобралась и делюсь структурированно и без воды.

➕ Сравнительная таблица и чек-лист: что выбрать под свою боль.

✔️Сохраняйте, чтобы больше никогда не путаться.

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

О том, как архивисты и программисты десятилетиями искали выход из этой ситуации, и как цифра меняет основы архивного дела рассказывает германский архивист Кристиан Кайтель. С его разрешения (и благословения издательства) мы публикуем отрывок из его книги «Двенадцать путей в архив. Контуры открытого и прикладного архивоведения».

Keitel C. Zwölf Wege ins Archiv. Umrisse einer offenen und praktischen Archivwissenschaft. Stuttgart: Franz-Steiner-Verlag, 2018. S. 188-202. Перевел Никита Ломакин (телеграм-канал Архивный гик), редактировала Анастасия Тарасова.

Все мы прекрасно знаем, join – одна из самых важных вещей в любой базе данных, но в то же время одна из самых ресурсозатратных операций. Да что уж там, в мире аналитики (OLAP) десятилетиями адепты различных подходов моделирования данных все спорят без остановки что лучше: нормализация (то есть много join) или денормализация (то есть мало join). Но все понимают, если можно без join, лучше без. Проблема в том, что они нужны практически всегда.

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

Привет! Недавно мы с проектом (а по факту я в гордом одиночестве) переезжали с MySQL на PostgreSQL. Зачем? Проект — гео‑сервис для рыбаков: карта с точками, поиск рядом, фильтры по регионам, водоёмам и рыбам. MySQL стал тормозить на гео‑запросах, а PostGIS обещал скорость и порядок. Плюс мы всё равно переезжали на новый VDS – решили заодно сменить СУБД, пока данных не стало неприлично много.

Со мной опять произошла какая-то мистика.

С тех пор как начал писать  серию статей под названием «Пятьдесят лет по стезе программирования», особенно когда готовил третью статью, мне хотелось найти рукопись с исходными кодами, написанного мною транслятора с языка РПГ (RPG) для ЭВМ М-220:

Вечный конфликт: аналитики требуют свободы маневра, а DBA закрывают доступ к базе, опасаясь одного «убийственного» запроса, который положит весь кластер. В Postgres Professional мы разработали Tengri — систему, где каждый пользователь получает изолированные вычислительные ресурсы. Рассказываю, как архитектура индивидуальных вычислителей позволяет избежать конкуренции за ресурсы и почему после такого опыта возвращаться к общим очередям запросов уже не хочется.

Привет, Хабр! Меня зовут Игорь Березняк, и мы с командой делаем Техплатформу Городских сервисов Яндекса. Я уже писал на Хабре про архитектуру платформы, рассказывал на «Хайлоаде» (и на Хабре) про шардирование и миграцию на YDB.

Эта статья написана по мотивам последнего доклада. В ней я рассказываю не о самой миграции (ну мигрировали и мигрировали, этим сейчас никого не удивишь), а о её причинах.

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

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

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

Если вы уже используете Битрикс24, но вручную анализируете сделки через фильтры и стандартные отчеты, то теряете скорость и масштаб аналитики. В статье рассказываю, как встроенный BI-конструктор помогает собирать кастомные метрики без подключения внешних BI-платформ.

Привет, Хабр!

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

Краткое содержание первой серии части (гиперссылка) нашего мануала:

мы развернули двухузловой кластер MySQL с асинхронной репликацией по GTID, улучшенной полу-синхронностью, и добавили два уровня отказоустойчивости: на уровне сервиса IP и роли БД.

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

В начале января 2026 года стало известно, что проект Anna's Archive, основная цель которого — поиск и скачивание бесплатных пиратских книг и другого контента, теперь не контролирует свое основное доменное имя: оно было переведено в статус serverHold. Возможная причина такой ситуации — неоднократные и многочисленные претензии со стороны правообладателей.

📊 Хотите стать аналитиком данных, но не знаете, с какой стороны подойти?

Я собрала чек-лист для старта в 2026 году, никакой воды - только то, что реально спросят на собеседовании:
🛠 Что учить: SQL (с оконными функциями), Python (Pandas), BI-системы.
🧠 Важный софт-скилл, о котором молчат курсы — управление ожиданиями заказчика.
🔮 Бонус: что нужно знать про DWH и ML, чтобы выделяться среди других джунов.

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