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 їх немає, якщо тільки ви не використовуєте спеціалізовані хмарні рішення з AI-розширеннями.

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

Що тепер можуть зробити користувачі MySQL

Якщо ваш стек використовує звичайний MySQL, у вас є три реальні шляхи:

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

Кожен варіант має свої компроміси щодо складності експлуатації, затримки (latency) та витрат на обслуговування. Рішення залежить від того, наскільки центральним елементом ціннісної пропозиції вашого продукту є векторний пошук.

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

Зміна в Laravel ілюструє ширший принцип проектування: уникайте розкидання перевірок, специфічних для бази даних, по всій основній логіці. Коли функція залежить від можливостей конкретного рушія, інкапсулюйте цю залежність за інтерфейсом драйвера. Новий підхід на основі граматики робить саме це, готуючи фреймворк до майбутніх розширень без необхідності перегляду основного конструктора запитів.

Розробникам, які створюють власні пакети, варто звернути на це увагу. Якщо ви бачите перевірки instanceof для типу бази даних всередині вашого сервісного шару, перенесіть цю відповідальність на драйвер або спеціалізований адаптер. Це дозволить підтримувати публічний API чистим і зробить ваш код стійким до майбутніх змін.