Milvus - 四种一致性级别与应用场景解析

花千树-010

于 2024-09-24 22:51:16 发布

阅读量994

点赞数 8

分类专栏： RAG 文章标签： milvus

本文链接：https://blog.csdn.net/fenglingguitar/article/details/142502293

版权

RAG 专栏收录该内容

9 篇文章 0 订阅

订阅专栏

在使用 Milvus 时，很多开发者在接触到查询请求中的大量参数时常感到困惑，尤其是 SDK 客户端开发者。本文将重点介绍其中的一个关键参数——Guarantee Timestamp（保证时间戳），并详细解释 Milvus 支持的四种一致性级别及其最适合的应用场景。

一致性概述

在分布式数据库系统中，一致性是指确保系统中的每个节点或副本在任意时刻都能获取相同的数据视图。在 Milvus 这样一个存储与计算分离的架构中，一致性尤为重要。Milvus 通过一套复杂的时钟机制和时间戳管理，保证用户查询时的数据准确性。

Milvus 的时钟机制

Milvus 的数据持久化操作由 DataNodes 处理，数据最终会被存储在 MinIO 或 S3 这样的分布式存储系统中。而计算任务，如搜索任务，则由 QueryNodes 承担。QueryNodes 处理两种数据类型：批式数据和流式数据。其中，批式数据一旦写入便不会再改变，而流式数据是通过消息队列持续传输的，可能因为网络延迟而存在时间上的不一致。为了避免这种不一致性导致查询结果不准确，Milvus 引入了 Guarantee Timestamp 机制。

Guarantee Timestamp 机制

当 QueryNodes 从消息队列中消费数据时，每条记录都会被打上时间戳。QueryNodes 会不断获取时间戳信息，并将最新的时间戳称为 ServiceTime，即它能看到的最晚时间戳之前的所有数据。用户可以通过指定 Guarantee Timestamp 来告知 QueryNodes，此次查询必须包含 Guarantee Timestamp 之前的所有数据，从而确保查询结果的一致性。

Guarantee Timestamp 的作用机制

如果 Guarantee Timestamp 小于 ServiceTime，QueryNodes 可以立即执行查询请求。
如果 Guarantee Timestamp 大于 ServiceTime，QueryNodes 需要等待，直到 ServiceTime 推进到 Guarantee Timestamp 后才能执行查询请求。

这为用户提供了对一致性和查询延迟的灵活控制。具体来说，如果用户对数据一致性要求高且对查询速度不敏感，Guarantee Timestamp 应设置得尽可能大；反之，如果用户需要快速查询结果且能容忍一定数据不一致性，则可以将 Guarantee Timestamp 设置得较小。

四种一致性级别

Milvus 支持四种一致性级别，用户可以根据自己的需求在一致性和查询延迟之间进行平衡：

强一致性
适用场景： 订单支付、账单处理等在线金融系统
强一致性是最严格的一致性级别，要求查询必须看到最新写入的数据。这种模式下，查询请求会等待最新的数据可见后才执行，因此会导致较高的查询延迟。
有界滞后一致性
适用场景： 视频推荐引擎、新闻推荐等需要一定性能的场景
有界滞后允许一定范围内的数据不一致性，但在一定时间后，数据仍将保持一致。这种一致性适合需要较低查询延迟且可以接受部分数据不可见的场景。
会话一致性
适用场景： 数据管理系统中，确保同一会话中的数据一致性
会话一致性保证用户在同一会话内写入的数据可以立即被读取。适合需要保证单个会话内数据一致性的场景，如删除操作后的数据刷新。
最终一致性
适用场景： 数据一致性要求不高但对查询速度有极高要求的场景
最终一致性是最宽松的级别，保证副本最终会达到一致状态，但不保证操作顺序。这种一致性适合数据实时性要求不高的场景，如电商产品评论的查询等。