Давно не было обстоятельных интервью, тем более с таким корифеем отечественной СУБД‑разработки. В 2022 году в Postgres Professional перешла команда специалистов по Oracle, включая Марка Ривкина, который занял позицию руководителя отдела технического консалтинга. Вместе с командой он занялся адаптацией продуктов под требования крупных корпоративных заказчиков и доработкой функциональности Postgres Pro — в первую очередь для тех, кто планирует миграцию с проприетарных СУБД.
В интервью для Хабра Марк рассказал, с какими задачами столкнулись на старте, какие функции пришлось внедрять в первую очередь, как выстроена работа с разработкой и сообществом, и в чём сегодня Postgres Pro реально может заменить Oracle, а в чём — пока нет. Поговорили и про ИИ в администрировании, и про перспективы российских форков PostgreSQL, и даже о том, что бы он заложил в архитектуру, если бы проектировал СУБД с нуля. Приятного чтения!
Расскажите о себе, насколько сложно было переходить с СУБД Oracle на СУБД PostgreSQL?
Переход с Oracle на PostgreSQL оказался не таким сложным. Во‑первых, сообщество и команда Postgres Professional очень открытые и дружелюбные. Во‑вторых, сам продукт во многом схож с Oracle, что облегчает понимание. В‑третьих, структура Postgres Professional, включая подходы к пресейлу, продажам и разработке, оказалась очень похожей на ту, к которой мы привыкли в Oracle.
Однако без сложностей не обошлось. В Oracle мы получали большое количество маркетинговых материалов: презентации, брошюры — которые оставалось только локализовать и адаптировать. В случае с Postgres Pro таких материалов несколько лет назад практически не было, либо они были слишком техническими. Нам пришлось создавать все с нуля.
Аналогичная ситуация была и с обучением: существовали тренинги для администраторов баз данных и разработчиков, но не было специализированных продуктовых тренингов, которые помогли бы быстро погрузиться в особенности системы с точки зрения пресейла. Поэтому на начальном этапе приходилось активно собирать информацию у разработчиков и руководства. К счастью, руководство компании хорошо разбирается в технических деталях, что позволяло эффективно обсуждать и выявляемые проблемы, и недостающие возможности.
PostgreSQL и Postgres Pro, при всех его достоинствах, — это не Oracle, который развивается уже около 50 лет и обладает более богатым набором возможностей. Мы столкнулись с отсутствием многих привычных по Oracle механизмов. Поначалу это вызывало определённые трудности у команды — мы постоянно натыкались на ограничения: «этого нет», «так сделать нельзя».
И как руководство реагировало на такую критику и предлагаемые Вами и командой инициативы?
Сложности стали толчком к продуктивной работе. Мы оперативно составили список недостающих в Postgres Pro функций, критичных для корпоративных пользователей, и начали активное обсуждение с техническим директором Фёдором Сигаевым и заместителем генерального директора Иваном Панченко.
Результатом стал план первоочередных доработок для Postgres Pro. Команда пресейла, помимо своих прямых обязанностей, на 30–50% включилась в процесс постановки задач для разработки.
Мы не просто формировали список необходимых фич, но и помогали разработчикам понять суть требований, а затем контролировали реализацию, чтобы убедиться, что результат соответствует ожиданиям. Были случаи, когда нас недопонимали, и приходилось уточнять требования.
Например, при реализации системы управления ресурсами, аналога Resource Manager в Oracle, изначально не была добавлена возможность переключения между разными планами: дневным, ночным, праздничным и т д. После обсуждения это было исправлено. Другой пример — поддержка пакетов в стиле Oracle, которые широко используются в сложных приложениях. Пакеты — это не просто способ группировки процедур и функций, они включают области инициализации, управление областью видимости, глобальные переменные и курсоры. В PostgreSQL ничего подобного не было, что затрудняло и разработку, и миграцию. Благодаря нашей совместной работе с командой разработки в Postgres Pro Enterprise, начиная с 16 версии появилось большое количество функций, направленных именно на облегчение миграции с Oracle. Приятно видеть, что руководство и разработчики прислушиваются к нашим потребностям и включают необходимые доработки в план развития продукта.
Насколько разработка проприетарных СУБД отличается от open‑source в плане «дорожных карт», планов разработки и так далее? Если бы вы проектировали новую СУБД с нуля в 2025 году, какие принципы заложили бы в её основу?
Длительный опыт работы в Oracle сформировал определённый взгляд на стратегию развития и планирование в области СУБД. Мне импонирует подход, который исторически характерен для крупных проприетарных вендоров, таких как Oracle, — создание универсальной или конвергентной СУБД. Идея заключается в том, чтобы одна система могла эффективно обрабатывать множество различных типов данных, рабочих нагрузок (OLTP, аналитика, графы, пространственные данные) и поддерживать разные парадигмы разработки (микросервисы, ИИ, блокчейн) вместо создания множества узкоспециализированных продуктов.
Преимущества такого подхода очевидны: заказчикам не нужно изучать и поддерживать зоопарк разных баз данных. Кроме того, реальные бизнес‑приложения редко ограничиваются одним типом нагрузки — часто в рамках одной системы требуется и быстрая обработка транзакций (OLTP), и аналитические запросы, и работа с графами или геоданными. Универсальная СУБД лучше справляется с такими смешанными сценариями.
Этот фокус на универсальность, на мой взгляд, влияет и на формирование «дорожных карт». Планирование в таких компаниях часто ориентировано на долгосрочное развитие единой платформы, способной адаптироваться к новым требованиям и технологиям.
Если говорить о текущих трендах, то сейчас обязательным элементом любой «дорожной карты» как для проприетарных, так и для open‑source СУБД является интеграция технологий искусственного интеллекта. Это включает не только эффективное хранение и обработку векторных данных для задач ИИ, но и применение алгоритмов машинного обучения для внутренних нужд СУБД: упрощения администрирования, автоматической оптимизации производительности и улучшения работы оптимизатора запросов.
В Postgres Professional мы тоже уделяем этому направлению большое внимание. Например, наша исследовательская лаборатория разработала интересный инструмент ChatPPG — систему на базе ИИ, обученную на всей документации PostgreSQL и Postgres Pro. Эта система позволяет задавать вопросы о продукте на естественном языке и получать точные, развернутые ответы. Раньше для получения такой информации мне нужно было обращаться к коллегам: разработчикам или техническому директору. Теперь я могу быстро получить ответ прямо со своего компьютера. Мы считаем этот инструмент очень полезным и уже предоставили доступ к нему и нашим заказчикам, и всему сообществу. В ближайшее время ChatPPG встроим напрямую в ряд продуктов Postgres Pro, например в Enterprise Manager, в Low‑code платформу для разработки и модернизации бизнес‑приложений без навыков программирования. После этого формулировать запросы можно будет на русском или английском языках, полностью отказавшись от ручного написания SQL.
Помимо этого, лаборатория работает и над другими проектами с использованием ИИ: инструмент для генерации структуры базы данных по описанию на естественном языке и система, позволяющая формулировать SQL‑запросы на основе запросов на естественном языке, что дает возможность взаимодействовать с данными даже пользователям, не знающим SQL. Проводятся исследования в области использования ИИ для дальнейшей оптимизации выполнения запросов.
Есть целый ряд очень перспективных идей. Признаюсь, я не всегда до конца понимаю, как именно работают эти технологии — некоторые результаты кажутся почти волшебством. Но вижу, что это приносит реальную пользу и эффективно решает задачи. За такими разработками, несомненно, будущее. И конечно, если бы мы создавали СУБД с нуля сегодня, то обязательно стремились интегрировать подобные наработки с самого начала.
Вообще имеет ли смысл создавать какие‑то новые СУБД в текущих реалиях?
Вопрос о целесообразности создания новых СУБД в современных условиях действительно актуален и неоднозначен. С одной стороны, технологическое развитие не стоит на месте, порождая новые идеи и потребности — появляются новые области применения данных (интернет вещей, искусственный интеллект, блокчейн), новые типы данных и специализированные задачи. Развиваются технологии хранения (быстрые SSD), сетевые технологии, появляются специализированные аппаратные комплексы для баз данных (например, Exadata) и СУБД, работающие полностью в оперативной памяти (in‑memory).
Эти новшества часто требуют переосмысления или даже кардинального изменения архитектуры СУБД. Поэтому разработка новых, часто узкоспециализированных систем управления базами данных для решения конкретных задач не только имеет смысл, но и активно происходит.
Однако есть и другая сторона медали, объясняющая, почему новые СУБД редко вытесняют «старые» универсальные системы. Существующие СУБД, развивавшиеся десятилетиями, обладают критически важными для корпоративного уровня возможностями, которые сложно и дорого воспроизвести с нуля:
Высокая надежность. В них заложены мощные механизмы обеспечения отказоустойчивости, гарантирующие сохранность данных и минимальное время простоя даже при сбоях оборудования, ошибках пользователей или других инцидентах.
Безопасность. Реализованы продвинутые и многоуровневые средства защиты данных и контроля доступа.
Производительность. Встроены многочисленные механизмы для обеспечения высокой производительности при разнообразных нагрузках, часто способные компенсировать даже неоптимально написанные запросы.
Управляемость. Предоставляются развитые средства для администрирования, мониторинга и диагностики.
Новые СУБД, как правило, создаются для решения одной специфической задачи, часто связанной с производительностью под определенный тип нагрузки. Из‑за ограничений в ресурсах в них зачастую отсутствуют многие из перечисленных выше функций.
Эта ситуация объясняет, почему действительно новых промышленных СУБД, созданных «с нуля», появляется не так много. Хотя есть примеры, такие как проекты Майкла Стоунбрейкера в США, который известен созданием коммерческих СУБД на новых принципах, хотя и они часто фокусируются на определенных аспектах.
Недавно вышло исследование Стоунбрекера и Павло. В своих выводах они утверждают, что реляционные СУБД живее всех живых. Как вы думаете почему большинство разработчиков продолжают использовать реляционные СУБД, несмотря на рост NoSQL‑решений?
Исследование Стоунбрейкера и Павло действительно подтверждает важную тенденцию: реляционные СУБД сохраняют свои сильные позиции, и я разделяю этот взгляд. Существует несколько ключевых причин, объясняющих, почему разработчики продолжают активно их использовать, несмотря на рост популярности NoSQL‑решений.
Во‑первых, сама реляционная модель данных отличается логичностью, простотой для понимания и хорошо знакома подавляющему большинству специалистов. С ней удобно работать, и накоплена огромная база знаний. Неотъемлемой частью успеха реляционных баз является язык SQL, ставший фактическим стандартом для работы с данными. Он широко распространен, хорошо изучен, и его выразительности достаточно для большинства задач. Его влияние настолько велико, что даже для многих нереляционных систем создаются SQL‑подобные интерфейсы. Крупные вендоры реляционных СУБД продолжают развивать SQL, расширяя его возможности, вместо того чтобы предлагать совершенно новые языки.
Реляционные СУБД постоянно эволюционируют. Исторические проблемы с производительностью и масштабированием на очень больших объемах данных активно решаются производителями. Этому способствуют как непрерывные программные улучшения и оптимизации, так и развитие аппаратного обеспечения: быстрые SSD, специализированные серверы баз данных, большие объемы памяти. Мощная поддержка со стороны компаний‑вендоров, обладающих значительными ресурсами для исследований и разработок, также играет важную роль в поддержании конкурентоспособности реляционных систем.
Помимо технологических аспектов, важную роль играет прагматизм самих разработчиков. Конечных заказчиков обычно интересует работающее приложение, а не технология хранения данных под ним. Разработчики же сфокусированы на создании и поддержке этих приложений, часто в условиях ограниченного времени. Они не всегда имеют возможность или острую необходимость осваивать принципиально новые технологии, особенно если существующие инструменты справляются с задачами. Привычка, глубокое знание продукта, а также значительные затраты и риски, связанные с переходом на новую платформу, часто приводят к тому, что разработчики предпочитают проверенные решения, действуя по принципу «от добра добра не ищут».
Наконец, важно понимать, что реляционные СУБД по‑прежнему отлично подходят для двух самых распространенных классов корпоративных задач: транзакционных систем (OLTP) и аналитических систем/хранилищ данных (OLAP). Для этих сценариев они обеспечивают необходимый баланс производительности, надежности, консистентности данных и управляемости. Это не умаляет значения NoSQL‑решений — их выбирают для специфических задач, где реляционный подход не оптимален, например, работа с графами, экстремальная масштабируемость под определенные нагрузки, специфичные облачные сценарии. Однако для значительной части стандартных бизнес‑приложений реляционные СУБД остаются проверенным, надежным и эффективным выбором.
Можно ли считать PostgreSQL полноценной заменой Oracle для крупных корпоративных систем или пока ещё рано?
Во‑первых, PostgreSQL полноценной заменой Oracle не является. У него не хватает множества важных характеристик, он плохо работает с большими БД и высоконагруженными БД. Поэтому правильнее говорить не про PostgreSQL, а про Postgres Pro Enterprise. Но все равно ответ на этот вопрос неоднозначен: для одних корпоративных систем Postgres Pro Enterprise может стать полноценной заменой Oracle, для других — пока нет. Все зависит от конкретных требований к масштабу, нагрузке и функциональности системы.
В большинстве случаев Postgres Pro действительно может заменить Oracle. Это касается прежде всего OLTP‑систем с высокими требованиями к надежности, безопасности и управляемости, где размеры баз данных измеряются сотнями гигабайт или даже десятками терабайт, а количество одновременных пользователей исчисляется тысячами. Для таких весьма распространенных корпоративных систем Postgres Pro предлагает достаточный уровень производительности, надежности и функциональности, сопоставимый с западными аналогами.
Однако существуют области, где Oracle пока сохраняет уникальные технологические преимущества, делающие прямую замену затруднительной или невозможной на данный момент. В первую очередь это касается архитектуры Real Application Cluster (RAC) — решения, которое, кроме Oracle и частично IBM (аппаратно) в прошлом, никто в полной мере не реализовал.
RAC обеспечивает одновременно и горизонтальную масштабируемость производительности, и высочайшую доступность на уровне, который сложно достичь стандартными средствами кластеризации PostgreSQL.
Или специализированные аппаратно‑программные комплексы Oracle Exadata («машины баз данных»). Их архитектура с интеллектуальными ячейками хранения (smart cells), выполняющими часть обработки данных, и высокоскоростными внутренними соединениями (InfiniBand) оптимизирована для экстремальных нагрузок. Эти решения Oracle ориентированы на сверхбольшие базы данных размером в сотни терабайт или даже петабайты, с высочайшими смешанными нагрузками — OLTP и тяжелые аналитические запросы — и c потенциально десятками тысяч одновременных пользователей. Для таких систем топового уровня прямой замены Oracle на PostgreSQL и его форки пока нет. Но это только «пока» — Postgres Pro ведет работу в этом направлении.
Еще одна проблема — аналитические системы. Oracle имеет много механизмов для поддержки как OLTP, так и OLAP-нагрузки. PostgreSQL и его форки разработаны под OLTP‑нагрузку. Мы сейчас активно работаем над несколькими решениями, позволяющими Postgres Pro эффективно поддерживать оба типа нагрузки.
В условиях импортозамещения, если компания использует систему, попадающую в категорию сверхвысоких нагрузок, где критичны возможности RAC или Exadata, простой переход на PostgreSQL часто невозможен. Заказчикам приходится идти по пути перепроектирования архитектуры своих приложений, например декомпозировать монолитные системы на более мелкие, функционально разделенные сервисы, чтобы уложиться в возможности альтернативных СУБД.
Таким образом, для значительной части корпоративных систем в России, включая многие системы уровня enterprise Postgres Pro является вполне реальной и полноценной заменой Oracle. Но остается определенный сегмент самых высоконагруженных, масштабных и комплексных систем, где технологии Oracle пока не имеют прямых аналогов в мире PostgreSQL, и переход на него требует не просто миграции данных, а изменения архитектуры самих приложений.
Какие фичи Oracle или Microsoft SQL Server вам больше всего хотелось бы видеть в PostgreSQL?
Хотя PostgreSQL является очень мощной и гибкой СУБД, есть ряд возможностей, заимствованных из проприетарных систем вроде Oracle Database или Microsoft SQL Server, которые могли бы значительно его обогатить.
Если ориентироваться на Oracle, который часто выступает законодателем мод в этой области, то можно выделить несколько таких желаемых направлений.
В первую очередь, это касается технологий для обеспечения высочайшей доступности и масштабируемости. Технология Oracle Real Application Cluster (RAC), позволяющая строить активные отказоустойчивые кластеры с разделяемыми ресурсами, пока не имеет полных аналогов в мире PostgreSQL.
Полезными были бы развитые возможности оптимизированного прямого доступа к системам хранения данных, возможно, в обход некоторых уровней операционной системы, как это реализовано, например, в архитектуре Oracle Exadata для повышения производительности ввода‑вывода (ASM).
Для управления изменениями и тестирования очень ценной представляется технология Oracle Real Application Testing (RAT), которая позволяет захватывать реальную рабочую нагрузку производственной системы и реалистично воспроизводить ее в тестовых средах для оценки влияния изменений.
Ценность представляют развитые средства автоматизации и интеллектуальной помощи администратору. У Oracle существует целый класс «советчиков» (Advisors) — это программные инструменты, которые анализируют работу СУБД и предоставляют конкретные рекомендации. Например, они могут предлагать создать определенные индексы для ускорения запросов (Index Advisor), помочь переписать неоптимальные SQL‑запросы (SQL Tuning Advisor) или, что особенно важно, предоставлять пошаговые инструкции по диагностике и безопасному восстановлению системы во время критических сбоев, учитывая конкретную конфигурацию (наличие резервных копий, реплик).
Хотелось бы видеть больше встроенных механизмов, возможно, с использованием ИИ/ML, для автоматизации таких задач, как тюнинг производительности, обнаружение аномалий и проактивное администрирование. Сюда же можно отнести и дальнейшее развитие адаптивных механизмов оптимизации запросов, которые подстраивают планы выполнения под реальные данные и нагрузку.
В области управления и мониторинга, хотя для некоторых форков PostgreSQL существуют графические инструменты администрирования, диагностики, мониторинга, такие как Postgres Pro Enterprise Manager (PPEM) и другие, но они пока слабее, чем Oracle Enterprise Manager. Мы работаем над развитием PPEM до уровня функциональности, глубины интеграции и удобства использования, сравнимых с Oracle Enterprise Manager.
Наконец, интересной, хотя и сложной для реализации в PostgreSQL из‑за его архитектуры MVCC, является технология Oracle Flashback. Она предоставляет возможность «заглянуть в прошлое» и запросить состояние данных или даже откатить изменения на определенный момент времени без необходимости полного восстановления из резервной копии, что крайне полезно для исправления ошибок пользователя.
Внедрение подобных возможностей, безусловно, еще больше укрепило бы позиции PostgreSQL в сложных корпоративных средах, требующих максимальной доступности, производительности, управляемости и высокой степени автоматизации. Во многом именно на этот список мы ориентируемся в плане своих разработок.
Как вы относитесь к тенденции использования PostgreSQL как «универсальной базы» для самых разных задач, включая аналитику, OLTP и NoSQL?
Отношение к PostgreSQL как к «универсальной базе данных» сложное и зависит от конкретной задачи. Исторически PostgreSQL и его форки, включая Postgres Pro Enterprise, превосходно зарекомендовали себя для OLTP‑нагрузок (Online Transaction Processing) — обработки транзакций в реальном времени. В этой области он действительно является зрелым и мощным решением.
Ситуация с аналитикой (OLAP — Online Analytical Processing) гораздо интереснее и динамичнее. Традиционно для сложных аналитических задач и больших хранилищ данных использовались специализированные СУБД или расширенные возможности крупных проприетарных СУБД. PostgreSQL изначально не был на это рассчитан. Однако, в связи с изменениями на рынке, возникла острая потребность в отечественных решениях, способных закрыть и нишу аналитики.
Для эффективной работы с аналитикой требуются иные подходы, чем для OLTP, так как аналитические запросы часто оперируют огромными объемами исторических данных и требуют специфических оптимизаций, таких как поколоночная обработка, специальные индексы и сложные оптимизаторы для интерактивного анализа.
Существует несколько основных подходов к построению таких аналитических систем. Один из них — это создание универсальной СУБД, способной поддерживать как OLTP, так и OLAP‑нагрузки. В этом случае в ядро СУБД добавляются аналитические возможности, например, поддержка колоночной обработки в памяти, как это сделано в Oracle, что позволяет работать с разными типами нагрузок в рамках одной системы.
Другой путь — разработка специализированной СУБД, полностью оптимизированной под аналитику, часто с колоночным хранением на диске, как Greenplum или Teradata. Такие системы обычно плохо справляются с OLTP, и данные в них нужно периодически загружать из операционных систем.
Наконец, современный гибридный или Lakehouse‑подход предполагает хранение подготовленных для аналитики данных в файловых форматах, таких как Parquet, во внешних хранилищах — озера данных, объектные хранилища S3. Для их обработки используются специализированные движки или федеративные запросы из основной СУБД, которая может объединять данные из своих таблиц и внешних файлов.
И когда, на ваш взгляд, что‑то из этого появится в PostgreSQL или форках на его базе?
Мы в Postgres Professional выбрали стратегию развития по всем этим трем направлениям одновременно, так как каждое имеет свои плюсы и минусы.
Во‑первых, продолжается универсализация ядра Postgres Pro Enterprise путем добавления функций для поддержки аналитики, что позволяет использовать его для небольших и средних хранилищ данных, сохраняя все преимущества зрелой платформы.
Во‑вторых, для обработки очень больших объемов данных разрабатываются и улучшаются механизмы масштабирования и специализации, такие как Shardman. Изначально созданный для OLTP, он адаптируется для эффективного выполнения и аналитических запросов на больших распределенных данных.
В‑третьих, исследуются возможности интеграции с Lakehouse и внешними аналитическими хранилищами для сценариев с огромными объемами данных.
Какие технологические решения в PostgreSQL можно считать его «узкими местами» по сравнению с коммерческими СУБД?
Важно разграничить ванильный PostgreSQL и коммерческую Postgres Pro, где большинство этих «узких мест» мы с командой уже расшили.
Во‑первых, в «ванильном» PostgreSQL существует большая проблема — масштабируемость и высокая доступность для очень больших баз данных (VLDB) и систем с экстремальными нагрузками. «Ванильный» PostgreSQL может испытывать трудности с эффективным управлением базами данных размером более десятков терабайт и не имеет встроенных зрелых механизмов горизонтального масштабирования, таких как прозрачное шардирование или мультимастер‑кластеризация. В то время как коммерческие СУБД часто предлагают более интегрированные решения. Также в ванильном PostgreSQL, в отличие от Postgres Pro, например, отсутствуют встроенные инструменты для автоматического управления конфигурациями высокой доступности (HA), что требует использования внешних решений или проприетарных разработок вендоров.
Во‑вторых, существенным отличием является экосистема управления, мониторинга и диагностики. В свободной PostgreSQL нет комплексных графических инструментов уровня Oracle Enterprise Manager для централизованного управления и глубокого анализа производительности. Не хватает и встроенных продвинутых средств диагностики, подобных отчетам Oracle AWR, а также «советчиков» (Advisors), которые автоматически анализируют работу СУБД и предлагают рекомендации по оптимизации.
В‑третьих, есть различия в механизмах оптимизации производительности. В PostgreSQL исторически отсутствовало встроенное сжатие данных, а также не было таких продвинутых возможностей, как адаптивная оптимизация запросов (которая подстраивает планы выполнения) или развитые средства управления планами выполнения запросов. Коммерческие СУБД часто имеют более зрелые оптимизаторы.
В‑четвертых, существуют функциональные и архитектурные различия, особенно заметные при миграции с Oracle. В PostgreSQL нет прямой поддержки Oracle‑пакетов, некоторых типов коллекций (например, index‑by tables), аналогов BFILE, технологии Flashback и других специфичных конструкций, что может требовать переписывания кода приложений.
Важно подчеркнуть, что многие из этих «узких мест» «ванильного» PostgreSQL активно устраняются как сообществом, так и Postgres Professional.
Насколько конкурентоспособны российские форки PostgreSQL на международном рынке?
Анализировать в масштабах мирового рынка пока достаточно сложно, но что касается СУБД Postgres Pro Enterprise, то систему высоко оценили крупные клиенты в Индии.
Одна из причин заключается в том, что базовая, «ванильная», версия PostgreSQL сама по себе очень популярна во всем мире: она бесплатна и удовлетворяет потребности множества пользователей, особенно для не самых крупных или критичных систем. Кроме того, активная фаза разработки и усовершенствования многих российских форков пришлась на последние несколько лет, и выход на международный уровень требует времени и целенаправленных усилий, которые активизировались сравнительно недавно.
На международной арене основным конкурентом для российских форков PostgreSQL зачастую выступают не столько гиганты вроде Oracle или Microsoft, сколько другие компании, предлагающие свои расширенные версии PostgreSQL. Например, американская компания EnterpriseDB (EDB), которая также активно дорабатывает ядро PostgreSQL, стремясь приблизить его по функциональности к Oracle, хотя и без таких уникальных решений, как RAC или Exadata. По сути, EDB и российские разработчики форков идут схожими путями, добавляя в PostgreSQL возможности корпоративного уровня.
В этой конкурентной среде российские решения могут предлагать привлекательные условия, в частности, по цене и уровню технической поддержки, по сравнению с такими игроками, как EDB. Это позволяет находить своих клиентов и реализовывать проекты за рубежом.
Какие аспекты миграции с проприетарных СУБД на PostgreSQL самые сложные с вашей точки зрения?
Пожалуй, самым сложным аспектом часто оказывается миграция серверного кода: хранимых процедур, функций, триггеров и пакетов. Процедурные языки (PL/SQL у Oracle, Transact‑SQL у Microsoft) существенно отличаются от PL/pgSQL в PostgreSQL. В «ванильной» версии PostgreSQL могут отсутствовать прямые аналоги некоторых конструкций, широко используемых в проприетарных системах, например, Oracle Packages или определенные типы коллекций. Это означает, что стопроцентно автоматизировать перенос кода невозможно — значительную его часть приходится переписывать вручную, оптимизировать под новую платформу или даже выносить логику на уровень приложения. Мы в Postgres Professional стараемся облегчить этот процесс, добавляя совместимые объекты и улучшая утилиты миграции такие, как ora2pgpro и другие.
Второй крайне сложный аспект — это миграция самих данных, особенно при очень больших объемах — сотни терабайт и более — при ограниченных сроках простоя. Простой перенос данных может оказаться невозможным. Приходится использовать специализированные ETL‑средства, технологии параллельной загрузки, а также механизмы захвата изменений данных (Change Data Capture, CDC) для минимизации простоя, когда сначала переносится основной срез данных, а затем догружаются изменения, накопленные во время процесса основного переноса. Это требует тщательного планирования и специальных инструментов, например, разрабатываемый Postgres Professional инструмент ProGate.
Третья область высокой сложности — обеспечение эквивалентного уровня нефункциональных требований, таких как надежность, безопасность и управляемость. Достижение того же уровня отказоустойчивости или защиты данных, который был в исходной проприетарной системе, часто требует использования иных архитектурных подходов и инструментов в экосистеме PostgreSQL. Например, может потребоваться настройка репликации и автоматического переключения с помощью внешних инструментов (как Patroni) или вендорских решений, реализация архитектуры Active‑Active, применение специфичных для PostgreSQL средств защиты. Это требует глубокого понимания возможностей обеих платформ.
Кроме того, настройка производительности после миграции также является нетривиальной задачей. Даже если SQL‑код и структура перенесены корректно, для достижения оптимальной скорости работы в PostgreSQL почти всегда требуется тщательная настройка: сбор актуальной статистики, создание или модификация индексов, возможно, использование специфических для PostgreSQL механизмов оптимизации.
На этом фоне перенос самой структуры данных обычно является наиболее простым этапом миграции из‑за значительного сходства стандарта SQL в части DDL, хотя и здесь требуется внимание к корректному сопоставлению типов данных.
Искусственный интеллект можно отнести к эволюции СУБД? Можно ли вообще ИИ отнести к СУБД?
На вопрос, можно ли считать искусственный интеллект (ИИ) частью эволюции СУБД, можно ответить и да, и нет. С одной стороны, ИИ — это самостоятельная научная и технологическая отрасль с широчайшим спектром применений, далеко выходящим за рамки баз данных, например, в обработке естественного языка, распознавании образов или стратегических играх.
С другой стороны, ИИ все теснее переплетается с развитием СУБД и позволяет решать многие задачи, характерные для управления данными, становясь важным фактором их эволюции. Можно выделить два основных направления этого взаимодействия.
Первое направление — это интеграция средств ИИ и машинного обучения (ML) непосредственно в СУБД. Некоторые СУБД развивают возможности для построения, обучения и применения ML‑моделей (ранее это часто называлось Data Mining) прямо внутри базы данных. Логика здесь в том, что раз данные уже хранятся в СУБД, то и модели для их анализа можно строить и использовать там же, без необходимости перемещения данных во внешние специализированные системы.
Второе, и, возможно, более значимое сегодня направление — это применение ИИ для улучшения и упрощения работы с самими СУБД. Алгоритмы ИИ — нейронные сети, статистические методы — все активнее используются для автоматизации и интеллектуализации различных аспектов управления базами данных. Примеры включают генерацию SQL‑запросов или структуры базы данных на основе описаний на естественном языке, автоматическую оптимизацию запросов и настройку производительности СУБД (например, адаптивная оптимизация), интеллектуальный поиск по документации, анализ логов для выявления аномалий или узких мест, а также автоматизацию многих рутинных задач администрирования баз данных, которые традиционно выполнялись вручную.
Какую часть работы администраторов баз данных уже можно заменить ИИ, а какую вряд ли удастся автоматизировать?
К задачам, которые уже поддаются автоматизации или где ИИ выступает мощным помощником, можно отнести анализ больших объемов данных и мониторинг. Например, ИИ способен обрабатывать огромные массивы лог‑файлов, выявляя аномалии, паттерны ошибок и сворачивая множество сообщений до значимых событий, что помогает быстрее понять состояние системы. Он также может находить неочевидные корреляции между различными параметрами производительности СУБД. Кроме того, важным применением является предиктивная аналитика, когда ИИ прогнозирует будущие проблемы, такие как скорое исчерпание дискового пространства или потенциальное падение производительности, позволяя администраторам принять превентивные меры. Искусственный интеллект также используется для облегчения доступа к информации; примером могут служить чат‑боты, такие как ChatPPG от Postgres Professional, помогающие быстро находить ответы в обширной технической документации. В смежных областях ИИ помогает разработчикам и тестировщикам, например, с генерацией кода или тестов, что косвенно влияет на всю экосистему работы с базами данных.
Тем не менее, существует значительная часть работы DBA, которую вряд ли удастся полностью автоматизировать в обозримом будущем. Это касается стратегического планирования и архитектурного дизайна СУБД, где требуется глубокое понимание бизнес‑целей и технологий. Решение комплексных, нештатных проблем, уникальных сбоев или инцидентов безопасности также требует человеческой экспертизы и нешаблонного подхода. Ключевым остается понимание бизнес‑контекста для правильной реализации требований на уровне данных и обеспечение их целостности. Разработка и внедрение политик безопасности, управление соответствием нормативным требованиям и, конечно, человеческое взаимодействие — обучение коллег, коммуникация со стейкхолдерами — все это области, где человеческий фактор и суждение остаются незаменимыми.
Какой навык у администратора баз данных станет самым важным в ближайшие 5 лет?
Сложно выделить единственный «самый важный» навык, но можно определить ключевое направление развития. Исторически основное время и усилия администратора баз данных были сосредоточены на диагностике проблем, настройке производительности (тюнинге) и решении инцидентов, включая восстановление после сбоев. Представляется, что эти задачи останутся центральными и в ближайшие 5 лет.
Однако, учитывая активное развитие средств автоматизации и искусственного интеллекта, которые могут взять на себя часть рутинных операций по мониторингу или предложению стандартных оптимизаций, наиболее важным качеством для DBA станет глубокая экспертиза и способность решать сложные, нетривиальные проблемы производительности и стабильности. Это включает в себя умение диагностировать неочевидные узкие места, разбираться в корневых причинах нестандартных ситуаций и сбоев, а также фундаментальное понимание принципов работы СУБД и её взаимодействия с окружением — операционной системой, системами хранения данных и приложениями.
Именно эта способность к глубокому анализу и решению уникальных задач будет отличать высококвалифицированного специалиста. Искусственный интеллект сможет автоматизировать типовые сценарии и предложить решения на основе известных паттернов, но для диагностики и устранения действительно сложных проблем, требующих нестандартного подхода, обширного опыта и интуиции, по‑прежнему будет необходим человек. Опытные специалисты, способные быстро и эффективно находить коренные причины проблем в комплексных системах, всегда будут высоко цениться на рынке.
Почему open‑source СУБД до сих пор не вытеснили коммерческие решения, несмотря на их популярность?
Несмотря на огромную популярность open‑source СУБД, таких как PostgreSQL, коммерческие решения продолжают занимать значительную долю рынка, особенно в корпоративном сегменте. Этому есть несколько причин, связанных с различиями в моделях разработки, поддержки и позиционирования.
Во‑первых, различаются философия и темпы развития. Open‑source проекты, управляемые сообществом, как «ванильный» PostgreSQL, часто развиваются на основе консенсуса, могут быть более консервативны в принятии новых, особенно крупных или «инвазивных», изменений.
Сообщество может не ставить своей основной целью завоевание всех сегментов рынка и иногда отклоняет функциональность, ориентированную, например, на сверхбольшие или высоконагруженные системы, считая это нишей существующих коммерческих продуктов.
Разработка и принятие решений могут идти не так быстро, как того требует рынок. Коммерческие же вендоры, включая тех, кто развивает форки PostgreSQL, находятся в условиях жесткой конкурентной борьбы. Им необходимо быстро реагировать на запросы рынка, выпускать новые функции и исправления, чтобы удерживать и наращивать долю, финансировать исследования и разработки, а также обеспечивать штат сотрудников. Это заставляет их двигаться быстрее и иногда реализовывать функциональность, которую сообщество пока не готово принять.
Во‑вторых, критически важным для корпоративных пользователей является уровень технической поддержки и ответственности. При использовании бесплатной open‑source версии СУБД поддержка обычно осуществляется силами сообщества через форумы и чаты, без каких‑либо гарантий по времени ответа или результату. Для бизнеса, особенно для критически важных систем, такой подход неприемлем. Коммерческие СУБД всегда поставляются с профессиональной технической поддержкой, работающей по строгим соглашениям об уровне обслуживания (SLA), гарантирующей быстрое реагирование, помощь в решении проблем, доступ к исправлениям и глубокую экспертизу продукта, вплоть до доступа к исходному коду у разработчиков. Качество, компетентность и доступность такой поддержки часто являются решающим фактором при выборе СУБД для предприятия. Стоит отметить, что некоторые компании, развивающие форки PostgreSQL, также предлагают платную поддержку и для «ванильной» версии.
В‑третьих, нельзя сбрасывать со счетов глубину и широту функциональности, накопленную ведущими коммерческими СУБД за десятилетия развития. В некоторых специфических областях, особенно на самом высоком уровне производительности, масштабируемости и доступности, таких как архитектуры Oracle RAC или Exadata, они все еще могут предлагать решения, не имеющие полных аналогов в мире open source.
Есть ли у России шанс создать собственную СУБД мирового уровня, или слишком велико отставание от западных решений?
Вопрос о шансах России создать СУБД мирового уровня сложен и требует рассмотрения разных подходов. Если говорить о создании с нуля универсальной СУБД корпоративного уровня, способной напрямую конкурировать с такими гигантами, как Oracle или Microsoft, то перспективы выглядят крайне сложными. Разработка подобных систем требует десятилетий непрерывного развития, огромных инвестиций, наличия крупной компании с десятками тысяч сотрудников, мощного маркетинга и большой клиентской базы. Масштабы ресурсов, которыми обладают западные лидеры, и их многолетний отрыв делают создание прямого аналога «с нуля» маловероятным.
Однако это не означает полного отсутствия шансов. Во‑первых, возможно создание нишевых СУБД, которые будут лучшими в мире для решения конкретных специализированных задач. В таких областях можно достичь мирового уровня, не вступая в прямую конкуренцию по всему фронту с универсальными системами.
Во‑вторых, и это наиболее реалистичный и уже реализуемый путь, Россия активно идет по пути создания и развития форков на базе зрелых open‑source проектов, прежде всего PostgreSQL. Такие российские СУБД, как Postgres Pro, не создаются «с нуля», а используют надежную и проверенную временем основу, дорабатывая ее под требования корпоративного рынка, добавляя уникальные функции, повышая производительность, безопасность и управляемость. Этот подход позволяет избежать колоссальных затрат на разработку базового ядра и сконцентрироваться на создании конкурентных преимуществ.
Важнейшим активом России в этой области является высокий уровень технических специалистов. Российские разработчики и администраторы баз данных исторически ценятся во всем мире за глубокие знания, опыт и умение решать сложные, нетривиальные задачи. Это создает прочную основу для разработки качественных и конкурентоспособных продуктов.
Есть ли предел масштабируемости для реляционных СУБД, или можно создать решение, эффективно работающее с петабайтами данных?
Да, у любой СУБД существуют пределы масштабируемости, особенно если рассматривать традиционную реляционную систему, работающую на одном сервере. Такой подход, называемый вертикальным масштабированием (увеличение мощности одного сервера — CPU, RAM, дисков), неизбежно упирается в физические ограничения оборудования.
Однако для преодоления этих ограничений и работы с огромными объемами данных, включая петабайты, разработаны и используются различные архитектуры горизонтального масштабирования, распределяющие нагрузку и данные по множеству компьютеров:
Шардирование (Sharding) — база данных логически разделяется на независимые части (шарды), которые размещаются на разных серверах. Запросы направляются к нужным шардам, а результаты агрегируются. Этот подход позволяет значительно увеличить общую емкость и производительность, но требует специального проектирования схемы данных и приложений, а масштабируемость не является идеально линейной из-за растущих накладных расходов на координацию и межшардовые операции.
Кластеризация с разделяемыми дисками (Shared-Disk Clustering) — несколько серверов (узлов) одновременно работают с единой базой данных, расположенной на общей системе хранения. Это обеспечивает высокую доступность и хорошую масштабируемость (хотя и не строго линейную), позволяя добавлять вычислительные узлы для увеличения мощности. Однако такие системы требуют сложной настройки и имеют практические ограничения на количество узлов.
Архитектуры с разделением вычислений и хранения (Shared‑Nothing / Disaggregated Compute & Storage) — этот подход, используемый во многих современных распределенных СУБД (например, Yandex Database, ClickHouse, Greenplum) и системах обработки больших данных (как Trino поверх data lake, или Hadoop/MapReduce), предполагает физическое разделение узлов, хранящих данные, и узлов, выполняющих обработку. Данные распределяются по множеству серверов хранения, а вычислительные узлы запрашивают необходимые данные по сети для обработки. Такая архитектура потенциально обеспечивает очень высокую масштабируемость, позволяя независимо наращивать емкость хранения и вычислительные ресурсы для работы с петабайтными и даже эксабайтными объемами данных. Однако это сопряжено с накладными расходами на передачу данных по сети и сложностями в обеспечении транзакционной согласованности и низкой задержки для определенных типов запросов.
Существуют реальные примеры СУБД, в том числе на базе Oracle, работающих с петабайтными объемами данных. Системы вроде Hadoop также изначально проектировались для обработки огромных массивов информации.
Какие тенденции в развитии СУБД сейчас недооценены, но могут радикально изменить индустрию в ближайшие 5–10 лет?
Прогнозировать будущее сложно, но можно выделить несколько технологических тенденций в области СУБД, которые, возможно, сейчас недооценены, но способны существенно изменить индустрию в ближайшие 5–10 лет.
Одним из таких направлений является энергонезависимая память (Persistent Memory / Storage Class Memory). Эта технология предлагает скорость доступа, близкую к оперативной памяти (DRAM), но сохраняет данные при отключении питания, как SSD или диски, при потенциально более низкой стоимости, чем DRAM. Если такая память станет массовой и доступной, это может потребовать фундаментального пересмотра архитектуры СУБД. Современные системы делятся на дисковые (оптимизированные для медленного постоянного хранения) и in‑memory (быстрые, но ограниченные объемом RAM и теряющие данные при сбоях). Энергонезависимая память стирает эту грань, открывая путь к созданию принципиально новых движков СУБД, сочетающих скорость и надежность хранения без традиционных компромиссов. Хотя первоначальный ажиотаж вокруг этой технологии несколько утих, ее потенциал для революции в архитектуре СУБД остается огромным.
Второе направление связано с глубокой интеграцией ИИ и развитием автономных баз данных. Хотя применение ИИ в СУБД уже не новость, возможно, недооценивается степень будущей автоматизации и переход к действительно автономным СУБД. Концепция заключается в создании самоуправляемых, самооптимизирующихся и самовосстанавливающихся систем, которые минимизируют или полностью исключают необходимость ручного администрирования. Пользователь просто заказывает базу данных с нужными характеристиками через портал самообслуживания (часто в облаке), а система автоматически ее развертывает, настраивает, масштабирует, обновляет и обеспечивает работоспособность. Полная реализация этой парадигмы может радикально изменить роль DBA и подходы к эксплуатации баз данных.
Хотя технология кластеризации с разделяемыми ресурсами, подобная Oracle RAC, хорошо известна и ценится, ее сложность означает, что она остается уникальной. Появление компании, способной успешно реализовать и предложить рынку аналогичное решение, могло бы серьезно изменить расстановку сил в сегменте высокопроизводительных и высокодоступных систем.
Наконец, продолжающийся переход к облачным моделям (DBaaS) также несет в себе потенциально недооцененные долгосрочные последствия. Хотя преимущества облаков очевидны (экономичность, гибкость), вопросы зависимости от провайдеров, безопасности данных, суверенитета и рисков отключения могут привести к развитию более сложных гибридных и частных облачных стратегий для управления базами данных, особенно в крупных организациях и госсекторе.
Интервью получилось объёмным — и это закономерно. Я хотел осветить вопросы, которые не задавали Ривкину или были несильно подсвечены. На мой взгляд, материал даёт довольно интересный срез состояния PostgreSQL и его российских форков: что уже можно использовать в enterprise‑нагрузках, что пока требует доработки, а где замена Oracle невозможна без изменения самой архитектуры систем. Следующее интервью в этой серии продолжит тему. Будет другой проект, другая команда и другой взгляд на то, как строить инфраструктуру на базе open source.
