ES几种查询方式

Posted 2023-03-22

参考技术A 创建一个测试用的索引，格式如下：

term：精确查询，不会对输入做分词，如果输入的是"战某某"，则直接查询"战某某"，如果输入的是"浙江战某某"，则直接查询"浙江战某某"

match：模糊匹配，需要指定字段名，输入会进行分词，如输入"浙江战某某"，根据中文分词会分词为"浙江"和"战某某"，然后进行匹配。如果待查询的字段包含"浙江"或"战某某"，或者都包含，结果都会被查询出来。

根据上面第4点，可以知道match查询会对输入进行分词，我们可以指定对分词后的结果进行and和or查询。and：代表分词后的所有结果都得匹配，or：代表分词后只要有一个结果匹配就行（默认是or，上述第四点就是or的场景）

multi_match：多字段模糊查询，和match类似都是模糊查询，但multi_match可以指定多字段进行模糊查询。

query_string：和match类似，但是match需要指定字段名，query_string是在所有字段中搜索，范围更广泛（当然query_string也支持指定字段查询）。

must: 相对于条件and，必须同时满足多条件
should：相当于条件or，只要有一个或部分条件满足
must_not: 非，不满足条件

ElasticSearch第5天 es实现分页查询的几种方式

参考技术A es实现分页查询，在ES中有三种方式可以实现分页：from+size、scroll、search_after

这种分页方式虽然查询变快了，但滚动上下文代价很高，每一个 scroll_id 不仅会占用大量的资源（特别是排序的请求），而且是生成的历史快照，对于数据的变更不会反映到快照上,那么在实时情况下如果处理深度分页的问题呢？es 给出了 search_after 的方式，这是在 >= 5.0 版本才提供的功能。

searchAfter的方式通过维护一个实时游标来避免scroll的缺点，它可以用于实时请求和高并发场景。
search_after的理念是，=在不同分片上（假设有5个分片），先按照指定顺序排好，根据我们传的search_after值 ，然后仅取这个值之后的size个文档。这 5*size 个文档拿到Es内存中排序后，返回前size个文档即可。避免了浅分页导致的内存爆炸情况，经实际使用性能良好,ES空闲状态下查询耗时稳定在50ms以内，平均10~20ms。

ElasticSearch之Search_After的注意事项

1.搜索时，需要指定sort,并且保证值是唯一的（可以通过加入_id或者文档body中的业务唯一值来保证）；
2.再次查询时，使用上一次最后一个文档的sort值作为search_after的值来进行查询；
3.不能使用随机跳页，只能是下一页或者小范围的跳页（一次查询出小范围内各个页数，利用缓存等技术，来实现小范围分页，比较麻烦，比如从第一页调到第五页，则依次查询出2,3,4页的数据，利用每一次最后一个文档的sort值进行下一轮查询，客户端或服务端都可以进行，如果跳的比较多，则可能该方法并不适用）
它与滚动API非常相似，但与它不同，search_after参数是无状态的，它始终针对最新版本的搜索器进行解析。因此，排序顺序可能会在步行期间发生变化，具体取决于索引的更新和删除

from+ size 分页，如果数据量不大或者from、size不大的情况下，效率还是蛮高的。但是在深度分页的情况下，这种使用方式效率是非常低的，并发一旦过大，还有可能直接拖垮整个ElasticSearch的集群。
scroll 分页通常不会用在客户端，因为每一个 scroll_id 都会占用大量的资源，一般是后台用于全量读取数据使用
search_after通过维护一个实时游标来避免scroll的缺点，它可以用于实时请求和高并发场景，一般用于客户端的分页查询
大体而言就是在这三种分页方式中，from + size不适合数据量很大的场景，scroll不适合实时场景，而search after在es5.x版本之后应运而生，较好的解决了这个问题。