向量數據庫~milvus

本文主要基於milvus官方的材料外加自己的一些理解整理而來，歡迎交流

設計理念

雲原生：存&算分離; 讀寫分離; 增量存量分離; 微服務架構，極致彈性；
日誌即數據：通過message queue解耦生產者、消費着，降低系統複雜度; 提升index、data、query模塊彈性;
流批一體：表和日誌二象性；流式數據分段固化持久化，提供快速恢復能力；通過TSO保證順序；

＃個人解讀：
1.設計理念非常貼近技術前沿，利用開源組件來承載流、批數據高可靠/可用存儲，實現計算、存儲、索引構建解耦&極致彈性，這種技術方案非常優雅。
2.通過pub-sub機制改變了傳統數據主節點-備節點-只讀節點依靠binlog進行數據複製的玩法，只有datanode一種消費者角色（可以認爲kafka，pular本身就是master；另外queryNode、indexNode是爲了減少各功能間耦合性從dataNode中剝離出，邏輯上還是dataNode的一部分）
3. 事實上，不少開源廠商比如圖數據庫TigerGraph也是這種玩法，我給其起個名字：把簡單留給自己，把困難留給巨人。勇敢點，踩着巨人，你也會成爲巨人。
4. 其實日誌即數據、流批一體都是Flink設計精髓， 也就是Kappa架構

產品探討

1. 自身定位：Milvus 主要是做向量域的近似查詢的數據庫

• Milvus 首先不是一個關係型數據庫，不會支持特別複雜的 JOIN 之類的查詢，也不會支持 ACID 的事務
• Milvus 不是一個搜索引擎，跟傳統的 Elasticsearch、Solr 之間也有很大區別。Milvus 針對的是 embedding 向量數據，而不是傳統的文本格式的數據。對於文本來說，Milvus 做的是基於語義的檢索，而不是基於關鍵詞的檢索

2. 業務層面：非獨立解決方案，需要用戶組合使用

別的系統比如tsdb、mongdb、es、graph、rdis等等都可以獨立提供服務。從milus目前提供的所有場景看，其只提供向量檢索這種抽象進, 抽象出的能力：入口一般爲query vector，出口爲相似向量id，需要藉助其他技術來提供整體解決方案，比如：

• 文本檢索：上游：BERT； 下游：mysql
• 問答系統：上游：BERT； 下游：mysql
• 推薦系統(電影特徵抽取)：上游：PaddlePaddle； 下游：redis或者mysql
• 圖片檢索：上游：ResNet-50； 下游：mysql
• 視頻推薦：上游：OpenCV抽取視頻關鍵幀，ResNet-50圖片特徵向量抽取；下游：Mysql，OSS
• 音頻檢索：上游：PANNs (Large-Scale Pretrained Audio Neural Networks)：下游：Object Storage
• 分子結構：上游：RDKit； 下游：mysql
• DNA序列發現：上游：CountVectorizer；下游： 下游：mysql

個人解讀：前後端場景多、技術差異性大，要做好需要很大工程能力，可能還是推出使用案例，引導用戶自行構建整體系統這條路比較容易。

3. 產品能力：用戶需要了解很多細節，有門檻

• 用戶來指定partition：並按照partition精細化管理其entity
• 人工干預操作：比如flush、load_collection, load_partition等
• Entity不支持去重：用過RDBMS的用戶會很麻煩，需要先抽取特徵，檢索並根據精確度來判斷是否重複
• 類型系統有限：string類型正在開發中
• 不支持transaction，但支持四種一致性
  • 強一致性：GuaranteeTs 設爲系統最新時間戳，QueryNodes 需要等待 ServiceTime 推進到 當前最新時間戳才能執行該 Search 請求；
  • 最終一致性：GuaranteeTs 設爲一個特別小的值（比如說設爲 1），跳過一致性檢查，立刻在當 前已有數據上執行 Search 查詢；
  • 有界一致性：GuaranteeTs 是一個比系統最新時間稍舊的時間，在可容忍範圍內可以立刻執行查詢；
  • 客戶端一致性：客戶端使用上一次寫入的時間戳作爲 GuaranteeTs，那麼每個客戶端至少能看到 自己插入的全部數據

4. 性能&成本問題

• milvus查詢需要sealed seg和growing seg都加載到QueryNode的內存中才能計算，大數據量下成本高
• 隨機向量檢索場景下如果採用內存換入換出的思路會有性能問題

5. 雖然開源，沒有自己的生態，容易被雲廠商集成
   這點由2所決定的，並且其主打的多模態查詢、雲原生、Log as data、流批一體這些概念在雲原生數據庫基本也都是標配，據我所知，阿里雲數據庫這邊是個產品都會集成向量檢索的能力，捲起來比誰都狠。

整體架構

包括LB、Access Layer、Coordinator Service、Message Storage、WorkerNode四類，如下圖：

Access layer：請求接入

Proxy

• serverless，高彈性
• 所有請求入口
• 併發處理：查詢請求通過pub-sub分到多個queryNode中，proxy對最終結果進行薈聚

Coordinator service：

接收任務並分發給對應worker node，主要工作包括：集羣拓撲管理、負載均衡、TSO時間生成器、數據管理等（應該不具備動態擴容能力，靠k8s快速拉起？）

RootCoord：集羣controller

• DDL/DCL處理：比如collection/partition/index等創建以及刪除；
• TSO時鐘服務： 時鐘timer tick；提供ts服務
• collect生命期狀態管理：
  • collection channel分配：分配vchannel到pchannel映射
  • segment alloc：接收DataCoord分配的segId並持久化
  • segment index build：接收DataNode flush seg結束請求，並trigger IndexCoord去build index

QueryCoord：查詢服務的controller

• 處理請求：LoadCollection, LoadPartition, ReleaseCollection, ReleasePartition
• QueryNode集羣管理
• Collection數據負載均衡：每個queryNode分配若干個Dmchannel，讓查詢最大程度並行化

DataCoord：數據服務的controller

• 管理信息：datanode信息、channel列表以及消費各datanode消費位點、<collection, partiton, segment>等信息
• DataNode集羣管理和負載均衡，目前兩種策略：
  • 按pchannel一致性哈希，每個dataNode可能管理對應多個pchannel，導致不均衡
  • 保證每個collection的pchannel分佈在不同的dataNode上
• 觸發flush、compact等後端數據操作

IndexCoord：索引構建服務的controller

• 管理信息：indexnode信息、indexMetable（index-related task）
• 處理四類請求：
  • watchNodeLoop: 監控indexNode離線、在線狀態
  • watchMetaLoop: 監控Meta變化（indexNode觸發並寫入etcd，indexcoord更新本地）
  • assignTaskLoop : 從metaTable取任務併發起索引構建任務
  • recycleUnusedIndexFiles：異步刪除無用索引文件

Worker nodes：具體任務執行者

負責具體執行來自coord的任務； 每類節點只負責部分segment的處理；所有節點無狀態，可以按需平滑擴容

QueryNode：對其所管理的segment進行流批一體化查詢

• 從MessageQueue消費增量日誌並寫入到growing segments中進行增量查詢
• 從object storage load加載seal seg進行存量數據查詢

DataNode：對其所管理的segment進行持久化

• 消費增量數據寫入growing segments並通過log snapshot持久化
• growing segments flush，條件：
  • entity條數超過配置
  • 用戶調用flush
  • 超過一定時間
• 重啓後恢復flowgraph(對應一個collection的一個segment)：
  • 通過WatchDmChannels從datacoord中獲取vchannel state位點信息
  • 如何保證消費不丟不重？ datanode在每次flush時都通過RPC SaveBinlogPaths 告訴datacoord，並datacoord將其更新到etcd中

IndexNode： 對其所管理的segment進行全量索引構建

• 接收index coord的請求從存儲層提取Segment提取數據並構建索引，寫入index File中；

Storage：高可用高可靠數據承載着

[etcd] metadata storage 元數據信息持久化

• collection schema: 存儲在minio中和data、index共同存儲
• node status：indexnode、datanode、querynode
• message consumption checkpoints：消費位點

[pulsar]log broker： log as data理念，流數據持久化，寫節點只讀節點化

• 讀、寫事務解耦，追加binlog方式
• 增量數據持久化，高可靠
• 查詢請求異步化處理
• 查詢結果異步返回
• 事件通知機制

[s3]object storage： 用戶數據持久化

• 存儲logs(來自datanode)、index（來自inodenode）、Delta File
• 利用本地ssd緩存來自aws s3、azure blob的結果（規劃中）

周邊工具

MilvusDM (Milvus Data Migration)： 數據遷移
Attu：服務可視化
Milvus CLI：交互式命令行
MilvusMonitor：服務監控
Milvus sizing tool：容量評估