Alsace-lee
Alsace-lee
各位好,目前我们在2副本和3副本的集群中进行集群重启操作,有概率复现如下问题 1)集群ps节点重启期间如果存在请求写入,则有大概率,集群重启后无法选出主节点,但可进行搜索 2)ps 节点重启过程,主节点如果不是最后一个重启节点,否则集群重启后无法选出主节点,但可进行搜索 3)ps 全部进行重启时,个别节点重启后可能无法加入集群 在生产环境中,遇到这些问题我们很难有完整的规避手段来避免集群不可用,比较头疼 相关issue似乎较多,请问是否有注意到这些集群节点同步的问题与跟进。 如果需协助,我们可以提供完整复现流程和日志。 感谢!
因需求需要对某table中的向量进行无监督的聚簇处理 然而实际上索引中就已经存在聚簇索引了 请教一下,是否有无入侵的办法获取到这部分聚簇信息? 感谢
因需要使用最近修复的功能,我们根据编译文档中的方法,使用3.2.7的基础环境镜像编译了vearch镜像 目前在使用过程中发现如下问题: 1、顺序启动master、router、ps ×2之后,通过_cluster/stats接口观察ps节点状态,两个节点均显示runtime error: invalid memory address or nil pointer dereference,更换为3.2.7版本官方镜像后则能正常注册。 2、router节点能够正常启动,启动后发送若干次请求之后则会退出。附error日志 个人怀疑可能与多线程相关配置有关,router节点在设置了容器的memset与cpuset之后环节了崩溃的问题,但依旧存在。 请问是否有相似的问题经验,从容器与docker本身的日志里来看,并没有直接预告shutdown的日志[](url)
vearch中存在两个多向量查询的API,分别是msearch和bulk_search 前情: msearch的原理是拼合向量请求并在服务端切割,但这样一来,所有搜索的参数与每条向量返回的数量就被限制为同样的参数。 由于业务需求,我们使用bulk_search进行多向量批量查询,在不同的query参数中带入size来解决这个问题。 目前遇到如下现象: msearch的结果中,子结果集的顺序与查询向量的顺序保持一致,并且这个问题查询到了相关issue:#513 bulk_search的结果中,子结果集的顺序仍然乱序 如下图: 查询请求的size分别为3与2,结果中前后顺序随机 附版本信息,11月8日checkout的master源码 "version": { "build_version": "3.2.7", "build_time": "2021-11-08 19:58.26", "commit_id": "8a1ddee587bb7db56e0087ad7d322cf2af8caef7" }
背景: 因业务测存在删除历史索引的需求,我们在table中增加了一个index_version字段,字段为long且index=true,全量更新后,期望删除该全量更新动作开始时间点之前的历史数据。 使用deleteByQuery接口理论上可以满足此需求,只需要进行如下入参即可 { "query": { "filter": [ { "range": { "index_version": { "GTE": 0, "LTE":20211021153000 } } }] } } 但实测发现,即便返回值为 { "head": { "err": { "msg": "success" }...
分别使用boost:0.5和boost:0.1进行查询,发现结果与不加boost参数的分数一样,没有生效。 请问是参数名称发生了变化还是索引有限制? [ { "query": { "sum": [ { "field": "vector", "feature": [0.038894109427928925,-0.009793886914849281,-0.0037632796447724104,0.0019075428135693073,-0.06625594943761826,-0.06498533487319946,0.07552092522382736,0.07950262725353241,-0.05313509338...], "boost":0.5 } ] } }]
最近一直在测试分片与多副本性能,所以常会遇见一些疑问,麻烦各位。 背景:在两台机器上创建了一个2分片,每个分片2个副本的业务并建立了3000w左右数据量的底库 1、在四个PS实例全开的情况下,单线程top500搜索性能(每次随机向量进行查询)一开始会在500ms左右,后续逐渐下降,直至200ms级。性能的下降可能和操作系统缓存和查询缓存有关,但是仍然没有达到预期性能。 2、尝试每个分片关闭一个节点后,性能得到了提升,top500性能在100ms左右。 疑问: 1、在搜索中是否存在“预热索引”这样的说法,我应该如何理解搜索性能在持续的调用中的逐渐上升? 2、各分片节点数量理论上不应该影响整体搜索性能,但实测下来却又有这样的影响。 最后附建表语句与搜索语句: `{ "name": "coll1", "partition_num": 2, "replica_num":2, "engine": { "name": "gamma", "index_size": 100000, "id_type": "Long", "retrieval_type": "IVFPQ", "retrieval_param": { "metric_type": "InnerProduct", "ncentroids": 16384,...
背景: 我有两台物理机器,192.168.65.218与192.168.65.210 现在想要发布一个千万级业务,业务数据切分为2片,每一片有2个节点,两台机器上的PS实例各自维护一个分片的其中一个副本,以保证每台机器拥有一份完整服务。 现在我进行这样的操作: 1. 在集群内发布4个PS实例,218机器2个,210机器2个 list/server如下  2. 发布业务,其中partitionNum=2,ReplicaNum=2 list/server如下 这里存在几个问题需要请教 每个Server标签中的Partitions数组里的元素是一个什么逻辑概念,每个元素内的replica中的数值是指什么。 这个数据结构我需要怎么解读才能够看出分片副本是否如果预期的一般分布的: 210: shard1-replica1 , shard2-replica1 218: shard1-replica2, shard2-replica2 如果不是,我应该如何进行change_member进行调整呢 问题比较特殊,麻烦诸位。