Bagisto, la plataforma de comercio electrónico de código abierto basada en Laravel, ha publicado un estudio práctico sobre la integración de MariaDB Vector para búsquedas semánticas directamente dentro de MariaDB 11.7+ (probado en MariaDB 11.8.9 LTS). El enfoque evita añadir una base de datos vectorial separada y muestra resultados reales de rendimiento y uso en un catálogo de productos.
Qué es y cómo funciona la búsqueda semántica
En lugar de buscar coincidencias de texto, MariaDB Vector usa embeddings: un modelo convierte el texto de cada producto en un vector (lista numérica de dimensión fija). Las consultas del usuario se convierten al mismo espacio vectorial y la búsqueda consiste en localizar los vectores más cercanos al vector de la consulta mediante similitud coseno y una búsqueda k‑NN (k nearest neighbours).
Bagisto concatena en un único campo de texto todos los elementos relevantes del producto (nombre, descripciones, SKU, rutas de categoría y atributos EAV no gráficos). Ese campo es el que se codifica en el embedding; otros datos pasan a un campo de metadatos usado luego para filtrar resultados por intención (precio, color, categoría, etc.).
Resultados de indexado y ocupación en disco
En las pruebas se indexaron 25.000 productos con embeddings de 1.536 dimensiones. La indexación, hecha con el propio driver de la extensión (un upsert por documento), alcanzó unas tasas medias que permiten indexar el catálogo en pocos minutos; la mayor parte de los upserts terminó en milésimas de segundo. En disco, los 25.000 vectores ocuparon cientos de megabytes, con la estructura de índice HNSW representando una parte significativa del espacio.
Latencia y concurrencia: qué esperar en la tienda
Una consulta típica («warm coat for winter hiking») ejecutada contra el kNN de MariaDB devolvió medianas de latencia que ya son percibidas como instantáneas por usuarios: medidas de ~32 ms en configuración por defecto y hasta ~10 ms de mediana con la caché del grafo en memoria. En pruebas de concurrencia, el rendimiento escaló casi linealmente hasta igualar el número de CPUs asignadas al contenedor de pruebas; con 6 núcleos y tunning, un solo servidor manejó alrededor de 1.900 búsquedas semánticas por segundo sobre el catálogo de 25.000 productos en pruebas locales.
Filtros y su impacto
Los filtros (por ejemplo, rango de precio y color) requieren combinar la búsqueda vectorial con filtros SQL. Dado que el índice vectorial devuelve candidatos por proximidad, MariaDB debe evaluar suficientes candidatos para encontrar los que también cumplan los filtros. En el estudio, añadir filtros incrementó la latencia media en la configuración por defecto (de 32 ms a 181 ms) y redujo ese impacto al ajustar la caché del grafo (media de 49 ms en la configuración afinada). Además, en la configuración por defecto alguna consulta filtrada devolvió menos resultados —un síntoma de que el motor no encontró suficientes candidatos filtrados antes de parar—; con el grafo en caché todas las consultas devolvieron el número esperado de resultados.
Ruta de degradación: búsqueda por texto
Si el proveedor de embeddings (API del modelo) no está disponible, la extensión de Bagisto define una ruta de degradación que usa búsqueda full‑text como fallback. En las pruebas esa ruta mostró latencias mucho mayores (en torno a 1 segundo) cuando el pool de buffer de InnoDB era pequeño, porque las filas son grandes (cada una incluye un vector) y la lectura de disco llega a penalizar mucho el rendimiento.
Qué deben hacer administradores y propietarios de tiendas
- Probar MariaDB Vector en un entorno de staging con una muestra representativa del catálogo para medir indexado, latencia y uso de memoria.
- Ajustar el tamaño de la caché del índice HNSW y el InnoDB buffer pool: la cache del grafo reduce notablemente la latencia de consulta; un buffer pool insuficiente penaliza el fallback full‑text.
- Observar cómo afecta la selectividad de filtros al número de candidatos que debe evaluar la búsqueda vectorial y afinar parámetros de HNSW para equilibrar precisión y rendimiento.
- Planear una estrategia de degradación si el proveedor de embeddings falla (por ejemplo, optimizar la búsqueda full‑text o disponer de un cache local de embeddings).
El informe de Bagisto ofrece un ejemplo aplicable a tiendas reales y demuestra que MariaDB Vector, integrado en MariaDB 11.7+ y especialmente en la rama LTS 11.8, puede proporcionar búsquedas semánticas con latencias adecuadas para tiendas online sin introducir una base de datos vectorial adicional.
Lee también:
- Tailscale impulsa ‘sovereign AI’ con inversión y nueva dirección para fomentar infraestructura abierta
- Linus Torvalds prueba código generado por IA para acelerar lecturas del kernel hasta 3x en un caso concreto
Fuente: MariaDB.org
