por Adam Gurary, Sheng Zhan, Ankit Vij, Vadim Antonov, Yu-Ju Huang y Dima Kotlyarov
Las búsquedas están en todas partes: descubrimiento de productos en sitios web de tiendas minoristas, consultas por voz en televisiones inteligentes, recomendaciones en cada feed y verificación de identidad al buscar cuentas. Cada una de ellas activa una solicitud por vista de página, por pulsación de tecla y por acción del usuario. A escala de consumo, esto se traduce en miles de consultas por segundo (QPS) que llegan al índice de búsqueda, con picos de tráfico que a menudo son varias veces mayores.
La búsqueda también se encuentra en la ruta crítica de los ingresos. En el sector minorista, los compradores que utilizan la búsqueda convierten a una tasa de dos a tres veces mayor que la de aquellos que simplemente navegan. En las plataformas de streaming, las recomendaciones impulsan la mayor parte de lo que ven los usuarios.
Alcanzar un nivel de QPS de producción solía significar la creación de una pila de recuperación a medida para cada aplicación. Pruebas de carga en diferentes tamaños de índice, tipos de consulta y filtros. Dimensionamiento manual de la capacidad. Configuración de equilibradores de carga delante del índice. Cada nuevo caso de uso de búsqueda reinicia el trabajo. Este problema es universal en bases de datos vectoriales, motores de búsqueda y pilas DIY.
Hoy anunciamos el escalado de alto QPS para Databricks AI Search, que ya está disponible de forma general. Los endpoints estándar ahora pueden escalarse a miles de QPS con un solo parámetro fácil de entender. Tú nos indicas tu objetivo y nosotros aprovisionamos la infraestructura para cumplirlo.
Establece target_qps en el endpoint al crearlo, o actualízalo en cualquier endpoint existente en cualquier momento a través del SDK, la API REST o la interfaz de usuario (UI) del endpoint. Databricks aprovisiona la infraestructura para alcanzar el objetivo. Sin necesidad de gestionar recuentos de réplicas, dimensionar nodos ni configurar equilibradores de carga.
La gobernanza de Unity Catalog y Delta Sync se mantienen activas. El mismo endpoint que sirvió para tu prototipo ahora se escala al tráfico de producción sin salir de la plataforma.
Tres patrones de producción en tiempo real lo requieren.
Barras de búsqueda, como la búsqueda de productos en comercio electrónico, el descubrimiento de contenido en plataformas de streaming y medios, y la búsqueda por voz en dispositivos conectados. Un cuadro de autocompletado puede activar una llamada de búsqueda por cada pulsación de tecla, por lo que los QPS se escalan con el volumen de escritura activa. Latencia afecta directamente a la conversión. Para ver una arquitectura de extremo a extremo, consulta Creación de búsquedas de productos en tiempo real en Databricks.
Sistemas de recomendación y personalización, como los paneles de "También te puede gustar" en el comercio electrónico o los feeds personalizados en plataformas de medios y streaming. Cada vista de página activa una consulta de recomendación, por lo que los picos de tráfico afectan primero a la recuperación. La latencia de recomendación se encuentra en la ruta crítica de la solicitud.
Resolución de entidades en tiempo real, como la coincidencia de identidades, la deduplicación y la búsqueda en grandes catálogos en el momento de la solicitud. Aquí, la tasa de consultas es un SLA operativo, no un pico que se pueda amortiguar.
Si observas algo de lo siguiente, probablemente necesites esto:
Declaración. Estableces un objetivo de QPS en el endpoint. Databricks calcula y aprovisiona la capacidad de cómputo para cumplir con ese objetivo. Sin recuentos de réplicas, sin dimensionamiento de nodos y sin planificación de capacidad.
Funciona con endpoints existentes. Actualiza cualquier endpoint estándar a través del SDK de Python, la API REST o la interfaz de usuario (UI). La nueva capacidad surte efecto la próxima vez que se cree o sincronice un índice en el endpoint.

Supervisión del estado de escalado. El campo scaling_info en el endpoint realiza un seguimiento del progreso a medida que pasa de SCALING_CHANGE_IN_PROGRESS to SCALING_CHANGE_APPLIED.
Observabilidad en producción. Operar un sistema de recuperación en producción requiere visibilidad de las solicitudes por segundo, la latencia de las solicitudes y el estado del endpoint. La interfaz de usuario (UI) del endpoint ahora muestra estos tres aspectos para cada endpoint.

Usa la autenticación de entidad de servicio para maximizar el rendimiento. El tráfico de la entidad de servicio se enruta a través de redes optimizadas para el rendimiento, diseñadas para cargas de trabajo de producción con altos QPS. El tráfico de tokens de acceso personal (PAT) está limitado a unas pocas decenas de QPS, lo que lo hace adecuado para prototipos pero no para producción. Consulta la guía de rendimiento para ver el tutorial completo.
Dimensionamiento. Utiliza la interfaz de usuario (UI) de observabilidad del endpoint y la integración nativa con Genie para comprender tus patrones de tráfico y configurar target_qps con suficiente margen para los picos de tráfico.
La diferencia entre el prototipo y la producción es ahora un parámetro de configuración. El escalado de alto QPS ya está disponible de forma general hoy mismo, sin necesidad de activación previa. Dos formas de empezar:
target_qps establecido en tu objetivo inicialtarget_qps para escalar el índice que ya está dando servicio a tu aplicaciónSeguimos trabajando para que la búsqueda sea más fácil de operar a escala. Para finales de este año, está previsto el escalado automático para picos de tráfico (sin planificación de capacidad ni dimensionamiento manual) y la compatibilidad con endpoints optimizados para almacenamiento.
Para profundizar más:
(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original
Suscríbete a nuestro blog y recibe las últimas publicaciones directamente en tu bandeja de entrada.