OpenSearch 使用二三事

谢昂雄
2023-12-01

先交代下我们的使用场景。我们是把一张分库分表的逻辑表导入了 OpenSearch,建立了相关索引,供后台管理界面查询使用。最近在使用的过程中遇到了几个问题。记之。

查询的数据最多只有 5000 条

我们有一个数据导出功能,当导出的数据超过 5000 条时,导出的表格里就只有 5000 条。我们使用的是 search 接口分页查,看日志发现当 startHit 到 5000 左右就返回失败了。咨询了下得知 search 接口为了保证能及时返回,当 startHit + hit > 5000 时就返回失败了。如果需要获取全量的数据需要用 scroll 接口。V3 可以参照这个来写,scroll迭代查询Demo,V2 的文档不太完善,试了几次才试出来。。。

query 子句长度不能超过 1k

我们的查询页面需要按照多个维度来查询,比如日期,发货仓,到货地等,而且都是多选,当日期跨度范围比较大的时候,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 的时候没遇到过 sql 过长的问题

联想了一下,对语句长度做限制应该是普遍存在的,为什么在之前使用 MySQL 批量插入的时候没遇到过类似问题。查了下,MySQL server 的max_allowed_packet 参数是限制接收到的包体长度的,默认值是 1M。

查询有 doc 丢失

运营同学在使用过程中发现有时会丢失一些数据。继续咨询,得到的回复是这样的

引擎更新文档是一整篇更新,更新流程是 先 delete 再 add。所以会有一瞬间找不到文档

这个问题目前没有解决方法,记录更新得越频繁就越容易出现这种情况。对于“频繁”没有具体的参数值,但是一秒钟有几次更新的话会被认为频繁。

最后,感谢 @Hooch 和 @本岩的答疑。

 类似资料: