全文索引fulltext速度太慢，可以单独对某个表进行吗？在es中_id编码规则是什么样的？

问答 问题
,
1

你好，我们的版本是3.4.0，现在我们使用的主要问题是全文索引构建的速度太慢，我们用了三个storage 组成了一个集群，然后在这三个storage 上开了三个listener ，rebuild后索引构建速度特别慢，20个小时可能构建了500万条，在我们的场景中需要全文索引的属性有50+，我们的数据量中属性的数量是百亿级，请问应该如何加速rebuild fulltext index 的速度，或者在使用中我们可以指定哪个index 首先同步吗？就是在rebuild fulltext index中指定哪个index可以首先构建？有什么方法可以加速构建全文索引吗？在docs中提示数据量大时，重建全文索引速度较慢，可以修改 Storage 服务的配置文件（nebula-storaged.conf）中snapshot_send_files=false，但是在conf 中并没有snapshot_send_files的这个配置项，请问如何加速全文索引的构建，或者是否rebuild的时候能够指定哪个索引？

我们有三个实体机，如果多创建几个docker，在docker里多开几个listener，rebuild的速度会快一些吗？

目前如果同步属性的速度上不去我们想尝试自己搜索然后生成es 语句入库，请问你们的id的生成方式是什么？这个id应该与更新数据有关，我们应该怎么生成这个id呢？“_id” : “FIPCJILONJHKKKGBMFCKOBNNDKBFCMPLJHDMODHGMFHHAHOOPHFPHFJIKKLMEGIF”

此外，在查询时，给定的全文检索默认只能返回es 的首页结果，例子中没有提供scroll翻页功能，我们只能把es 的index 设置的更大，请问有什么方法可以翻页检索吗？类似es的scroll

2

storage（不是listener）的配置里的snapshot_send_files要改为false

3

3.4没有支持分页功能

4

image
image791×530 153 KB

这个是我们的nebula-storaged.conf中搜索到的snapshot相关的，我们直接添加一个参数吗？

5

另外我们在某些环境下测试提示 curl error 28， 但是一般第二次请求就对了，最多不超过3次请求能获得正确的结果，这个从日志里也看不出问题，日志就提示curl error 28， 但是都是很长时间不用后的第一次请求报这个错，再次请求就不会报错了，这个可能是什么原因造成的？给我的感觉好像是第一次建立连接出问题了，连接建立后就没问题了，感觉之前连接过期了，你们碰到过这个问题吗？这个应该不是listener变化搜不到的问题，虽然改了es也会报这个错误，但他们是一直搜不到，而我们的问题是第一次一般搜不到，再发送一个请求就可以了

6

此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。