CocoIndex apoya Qdrantnativo- la integración cuenta con una pila Rust de alto rendimiento con procesamiento incremental de fin a fin para la escala y la frescura de los datos. 🎉 Acabamos de lanzar nuestro último cambio que trataautomatic target schema setupcon Qdrant de CocoIndex flujo de indexación.
Esto significa que los desarrolladores no necesitan realizar ninguna configuración de esquema - incluyendo la configuración de tablas, tipos de campos, claves e índices para tiendas de destino. La configuración es el resultado de la inferencia de esquemas de la definición de flujo de CocoIndex. Ya se apoya con la integración nativa con Postgres, Neo4j y Kuzu. Esto permite un funcionamiento más suave entre las tiendas de indexación y de destino.
No más configuración manual
Anteriormente, los usuarios tenían que crear manualmente la colección antes de indexar:
curl -X PUT 'http://localhost:6333/collections/image_search' \
-H 'Content-Type: application/json' \
-d '{
"vectors": {
"embedding": {
"size": 768,
"distance": "Cosine"
}
}
}'
Con el nuevo cambio, el usuario no necesita hacer ninguna gestión manual de la colección.
Cómo funciona
Siguiendo el modelo de programación de flujo de datos, el usuario define un flujo, donde cada paso tiene información de tipo de datos de salida, y la siguiente configuración toma información de tipo de datos.ejemplo(~100 líneas de Python de final a final)
En resumen, se puede presentar como el siguiente gráfico lineal.
En el flujo de datos declarativo como arriba
Objetivo = fórmula (fuente)
Implica tanto los datos como el esquema objetivo esperado. Una definición de flujo único impulsa tanto el procesamiento de datos (incluido el manejo de cambios) como la configuración del esquema objetivo, proporcionando una única fuente de verdad para los datos y el esquema.Tipo de inferencia(Por ejemplo, el descanso
En el flujo de indexación, la exportación de embeddings y metadatos directamente a Qdrant es todo lo que necesita.
doc_embeddings.export(
"doc_embeddings",
cocoindex.storages.Qdrant(collection_name=QDRANT_COLLECTION),
primary_key_fields=["id"],
)
Para iniciar un proceso CocoIndex, los usuarios deben ejecutar primero la configuración, que cubre toda la configuración necesaria para cualquier backend necesario.
cocoindex setup main.py
cocoindex setup
- Crear nuevos backends para la configuración del esquema, como tablas/colecciones/etc.
- Alterar los backends existentes con el cambio de esquema - intentará hacer una actualización no destructiva si es posible, por ejemplo, las claves primarias no cambian y el soporte de almacenamiento de destino actualiza el esquema en el lugar (por ejemplo, ALTER TABLE en Postgres), de lo contrario caer y recrear.
- Descarga de los backend.
Los desarrolladores corren
cocoindex update main.py [-L]
para iniciar una tubería de indexación (-L para el funcionamiento largo).
Si ha realizado actualizaciones lógicas que requieren que se actualice el esquema en la tienda de destino, no se preocupe.cocoindex updatede nuevo después de la actualización de la lógica. CocoIndex inferirá el esquema para la tienda objetivo.cocoindex setupComo opción de diseño, CocoIndex no actualizará ningún esquema sin su aviso, ya que algunas actualizaciones de esquemas pueden implicar cambios destructivos.
Para dejar caer un flujo, correrías
cocoindex drop main.py
cocoindex dropDeja caer la caída al caer el flujo.
Todas las entidades de backend para las tiendas de destino, como una tabla de PostgreSQL o una colección de Qdrant, son propiedad del flujo como datos derivados, por lo que también se eliminarán.
¿Por qué la inferencia de esquema objetivo automático?
La pregunta debería ser, ¿por qué no?
La forma tradicional es que los usuarios se enteren completamenteCuandoyCómopara configurar/actualizar el propio esquema objetivo, incluido el esquema específico. Los flujos de indexación a menudo abarcan varios sistemas.
En la tienda de destino:
- Bases de datos vectoriales (PGVector, Qdrant, etc.)
- Bases de Datos Relacionales (PostgreSQL)
- Bases de datos de gráficos (Neo4j, Kuzu, etc.)
Los tipos de datos que está exportando y su esquema objetivo deben coincidir.
Si existe algún seguimiento de estado interno, por ejemplo, en el caso de procesamiento incremental
- Tablas internas (tracking de estado)
Es aburrido y doloroso hacer esto manualmente, ya que todos estos sistemas deben estar de acuerdo en el esquema y la estructura.
- Configuración y sincronización manual de esquemas.
- Coordinación estrecha entre desarrolladores, DevOps y ingenieros de datos - las personas que escriben el código pueden no ser las mismas personas que lo implementan / ejecutan en una organización.
- Debugging los desequilibrios entre la lógica de flujo y las capas de almacenamiento.
- El rollout de la producción es típicamente estresante.
Cualquier adición de partes en movimiento al sistema de tuberías de indexación agrega fricciones - cualquier desacuerdo entre la lógica y el esquema de almacenamiento podría resultar en fallas silenciosas o errores sutiles.
- En algunos casos, no se trata de fallos silenciosos. El fracaso debe ser obvio, por ejemplo, si los usuarios olvidan crear una tabla o colección, simplemente se equivocará al escribir al objetivo.
- Algunos otros escenarios pueden conducir a problemas no obvios, es decir, fuera de sincronización entre el almacenamiento para los estados internos y el objetivo. por ejemplo, los usuarios pueden bajar el flujo y recrear, pero no lo hacen para el objetivo; o bajar y recrear el objetivo, pero no lo hacen para el almacenamiento interno.
Los cambios continuos en un sistema introducen dolor persistente en la producción. Cada vez que se actualiza un flujo de datos, el esquema objetivo debe evolucionar al mismo tiempo.noUn proceso aburrido de una vez, pero una fuente continua de fricción.
En los sistemas de datos del mundo real, los nuevos campos a menudo necesitan indexar, los viejos se deprecian y las transformaciones evolucionan.Si un tipo cambia, el esquema debe adaptarse.Estos cambios aumentan la complejidad y subrayan la necesidad de una infraestructura más resiliente y adaptable.
Siguiendo el modelo de programación de flujo de datos, cada paso es derivado de datos todo el camino hasta el final.Infraestructura de indexación requiere la coherencia de datos entre la tubería de indexación y los almacenes de destino, y los extremos menos soltos, más fácil y más robusto será.
Nuestra visión: Indexación Declarativa y Basada en Flujos
Cuando comenzamos CocoIndex, nuestra visión era permitir que los desarrolladores definieran la lógica de transformación de datos e indexación declarativamente, y CocoIndex hizo el resto.automatic schema setup.
Estamos comprometidos a cuidar de la infraestructura subyacente, para que los desarrolladores puedan centrarse en lo que importa: los datos y la lógica.
Si alguna vez ha tenido dificultades para mantener sincronizada su lógica de indexación y configuración de almacenamiento, hemos estado allí.
