一.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 集群中实现以下功能：
-
节点发现：它允许节点发现其他节点的存在，并与它们通信。
-
节点管理：它允许管理员在不影响其他节点的情况下对节点进行管理。
-
集群状态管理：它允许集群状态的变化被快速检测和响应。
二.项目中的实际应用
背景：需要对每天百万以上的数据进行利润的分类，前端需要按照分类进行分页查询。
分类的字段是一个字段，一个订单可能对应到多个分类，若优惠券，异常件，因此前端使用的是模糊匹配，在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
2.3.3 Search After
引用
https://www.51cto.com/article/656071.html
https://blog.csdn.net/wlei0618/article/details/120800632
标签：项目,使用,10100,查询,索引,Elasticsearch,分片,2.3,节点 From： https://www.cnblogs.com/developS/p/17629921.html