zcdb

pstack里面有一堆blas，我猜测是不是在训练过程中，训练的时候搜索的确压力会比较大，你是在训练还没结束的时候搜索的吗？

> > pstack里面有一堆blas，我猜测是不是在训练过程中，训练的时候搜索的确压力会比较大，你是在训练还没结束的时候搜索的吗？ > > 你说的训练是什么意思呢？我这边是先插入了一条向量数据，成功了之后再重复查询这条数据，发现线程会一直增加。而且在停止请求之后线程数也不会降下来 训练是指训练索引，不过你只插入了一条数据，那就还没有开始训练。你重复查询的话请求正常返回了吗？ 另外看你的建表语句，dimension=2，但是nsubvector=32，这种设置是没啥意义的，最好dimension可以整除nsubvector，不过也不应该出现这种情况，你可以设置nsubvector=2试试吗？

https://vearch.readthedocs.io/zh_CN/latest/quick-start-guide.html 参照文档安装一下rocksdb的相关依赖吧

向量维度是多少呢？如果编译的时候指定-DPERFORMANCE_TESTING=ON gamma.log有各阶段详细的耗时，能看一下那些阶段耗时比较高吗？ 另外试过设置efSearch更大，且打开efSearch check吗？ 如果数据量增大，耗时会增大，但是hnsw图模型的特点不会导致耗时跟数据量同步增长的，跟ivfpq这种不太一样

128维的话这个耗时的确感觉是偏高的。我们用sift1m测试过单条应该就1ms左右吧，可以使用sift1m测试一下看看是不是有哪没对齐？或者先使用“metric_type”:"L2"试试，hnsw对L2更友好一点，构图效果可能会更好

我刚才又测试了一下，sift1m topn=2000，单条搜索整体耗时平均4.5ms左右吧。对了，你们用的版本是哪个版本？我的测试是基于github master最新的版本

sift1m数据集有100万数据，我测试的参数"nlinks": 32, "efConstruction": 200, "efSearch": 64。avx2指令集你测试的机器支持吗？

打开了，sift1m这种参数下打开召回也是比较高的

你的recall@2000是怎么算的呢？

如果是这样计算的话，那打开efSearch check是不好保障召回。不过你的场景必须要求top2000的值都尽可能命中吗？这样的话考虑到高召回，这个耗时应该是正常的