Comprender los modelos de consistencia para bases de datos vectoriales
Los sistemas distribuidos para tus aplicaciones de búsqueda vectorial se están volviendo indispensables, desde la escalabilidad y la tolerancia a fallos hasta un rendimiento mejorado y la accesibilidad global. Los principios fundamentales que hacen de los sistemas distribuidos la columna vertebral de aplicaciones resilientes y de alto rendimiento nos obligan a considerar las compensaciones entre consistencia, disponibilidad y latencia.
Por ejemplo, la consistencia es crítica para ciertos casos de uso de búsqueda vectorial en tu aplicación distribuida. ¿No sería terrible si consultaras datos que esperabas que estuvieran allí pero no estuvieran? Eso ocurriría si tus datos no fueran consistentes en todas las réplicas que tienes en tus sistemas distribuidos. En apariencia, suena simple. Por supuesto, mis datos deberían estar allí después de que los coloque allí y los replique en múltiples nodos. Pero ¿cuándo deberían estar allí? ¿Cómo te aseguras de eso?
En respuesta al problema de consistencia, la base de datos vectorial completamente distribuida Milvus ofrece Consistencia Ajustable. Milvus tiene una arquitectura única que te permite escalar horizontalmente la forma en que escribes tus datos y garantizar la consistencia sin tener que usar herramientas adicionales. Al aprovechar una infraestructura distribuida, Milvus es un sistema pub-sub débilmente acoplado, lo que significa que la consistencia puede gestionarse y ajustarse fácilmente mediante marcas de tiempo.
En este artículo, veremos:
¿Qué es la consistencia?
- Requisitos de consistencia de las bases de datos vectoriales
Consistencia, disponibilidad y particiones
¿Qué niveles de consistencia ofrece Milvus?
Consistencia eventual
Consistencia de sesión
Consistencia acotada
Consistencia fuerte
Resumen de la comprensión de la consistencia para bases de datos vectoriales
¿Qué es la consistencia?
Una de las definiciones de consistencia es “el logro de un nivel de rendimiento que no varía mucho en calidad con el tiempo”. En cuanto a la consistencia para tu base de datos distribuida, te proporciona los datos más precisos y actualizados que solicitas. Por eso Milvus ofrece la capacidad de “ajustar” tu consistencia según cuán recientes deben ser los datos a los que quieres acceder.
Diferentes tipos de bases de datos tienen requisitos de consistencia adicionales. Por ejemplo, las bases de datos no relacionales suelen tener requisitos “eventuales” o ACID (atomicidad, consistencia, aislamiento y durabilidad) relajados. Puedes obtener datos parcialmente actualizados al trabajar con bases de datos NoSQL.
Por otro lado, las bases de datos SQL compatibles con ACID como Postgres tienen diferentes requisitos de consistencia. Estas bases de datos garantizan que no recibirás datos parcialmente actualizados al imponer la consistencia a nivel de cambio. Así que, cuando haces una consulta, debes esperar a que se complete todo el cambio para obtener los datos de ese cambio.
Requisitos de consistencia de las bases de datos vectoriales
Mientras tanto, las bases de datos vectoriales tienen requisitos de consistencia diferentes a los de las bases de datos relacionales o no relacionales. Puedes tener datos válidos incluso antes de que un cambio por lotes se complete por completo. Sin embargo, no puedes tener datos parcialmente actualizados. Las bases de datos vectoriales funcionan bajo el teorema PACELC. Eso es exactamente lo que hace Milvus mediante su configuración pub-sub. Cada fila se “publica” a través de la canalización de escritura y es “suscrita” por los nodos necesarios. Esta configuración te permite buscar o consultar Milvus y obtener resultados basados en las diferencias en las marcas de tiempo.
Consistencia, disponibilidad y particiones (CAP)
El teorema CAP es un concepto de informática que establece que existe una compensación entre consistencia, disponibilidad y tolerancia a particiones. Solo puedes elegir dos de las tres. Cuando hay una partición de red, debes elegir entre disponibilidad y consistencia. Un sistema que exige alta disponibilidad de datos requiere réplicas, lo que hace que la consistencia sea más difícil.
El teorema PACELC es una extensión del teorema CAP. Es el teorema CAP + else + latencia + consistencia. Establece que no necesitas preocuparte por las compensaciones entre disponibilidad y consistencia en un sistema sin particiones de red. Sin embargo, aún tienes que elegir entre latencia y consistencia, ya que necesitas esperar a que los datos se sincronicen.
¿Qué niveles de consistencia ofrece Milvus?
Milvus ofrece cuatro niveles de consistencia diferentes. En orden de menor a mayor consistencia, son: Eventual, Session, Bounded y Strong. La consistencia eventual significa que estás dispuesto a esperar hasta que “... cuando sea” ocurra. La consistencia fuerte significa que quieres incluir todos los datos en el momento en que envías la consulta. Session y Bounded están en un punto intermedio. Veámoslo con más detalle.
¿Puedes adivinar qué emojis representan qué niveles?
Consistencia eventual
La consistencia eventual (o “Eventually”) significa que los datos eventualmente serán consistentes en todas las réplicas. Usamos la consistencia eventual cuando nos importa más la velocidad de una aplicación que tener los datos más actualizados o consultas repetibles. Para Milvus, este tipo de consistencia significa que implementamos el requisito de consistencia omitiendo la verificación de marca de tiempo al leer.
Un ejemplo de caso de uso de este tipo de nivel de consistencia podría ser al obtener reseñas de productos. La mayoría de los usuarios no leerán todas las reseñas de un producto, por lo que obtener las reseñas más actualizadas no es de gran importancia. Si quieres crear una colección con este nivel de consistencia, el código siguiente muestra cómo crear una colección con consistencia de nivel “Eventually” en Milvus. Es importante tener en cuenta que consistency_level busca la palabra clave “Eventually.”
Consistencia de sesión
La consistencia de sesión significa que cada sesión está al menos actualizada según sus propias escrituras. Una sesión puede tener múltiples réplicas, así que esa es la primera compensación entre latencia y consistencia. Usamos la consistencia de sesión cuando solo necesitamos guardar nuestro estado una vez por sesión. Milvus implementa este tipo de consistencia estableciendo la marca de tiempo requerida en el momento de la última escritura.
En la práctica, puedes usar la consistencia de sesión cuando necesitas que cada instancia cliente-servidor tenga consistencia de datos. Un ejemplo de eso es un servidor de videojuegos. No quieres permitir que los jugadores hagan glitches infinitos, por lo que debes garantizar la consistencia dentro de cada instancia o sesión. El código siguiente muestra cómo hacer una búsqueda vectorial usando un nivel de consistencia de “Session.”
Consistencia limitada
La consistencia limitada (o obsolescencia limitada) es un paso “más consistente” que la consistencia de sesión. Con la consistencia de nivel “Session”, las otras instancias, o sesiones, se tratan como eventualmente consistentes. La obsolescencia limitada obliga a cada instancia y réplica a sincronizarse dentro de un período determinado.
Un ejemplo de obsolescencia limitada podría ser un motor de recomendación de videos. Los usuarios no necesitarán los videos más recientes de inmediato, pero deberían verlos pronto. Los cambios de un usuario también deberían propagarse rápidamente fuera de su sesión. El código siguiente muestra cómo buscar en Milvus con un requisito de consistencia limitada.
Consistencia fuerte
La consistencia fuerte hace que los datos estén disponibles en el momento en que los insertas. Por supuesto, esta consistencia conlleva una compensación de latencia: debemos esperar a que el sistema cambie. En la práctica, Milvus implementa esta consistencia estableciendo la marca de tiempo de lectura requerida en la última actualización del sistema. Esto eleva nuestra latencia de búsqueda a un mínimo de 200 ms.
Un ejemplo de consistencia fuerte podría ser la detección de fraude. Si alguien usa tu cuenta bancaria para cometer fraude, debes saberlo y detenerlo de inmediato. Las aplicaciones que necesitan una configuración de tipo lectura después de escritura necesitan consistencia fuerte. El código a continuación muestra cómo consultar una colección (búsqueda filtrada sin vectores) con un requisito de consistencia fuerte.
Resumen de la comprensión de la consistencia para bases de datos vectoriales
La consistencia de los datos es una de las cosas más importantes que se deben considerar al crear tu aplicación distribuida. Toda aplicación necesita datos, y todos los datos necesitan algunos requisitos de consistencia. En cuanto a los datos vectoriales, debemos evaluar la consistencia de los datos con respecto a los requisitos de consistencia basados en filas.
En consonancia con estos requisitos, Milvus ofrece cuatro niveles de consistencia basados en la marca de tiempo de los datos. Ten en cuenta que esto solo es posible para la consistencia basada en filas y no está implementado en bases de datos SQL o NoSQL. Los cuatro niveles de consistencia, de mayor a menor consistencia, son fuerte, acotada, de sesión y eventual.
La consistencia fuerte garantiza que tengamos todos los datos más actualizados disponibles en todo el sistema (casi) de inmediato. Este nivel de consistencia se logra actualizando la marca de tiempo a la marca de tiempo de inserción más reciente, lo que garantiza que podamos consultar todos los datos insertados hasta el momento de la solicitud.
La consistencia acotada garantiza que tengamos todos los datos más actualizados en todo el sistema dentro de un período fijo. La consistencia acotada establece la marca de tiempo que se debe comprobar dentro de un período determinado desde la solicitud. De esta manera, tenemos todos los datos dentro de un período acotado. La consistencia acotada es la configuración predeterminada en Milvus.
La consistencia de sesión garantiza que tengamos todos los datos más actualizados en la sesión actual en la que estamos trabajando. Milvus logra este nivel de consistencia estableciendo la marca de tiempo de cada instancia en la última vez que esa instancia insertó datos. De esta manera, tenemos todos los datos insertados en (al menos) la instancia que usamos.
Finalmente, la consistencia eventual (con la palabra clave “Eventually”) garantiza que, eventualmente, todos los datos en todo el sistema serán consistentes. Los datos pueden proliferar y se sincronizan con las réplicas a la velocidad que tenga sentido. Aunque sacrificamos cierta consistencia de los datos, obtenemos a cambio una mejor disponibilidad y rendimiento. En la práctica, este nivel de consistencia no tarda mucho. Milvus implementa la consistencia eventual omitiendo la comprobación de la marca de tiempo y ejecutando búsquedas o consultas de inmediato.
Sigue leyendo
Zilliz Cloud Now Available in AWS Asia Pacific (Seoul)
Zilliz Cloud is now available in AWS Seoul — low-latency vector search, in-country data residency, and one-step migration for Korean AI teams. 31 regions across 5 clouds.
Why Teams Are Migrating from Weaviate to Zilliz Cloud — and How to Do It Seamlessly
Explore how Milvus scales for large datasets and complex queries with advanced features, and discover how to migrate from Weaviate to Zilliz Cloud.
Migrating from S3 Vectors to Zilliz Cloud: Unlocking the Power of Tiered Storage
Learn how Zilliz Cloud bridges cost and performance with tiered storage and enterprise-grade features, and how to migrate data from AWS S3 Vectors to Zilliz Cloud.