Наша архитектура ближе именно к подходу Oracle с общим хранилищем. RDMA у нас как раз есть, мы писали вот в этой статье. Он есть и между всеми узлами кластера, и между Compute-нодами и shared storage. Oracle в своё время тоже пришёл к этому через Infiniband и cache fusion, потому что обычная TCP-сеть быстро становится узким местом для межузлового обмена. У нас та же идея: каждый узел должен иметь доступ ко всем данным, а не только к “своему шарду”.
При этом, координатор - не фиксированный, координатором может быть любая нода, к которой подключился клиент. Это не схема Greenplum/ClickHouse с выделенным master/coordinator, который знает всё про распределение данных.
Главная задача здесь — масштабируемость. Когда система строится вокруг общей памяти, именно память довольно быстро становится бутылочным горлышком: чем больше узлов, тем сильнее они начинают конкурировать за shared memory. Oracle придумал cache fusion, но это всё-таки протокол когерентности кэшей, а не решение проблемы быстрого горизонтального масштабирования.
Аппаратное масштабирование - не лучший вариант, т.к. нам нужно иметь какую-то физическую копию данных (шарда или всей БД, если shared nothing). Когда нагрузка приходит внезапно, быстро новые узлы поднять не получится. Но даже если мы имеем некоторое количество узлов/шардов про запас, корректная обработка данных становится проблемой, т.к. план должен учитывать распределение данных.
Shared storage решает эту проблему тем, что воркеры становятся stateless - для запуска им не нужно иметь свою копию данных, т.к. она хранится в этом самом общем хранилище. Все, что ему требуется, - это вычислительные ресурсы (ЦП и память). Поэтому за короткий промежуток времени мы сможем поднять большое количество воркеров, а при снижении нагрузки - выключить их. И все это сравнительно бесплатно.
Во всех сборках и версиях Tantor Postgres память освобождается точно так же, как и в ванильной версии PostgreSQL.
Пример для теста, который приведён в статье:
DROP TABLE IF EXISTS table1;
CREATE TABLE table1 (column1 TEXT, column2 INT);
INSERT INTO table1 SELECT array_to_string(array(
SELECT SUBSTR('ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789',((random()*(36-1)+1):: INTEGER),1)
FROM generate_series(1,256)),''), round(random()*100 )
FROM generate_series(1,2000000);
insert into table1 select * from table1;
insert into table1 select * from table1;
INSERT INTO table1 SELECT array_to_string(array(
SELECT SUBSTR('ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789',((random()*(36-1)+1):: INTEGER),1)
FROM generate_series(1,256)),''), round(random()*100 )
FROM generate_series(1,2000000);
select count(*) from table1;
\c \\
\timing on \\
set max_parallel_workers_per_gather=0;
set work_mem = '1GB';
explain (ANALYZE) SELECT t3.* FROM table1 t1
FULL JOIN table1 t2 ON t1.column2=t2.column2
FULL JOIN table1 t3 ON t3.column2=t2.column2
LIMIT 10;
замеры до теста, в середине выполнения запроса и после запроса.
"Окно" - это прежде всего о внутренних изменениях:
уже есть "взрослый" внутренний спрос, который нельзя закрыть сколь угодно улучшенным форком. Нужны именно архитектурные решения для масштабирования и эффективности
фокус конкуренции вендоров имеет смысл смещать в область архитектуры и сервиса вокруг Postgres
Мировой подход (cloud-native) очевиден. Нужно целенаправленно работать в этом направлении
Трудно, но необходимо - перейти к реальной смене парадигмы в архитектуре, поскольку этого требует наш собственный российский рынок.
Дело не только в миллиардах, но и в выборе фокуса и стратегии развития. Ключевой тезис статьи - не в констатации очередного отставания, а в попытке понять его внутренние причины внутри рамок, в которых находятся российские вендоры. Даже в неравных условиях идти по пути наименьшего сопротивления может быть не вполне верным решением. Да, у зарубежных компаний больше ресурсов, но вопрос, который мы задаём, звучит иначе: почему при массовом использовании PostgreSQL в России (что создает огромную базу для развития) мы наблюдаем в основном «прикладные решения» и форки, а не архитектурные инновации, которые, как оказывается, не всегда требуют миллиардных бюджетов, но всегда требуют иного подхода — фокуса на cloud-native, сервисных моделях и фундаментальных изменениях архитектуры с сохранением совместимости. Т.е. важна в первую очередь смена парадигмы.
Тест, как вы знаете, ранее проходила Фирма 1С, и контекст, на который вы указываете, обсуждался в том числе. Однако в рамках методологии конкретно этого теста (составленной по требованиям крупнейших компаний) основным маркером является сам факт того, что СУБД в связке с 1С:ERP проходит его при столь большом количестве пользователей.
Формирование отчетов - 4% Проведение документов - 17% Открытие форм списков документов - 19% Открытие форм документов - 17% Ввод нового документа - 17% Ввод документа на основании - 12% Печать - 11% Прочее - 3%
Есть такое) без истории pg_stat_activity и pg_locks пост-мортем блокировок мало что даёт и он часто требуется. В Tantor как раз есть отдельный раздел для анализа блокировок и истории сессий https://docs.tantorlabs.ru/tp/6.0/instances/pg_monitor/pg_m_Locks.html — можно не только видеть текущие блокировщики, но и поднимать историю по сессиям и взаимным зависимостям. Это сильно упрощает как раз тот post-mortem, о котором вы пишете. А "собрать в Grafana за час" — да, простые панели — это реально быстро, но связка событий, роли доступа, алертинг, рекомендации по конфигурации и настройкам индексов и пр. и пр. — это уже сложнее, и именно такие вещи в энтерпрайз-системах делаются "из коробки", чтобы DBA не занимались собиранием велосипедов под продакшн-нагрузками.
Мы описали решения, которые используют российские компании, и которые мы можем подробно прокомментировать по опыту. Конечно, рынок шире, и в будущем можно будет охватить и другие продукты.
Zabbix — хорошая штука, но наши клиенты делились опытом проблем с ним на больших оборотах. Он часто упирался в свою БД, и поддержка тысяч инстансов требовала много ручной работы. Связка Grafana + Prometheus показала себя более надежной и удобной в масштабировании. Похоже, в свежих версиях Zabbix улучшили HA, но еще совсем недавно этих улучшений не хватало.
Третье поколение Xeon. Сейчас самое свежее поколение для них - шестое (и седьмое в разработке). Не о десктопных же процессорах речь. К слову, в линейке Tantor XData есть и МБД на российском процессоре Baikal-S
Попытки были в 2016 году и раньше. Мы планируем сначала добавить возможность работать с временными таблицами на репликах, так как с востребованным функционалом вероятность принятия выше. В любом случае, принятие патча такой сложности в апстрим - дело небыстрое.
В практиках курса не используется docker, и СУБД Tantor Postgres также не требует docker, но может работать в контейнерах docker и виртуальных машинах. Вы привели ссылку на документацию по Платформе Тантор 5.3, платформа устанавливается как в docker-контейнерах, так и без docker с помощью Ansible. Также возможен перенос из docker на отдельную машину (физическую или виртуальную).
Наша архитектура ближе именно к подходу Oracle с общим хранилищем. RDMA у нас как раз есть, мы писали вот в этой статье. Он есть и между всеми узлами кластера, и между Compute-нодами и shared storage. Oracle в своё время тоже пришёл к этому через Infiniband и cache fusion, потому что обычная TCP-сеть быстро становится узким местом для межузлового обмена. У нас та же идея: каждый узел должен иметь доступ ко всем данным, а не только к “своему шарду”.
При этом, координатор - не фиксированный, координатором может быть любая нода, к которой подключился клиент. Это не схема Greenplum/ClickHouse с выделенным master/coordinator, который знает всё про распределение данных.
Главная задача здесь — масштабируемость. Когда система строится вокруг общей памяти, именно память довольно быстро становится бутылочным горлышком: чем больше узлов, тем сильнее они начинают конкурировать за shared memory. Oracle придумал cache fusion, но это всё-таки протокол когерентности кэшей, а не решение проблемы быстрого горизонтального масштабирования.
Аппаратное масштабирование - не лучший вариант, т.к. нам нужно иметь какую-то физическую копию данных (шарда или всей БД, если shared nothing). Когда нагрузка приходит внезапно, быстро новые узлы поднять не получится. Но даже если мы имеем некоторое количество узлов/шардов про запас, корректная обработка данных становится проблемой, т.к. план должен учитывать распределение данных.
Shared storage решает эту проблему тем, что воркеры становятся stateless - для запуска им не нужно иметь свою копию данных, т.к. она хранится в этом самом общем хранилище. Все, что ему требуется, - это вычислительные ресурсы (ЦП и память). Поэтому за короткий промежуток времени мы сможем поднять большое количество воркеров, а при снижении нагрузки - выключить их. И все это сравнительно бесплатно.
Во всех сборках и версиях Tantor Postgres память освобождается точно так же, как и в ванильной версии PostgreSQL.
Пример для теста, который приведён в статье:
замеры до теста, в середине выполнения запроса и после запроса.
"Окно" - это прежде всего о внутренних изменениях:
уже есть "взрослый" внутренний спрос, который нельзя закрыть сколь угодно улучшенным форком. Нужны именно архитектурные решения для масштабирования и эффективности
фокус конкуренции вендоров имеет смысл смещать в область архитектуры и сервиса вокруг Postgres
Мировой подход (cloud-native) очевиден. Нужно целенаправленно работать в этом направлении
Трудно, но необходимо - перейти к реальной смене парадигмы в архитектуре, поскольку этого требует наш собственный российский рынок.
Дело не только в миллиардах, но и в выборе фокуса и стратегии развития. Ключевой тезис статьи - не в констатации очередного отставания, а в попытке понять его внутренние причины внутри рамок, в которых находятся российские вендоры. Даже в неравных условиях идти по пути наименьшего сопротивления может быть не вполне верным решением. Да, у зарубежных компаний больше ресурсов, но вопрос, который мы задаём, звучит иначе: почему при массовом использовании PostgreSQL в России (что создает огромную базу для развития) мы наблюдаем в основном «прикладные решения» и форки, а не архитектурные инновации, которые, как оказывается, не всегда требуют миллиардных бюджетов, но всегда требуют иного подхода — фокуса на cloud-native, сервисных моделях и фундаментальных изменениях архитектуры с сохранением совместимости. Т.е. важна в первую очередь смена парадигмы.
Например
Об этом будем рассказывать на Инфостарте https://event.infostart.ru/2025/agenda/2443778/
Тест, как вы знаете, ранее проходила Фирма 1С, и контекст, на который вы указываете, обсуждался в том числе. Однако в рамках методологии конкретно этого теста (составленной по требованиям крупнейших компаний) основным маркером является сам факт того, что СУБД в связке с 1С:ERP проходит его при столь большом количестве пользователей.
Формирование отчетов - 4%
Проведение документов - 17%
Открытие форм списков документов - 19%
Открытие форм документов - 17%
Ввод нового документа - 17%
Ввод документа на основании - 12%
Печать - 11%
Прочее - 3%
Не только проведение документов! Замеряемые ключевые операции можно разделить на сю такие группы:
Формирование отчетов
Открытие форм списков документов
Открытие форм документов
Ввод нового документа
Проведение документов
Печать
Да, подробно все расскажем!
Это особенности организации конкретно этого тестирования. В промэксплуатации, конечно, диски можно поскромнее)
Есть такое) без истории pg_stat_activity и pg_locks пост-мортем блокировок мало что даёт и он часто требуется. В Tantor как раз есть отдельный раздел для анализа блокировок и истории сессий https://docs.tantorlabs.ru/tp/6.0/instances/pg_monitor/pg_m_Locks.html — можно не только видеть текущие блокировщики, но и поднимать историю по сессиям и взаимным зависимостям. Это сильно упрощает как раз тот post-mortem, о котором вы пишете. А "собрать в Grafana за час" — да, простые панели — это реально быстро, но связка событий, роли доступа, алертинг, рекомендации по конфигурации и настройкам индексов и пр. и пр. — это уже сложнее, и именно такие вещи в энтерпрайз-системах делаются "из коробки", чтобы DBA не занимались собиранием велосипедов под продакшн-нагрузками.
Мы описали решения, которые используют российские компании, и которые мы можем подробно прокомментировать по опыту. Конечно, рынок шире, и в будущем можно будет охватить и другие продукты.
Zabbix — хорошая штука, но наши клиенты делились опытом проблем с ним на больших оборотах. Он часто упирался в свою БД, и поддержка тысяч инстансов требовала много ручной работы. Связка Grafana + Prometheus показала себя более надежной и удобной в масштабировании. Похоже, в свежих версиях Zabbix улучшили HA, но еще совсем недавно этих улучшений не хватало.
Нет. Сейчас трейсятся только верхнеуровневые запросы, то есть результат агрегированный. Это покрывает большую часть задач.
Взгляните, вот тесты для Tantor XData 2B на Baikal-S:
Скрытый текст
А вот для Tantor XData 2Y:
Скрытый текст
В линейке используется реестровое оборудование B4com, Yadro, Aquarius, Элпитех, Baikal.
Третье поколение Xeon. Сейчас самое свежее поколение для них - шестое (и седьмое в разработке). Не о десктопных же процессорах речь. К слову, в линейке Tantor XData есть и МБД на российском процессоре Baikal-S
Попытки были в 2016 году и раньше. Мы планируем сначала добавить возможность работать с временными таблицами на репликах, так как с востребованным функционалом вероятность принятия выше. В любом случае, принятие патча такой сложности в апстрим - дело небыстрое.
В практиках курса не используется docker, и СУБД Tantor Postgres также не требует docker, но может работать в контейнерах docker и виртуальных машинах. Вы привели ссылку на документацию по Платформе Тантор 5.3, платформа устанавливается как в docker-контейнерах, так и без docker с помощью Ansible. Также возможен перенос из docker на отдельную машину (физическую или виртуальную).