СУБД по-русски: почему вместо замены «1 к 1» бизнес создает новые системы хранения и аналитики данных

Российский рынок систем управления базами данных (СУБД) в 2024 году, по данным CNews, вырос на треть — до 89,5 млрд рублей. Ожидается, что к 2030 году 93% будет занято российским ПО: уход иностранных вендоров заставил бизнес искать новые решения, а отечественные компании — ускоренно развивать собственные продукты.

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

Работа с большими данными зависит, прежде всего, от того, насколько они большие — в среднем сейчас это 50–100 терабайт, говорит Борис Кириллов, технический директор компании «Формат Кода».

На практике «большие объемы данных» — это не всегда про терабайты логов.

— Иногда бизнесу кажется, что у него BigData, а на деле это просто плохо организованные процессы, — отметил Кирилл Манжура, генеральный директор IT-компании LARD, проекта финансово-инвестиционного холдинга «ЛК МЕНЕДЖМЕНТ». — А СУБД — это инструмент, который позволяет данные не просто хранить, а управлять ими: быстро извлекать, связывать, фильтровать.

Он привел в пример случай с крупным ритейлером, который хранил данные о продажах в Excel на сетевых дисках. Итог — сбои, потерянные файлы, невозможность собрать аналитику. После того, как в компании была развернута PostgreSQL с отказоустойчивым кластером и сделана интеграция с BI, отчеты стали формироваться за минуты.

Выбор системы управления базами данных зависит от задач бизнеса.

— Универсальной единой системы, которая подойдет под все кейсы, не существует, — подчеркнул Борис Кириллов. — Если основная нагрузка транзакционная (т. е. с данными совершаются разные операции — например, покупка товаров в интернет-магазине), требуется один тип баз данных, если аналитическая — совершенно другие.

По его словам, зачастую это использование не одной СУБД, а целого комплекса: так называемого дата-озера (DataLake), хранилища (Warehouse), «побережья данных» (DataHarbor). А сейчас развивается направление DataLakehouse — гибрида между «озером» и «хранилищем».

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

Приходится выбирать соответствующую модель в зависимости от отраслевых требований и от объема данных, отметил Александр Ложков, а поскольку полной замены найти на рынке не удается, надо применять комплексные решения.

Статистики по тому, какие виды СУБД выбирают представители тех или иных сегментов рынка, нет.

— Есть общее понимание, что чаще всего выбирают реляционные СУБД для транзакционных решений — эти системы подходят также для хранения большого количества записей с разными типами соотношений. Самые известные из иностранных — Oracle, SQL Server, MicrosoftServer и т. д. — объяснил Александр Ложков. — И у нас на рынке в последние годы появилось достаточно много альтернативных решений, в основном базирующихся на PostgreSQL — это СУБД с открытым исходным кодом: на его основе создаются различные расширения и отдельные СУБД, которые с ним совместимы.

— Если у вас банковские транзакции — без реляционной модели никуда: нужна строгая структура и консистентность, — объясняет Кирилл Манжура. — Если аналитика на гигабайтах логов, то колоночные СУБД вроде ClickHouse будут оптимальны. In-memory хорошо работает в высоконагруженных сервисах, где критична скорость (например, системы бронирования).

По его словам, финансовый сектор и госсектор выбирают реляционные СУБД с сертификацией ФСТЭК — это вопрос регуляторики. E-commerce, в свою очередь, часто идёт в сторону колоночных для аналитики. Телеком и крупные сервисы предпочитают распределенные, потому что у них миллионы пользователей и огромная нагрузка.

— Здесь важно не «модно/не модно», а то, какие SLA вы обязаны обеспечивать, — подчеркнул Кирилл Манжура.

Выбор СУБД зависит от нагрузки, которая может быть транзакционной (OLTP, OnlineTransactionProcessing), аналитической (OLAP, OnlineAnalyticalProcessing) и смешанной (HTAP, HybridTransactional/AnalyticalProcessing), продолжил Борис Кириллов. Также выбор зависит от количества данных — есть строковая база (тот же Postgres), а есть колоночная — она как раз больше подходит для аналитики больших данных. В частности, по его словам, сейчас активно продвигаются решения компании Arenadata, например, ADB, который основан на Greenplum. Еще один аналитический продукт — YandexClickhouse. Что касается транзакционных БД, то основные игроки ушли с рынка и сейчас все решения основаны на Postgres, отметил эксперт.

— В нашей практике мы чаще сталкиваемся с построением DataLake и LakeHouse — в этом случае получается сложное решение, где совмещаются различные системы, — отмечает Борис Кириллов. — В целом же при миграции с Oracle происходит не копирование один в один, а «распиливание» на Postgres и еще множество систем вокруг.

Уход иностранных компаний стал мощным стимулом для развития российских СУБД.

— Наш продукт как раз появился из-за того, что на рынке не хватало части решений, — рассказал Александр Ложков. — Перед нами стояла задача импортозамещения СУБД для банковской отрасли, до этого работавшей на Oracle. Оказалось, что на рынке нет участника, который готов поддержать приоритеты финтеха в требуемые сроки и в определенной функциональной номенклатуре: необходима была поддержка некоторых функций в таком виде, чтобы не переписывать прикладное решение, которое раньше работало с Oracle. Таким образом получился наш проект FTData, который поддерживает функции PostgreSQL, плюс в нем реализованы необходимые для банковской системы функции.

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

— Миграция — это не «ctrl+c/ctrl+v»: нужно тестировать каждое приложение, переписывать запросы, проверять совместимость, — отмечает Кирилл Манжура. — В LARD мы используем кастомный набор инструментов: анализируем схемы, конвертируем хранимые процедуры, тестируем нагрузку. В одном проекте по миграции с SAP HANA мы писали промежуточный ETL-контур, чтобы бизнес не останавливался в процессе перехода. Это спасло заказчика от простоев.

По его словам, самую большую сложность при импортозамещении представляет интеграция:

— Люди боятся менять, потому что «и так работает». Еще одна сложность — нехватка специалистов по отечественным СУБД, — пояснил Кирилл Манжура. — Часто сталкиваемся с ситуацией, когда руководство готово на импортозамещение, но команда разработки «тормозит». Поэтому мы предлагаем формат «переход с поддержкой»: сначала делаем совместную инфраструктуру, а потом плавно переводим всё на новые рельсы.

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

Борис Кириллов пояснил, что при миграции на какие-то решения нужно сделать выбор между продуктом вендоров и open source.

— Большинство решений с открытым кодом еще не достигло той степени зрелости, которую можно использовать для работы в критической инфраструктуре, — объяснил он. — Там часто возникают проблемы, что-то может не работать, что-то нужно оптимизировать — и если нет команды, которая может постоянно это контролировать, то у бизнеса возникают трудности.

Поскольку один в один мигрировать с одной СУБД на другую невозможно, возникает необходимость «допилить» программное обеспечение. Этим и занимается ряд компаний, включая «Формат Кода».

— Миграция базы на 50 Гб и на 500 Тб — это разные задачи: уровень сложности растет экспоненциально, — подчеркнул Борис Кириллов. — Бывало такое, что некоторые заказчики хотели одно решение, а в процессе выяснилось, что оно не подходит и существуют архитектурные ограничения. Количество вендоров в России ограничено, и мы используем много продуктов open source, но это всегда вопрос поддержки и адаптации под конкретного клиента.

Кастомизация продуктов под конкретных заказчиков вызывает вопрос: если раньше были универсальные иностранные решения, появятся ли такие же на отечественном рынке?

— Если говорить о том, насколько реляционные СУБД как наиболее распространенные решения приблизятся по своей полноте к возможностям Oracle, то честный ответ таков: в том виде, чтобы была возможна бесшовная миграция, этого не произойдет, — считает Александр Ложков. — Но есть и другая сторона медали: далеко не все функции и возможности Oracle используются современными российскими прикладными решениями. Это новая реальность, ее уже не откатить обратно, скорее всего.

Он отметил: даже если ушедшие вендоры вновь выйдут на наш рынок, не все будут готовы к ним вернуться.

— Полного аналога Oracle не существует, и это честный факт, — подтвердил Кирилл Манжура. — Но 90% бизнес-задач закрываются российскими и open source решениями: PostgresPro, Линтер, ClickHouse. Здесь нет самоцели «заменить один в один» — нужно сохранить функциональность и контроль. Большинство задач по транзакциям, аналитике и интеграции с 1С можно решать именно на них.

— Российским продуктам пока не хватает возможностей для полноценного горизонтального масштабирования, но мы над этим активно работаем, — добавил Александр Ложков. — Отчасти это связано с тем, что у Postgres и Oracle концептуально разное строение: сделать из одного другое точно не получится, но приблизиться к этому возможно.

По его словам, сейчас многие компании — разработчики СУБД работают в разных направлениях.

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

— Сейчас идет тренд на упрощение, и нет необходимости в создании универсального комбайна, — поддержал Борис Кириллов. — Мы также сталкивались со случаями, когда люди настолько оказались завязаны на одну систему, что им самим стало тяжело ее поддерживать, потому что это превратилось в огромный неуправляемый комбайн. Плюс нагрузка была так высока, что сама база уже была на грани.

В таком случае во время миграции происходит разделение системы на несколько решений под разные задачи: для одних потоков, например, используется Postgres, для аналитики — ADB, Clickhouse. Таким образом, всегда получается комплексная задача.

— Вопрос горизонтального масштабирования во многом зависит от того, какое решение используется, а также, собственно, от размера бизнеса, — добавил Борис Кириллов. — Но для небольшого объема в 10–40 Тб того же Postgres вполне достаточно.

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

— Здесь важен принцип «минимально необходимого доступа». Никому не нужен админский доступ «на всякий случай». Плюс обязательно журналирование действий и шифрование, — поделился основными принципами Кирилл Манжура. — Бывает такое, что после проведения аудита оказывалось, что у какого-нибудь из сотрудников, например, бухгалтера, был доступ к выгрузке всей клиентской базы. Это риск не только ИБ, но и репутационный.

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

Сейчас проходят сертификационные испытания специально подготовленной для этого версии.

— Версия, отвечающая требованиям ФСТЭК, отличается от обычной, потому что требования безопасности, как правило, ухудшают производительность, — пояснил эксперт. — Поэтому у большинства поставщиков есть две версии, но работа над вариантом для ФСТЭК влияет на весь проект в целом. Например, мы в «обычную» версию планируем также внедрить решения, связанные с отказоустойчивостью.

Александр Ложков отметил, что у регулятора процесс проверки отлажен и постоянно эволюционирует. Те, кому необходима версия, отвечающая тому или иному классу доверия ФСТЭК, могут опираться на итоги сертификации.

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

Он добавил: если для бизнеса максимально важна производительность, то решение вопросов инфобеза с помощью инфраструктуры наиболее актуально, т. к. для «озер данных» защита на уровне ФСТЭК дает минус 30−40% к производительности.

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

Прежде чем менять СУБД с импортной на отечественную, надо понять — зачем это нужно, отметил Александр Ложков. Если это предписано регулятором, стоит обратиться в реестр российского ПО и найти компанию, которая там присутствует.

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

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

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

— Ключевое — это исходить из бизнес-задач, ну и из законодательства, которое иногда идет впереди бизнеса — у регуляторов в разных сферах свои требования, — говорит Борис Кириллов. — Но стандарты информационной безопасности сейчас везде достаточно высокие, и это тоже надо учитывать.

— Выбор СУБД — это всегда баланс четырех факторов, — подвел итог Кирилл Манжура. — Первое — стоимость владения: не только лицензий, но и сопровождения. Второе — безопасность, и если речь идёт о госсекторе или банках, то без сертификации ФСТЭК система просто не пройдет аудит. Третье — совместимость: СУБД должна работать в связке с 1С, отечественными ОС, средствами виртуализации. И четвёртое — поддержка. Если у продукта нет живого саппорта и понятных SLA, внедрение бессмысленно — бизнес встанет при первом же сбое.

По его словам, зрелость решения определяется временем на рынке, количеством внедрений и скоростью реакции на инциденты.

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

По прогнозам, российский рынок СУБД вырастет к 2030 году более чем в три раза — и 90% его займут отечественные производители. Эксперты отмечают тенденцию к созданию разнообразных экосистем.

— Сейчас множество вендоров предлагают не какую-то одну СУБД, а различные виды, — рассказывает Борис Кириллов. — Например, если взять компанию ArenaData, то у них есть форкPostgres, и Clickhouse, и ADB, GreenGage на основе Greenplum, PicoData и средства для DataGovernance. То есть, по сути, они предлагают множество инструментов для работы с данными — и, соответственно, идет комплексное построение системы. Они проще интегрируются, оказывают поддержку, стандартизируют мониторинг и прочее. Но при этом какой-то универсальной СУБД, наверное, не будет создано, так как сегодня это выглядит сложно реализуемым технологически.

Также эксперт прогнозирует, что компании будут делать упор на поддержку и на сертификацию ФСТЭК.

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

— Зачастую бизнес не готов менять СУБД на отечественную просто из-за непонимания того, с чем придется столкнуться, — пояснил он. — Мы тоже смотрим в эту сторону, у нас есть определенный опыт, есть инструменты, которые помогают мигрировать, есть команда, есть успешные проекты.

Что касается отдаленного будущего, то, безусловно, искусственный интеллект проникает понемногу и в аналитические системы, и в обработку данных, а некоторые включают его и в СУБД, отметил Александр Ложков.

— Будущее СУБД для российского бизнеса напрямую связано с локализацией и независимостью, — уверен Кирилл Манжура. — Очень большое значение уже сейчас приобретает интеграция с искусственным интеллектом. AI помогает оптимизировать запросы, прогнозировать пики нагрузки, находить аномалии в транзакциях. То, на что раньше уходили часы ручной работы администратора, сегодня может делаться автоматически, а человеку остаётся только принимать решение.

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

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