Векторный поиск в Laravel теперь поддерживает MariaDB

Laravel 13 позволяет разработчикам выполнять нативные запросы векторного поиска в MariaDB, добавляя возможности семантического поиска в экосистему Laravel без необходимости перехода на PostgreSQL.

Новая поддержка заменяет предыдущую реализацию фреймворка, ограниченную только PostgreSQL, поэтому знакомый метод whereVectorSimilarTo теперь работает напрямую с подключением к MariaDB. Если вы создаете рекомендательные системы, инструменты для поиска сходства документов или любые функции, основанные на логике «ближайшего соседа» (nearest-neighbor), это изменение устраняет серьезное препятствие.

Почему это важно

Ранее конструктор запросов Laravel определял необходимость векторного поиска с помощью проверки instanceof, которая распознавала только подключения PostgreSQL. Такой подход привязывал функцию к одному драйверу и засорял кодовую базу условными операторами, специфичными для конкретной базы данных.

В 13-й версии логика перенесена на уровень грамматики (grammar layer), и добавлены два метода, специфичных для драйвера:

  • supportsVectorDistance() — сообщает Laravel, может ли текущее подключение вычислять векторные расстояния.
  • compileVectorDistanceExpression() — формирует SQL-фрагмент, который выполняет вычисление.

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

MariaDB получает нативные функции, а MySQL — нет

MariaDB поставляется с нативными векторными функциями. В стандартном MySQL их нет, если только вы не используете специализированное облачное решение с расширениями для ИИ.

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

Что теперь могут делать пользователи MySQL

Если ваш стек использует обычный MySQL, у вас есть три реалистичных пути:

  1. Мигрировать на MariaDB — это полноценная замена для большинства рабочих нагрузок MySQL, которая дает нативную поддержку векторов, сохраняя ту же экосистему.
  2. Добавить выделенный сервис поиска — запустить легковесный экземпляр PostgreSQL параллельно с MySQL исключительно для запросов сходства.
  3. Обойтись без этого — семантический поиск является необязательным для многих приложений; если выгода не перевешивает эксплуатационные расходы, использование MySQL может оказаться прагматичным выбором.

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

Уроки проектирования API

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

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