【Milvus】数据一致性级别（Consistency Level）：Strong、Bounded、Session、Eventual

在 Milvus 2.5.10（搭配 pymilvus 2.5.6），一致性级别（Consistency Level）是 Milvus 向量数据库的一个重要特性，用于控制查询和搜索操作时数据的一致性程度。Milvus 是一个分布式向量数据库，支持高性能的向量相似性搜索，但分布式系统中数据同步可能存在延迟，一致性级别允许用户在性能和数据一致性之间进行权衡。以下基于 Milvus 2.5.10 的官方文档（https://milvus.io/docs/consistency.md）和其他相关资源，详细介绍 Milvus 支持的一致性级别，包括定义、支持的级别、适用场景、配置方法、代码示例以及选择建议。

---

1. 一致性级别概述

一致性级别定义了 Milvus 在执行查询（query）或搜索（search）操作时，数据视图的“新鲜度”或一致性要求。Milvus 是一个分布式系统，数据分布在多个节点上，写入操作（如插入、更新、删除）可能需要时间在所有节点间同步。不同的应用场景对一致性和性能的需求不同：

• 高一致性：要求查询返回最新的数据，适合对数据准确性要求高的场景（如金融系统）。
• 低一致性：允许查询返回稍旧的数据，适合追求低延迟和高吞吐量的场景（如实时推荐系统）。

Milvus 提供四种一致性级别，允许用户根据需求灵活配置：

• Strong（强一致性）
• Bounded（有界一致性）
• Session（会话一致性）
• Eventual（最终一致性）

一致性级别可以通过以下方式设置：

• 集合级别：在创建集合时指定默认一致性级别。
• 操作级别：在执行查询或搜索时动态指定一致性级别（覆盖集合默认设置）。

---

2. 支持的一致性级别

以下是 Milvus 2.5.10 支持的四种一致性级别，逐一介绍其定义、机制、适用场景、优缺点和实现细节。

2.1 Strong（强一致性）

• 定义：查询或搜索操作保证返回所有已提交的写入操作（插入、更新、删除）的最新结果。Milvus 确保读取操作看到所有之前完成写入的完整状态。
• 机制：
  • Milvus 等待所有节点完成数据同步，确保查询时数据视图反映所有已提交的写入。
  • 使用时间戳（timestamp）机制，确保读取操作的快照包含所有小于或等于当前时间戳的写入。
• 适用场景：
  • 数据准确性至关重要的场景，如金融交易、库存管理。
  • 需要严格一致性的分析任务。
• 优点：
  • 提供最高的准确性，保证查询结果反映最新数据。
  • 适合对一致性要求高的应用。
• 缺点：
  • 最高延迟，可能因等待数据同步而降低性能。
  • 不适合高吞吐量或低延迟场景。
• 支持的操作：query、search。
• 时间戳：读取最新的全局时间戳。

2.2 Bounded（有界一致性）

• 定义：查询或搜索操作保证返回在指定时间范围（staleness bound）内的数据，允许一定程度的延迟，但数据不会过于陈旧。
• 机制：
  • Milvus 允许用户指定一个时间范围（通过 guarantee_timestamp），查询返回不晚于该时间戳的数据。
  • 提供了一种折中，平衡一致性和性能。
• 适用场景：
  • 允许一定延迟但需控制数据新鲜度的场景，如实时分析、推荐系统。
  • 需要在一致性和延迟间权衡的应用。
• 优点：
  • 比 Strong 一致性更快，延迟可控。
  • 适合大多数实时应用。
• 缺点：
  • 可能返回稍旧的数据（取决于时间范围）。
  • 需要手动配置时间范围，增加复杂性。
• 支持的操作：query、search。
• 时间戳：基于用户指定的 guarantee_timestamp。

2.3 Session（会话一致性）

• 定义：保证同一客户端（会话）内的写入操作对后续查询可见，但不保证其他客户端的写入立即可见。
• 机制：
  • Milvus 跟踪每个客户端的写入时间戳，确保该客户端的查询能看到自己的所有写入。
  • 其他客户端的写入可能有延迟。
• 适用场景：
  • 用户会话场景，如用户在同一会话中插入数据并立即查询。
  • 在线服务（如个性化推荐、用户偏好查询）。
• 优点：
  • 保证客户端自身操作的可见性，适合交互式应用。
  • 性能优于 Strong 一致性。
• 缺点：
  • 其他客户端的写入可能不可见，存在一定不一致性。
  • 不适合需要全局一致性的场景。
• 支持的操作：query、search。
• 时间戳：基于客户端会话的最新写入时间戳。

2.4 Eventual（最终一致性）

• 定义：查询或搜索操作可能返回旧数据，但随着时间推移，数据最终会一致。Milvus 不保证立即反映所有写入。
• 机制：
  • Milvus 尽可能快地执行查询，不等待数据同步。
  • 依赖分布式系统的最终一致性，数据在后台逐渐同步。
• 适用场景：
  • 高吞吐量、低延迟场景，如实时推荐、内容搜索。
  • 对数据新鲜度要求不高的应用。
• 优点：
  • 最低延迟，最高吞吐量。
  • 适合大规模分布式系统。
• 缺点：
  • 可能返回过时数据，不适合一致性敏感场景。
  • 查询结果可能不稳定。
• 支持的操作：query、search。
• 时间戳：使用最早的可用时间戳。

---

3. 一致性级别的配置

在 Milvus 2.5.10 中，一致性级别可以在以下两个层面配置：

3.1 集合级别（默认一致性）

• 在创建集合时，通过 consistency_level 参数指定默认一致性级别。
• 可选值："strong"、"bounded"、"session"、"eventual"。
• 示例：

  from pymilvus import MilvusClient, CollectionSchema, FieldSchema, DataType
  from pymilvus.client.constants import ConsistencyLevel
  
  client = MilvusClient(uri="http://localhost:19530")
  fields = [
      FieldSchema(name="id", dtype=DataType.INT64, is_primary=True),
      FieldSchema(name="vector", dtype=DataType.FLOAT_VECTOR, dim=128)
  ]
  schema = CollectionSchema(fields=fields)
  client.create_collection(
      collection_name="strong_consistency_example",
      schema=schema,
      consistency_level=ConsistencyLevel.Strong  # 设置默认强一致性
  )
  

3.2 操作级别（动态覆盖）

• 在执行 query 或 search 操作时，通过 consistency_level 参数动态指定一致性级别，覆盖集合默认设置。
• 可选值："strong"、"bounded"、"session"、"eventual"。
• 对于 bounded 一致性，还需指定 guarantee_timestamp。
• 示例（见下文代码）。

---

4. 代码示例

以下是基于 pymilvus 2.5.6 的完整示例，展示如何为集合设置一致性级别，并在查询和搜索中动态指定一致性级别。

示例：配置不同一致性级别

from pymilvus.client.constants import ConsistencyLevel
from pymilvus import MilvusClient, CollectionSchema, FieldSchema, DataType
from pymilvus.milvus_client.index import IndexParams
import random
import time

client = MilvusClient(uri="http://localhost:19530")

# 创建集合，设置默认一致性为 Session
fields = [
    FieldSchema(name="id", dtype=DataType.INT64, is_primary=True),
    FieldSchema(name="vector", dtype=DataType.FLOAT_VECTOR, dim=128)
]
schema = CollectionSchema(fields=fields)
client.create_collection(
    collection_name="consistency_example",
    schema=schema,
    consistency_level=ConsistencyLevel.Session
)

# 创建向量索引
index_params = IndexParams()
index_params.add_index(
    field_name="vector",
    index_type="HNSW",
    metric_type="L2",
    params={"M": 16, "efConstruction": 200}
)
client.create_index(collection_name="consistency_example", index_params=index_params)

# 插入数据
data = [
    {"id": i, "vector": [random.random() for _ in range(128)]}
    for i in range(1000)
]
client.insert(collection_name="consistency_example", data=data)

# 等待写入完成
time.sleep(1)

client.load_collection("consistency_example")

# 查询：使用 Strong 一致性
results = client.query(
    collection_name="consistency_example",
    filter="id < 10",
    output_fields=["id"],
    consistency_level=ConsistencyLevel.Strong
)
print("Strong consistency query results:", results)

# 搜索：使用 Bounded 一致性
query_vector = [random.random() for _ in range(128)]
results = client.search(
    collection_name="consistency_example",
    data=[query_vector],
    limit=5,
    consistency_level=ConsistencyLevel.Bounded,
    guarantee_timestamp=int(time.time() * 1000) - 1000  # 允许 1 秒延迟
)
print("Bounded consistency search results:", results)

# 查询：使用 Eventual 一致性
results = client.query(
    collection_name="consistency_example",
    filter="id < 10",
    output_fields=["id"],
    consistency_level=ConsistencyLevel.Eventually
)
print("Eventual consistency query results:", results)

输出示例

Strong consistency query results: [
    {'id': 0}, {'id': 1}, ..., {'id': 9}
]
Bounded consistency search results: [
    [{'id': 123, 'distance': 0.234}, ...]
]
Eventual consistency query results: [
    {'id': 0}, {'id': 1}, ..., {'id': 9}
]

代码说明

• 集合创建：设置默认一致性为 session，确保会话内写入可见。
• 索引：为向量字段创建 HNSW 索引，支持搜索。
• 插入：插入 1000 条数据，模拟实际场景。
• 查询/搜索：
  • 使用 strong 一致性，确保查询最新数据。
  • 使用 bounded 一致性，指定 guarantee_timestamp 控制延迟。
  • 使用 eventual 一致性，追求最低延迟。
• 时间戳：guarantee_timestamp 以毫秒为单位，需根据应用需求设置。

---

5. 选择一致性级别的建议

选择一致性级别时，需权衡一致性、延迟和吞吐量。以下是建议：

• Strong：
  • 适用：金融、库存管理、实时分析等对数据准确性要求高的场景。
  • 注意：延迟较高，适合低频查询或小型数据集。
• Bounded：
  • 适用：实时推荐、内容搜索等需要平衡一致性和性能的场景。
  • 注意：需合理设置 guarantee_timestamp，通常为当前时间减去允许的延迟（如 1-5 秒）。
• Session：
  • 适用：用户会话、交互式应用（如用户插入后立即查询）。
  • 注意：默认推荐，适合大多数在线服务。
• Eventual：
  • 适用：高吞吐量、低延迟场景，如大规模推荐、日志分析。
  • 注意：可能返回旧数据，不适合一致性敏感场景。

选择流程：

1. 确定应用对一致性的需求（是否需要最新数据）。
2. 评估性能要求（延迟、吞吐量）。
3. 测试不同一致性级别，观察延迟和结果准确性。
4. 对于动态场景，使用操作级别的 consistency_level 灵活调整。

---

6. 注意事项

• 版本兼容性：
  • Milvus 2.5.10 和 pymilvus 2.5.6 完全支持四种一致性级别。
  • 确保 Milvus 服务版本正确（docker run -d --name milvus_standalone -p 19530:19530 milvusdb/milvus:2.5.10）。
• 性能影响：
  • Strong 一致性可能显著增加延迟，尤其在高并发或分布式环境中。
  • Eventual 一致性提供最佳性能，但需接受数据可能不一致的风险。
• 时间戳配置：
  • Bounded 一致性需要设置 guarantee_timestamp，建议基于当前时间（如 int(time.time() * 1000)）减去允许的延迟。
  • 错误的时间戳可能导致查询失败或返回空结果。
• 索引与一致性：
  • 一致性级别不影响向量索引类型（如 HNSW、IVF_FLAT），但可能影响搜索结果的最新性。
  • 确保索引构建完成后执行查询，以避免数据不完整。
• 错误处理：
  • 如果一致性级别配置错误（如不支持的级别），Milvus 会抛出异常：

    try:
        client.search(..., consistency_level="strong")
    except Exception as e:
        print(f"Error: {e}")
    

• 分布式环境：
  • 在分布式部署中，节点间同步延迟可能更明显，Strong 一致性会等待所有节点同步。
  • 使用 Eventual 或 Session 可减少跨节点同步的开销。

---

7. 总结

Milvus 2.5.10 支持四种一致性级别（Strong、Bounded、Session、Eventual），提供了从最高一致性到最低延迟的灵活选择。Strong 适合准确性敏感场景，Bounded 平衡一致性和性能，Session 适合用户会话，Eventual 优化高吞吐量场景。用户可以通过集合级别的 consistency_level 设置默认行为，或在查询/搜索时动态覆盖。