El impulso de ingeniería de Alibaba para hacer que pgvector funcione a escala de mil millones de vectores

Las bases de datos vectoriales pasaron por tres fases desde 2023: primero, soportar tipos de vectores y operadores básicos de distancia. Luego llegaron los índices de vecinos más cercanos aproximados como IVF y HNSW, reduciendo los tiempos de respuesta a milisegundos de un solo dígito. La tercera fase, la preparación para producción a escala, resultó ser la más difícil. El equipo de PolarDB para PostgreSQL de Alibaba Cloud documentó su enfoque en un artículo técnico que desglosa exactamente lo que se necesitó para convertir la extensión de código abierto pgvector en un motor que puede almacenar miles de millones de vectores y devolver resultados en milisegundos.

Cuantización: ajustando vectores grandes en huellas más pequeñas

El primer cuello de botella es el costo de almacenamiento y cómputo. Un solo vector float32 de 768 dimensiones pesa aproximadamente 3 KB. Multiplique eso por mil millones y estará viendo 3 TB de datos sin procesar antes de los índices. PolarDB para PostgreSQL ahora soporta tres esquemas de cuantización junto con los índices IVF y HNSW: Cuantización de Producto (PQ), Cuantización Escalar (SQ) y Cuantización de Bits Aleatorios (RaBitQ). Cada uno comprime un vector entre un cuarto y un sesentaicuatroavo de su tamaño original, manteniendo la precisión controlable. El equipo enfatizó que ningún esquema único se adapta a todos los escenarios, la elección correcta depende del tamaño del conjunto de datos, la concentración de características y la dimensionalidad. PQ divide los vectores en subsegmentos y entrena un libro de códigos por segmento, ofreciendo alta compresión pero un costo de entrenamiento elevado. SQ mapea cada dimensión float32 linealmente a int8 o int4, convirtiéndolo en la opción más rentable. RaBitQ utiliza transformación ortogonal aleatoria más cuantización de 1 bit, con un límite inferior de precisión demostrable en teoría.

Mejoras de rendimiento: gestión de E/S y espacio libre a escala de mil millones

Las construcciones de índices en pgvector estándar siguen el administrador de búferes de PostgreSQL: cada página escrita pasa a través del búfer compartido, adquiere un bloqueo, genera registros de write-ahead y se vacía asincrónicamente. Cuando los índices alcanzan cientos de gigabytes, ese camino se convierte en el cuello de botella principal. PolarDB introdujo lectura-escritura por lotes para construcciones de índices y una ventana de precarga para consultas. Las pruebas internas mostraron una mejora de 1.5 a 2 veces en la velocidad de construcción y consulta a escala de mil millones de vectores. Un segundo punto problemático surgió bajo inserciones sostenidas: cuando aparecen páginas libres en un índice, una nueva inserción tenía que escanear páginas de datos secuencialmente para encontrar espacio disponible. El equipo introdujo un mecanismo eficiente de gestión del Mapa de Espacio Libre (FSM). En pruebas con inserciones sostenidas a escala de mil millones de filas, la contención de E/S se redujo en un 90 por ciento y la latencia de escritura p99 se volvió notablemente más estable. Combinado con un marco de limpieza de índices rediseñado que mueve la hinchazón de un crecimiento lineal a un estado estable, el sistema mantiene la estabilidad a largo plazo incluso bajo cargas de trabajo de alta escritura y eliminación.

Mejoras del ecosistema: polar_vectorboost automatiza la búsqueda híbrida

Los equipos que adoptan la recuperación vectorial a menudo tenían que escribir grandes cantidades de lógica de consultas de fusión a mano, incrustar columnas, tokenización, rellenar datos, recomendar índices, y luego lidiar con escalas inconsistentes, clasificación de fusión faltante y estabilidad de recuperación. La extensión interna de PolarDB, polar_vectorboost, comprime esas operaciones SQL de alta frecuencia en una sola llamada de función. Una sola llamada puede agregar una columna de incrustación, tokenizar texto automáticamente, rellenar datos, recomendar un índice y registrar metadatos. Para la búsqueda híbrida, soporta dos algoritmos de fusión: Fusión de Rango Recíproco (RRF), que es insensible a la escala, y un enfoque ponderado normalizado por min-max. También une automáticamente los términos de tsquery con OR para evitar el colapso de recuperación que puede causar la unión AND predeterminada de plainto_tsquery. Un conjunto de funciones de diagnóstico, que verifican tipos de columna, consistencia de dimensiones, estado del índice y vectores NULL o de norma cero, ayuda a los desarrolladores a detectar problemas antes de que lleguen a producción.

Escenarios a gran escala: pgvector distribuido para capacidad a nivel de PB

El almacenamiento de un solo nodo eventualmente alcanza un límite, y el rendimiento de escritura está limitado por una CPU. PolarDB para PostgreSQL ha completado la adaptación distribuida de pgvector. El enfoque central se basa en tres mecanismos: distribuir datos vectoriales a través de fragmentos, cada uno con su propio índice; manejar consultas entre fragmentos con un patrón de dispersión-recolección; y soportar rebalanceo dinámico de fragmentos. El resultado son tres cambios cualitativos. El almacenamiento escala horizontalmente hasta el rango de petabytes. El rendimiento de escritura escala aproximadamente linealmente con el número de nodos. Y la recuperación ante fallos se vuelve a nivel de fragmento en lugar de a nivel de base de datos. El equipo señaló que en escenarios vectoriales, la capacidad distribuida no se trata solo de capacidad, determina si el sistema sigue siendo sostenible bajo crecimiento a largo plazo.

Capacidades fundamentales: qué lo hace de grado de producción

Las capacidades de recuperación vectorial se asientan en la capa de fundamento de la base de datos. La pila de fundamentos de PolarDB para PostgreSQL incluye optimización profunda del núcleo con replicación física, una red de alta velocidad RDMA y almacenamiento compartido distribuido. Es posible escalar hacia arriba y hacia abajo en segundos mediante una arquitectura de un escritor y múltiples lectores con capacidad en el rango de terabytes. Un motor de consultas paralelas entre máquinas ejecuta SQL de forma cooperativa entre nodos para acelerar consultas analíticas. Para almacenes de vectores a escala de mil millones, los fragmentos calientes residen en un nivel de alta velocidad mientras que los fragmentos fríos se mueven al almacenamiento de objetos, equilibrando costo y rendimiento. El equipo argumentó que la capacidad vectorial se centra principalmente en la capa de recuperación, mientras que la disponibilidad general en producción depende de la base de datos subyacente. Cada una de las cinco dimensiones aborda un cuello de botella de ingeniería clave en lugar de una sola métrica de rendimiento, y juntas transforman pgvector de una extensión de código abierto a un motor integrado que puede manejar miles de millones de vectores con tiempos de respuesta de milisegundos.