调优建议
查询模块
保证ES节点有充足的内存
ES默认分配节点一半的内存给JVM（最多会分配30GB），剩余的内存用于向量索引和pagecache，节点内存不足会导致频繁触发向量索引的驱逐和加载，导致查询延迟较高。
因此需要确保数据节点有足够的内存，使向量索引常驻内存。可以通过以下方式获取节点向量数据的内存使用情况。
1GET /_bpack/_knn/stats
2GET /_bpack/_knn/nodeId1,nodeId2/stats // 获取指定节点nodeId1，nodeId2的内存使用情况，使用逗号进行分割如果发现内存不足，建议参考资源评估建议进行集群容量规划。
首次查询之前把数据进行预加载
默认情况下，ES的向量索引构建完成后，不会主动加载到内存中。并且在首次查询中会触发加载，只有向量数据全部加载到内存中才能进行查询。
在首次查询前，可以通过如下指令提前预热数据，降低延迟：
1GET /_bpack/_knn/warmup/my_index1, my_index2尽量减少segment的数量
ES中的索引的基础存储单元为segment。在KNN算法中，每个segment都会单独构建向量索引，因此在搜索过程中需要检索每个segment。
如果索引中segment的划分过于琐碎，会影响检索的速度。一般情况下，可以通过BES的定时任务，定期把琐碎的segment合并。
当然也可以在写入结束后的业务低峰期，通过force_merge强制执行合并，减少segment的数量，提高检索的效率。
1POST /my-index-000001/_forcemerge?max_num_segments=3尽量避免从_source中查询向量字段
在构建索引过程中默认会把原始JSON存储在_source字段中，因此搜索结果中的每一次命中索引都包含完整的_source内容。
当索引包含高维度向量字段时，_source可能比较大，加载成本就很高，这可能会显著降低KNN搜索的速度。
尽量使用doc_value存储数据
doc_value和_source存储的内容是一致的，但是doc_value是面向列式存储的，因此会拥有更好的排序和聚合效率。
创建索引过程中，不需要特地打开 doc_value 开关，ES对于绝大多数类型的数据会自动构建 doc_value 。
1对于 text 类型的数据，不会构建 doc_value 而是存储在 _source 中。
2因此如果可以的话，建立索引过程中尽量使用 keyword 类型代替 text 类型。查询过程中，可以指定查询doc_value中字段，减少加载_source数据，加速查询效率。
查询方式如下所示:
1GET /my_index/_search
2{
3 "query": {
4 "hnsw": {
5 "vec": {
6 "vector": [
7 0.495662,
8
9 ...
10
11 -0.10869
12 ],
13 "k": 10,
14 "ef": 200
15 }
16 }
17 },
18 "size": 10,
19 "_source":false, // 规避加载 _source 中的数据，加速查询效率
20 "docvalue_fields":[
21 "id",
22 "tag_keyword"
23 ] // 填写需要从 doc_value 中查询的字段
24}关闭默认的自动构建mapping开关
对于字符串类型的字段，自动构建的mapping会默认同时构建text和keyword类型数据，比较浪费磁盘空间。
如果不需要对字段进行全文检索，则只需要设置keyword类型即可。
也可以通过下面配置，设置默认构建单一类型：
1PUT index
2{
3 "mappings": {
4 "dynamic_templates": [
5 {
6 "strings": {
7 "match_mapping_type": "string",
8 "mapping": {
9 "type": "keyword"
10 }
11 }
12 }
13 ]
14 }
15}规避使用_source存储数据，减少查询过程中的数据加载量
在构建索引的过程中，可以通过如下方式禁用_source字段:
1PUT my-index-000001
2{
3 "mappings": {
4 "_source": {
5 "enabled": false
6 }
7 }
8}但是禁用_source的操作需要您深思熟虑后进行，因为禁用_source后以下功能将无法使用
- 无法使用
update,update_by_query以及reindex的API，也无法从一个集群的索引reindex到另一个集群 - 无法使用高亮
- 不能修改索引的
mappings和analysis
也可以对向量字段不构建_source，只对标量字段构建
1PUT my-index-000001
2{
3 "mappings": {
4 "_source": {
5 "excludes": [
6 "vec", // 可以直接指定不构建_source的字段
7 "vec.*" // 也可以通过通配符进行模糊匹配
8 ]
9 }
10 }
11}写入模块
合理配置shard数量
为了使shard分配的更加均匀，从而避免写入热点，建议把shard数量设置成节点数量的整数倍。
shard数量设置方法如下所示:
1PUT /my_index
2{
3 "settings": {
4 "index": {
5 "number_of_shards": 3 // 索引的分片数量，创建后无法修改。
6 }
7 }
8}合理设置replica的数量
没有副本意味着节点丢失可能会导致数据丢失，因此多副本对于数据安全十分重要，以便在出现问题时可以重新加载数据。
并且适度增加副本数量，可以增大查询过程中的并行程度，从而提高查询效率。
每增加一个副本都会增加集群磁盘成本，并且副本数不能大于节点的数量。
1在多副本情况下，写入过程可以先设置副本数 index.number_of_replicas 为0，增加写入的速度。
2PUT /my_index/_settings
3{
4 "number_of_replicas": 0 // 分片的副本数量，取值范围[0, 节点数-1]，可随时修改
5}
6在写入完成后，再把副本调整到合适的数量。合理调整refresh间隔
refresh_interal是用来控制多久把内存里的数据刷出segment的。ES会对刷出的segment进行合并，如果合并不过来会阻止写入。
所以把refresh_interval调大，也可以把刷出的segment变大，降低合并的频率，提升导入性能。
调整refresh_interval方式如下：
1PUT /my_index/_settings
2{
3 "index.refresh_interval": "10s"
4}写入速度流程优化
使用bulk请求写入数据
bulk请求写入效率比单个索引请求性能更好，尽量使用bulk请求进行数据写入。
1为了知道批量请求的最佳大小，可以在具有单index的单节点集群进行上进行测试。
2首先尝试一个批次包含100个document，之后测试一个批次包含200个，以此类推，在每次测试过程中将批量请求中的document数量增加一倍。
3当索引构建的速度开始趋于平稳时，批量请求需要包含的document数据就达到了的最佳大小。增加索引构建并发
当构建较大数据量的向量索引时，可能会出现build较慢的情况。 可以根据分片数和节点CPU核数，在写入数据前适当调整"bpack.knn.hnsw.index_thread_qty" 。
例如，1kw数据量，1节点2分片，节点为16核CPU，我们可以把"bpack.knn.hnsw.index_thread_qty" 设置为4-6（如果设置为8，会使CPU满载，生产环境可能有风险），可以提高构建索引效率。
调节方式如下：
1PUT /_cluster/settings
2{
3 "persistent" : {
4 "bpack.knn.hnsw.index_thread_qty":3
5 }
6}"bpack.knn.hnsw.index_thread_qty" 参数设置偏大，会导致构建时启动线程过多。在负载比较高的集群，不建议调整这个参数，以免集群满载。
如果写入和构建向量索引偏慢，可以通过临时减少集群负载（减少其他写入和查询），并调大"bpack.knn.hnsw.index_thread_qty"的方式来加快构建 ，等到构建结束，再将"bpack.knn.hnsw.index_thread_qty" 调整回1。
自动生成DocumentID
当写入索引过程中指定 _id 时，ES需要检查同一分片中是否已存在具有相同 _id 的document，这是一项成本高昂的操作，并且随着索引的增长，成本会变得更高。
如果使用场景允许，建议写入过程中不指定_id, ES可以跳过检查，从而加快索引速度。
1POST _bulk
2{ "create" : { "_index" : "test1"} } // 不指定 _id
3{ "create" : { "_index" : "test2", "_id" : "3" } } // 指定 _id