Milvus为什么需要load整个index data到内存中，而不是类似MySQL这种传统数据库做分片加载

[LangKing9]

Milvus为什么需要load整个index data到内存中，而不是类似MySQL这种传统数据库做分片加载
我现在有100M的vector数据，1536维，全部load到内存中，感觉会非常庞大。

[yhmo]

分片加载，swap这些功能正在做，以后可以加载更为灵活。

[LangKing9]

请问有预期计划么，目前milvus只存id 和 vector，后面接了个MySQL，拿到id去mysql看正文。尽量让他load少。
请问这个方案科学么

[yhmo]

2.4版本的后续小版本会有动态加载的方案，估计也就一两个月的事情吧。现在把标量数据接到mysql里节省内存也没啥问题。

[secsilm]

请问你load一次需要花多少时间？业务上每来一条数据就要query和insert，不能每次都load吧？

[yhmo]

load()只调用一次就可以，只要调用一次之后，它会自动把新增的数据放进内存里。
load做的事情是从存储里读取文件数据到querynode的内存里，load的耗时就要看存储系统的读带宽了。

[secsilm]

好的谢谢。

[xiaofan-luan]

2.4已经支持了mmap功能了（ https://milvus.io/docs/mmap.md）。需要注意的是这样做性能可能会非常慢，尤其是向量索引，原因是向量的查询locality很差，对磁盘的io要求很高。所以这非常看你的use case

[LangKing9]

我现在会有1 billion 的向量数据 维度1536维，那就是计算下需要多少内存，硬件就得配齐了对吧

[yhmo]

可以使用这个工具来估计资源用量：https://milvus.io/tools/sizing/
Number of vectors 单位是Million，所以你就填1000
索引如果选HNSW/IVF_FLAT的话，每1GB数据就要用1GB内存；如果选IVF_SQ8/IVF_PQ，每1GB数据要使用大约250MB内存。后面那种的召回率要低一些。

1 billion 1536 dim 需要的资源很多，这个工具是把最小理论值乘以了一个大约2.0的安全系数的。你可以不完全按照它推荐的来，但也不能太抠。

[chenxilol]

我想问一下Get之前需不需要Load

[yhmo]

@chenxilol
Get是指的Query么，凡是要调用query()或者search()之前都必须要先调用load().

[LangKing9]

估出来是 1144.5 G
基本1T内存是要的咯？
您说的向量的locality不太好，所以市面上其它方案，也肯定需要消耗这些内存对吧。
否则就会严重降低检索效率
感觉整1T内存的云服务器成本比较高，请问有什么处理思路么

[LangKing9]

或者1billion数据，vector维度可以弄256
用openai的embedding拿到的是1536维，可以自己拿显卡部署什么embedding模型，把维度降下来么
数据也可以清洗下，降到100Million的样子

[yhmo]

你自己算一下，向量每个维度的值是float32，占用4个字节。每条1536维的向量占用的空间是6KB。1000条就是6MB，一百万条6GB，一亿条就是600GB，十亿条就是6TB。这个是理论值。
然后用不同的索引类型使用的内存关系如下：
HNSW/IVF_FLAT ------------- 这两种需要的内存和理论值基本相等
IVF_SQ8/IVF_PQ-------------- 这两种需要的内存大约相当于理论值的25%~30%

如果除了向量之外还有别的字段，比如Int64类型的字段，十亿条就占用 十亿乘以8字节 这么多空间。如果是VARCHAR类型，那就跟字符串的长度相关，由于是用UTF-8编码，每个字符可能占用1～4字节。

所以，你基本可以按这个路子估计出任意数据所需的最小内存。

选择占内存小的索引是最简单的方法。降维也是一个方法，但降维的工具你要自己去找。

[LangKing9]

哦哦谢谢，明白了

1. 换索引类型
2. 降维
   HNSW/IVF_FLAT更适用于高维向量且对内存和查询速度有较高要求，而IVF_SQ8/IVF_PQ适用于大规模数据且能够在较低的内存消耗下实现高效的近似最近邻搜索。
   不知道这个对索引选用的说法对不对。像我这个大规模数据，感觉是得用IVF_SQ8/IVF_PQ去搞

[LangKing9]

另外mmap也可以做个测试对吧，相当于就是 动态load，unload。需要消耗这个加载 卸载的时间吧

[xiaofan-luan]

IVF_SQ8对搜索精度有较大影响
DiskANN需要高性能磁盘，并且对延迟有很大影响
HNSW需要较多的内存使用
你也可以直接使用Zilliz cloud的Capacity optimized 实例，目前是性价比比较高的选择。1亿向量大概只需要16CU，大概一万多一个月

[LangKing9]

如果是开服务器的话，一般256G内存最少对应32核，32核是不是大概率都会空闲呀

[LangKing9]

https://docs.zilliz.com.cn/docs/cu-types-explained#assess-capacity
我看这里说的经济型也是毫秒级延迟

[LangKing9]

只做主键查找的话，标量库 用Mysql/pg 还是 mongodb这种 会更优呀

[yhmo]

向量维度其实我们不会给建议，只要是2到32768之间都可以。降维会影响召回的效果，有多大影响未知，所以由用户自己决定。
标量库我觉得这几个成熟的db都可以吧，你自己可以用自己的数据拿三套db对比一下。
关于zilliz cloud的性能数据，我找个人跟你对接下。

[LangKing9]

好的 谢谢，如何联系？
准备采购

[yhmo]

中国区的话在这里填个表，然后就有人联系你了：https://zilliz.com.cn/contact-sales

[LangKing9]

Zilliz Cloud迁移数据 带宽情况怎样呢，害怕打完embedding的数据导入花好几天。

[xiaofan-luan]

可以联系我们，我们有批量导入文件的方式

[LangKing9]

已经填表啦，销售什么时候会来电呀，想一起咨询一下

[yhmo]

请各位提问时尽量使用英语，Milvus社区里有世界各地的工程师，用英文问答所有人都能看得懂。