在昨天的文章《点击查看 Milvus 社区十大关键词（上）》中，我们提到将 2023 年所有 Milvus 技术交流群的聊天历史做了整理分析，得到了如下的一张词云图：
按照热度，排名前十的关键词依次为：版本、查询、内存、插入、配置、日志、集群、文档、 部署、删除。昨天我们已经详解了前五大关键词，今天我们来聊聊剩下的其他五个关键词！
01.
「日志」：问题定位的指南针
“2.X 集群的日志在哪里导啊”
“现在没有对 Milvus 进行任何读写操作，但是日志还是不断增加，这正常吗？”
“请教下 k8s 部署的 Milvus 日志如果持久化，只能使用共享存储吗？如果只想放在本地盘可以如何配置？”
社区讨论问题的时候基本都离不开日志，因为日志是问题分析的第一抓手，也是问题定位的指南针。大家在社区中发的日志非常多，不同日志背后的原因各不相同，我们不可能在这里讨论清楚所有的报错日志。但是关于日志有一些共性的问题，可以给大家一些建议。
首先是 Milvus 的日志怎么看、怎么导，Milvus 的 GitHub 仓库里面提供了一个日志导出的脚本 export-milvus-log.sh（https://github.com/milvus-io/milvus/tree/master/deployments/export-log），可以做到一键式地导出集群所有日志，尤其是大家在提 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 节点已经可以支持多副本的能力，具体配置方法参考（https://milvus.io/docs/coordinator_ha.md#Coordinator-HA）。另外是关于使用单机版支持主从和多副本的问题，理论上是可以的，但是用户需要自己保证数据的一致性，以及主备间的 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 社区这个大家庭，一起见证全球最流行向量数据库的发展进步！
本文分享自微信公众号 - ZILLIZ（Zilliztech）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。