На разных континентах и субконтинентах
В расписании конференции PGConf.Russia, к которой мы ещё, конечно, вернёмся в разделе Конференции, моё внимание привлёк вот такой доклад:
YMatrix Domino: Design Considerations, Trade-offs, and Implementation of In-Database Stream Processing - видимо, игрек впереди названия как раз в честь Яо Яндуна (Yandong Yao), гендира и сооснователя компании Ymatrix (также известной как Beijing Siwei Zongheng Data Technology Co., Ltd. или «Сывэй Цзунхэн»). Не думаю, что многим читателям этих обзоров она известна хотя бы по одному из этих названий.
Он экс-руководитель пекинского R&D-центра Greenplum.
Оказывается, на хабре есть статья о YMatrix:
Нагрузочное тестирование YMatrix, автор Марк Лебедев @mmlebedev, ведущий архитектор в GlowByte ("сегодня штат превышает 1 800 человек, и мы продолжаем расти"). Из неё мы узнаём: в команде YMatrix 2 из 5 топ-контрибьюторов Greenplum (ключевые разработчики, менявшие исходный код), на которых приходится примерно 20% вклада в R&D GreenPlum. Ядро команды разработки состоит из 30+ разработчиков, занимающихся развитием основных фичей.
Как продукт, YMatrix представляет собой активно развивающийся форк GreenPlum 7 с большим количеством доработок и изменений.
Изменения и доработки довольно любопытные:
MARS3 — гибридный колоночно‑строчный формат хранения, реализованный через структуру LSM Tree (Log‑Structured Merge Tree), которая позволяет хранить данные в отсортированном виде по указанным полям;
Domino — потоковая репликация данных для обеспечения высокой доступности;
MXShift — инструмент для полной, инкрементальной или условной миграции данных между кластерами GreenPlum/YMatrix в кластер YMatrix;
MXVector — все вычисления производятся в векторизованном виде. В сценариях с большими объёмами данных это значительно повышает скорость выполнения запросов;
YMatrix Cloudedition — раздельное хранение и вычисление данных. Позволяет хранить бинарные файлы в Object Storage.
Первый пункт указывает на решимость работать и с OLTP, и с OLAP.
Если уступить соблазну поисследовать территории, непосредственно прилегающие к Ymatrix, то можно найти немало любопытного. Например, там есть sqlmapproject с крышесносным описанием:
Automatic SQL injection and database takeover tool - автоматические SQL-инъекции, инструмент для желающих завладеть сервером базы данных. Прям Пираты Карибского моря. Но в описании всё куда прозаичней. Там вставлено 1 словечко: testing :) Хотя ... от любви до ненависти (и обратно) 1 шаг :)
Поблизости есть и Chaos Engineering - Ван Сян (WangXiang) разрабатывает для китайской базы TiDB экосистемные инструменты и такую вот платформу тестирования. У него (или у неё?) есть и англоязычные блоги:
Chaos Mesh Remake: One Step Closer toward Chaos as a Service
TiDB Binlog Architecture Evolution and Implementation Principles
Кстати, хаосы и пираты - это весело, но проект sqlmap изначально вовсе не китайский. У него богатая европейская история. Его основал Даниэль Беллуччи (Daniele Bellucci) аж в 2006, тут же бросил, но его дело подхватил Бернардо Дамеле (Bernardo Damele - они, видимо, итальянцы). В 2009 после конференции в Варшаве подключается поляк Мирослав Стампар (Miroslav Stampar). Сейчас он один, видимо, поддерживает этот проект - в Европе.
Есть китайский ресурс modb.pro, где, видимо, активно тусуются сообщества разработчиков баз данных. Есть там названия привычные - PostgreSQL, Oracle, MySQL, а есть там и про китайские базы данных, например:
YashanDB, разработчик - SICS (Shenzhen Institute of Computing Sciences), то есть это академическая разработка - ну прям как проекты профессора Майкла Стоунбрейкера.
О базе сами они пишут интересные вещи:
Новая СУБД полностью самостоятельно спроектирована и разработана в SICS. Опираясь на классические теории баз данных, она интегрирует оригинальные научные разработки:
На теорию ограниченной оценки (Bounded Evaluation theory - видимо, основано на работах коллектива профессора Вэньфэя Фана (Wenfei Fan), речь о выполнении запросов к базе к ограниченным объёмам данных, независимо от общего размера базы. Это гарантирует, что запрос не «повесит» систему и завершится за предсказуемое время.
На теорию аппроксимации (Approximation theory) - должна работать эффективно без больших инвестиций в железо).
На теорию параллельной масштабируемости (Parallel Scalability theory). Но в описании говорится и о планировании с адаптивном асинхронном параллелизмом (adaptive asynchronous parallel task scheduling mechanism); о теории планирования параллельных транзакций (Parallel Transaction Scheduling Theory), использующей Optimistic Concurrency Control (OCC).
На теорию смешанных кросс-модальных вычислений (Cross-Modal Fusion Computation theory - там говорится о NP-полноте (NPspace-completeness) и ещё о какой-то coNPspace-completeness).
Но самая серьёзная заявка, кажется, такая:
Теория вычислительной сложности больших данных (Big Data Computational Complexity Theory) - это основа вычислений Big Data. Традиционные теории вычислительной сложности неприменимы к большим данным. Впервые представлена революционная теория, определяющая ограничения и решения за полиномиальное время (tractable problems) для больших данных.
Вот так, ни много ни мало.
Кстати, если вы думаете, что на российских конференциях о китайских базах доклады не делали, то вы ошибаетесь. Postgresso - это такая укороченная летопись событий в мире баз данных.
В Postgresso 4 (53) читаем: openGauss 5.0.0. Честно говоря, об openGauss я узнал на PGConf.Russia 2023 из доклада Максима Милютина Аналитические open-source решения на базе PostgreSQL. Эту постгресовую СУБД разрабатывает Huawei, и она показывает неплохие результаты на их чипах kunpeng на базе ARM. В 2021-м появилась 1.0.1, а сейчас уже 5.0.0. Вот правильная (!) ссылка на страницу Release Notes. Распространяется по лицензии Mulan PSL v2.
OpenGauss — это форк PostgreSQL (изначально созданный Huawei на базе старой версии PG 9.2.4, который затем сильно ушел в сторону собственной архитектуры с движком хранения Ustore и языком PL/pgSQL в версии 2.0+). OpenGauss актуальна, о ней тоже говорят на modb.pro.
Не менее актуальна HTAP-база TiDB.
А что же на Индийском Субконтиненте? Индийских фамилий в рассылке (Postgres) hackers и в сообществе полно. Но кто там работает именно на индийские компании - непонятно.
И базы есть индийские - BangDB (конвергентная мультимодальная СУБД со встроенной поддержкой ИИ, потоковой аналитики, графов и временных рядов в одном движке;
Dgraph - распределённая графовая база данных с нативной поддержкой GraphQL (и графовый движок Hasura разработан в Бангалоре); и академические разработки есть.
Но вернёмся к делам сообщества.
Недавно в переписке разработчиков мне попался представитель компании Cybrosys Technologies (более 1000+ приложений в Odoo App Store, 4000+ статей в блоге). Причём анонимный - просто Postgress [sic!] Cybrosys. Сами представители Odoo (бывшая TinyERP) в такой активности не замечены. Хотя сама компания на подъёме, неизменно присутствует в списках опенсорсных и бесплатных ERP/CRM (таких списков даже в wiki 2: здесь и здесь). Odoo - компания бельгийская, а в Индии с ней работают многие местные фирмы.
Впрочем, может быть (нет, наверняка!) в переписке сообщества участвуют представители других китайских и индийских компаний, просто из адресов и подписей это не следует.
Но перенесёмся из Индии и Китая через океан - в Канаду. Там, на западном побережье, в Большом Ванкувере нас как бы встречает Кэри Хуанг (Care Huang) из канадской компании HighGo с темой глобальных индексов. К теме и к конференции в Ванкувере мы ещё вернёмся. А пока обратно - не в Китай, но на конференцию, с которой мы начали этот выпуск.
Конференции
Уже в понедельник. А потом и во вторник. Очень много интересных докладов, трудно было выбрать. Начну с парусников:
Разработка и внедрение автоматизированных моделей беспилотных парусников для экологического мониторинга с применением PostgreSQL - Игорь Тот, преподаватель Колледжа телекоммуникаций Московского технического университета связи и информатики.
Аналитическое расширение, реализующее базовые алгоритмы машинного обучения в среде PostgreSQL - Наталья Графеева, доцент ИТМО, Александра Сухотина, Студент магистратуры ИТМО.
Я помню Наталью по PGConf.СПб 2024 PGConf.Academy. Жизнь Postgres внутри академической, преподавательской среды - это интересно.
Мы реализуем алгоритмы машинного обучения там, где данные уже лежат — непосредственно внутри PostgreSQL, на чистом PL/pgSQL используя эффективные алгоритмы вычислений (в частности, градиентный спуск). Это позволяет производить вычисления вблизи данных, обеспечивая безопасность и минимальную задержку.
Случайности, которые меняют PostgreSQL: история о багах, которые прятались годами
Дмитрий Юричев, Moneta, инженер-программист:
как наши отчеты привели к крупным исправлениям в коде PostgreSQL:
1. Некорректные обновления в MERGE.
2. Проблема с multixact на standby-сервере.
Перспектива развития pg_profile - бинарная версия - Андрей Зубков, Postgres Professional, руководитель отдела систем мониторинга:
этот подход должен драматически снизить нагрузку на систему при выполнении снимков, значительно их ускорить, а также предоставить возможность сбора данных, не имеющих SQL-интерфейса.
Особенности построения аналитики из 1С:Предприятие в Postgres Pro AXE и Tengri Data - Борис Бондарев, BI.Qube, главный архитектор:
• Захват данных из 1С – сравнение вариантов интеграции, CDC или пакетная загрузка.
• Какие проблемы аналитики на PostgreSQL решаются с переходом на AXE и Tengri.
• Нюансы синтаксиса и обработки в AXE и Tengri в различных сценариях загрузки данных из 1С.
• Инструменты для автоматизации создания, настройки и сопровождения аналитического слоя данных.
Применяем расширение pg_clickhouse. Делимся опытом и результатами
Алексей Прошин, EGAR, Data Engineer. А ведь это расширение появилось недавно. Расскажет:
принципы pushdown, как проверять pushdown через EXPLAIN/ANALYZE.
Построение Data Lakehouse на базе PostgreSQL и Postgres Pro AXE - Жора Бабаян, Postgres Professional, разработчик.
Эволюция бэкапа Postgres. СРК Кибербэкап: пройденные этапы, проблемы, решения - Юрий Темкин, ООО Киберпротект, ведущий программист-разработчик:
Улучшения RPO и RTO. Детали организации данных внутри архива, которые позволяют делать прореживание данных без их физического перекладывания или как оптимизация архива под ленту помогла ускорить восстановление с любых носителей.
А тут и мастер-класс по теме бэкапа подпоспел:
Защита бекапов баз данных от шифровальщиков - Сергей Чаукин, YADRO, менеджер по работе с технологическими партнёрами.
Бизнес-логика в БД: Тяжёлое наследие 90-х или архитектура будущего? - Максим Грамин, Postgres Professional, системный аналитик.
Что, когда и почему следует размещать на стороне базы данных, а что категорически нет. Что изменится с популяризацией распределенных СУБД.
AfterLife — жизнь после переноса больших производственных систем на PostgreSQL (с Oracle Exadata)
Дмитрий Ремизов, ГНИВЦ, архитектор. На мой вкус тут ключевое слово - из Exadata. И название мне нравится :)
Разнообразные проблемы (и решения) в больших производственных системах после переноса на PostgreSQL. Multi- и Sub- транзакции (детективная история). Типичные проблемы оптимизатора. Разница в преобразовании типов и т.д. и т.п.
pGenie: Генератор кода по схеме и запросам по методологии DB-First
Никита Волков, codemine.io, архитектор:
Схема БД и SQL-запросы определяют контракт, а код для любого языка программирования генерируется автоматически со всевозможными проверками на корректность. Данный подход я реализовал в инструменте pGenie. Я вывожу его в опенсорс и представлю в данной презентации.
Ещё мастер-классы:
Расширения Postgres Pro Enterprise для оптимизации запросов
Денис Гидин, Postgres Professional, старший инженер. 170 минут (!) Запись на мастер-класс доступна только для подтверждённых офлайн участников PGConf.Pоссия 2026.
А теперь интригующая экзотика:
Квантовая эволюция SQL от Structured Query Language к Structured Quantum Language - Виталий Пелешенко, РЭУ им. Г. В. Плеханова, доцент.
Как гравитация организовала почти все на свете (Алексей Семихатов) | PGConf.Pоссия 2026 | PGConf.Russia - Алексей Семихатов. Ну кто ж не знает Семихатова. Как кто? Я, например, ухитрился не знать до его остросюжетной - и при этом профессиональной - лекции на позапрошлогодней PGConf.Russia Открытие Вселенной силой мысли.
Пройдёт 2-3 апреля. Москва, ВДНХ, павильон №38 «Бизнес.Техноград». В программе доклады и стримы развития - Боже, что это? А, вот что: срежиссированные тематические маршруты по конференции, один стрим развития - одна тема, которая раскрывается последовательно через разнообразные форматы (доклады, воркшопы, дискуссии и др.) для максимально полного и практического понимание ключевой темы.
PostgreSQL Conference Germany 2026
Пройдёт в Эссене 21-22 апреля, организатор - PostgreSQL Europe. Опубликовано расписание. Доклады можно присылать и на немецком, и на английском (однако, в расписании почти все на английском).
What's Missing in Postgres? - Брюс Момджан. Кочующий доклад, с тем же названием был на Prague Pg Dev Day 2026 (P2D2), на FOSDEM PGDay 2026 и - конечно - будет в Ванкувере, о котором дальше.
Swapping the Elephant Without Breaking the Room - Антон Борисов (Anton Borisov, из интересной компании Fresha). То есть посудная лавка уцелеет. Тоже был в Праге - кочующие доклады это нормально.
Operating Postgres as a data source for your analytics pipelines - Илья Космодемьянский (Ilya Kosmodemiansky), на этой конфе несколько докладов от Цапли - Data Egret. Вот ещё пример:
Not Just Altruism: Selling PostgreSQL Contributions to Your Employer - Валерия Каплан (Valeria Kaplan, Data Egret):
Что выигрывает отдельный разработчик и что получает компания. Как вклад в open-source помогает нанимать лучших специалистов, ускорять техническое развитие, повышать узнаваемость бренда, укреплять доверие клиентов и влиять на будущее всей экосистемы.
How I built an open source community in Armenia - Эмма Сароян (Emma Saroyan, PG Armenia).
Ну и куда без AI/ML. И речь НЕ об эффективных запросах на естественном языке:
The Elephant That Learns: How to use Machine Learning to Optimize PostgreSQL - Чарли Батиста (Charly Batista, EDB):
Практические приёмы: от поиска аномалий и прогноза нагрузки до автоматических рекомендаций по индексам. Покажем на живых примерах и с помощью открытых инструментов, как ML-модели учатся «чувствовать» приближение проблем — предсказывать тормоза, ловить первые сигналы сбоев и подсказывать, где и как настроить базу, чтобы она работала быстрее и стабильнее.
Как обещано, возвращаемся в Ванкувер, на Slonik Event:
Она же PostgreSQL Development Conference 2026. Состоится 19-22 мая - 4 дня, это марафон для Postgres-конференций. А расписания у конференции аж целых 2: одно на сайте, другое на PostgreSQL.org. Напишем здесь не о докладах, а о прямоугольных и круглых дискуссиях. Их тоже немало:
30 Years of PostgreSQL Retrospective - и круглая и прямоугольная (roundtable, но panelists will share), поучаствуют классики: Брюс Момджан (Bruce Momjian), Ян Вик [!] (Jan Wieck), Мелани Плейгман (Melanie Plageman - она пока не классик), Томас Локхарт (Thomas Lockhart - был в 1-й Core Team), Вадим Михеев [!] (Vadim Mikheev). Это в списке. А в описании ещё и Том Лейн (Tom Lane) и Джолли Чен [!] (Jolly Chen - это вообще один из создателей Postgres95).
Unexpected successes & epic failures by PostgreSQL committers: A Roundtable - круглая. Рассказывают Альваро Эррера (Álvaro Herrera), Даниэль Густафссон (Daniel Gustafsson), Питер Айзентраут (Peter Eisentraut), Томас Манро (Thomas Munro), модерируют Клэр Джордано (Claire Giordano) и Грег Бёрд (Greg Burd). "Считайте, что это такая групповая терапия для PostgreSQL-хакеров (в хорошем смысле): вы поймёте, что не одиноки".
Real-Time Patch Idea Evaluation - прямоугольная. И даже не дискуссия, а игра: Андрес Фройнд (Andres Freund), Хейкки Линнакангас (Heikki Linnakangas) и Роберт Хаас (Robert Haas) как коммитеры будут принимать или аргументированно отвергать патчи, о которых они до этого не знали. Прямо на глазах у честной публики.
Но обратите внимание и на вот такой доклад:
Experimenting with a Global Index in PostgreSQL: Design, Implementation, and Challenges, который подготовил Дилип Кумар (Dilip Kumar, Google). Эта тема получит развитие в нашем обзоре.
Это 1-е мероприятие в серии, пройдёт 4-5 июня в Чикаго. Оно с уклоном в образование, построение сообщества, связь с академическими кругами.
Бесплатная виртуальная конференция, организаторы - те, кто связан с open source в Microsoft. 16-18 июня. В расписании, как обычно, много знакомых postgres-имён.
Суперкомпьютерные дни в России 2026
Пройдут 28 - 29 сентября. Программа пока неизвестна, но на этой конференции регулярно случаются доклады, имеющие отношение к базам данных и к Postgres в том числе. Именно на такой конференции (тогда в Дюрсо на берегу моря, а не в Москве) я познакомился с Олегом Бартуновым. Если не путаю - давно это было.
5 марта 2026 г. - начало приема работ,
1 апреля - представление аннотаций работ,
15 апреля - представление полных версий работ,
15 мая - уведомление о включении работы в программу конференции,
30 мая - представление окончательного варианта работы.
Не думаю, что многие читатели наших обзоров доберутся, скажем, до Эссена, но знать, что происходит на таких конференциях, полезно.
И отчёты об уже прошедших бывают полезны и интересны:
Андреас Шербаум (Andreas 'ads' Scherbaum) посетил PostgreSQL Conference Japan 2025, рассказывал про свои интервью. (заглянул и на конфу в Корее). Фото суши и разнообразных саке. Удивился некоторым особенностям: раздали всем баджики, но на них нет имён, только "организатор"/"докладчик"/"пресса". Для всех участников раздаточные материалы в бумажном виде, распечатали и слайды докладов, если спикеры передали их организаторам. А заодно он продвигал в эти страны WarehousePG - опенсорсную альтернативу Greenplum.
Генриэтта Домбровская (Henrietta 'hetty' Dombrovskaya) пишет о конференции в прериях: Prairie PostgreSQL User Group November Meetup. Prairie State - это Иллинойс, но это немного обман, т.к. прерии все там давно распахали, и в народе штат называют Кукрузным.
Он вернулся в Москву 19 марта: PG BootCamp Russia 2023 проходил в Москве. Потом - Минск, Казань Екатеринбург. И вот.
Индексы глобальные и российские
Наше всё - Брюс Момджан - высказывался на эту тему в своём блоге летом 20-го: Global Indexes: <...> Один важный сценарий использования (one big use-case) это возможность создавать индексы на секционированных таблицах так, что индексируются все дочерние таблицы, а не отдельные индексы на каждую дочернюю таблицу. Это позволило бы ссылаться на секционированную таблицу по внешнему ключу (FOREIGN KEY), в который не обязательно входит ключ секционирования; Postgres 12 позволяет это делать только когда он входит.
Другой сценарий для глобальных индексов: добавление ограничения уникальности к секционированной таблице, когда столбцы с UNIQUE не в ключе секционирования.
Третий сценарий - возможность индексировать значения, появляющиеся только в нескольких секциях в столбцах, не входящих в ключ секционирования. Тогда с глобальным индексом проверять индекс каждой секции было бы не обязательно.
Но пока что не ясно, оправдывают ли эти сценарии те архитектурные изменения, без которых невозможно реализовать глобальный индекс. Некоторое поведение можно симулировать через триггеры и пользовательские справочные таблички (user lookup tables). И большой глобальный индекс может столкнуть нас с теми же проблемами, из-за которых мы вообще ввели секционирование.
И вот мы видим, что тема по-прежнему актуальна. Дилип Кумар (Dilip Kumar, Google) докладывал на PG Conf India и будет говорить об этом на PGConf.dev 2026 (см. выше в разделе Конференции). В описании к индийскому Experimenting with a Global Index in PostgreSQL: Design, Implementation, and Challenges читаем: В этом докладе мы поделимся опытом экспериментов по реализации глобальных индексов в PostgreSQL. В интервью летом 2024 он говорит, что работает над “Global Indexes for PostgreSQL” - тогда ещё в EDB.
Об этом вспомнили не вдруг - тема то и дело всплывает.
Этот вопрос поднимали и ребята из HighGo - канадской фирмы, спонсора конференции в Ванкувере. Точнее, главный её разработчик - Кэри Хуанг (Cary Huang), он же разработчик Hornet Labs, но это, похоже, примерно одно и то же.
Разработчики в этих Hornet-HighGo были в том числе озабочены вопросом: нехорошо, что в Postgres нет глобальных индексов. Надо бы их к нему прикрутить.
Реализовать его не так сложно, если индекс по полю, которое является ключом секционирования. Если по другому полю - вот тут возникают сложности и проблемы выбора решения - чем жертвовать и ради чего.
Об этом Кэри начал говорить ещё в 2022 - предложил патч Patch: Global Unique Index и ссылался на тему в рассылке hackers: Proposal: Global Index.
Тот тред стартанул в 2019 Ибрар Ахмед (Ibrar Ahmed) из Пакистана. В интервью Андреасу Шербауму (Andreas Scherbaum) на PostgreSQL Person of the Week он, кстати, говорит интересную вещь: здесь в Исламабаде у нас хорошо представлены PostgreSQL-компании: EnterpriseDB, 2ndQuadrant [теперь тоже EBD], Percona [на момент интервью там он и работал], HighGO [!] и Bitnine [1-й раз слышу].
Так что Кэри мог с ним пересечься там. К тому же в том письме Ибрар ссылается на слова Брюса, сказанные им на PostgreSQL-Conf Asia (PGConf Asia 2018, видимо). Ибрар не просто излагает свои соображения, а подытоживает беседы на эти темы с классиками Postgres: Робертом Хаасом, Питером Гайгеном, Хеикки Линнакангасом (Robert Haas, Peter Geoghegan, Heikki Linnakangas).
Ему тогда многие возражали, особенно резко самый производительный кодописец PostgreSQL - Том Лейн (Tom Lane). Он опасался, что новшество всё разрушит: да, эффекты от внедрения глобальных индексов желательны, но это не значит, что нам нужна реализация в виде разделяемого (shared) индекса.
И вот относительно недавно, в письме Re: Proposal: Global Index for PostgreSQL - Дилип Кумар. Лето 2025. Делип - тот самый, что будет докладывать о состоянии дел на PGConf.dev 2026.
Никита Малахов (Nikita Malakhov) ссылается на другое письмо - от Кэри Хуанга: Patch: Global Unique Index - в 2022.
А Кэри ссылается на Дэвида Джана (David Zhang) - на его статью о двух подходах к проблеме и собственных конструктивных предложениях: Global Index, a different approach.
Подход 1 (комьюнити POC - Proof Of Concept): Хранение в одной таблице (single index relation) - производительность лучше, но проблемы с размером файла (block limit) и с удалением секций (очищением индекса, detach).
Подход 2 (HighGo): Раздельное хранение по секциям (separate global index relations per partition), с логикой глобального доступа/уникальности - без лимита размера.
Много проблем, а главная такая: глобального индекса в дистрибутиве сообщества так и нет, и что появится в следующей мажорной версии - гарантий тоже нет.
Ну и ладно? Кому очень нужно, те сделают? Так и произошло. Прежде всего в России. Здесь огромные базы на Postgres с огромными таблицами, здесь импортозамещение, а те, кто пришёл с Oracle, знают, что там глобальные индексы работают вовсю.
Но "ну и ладно" не пройдёт: разработчики живут одной большой семьёй в сообществе, и если сообщество выбирает не тот путь, не ту архитектуру, что частные компании уже выбрали, это усложняет процессы.
Итак:
В Postgres Pro Enterprise есть единый не секционированный глобальный индекс через расширение pgpro_gbtree: физически это один B-tree файл для всех секций с лимитом размера ~32 TB. Зато с глобальной уникальностью и быстрым поиском. Об этом написана статья:
Глобальные индексы для секций в Postgres Pro: глобальная уникальность без костылей, там сказано:
Расширение и метод доступа: функциональность реализована в расширении pgpro_gbtree. Для создания глобального индекса используется новый метод доступа gbtree. Основой gbtree являются стандартные механизмы B‑tree, но с доработками для секционированных таблиц.
Создание индекса: синтаксис создания похож на обычный, но требует наличия первичного ключа у секционированной таблицы и указания USING gbtree.
В SberTech PlatformV единый глобальный индекс с autounite локальных. Об этом рассказывается, например, здесь: СберТех обновил Platform V Pangolin: развитие глобальных индексов, режим PTRACK и другие изменения в релизе 6.3.0 и здесь: Как мы улучшили СУБД промышленного уровня Platform V Pangolin в версии 6.1.
Между прочим, панголин на слона, вроде, не сильно похож и не очень близкий его родственник: панголин это отряд китопарнокопытных, а слон родом из полукопытных.
Но не только в России сделали свои глобальные индексы. Имеются глобальные индексы в PolarDB for PostgreSQL Enterprise Edition в Alibaba Cloud. Свои глобальные индексы продвигают Citus и YugabyteDB.
Citus не реализует «классические» глобальные индексы, а использует распределённое шардирование с локальными индексами. Индексы создаются локально на каждом шарде, и запросы, не включающие ключ распределения, требуют опрос всех шардов. Статья об этом была уже в 2017, с тех пор, кажется, новых не появлялось: Postgres Parallel indexing in Citus - Citus Data.
А в YugabyteDB придумали глобальные вторичные индексы (GSI). Там индекс - это такая же распределённая сущность, как и основная таблица. Данные в индексе шардируются на основе первичного ключа самого индекса, а не на основе ключа основной таблицы. То есть строка таблицы и соответствующая ей запись в индексе могут физически находиться на разных узлах.
Есть относительно свежие югобайтовские статьи - 2023, например: Designing Distributed Indexes for Optimal Query Performance.
У Алибабы в PolarDB for PostgreSQL глобальные индексы официально прописаны в документации - Use global indexes to speed up queries and add unique constraints for partitioned tables non-partitioned keys. Есть и техническая статья с картинками - как и что, там целый раздел про глобальные индексы: Introduction to the Core Features of the Partitioned Table in PolarDB for PostgreSQL. Между прочим, в доках других PolarDB и GSI упоминаются, но не в контексте PostgreSQL.
В заключение немного философии, не очень заумной, не пугайтесь:
Философия и ИИ
Платон, R и DuckDB
"Были у нас диалоги Платона, а стали диалоги с Платоном. Собрала на скорую руку веб-приложение, которое позволяет поговорить с Платоном. Платон русский 🇷🇺, нейросеть китайская 🇨🇳, а мудрость все равно, получается, древнегреческая.
Диалоги с Платоном — это Shiny-приложение на R, в котором AI подражает Платону, отвечая на волнующие вас вопросы.
Как это работает:
В основе RAG: при каждом запросе модель ищет релевантные отрывки из русских переводов Платона в векторной базе (DuckDB + пакет ragnar (R для работы с RAG)).
Ответы генерируются моделью DeepSeek. Как выяснилось, бесплатные Ollama работают только локально или на внешнем сервере.
Под капотом shinychat, а за диалог с LLM отвечает пакет ellmer."
Это пишет Ольга Алиева, канал RAntiquity - "Об античности на языке R и не только".
Апофатический ИИ: Почему нейросети учатся через «НЕТ», и как синтетические данные убивают смысл
Одно время много говорили про апофатическое богословие. А тут - апофатический ИИ (впрочем, ИИ уже почти Бог). Надо учить, говорит автор, не тому, на что похож, а тому, чем не является. А на что похож тогда выйдет само собой. И более эффективно. Примерно так.
На этом выпуск завершаем. Завтра конференция.