Timestamp
本主题解释时间戳的概念，并介绍 Milvus 向量数据库中与时间戳相关的四个主要参数。
概述
Milvus 会为每批数据操作语言（DML）操作分配时间戳，包括 数据插入和删除。因此，每个 Entity 都带有时间戳属性，同一批 DML 操作涉及的 Entity 共享相同的时间戳。
Timestamp 参数
在 Milvus 中进行向量相似性搜索或查询时，会涉及几个与时间戳相关的参数。
-
Guarantee_timestamp -
Service_timestamp -
Graceful_time -
Travel_timestamp
Guarantee_timestamp
Guarantee_timestamp 用于保证搜索或查询能够看到该时间戳之前所有已完成 DML 操作产生的数据。例如，如果分别在 15:00 和 17:00 写入两批数据，并将 Guarantee_timestamp 设置为 18:00，则这两批数据都应参与搜索。
如果未显式配置 Guarantee_timestamp，Milvus 会根据搜索请求时间和 Consistency Level 自动确定可见性边界。
用户通常无需直接设置 Guarantee_timestamp。只需选择 Consistency Level，Milvus 即可自动计算对应的可见性边界。TSO 的实现细节参见 Milvus Hybrid Timestamp。
示例
如上图所示，Guarantee_timestamp 的值设置为 2021-08-26T18:15:00 （为简单起见，本例中的时间戳用物理时间表示）。在进行搜索或查询时，会搜索或查询 2021-08-26T18:15:00 之前的所有数据。
Service_timestamp
Service_timestamp 由 QueryNode 自动维护，表示该 QueryNode 已处理完成的 DML 时间水位。
查询节点管理的数据可分为两类：
-
历史数据（或称批量数据）
-
增量数据（或称为流数据）。
在 Milvus 中，您需要在进行搜索或查询之前加载数据。因此，在发出搜索或查询请求之前，会通过查询节点加载 Collection 中的批量数据。然而，流数据是即时插入 Milvus 或从 Milvus 中删除的，这就要求查询节点保持 DML 操作和搜索或查询请求的时间轴。因此，查询节点使用 Service_timestamp 来保存这样一个时间轴。Service_timestamp 可以看作是某些数据可见的时间点，因为查询节点可以确保 Service_timestamp 之前的所有 DML 操作都已完成。
当有搜索或查询请求传入时，查询节点会比较 Service_timestamp 和 Guarantee_timestamp 的值。主要有两种情况。
情况 1：Service_timestamp >=Guarantee_timestamp
如图 1 所示，当 Service_timestamp >= Guarantee_timestamp 时，QueryNode 已处理完可见性边界之前的全部 DML 操作，因此可以立即执行搜索或查询。
情况 2：Service_timestamp <Guarantee_timestamp
如图 2 所示，当 Service_timestamp < Guarantee_timestamp 时，仍有部分应当可见的 DML 操作尚未处理完成。QueryNode 必须等待 Service_timestamp 推进到 Guarantee_timestamp 后再执行请求。
Graceful_time
Graceful_time 不是时间戳，而是一段允许的数据可见性延迟。它与 Guarantee_timestamp 和 Service_timestamp 一起决定请求是否需要等待。
当有搜索或查询请求传入时，可能会出现两种情况。
情况 1：Service_timestamp +Graceful_time >=Guarantee_timestamp
如图 1 所示，当 Service_timestamp + Graceful_time >= Guarantee_timestamp 时，未处理完成的数据仍处于允许的延迟范围内，请求可以立即执行。
情况 2：Service_timestamp +Graceful_time <Guarantee_timestamp
如图 2 所示，当 Service_timestamp + Graceful_time < Guarantee_timestamp 时，数据可见性延迟超出允许范围，QueryNode 需要等待时间水位继续推进。
下一步
- 了解 保证时间戳 如何 在 Milvus 中实现可调整的一致性