点击查看 Milvus 社区十大关键词(下)

原创
01/30 17:36
阅读数 16

在昨天的文章《点击查看 Milvus 社区十大关键词(上)》中,我们提到将 2023 年所有 Milvus 技术交流群的聊天历史做了整理分析,得到了如下的一张词云图:

按照热度,排名前十的关键词依次为:版本、查询、内存、插入、配置、日志、集群、文档、 部署、删除。昨天我们已经详解了前五大关键词,今天我们来聊聊剩下的其他五个关键词!

01.「日志」:问题定位的指南针

  • “2.X 集群的日志在哪里导啊”

  • “现在没有对 Milvus 进行任何读写操作,但是日志还是不断增加,这正常吗?”

  • “请教下 k8s 部署的 Milvus 日志如果持久化,只能使用共享存储吗?如果只想放在本地盘可以如何配置?”

社区讨论问题的时候基本都离不开日志,因为日志是问题分析的第一抓手,也是问题定位的指南针。大家在社区中发的日志非常多,不同日志背后的原因各不相同,我们不可能在这里讨论清楚所有的报错日志。但是关于日志有一些共性的问题,可以给大家一些建议。

首先是 Milvus 的日志怎么看、怎么导,Milvus 的 GitHub 仓库里面提供了一个日志导出的脚本 export-milvus-log.sh,可以做到一键式地导出集群所有日志,尤其是大家在提 issue 的时候,提供一份完整的日志对于问题的快速定位至关重要。

其次是日志等级问题,为了满足不同的应用场景,Milvus 提供了多种日志级别。正常情况下,大家使用 info 等级就够了,在做一些问题 debug 的时候,才需要调成 debug 等级,debug 级别的日志会非常多,当你发现 Milvus 的日志非常多的时候,大概率是日志等级设错了。

最后还有一点,Milvus 默认是把日志输出到标准输出的,而 container runtime 一般都有 log rotation,会做不定期的清理。如果有条件,最好为 Milvus 接入一套日志采集系统,比如 Loki,后续发生问题再去回查日志也会方便很多。

02.「集群」:生产环境永远推荐使用集群模式

  • “Milvus单集群,能到百亿向量吗?还是到十亿级?”

  • “Milvus standalone 中的数据如何迁移到 Milvus 集群中?”

  • “coordinator 能做集群么?”

  • “Milvus 集群版依赖太多了,资源很缺,部署单机版支持主从或者多副本么?”

Milvus 是一个分布式的向量数据库,“分布式”是它的一个核心特点。目前市面上的向量数据库非常多,如果你在寻找一款分布式的向量数据库,那么 Milvus 一定是个不错的选择。线上生产环境的数据库系统基本都需要可扩展和高可用能力,因此在生产环境中,永远推荐使用 Milvus 集群模式。Milvus 是一个存算分离的架构,当数据量增长以后,只需要扩展计算节点和存储节点的资源,理论上只要资源足够,能容纳的数据也是没有上限的。在目前的社区中,最大数据规模已经到了 100 亿的体量。

此外,针对“集群”讨论里的还有其他几个话题,目前 Milvus 的 backup 工具可以支持将 Milvus standalone 中的数据迁移到 Milvus cluster 中。其次,从 Milvus 2.2.3 版本之后,Coordinator 节点已经可以支持多副本的能力,具体配置方法参考。另外是关于使用单机版支持主从和多副本的问题,理论上是可以的,但是用户需要自己保证数据的一致性,以及主备间的 HA 切换,整体实现的难度可能比部署一个 Milvus 集群还要高不少。

03.「文档」:80% 的答案就在官网文档里

了解一个数据库最快的方法就是阅读它的文档,Milvus 也不例外,社区里面 80% 的问题,都可以直接在官方文档里面找到答案。下面是一些社区中常见的关于“文档”的讨论:

  • “partitionkey 怎么使用?好像没看到相应的文档。”

  • “Milvus 2.3 单机版有 3 个组件,etcd minio 都是什么作用,怎么交互的,有相关文档么?”

  • “Milvus 每次上传文档,怎么建立索引,然后问答时候根据指定文档回答。”

归纳起来,社区里面关于文档的问题,主要分两类——使用文档和原理文档。获取的首要途径一定是 Milvus 官网,之前也在一些文章里讲过了,对于每一个想要学好 Milvus 的人,官网文档值得至少 5 遍以上。而关于 Milvus 的使用,除了官网之外,各个 sdk repo 的代码示例也非常值得去仔细研读。至于原理类的文档,前文的“查询”关键词章节也提供了一些官网之外的参考资料,大家可以根据需要了解。

04.「部署」:简化部署一直在路上

  • “docker-compose 能部署分布式吗?”

  • "单机部署为什么还依赖这么多组件?"

  • “大家 Milvus 集群部署有没有实践过比较好的方案?”

作为一个开源数据库,是否能够进行快速部署,是所有工作的前提。在简化部署的道路上,社区从来没有停止过脚步。2023 年,社区推出了 Milvus-lite 这样的轻量化版本,没有 k8s、没有 docker、依旧能玩 Milvus。

之前有用户反映当下 Milvus 的消息系统 Kafka/Pulsar 太重,社区在 2.3.0 版本中推出了更轻的 NATS MQ 方案,未来自研 MQ 的方案也已经在路上了。对于 node 节点太多的问题,社区在 2.3.0 版本中合并了 IndexCoord 和 DataCoord,并且接下来的版本还会将 DataNode 和 IndexNode 进行合并,未来需要管理的节点将会进一步减少。对于 docker 部署单机版本依赖多的问题,社区也会在近期推出纯“standalone”的版本,不需要任何依赖。Milvus 的迭代发展大家有目共睹,请大家相信,只需要一些时间,社区一定会把简化部署这件事情做好。

05.「删除」:眼见未必为实

  • “执行 Collection 中的 delete 操作后,再次调用 num_entities 检查集合中的数据的条数,和删除前一致, delete 不能从物理层面上删除数据吗?”

  • “删除的数据还能被查到是为什么?”

  • “请问下删除 collection 后,磁盘大小没有恢复,该怎么处理?”

社区中关于“删除”讨论最多的是,删了为什么条数没变,删了为什么还可以搜到,删了为什么磁盘还没恢复。第一眼看到的未必是真相,上面这几个问题也是如此。由于之前设计的原因,num_entities 检查集合条数并不能实时统计到被删除的条数,在 2.3.0 版本中,为了解决这个行数统计的问题,在 query 接口里面专门引入了count(*) 表达式来统计准确行数。

其次,被删除之后还能查到,大概率是因为查询一致性等级的原因,对此大家可参考《聊聊 Milvus 的几种一致性等级》,里面详细讨论了这个问题。对于做完删除,磁盘不恢复的问题,是因为 Milvus 内部做 GC 是有一段时间等待,这个时间段可以通过dataCoord.gc.dropTolerance这个参数来控制。默认留一个时间等待,而不是立即清理,也是为了在一些紧急时刻,比如误删集合,留一个后悔药的机会。

至此,2023 年 Milvus 社区十大热门关键词解析就全部结束了,希望这 2 篇文章能够给那些正在使用 Milvus 或者将要使用 Milvus 的朋友一些启发和帮助,未来能够在自己的业务中用对 Milvus、用好 Milvus。2024 年,也希望更多的小伙伴能加入 Milvus 社区这个大家庭,一起见证全球最流行向量数据库的发展进步!

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部