Базы данных *

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

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

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

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

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

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

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

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

Prometheus прекрасно подходит для краткосрочного мониторинга, но у этого решения есть свои ограничения по масштабу, и если вы столкнулись с высоким потреблением памяти/CPU, снижением скорости запросов или вам требуются уникальные лейблы вида user ID, то стоит подумать над внедрением альтернатив. На наш взгляд следующими после Prometheus в линейке стоят Thanos, Cortex, Mimir или VictoriaMetrics. Объективное, насколько это возможно, сравнение характеристик этих решений мы и проведем ниже.

СОДЕРЖАНИЕ

• 3.1. Что важнее: простота или масштаб?
• 3.2. Стоимость
• 3.3. Надёжность и высокая доступность
• 3.4. Насколько подходит по задачам?

• 6.1. Параллельный запуск и проверка
• 6.2. Мониторинг очередей remote_write
• 6.3. Аккуратное отключение Prometheus
• 6.4. Резервное копирование
• 6.5. Тестирование

• 10.1 Используйте recording rules для тяжёлых агрегаций
• 10.2 Не злоупотребляйте лейблами с высокой кардинальностью
• 10.3 Downsample старые точки данных
• 10.4 Осторожно с федерацией Prometheus

Привет! Я Андрей Сташок, бэкенд-разработчик в KTS. В этой статье я расскажу о запуске параллельных тестов через pytest-xdist.

Почему это важно?

Объясню на нашем примере. При разработке продуктов мы постоянно выполняем юнит-тестирование. Раньше мы проверяли все последовательно, и с расширением тестовой базы время проведения испытаний заметно возрастало. Распараллеливание через pytest-xdist помогло нам сильно ускориться, и сегодня я хочу поделиться этим трюком с вами.

Я расскажу, как запускать параллельные тесты для реляционной БД PostgreSQL (с драйверами asyncpg и psycopg2) и key-value БД Redis. Для подключения к реляционной БД мы будем использовать SQLAlchemy, а для Redis — библиотеку redis. Кроме того, я рассмотрю, как автоматизировать выполнение миграций при каждом запуске тестов с использованием alembic.

Больше года назад мы в LEADS.SU задумались над высокодоступностью нашей БД и начали искать различные варианты. Круг решений сужало то, что мы используем TokuDB, который уже не поддерживается. Вариантов было несколько, но точно было понятно что запуск кластера повлечет за собой полное клонирование файлов /var/lib/mysql, к тому моменту размер этой директории уже перевалил за пару сотен гигабайт и мы задумались над ревизией данных, что привело к долгоиграющему процессу по уменьшению размера БД.

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

Если в таблицах БД PostgreSQL есть поля большого размера, при выгрузке часть строк таких таблиц может не выгружаться с выдачей ошибки ERROR: out of memory. Столкнуться с подобной ситуацией можно, например, при выгрузке утилитой pg_dump таблиц, в которых хранятся XML-документы, или при выгрузке таблицы public.config системы «1C:Предприятие». В статье рассматриваются причины возникновения подобных ошибок и способы решения проблемы.

Способность открытых LLM шутить, причем по-доброму, могла бы расширить применение ИИ во многих сферах – образовании, терапии, обслуживании клиентов. Так что мы с коллегами из Лаборатории естественного языка НИУ ВШЭ задались этим вопросом и попытались разработать собственную методологию курирования (фильтрации и аннотирования) наборов данных для генерации доброго юмора на малых LM. По всем научным канонам мы ее описали и оценили в этом препринте. А здесь я постараюсь рассказать о ней чуть короче и менее научно.

Когда в проекте используется составной B-tree индекс, важно не просто "создать индекс", а сделать это правильно — иначе запросы могут не только не ускориться, но и начать работать медленнее. Возникает логичный вопрос: как выбрать порядок колонок, чтобы индекс действительно работал эффективно? Брутфорсом? По интуиции? По селективности?

В этой статье я расскажу, как подходить к построению составных индексов в PostgreSQL, на что реально влияет порядок колонок. Также разберём простое правило ESR, которое помогает упростить выбор и получать стабильный прирост производительности на всех стендах.

В арсенале Postgres Pro есть мощное, но порой недооцененное оружие — декларативное секционирование. Оно только звучит сложно, а на деле позволяет элегантно «нарезать» гигантские таблицы, превращая их из неповоротливых монстров в управляемые и быстрые структуры. Делимся нетайными знаниями, которые помогут оптимизировать запросы и упростить жизнь. 

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

В этой статье рассмотрим классическую проблему «мягкого удаления» на уровне схемы баз данных и её влияние на аналитику.

Почти в каждой системе встречается требование «не удалять данные окончательно».

Всем привет! Меня зовут Илья Криволапов, тружусь системным аналитиком в SENSE на проекте одного из цветных банков РФ. В профессии я уже пятый год и, несмотря на фамилию, ломал прод всего лишь несколько незначительных раз (надеюсь). 

На досуге я преподаю в университете дисциплину «Хранение и обработка больших объемов данных» и за все время у меня накопилось много полезной информации. Непростительно хранить такой клад у себя в столе, поэтому я подготовил для читателей Хабра ультимативный гайд по оптимизации или хорошему такому, грамотному проектированию баз данных с расчетом на масштабирование.

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

Кому будет полезно? Всем отвечающим за «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам. 

Согласны? Узнали? Тогда поехали!

Один из игроков — я, Кирилл Красновид, тимлид BI-команды в Профи.ру. Наша задача — делать так, чтобы каждый быстро и удобно получал нужную информацию без лишней суеты и ожиданий. 

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

ScyllaDB — это высокопроизводительная распределённая NoSQL-база данных, совместимая с Apache Cassandra, но в разы более быстрая за счет того, что написана на C++. Однако, несмотря на сверхбыструю скорость работы, можно ли сделать ее еще быстрее?

В современных компаниях корпоративные хранилища данных (Data Warehouse) играют критически важную роль, обеспечивая централизованное хранение и обработку больших объёмов информации. Данные поступают из разнообразных источников: операционных систем, CRM, ERP, IoT-устройств, веб-аналитики, мобильных приложений и других платформ, отражая все аспекты деятельности организации. На основе этой информации компании формируют разного рода отчётность, отслеживают ключевые показатели эффективности (KPI), оптимизируют бизнес-процессы, прогнозируют рыночные тенденции и принимают стратегические решения.

Эффективная работа с хранилищем невозможна без участия бизнес- и системных аналитиков, которые проектируют структуры данных, очищают и объединяют информацию, адаптируя решения под меняющиеся задачи. С ростом объёмов данных и требований к скорости анализа даже опытные команды сталкиваются с вызовами. Рутинные операции — проектирование схем, поиск таблиц, проверка качества данных — требуют не только технических навыков, но и глубокого понимания бизнес-контекста. Большую часть времени занимает написание и оптимизация SQL-запросов, что становится «узким местом» в условиях динамично меняющихся требований.

Ошибки в SQL-запросах или недостаточное знание структуры данных приводит к потерям времени и снижению точности аналитики. Для решения этих проблем на помощь приходят технологии на основе больших языковых моделей (LLM), таких как GigaChat, GPT, BERT или DeepSeek. Обученные на исторических данных и журналах запросов, они способны автоматизировать подбор таблиц, JOIN-условий и шаблонов SQL. 

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

Один параметр PostgreSQL может похоронить вашу производительность, если вы о нём забудете — это fillfactor. Почему однократная настройка числа приводит к неожиданным page split, bloat и мучительному откату запросов? Давайте разбираться.