elasticsearch总结

一般需要安装elastic+ elastic-head
head提供前端页面展示数据使用。

​els是什么

lucence实现的分布式搜索引擎.

怎么做到的

基于lucence。

启动流程

1、elasticsearch: 本地自己测试，可以修改elasticsearch/bin 目录的 jvm.options中 -xms的参数256m。减少内存的损耗；
在els根目录bin目录下执行 elasticsearch.bat可执行文件。（闪退的话在小黑窗执行就可以看到错误）

2、elasticserach-head：在head根目录下，执行npm run start，即可启动head。

常见应用

分词搜索、日志采集处理（elk）、等。主要是大数据的处理。

基本概念

简单理解看上图。
目前es6.0之后，一个index只有一个types，但是后续types被取消。原因是 如果一个index中有多个type，type中如果有相同的fileds的话，这些相同的fileds是有冲突的。所以为了避免这种设计导致的用户容易犯的错误。后续index更像是一个表（即单库单表）

平时开发流程

1、数据同步方案

考虑数据的实时性要求
如果实时性很高要求的话，比如订单处理等关键业务，需要做到实时同步，在订单生成的时候采用api同步。（这里其实也可以直接通过mq去做，mq有消息重试的机制，保证一致性）

这里要考虑同步失败的情况，避免业务受到影响，需要在一次失败后就放弃，后续处理用mq来实现，失败就加入mq。

实时性要求不高的话，有两种方案：
1、使用中间件比如elasticsearch-jdbc处理。
好处：简单。不用在代码层面操作。
缺点：1、不能对数据做复杂处理，因为有时候我们直接的数据并不是一条语句能解决的，可能是多个表的关联查询。2、对于删除也满足不了。
所以适用的场景：数据不复杂，数据采用逻辑删除或者不删除。或者删除用api更新，其他的使用插件更新。

2、采用定时任务+ api更新的操作。记录修改的数据，定时任务去定时增删改。
该种方式以我们公司实际的应用举例：商品的分词搜索。

多sku商品的增删改。
商品删除的动作有多种情况；
1）、商品spu被删除了。
2）、商品的某个sku被删除了，但是spu没有删除，这会种情况是商品被修改了。

商品新增： 1）、商品spu增加了。
商品修改： 1）、就是商品sku被修改了。也可以导致sku被删除。

大概的步骤是这样：
1、采用数据库触发器记录更新和删除的skuid。对于新增使用redis维护一个id增量。

redis维护id增量的必要性考虑：可以根据修改时间和新增时间进行更新或者新增操作
（不好的地方：需要额外维护一个字段，因为要加索引，不然查找很慢，另外db的压力也不小）。

2、定时任务执行记录日志，对更新的skuid对应的spuid进行相应的操作。
3、执行完毕后删除日志记录。）
好处： 对代码没有耦合。商品zsg的操作不会有其他操作。
缺点： db压力不小。（可以通过相关的操作进行规避，比如商品修改之后设置一个修改的flag，但是这种场景太多了，代码耦合会比较大）
其他思路：
1、商品zsg的时候将对应的spuid传入到mq中，思路同上述的订单处理。
好处：不用维护zsg表。数据库压力也没那么大。
缺点： 耦合度方面比上一种方案高。
后续尝试下这种方案。应该是最终方案。

分布式部署方案

es的分布式原理：主从。
服务器部署步骤：
1、每台服务器都安装对应的es.
2、配置好配置文件，关键点是集群名称、发现ip地址的配置。其他的交给es去操作即可。
3、启动每台服务器的es服务，即可实现高可用。

需要了解节点、分片、索引的关系。
节点：一个节点就是一个es实例，一个节点可以包含多个分片（主分和复制分片可以同时存在）。
分片：一个索引（有很多数据）有多个分片（所以说数据是被es分配在不同的分片中），分片有复制分片（可修改）和主分片（定义后不可修改）。
主节点的作用：因为是主从，所以需要进行写数据，同步数据，还有节点发现等。
复制分片里的数据就是主分片数据的复制。

所以节点需要部署在不同服务器上，可以避免单机故障。

1、单服务器多节点。这个没啥好说的。
2、多服务器多节点。
多服务器之间如何做服务发现。在yml配置文件中配置参数

discovery.zen.ping.unicast.hosts: 【ip地址】

es即可自动进行管理这些服务节点。

几个问题：
1、是否分片越多越好。
当然不是，节点不够的话，分片越多，就会导致很多分片无法进行分配，es状态会变黄。
即需要分析节点数量（服务器）和 分片之间的关系。

2、为何es要设计一个索引多个分片，而不是像关系型数据库一样，就一个index，一个分片。
我的理解：分片相当于分表，把同一个类型的数据分散存储，再配合node节点，可以做容灾备份，提高查询效率。比如查询某一个东西，符合条件的在不同的节点（所以说一台服务器最好就部署一个节点）上，那么可以充分利用不同节点的资源，另外不同分片，相当于对数据做了拆分。也能提高效率。

其他

1、中文分词器 ik分词下载地址（可以查看其他版本） ：

elasticsearch-analysis-ik

验证查询语句是否正确：/test_ik/search_goods/_validate/query

2、搜索规则

请尽可能多的使用过滤式查询。

term 精确查询，这里的精确查找的意思是term的字段被包含在搜索出来的结果中，而不是和搜索出来的结果一样。精确的是输入的那个字段值

布尔过滤器
constant_score 查询包装器，复合查询包装其他复合或叶子查询

记住 term 查询只对倒排索引的词项精确匹配

语句的结构涉及到评分的计算，

boost 参数被用来提升一个语句的相对权重

match 匹配查询

如果单独地不加任何修饰词地使用 “query” 这个词，我们指的是 “scoring query” 。（评分查询），相对的，使用filter查询时不评分查询，速度很快且会被缓存。

如何选择查询与过滤
通常的规则是，使用查询（query）语句来进行 全文 搜索或者其它任何需要影响 相关性得分 的搜索。除此以外的情况都使用过滤（filters)。

muilt_match ^ 字符语法为单个字段提升权重， 采用最佳字段的策略

倒排索引

默认全文搜索的结果是 or

在{“enabled”:true}的情况下可以根据ID直接检索对应source JSON的字段，不用去倒排索引去按Field取数据

​