Milvus存算分离系列-3: 存算双写

前言

书接上文，还是回到数据实时可见这个问题上。milvus的target机制实际上只解决了一部分问题，即那些已经“落盘”的数据，可以通过target推进机制来可见。这种机制类似于lucene的“flush”功能，即只有刷新过的数据可查，而没刷新的数据不能查询。这个做法在share nothing的架构下问题不大，比如es就是完全接受lucene的flush机制，提供了“近实时”查询，即一般把flushInterval设置为1s，新写入的数据在1s之后就是可见的。但是对于milvus这种存算分离+云原生的架构，如果新写入的数据要经过write-object storage再download的过程才能可查，那么且不说由于flushInterval太短造成的小文件问题，仅仅是这个upload+download的过程的延时肯定都已经做不到“近实时”了。本文从此出发，介绍milvus是怎么解决“最新数据实时可见”这个问题的。

sync与未sync的数据

可选方案

1. 存算双读

双读就是存储节点和计算节点都做查询再做结果合并，如下图， 存储节点的热数据和计算节点上synced数据之间没有交集，查询分2路分别查到hot_result和synced_result后进行合并，然后返回给client。这种做法的好处是数据没有冗余，是“计算跟随数据”的风格。缺点是存储节点会受到计算负载的影响。

存算双读

2. 存算双写

而双写意味着同一份数据，既写入存储节点，又写入计算节点。如上图所示，当查询发生的时候，query只需要发给计算节点，就能够得到完整数据。双写的好处存储节点不必承担计算负载，坏处是数据冗余，对于内存压力比较大。

Milvus的存算双写机制

综上，无论是双写还是双读，存算分离架构下都需要相当的额外资源和复杂性来满足数据实时性的要求。milvus在这个问题上选择双写。主要原因是向量的查询计算量很大，cpu资源比较紧张，而存储节点的cpu需求则比较低。所以如果让存储节点去做实时计算，在配置cpu资源不足而压力较大的情况下可能发生严重争抢，而在资源配置较高查询压力不够的时候又不容易伸缩来节省资源。因此采用双写，接受一定的数据冗余带来的内存消耗，让计算需求&&资源都集中在计算节点，实现更好的伸缩性，这对于云原生架构的数据库来说比较明智。

如上图所示，整个存算双写的流程如下：

1. proxy将insert msg append到message queue中(一般为pulsar或kafka)
2. QueryNode和DataNode分别消费mq中的数据，生成相同的growing segment。此时，查询指向QueryNode上的GrowingSegment和sealedSegment, 最新插入的数据也是可查的。
3. DataNode定期会将growing segment sync到object storage上
4. 已经sync的segment的meta数据被同步到etcd上
5. mixCoord通过watch etcd key，发现有新的sealed segment存在，则通知QueryNode加载最新的sealed segment
6. QueryNode加载最近的sealed segment，此时原本的growing segment已经没有存在价值
7. QueryNode上原growing segment被释放掉。

总结

本文从“最新数据实时可见”这个需求入手，介绍了milvus 通过存算双写保证数据实时可查的解决方案和整个双写流程。