浅谈Elasticsearch（ES搜索）_es全局搜索的优势

1 什么是ES

Elasticsearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，ES我主要感觉是由于ES的实时搜索能力比较强
还有就是ES小巧安装简便.底层也是基于lucence的全文搜索引擎,天然适用于分布式的项目

2 Es有自己的索引库,它的体系结构是

Elasticsearch 关系型数据库Mysql
索引(index)相当于 数据库(databases)
类型(type)相当于 表(table)
文档(document)相当于 行(row)

3 安装ES

安装Es时要配置一个 Ik分词器,因为es本身不支持中文
ik分词器分为
ik_smart 为最少切分
ik_max_word为最细粒度划分

4 在存储数据时，Es使用了倒排索引算法

这个算法的使用时这样的，举个例子
比如:
1 我是一个粉刷匠，
2 粉刷本领强
要按照设定好的分词方式来拆词在按照倒排索引的算法进行存储, 如果配置的是
ik_smart 粗粒度 ,那么拆分出来的结果
就是,比如 粉刷这个词 在 索引1 出现1次 {1:1} 在索引2 出现1次 {2:1}
这样拆词后,关键字搜索粉刷时,会立刻锁定要 有粉刷这个关键字的记录,并返回给前端
了,所以这个算法打打加快了搜索的速度

5 ES使用

步骤上来说的话，主要是添加es的依赖
然后就是创建dao层,实现接口 ElasticsearchRepository,类似SpringDataJPA 实现了基
本的增删改查和分页查询等功能

   public interface ArticleSearchDao extends     
		ElasticsearchRepository<Article,String> {
        /**
         * 检索
         */
         public Page<Article> findByTitleOrContentLike(String 
title, String content, Pageable pageable);
  }
1
2
3
4
5
6
7
8

6 相关的es注解

在实体类上添加@Document注解,里面配置indexName属性配置工程名,设置type来配
置es索引库的类型表是哪个
那么需要添加到 索引库中的字段需要在属性上添加@Field注解
注解中添加的属性包括
index =true ,配置是否能被搜索出来
analyzer: 是声明分词器;ik_smart(粗粒度)；ik_max_word(细粒度)，存的是用的分词器
是否存储，就是是否在页面上显示
searchAnalyzer 声明搜索关键字使用的分词器,查的时候用的分词器

@Document(indexName=“New_article”,type=“article”)
public class Article implements Serializable {

   @Id
   private String id;//ID
   @Field(index= true ,
analyzer="ik_max_word",searchAnalyzer="ik_max_word")
    private String title;//标题

    @Field(index= true,
analyzer="ik_max_word",searchAnalyzer="ik_max_word")
    private String content;//文章正文
    private String state;   //审核状态
}
1
2
3
4
5
6
7
8
9
10
11

那在service层主要还是调用dao接口 实现分页检索文章信息 和在redis缓存查询搜索历史关键字等功能吧

7 ES的特点

es本身的主要特点就是实时搜索能力强，但据我了解es是近实时搜索的,它默认每隔1秒进行数据的同步,也就是数据导入索引库,默认1秒秒才能搜索的，所以不能算是真正的实时搜索,每个1秒的同步其实对服务器的压力也很不小的，所有可以根据项目的实际情况,可以修改同步时间,比如改成10秒同步一次什么的,其实效果也很好

8 es和solr的不同

solr做分布式集群，还得安装插件,es集群天然自适应分布式场景,不需要插件什么的，而且内部已经隐藏了复杂的处理机制,es集群的特点主要是 采用分片机制实现了集群的复杂均衡,而且我们不用关心数据是按照什么机制分片的、最后放入到哪个分片中, es会自动进行均衡的分配达到负载均衡的;

9 ES遇到的问题

在es测试过程中发现logstash存储海量数据时,比如压力测试需要保存原始数据有几千万条, 发现过了几十万条之后，到了后面同步就特别慢，无法完成同步，发现原因是：
statement => “select * from t_wechat_message where id > :sql_last_value”
logstash配置文件中会配置同步时需要执行的sql，sql_last_value是内置变量，我这里面记录的是每次同步之后的id的值，id是自增的，但是在真正执行sql的时候，开启分页的模式下，logstash会在statement外面包上一层查询

SELECT * FROM (select * from tb_article where id > 20000000) AS t1 LIMIT 500 OFFSET 100000;
(offset x是跳过x个数据，limit y是选取y个数据)
如果当前批次需要同步的数据量特别大，就会导致offset特别大，offset特别大的时候，sql执行时间就特别长，导致无法完成同步

遇到这个测试结果后,我采取的以下的优化方法
分批进行，每批量只执行100000条，这样offset最大值也只有100000，速度会大大提高
statement => “select * from tb_article where id > :sql_last_value limit 100000”
或者
statement => “select * from tb_article where id > :sql_last_value and id < (:sql_last_value + 100000)”