Автономные СУБД на основе ИИ: эволюция вместо революции

#Уголок_профессора

Терминология и исторический контекст

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

Исторически все достижения человека были направлены на облегчение его жизни. Египтянам надоело таскать каменные глыбы для постройки пирамид, и они стали применять краны и блоки. Все науки изначально развивались как обобщение и расширение имеющегося опыта, позволяющего уже с теоретической позиции подходить к сложным практическим задачам. Появление одной из важнейших концепций математики — нуля — у индийских математиков было связано вовсе не с желанием оставить след в истории, а c необходимостью упрощения самого счёта путем перехода на позиционную систему исчисления. Дальнейшее увеличение объемов и сложности вычислений привело к появлению в начале механических счетных машин (арифмометров), а затем — их электронных потомков. Рост общего количества вычислений неизбежно двигал эволюцию и средств хранения результатов — от перфокарт к магнитным и оптическим носителям. Потому вполне логичным выглядит обобщение правил обращения с данными (управления ими) в виде реляционной алгебры, получившей наибольшую известность с выходом в 1970-х годах работ Э. Кодда. И вот уже полвека разработанный математический аппарат, пусть и в адаптированном виде, исправно трудится как в небольших решениях — например, SQLite, так и в крупных коммерческих СУБД — Oracle, MS SQL, DB2.

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

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

• самоадаптируемые 1970–1990;
• самонастраивающиеся 1990–2000;
• облачные 2010–...

Эволюция адаптации и первые подходы к автоматизации

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

Конечно, крупные вендоры — такие как Oracle, общаясь с бизнесом и понимая его потребности, задумались об облегчении и без того непростой жизни компаний, взяв на себя некоторую работу по подкрутке регуляторов поведения СУБД. Изначально автонастройка была в очень простом виде: как расчет «производных» регуляторов от значений «базовых». Например, отдать под определенные буферы некоторый процент выделенной СУБД памяти. Это тот самый процент, который стал результатом фидбэка от бизнеса и работы над реальными кейсами заказчиков команды инженеров вендора. Ими же были созданы и способы его расчета. Это своего рода реализованные в коде best practices. Конечно, даже эти апробированные решения нельзя считать универсальными: заказчики разные, масштабы их баз, аппаратные средства и характеры нагрузок — тоже. И Oracle реализовал компромиссный вариант в виде механизма «советников» (advisors). Механизм развивается уже весьма продолжительное время — как минимум с версии Oracle 12c, выпущенной в середине 2013 года. «Советников» Oracle предлагает немало — как по части взаимодействия СУБД с внешним (по отношению к ней) окружением, так и по тюнингу SQL-ядра. Для Postgres можно отметить оптимизаторы запросов geqo (на основе генетических алгоритмов) и aqo (на основе алгоритмов машинного обучения для PostgresPro).

Следующим этапом развития концепции адаптируемости и «облегчения жизни» можно считать появление концепции автономной базы данных, выполняющей функции самоуправляемости, самозащиты и самовосстановления. Одна из мотиваций необходимости автономности — затраты на ручной труд администраторов по поддержанию производительности СУБД. Согласно приводимым в отраслевых публикациях данным, 72% ИТ-бюджетов может уходить на сопровождение эксплуатируемых систем, а до 75% стоимости обслуживания СУБД — на оплату труда. Именно эти цифры часто служат аргументом в пользу автоматизации.

Важно, однако, отметить, что большинство реализованных на сегодняшний день автономных функций, в том числе в решениях Oracle Autonomous Database, Amazon RDS и аналогичных, предполагают работу в облачной среде или в хорошо унифицированных виртуализированных инфраструктурах. Разнородное аппаратное обеспечение замещается слоем виртуализации, поверх которого работают автоскейлеры, средства резервного копирования и другие компоненты автоматизации.

Роль искусственного интеллекта: возможности и ограничения

В дискуссиях об автономных СУБД часто звучит тезис о том, что технологии искусственного интеллекта (ИИ) позволят в будущем отказаться от администраторов баз данных или кардинально сократить их участие. Сторонники такого подхода указывают на высокую долю ручного труда в стоимости владения и на прогресс в области машинного обучения.

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

Обывательское отношение к ИИ предполагает сбор «сливок» без учета реальных трудозатрат на подготовку модели и объема вычислительной работы, что можно выразить в стоимости электроэнергии как переменной части и стоимостях оборудования и затрат на его поддержание в рабочем состоянии как постоянной части. В США обсуждается необходимость постройки новых АЭС для удовлетворения энергетических нужд дата-центров, в которых должны размещаться вычислительные мощности все большего числа нейросетей.

Сейчас ИИ пытается ускоренно пройти путь «от мэйнфрейма до ноутбука», не имея при этом, по мнению некоторых экспертов, предпосылок для качественных сдвигов в энергоэффективности. Машинное обучение и нейросети развивались волнами, достигая пределов своих концептуальных возможностей или упираясь в ограничения ресурсов. Первый кризис нейросетей в 1970-е был вызван не экономическим шоком, а доказанной известным американским учёным в области искусственного интеллекта Марвином Минским ограниченностью способности персептрона к представлению логических операций (невозможность создания на персептроне операции xor). Позже стали появляться другие архитектуры нейросетей, модели нейронов, функции активации. С середины 1970-х область ИИ прошла путь от «кустарщины» до «фабричного многономенклатурного производства».

На современном этапе начинают вступать в силу ресурсные ограничения. Рост совокупного числа нейронов в нейросетях порождает требования к вычислениям, памяти, долговременному хранению. Рост сложности нейросетей, вероятно, будет продолжаться по мере усложнения задач. Создание и обучение крупных моделей с нуля остается дорогостоящей задачей, доступной преимущественно крупным игрокам. В то же время для узкоспециализированных задач (например, настройки параметров СУБД под конкретную нагрузку) в последние годы появились более легковесные подходы: малые языковые модели (SLM), методы эффективной адаптации (LoRA, PEFT), позволяющие дообучать модели на относительно небольших объемах данных. Это снижает порог входа, но по-прежнему требует высокой квалификации команды.

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

Вместе с тем, гибридные и локальные архитектуры продолжают активно развиваться: модели могут работать в изолированном контуре предприятия (on premise) или в приватном облаке. Технологии малых языковых моделей и методов адаптации позволяют разворачивать ИИ-компоненты без обязательного доступа в публичные сегменты интернета. Таким образом, зависимость от сети не является абсолютным ограничением, но представляет собой один из сдерживающих факторов, который необходимо учитывать при проектировании систем.

Экономика автоматизации: две модели и гибридные сценарии

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

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

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

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

На практике все чаще встречается гибридный подход, при котором:

• на автоматизацию возложены рутинные операции (мониторинг, подбор базовых параметров, простые корректировки);
• человек сосредотачивается на архитектурных решениях, нештатных ситуациях и стратегическом развитии;
• ИИ-компоненты используются как советники (advisors), а не как полностью автономные управляющие системы.

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

Заключение: текущее состояние и ближайшие перспективы

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

Приведём в пользу этого факты, которые можно считать устоявшимися:

• Существует устойчивый тренд на автоматизацию рутинных операций администрирования.
• Крупные вендоры (Oracle, Microsoft, Google Cloud, Amazon) предлагают облачные решения с элементами автономности.
• Инструменты на основе машинного обучения (например, AQO для PostgreSQL) показывают свою эффективность для решения узких задач, таких как оптимизация запросов.

Однако несколько важных вопросов по-прежнему остаются открытыми. А именно:

• Сможет ли развитие методов эффективного обучения (SLM, PEFT) сделать ИИ-компоненты автономных СУБД доступными для широкого круга организаций, а не только крупных игроков?
• Будут ли найдены архитектурные решения, позволяющие сочетать высокую степень автоматизации с требованиями информационной безопасности и изолированности сред?
• Как изменится роль администраторов баз данных: произойдет ли их массовое сокращение или, скорее, трансформация функций в сторону более сложных и стратегических задач?

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

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