В данной публикации я поделюсь двумя основными причинами, по которым я предпочитаю избегать использования автоинкрементных полей в PostgreSQL и MySQL в будущих проектах. Вместо этого я предпочитаю использовать UUID-поля, за исключением случаев, когда есть очень веские аргументы против этого подхода.
СУБД PostgreSQL способна бысто работать с огромными массивами данных благодаря множеству различных механизмов, таких как карта свободного пространства, позволяющая за короткий промежуток времени найти страницу из основного слоя с необходимым свободным пространством для вставки новых версий строк.
В этой статье мы разберемся в устройстве карты свободного пространства, а также познакомимся с алгоритмом получения страницы с необходимым свободным пространством.
Привет, Хабр!
При работе с PostgreSQL (да и в целом с любой БД) важно правильно настраивать и управлять ресурсами, такими как память, процессорное время и дисковые операции, и так далее для обеспечения лучшей производительности и стабильности работы БД.
В этой статье мы как раз и рассмотрим кратко о том, как управлять ресурсами в PostgreSQL.
Стартует уже совсем скоро: 8 апреля, а завершится 9-го. Можно просмотреть расписание и список докладов.
Первый доклад после открытия - директора нашего отдела образования Павла Лузанова - PostgreSQL 17:
В этом году даты проведения конференции совпадают с завершением релизного цикла 17 версии. 8 апреля в 15:00 MSK прием изменений завершится. А мы сможем обсудить, что ожидать в осеннем релизе. Здесь и инкрементальное резервное копирование, изменения в логической репликации, триггер на подключение и наверняка появится что-то любопытное в начале апреля.
Следующий доклад в конференц-зале - Про-Shardman, Алексей Борщев и П. Конотопов. То, что он идёт вторым после обзорного, показывает, какое значение придают этой новой СУБД в компании. Интерес к ней действительно огромный. Они расскажут о Шардмане с точки зрения SQL разработчиков и архитекторов БД:
что такое Шардман;
чем отличается от обычного Постгреса;
типы таблиц и их использование;
как адаптировать схему БД для работы на шардах.
Конечно, будет рассказано и о других новинках компании: доклад Pooler, load balancer, proxy. Что их объединяет? Артём Галонский, pgpro_rp (приоритизация ресурсов, доложит Александр Попов) и других.
Всем привет! Меня зовут Егор, я стажёр backend-разработчик в зарплатном проекте Росбанка (он же Payroll). В этой статье я расскажу про путь становления от «зеленого» стажера до боевой единицы в команде: через что мне пришлось пройти, с какими трудностями я столкнулся и как прокачал свои скилы.
Всем привет! Я Сергей, работаю в B2B-команде Яндекс Маркета последние 3,5 года. Как уже понятно из заголовка, сейчас я вам расскажу про yet-another-миграцию с базы на базу, которая началась в середине 2021 года и заняла почти год. Получается, мемуары.
Вас ждёт рассказ о том, как мы:
- несколько месяцев чинили тесты и делали трансформер;
- десятки раз переливали данные;
- чинили баги незаметно для пользователей;
- заставили сервис работать на PostgreSQL быстрее, чем он работал на Oracle.
Продолжаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".
В этой лекции мы узнаем, что такое план выполнения запроса, как и зачем его читать (и почему это совсем непросто), и о каких проблемах с производительностью базы он может сигнализировать. Разберем, что такое Seq Scan, Bitmap Heap Scan, Index Scan и почему Index Only Scan бывает нехорош, чем отличается Materialize от Memoize, а Gather Merge от "просто" Gather.
Как обычно, для предпочитающих смотреть и слушать, а не читать - доступна видеозапись (часть 1, часть 2) и слайды.
Привет, я Паша, разработчик в Yandex Infrastructure, и я катаю гусей. С 2019 года я развиваю S3-хранилище как для внутренних пользователей Яндекса, так и для клиентов Yandex Cloud. А «гусём» называется наш бэкенд S3 API: он написан на Go, а из словосочетания Go + S3 получился goose. Возможно, вы также слышали про GeeseFS — это наш высокопроизводительный FUSE-клиент для S3. C его помощью вы можете на своём ноутбуке или виртуалке подмонтировать папку, которая будет работать с бакетом S3.
Для чего нам «гуси» и прочая орнитология? Яндексовая инсталляция хранилища S3 хранит миллиарды файлов. Это огромные объёмы данных, а также метаданных. Для хранения метаданных мы научились использовать умное шардирование, и теперь сами управляем распределением занятого места и нагрузкой между шардами баз.
Так что сегодня я расскажу, как сделать так, чтобы ни один клиент, даже с самым неудобным паттерном нагрузки, не положил сервис.
Когда говорят «мы ускорили выполнение нашего запроса в N раз» это значит, что сначала сделали плохо а потом начали думать как улучшить.
Так я думал раньше.
Статический анализ структуры базы данных — это процесс выявления ошибок, нерекомендуемых практик и потенциальных проблем в базе данных только на основе структуры, типов данных, свойствах объектов. Статиеский анализ структуры не задействует ни пользовательские данные, ни статистику по таким данным.
Рассмотрим подробнее статический анализ структуры базы данных — что это, какие задачи решает, как интегрировать статический анализ в CI.
Общеизвестно, что PostgreSQL - крайне эффективная СУБД с богатой функциональностью. При этом не секрет, что PostgreSQL масштабируется только вертикально и её производительность ограничена возможностями одного сервера.
Написано много хороших постов, в которых сравнивают архитектуру монолитных и распределенных СУБД. К сожалению, обычно авторы ограничиваются теоретическим сравнением и не приводят конкретные цифры. Данный пост же наоборот основан на эмпирическом исследовании с использованием бенчмарка TPC-C, который является промышленным стандартом для оценки производительности транзакционных СУБД (On-Line Transaction Processing, OLTP).
Мы расскажем, когда именно одного Postgres'a становится мало, и какие возможны компромиссы между производительностью и надежностью. Для тех, кто не готов к компромиссам, мы покажем, что могут предложить такие распределенные СУБД, как CockroachDB и YDB.
Анализ планов и форматирование запросов PostgreSQL удобно выполнять в VS Code, используя explain.tensor.ru и плагин, о котором пойдет речь ниже.
Новые контрибьюторы PostgreSQL:
Бертран Друво (Bertrand Drouvot),
Габриэль Бартолини (Gabriele Bartolini),
Ришар Гуо (Richard Guo).
Новые главные (major) контрибьюторы PostgreSQL, прибавилось два представителя Microsoft и один от Amazon:
Александр Лахин (Alexander Lakhin) - особенно поздравляем!
Дэниэл Густафссон (Daniel Gustafsson, Microsoft),
Дин Рашид (Dean Rasheed),
Джон Нэйлор (John Naylor),
Мелани Плейгман (Melanie Plageman, Microsoft),
Натан Боссарт (Nathan Bossart, Amazon Web Services).
Всех поздравляем! Страница контрибьюторов здесь.
В прошлой статье я показал, как условие с парой однотипных неравенств, плохо поддающееся индексации с помощью btree, можно переделать на эффективно gist-индексируемое в PostgreSQL условие относительно диапазонных типов, а наш сервис анализа планов запросов explain.tensor.ru подскажет, как именно это сделать.
Но что делать, если неравенств у нас не два, а целых четыре, да еще и с разными типами участвующих полей? Например, для целей бизнеса это может быть задачей вроде "найди мне все продажи за декабрь на сумму 10-20K", что на SQL будет выглядеть примерно так:
dt >= '2023-12-01'::date AND dt <= '2023-12-31'::date AND
sum >= 10000::numeric AND sum <= 20000::numeric
Я уже не раз писал, что условия с несколькими неравенствами (<, <=, >=, >) обычно плохо подходят для индексирования "классическим" btree, вызывают "тормоза", и необходимо придумывать различные нетривиальные подходы в PostgreSQL, чтобы добиться хорошей производительности подобного запроса.
В этой статье мы не только рассмотрим способы решения подобных задач "в общем виде", но и покажем, как нам удалось автоматизировать их решение в рамках функционала рекомендаций индексов нашего сервиса анализа планов explain.tensor.ru и его новых возможностях.
В прошлый раз я описал, как можно поставить задачу (Job) в очередь Laravel из хранимой процедуры или триггера PostgreSQL.
В этой статье я расскажу, как можно преобразовать события, возникающие в PostgreSQL, в события Laravel.
Рабочий пример выложен на GitHub.
PostgreSQL 16 вносит немало улучшений в планировщик запросов и позволяет выполнять многие SQL-запросы быстрее, чем в предыдущих версиях PostgreSQL.
Если вы посмотрите на PG16 release notes, то увидите некоторые из этих улучшений. Но из-за объема изменений, вносимых в каждом выпуске PostgreSQL, невозможно предоставить достаточно подробную информацию о каждом изменении.
В этом посте вы получите глубокое представление о 10 улучшениях, внесенных в планировщик запросов PostgreSQL 16. Для каждого из улучшений будет сравнения выходных данных планировщика PG15 и PG16, а также примеры того, что изменилось, в виде автономного теста, который вы можете попробовать сами.
Доброго времени суток. Основываясь на своём опыте хочу представить некоторые рекомендации при разработке кодовой базы на SQL.
Данные рекомендации получены горьким опытом, так что надеюсь, они Вам помогут :)
