Комментарии 11
Громкие замечания, пустые, как барабан. Мировые компании с миллиардными инвестициями, лучшиии мировыми кадрами и и доступом к мировым рынкам оказания услуг в IT "неожиданно" оказались сильнее частных Российских компаний с прикладными решениями и ограничениями на ведение бизнеса. Ужас какой...
Дело не только в миллиардах, но и в выборе фокуса и стратегии развития. Ключевой тезис статьи - не в констатации очередного отставания, а в попытке понять его внутренние причины внутри рамок, в которых находятся российские вендоры. Даже в неравных условиях идти по пути наименьшего сопротивления может быть не вполне верным решением. Да, у зарубежных компаний больше ресурсов, но вопрос, который мы задаём, звучит иначе: почему при массовом использовании PostgreSQL в России (что создает огромную базу для развития) мы наблюдаем в основном «прикладные решения» и форки, а не архитектурные инновации, которые, как оказывается, не всегда требуют миллиардных бюджетов, но всегда требуют иного подхода — фокуса на cloud-native, сервисных моделях и фундаментальных изменениях архитектуры с сохранением совместимости. Т.е. важна в первую очередь смена парадигмы.
Главный шанс для отечественных игроков – использовать представившееся окно возможностей.
Интересно, какое окно возможностей нам тут представилось ? Полявилось достаточное количество сильных инженерных команд ? Глобальные рынки, рост экономики, инвестиции ?
"Окно" - это прежде всего о внутренних изменениях:
уже есть "взрослый" внутренний спрос, который нельзя закрыть сколь угодно улучшенным форком. Нужны именно архитектурные решения для масштабирования и эффективности
фокус конкуренции вендоров имеет смысл смещать в область архитектуры и сервиса вокруг Postgres
Мировой подход (cloud-native) очевиден. Нужно целенаправленно работать в этом направлении
Трудно, но необходимо - перейти к реальной смене парадигмы в архитектуре, поскольку этого требует наш собственный российский рынок.
Не стоит скидывать со счетов, что Россия всё ещё сырьевой придаток, то есть кадры за даром утекают вне действия нашего рынка. Местный работодатель пытается лишь как-то накопить финансовый запас или вообще его сливает опять туда-же. Местный рынок стартапов - кинуть идею и продать, кто больше даст. Откуда будут серьёзные проекты? Даже скажем postges.pro,альты и астры - лишь попытка, что-то добавить к продукту, а не сделать новый продукт на основе старого.
Серьезные проекты - это всегда инвестиции и большие риски. Поэтому компании ограничиваются "косметикой". Второй важный момент - отсутствие, зачастую, 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 и создание проекта вокруг него.
Вадим, эти технические штуки, которые вы перечислили, звучат очень круто, но непонятно. Было бы очень интересно прочитать именно про них: что это, зачем, почему, например, в compute-storage separation репликация только метаданных WAL, что такое WAL pipeline и прочее. Просто от перечисления толку мало. А эта статья, например, вообще не техническая, это какая-то декларация бизнес-стратегии, я не инвестор поэтому мимо. Статья была полезна тем, что я нашёл на гитхабе neon, почитал их документацию, там рассказывают про page server, про prefetching, много интересных технических подробностей. Аналогичный материал прорекламировал бы вас лучше, чем амбициозные бизнес-статьи. Только, пожалуйста, без нейронок, эту статью читать очень больно.
Так, ну мы уже все это делаем
Физический бекап wal-g кажется знают все )
Пулер odyssey теперь в pgdg, Andy Pavlo про него тоже рассказывал
Greenplum (MPP Postgres) теперь называется cloudberry и это проект Apache
Шардированный postgres тоже есть, называется SPQR и он тоже в open-source под лицензией postgres
Можно набежать в любой проект и нанести пользу. Например, если вы используете gporca и хочется его дальнейшего развития - мы этим занимаемся в cloudberry.
И также всегда можно встретиться лично на конфе/meetup/в баре и обсудить интересные идеи, вдруг вы хотите не знаю, robust predicate transfer для PG реализовать. Welcome )
Леонид, спасибо за предложение! Идеи есть, предлагаю их обсудить на 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 активно используем у себя в продуктах и даже иногда патчим :)
Postgres по-русски: где наши Aurora, AlloyDB и Neon?