В System Design нет «правильных» решений — только компромиссы. Бюджет, сроки, команда и законы диктуют, какие технологии выбрать, как масштабироваться и когда идти на жертвы. Разберём, почему определение бизнес-ограничений это важный этап System Design и почему они диктуют Айтишникам как и с чем работать.
Если на собеседовании по System Design не уделить внимание требованиям, это почти гарантированно приведёт к провалу — даже если ваше техническое решение идеально. Игнорирование требований — главная причина провала на собеседовании. Уделите этому 5-10 минут, и ваше решение сразу станет в разы сильнее. Расскажем, как собрать и зафиксировать требования чтобы повысить свои шансы при прохождении собеседования в IT-компанию.
Привет, Хабр!
Сегодня рассмотрим, как работает fillfactor в PostgreSQL — тот самый параметр, который никто не трогает, пока таблицы не начинают раздуваться как на дрожжах. Разберём, зачем он нужен, что происходит при UPDATE, когда стоит менять его вручную и как не наломать дров.
В статье рассматриваются особенности типов данных для хранения вещественных чисел в PostgreSQL.
Типы данных PostgreSQL для работы с вещественными числами:
1) float4, синоним real, синоним float(1..24)
2) float8, синоним float, синоним double precision, синоним float(25..53)
3) numeric синоним decimal. Диапазон для этого типа значительный: 131072 цифр до точки и 16383 цифр после точки. Но если при определении типа указать numeric(точность, масштаб), то максимальные значения точности и масштаба 1000. numeric можно объявить с отрицательным масштабом: значения могут округляться десятков, сотен, тысяч.
Кроме чисел и null поддерживаются значения Infinity, -Infinity, NaN.
Поля типов данных фиксированной длины не могут вытесняться в TOSAT-таблицу, переменной длины (numeric) могут.
float4 обеспечивает точность 6 разрядов (значащих чисел в десятичной системе счисления), float8 обеспечивает точность 15 разрядов. Последний разряд округляется:
Переезд крупных, высоконагруженных систем с одной СУБД на другую — всегда вызов, сравнимый с хирургической операцией на работающем сердце. Компания ОТР поделилась уникальным опытом миграции одной из таких систем с Oracle на отечественную Postgres Pro. Ирина Токарева и Сергей Кузнецов из ОТР рассказали о тернистом пути, противостоянии росту энтропии больших объёмов поступающих и изменяемых данных, достигнутых результатах.
Привет, Хабр! Мы продолжаем цикл статей о нововведениях СУБД Tantor Postgres 17.5.0, и сегодня поговорим о поддержке авторизации через OAuth 2.0 Device Authorization Flow — это современный и безопасный способ предоставления доступа, который позволяет приложениям запрашивать доступ к PostgreSQL от имени пользователя через внешнего провайдера идентификации и управления доступом, например Keycloak, что особенно удобно для облачных сред и микросервисных архитектур (функция будет также доступна в PostgreSQL 18). В статье пошагово разберём настройку OAuth-авторизации в PostgreSQL с использованием Keycloak: настроим Keycloak, подготовим PostgreSQL, напишем валидатор токенов OAuth в PostgreSQL и проверим успешную авторизацию через psql с использованием Device Flow.
Недавно вышла отличная книга PostgreSQL Mistakes and How to Avoid Them от Jimmy Angelakos — системного архитектора, практика и давнего участника сообщества PostgreSQL. Книга подробно разбирает распространённые ошибки, с которыми сталкиваются разработчики и администраторы при работе с PostgreSQL, и предлагает практичные решения: от тонкостей конфигурации и миграции до антипаттернов в SQL и выбора типов данных.
Я перевёл одну из ключевых глав этой книги — про неправильное использование типов данных. В ней подробно объясняется, почему, например:
timestamp without time zone может ломать логику расчёта интервалов;
money — это не то, чем кажется (и почему он опасен);
char(n) и varchar(n) не дают ожидаемой экономии и даже вредны;
serial — это прошлый век, а identity — настоящее.
Глава будет полезна всем, кто работает с PostgreSQL в проде — особенно backend-разработчикам, независимо от языка и фреймворка. Если вы проектируете схемы БД, пишете SQL-запросы или просто хотите избежать неприятных грабель — стоит прочитать.
Побывав на PGConf.DE’2025 и обсуждая там практику применения Postgres на больших базах данных, я к своему удивлению регулярно слышал мнение, что проблемой является время планирования запроса. Как разработчику, мне было странно узнать, что этот фактор может, например, тормозить принятие решения о переходе на партиционирование, что казалось бы естественный шаг, когда количество записей в таблице переваливает за сотню миллионов. Что ж, давайте разбираться.
Да что ж это делается? Хрустящие данные обратились снежинками, новый кирпичик данных стал неоновым, временная шкала обратилась в тигра и Xata переродилась
Два события заставили нас начать этот выпуск не с новостей о релизе. Snowflake купила Crunchy Data, а Data Bricks приобрела Neon. Что важнее, что сенсационней? Crunchy Data - компания-ветеран, Neon - стартап. Рыночная стоимость, однако, оказалась у стартапа в 4 раза больше. А тут и ещё 2 события (не столь сенсационных конечно). Но начнём с ветеранов.
Как мы построили DevOps в локальном облаке без AWS и managed-сервисов: GitLab CI, Kubernetes, PostgreSQL, мониторинг на Prometheus и Grafana. 10 000 TPS в пике, 12 минут на деплой, 2 минуты на восстановление — и всё это в проде.
pg_repack отличается от VACUUM FULL, какие особенности есть у каждого подхода и как использовать repack без дополнительных телодвижений. Статья будет полезна инженерам, поддерживающим PostgreSQL в продакшене, разработчикам облачных приложений и SaaS-сервисов и просто любопытным, кто стремится лучше понять, что происходит под капотом PostgreSQL в разных ситуациях. Погнали!
Мы продолжаем свое участие в международной олимпиаде «IT-Планета». Как и в прошлые годы, проводился конкурс по SQL, состоящий из трех этапов: теоретический и практический туры, проходящие онлайн, и финальный очный тур.
В первом туре участвовало свыше 4 500 человек, из которых 245 были отобраны во второй. В этом году я занимался разработкой задач и проведением первых двух туров. Предлагаю перейти к рассмотрению задач практического этапа.
Хабр, привет! В этой статье расскажем, как команда банка ВТБ построила собственную аналитическую систему на базе открытых технологий и с использованием решений Arenadata. Мы рассмотрим архитектуру платформы, разберём её сильные и слабые стороны, а также заглянем «под капот» — покажем, как устроены процессы внутри банка и почему ВТБ решил идти своим путём, а не использовать готовые вендорские системы.
Привет, Хабр!
В этой статье разбираем один из самых коварных способов убить базу — плохие JOIN'ы. Казалось бы, простое дело: связать пару таблиц — и вперёд. Но если в ON засунуть LOWER(email), забыть про индексы или перепутать LEFT JOIN с INNER — сервер мигом начнет дышать на ладан.
Пришло время заключительной статьи проекта Mireapay, в этой последней статье программы минимум автор расскажет о том, как шардировать сервисы и какие варианты возможны. Но что самое главное, как это сделать просто и не тратить лишнее время на разработку в дальнейшем.
pg_stat_statements — стандартное расширение PostgreSQL для сбора статистики выполнения SQL-запросов. Статистика позволяет анализировать поведение запросов во времени, выявлять проблемные участки и принимать обоснованные решения по оптимизации. Однако в системах с высокой конкуренцией pg_stat_statements само по себе может стать узким местом и вызывать просадки производительности. В этой статье разбираем, в каких сценариях расширение становится источником проблем, как устроено сэмплирование и в каких случаях его применение позволяет снизить накладные расходы.
Привет! На связи Дмитрий Руденко из команды Databases Т-Банка.
Благодаря обновленному мониторингу, команды стали чаще обращать внимание на на различные аспекты работы Postgres, так или иначе влияющие на общий перформанс сервиса.
Один из таких аспектов — процесс уборки мусора, — autovacuum, вычищающий мертвые версии строк таблиц. В статье рассмотрим причины возникновения одного из самых неприятных подвидов — autovacuum: to prevent wraparound.
В этой статье рассказываем о том, как мы решили проблему удаления брошенных файлов — файлов данных, которые не ассоциированы ни с одной из имеющихся в базе данных таблиц, но могут оставаться на файловой системе после аварийного завершения процессов.
Всем привет! На связи снова Илья Криволапов — системный аналитик в SENSE, где мы трудимся на проекте одного из цветных банков РФ. Работаю в профессии уже пятый год и, несмотря на мою фамилию, с продом у нас в целом тёплые отношения.
Помимо боевых задач, я преподаю курс «Хранение и обработка больших объемов данных» и за это время накопил немало практических кейсов и наблюдений. Всё это добро я решил не держать при себе и собрал самое полезное в виде ультимативного гайда по оптимизации и грамотному проектированию баз данных с расчетом на масштабирование, который сейчас публикую на Хабре.
Цикл состоит из 3 частей. В первой мы обсудили два базовых подхода к масштабированию БД: вертикальный и горизонтальный. Поговорили о плюсах, минусах и о том, как делать точно не стоит.
Во второй части – то есть сейчас – мы нырнём глубже в мир горизонтального масштабирования и разберем три первых способа шардирования: по диапазону, по хэшу и по географическим зонам. Я расскажу, как каждый из них работает, где пригодится и в каких случаях может дать сбой.
Материал по-прежнему будет полезен всем, кто заботится о «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам.
Готовы продолжать? Тогда поехали!