Elasticsearch(三)：实战

一、背景

前面已经对elasticsearch的核心概念进行比较详细的介绍，但是在实际生产中我们如何使用elasticsearch呢？

2.1映射

映射为类似于数据库字段的定义，比如可以定义映射的字段名称、字段类型、倒排索引配置等。

通过restapi可以查看具体的索引映射关系

Request:GET/operate_log_test-000144Response:

{"operate_log_test-000144":{"aliases":{"alias_operate_log_test_index":{"is_write_index":false}},"mappings":{"properties":{"createdOrg":{"type":"keyword"},"content":{"type":"text"},"updatedTime":{"type":"date"}}},"settings":{"number_of_shards":"1","creation_date":"1629881813094","number_of_replicas":"0","uuid":"eMsw1FJWTBKbj8-_vPpVbg","version":{"created":"7040099"}}}}

2.1.1自动识别

在写入文档的时候，索引不存在会自动创建索引，elasticsearch会自动根据文档（json）推算出自动类型。

字符串，日期格式字符串会设置成date，数字会设置成float/long，其它的字符串会设置成text，并增加一个子字段keyword；

布尔值，会推算成boolean

浮点数，float

整数，long

对象，object

注意：在实际生产使用中，不要使用自动识别类型，容易出错。需要显示设置字段类型。而且索引映射类型一旦确定了就无法修改了。可能对查询产生影响，字段自定义设置还可以根据使用场景合理设置类型，比如去掉不必要的分词，从而优化elasticsearch的空间。

2.1.2显示设置

dynamic显示设置有三个选项：

True，如果文档有新字段，自动识别并写入

False，新增的字段会被丢弃

Strict,新增字段拒绝写入

如下的设置，将dynamic设置为strict，写入时就不能新增字段，否则会报错。

PUToperate_log_dev-000085_mapping

{"dynamic":"strict"}

2.2模版

我们在使用的elasticsearch索引的时候，一个索引的容量不易太大，比如日志可以按照时间来创建索引。所有的所有的设置和映射应该一致，我们可以使用索引模板。它的作用就是帮你设置mapping和setttings，自动匹配到新创建的所有上。

PUT/_template/trace_segment_record_template

{"index_patterns":["trace_segment_record_*"],"order":1,"settings":{"number_of_shards":1,"number_of_replicas":0},"mappings":{"traceId":{"type":"keyword"},"latency":{"type":"long"}}}

elasticsearch的searchapi分为两种，一种为urlsearch，这种就是在url中使用查询参数。另一种为requestbodysearch，基于json的查询语句，俗称dsl语句。

3.1Urlsearch

和get请求类似，在url请求url中加查询条件，如示例：

GET/索引名称/_search?q=createdOrgName:总公司。

这里还可以加入更多的语法，如from,to分页，排序、正则表达式等多个规则。更多的功能和语法可以参看官方api文档。

3.2DSL查询

3.2.1match查询、MatchPhraseQuery

会对输入的查询进行分词，生成的每个词项进行底层查询，最终将结果汇总并且会算分。

GET/operate_log_test-000144/_search

{"_source":["operatorAfter","menu*"],"from":0,//分页起始页数"size":10,//分页的大小"sort":[{//排序"createdTime":{"order":"desc"}}],"query":{//查询"match":{"menuName":{//字段名称"query":"报表分析",//字段值"operator":"and"//关系}}}}

3.2.2QueryString

{"query":{"query_string":{//查询类型为quer_string"fields":["operatorMenu"],"query":"行为记录AND修改"}}}

3.2.3Term查询

Term查询会对输入的查询条件不做分词，作为一个整体，当查询分词的字段时可能会查不到，因为分词的字段会拆分成多个子项。

3.2.4constant_score查询

可以将query查询转化为filter，不会进行tf-idf算法，会使用缓存，提升性能

Request:

{"from":0,"size":10,"sort":[{"createdTime":{"order":"desc"}}],"query":{"constant_score":{"filter":{"term":{"operatorTypeName":"行为记录"}}}}}}

Response:

{"hits":{"total":{"value":690,"relation":"eq"},"max_score":1.0,//相关度算法都为1"hits":[{"_index":"operate_log_test-000148","_type":"_doc","_id":"5u2TlHsBurvRCs23vPxS","_score":1.0,//相关度算法都为1"_routing":"operatorEmp","_source":{"createdOrg":"999999","createdOrgName":"总公司","createdTime":1630285315140,"esAddTime":1630285315150}}]}}

3.2.5constant_score的数字范围、日期范围

"constant_score":{"filter":{"range":{"price":{"gte":20,"lte":30}}}}"constant_score":{"filter":{"range":{"date":{"gte":"now-1y"}}}}

3.2.6聚合查询

统计各个菜单不同员工的访问量

GET/alias_operate_log_test_index/_search

{"size":0,"aggs":{"menu_count":{"terms":{"field":"operatorMenu"},"aggs":{"emp_count":{"terms":{"field":"operatorEmpName"}}}}}}{"aggregations":{"menu_count":{"doc_count_error_upper_bound":138,"sum_other_doc_count":11157,"buckets":[{"key":"运单查询","doc_count":1137,"emp_count":{"doc_count_error_upper_bound":0,"sum_other_doc_count":52,"buckets":[{"key":"刘龙会","doc_count":748},{"key":"王浩杰","doc_count":67},{"key":"段惠艳","doc_count":58}]}},{"key":"数据导入","doc_count":418,"emp_count":{"doc_count_error_upper_bound":0,"sum_other_doc_count":0,"buckets":[{"key":"罗为为","doc_count":219},{"key":"马超","doc_count":97}]}}]}}}

3.2.7排序

排序和指标分组需要用到正排索引，这种索引有两种实现：

Fileddata（内存），只针对text类型，默认关闭，不建议使用。

Docvalues（磁盘），针对keywords，默认启用，如果想节省空间和提升写入速度可以关闭，重新打开需要重建索引。需要明确不用排序和聚合分析。

{"properties":{"user_name":{"type":"keyword","doc_values":false}}}

3.2.8Boolquery

组合查询，可以多字段条件组合来查询，还可以嵌套使用。

Must，必须匹配，贡献算法

Should，选择性匹配，是一个数组，贡献算分

must_not，必须不能匹配（filtercontext）4)Fitler，必须匹配，不贡献算分

示例

{"query":{"bool":{"filter":{"term":{"response":200}},"must":{"range":{"timestamp":{"lte":"2021-09-05T03:25:21.326Z"}}}}}}

3.2.9Multimatchquery、DisMaxQuery

主要用于同一个输入内容，elasticsearch中是多个字段的情况，Multimatchquery最终算分如何加权可以通过参数来控制，DisMaxQuery查询是会选择一个评分最好的而字段作为最终排序字段。

{"query":{"multi_match":{"query":"shanghai","type":"most_fields","fields":["city^10",""]}}}

我们可以在kibana建立丰富的分析报表，具体的步骤如下：

如图上所示：

可以选择聚合指标，可以选择计数，还有求和、平均数、去重求和等指标

选择拆分条件，就是我们理解的sql中的group语句

可以添加子拆分条件，每个条件都可以自定义排序规则和数量和一些其它的信息

保存并命名完成可视化组件添加

从上面的图表中非常的直观可以查看：

每日日志总量、最高访问菜单量

用户访问行为类型、菜单、员工名称分布

一周访问量的趋势图

访问量ip去重后的热力图

Kibna有丰富的可视化组件，可以自行的组合使用。

当日志越来越大的时候，如何使得老日志自动删除，或者移动到成本比较低的磁盘上呢，这些操作如何尽可能的自动化管理，减少人工操作呢。

Elasticsearc将索引的生命周期划分为4个阶段

hot，拥有大量的读写操作

Warm,不存在写操作，有读操作

Cold，不存在写，极少的读操作

Delete,完全不需要，可以删除

基于上述的的需求，推出了indexlifecyclemanagement管理工具，索引绑定了这个生命周期策略后，可以自动的转移或者删除。可以基于kibana的生命周期管理模块进行设置，也可用通过elasticsearch的restapi进行设置。

5.1Restapi设置

5.1.1设置刷新时间（生产环境设置为10分钟，刷新一次）

PUT_cluster/settings

{"persistent":{"_interval":"600s"}}

5.1.2设置一个索引管理策略

PUT/_ilm/policy/portal_operatelog_policy

{"policy":{"phases":{"hot":{"actions":{"rollover":{//当索引的文档增长到100万的时候触发进入删除阶段"max_docs":1000000}}},"delete":{"min_age":"20s",//删除阶段等待20s后，删除"actions":{"delete":{}}}}}}

5.1.3索引策略绑定索引模板

PUT/_template/operate_log_test_index_template

{"index_patterns":["operate_log_test-*"//索引模板匹配的索引格式],"settings":{"index":{"lifecycle":{//上一步创建的管理策略"name":"portal_operatelog_policy",//设置别名"rollover_alias":"alias_operate_log_test_index"},"number_of_shards":"1","number_of_replicas":"0"}},"mappings":{"省略"},"aliases":{"省略"}}

5.1.4创建索引，使其别名设置为可写入

PUToperate_log_test-000001

{"aliases":{"alias_operate_log_test_index":{"is_write_index":true}}}

踩坑：这里的索引名称一定要是operate_log_test-000001这种数字结尾类型的，否则发生滚动的时候会报错。

设置完成后，当operate_log_test-000001达到了100万个文档后，自动会滚动生成operate_log_test-000002这个文档，新数据会往operate_log_test-000002这个文档写入。当这个operate_log_test-000001索引满足了删除条件后，会自动删除。

5.2kibana页面

可以通过kibana提供的可视化界面管理，实际上还是调用上面的api。具体如何操作，这里就不一一赘述了。

通过本文，我们可以了解到如何创建一个索引和映射，知道自动类型转换可能存在问题，比如存在多余的冗余字段，类型也不可后期改动，所以需要显示有针对性的设置字段类型。

对于日志类型的多个索引，我们可以通过索引模板来进行自动管理，它可以自动识别索引名称，按照模板创建对应的settings和mappings。

通过生命周期策略管理工具来让索引自动的删除、归档，大大的减少了人工成本。通过一些聚合查询我们可以在kibana上使用多种类型的图表来多个维度展示存储的数据，进而使我们的业务数据更直观。

文章导航

类别

标题

发布

Redis

Redis(一)：单线程为何还能这么快？

己发布

Redis(二)：内存模型及回收算法

己发布

Redis(三)：持久化

己发布

Redis(四)：主从同步

即将上线

Redis(五)：集群搭建

即将上线

Redis(六)：实战应用

即将上线

Elasticsearch

Elasticsearch(一)：概述

己发布

Elasticsearch(二)：核心

己发布

Elasticsearch：实战

本文章

Elasticsearch写入流程详解

即将上线

Elasticsearch查询流程详解

即将上线

Elasticsearch集群一致性

即将上线

Lucene的基本概念

即将上线

Elasticsearch部署架构和容量规划

即将上线

RocketMQ

RocketMQ—NameServer总结及核心源码剖析

2021.11.01

RocketMQ—深入剖析Producer

即将上线

Broker—启动流程源码解密

即将上线

Broker—接受消息处理流程解密

即将上线

Tomcat源码分析

Tomcat(一)：项目结构及架构分析

即将上线

Tomcat(二)：启动关闭流程分析

即将上线

Tomcat(三)：应用加载原理分析

即将上线

Tomcat(四)：网络请求原理分析

即将上线

Tomcat(五)：嵌入式及性能调优

即将上线

Nacos

Nacos项目结构及架构分析

即将上线

Nacos服务注册源码解析

即将上线

Nacos配置管理源码解析

即将上线

版本优化功能解析

即将上线

Netty

计算机网络＆nio核心原理

即将上线

详细解读kafka是如何基于原生nio封装网络通信组件的？

即将上线

netty初识之核心组件介绍

即将上线

源码解析netty服务端，端口是如何拉起来的？新连接接入又如何处理？

即将上线

深入netty中各种事件如何在pipeline中传播的？

即将上线

网络编程中拆包粘包是什么？kafka以及netty是如何解决的？

即将上线

深入解读netty中最为复杂的缓存分配是如何进行的？

即将上线

源码分析netty、kafka、sentinel中不同时间轮实现方式以及细节

即将上线

尝试从上帝角度对比kafka＆netty中的性能优化，各种设计模式的丰富运用

即将上线