点击观看完整视频实录
⌛ 时间戳
02:31-09:07 Attendee A：Milvus 在 GPU 的支持与性能上的一些问题
09:17-21:00 Attendee B：Milvus 分布式相关讨论
视频后半段画面遗失了 但很谢谢另外两位小伙伴的参与
| Milvus Q&A 部分文字实录
Attendee= 参会者
Attendee B：
我本身对分布式这块还是满感兴趣的， 想问一下社区这边之后的规划？也希望有机会和大家一起做开发促进这块的推动、落地。
顾老师@Milvus：
现在分布式的话，其实整体上来说两种思路，一个是基于像现在这种 Mishards 这种 sharding 的方式做一些分库。那么现在主要的一些性能瓶颈可能会是在读取元数据上面，我们现在是在想怎么样去解决这个问题，现在有一些思路去解决这种读取元数据时候的这种竞争，这是一种思路。
然后另外一种也是一直在关注，比如说类似于这种分布式的一致性协议 raft 这种协议，因为现在这些用的比较多一点，但其实 raft 也有它自己的限制。
Attendee B：
对，副本这种限制的确是一个问题。
顾老师@Milvus：
这是一方面，分布式执行的三副本大家现在都能接受，这个问题倒还好。但是怎么讲，因为 raft 本身它所针对的场景它可能不是那么的适合这种频繁的更新，然后像如果是在这种一般的场景下面，就是结构化数据库的场景下，比如说账务系统上也做了一次转账，那么它其实传日志过去的时候，就是说你把你的账户上的余额从一个数字更新到另外一个数字，但是它这部分的量很小。但是你想如果是在一个向量的场景下面，通常来讲我们也没有更新的操作，更多的就是插入了一个比如说 512 的 2K 一条，这个量其实是非常大的。raft 协议这样的模式，其实它不是那么的适合这种大数据量的更新，它不是那么的友好的。所以其实可能怎么说也在研究，但是也不敢说它是不是一定能解决这个问题。所以现在就是两种思路，然后都可能要做一些探索。当然在这种 sharding 的方式上解决元数据访问的冲突，相对来说可以解决更快一点，因为现在有一些思路，然后可以去做一些尝试。
Attendee B：
了解。我可以提几个小的参考嘛？
第一个就是说我觉得关于 raft 协议的场景上，然后因为它本身其实看起来是一个强一致性，或者说在一定时间内它是要达到最终的一致性。那么在这种场景下，其实 2K 的这种数据就向量而言，因为我们做的是人脸检索，其实 2K 数据应该算是比较大的，这种应该还算比较少的。
顾老师@Milvus：
所以你有大量实时的数据更新进来的时候，因为其实 512 维的维度并不高，如果是 768 或者 1024 数据量会更大，如果你要有一个非常频繁的 feed 的把数据这种这种注入进来的话，其实整个 raft 的集群的网络的压力可能会比较大，它和传统单纯的 SQL 的数据库不太一样，SQL 的数据库很大情况下，插入是比较少，可能很多的是在做更新，更新的话其实你只要同步 redo SQL 那部分的一个字段加上一个主键这样子，其实内容不是那么的多的。
Attendee B：
那是不是说其实我们要同步的是一种 binlog，而不是直接去同步元数据？
因为我理解元数据的同步，比如说类似于增删改查这种其实是比较频繁的，假设增删改查比较频繁，其实会有一些数据合并的问题，其实就不如去看一下，比如说类似于Redis（很久之前看过，但现在已经忘得差不多了），它会有一些类似于类似于 binlog的，比如说你在某些数据上+1-1，然后反复多次之后，其实可能对于整个集群的影响没有那么多，当然它是一个比较简单的程序，它就是数值型的可能和向量型的还是不太一样。但是如果是频繁的这种增插的话，我理解增插还好说，因为其实你可以打个批量包，甚至用数据压缩的方式，都可以去在一定程度上解决问题。但是合并的策略应该需要去想一下。
然后第二个是说你说的关于文件读取或者说数据索引文件，我觉得其实可以考虑看不同的索引类型去做这个事，因为更多的场景下，比如说刚才说到的一些人脸的搜索上，它可能是需要比较精准，它是 Flat 的，或者说就是那种最精准的暴力搜索，但是一些其他的比如说 IVF/IVFPQ 其实它就不是一个精准搜索。在这种情况下，其实索引或者说建立的方式上，我理解其实就相当于会里面的优化。我的建议是针对不同的索引类型可能从不同的方式或者从不同的角度去解决可能会更好一些。根据场景来，也不能都用同一个方式去解决，我的建议是这样。
顾老师@Milvus：
怎么说呢，因为毕竟想做成一个通用性的技术，然后也引入了像 write-ahead log （WAL）这样的方式，而且也会存向量的原始的数据。所以其实更多还是希望能够有一个相对大家都差不太多的方式去统一的做这些东西，但这个东西确实是一个怎么说呢？和这个会有点不太一样，所以在这方面是有点不太好办的地方。
Attendee B：
只是提议，因为如果说作为开源的话，其实可能对于大家更多是一个专用场景的话，可能这会比较难。这就相当于通用和深度，你选一个的话通用上可能兼容情况更好，才有更多的人用，但是深度上可能就是说可能在某一个方向上，某些人或者某些领域就会影响不是那么好，然后他们只能说我在这个技术来去改造，对吧？
顾老师@Milvus：
是的，所以其实关于日志同步是一个比较复杂的问题，因为传统数据库还是可以去...redo log 其实量还是可以缩的比较小，但是一旦是涉及到这种插入的话或者删除的话，其实它是全量数据更新过去的。所以在很多年以前我还在 IBM 工作的时候，我们当时是做一个两个数据库集群之间的数据同步工具，在一个国内比较大的银行那边做 POC，然后就会发现说这当中最大的一个挑战就在于在正常情况下，其实数据库是不需要记全量日志的。就是说我一条记录上面，比如说我更新了字段，比如说这条记录有 10 个字段，字段 1 到字段 10，假定我在一次，其实比较多的是更新的，就是查询的操作是最多的，然后去更新，最后才是插入。在做更新操作的时候，可能你更改了字段 2 和 3，那么在数据库的日志当中它只会记 2 和 3 的东西在日志里，所以他其实日志的量会比较小。
当我们去把这些 redo log 去同步出去的时候，其实那样量也都还好，因为你只同步了两个字段。但是在某一些场景下，当然用户要做一些审计的时候，他想知道的东西可能不单单是哪一些字段被修改了，他想知道说比如说字段 1 是账户的 ID，他想知道说在这段时间内有哪些账户的信息被修改，这个时候你日志发送出去的内容就不单单只是被修改的那些，需要把剩下那些没有修改过的都发出去，因为以防用户他在某些业务场景下他需要用到不同的数据，然后这时候你就会发现你的日志量暴增，又带来了各种日志的问题，传输的问题等等，所以其实在这个场景下面就始终是巨大的一个挑战。
而向量又很不幸，它又不是这种我把 512 维的数据，他又不能说我改了其中的两个数据，这样通常来说都是不断的插入新的 512 维的数据两边一条，所以在这个当中其实确实如果真跑起一个 raft 集群的话，可能对网络会有一定的压力，所以这也是一直在考虑的一个问题。
Attendee B：
好的好的，感谢。
顾老师@Milvus：
非常感谢 Yan 对我们这个项目这么的关注，我们其实在 Slack 上也有一个开发者的频道，也欢迎大家就是想要参与到项目开发的同学能够加入到里面，我们以后也会把我们的社区变得更有组织性，如果对于那些想要参与到开发工作当中的同学的话，我们也会有更多的这种深度的技术交流的这种机会，去探讨这些未来的 roadmap 之类的。
希望加入 Milvus 为社区贡献代码吗？欢迎加入 Milvus Slack 开发者频道！
| 欢迎加入 Milvus 社区
github.com/milvus-io/milvus | 源码
milvus.io | 官网
milvusio.slack.com | Slack 社区
zhihu.com/org/zilliz-11/columns | 知乎
zilliz.blog.csdn.net | 博客
space.bilibili.com/478166626 | Bilibili
