В арсенале Postgres Pro есть мощное, но порой недооцененное оружие — декларативное секционирование. Оно только звучит сложно, а на деле позволяет элегантно «нарезать» гигантские таблицы, превращая их из неповоротливых монстров в управляемые и быстрые структуры. Делимся нетайными знаниями, которые помогут оптимизировать запросы и упростить жизнь.
Привет, Хабр!
В этой статье рассмотрим классическую проблему «мягкого удаления» на уровне схемы баз данных и её влияние на аналитику.
Почти в каждой системе встречается требование «не удалять данные окончательно».
Асинхронность в JavaScript, где и как использовать в web разработке на frontend и backend. Цепочка промисов и их параллельные выполнение.
Всем привет! Меня зовут Илья Криволапов, тружусь системным аналитиком в SENSE на проекте одного из цветных банков РФ. В профессии я уже пятый год и, несмотря на фамилию, ломал прод всего лишь несколько незначительных раз (надеюсь).
На досуге я преподаю в университете дисциплину «Хранение и обработка больших объемов данных» и за все время у меня накопилось много полезной информации. Непростительно хранить такой клад у себя в столе, поэтому я подготовил для читателей Хабра ультимативный гайд по оптимизации или хорошему такому, грамотному проектированию баз данных с расчетом на масштабирование.
Всего в цикле будет 3 статьи. В первой поговорим о двух разных подходах масштабирования БД и о том, как лучше его делать и как лучше не делать (Никогда. Пожалуйста).
Кому будет полезно? Всем отвечающим за «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам.
Согласны? Узнали? Тогда поехали!
PGConf.Russia 2025 прошла в месте историческом: в Центре Международной Торговли. История её короткая, но эффектная: построили в конце 70-х, ЦМТ был сначала Совинцентром, потом «Хаммеровским центром» - это было в то время такое окно в Европу. Через окно входили и выходили технологии и бизнес. Скульптура Меркурия перед фасадом мелькала тогда то и дело в новостях. Бизнес, судя, например, по машинам на парковке, это здание (комплекс зданий) отнюдь не позабыл. Хотел написать (и, как видите, написал) круче только в Кремлёвском Дворце Съездов эту конференцию провести, но и не так, и КДС тут не при чём. Но я был впечатлён и вспоминал с некоторыми коллегами былые технологические события, проходившие здесь во времена, когда таких мест было раз два и обчёлся, а может и раз - без два.
Привет, Хабр!
Один параметр PostgreSQL может похоронить вашу производительность, если вы о нём забудете — это fillfactor. Почему однократная настройка числа приводит к неожиданным page split, bloat и мучительному откату запросов? Давайте разбираться.
Эта история началась с шутки на офисной кухне 10 декабря, но, как водится, у каждой приличной шутки, она вдруг стала интересной для воплощения, а в конце переросла в не самую технически простую реализацию с хождением по многочисленным граблям.
А началось всё просто: пока все вокруг спорят как настраивать железо и тюнить операционные системы дабы выжать лишних TPS, мы решили проверить как отреагирует движок PostgreSQL если загрузить в него действительно большой объём данных. Например, давайте сделаем базу размером один петабайт и посмотрим как он это переживёт.
На дворе было 10 декабря, руководство поставило задачу сдать отчёт 20 января, до нового года оставалось меньше месяца, а в руках появился знакомый всем инженерам зуд.
Шардирование, двухфазный коммит и распределенные транзакции окружены определенными мифами и заблуждениями. Например, может быть достаточно неочевидно, что двухфазный коммит обеспечивает только атомарность транзакций, но не их изоляцию. Поэтому мы решили написать пост, который бы помог разобраться в этих сложных вещах и сделать правильный выбор, когда Postgres'а Вам станет мало и Вы столкнётесь с шардированием.
Привет, меня зовут Костя Осипов, и я занимаюсь разработкой СУБД. На Хабре есть несколько моих статей про MySQL, Tarantool и про всякое-разное. Кроме того, я веду Telegram-канал, где делюсь инсайтами в области управления базами данных. Сегодня я выступаю в роли основателя компании Picodata, создающей одноимённую открытую СУБД, и управляющего директора ПАО Arenadata по исследованиям и разработке. Ниже — вольный пересказ моего недавнего доклада на HighLoad. Он про то, что нас ждёт в мире СУБД завтра, и, в частности, про место резидентных СУБД в архитектурах будущего.
Greenmask — это кроссплатформенный инструмент, разработанный на Go специально для безопасной работы с данными PostgreSQL: он помогает делать логические бэкапы, восстанавливать таблицы и при необходимости — анонимизировать чувствительную информацию. Главное преимущество Greenmask — полная совместимость с pg_dump и pg_restore. То есть, если вы уже работаете с этими инструментами, интеграция Greenmask не потребует пересмотра всей инфраструктуры.
Один из ключевых сценариев использования утилиты - подготовка баз данных для тестового стенда. Greenmask позволяет упростить процесс дампа продуктивных баз, обработки их для анонимизации тех же персональных данных, снижения размера баз (в тестовой среде зачастую не нужны терабайты данных с прода), восстановления дампов в тестовый контур.
Ниже в статье я опишу базовый функционал, примеры конфигураций для начала работы с Greenmask, а так же рассмотрим примеры трансформации данных при дампе таблиц.
Официальный сайт: https://greenmask.io
Документация: https://docs.greenmask.io/latest/
GitHub-репозиторий: https://github.com/GreenmaskIO/greenmask (уже 1308 звезд)
Telegram-канал: https://t.me/greenmask_ru
Коннекты обычно не приносят много головной боли на начальных этапах разработки. Вообще работа с ними обычно делается один раз, во время настройки, и дальше тюнится по необходимости. Но эта необходимость возникает часто в виде непонятных ошибок, которые выкидываются в случайных местах, непонятных графиков в графане и суеты админов вашей базы данных. Я постарался собрать ту информацию, которая позволит вам не потеряться в такой ситуации и даже поможет определить суть проблемы.
Задачи на собеседованиях. Денежные переводы в SQL. Обновление счетов и уровни изоляций
Задача перевода денег в первом приближении сводится к обновлению пары строк и кажется простой — но обеспечение корректности при параллельном доступе может быть неожиданно сложным для только знакомящихся с уровнями изоляций БД.
В статье обзор пяти докладов прошедшей в апреле 2025 года конференции PgBootcamp. Даже на тех конференциях, которые я посещал, мне было бы интересно почитать обзор докладов, но я их не встречал. Иногда можно найти статью к докладу, но для большинства докладов на конференциях такого формата нет. По какой-то причине, обзоры докладов с конференций - редкость. Я решил написать обзор, возможно он окажется полезен.
Доклады конференции PgBootcamp недавно выложили в общий доступ и их можно скачать и посмотреть.
Введение
Доклады конференций полезны тем, что содержат описание того, что актуально при работе с PostgreSQL. Организаторы выбирают наиболее интересные доклады и не пропускают то, что уже всем известно.
О конференции PgConf я знал давно, а о конференции PgBootcamp я узнал год назад. За это время прошли три конференции: в Казани, Минске и Екатеринбурге. Архив докладов есть на сайте pgbootcamp.ru (регистрироваться на сайте не нужно, в "Программе" - список докладов, внизу каждого доклада ссылка на видеозапись доклада).
Перед очередной конференцией можно бесплатно зарегистрироваться онлайн и оффлайн, она однодневная и проходит параллельно в двух залах. Регистрация на конференции полезна тем, что, что присылается ссылка на трансляцию и запись можно просматривать во время и сразу после окончания конференции. Без регистрации доклады становятся доступны только через 2-3 недели.
Большие языковые модели (Large Language Model, LLM) используют в разных областях: с их помощью генерируют программный код, ищут информацию, озвучивают реплики чат-ботов. А вот при работе с реляционными данными языковые модели часто ошибаются.
Чтобы справиться с этими ошибками, в мы разработали три пайплайна для работы с базами данных. Эти пайплайны представляют собой цепочку связанных между собой языковых моделей: каждая из них генерирует свой ответ, и следующая модель работает с ответом предыдущей. Таким образом мы получаем дополнительный контекст, и запрос к базе данных становится точнее.
Привет, Хабр!
Меня зовут Сергей Аладышев, работаю системным аналитиком на протяжении 10 лет, и в работе часто сталкиваюсь с задачами, в том числе типовыми, решения для которых выглядят понятными, но не всегда оптимальными, а главное затратными по времени.
Появляется непреодолимое желание их оптимизировать. Сегодня хочу обсудить похожую задачу: «поиск разрывов истории записей», она же: «поиск разрывов истории SCD2 в SQL». С задачей сталкивался несколько раз, но статей с её разбором не нашел, поэтому решил, что тема актуальна.
Началось все, как и всегда, с получения исчерпывающих требований от заказчика:
Привет, Хабр!
Сегодня поговорим про ретеншн — ту самую метрику, от которой часто пляшут все продуктовые команды. Вы знаете: «вернулся через 7 дней» (D7) — и сказано, что мы класс
Но на деле класс ломается, как только продукт усложняется. В этой статье рассмотрим, почему классический D7 retention не работает, как построить настоящие кривые удержания через когорты, в чём разница между recurring vs one-shot поведением, какие есть альтернативные метрики и сравним три метода.
Если ваш сервис рассчитан на миллиарды пользователей, то несомненно возникнет вопрос о масштабировании.
Ранее, автор уже рассмотрел способ масштабирования через партицирование. В данной статье рассмотрим шардирование сервиса Баланс дабы обеспечить его работу с миллиардами пользователей без необходимости использовать суперкомпьютеры, а при желании вовсе запускать на "кофеварках".
Сегодня я хочу затронуть тему дополнительных ухищрений, которые могут позволить ускорить выполнение запроса. В данном случае речь пойдёт о перестановке условий в выражениях фильтрации, JOIN'ов, HAVING-клаузах и прочем. Идея заключается в том, что получив негативный результат в одном условии из цепочки выражений, объединенных оператором AND, равно как позитивный результат в одном из условий, объединённых оператором OR, можно не вычислять все последующие и сэкономить вычислительный ресурс. Что это даёт и как конкретно реализовать - об этом ниже.
Каждый, кто работает с PostgreSQL, знает его символ — синего слона. Но задумывались ли вы, откуда он взялся? Его история — это не результат работы дорогого брендингового агентства, а захватывающее повествование о зарождении IT-сообщества, питерских энтузиастах, случайных файлах и том, как «маленький презент» стал мировым символом.
