一、背景
前面已经对elasticsearch的核心概念进行比较详细的介绍,但是在实际生产中我们如何使用elasticsearch呢?
本篇文章我们先介绍一些elasticsearch常见的使用方法,然后通过一个实际的例子来加深对elasticsearch使用的理解。这个实际例子是网站上收集的用户点击菜单的行为日志数据存储在elasticsearch上,并可以通过工具可以通过一些图表来分析用户的行为。总体的目标:满足多个维度图表的查看,索引可以定期归档或者存储不用人工干预。
二、映射和模板
2.1 映射
映射为类似于数据库字段的定义,比如可以定义映射的字段名称、字段类型、倒排索引配置等。
通过rest api可以查看具体的索引映射关系
Request: GET /operate_log_test-000144
Response:
{
"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,写入时就不能新增字段,否则会报错。
PUT operate_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的search api分为两种,一种为url search,这种就是在url中使用查询参数。另一种为request body search,基于json的查询语句,俗称dsl语句。
3.1 Url search
和get请求类似,在url请求url中加查询条件,如示例:
GET /索引名称/_search?q=createdOrgName:总公司。
这里还可以加入更多的语法,如from,to分页,排序、正则表达式等多个规则。更多的功能和语法可以参看官方api文档。
3.2 DSL查询
3.2.1 match查询、Match Phrase Query
会对输入的查询进行分词,生成的每个词项进行底层查询,最终将结果汇总并且会算分。
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.2 Query String
{
"query":{
"query_string":{ //查询类型为quer_string
"fields":[
"operatorMenu"
],
"query":"行为记录 AND 修改"
}
}
}
3.2.3 Term查询
Term查询会对输入的查询条件不做分词,作为一个整体,当查询分词的字段时可能会查不到,因为分词的字段会拆分成多个子项。
3.2.4 constant_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.5 constant_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.8 Bool query
组合查询,可以多字段条件组合来查询,还可以嵌套使用。
-
Must, 必须匹配,贡献算法
-
Should,选择性匹配,是一个数组,贡献算分
-
must_not,必须不能匹配(filter context) 4)Fitler,必须匹配,不贡献算分
示例
{
"query":{
"bool":{
"filter":{
"term":{
"response":200
}
},
"must":{
"range":{
"timestamp":{
"lte":"2021-09-05T03:25:21.326Z"
}
}
}
}
}
}
3.2.9 Multi match query、Dis Max Query
主要用于同一个输入内容,elasticsearch中是多个字段的情况,Multi match query最终算分如何加权可以通过参数来控制,Dis Max Query查询是会选择一个评分最好的而字段作为最终排序字段。
{
"query":{
"multi_match":{
"query":"shanghai",
"type":"most_fields",
"fields":[
"city^10",
"street.std"
]
}
}
}
四、Kibana图表
我们可以在kibana建立丰富的分析报表,具体的步骤如下:
4.1 可视化组件
kibana首页-》visualize菜单-》选择索引模式-》选择可视化图表类型-》填写规则-》保存
如图上所示:
-
可以选择聚合指标,可以选择计数,还有求和、平均数、去重求和等指标
-
选择拆分条件,就是我们理解的sql中的group语句
-
可以添加子拆分条件,每个条件都可以自定义排序规则和数量和一些其它的信息
-
保存并命名完成可视化组件添加
4.2 可视化组件
kibana首页-》dashboard菜单-》选择上一步骤创建的可视化组件即可创建一个图表面板,综合了各种小组件。
从上面的图表中非常的直观可以查看:
-
每日日志总量、最高访问菜单量
-
用户访问行为类型、菜单、员工名称分布
-
一周访问量的趋势图
-
访问量ip去重后的热力图
Kibna有丰富的可视化组件,可以自行的组合使用。
五、索引生命周期管理
当日志越来越大的时候,如何使得老日志自动删除,或者移动到成本比较低的磁盘上呢,这些操作如何尽可能的自动化管理,减少人工操作呢。
Elasticsearc将索引的生命周期划分为4个阶段
-
hot,拥有大量的读写操作
-
Warm, 不存在写操作,有读操作
-
Cold,不存在写,极少的读操作
-
Delete, 完全不需要,可以删除
基于上述的的需求,elascitcsearch6.6推出了index lifecycle management管理工具,索引绑定了这个生命周期策略后,可以自动的转移或者删除。可以基于kibana的生命周期管理模块进行设置,也可用通过elasticsearch的rest api进行设置。
5.1 Rest api设置
5.1.1 设置刷新时间(生产环境设置为10分钟,刷新一次)
PUT _cluster/settings
{
"persistent":{
"indices.lifecycle.poll_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 创建索引,使其别名设置为可写入
PUT operate_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.2 kibana页面
可以通过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配置管理源码解析 | 即将上线 | |
Nacos2.0版本优化功能解析 | 即将上线 | |
Netty | 计算机网络&nio核心原理 | 即将上线 |
详细解读kafka是如何基于原生nio封装网络通信组件的? | 即将上线 | |
netty初识之核心组件介绍 | 即将上线 | |
源码解析netty服务端,端口是如何拉起来的?新连接接入又如何处理? | 即将上线 | |
深入netty中各种事件如何在pipeline中传播的? | 即将上线 | |
网络编程中拆包粘包是什么?kafka以及netty是如何解决的? | 即将上线 | |
深入解读netty中最为复杂的缓存分配是如何进行的? | 即将上线 | |
源码分析netty、kafka、sentinel中不同时间轮实现方式以及细节 | 即将上线 | |
尝试从上帝角度对比kafka&netty中的性能优化,各种设计模式的丰富运用 | 即将上线 | |
Netty在Rocketmq中的实践,RocketMq的消息协议解读 | 即将上线 | |
关注IT巅峰技术,私信作者,获取以下2021全球架构师峰会PDF资料。