嗯，好的，我对es的了解呢就是它是建立在apache Lucene(阿帕奇lucen)搜索引擎库基础上的搜索引擎，使用分布式存储(分片存储)，特点就是检索速度快。
-
一般数据量较大搜索频次高但是不频繁更新的数据，还有如果数据结构字段过多的数据检索功能，一般都会使用es搜索，我们系统首页的商品搜索，订单列表的搜索框，都是用的es检索
-
查询快的原因一个是es会对数据进行分词，分词以后再保存索引，查询的时候通过索引匹配，提高查询速度；
（我们一般对于数据字段过多的表，或者需要关联查询多表获取结果的表，都会只将有效的字段、处理好的结果字段存入es，而不是将所有字段存入es，这样也会影响es性能）
（es预热：将数据按照请求频率分为热数据、冷数据，热数据提前预热；或者单独建冷热数据索引，将热数据加载到内存里）
-
另一个原因是es使用了倒排索引，倒排索引会根据属性值来确定数据存储的位置，可以减少扫描的数据量
-
es采用了分片机制(每个分片上数据是相同的，将不同分片放置在不同的节点，任何一个节点当机，其他分片也能查询到数据备份；主分片可以读写，副本分片是只读的)
-
es的水平扩展性好，可以水平添加更多的服务器节点来提高性能
问题： es存在深分页问题
我们有一个数据几千万的用户数据表，进行分页查询的时候，每页10条，如果选择第2000页，性能会非常差，还有可能会导致内存泄漏
原因：es查询分页数据的时候，比如每页10条，一直往后翻页，翻到第2000页，在每个分片上会将前20000条数据查出来，不同的分片再做一些合并处理操作，最后得到第2000页的数据，如果查询的分页越深，每个分片上返回的数据就越多，对性能的压力和内存的损耗就越大，就会出现越翻越慢的情况，出现查询超时或者内存溢出的情况
解决：首先首页的订单列表不会出现深分页的情况，数据量较小不会出现这种情况；我知道我们系统唯一出现过类似问题的地方是首页推荐商品池，这个商品池数据取的是主站统一的推荐商品es接口，数据量上千万，主页采用左右滑动的形式，每页50条，滑动几十次后出现加载卡顿的情况，后来了解到可能是深分页的问题，该用了feed流来解决，feed流其实我们也是调用的中台的接口，大体的实现就是会有一个scroIId游标，原理是会将数据存一个快照，然后分页之后通过游标id去定位下一页的数据，就不会出现加载慢和内存损耗的情况；feed流的缺点就是需要前一页的scrolld来寻找下一页，所以不能随意跳页，只能一页一页往下翻