Базы данных *

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

Ответ на эти вопросы всё чаще звучит в двух буквах – ИИ. Искусственный интеллект, в частности ИИ-агенты, предлагает новый уровень автоматизации бизнес-процессов. 

Эксперт Postgres Professional Андрей Зубков «нырнул» в глубины VACUUM и выяснил, что детализированная статистика может выявить глубинные проблемы, которые критически влияют на производительность. Расскажем о том, что скрывалось в глубине PostgreSQL

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

Я видел, что даже в среднем бизнесе решения принимаются на основании чуйки хозяина. Тогда как в entreprise решения принимаются на основании процедур, отчётов. Люди страдают и ненавидят этот процесс, так как много времени уходит на оцифровку. Но при этом корпорации довольно эффективны, что показал мой дальнейший опыт. Они работают на 4-ку, но стабильно. Малый бизнес может сегодня сработать на 5, а завтра на 2.

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

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

В этой статье я расскажу, как и кому может помочь аналитика данных.

Привет, Хабр! Я Станислав Габдулгазиев, архитектор департамента поддержки продаж Arenadata. В этой статье рассмотрим, как большое количество мелких файлов влияет на производительность различных систем хранения, таких как HDFS и объектные хранилища с S3 API.

Разберём, какие технологии хранения лучше всего подходят для работы с мелкими файлами в архитектурах Data Lake и Lakehouse. Сравним производительность HDFS и объектных хранилищ с S3 API. На конкретных тестах покажем, почему именно HDFS эффективнее справляется с большим количеством небольших файлов. Обсудим также случаи, когда мелкие файлы становятся не просто нежелательной ситуацией, а неизбежной необходимостью, например в подходах типа Change Data Capture (CDC).

Мы на Хабр Карьере помогаем IT-специалистам зарабатывать больше, а компаниям — быть в курсе трендов на рынке найма. 

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

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

Привет, Хабр! На связи Андрей Бородин, в Yandex Cloud я руковожу направлением разработки СУБД с открытым исходным кодом — и я попал в Яндекс через опенсорс. Я уже немного рассказывал, что и зачем мы делаем в опенсорсных БД с точки зрения облачных сервисов, где мы развиваем PostgreSQL, Greenplum, Cloudberry, Valkey и другие решения.

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

На масштабах Яндекса возникают нетривиальные задачи, которые интересно решать. А когда мы делимся решениями с сообществом, то можем получить от них новый взгляд на проблему, и продолжить совместную разработку новой фичи в удобном формате: с кем‑то на условиях независимого сотрудничества, а кого‑то можем позвать в команду (как это было и со мной).

В общем, если придерживаться опенсорс‑философии, может возникнуть ситуация win‑win. Сегодня с коллегами Леонидом Борчуком @leborchuk и Дмитрием Сарафанниковым расскажу пару историй про то, как это бывает с опенсорсными СУБД.

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

Внутристраничная очистка (HOT cleanup) — это оптимизация, благодаря которой старые версии строк могут эффективно удаляться из блоков таблиц. Освобождённое место используется под размещение новой версии строки. Освобождается только место, занимаемое версиями строк, вышедшими за горизонт базы данных (xmin horizon). В статье рассматривается алгоритм работы аналогичной оптимизации для индексов. Если горизонт удерживается, то ни внутристраничная очистка, ни вакуум не могут освободить место, и тогда новая версия строки вставляется в другой блок. Увидим на примере стандартного теста pgbench, как сильно может снижаться производительность при удержании горизонта базы данных (в случае когда есть сессия с долгим запросом или транзакцией) и разберемся в причинах снижения производительности.

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

Я, Михаил Герасимов, инженер РСХБ-Интех. Уже два года занимаюсь автоматизацией тестирования, и за это время успел написать (и переписать) немало SQL-запросов. Вместе с моим коллегой Михаилом Палыгой мы развиваем инструменты для автоматизированного тестирования, и сегодня расскажем вам о том как мы справляемся с построением сложных SQL-запросов и проверкой объектов в базе данных, на примере нашей библиотеки CheckMateDB для автоматизации тестирования банковской системы ЦФТ-Банк.

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

Мы создали иерархию классов CriteriaBasic и Table для удобного описания критериев поиска данных в базе, используя паттерн fluent interface. Также мы разработали кастомные классы проверок на базе AssertJ с поддержкой Allure-шагов, которые позволяют проверять сложные многоуровневые объекты с возможностью погружения во вложенные структуры. Для облегчения рутинной работы создали плагин, автоматически генерирующий классы DTO и Table на основе структуры базы данных. Библиотека интегрирована с Hibernate через DaoCommon, что обеспечивает удобное выполнение SQL-запросов и управление сессиями. Результатом стало существенное улучшение читаемости тестов, повышение переиспользуемости кода, стандартизация подхода к тестированию и создание информативных Allure-отчетов.

Если вы, как DBA устали тратить время на изучение статистики производительности, анализ логов и настройку разрозненных инструментов мониторинга при администрировании большого количества баз данных, то у нас есть решение — PPEM (Postgres Pro Enterprise Manager). Он объединяет возможности визуализации метрик, управления экземплярами и резервным копированием, анализ производительности в единую графическую консоль, позволяя локализовать проблему и быстро принять меры. Расскажем, как мы решали «головные боли» DBA по мониторингу и аналитике БД.

Привет, Хабр! На связи Давид Саргсян. Я занимаюсь системным анализом цифровых продуктов банка ПСБ.

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

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

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

PostgreSQL — одна из самых популярных СУБД, и это во многом благодаря открытому исходному коду. В статье рассказывается о том, как открытость кода влияет на развитие PostgreSQL и создание сообщества вокруг неё.

Рассмотрим, как реализован SortMergeJoin в Apache Spark, и заодно заглянем в исходный код на GitHub. Spark написан на языке Scala, и вся логика работы оператора доступна в открытом репозитории проекта.

Как преподаватель, могу сказать, что студентам непросто бывает привести базу данных к какому‑то осмысленному виду (не говоря уже про третью нормальную форму). Во‑первых, нередко «всё связано со всем», во‑вторых, в мало‑мальски сложной (в смысле, комплексной) задаче бывает трудно правильно спроектировать таблицы (то есть определить, какие таблицы должны быть в базе, как они должны быть связаны друг с другом, где и какая информация должна в них храниться). Помогает ли им в этом теория? И да, и нет. Дело в том, что нормализация данных говорит о желаемом виде каждой таблицы, и, преобразуя отдельно взятую таблицу к нормальной форме, мы также что‑то делаем со всей базой данных (добавляем новые таблицы, перемещаем между ними поля, и так далее) — это как сборка кубика Рубика. Второй проблемой здесь является то, что даже база данных, состоящая из единственной таблицы, не приведенной к первой нормальной форме, внезапно, тоже будет работать — криво‑косо, но будет! Теория — штука хорошая, но кое‑чего ей не хватает, а именно — задания точки отсчёта. Ведь для того, чтобы пройти к библиотеке третьей нормальной форме, для начала нужно понимать, где мы находимся.

При нагрузочном тестировании баз данных Tantor Postgres или других на базе PostgreSQL с использованием стандартного инструмента pgbench отсутствие фиксации деталей окружения (таких как конфигурация СУБД, характеристики сервера, версии ПО) часто приводит к нерепрезентативным результатам и необходимости повторных тестов. В статье рассматривается разработанный автором инструмент pg_perfbench, который призван решить эту проблему.

Привет! Меня зовут Влад Божьев, я старший разработчик юнита АБ-тестирования Авито. Один из наших ключевых инструментов – M42, сервис для визуализации метрик. Он позволяет быстро проверять гипотезы, анализировать отклонения и оценивать инициативы.

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

В нашем семантическом слое данных больше  20 000 метрик, и есть десятки разрезов для каждой из них. Под катом рассказываю, как мы храним терабайты данных и автоматизируем добавление новых разрезов в отчёт M42.

Любой, кто хоть раз пытался «по-быстрому» проанализировать CSV-файл или прототип БД, сталкивался с выбором из неудобств: открывать в Excel, запускать Jupyter, возиться с pandas, или поднимать Postgres/ClickHouse ради пары запросов. Мне показалось странным, что в 2025 году до сих пор нет удобной zero-setup SQL-песочницы для локальных данных.

Так родился PondPilot - open-source инструмент для анализа данных, работающий прямо в браузере, без серверов и настройки.