Быки, коровы и квайны
Об олимпиаде незапамятных времён спонсорства Oracle рассказывал ещё bzq aka Евгений Бредня, возглавляющий сейчас техподдержку Postgres Professional, а тогда (2016-2017) он ещё готовил вопросы как сотрудник AT Consulting. Вот части I и II. У Евгения на хабре интересные статьи — и о причудливых задачках, и о техподдержке. Так писали мы в Postgresso №6 (55). Там же рассказали и уже об актуальных на том момент (2023) задачах 2-го и 3-го этапов, которые готовил Егор Рогов, руководитель программ отдела образования Postgres Professional (задачи для первого готовил не он, а Евгений Моргунов, автор PostgreSQL. Основы языка SQL).
В прошлом году, как известно в том числе из Postgresso #5 (66), организаторы даже выложили огромное видео, в котором был доклад Егора Рогова - в качестве важных материалов, сопутствующих олимпиаде: XV Международная олимпиада в сфере информационных технологий «IT-Планета 2024». 1-й этап — заочный теоретический тест по PostgreSQL, из почти 3000 человек отобрали примерно 200. Вопросы для этого этапа были подготовлены Евгением Давыдовым. 2-й этап — также заочный. Здесь участникам было предложено подумать над пятью задачами Егора Рогова. Их он и разбирает в этой статье. А финал (3-й этап) Олимпиады проходил очно в Архангельске.
Но это присказки.
В этом году задачи для IT-Планеты опять придумывали мои коллеги из Отдела образования Postgres Professional.
«IT-Планета 2025»: задачи второго этапа по PostgreSQL
— это задачи Евгения Давыдова aka Zheka22, в прошлый раз придумывал для 1-го этапа, теперь - для 2-го, уже в статусе руководителя программ высшего образования, между прочим.
Задача 1: Карлсон и варенье [у меня сейчас в имени обжоры была фрейдистская ошибка: Карслон]. Найти дни, когда Карлсон чувствовал себя счастливым (см. подробности).
В комментарии к статье некто Красный Волк RedWolf предлагает своё решение - без оконных функций, с INNER JOIN.
Задача 2: неожиданно объектами задания оказались параметры кластера PostgreSQL. Необходимо найти промежутки времени, когда максимальное количество параметров принимало значение, отличное от значения по умолчанию (см. в статье).
В комментариях Егор Рогов, то есть коллега Евгения, предлагает решение с рекурсивным запросом и JSON, а Кирилл Боровиков Kilor — «банальным», но шустрым подсчетом точек изменений. Потом и Красный Волк предлагает своё решение.
Задача 3: ИТ-конференция. На неё продаются билетов 3 типов (разной стоимости). Участники регистрируются, но криво: иногда по нескольку раз в день передумывают. Найти сколько каких билетов закупили (см., не всё так просто).
Задачи 4-5: Быки и коровы (игра), 2 варианта.
Kilor тоже решил — опять же, загляните в комментарии.
«IT-Планета 2025»: задачи третьего этапа по PostgreSQL
На третьем этапе олимпиады мы, как обычно, решали задачки на SQL, но в этом году надо было написать запрос не просто правильный, но и короткий. Чем короче — тем лучше результат. В детстве мы развлекались таким на микрокалькуляторах и на ассемблере, а сейчас я решил посмотреть, что получится, если попробовать то же на SQL. Получилось, на мой взгляд, интересно. Практического смысла в этом, конечно, никакого нет, но практики и на работе хватит, а тут мы развлекаемся — пишет Егор Рогов, автор задачек.
Задача 1: Квайн.
Оказывается, это такой тип задач, названный в честь философа Уилларда Квайна (Willard Van Orman Quine): запрос, который выводит самого себя.
Задача 2: Лужи. На основе Trapping Rain Water.
Известная задача с литкода — говорит Егор, — об этом, конечно, надо было еще догадаться, но это как раз звездный час ИИ. Простой вопрос к, скажем, DeepSeek про задачу о лужах тут же выдает и саму задачу, и решение на Питоне, которое требует O(n) по времени и O(1) по памяти. Вопрос в том, что с этим делать дальше. И-интеллект и тут, конечно, что-то предложит, но уже начнет плавать, поэтому включаем голову.
Задача 3: Лужи 3D (Trapping Rain Water II).
В комментариях к этой статье предложили решение только 1 задачи: @not0a0whale — это оказался Никита Тихонович, который участвовал в конкурсе: он подкрутил, подсократил собственное решение с безумной регуляркой.
Фёдор Сологуб и Станислав Лем, pdot, GraphViz и софт-монстры с Einstürzende Neubauten
Диана (Дайан) Фэй (Dian Fay) стала героиней PostgreSQL Person of the Week. Я не помню это имя, и заинтересовала меня больше не техническая часть, а гуманитарная. Но сначала о деле.
Американка Фэй поработала во многих стартапах, её знают по проекту pdot — приложению, которое генерит диаграммы для GraphViz, которые визуализируют описания на языке DOT. Говорится, что схемы pdot более релевантные, чем обычные диаграммы сущность-связь, позволяют интерактивно исследовать схему с различных точек зрения, а также визуализируют менее часто отображаемые отношения, такие как взаимодействия триггеров и функций, зависимости представлений.
Ещё она подхватила проект MassiveJS у Роба Конери (Rob Conery), а теперь работает над более продвинутым продолжением этого проекта — monstrous, для чего ей пришлось углубиться в реляционную алгебру, рассказывает Диана.
Любимое её расширение — PostGIS. Как‑то на досуге она решила моделировать с помощью SQL и PostGIS флювиальные процессы на придуманном ею континенте Сквария (Squaria, типа Квадратландия) — как там будут вершить эрозию реки и озёра. Другое любимое расширение менее раскрученное: pgTAP.
Круг чтения впечатляет: например, Диана на досуге изучает труды конференции Software Development and Reality Construction 1988 года. Но это ладно. Настольная книга у неё сейчас — новые переводы рассказов Фёдора Сологуба. Оказывается, ещё в тинейджерстве к ней попала книжка с его рассказом Благоуханное имя. По‑английски The Sweet‑Scented Name. И этот рассказ — говорит она — сформировал её эстетически. Также упоминает Рукопись, найденную в ванне Станислава Лема, штудирует философские сочинения Делёза & Гваттари.
Ну а как захочется послушать музычку, включает миниалистский нойз ▶︎ Time Destroys Everything (En Nihil), или (бывший) индастриал — Морскую звезду (Einstürzende Neubauten) или Вельо Риховича Тормиса.
Миграции - кто куда
Migrating the Jira Database Platform to AWS Aurora
В этой статье Пэта Рубиса (Pat Rubis), главного инженера по надёжности (principal site reliability engineer) Atlassian, впечатляют прежде всего цифры. Вот это переезд: 4 миллиона баз данных на 3 тыс. серверов PostgreSQL в 13 региональных AWS по всем миру. А всего DB-файлов баз данных, используемых Jira — 27.4 млрд! И всё переехало. Как такое возможно? Там рассказано.
A Tale of Migrating from CockroachDB to Postgres
Шон Каллахан (Sean Callahan), рассказывает, как перевозили Motion из CockroachDB, на PostgreSQL. Поначалу — в 2022 — всё было неплохо, базы прекрасно горизонтально масштабировались, но потом выяснилось, что у приложений начинаются проблемы с задержками; несмотря на совместимость с PostgreSQL‑протоколом, CockroachDB не полностью поддерживает все возможности PostgreSQL (например, отсутствует pg_advisory_lock, особенности транзакций, синтаксис некоторых команд), что усложняет миграцию и разработку.
Эти недостатки описаны и в статье Поднимаем кластер CockroachDB из трех нод. Записки программиста.
Migrate Coackroach DB to Postgres, об этом пишет некто Герсон Моралес (Gerson Morales) — без хорошо/плохо, просто пошаговое руководство.
Why We Moved From CockroachDB to PostgreSQL — Дакшитха Ратнаяке (Dakshitha Ratnayake), представившийся как Developer Advocate (чего только не придумают), рассказывает о том как на PostgreSQL переезжал ZITADEL Cloud.
А вот в обратную сторону: Миграция Laravel Nova с PostgreSQL на CockroachDB. Наш опыт и решение — это Совкомбанк Технологии.
Что касается миграции на CockroachDB с Oracle, то есть, например, такой отчёт о миграции: Как мы мигрировали критичную БД с Oracle в CockroachDB — пишет PeterBobrov в блоге QIWI.
А вот не про миграцию непосредственно, зато серьёзная статья серьёзного человека о различиях в транзакционных системах — о них не так часто пишут в этом жанре:
Comparison of the transaction systems of Oracle and PostgreSQL
Лауренц Альбе (Laurenz Albe, Cybertec):
Запуск и завершение транзакций
В Oracle любая DML-операция автоматически запускает транзакцию, которую нужно явно завершить с помощью
COMMITилиROLLBACK. Нет отдельного оператора для начала транзакции.В PostgreSQL включён режим автокоммита (autocommit): если не начать явную многооперационную транзакцию через
START TRANSACTIONилиBEGIN, каждая SQL-операция выполняется как отдельная транзакция с автоматическим завершением.
Обработка ошибок внутри транзакций
В Oracle ошибка в SQL-операции не прерывает всю транзакцию, а только откатывает эффекты ошибочной операции. Транзакция может продолжаться. Для отката всей транзакции требуется явный
ROLLBACK.В PostgreSQL ошибка в любом SQL-запросе во время транзакции сразу приводит к её отмене — все последующие запросы в рамках этой транзакции игнорируются до её завершения.
Реализация многоверсионности (MVCC)
Oracle использует отдельное UNDO-табличное пространство, чтобы хранить старые версии строк. Это накладывает ограничения на объем данных, которые можно изменить за транзакцию, и требует управлять размером UNDO.
PostgreSQL хранит все версии строк непосредственно в самой таблице, что устраняет необходимость в отдельном UNDO-слое.
Лог транзакций
Оба движка используют журналы транзакций для обеспечения долговечности данных — Oracle использует REDO‑лог, PostgreSQL — WAL. Обе системы гарантируют схожий уровень защиты и восстановления.
Особенности работы с конкурентным доступом и блокировками
Различия в реализации мультиверсионности и блокировок приводят к отличиям в поведении систем при одновременном доступе пользователей.
Реализация изоляции транзакций и её влияние на результаты запросов
Приводится сравнение поведения при уровне изоляции READ COMMITTED, где, несмотря на общие принципы, есть нюансы в том, какие данные видны транзакциям.
Ограничения на масштабируемость транзакций в Oracle
У Oracle есть ограничение на количество изменений в транзакции, обусловленное размером UNDO-табличного пространства. Для больших операций рекомендуется разбивать изменения на партии. В PostgreSQL такого ограничения нет.
И на закуску миграционный доклад на грядущей HighLoad++ 2025:
Неожиданные различия PostgreSQL и YDB: опыт перевоза процессинга Яндекс Такси — миграция микросервиса с шардированного PostgreSQL на YDB: несмотря на похожесть двух СУБД, YDB далек от состояния «drop‑in replacement» для PostgreSQL — Игорь Березняк, Техплатформа Городских сервисов Яндекса.
Это мы плавно переходим в раздел
Конференции
Продолжаем о HighLoad++ 2025. Там будут, например, такие доклады:
Почему следует время от времени переписывать все компоненты СУБД с нуля — интересный список предыдущих занятий докладчика — Павла Велихова, руководителя команды оптимизатора YDB: Enosys Integration Server (сейчас часть Oracle), Sedna XML DBMS, система Texterra (Институт Системного Программирования), SciDB MPP DBMS, News360, Huawei GaussDB, TigerGraph. В этом докладе он обещал не распыляться, а сфокусироваться на движке выполнения запросов и оптимизаторе запросов.
Подводные камни в реализации глобальных вторичных индексов — опыт асинхронной реализации глобальных вторичных индексов на примере Tarantool — Евгений Митин, Пикодата.
Онлайн анализатор миллиона видеостримов: как положить в кликхаус 2 млрд записей в сутки и достать в мультитенантную графану — решение, анализирующее структурную целостность около миллиона видеопотоков одновременно — Максим Лапшин, erlyvideo.
Как мы внедрили WebAssembly в SQL‑движок YTsaurus — WebAssembly в SQL‑движке для безопасных UDF; преимущества и ограничения технологии WebAssembly; та же технология в других СУБД — Дмитрий Торилов, Яндекс.
Мы писали о прошлогодней конференции в статье, наполовину посвященной ей, наполовину PGConf.Academy. Они и в этом году ходят парой. PGConf.СПб 2025 пройдёт 29 сентября.
Пока всё открыто: регистрация открыта, но цена участия будет разная при подаче до 15 августа, до 15 сентября, и до 22 сентября. Потом — всё. Это не относится к студентам и преподавателям — для них участие бесплатно. Доклады можно предлагать до 1 августа, на мастер‑классы — тоже до 1 августа.
Прошлогодняя конференция очень понравилась. Мне — больше всего тем, что докладчики и слушатели не сильно пересекались с обычными завсегдатаями постгресовых конференций. Не сомневаюсь, что и эта понравится.
Конференция пройдёт 6 октября. На этот раз не в районе МГУшных новостроек за Ломоносовским проспектом, а в Центре Культур ВШЭ на Покровском бульваре 11, стр. 6, корпус Z — менее экзотично, зато удобно.
Расписания ещё нет, доклады ещё принимаются до 12 сентября, регистрация открыта. Участие для преподавателей и представителей образовательных организаций бесплатное, но необходимо получить подтверждение участия.
Пройдёт 9 сентября в Лондоне. Опубликовано расписание.
Состоится впервые в Неаполе 25 сентября. Опубликовано расписание, открыта регистрация. Хорошо это или не очень, но из знакомых докладчиков только Гюльчин Йылдырым Джелинэк (Gülçin Yıldırım Jelinek) с докладом Anatomy of Table-Level Locks in PostgreSQL.
Университетский Консорциум исследователей больших данных, куда входят организации из России, Казахстана, Узбекистана, Армении, Киргизии, пройдёт 30-31 октября в Казани в IT-парке им. Башира Рамеева.
В программе конкретные доклады не указаны, но обозначены треки, например дата-тех: инструменты и технологии. И в программе есть винотека данных — обсуждение проблем отрасли за бокалом белого или красного.
Релизы
Изначально Shardman создавали на базе ванильной PostgreSQL 14, новый продукт основан на Postgres Pro Enterprise 17.5.1 и Shardman 14.18.2. Для объединения этих редакций провели масштабную и сложную работу. Теперь Shardman — полноценная часть экосистемы СУБД Postgres Pro.
Повышенная отказоустойчивость системы: теперь каждый шард — кластер BiHA, а не stolon.
Расширенные возможности управления таблицами — добавили поддержку команды LOCK TABLE для глобальных и сегментированных таблиц.
Новая логика блокировок — уменьшает нагрузку на процессор при восстановлении физических реплик, работающих как источники для многопоточной логической репликации.
Улучшенная стабильность, так как 17-я версия впервые прошла полноценное исследовательское тестирование в департаменте выпуска продуктов.
Возглавляющий проект Виталий Кухарик (Vitaliy Kukharik @vitabaks, Таиланд) говорит, что отныне Autobase годится для промышленной эксплуатации как DBaaS для PostgreSQL.
Теперь можно:
импортировать существующие кластеры в пользовательский интерфейс (UI) Autobase UI;
экспортировать кластеры в директории файлов Ansible;
добавили поддержку AWS Network Load Balancer;
переработали систему автоматизации, теперь она современная, на базе Ansible Collection.
Большой список нового и исправленного, огромный список новых контрибьюторов — в том числе и из Красноярска. Но первым стоит загадочный контрбьютор @renovate[bot], он сделал свой 1-й вклад в проект.
Да, не пройдёшь мимо такого названия. Вот это нейминг так нейминг!
Procrastinate — это библиотека для распределённой обработки задач на Python 3.9+, с открытым исходным кодом, использующая PostgreSQL 13+ для хранения определений задач, управления блокировками и распределения задач. Она может использоваться как в контексте синхронного кода, так и асинхронного, интегрирована с Django и работает с ASGI-фреймворками. Поддерживает периодические задачи, повторные попытки, произвольные блокировки задач и другие возможности.
Из основного кода вы вызываете специальные функции (задачи), но, вместо того чтобы выполняться сразу на месте, они планируются для выполнения в любом назначенном месте - сейчас или в будущем.
Вышла Procrastinate 3.4.0. Но больше о новшествах в Procrastinate 3.0.0.
Статьи
Features I Wish MySQL Had but Postgres Already Has
В прошлом выпуске Postgresso 2–3 мы рассказывали о статье What's New in PostgreSQL 18 — a DBA's Perspective этого автора — Тяньджоу (Tianzhou, Bytebase). Теперь узнаем: в чём же Postgres опередил MySQL?
CTE;
RLS;
более совершенный парсер: PostgreSQL более точно следует SQL-стандартам, лучше обрабатывает ошибки и поведение его более предсказуемо;
Postgres query plan visualization tools
Майкл Кристофайдес (Michael Christofides, pgMustard), хорошо знакомый нам по подкастам Postgres FM в соавторстве с Николаем Самохваловым (Nikolay Samokhvalov, postgres.ai), сделал обзор инструментов, которые помогают анализировать (ссылки - на главки в статье).
Конечно, набор Майкла не полный. Добавим, справедливости ради, explain.tensor.ru. Например.
Вот, кстати, другая его статья:
Approximate the p99 of a query with pg_stat_statements
P99 — это статистическое понятие из области: нормальное распределение (Гауссовские колокольчики), сигмы. Вот здесь изложено полней.
Среднее время обработки запроса — штука обманчивая. Майкл поясняет:
представьте себе два сценария: первый запрос обрабатывается в среднем за 100 миллисекунд, но иногда (1%) занимает свыше 500 миллисекунд (p99), второй же запрос в среднем выполняется за 110 миллисекунд, но его p99 составляет всего 200 миллисекунд. Вполне вероятно, что именно первый запрос вызывает большее недовольство пользователей, несмотря на то, что в целом он работает быстрее.
Пока что такие колокольчики и сигмы надо собирать вручную. Майкл сочиняет соответствующий запрос к pg_stat_statements. Но ссылается и на расширение pg_stat_monitor для тех, кто не любит самодельные запросы.
Название статьи Питера Айзентраута (Peter Eisentraut, EDB), как выяснилось, отсылает к системе наименований стандартов языка C. А под SQL:202y он имеет в виду несуществующую пока — грядущую версию следующую стандарта SQL. Пока что был SQL:2023. По графику выпуск новой версии стандарта SQL предполагается в 2028 году. Вот и увидим, что получится — говорит Питер.
Понятно, что многие уже разработали средства для работы с векторами, не дожидаясь стандарта. И уже стоит прикинуть, что было бы неплохо стандартизовать — как общее для всех разработчиков.
Прежде всего Питер говорит о вычислении расстояния между векторами (по разным алгоритмам) — ведь это основа семантического подобия.
Но прежде должны быть конструкторы для векторов — vector(). С ними можно делать для начала вот что:
vector_dimension_count()vector_norm()vector_serialize()
В основной запрос на близость можно будет ввести параметры:
SELECT *, vector_distance(items.embedding, :someparam, cosine) FROM items ...
вот какие они, например:
cosinedoteuclideaneuclidean_squaredhammingmanhattan
Это разные алгоритмы вычисления расстояний. Внутри SELECT можно будет ввести такие новые элементы языка SQL:
FETCH APPROX FIRST 5 TO 10 ROWS ONLY
Тут, казалось бы, комментаторы должны набежать с предложениями: а я бы добавил то, а я бы добавил это. Но они молчат. Может, читатели этого обзора восполнят эту недостачу.
Кот и пёс, лягушка и триллион строк
Если честно, мне немного обидно. Лев Кокотов (Lev Kokotov) сначала создал PG-Кота, а теперь всё внимание PG-Псу. Ещё щенку, в общем. Кот — рабочая лошадка, вкалывает в продакшн серверах. Пёс приносит палочку и учится новым командам. Оба суть пулеры соединений и прокси для PostgreSQL, написанные на Rust и использующие асинхронный Tokio rutime. Но Пёс сразу ориентирован на работу с шардами. Кот тоже умеет с ними работать, но с кросс‑шардовой агрегацией у него не очень и со сборкой результатов так себе, вот маршрутизация запросов на нужный шард — тут Кот мастер. Если честно, у Пса со сложными кроссшардовыми операциями тоже не бог весть, но — пока. Он быстро учится.
PgDog vs. Citus — это не бенчмарки, а сравнение архитектур. Они не то что отличаются: они принципиально разные. Соответственно и для задач подходят совсем разных. Поэтому остановимся подробней.
PgDog:
Основан на многопоточном асинхронном рантайме Tokio (Rust), использует задачи (tasks), которые эффективно распределяются между потоками.
Благодаря асинхронности и использованию epoll (Linux) или kqueue (BSD), PgDog может обслуживать сотни тысяч, а то и миллионы соединений.
Отлично подходит для I/O-нагруженных (OLTP) сценариев, где требуется высокая пропускная способность и большое число одновременных подключений.
PgDog — это stateless-прокси: его инстансы не зависят друг от друга, легко масштабируются горизонтально, не требуют внешнего хранилища, кроме конфигов. Это особенно важно для облачных и контейнерных сред.
Citus:
Это расширение к PostgreSQL, использующее процессную архитектуру самого Postgres.
Ограничено максимальным количеством соединений, которое может выдержать Postgres (обычно до 5000, но на практике рекомендуется не более 2 подключений на CPU-ядро).
В архитектуре Citus есть один координатор и несколько фоновых процессов (workers). Все запросы идут через координатор, который может стать узким местом при большом количестве коротких запросов (OLTP), но хорошо подходит для OLAP-нагрузок, когда фоновые процессы читают и агрегируют большие объёмы данных.
В Citus масштабируется только слой фоновых процессов, координатор же остаётся единственной точкой входа, и его производительность ограничена архитектурой Postgres.
Итого:
PgDog — хорош, когда у вас много коротких транзакций, высокая конкуренция соединений (OLTP), и вы хотите горизонтально масштабировать пул соединений. На момент написания статьи PgDog поддерживает только базовые кросс‑шардовые агрегации (то есть не все сложные аналитические запросы реализованы). Это молодой проект, находящийся в активной разработке, и пока экспериментальный.
Citus — если у вас аналитические нагрузки (OLAP), большие таблицы и сложные агрегации. Для сложных аналитических задач (OLAP) Citus пока предпочтительнее.
PgDog vs. PgBouncer — а в этой статье как раз бенчмарки — с участием Кота тоже. На них до 50 соединений все бегут ноздря в ноздрю, потом Баунсер выдыхается и плетётся сзади, а Пёс выигрывает у Кота то голову, то полкорпуса.
Sharding pgvector — берём датасет Cohere/wikipedia, то есть всю англоязычную вики. Выбираем число центроидов равным числу шардов. И вуаля.
А вот и обещанная ЛЯГУШКА. Да не простая, а дождевая: 🐸 rainfrog
Это минималистичный инструмент, претендует этот терминальчик на то, чтобы стать альтернативой pgadmin/dbeaver! Но пока он в бета-фазе. Сейчас самая зрелая версия - 0.3.4.
А с какой стати Лягушка-то? Оказывается, лягушки прячутся в лужицах внутри следов от слонов.
Ещё статьи: про триллионы и миллиарды
PostgreSQL: 1 trillion rows in Citus
От этой статьи Ханс-Юргена Шёнига (Hans-Jürgen Schönig), гендира и основателя Cybertec, по воде сообщества разошлись круги. Её, написанную в середине марта, точнее цифры из неё, точнее триллион, нередко цитируют как этакую точку отсчёта.
Для начала Ханс-Юрген напоминает, что триллион строк не получится уложить в обычную таблицу: заголовок каждой записи это 24 байта и 12 байтов данные (int + bigint), это уже 34 ТБ, что больше максимального размера таблицы при размере блока в 8 КБ. Надо секционировать или вертикализировать, или нарезать на шарды при помощи Citus.
Он выбрал 3-е. Поскольку в Citus вертикальное хранение, размер таблицы получился около 1563 ГБ, что влезло на обычный ноутбук.
Ханс-Юрген сначала просит просто пересчитать триллион строк — это 53 минуты, потом усложняет запрос до GROUP BY 1 ORDER BY 2 DESC; Вот такие дела.
Как мы под Новый Год загрузили в PostgreSQL петабайт данных и что из этого вышло
Статья опубликована 20 мая2025 года и подписана mizhka — это Михаил Жилин, директор департамента системной производительности в Postgres Professional.
Там вовсе не Citus, а Shardman. И тут тоже триллион строк, хотя задачи уместить на персоналку не стоит. Более того: надо сделать не игрушечную инсталляцию, а прогнать бенчмарки.
До этого Михаил опубликовал более года назад в соавторстве с Павлом Конотоповым статьи (Pavel Konotopov aka kakoka): Мифы и реалии «Мультимастера» в архитектуре СУБД PostgreSQL, ч. 1, 2 и 3. А ещё раньше — Аномалии под нагрузкой в PostgreSQL: о чём стоит помнить и с чем надо бороться. Этого автора стоит читать всегда.
Михаил пишет: нас ждало удивление номер один. Абсолютно все облачники окуклились на первой же строчке. Ну вот нет у них столько свободного места, даже если начать его специально под нас разгребать. Можно собрать по кускам из разных регионов, но качество результатов такого тестирования, когда у тебя нода в Москве, нода в Саратове, а третья нода на Крайнем Севере — сами понимаете.
Поэтому облака были отвергнуты, и в дело вступила классическая аренда железа. И тут нас ждало точно такое же разочарование: ни в одном ЦОДе не оказалось столько места на быстрых дисках, вот чтобы просто вынь да положь.
Когда мы уже были на грани того, чтобы забросить нашу прекрасную идею, из одного хорошего ЦОДа нам ответили, что у них есть семь примерно похожих на наш запрос сервера, они готовы набить их дисками и занедорого дать нам попользоваться. Распределённая СУБД Shardman на семь машин звучит интересно, поэтому было принято управленческое решение согласиться.
Одна [нужная нам] строчка в таблице это примерно 1100 байт. Значит таких строчек нам надо залить в базу примерно триллион (это когда в числе 13 цифр). Времени у нас две недели, значит надо выдавать около гигабайта в секунду и тогда даже небольшой запас останется. Выглядит как абсолютно реальная задача и современные диски вполне так умеют.
Для тестирования использовали YCSB (Yahoo! Cloud Serving Benchmark), а если точнее, то его реализацию на go от pingcap.
Существует также видеозапись доклада Михаила: Через тернии к звездам - как засунуть Петабайт в Postgres. Михаил Жилин (версия vk).
Billions of Edges Per Second with Postgres
Здесь - ура! - не триллионы. Всего лишь миллиарды. Но зато не строк, а рёбер графа.
Пишет Мишель Пеллетье (Michel Pelletier, OneSparse): OneSparse может сериализовать и десериализовать графы в объекты Postgres и обратно, записывая их на диск или извлекая из дискового пространства. Самым простым было бы хранение в TOAST больших массивовданных переменной длины. Однако, основным ограничением этого подхода является то, что в Postgres размер TOAST по конструкции ограничен примерно 1 ГБ, что обычно ограничивает размер TOAST‑графов несколькими сотнями миллионов рёбер. Графы с миллиардами рёбер значительно превышают этот размер, поэтому OneSparse также предоставляет функции для загрузки гораздо более громоздких графов либо SQL‑запросами, либо как Large Object‑хранилища, либо, что наиболее оптимально, как сжатые файлы на самом сервере.
Самый большой граф — urand — содержит 4,3 миллиарда рёбер. Значения показывают количество «рёбер в секунду» (Edges Per Second), которые OneSparse способен обработать при обходе графа с помощью BFS, деля число рёбер в графе на время выполнения. Здесь мы видим, как невероятно быстро OneSparse справляется с обходом графов, достигая скорости более 7 миллиардов рёбер в секунду на некоторых графах.
Мелани
В конце этого обзора мне хочется отдельно напомнить о целом собрании сочинений по Postgres под брендом melanny20. Бренд у Postgres Professional. Статей сейчас уже 21: 3 на русском, остальные на английском. И это примерно за полгода.
На русском вот такие (в обратном хронологическом порядке):
Устраняем эффект шумного соседа в PostgreSQL с помощью cgroups — статья‑туториал по материалам выступления Камиля Каримова, инженера техподдержки компании Postgres Professional, на конференции PGCONF.СПБ 2024.
pg_profile и pgpro_pwr: анализируем производительность БД — тоже туториал. Обозначен как простой.
Asymmetric Join в PostgreSQL как эволюция Partitionwise Join — и это туториал, но уже сложный.
На сегодня всё.