Российский рынок СУБД подошел к моменту, когда для самых тяжелых корпоративных нагрузок уже недостаточно просто развивать существующие технологии. Нужны изменения на уровне архитектуры — и именно здесь начинается новый этап развития российских СУБД и машин баз данных. О том, как меняются требования заказчиков и куда движется рынок, CNews поговорил с генеральным директором «Тантор Лабс» Вадимом Яценко.

Вадим Яценко: Спрос все больше определяется задачами бизнеса. Растет объем данных, активно внедряется искусственный интеллект, компаниям нужна аналитика не на вчерашних, а на актуальных данных, появляются новые требования к их обработке.

Импортозамещение остается только одним из факторов. Для малого и среднего бизнеса острота здесь уже несколько снизилась, отечественные СУБД используются очень активно. В enterprise-сегменте, где зарубежные СУБД сохраняют позиции, заказчики подходят к миграциям гораздо взвешеннее. Просто заменить одну СУБД на другую недостаточно. Смотрят заказчики не только на то, насколько решение подходит под текущие задачи, но и сможет ли оно развиваться вместе с их информационными системами и выдерживать рост требований в будущем. СУБД выбирают с расчетом на несколько лет вперед.

Оценивается и сервис: клиентам со сложными проектами особенно важно индивидуальное сопровождение. Вендор, готовый работать с конкретными потребностями заказчика, получает преимущество.

Вадим Яценко: Заказчики оценивают перспективы разработчика — продолжит ли он работу через год или два, будет ли у него достаточно ресурсов для развития, не закроют ли акционеры это направление?

Но есть и второй вопрос — куда в целом движется его технологическая экосистема. СУБД не существует изолированно: нужны развитые инструменты управления и мониторинга, сильная ИИ-обвязка контура эксплуатации, средства резервного копирования и защиты данных, поддержка новых типов нагрузок и технологий. Важно понимать, что вендор не просто поддерживает статус-кво, дорабатывая существующий пул технологий, а способен переходить к следующему уровню — там, где должна меняться архитектура.

В начале волны импортозамещения многие компании открывали у себя направления разработки СУБД. Сейчас мы видим и обратное движение: укрупнение участников, отказ отдельных игроков от этих направлений или переход на другие решения. Мы сами с приобретением СУБД «Персей» серьезно усилили команду разработки.

В общем, фокус преимущественно на доверие к будущему вендора и его продуктовой экосистемы.

Вадим Яценко: У зарубежных разработчиков больше рынок, а значит, больше возможностей вкладывать средства в развитие. Российским компаниям приходится решать технологические задачи сопоставимого масштаба на меньшем рынке. Сокращать разрыв помогают инженерные компетенции и программное обеспечение с открытым исходным кодом, хотя не любое такое решение подойдет для конкретной задачи.

Но нужно отличать общую картину от ситуации в отдельных нишах. Например, в корпоративных решениях на базе PostgreSQL российские вендоры, по моей оценке, уже способны конкурировать с зарубежными. У нас эта технология получила широкое применение в системах, где раньше использовались другие СУБД. Заказчики предъявляют к ней требования, которые прежде адресовали крупным зарубежным поставщикам, и это заставляет развивать продукт.

Но, как я уже сказал, в enterprise-сегменте все сложнее, вопрос не только в наборе функций или оптимизации отдельных сценариев. В первую очередь мы упираемся в архитектуру самой СУБД. Нужно пересматривать наши рыночные подходы к масштабированию, повышать эффективность работы с аналитикой, ИИ, большими объемами данных. Мировые реализации PostgreSQL давно ушли от модели «форк + набор дополнительных функций» в сторону архитектурных изменений при сохранении совместимости. Мы делаем это же на нашем рынке.

Вадим Яценко: Обычно называют финансовый сектор и розничную торговлю. Но в промышленности, энергетике и топливном комплексе требования отнюдь не менее жесткие. Практически в каждом сегменте есть высоконагруженные информационные системы, от которых зависит работа всей организации. В банке таких систем может быть больше, но это не делает промышленную систему менее критичной. Требования к производительности и безопасности определяются прежде всего ее ролью в бизнесе.

У российских специалистов есть опыт работы с большими нагрузками на PostgreSQL. Я, например, участвовал в разработке системы «Платон», где эта СУБД использовалась для хранения больших объемов данных, и знаю, что миграция с программно-аппаратных комплексов «Oracle Exadata» или решений других крупных зарубежных поставщиков — это очень серьезный вызов. Нужно обеспечить не только нужную производительность, но и корпоративные функции, к которым клиент привык.

Вадим Яценко: Заказчики очень хорошо понимают сложность таких проектов. Особенно это заметно в финансовом секторе, когда речь идет о процессинговых системах. Сравнение с заменой двигателя в полете здесь вполне уместно.

В системе, от которой зависят миллионы людей, даже обновление требует подготовки: его нужно провести без остановки или с минимальным перерывом. Замена СУБД — отдельный большой проект. Часть организаций начала эту работу заранее, понимая ее объем и необходимый горизонт планирования. Другие продолжают работать на прежних системах и откладывают переход. Дело не всегда в недооценке риска. Есть дефицит квалифицированных специалистов, которые уже проводили подобные миграции. Заказчик может понимать необходимость изменений, но пока не располагать командой с нужным опытом.

Есть и другой подход: построить новую информационную систему рядом со старой, а затем переключиться между ними. Менять не только СУБД внутри приложения, а систему целиком. Такие проекты тоже есть, и для ряда заказчиков задача в такой постановке понятнее и предсказуемее.

Вадим Яценко: Да, разрыв сокращается, но здесь важно понимать, о каких решениях и нагрузках мы говорим. То, что касается PostgreSQL, находится в своей весовой категории, не более того. Наиболее серьезная часть требований корпоративного сегмента выходит за рамки возможностей этой СУБД. Около трех лет назад мы начали развивать направление машин баз данных. Одним из основных ориентиров для нас с самого начала был Oracle Exadata — такие комплексы широко использовались российскими заказчиками, и нам было важно получить сопоставимый класс решения, но на отечественной технологической базе, причем с сохранением 100% совместимости с привычным PostgreSQL.

Сегодня у нас уже третье поколение машины баз данных — Tantor XData Gen3. В наших синтетических нагрузочных тестах она показала результаты выше Oracle Exadata восьмого и девятого поколений. С десятым и одиннадцатым поколениями мы сравнение не проводили, поскольку у нас не было соответствующего оборудования для испытаний.

При этом мы не считаем, что задача решена раз и навсегда. Важно, чтобы переход с зарубежных решений не означал компромисса по производительности и возможностям, а у заказчика был технологический запас для дальнейшего роста. А интересных возможностей для дальнейших улучшений очень много.

Вадим Яценко: Еще пару лет назад переход на российские версии PostgreSQL однозначно воспринимался как риск снижения производительности. За последние два года мы очень много работали над оптимизациями для специфики «1С», в том числе над возможностями, за счет которых Microsoft SQL Server раньше смотрелась выигрышно. Речь идет не об одной или двух оптимизациях: в нашем последнем релизе их порядка пятидесяти, и важно именно само накопление. Это отдельное направление разработки, требующее глубокого понимания и СУБД, и самой платформы «1С».

Результат этой работы отражается и во внешних оценках, и в тестах. Сейчас на многих операциях наша СУБД Tantor Postgres для 1С уже показывает более высокую производительность. И работа в процессе, то есть, еще сохраняется большой потенциал для развития.

Но я бы не говорил, что после перехода на российскую СУБД заказчик автоматически получит какой-то фиксированный прирост производительности. Все зависит от конкретной конфигурации «1С», размера базы, оборудования и характера нагрузки. Но обратная связь от заказчиков весьма положительная. Вероятность получить снижение производительности становится меньше, и по многим операциям производительность может оставаться на прежнем уровне или повышаться.

Вадим Яценко: Банки всегда предъявляли жесткие требования, а теперь мы все чаще сталкиваемся с запросом на работу в нескольких центрах обработки данных (ЦОД). Если целиком выходит из строя одна площадка, система должна продолжать работу на другой. При такой архитектуре нужно учитывать расстояние между площадками, задержки синхронизации, возможную потерю данных и влияние этих механизмов на производительность.

В нашей СУБД появились инструменты, которые позволяют свести к минимуму риск потери данных при катастрофе или потере целой площадки. Мы также развиваем встроенные средства отказоустойчивости, резервное копирование и интеграцию с корпоративными системами резервного копирования.

Для банков это не новые пожелания: они привыкли к широкому набору подобных инструментов в зарубежных продуктах. Наша задача — сохранить необходимый им уровень качества при переходе на российские решения.

Вадим Яценко: Здесь играет роль совместимость с PostgreSQL. Она позволяет сохранить значительную часть существующего прикладного кода, инструментов и компетенций. Это принципиально отличает такую ситуацию от перехода между полностью закрытыми платформами.

Но не стоит, конечно, создавать иллюзию, что будто бы между любыми российскими СУБД на основе PostgreSQL можно переключиться за несколько дней. Чем больше специфических возможностей конкретного продукта используется в системе, тем выше стоимость обратной миграции.

Если вендор поверх основы создает собственные архитектурные технологии, заказчик должен понимать, какие из них имеют открытые интерфейсы, а какие создают зависимость непосредственно от конкретной платформы, какие являются технологией вчерашней, а какие условно сегодняшней или завтрашней.

Поэтому я бы ставил вопрос не так: «можно ли легко уйти от одного российского вендора к другому?». Вопрос в том, насколько архитектура выбранного решения позволяет заказчику сохранять свободу выбора в будущем. Это один из критериев, который сегодня для критических систем обязательно нужно учитывать.

Вадим Яценко: Потому что в enterprise-системах уже недостаточно просто поставить СУБД на мощный сервер. Важна вся система: процессоры, память, диски, сеть и то, как все это работает вместе с СУБД.

Когда ПАК делает сам разработчик СУБД, он отвечает за все целиком. Он знает, какие архитектурные решения заложены в СУБД, под какие нагрузки она проектировалась и как должна работать на конкретном оборудовании. Это принципиально отличается от ситуации, когда один поставщик дает сервер, другой — СУБД, а заказчик или интегратор потом должен самостоятельно свести все это в работающую систему. Для заказчика это прежде всего вопрос предсказуемости. Он получает не просто лицензию на СУБД, а готовую платформу, где аппаратная и программная части изначально спроектированы и оптимизированы друг под друга. И за конечный результат отвечает один вендор.

Вадим Яценко: Если говорить именно о непрерывности бизнеса, то вопрос не столько в самой миграции — здесь давно понятен подход с параллельной работой систем и коротким финальным переключением. Гораздо важнее, что происходит с системой дальше: как она будет справляться с пиковыми нагрузками, ИИ-нагрузками, ростом числа запросов и увеличением объемов данных.

В XData Gen3 вычислительные ресурсы можно масштабировать независимо от хранения данных. Это позволяет наращивать производительность по мере роста бизнеса, не перестраивая всю систему целиком. Для критических систем это, на мой взгляд, гораздо важнее разового выигрыша в момент миграции: заказчик получает запас масштабируемости и возможность развивать систему вместе с бизнесом.

Вадим Яценко: Tantor RAC — технология в составе XData Gen3. Продукт для рынка новый, и о многом в практике использования я пока не могу говорить подробно. Проекты идут, технология работает на реальных enterprise-нагрузках, мы получаем обратную связь, работа кипит.

Вадим Яценко: Переписывать приложение под XData Gen3 не требуется, в этом «фишка» продукта. Мы сохранили совместимость с PostgreSQL, расширениями и бизнес-приложениями, включая 1С.

Новая для DBA часть связана прежде всего с самой архитектурой машины: появляются горизонтальное масштабирование, RDMA и другие компоненты, которых нет в обычной установке PostgreSQL.

Но мы как раз стараемся не заставлять администратора вручную управлять всей этой сложностью, для этого у нас есть продвинутая система с реальным ИИ.

Вадим Яценко: Наверное, главный урок в том, что нельзя просто собрать enterprise-систему из известных компонентов и ожидать, что она сразу будет работать как промышленная машина. Enterprise-решение — это не набор галочек в спецификации. Нужно понимать, как оно будет вести себя при росте нагрузки, масштабировании и эксплуатации в течение нескольких лет. Смотрите на перспективу роста — какие будут объемы данных через несколько лет, как будет расти число запросов, что с ожиданиями от аналитики и внедрения ИИ. Платформа должна решать не только сегодняшнюю задачу, но и иметь запас по архитектуре.

И еще важно начинать такие проекты заранее. Переход критической системы — это история, которую лучше начинать до того, когда старая платформа уже уперлась в свои возможности.

Вадим Яценко: Российские машины баз данных непременно станут привычным классом корпоративной инфраструктуры. Пришло уже время перестать воспринимать такие технологии как что-то, что только когда-нибудь должно появиться. Они уже есть, они используются и спустя немного времени станут российским стандартом для самых критичных и высоконагруженных систем.