XData Gen3, это HTAP, а не MPP система (как GreenplumDB и StarRocks). То-есть позволяет работать с одними и теми же данными в OLTP профиле и OLAP (MPP) без их копирования в другой "движок". Поэтому StarRocks не хуже и не лучше, это просто другой класс СУБД, ориентированный только на аналитику.
Postgres с репликацией и чтением с реплик имеет N копий данных и все "прелести" с задержкой репликации при интенсивной записи на мастере и множество других проблем, которые были описаны в этой статье.
Что касается Exadata, то кроме заголовка, в конце статьи сделано сравнение из 26 пунктов, которые подробно раскрывают этот вопрос)
Возможно, следует еще раз перечитать статью, а то складывается впечатление, что комментарий, это реклама StarRocks :)
Андрей, привет! Да, машина доступна для тестирования. Учитывая, что вещь недешевая, с точки зрения оборудования, раздавать массово пока не получается :) но мы работаем уже над вариантом XScale в k8s, где можно будет тестировать из облака и совсем недорого. Вдруг Yandex Cloud захочет себе такой "велосипед" тоже 😉
Леонид, спасибо за предложение! Идеи есть, предлагаю их обсудить на PG BootCamp Russia 2026 19 марта, там как раз и Андрей Бородин будет :)
Что касается продукта, то к сожалению Cloudberry не решает всех тех проблем, которые решили мы в Tantor XData Gen3, плюс эта СУБД все же про MPP больше. У нас же это гибрид OLTP + OLAP, в котором действительно есть GPORCA, но вокруг нее еще много чего доработано, например Elastic Parallel Query для реализации MPP и виртуального шардинга по Shared Storage (без реальных физических шардов).
С Odyssey тоже хорошо знакомы, тестировали его у себя, но к сожалению он не справился с той нагрузкой, которая нам была необходима (сотни тысяч TPS с ребалансингом на лету при добавлении новой реплики). Да и для реализации session/transaction consistency необходима доработка СУБД, чтобы пуллер работал через ее API, поэтому пришлось тут тоже дописывать. Про SPQR Денис Волков рассказывал у нас на PgDay Israel 2024, но у нас нет шардинга, поэтому не смотрели в эту сторону. А вот WAL-G активно используем у себя в продуктах и даже иногда патчим :)
Эта статья, действительно, про стратегию, вы правы. В серии статей мы обязательно раскроем всю технику и "кишки". Каждая статья будет описывать ту или иную технологию с формулировкой проблематики, которую она решает.
Серьезные проекты - это всегда инвестиции и большие риски. Поэтому компании ограничиваются "косметикой". Второй важный момент - отсутствие, зачастую, vision на 3-5 лет и ситуативное развитие, когда "фича" делается под заказчика, чтобы мимикрировать сиюминутно под какой-нибудь Oracle или MS. Опять же, потому что клиент за это заплатит и мы снова возвращаемся к вопросу инвестиций и их окупаемости. Но с таким подходом ничего даже близкого к Amazon Aurora или AlloyDB не построить, а потребность в этом есть. Например, нам удалось реализовать реальную HTAP машину, которая может работать одновременно с OLTP и аналитической нагрузкой внутри Tantor XData Gen.3. Для этого пришлось реализовать много чего:
Compute Storage Separation с репликацией только метаданных WAL
Синхронизацию буферных кешей на репликах (RDMA)
Механизм WAL Pipeline
Commit Sequence Number (CSN)
Read Write Splitting с поддержкой session консистентности
Внедрение механизма параллельного выполнения на репликах (GPORCA)
Распределенную файловую систему для Postgres
Собственный быстрый Storage с использованием RDMA
И т д.
Это огромный проект и инвестиции, которые мы уже сделали. В ближайшее время машина будет представлена широкой публике. Есть в планах и раскрытие исходников в open source и создание проекта вокруг него.
Однако параметр STATISTICS увеличивает в гистограммах число корзин, то есть наиболее часто встречающихся значений (most_common_vals), а также массив с частотой встречаемости этих значений (most_common_freqs). Увеличение числа корзин увеличивает размер, хранимых статистик, размер таблицы системного каталога, влияет на кэш системного каталога в памяти процессов, замедляет создание плана выполнения. Хотелось бы увеличить число строк в выборке при анализе таблицы, не меняя объем хранимых статистик.
В Платформе есть снепшоты и блокировок и активных сессий с историей. Причем информация о взаимоблокировках "дообогащается" информацией, которой нет в логах и позволяет быстро понять какой процесс блокировал. Сделать подобный велосипед с парсингом логов, хождение в БД, гистограммами и т.д. уже не выглядит простой задачей. Добавим сюда возможность прям из интерфейса подключиться к БД и глянуть схему, написать свой SQL, чтобы быстро посмотреть какую-то информацию или сконфигурировать группу инстансов одним конфигом через групповые параметры или сделать анонимизированный дамп или через профилировщик найти, что не хватает индекса, и вот уже мы получаем "швейцарский нож" для DBA. Не хватает чего-то? Есть планировщик задач, где можно запустить любой SQL или bash/python скрипт и т д. И все это бесплатно, если куплена СУБД. Можно ли собрать такое на open source или бесплатных инструментах типа pgAdmin? Не уверен. Будет набор разнородных, несвязанных продуктов, скрипты и т д. А завтра сменил работу и все это хозяйство досталось новому DBA, который выбросит все и построит свой велосипед, потому что "потому" :)
Так что, если б у меня в свое время был такой кот, может я бы и не женился :)
Это очень субъективно, на мой взгляд, оценивать установку СУБД и GUI. Платформа гораздо более зрелый продукт и на рынке(в тот числе международном) с 2020 года, тогда как PPEM с конца 2023 года. Если интересно сравнение, то был целый доклад на PgConf об этом. Не знаю насколько он был объективен, не присутствовал.
Старый добрый pipelinedb умер в 2019 году. Справедливости ради, стоит отметить, что репа родилась 25 марта 2025 года, перед pgBootCamp 2025 в Екатеринбурге, о чем и был доклад.
Это opensource расширение, доступное на github по лицензии Apache 2.0 и за него платить ничего не нужно, чтобы начать использовать. Если нужна поддержка - тогда welcome к вендору.
На вскидку, например, иметь возможность управлять SLRU буфферами, при большом количестве соединений (сотни, тысячи) и транзакций(десятки-сотни тысяч). Эти патчи в ядро, есть в некоторых СУБД из вышеупомянутой статьи.
XData Gen3, это HTAP, а не MPP система (как GreenplumDB и StarRocks). То-есть позволяет работать с одними и теми же данными в OLTP профиле и OLAP (MPP) без их копирования в другой "движок". Поэтому StarRocks не хуже и не лучше, это просто другой класс СУБД, ориентированный только на аналитику.
Postgres с репликацией и чтением с реплик имеет N копий данных и все "прелести" с задержкой репликации при интенсивной записи на мастере и множество других проблем, которые были описаны в этой статье.
Что касается Exadata, то кроме заголовка, в конце статьи сделано сравнение из 26 пунктов, которые подробно раскрывают этот вопрос)
Возможно, следует еще раз перечитать статью, а то складывается впечатление, что комментарий, это реклама StarRocks :)
Мы думаем над этим. Но это будет отдельный проект, комитить в PolarDB от Alibaba не планируем, так как сильно много изменений.
Андрей, привет! Да, машина доступна для тестирования. Учитывая, что вещь недешевая, с точки зрения оборудования, раздавать массово пока не получается :) но мы работаем уже над вариантом XScale в k8s, где можно будет тестировать из облака и совсем недорого. Вдруг Yandex Cloud захочет себе такой "велосипед" тоже 😉
Леонид, спасибо за предложение! Идеи есть, предлагаю их обсудить на PG BootCamp Russia 2026 19 марта, там как раз и Андрей Бородин будет :)
Что касается продукта, то к сожалению Cloudberry не решает всех тех проблем, которые решили мы в Tantor XData Gen3, плюс эта СУБД все же про MPP больше. У нас же это гибрид OLTP + OLAP, в котором действительно есть GPORCA, но вокруг нее еще много чего доработано, например Elastic Parallel Query для реализации MPP и виртуального шардинга по Shared Storage (без реальных физических шардов).
С Odyssey тоже хорошо знакомы, тестировали его у себя, но к сожалению он не справился с той нагрузкой, которая нам была необходима (сотни тысяч TPS с ребалансингом на лету при добавлении новой реплики). Да и для реализации session/transaction consistency необходима доработка СУБД, чтобы пуллер работал через ее API, поэтому пришлось тут тоже дописывать. Про SPQR Денис Волков рассказывал у нас на PgDay Israel 2024, но у нас нет шардинга, поэтому не смотрели в эту сторону. А вот WAL-G активно используем у себя в продуктах и даже иногда патчим :)
Эта статья, действительно, про стратегию, вы правы. В серии статей мы обязательно раскроем всю технику и "кишки". Каждая статья будет описывать ту или иную технологию с формулировкой проблематики, которую она решает.
Серьезные проекты - это всегда инвестиции и большие риски. Поэтому компании ограничиваются "косметикой". Второй важный момент - отсутствие, зачастую, vision на 3-5 лет и ситуативное развитие, когда "фича" делается под заказчика, чтобы мимикрировать сиюминутно под какой-нибудь Oracle или MS. Опять же, потому что клиент за это заплатит и мы снова возвращаемся к вопросу инвестиций и их окупаемости. Но с таким подходом ничего даже близкого к Amazon Aurora или AlloyDB не построить, а потребность в этом есть. Например, нам удалось реализовать реальную HTAP машину, которая может работать одновременно с OLTP и аналитической нагрузкой внутри Tantor XData Gen.3. Для этого пришлось реализовать много чего:
Compute Storage Separation с репликацией только метаданных WAL
Синхронизацию буферных кешей на репликах (RDMA)
Механизм WAL Pipeline
Commit Sequence Number (CSN)
Read Write Splitting с поддержкой session консистентности
Внедрение механизма параллельного выполнения на репликах (GPORCA)
Распределенную файловую систему для Postgres
Собственный быстрый Storage с использованием RDMA
И т д.
Это огромный проект и инвестиции, которые мы уже сделали. В ближайшее время машина будет представлена широкой публике. Есть в планах и раскрытие исходников в open source и создание проекта вокруг него.
Судя по этой статье, не устраняет:
https://github.com/IvorySQL/IvorySQL
В Платформе есть снепшоты и блокировок и активных сессий с историей. Причем информация о взаимоблокировках "дообогащается" информацией, которой нет в логах и позволяет быстро понять какой процесс блокировал. Сделать подобный велосипед с парсингом логов, хождение в БД, гистограммами и т.д. уже не выглядит простой задачей. Добавим сюда возможность прям из интерфейса подключиться к БД и глянуть схему, написать свой SQL, чтобы быстро посмотреть какую-то информацию или сконфигурировать группу инстансов одним конфигом через групповые параметры или сделать анонимизированный дамп или через профилировщик найти, что не хватает индекса, и вот уже мы получаем "швейцарский нож" для DBA. Не хватает чего-то? Есть планировщик задач, где можно запустить любой SQL или bash/python скрипт и т д. И все это бесплатно, если куплена СУБД. Можно ли собрать такое на open source или бесплатных инструментах типа pgAdmin? Не уверен. Будет набор разнородных, несвязанных продуктов, скрипты и т д. А завтра сменил работу и все это хозяйство досталось новому DBA, который выбросит все и построит свой велосипед, потому что "потому" :)
Так что, если б у меня в свое время был такой кот, может я бы и не женился :)
Это очень субъективно, на мой взгляд, оценивать установку СУБД и GUI. Платформа гораздо более зрелый продукт и на рынке(в тот числе международном) с 2020 года, тогда как PPEM с конца 2023 года. Если интересно сравнение, то был целый доклад на PgConf об этом. Не знаю насколько он был объективен, не присутствовал.
Старый добрый pipelinedb умер в 2019 году. Справедливости ради, стоит отметить, что репа родилась 25 марта 2025 года, перед pgBootCamp 2025 в Екатеринбурге, о чем и был доклад.
Это opensource расширение, доступное на github по лицензии Apache 2.0 и за него платить ничего не нужно, чтобы начать использовать. Если нужна поддержка - тогда welcome к вендору.
Реализовано, как расширение pg_uuidv7, начиная с версии
16.8.x+и 17.5.x+Тест TPC-B(pgbench);
БД - 3TB;
Профиль нагрузки - RW, с классическим распределением нагрузки - 80% read, 20% write;
Количество одновременных пользователей - 100;
Пиковые значения TPS - 66k, среднее значение ~60k TPS
На вскидку, например, иметь возможность управлять SLRU буфферами, при большом количестве соединений (сотни, тысячи) и транзакций(десятки-сотни тысяч). Эти патчи в ядро, есть в некоторых СУБД из вышеупомянутой статьи.