目錄

背景

動機

Timestamp種類及使用場景

Guarantee timestamp

Service timestamp

Graceful time

Timestamp同步機制

主流程

時間戳同步流程

---

背景

Milvus 在設計上突出了分布式的設計，雖然Chroma 也支持分布式的store 與 query。但是相對Milvus來說，不算非常突出。正因為Milvus 在設計上對分布式store 與 query 非常重視，所以引入了TSO機制。也就是timestamp oracle mechanism。我會以比較形象的方式講述下這部分機理，并結合Milvus的配置及工作生活中的場景，技術上的設計美感和項目中的管理藝術，最終你會發現大道殊途同歸。‘夢里尋他千百度,驀然回首,那人卻在燈火闌珊處‘。

TSO設計動機

Milvus 在設計時為什么要引入 TSO機制？實際上其動機和使用場景掛鉤，當你使用 stand-alone 模式啟動Milvus時，TSO的作用或許你看不出來，當然在不同 coordinate 與 node 之間這種時間同步機制仍然存在，因為從設計上的角度上來說，如果支持了分布式，那么自然也涵蓋了stand-alone的單機模式。只是單機模式可以延用分布式設計的特性。

想象一個場景：

那么最正確的結果應該是：

• user2在 t2 時刻 query c0 collection， 結果是 empty result。

• user2在 t7 時刻 query c0 collection， 結果是 A1。

• user2在 t12 時刻 query c0 collection， 結果是 A1與A2。

• user2在 t71 時刻 query c0 collection， 結果是 A1。

假設沒有統一的時間戳作為度量，你沒法將不同cilent 的操作，這里包括了 DDL 與 DML，進行統一輸出。DDL與 DML 前面都介紹過了，這里就一筆帶過。但是客戶端子的時間系統有可能基準參差不齊，這例你有可能說使用對時服務可以解決這個問題。確實，使用對時服務可以解決多client時間同步的問題，但是因為timestamp對分布式系統太重要，你不能總想著依靠一個對時服務來解決所有的問題。萬一兩個對時服務基準不統一，或是一個client根本連不上對時服務怎么辦？真正robest的db 不會將自己的 kernel 依附在一個自己認為是核心且必要，但外界可有可無，甚至不準的service 之上。

先看下Milvus 中幾種timestamp 的定義與使用場景

Timestamp種類及使用場景

Guarantee timestamp

這種 timestamp 顧名思義，就是保證性質的，就相當于設置之后Milvus保證在這個之前的所有DDL 與DML都執行完成。

需要注意的是，這個 guarantee 時間戳不需要你來設置，因為它對于Milvus 來說太核心了，萬一你設置一個不太對的值，整個 system 的 query 結果可能不符合預期或是直接導致Milvus sys崩潰。 

舉個例子：