先交代下我们的使用场景。我们是把一张分库分表的逻辑表导入了 OpenSearch,建立了相关索引,供后台管理界面查询使用。最近在使用的过程中遇到了几个问题。记之。
我们有一个数据导出功能,当导出的数据超过 5000 条时,导出的表格里就只有 5000 条。我们使用的是 search 接口分页查,看日志发现当 startHit 到 5000 左右就返回失败了。咨询了下得知 search 接口为了保证能及时返回,当 startHit + hit > 5000 时就返回失败了。如果需要获取全量的数据需要用 scroll 接口。V3 可以参照这个来写,scroll迭代查询Demo,V2 的文档不太完善,试了几次才试出来。。。
我们的查询页面需要按照多个维度来查询,比如日期,发货仓,到货地等,而且都是多选,当日期跨度范围比较大的时候,query 子句的日期部分是这样的:
timekey: "2017-06-01" OR timekey: "2017-06-02” OR timekey: "2017-06-03” ...
当日期跨度比较大的时候发现查询又失败了。咨询了下 Hooch,query 子句编码后长度不能超过 1k,filter 子句长度不能超过 4k。然后教了我一种简洁的写法。
timekey:"2017-06-01"|"2017-06-02"|"2017-06-03” ...
然而只是这样还是不够,日期只是我的查询条件之一,几个条件加起来很容易超过 1k。比如到货地,当按照某个行政级别(比如省)查询时,需要把该级别和该级别下面各级别的数据都筛选出来,如果也这样遍历的话很容易就超了。想过把部分条件放到 fitler 子句里,但是 fitler 子句只支持 “> <“ 这样的过滤条件。另外想到的就是分多次查,但是分多次多个查询条件怎么拆分,还有怎么做分页,想想就觉得很痛苦。
继续翻文档的过程中,发现 OpenSearch 支持 “^31” 这样的语法来查 31 开头的数据(字段类型需是 SHORT_TEXT,分词模式选模糊分词),而地址 id 下级地址和上级地址的前缀又是一样的,通过这种方式很容易匹配一个行政级别下面的数据。同样的思路,其他字段的查询语句超长时,我也可以通过求公共前缀的方式来压缩长度。
联想了一下,对语句长度做限制应该是普遍存在的,为什么在之前使用 MySQL 批量插入的时候没遇到过类似问题。查了下,MySQL server 的max_allowed_packet 参数是限制接收到的包体长度的,默认值是 1M。
运营同学在使用过程中发现有时会丢失一些数据。继续咨询,得到的回复是这样的
引擎更新文档是一整篇更新,更新流程是 先 delete 再 add。所以会有一瞬间找不到文档
这个问题目前没有解决方法,记录更新得越频繁就越容易出现这种情况。对于“频繁”没有具体的参数值,但是一秒钟有几次更新的话会被认为频繁。
最后,感谢 @Hooch 和 @本岩的答疑。