我使用milvus2.3 版本，存储一条数据需要6-10s，存储批量的数据也差不多这个时间，但是我们有单条新增接口的需求。我们有个自研的faq后台，用户在自己新增数据的时候， 就感觉很慢，我想请教有什么方法进行优化吗，主要是建立集合和插入数据比较慢，还在创建集合后加载也很慢，我在互联网检索不到相关的资料，请大佬帮忙看一下，谢谢。

[zhangnn520]

我使用milvus2.3 版本，存储一条数据需要6-10s，存储批量的数据也差不多这个时间，但是我们有单条新增接口的需求。我们有个自研的faq后台，用户在自己新增数据的时候， 就感觉很慢，我想请教有什么方法进行优化吗，主要是建立集合和插入数据比较慢，还在创建集合后加载也很慢，我在互联网检索不到相关的资料，请大佬帮忙看一下，谢谢。

[zhangnn520]

[zhangnn520]

[yhmo]

调用collection.insert()之后不要调用collection.flush()

不知道你客户端代码怎么写的，只能猜

[IIIya]

请问为什么不要flush呢

[xiaofan-luan]

flush本身就是一个很慢的操作，数据的持久化也不依赖flush

[zhangnn520]

是的，谢谢大佬 ---- 回复的原邮件 ---- 发件人 ***@***.***> 日期 2024年02月01日 15:59 收件人 ***@***.***> 抄送至 ***@***.***>***@***.***> 主题 Re: [milvus-io/milvus] 我使用milvus2.3 版本，存储一条数据需要6-10s，存储批量的数据也差不多这个时间，但是我们有单条新增接口的需求。我们有个自研的faq后台，用户在自己新增数据的时候， 就感觉很慢，我想请教有什么方法进行优化吗，主要是建立集合和插入数据比较慢，还在创建集合后加载也很慢，我在互联网检索不到相关的资料，请大佬帮忙看一下，谢谢。 (Discussion #30421) flush本身就是一个很慢的操作，数据的持久化也不依赖flush — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[zhangnn520]

大佬，我把集合flush注释掉，也发生了一个问题。我们的faq服务需要支持对存入milvus数据库的数据进行编辑，比如有个场景:数据刚刚单条存入数据，用户发现错了，想去修改一下，此时由于注释掉flush,可能数据还在内存中，没有存入数据库，导致修改接口在milvus找不到数据，从而无法进行修改，大佬对此有什么解决方案吗。我真的是一步一个坑，哈哈哈哈。 ---- 回复的原邮件 ---- 发件人 ***@***.***> 日期 2024年02月01日 15:59 收件人 ***@***.***> 抄送至 ***@***.***>***@***.***> 主题 Re: [milvus-io/milvus] 我使用milvus2.3 版本，存储一条数据需要6-10s，存储批量的数据也差不多这个时间，但是我们有单条新增接口的需求。我们有个自研的faq后台，用户在自己新增数据的时候， 就感觉很慢，我想请教有什么方法进行优化吗，主要是建立集合和插入数据比较慢，还在创建集合后加载也很慢，我在互联网检索不到相关的资料，请大佬帮忙看一下，谢谢。 (Discussion #30421) flush本身就是一个很慢的操作，数据的持久化也不依赖flush — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[yhmo]

没flush的数据upsert应该也能修改

[zhangnn520]

谢谢大佬 ---- 回复的原邮件 ---- 发件人 ***@***.***> 日期 2024年02月04日 10:03 收件人 ***@***.***> 抄送至 ***@***.***>***@***.***> 主题 Re: [milvus-io/milvus] 我使用milvus2.3 版本，存储一条数据需要6-10s，存储批量的数据也差不多这个时间，但是我们有单条新增接口的需求。我们有个自研的faq后台，用户在自己新增数据的时候， 就感觉很慢，我想请教有什么方法进行优化吗，主要是建立集合和插入数据比较慢，还在创建集合后加载也很慢，我在互联网检索不到相关的资料，请大佬帮忙看一下，谢谢。 (Discussion #30421) 没flush的数据upsert应该也能修改 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[zhangnn520]

大佬，我能加您微信吗，这样可以方便向您请教问题。 ---- 回复的原邮件 ---- 发件人 ***@***.***> 日期 2024年02月04日 10:03 收件人 ***@***.***> 抄送至 ***@***.***>***@***.***> 主题 Re: [milvus-io/milvus] 我使用milvus2.3 版本，存储一条数据需要6-10s，存储批量的数据也差不多这个时间，但是我们有单条新增接口的需求。我们有个自研的faq后台，用户在自己新增数据的时候， 就感觉很慢，我想请教有什么方法进行优化吗，主要是建立集合和插入数据比较慢，还在创建集合后加载也很慢，我在互联网检索不到相关的资料，请大佬帮忙看一下，谢谢。 (Discussion #30421) 没flush的数据upsert应该也能修改 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[yhmo]

微信公众号搜索“Zilliz”，关注，然后随便打开里面的一篇文章，下文章末尾有milvus微信用户群的二维码，扫码进入

[zhangnn520]

我今天在做删除数据发现milvus数据库数据集没有减少，我查了资料发现他只是将删除的数据做了处理，只是在检索的时候找不到了，实际数据还在数据库的，我想请教大佬有什么方法可以查出删除后实际数量(如果数据被删除应该从数量中减去)，我也找了很多方法，包括参考官方源码，并没有找到，源码中有个num_entities的方法，但是查询出来的数量也是包含删除的数据，这样导致我们对我显示milvus实际数量与一起存入es数据对不上，我也很头疼，找不到什么方法 ---- 回复的原邮件 ---- 发件人 ***@***.***> 日期 2024年02月04日 10:03 收件人 ***@***.***> 抄送至 ***@***.***>***@***.***> 主题 Re: [milvus-io/milvus] 我使用milvus2.3 版本，存储一条数据需要6-10s，存储批量的数据也差不多这个时间，但是我们有单条新增接口的需求。我们有个自研的faq后台，用户在自己新增数据的时候， 就感觉很慢，我想请教有什么方法进行优化吗，主要是建立集合和插入数据比较慢，还在创建集合后加载也很慢，我在互联网检索不到相关的资料，请大佬帮忙看一下，谢谢。 (Discussion #30421) 没flush的数据upsert应该也能修改 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[yhmo]

num_entities 不统计被删除的行数。
要统计精确的行数，使用count(*)
https://milvus.io/docs/query.md#Count-entities

[zhangnn520]

谢谢大佬 ---- 回复的原邮件 ---- 发件人 ***@***.***> 日期 2024年02月04日 13:05 收件人 ***@***.***> 抄送至 ***@***.***>***@***.***> 主题 Re: [milvus-io/milvus] 我使用milvus2.3 版本，存储一条数据需要6-10s，存储批量的数据也差不多这个时间，但是我们有单条新增接口的需求。我们有个自研的faq后台，用户在自己新增数据的时候， 就感觉很慢，我想请教有什么方法进行优化吗，主要是建立集合和插入数据比较慢，还在创建集合后加载也很慢，我在互联网检索不到相关的资料，请大佬帮忙看一下，谢谢。 (Discussion #30421) num_entities 不统计被删除的行数。 要统计精确的行数，使用count(*) https://milvus.io/docs/query.md#Count-entities — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>