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 社区这个大家庭，一起见证全球最流行向量数据库的发展进步！
