Elasticsearch在项目中的使用

一.mysql和es的比较

1.mysql适合存储海量的数据，但是某些情况下的查询效率过低。

正常可以通过添加索引等加快查询速度，但是模糊查询的时候效率很低，会触发全局扫描

SELECT * FROM product WHERE title like '%优惠券%' 

2.基于 Lucene 引擎构建的开源分布式搜索分析引擎，可以提供针对 PB 数据的近实时查询，广泛用在全文检索、日志分析、监控分析等场景

主要使用了倒排索引来加快查询速度。

a.查询fury的文档，使用正排索引需要全局扫描，然后挨个比较查找是否有这个单词。

b.使用倒排索引，查询到fury需要2次，一次定位到两个id，再根据id确认具体数据

 3.es是分布式架构，

一个 ES 集群由多个 node 节点组成，每个 index 是以分片(Shard，index 子集)的数据存在于多个 node 节点上的。

这样的话当一个查询请求进来，分别在各个 node 查询相应的结果并整合后即可，将查询压力分散到多个节点，避免了单个节点 CPU，磁盘，内存等处理能力的不足。

另外当新节点加入后，会自动迁移部分分片至新节点，实现负载均衡，这个功能是 ES 自动完成的，是使用zookeeper实现

ZooKeeper 能够在 Elasticsearch 集群中实现以下功能：

1. 节点发现：它允许节点发现其他节点的存在，并与它们通信。

2. 节点管理：它允许管理员在不影响其他节点的情况下对节点进行管理。

3. 集群状态管理：它允许集群状态的变化被快速检测和响应。

二.项目中的实际应用

背景：需要对每天百万以上的数据进行利润的分类，前端需要按照分类进行分页查询。

分类的字段是一个字段，一个订单可能对应到多个分类，若优惠券，异常件，因此前端使用的是模糊匹配，在mysql中查询效率会很低。

而且数据一般可以查询到仅3个月内数据，按照每天百万来说，数据量也接近1亿。

2.1 使用from+size分页

from + size大于10000的时候，就会出现问题

2.2 深度分页

分布式数据库不同于单机数据库，数据是被分散保存在每个分片中的，无法保证要查询的这一百位学员的成绩一定都在某一个分片中，结果很有可能是存在于每个分片。换句话说，你从任意一个分片中取出的前10100位学员的成绩，都不一定是总成绩的前10100。更不幸的是，唯一的解决办法是从每个分片中取出当前分片的前10100名学员成绩，然后汇总成50500条数据再次排序，然后从排序后的这50500个成绩中查询前10100的成绩，此时才能保证一定是整个索引中的成绩的前10100名。

实际上需要进行两次排序，先从各自的分片中找出10100，然后在堆内存中进行二次排序，若是深度更大，容易造成oom的问题，因此设置max_result_window为10000。

2.3解决方案

2.3.1 避免深度分页，取消跳页，只能下一页点击

2.3.2 Scroll Search

scroll search 的方式，官方的建议并不是用于实时的请求，因为每一个 scroll_id 不仅会占用大量的资源（特别是排序的请求），而且是生成的历史快照，对于数据的变更不会反映到快照上。这种方式往往用于非实时处理大量数据的情况

2.3.3 Search After

search_after 分页的方式和 scroll 有一些显著的区别，首先它是根据上一页的最后一条数据来确定下一页的位置，同时在分页请求的过程中，如果有索引数据的增删改查，这些变更也会实时的反映到游标上。

 第二页的请求，使用第一页返回结果的最后一个数据的sort值，传给 search_after 字段来取下一页。注意，使用 search_after 的时候要将 from 置为 0 或 -1

search_after 适用于深度分页 + 排序，因为每一页的数据依赖于上一页最后一条数据，所以无法跳页请求。

且返回的始终是最新的数据，在分页过程中数据的位置可能会有变更。

引用

https://www.51cto.com/article/656071.html

https://blog.csdn.net/wlei0618/article/details/120800632

https://blog.csdn.net/huchao_lingo/article/details/115866307