前言
本篇是ES系列的第二篇，继上次的理论篇ElasticSearch理论体系构建后，带来了实战篇。实战篇来自于我对常见操作以及场景的分析总结，详细到每个步骤和理由，下一篇将是性能优化篇。
常用操作
以下操作均使用ES的API进行展示，为什么这么做呢，而不是选用某一个程序代码来进行演示？原因是我认为，ES的核心在于API，无论是Java、python等包装的操作客户端，哪怕语法用得再厉害，无非就是对原生Restful API的封装罢了。再说了大部分客户端都支持直接丢个Json进去，你掌握了API的写法，其实用什么语言都能很快上手。
索引操作
创建索引–最基础的操作，一般建议是直接如下案例，一次性建好配置和映射还有别名，避免多次IO
PUT /索引名称 { "settings": { "属性名": "属性值" } }
PUT /flink-test1
{
"settings": {
"number_of_shards": 6,
"number_of_replicas": 1,
"refresh_interval": "5s",
"translog.durability": "async",
"translog.sync_interval": "30s",
"index.highlight.max_analyzed_offset": 2000000
},
"aliases": {
"flink-test": {}
},
"mappings": {
"properties": {
"userId": {
"type": "keyword"
},
"userName": {
"type": "text",
"analyzer": "ik_max_word",
"search_analyzer": "ik_smart"
},
"requestUrl": {
"type": "text",
"analyzer": "ik_max_word",
"search_analyzer": "ik_smart"
},
"requestType": {
"type": "keyword"
},
"logType": {
"type": "keyword"
},
"requestMethod": {
"type": "text",
"analyzer": "ik_max_word",
"search_analyzer": "ik_smart"
},
"env": {
"type": "keyword"
},
"localIp": {
"type": "keyword",
"index": false,
"doc_values": false
},
"requestIp": {
"type": "keyword",
"index": false,
"doc_values": false
},
"triceId": {
"type": "keyword"
},
"createTime": {
"type": "date",
"format": "yyyy-MM-dd HH:mm:ss.SSS"
},
"system": {
"type": "keyword"
},
"threadName": {
"type": "keyword"
},
"msg": {
"type": "text",
"analyzer": "ik_max_word",
"search_analyzer": "ik_smart"
}
}
}
}
判断索引是否存在–HEAD /索引名称
查看索引–GET** /索引名称
批量查看索引–GET **/索引名称1,索引名称2,索引名称3,…
查看所有索引–GET _all
概要信息– GET /_cat/indices?v
查询主节点–GET /_cat/master
打开索引–POST /索引名称/_open
关闭索引–POST /索引名称/_close
删除索引–DELETE /索引名称1,索引名称2,索引名称3…
创建映射字段
PUT /索引库名/_mapping
{
"properties": {
"字段名": {
"type": "类型",
"index": true，
"store": true，
"analyzer": "分词器"
}
}
}
查看映射关系–GET** **/索引名称/_mapping
一次性创建索引和映射
PUT /索引库名称
{
"settings":{
"索引库属性名":"索引库属性值"
},
"mappings":{
"properties":{
"字段名":{
"映射属性名":"映射属性值"
}
}
}
}
查看索引配置–GET** **/索引名称/_settings
修改索引配置
PUT /log-zero-uat-202211/_settings
{
"index" : {
"highlight.max_analyzed_offset" : 500000
}
}
文档操作
新增文档–第一种指定ID，不推荐，建议使用第二种不指定ID，由ES自动生成
POST /索引名称/_doc/{id}
POST /test111/_doc
{
"name" : "百度",
"job" : "小度用户运营经理",
"payment" : "30000"
}
查看单个文档–GET** **/索引名称/_doc/{id}
查看所有文档
POST /索引名称/_search
{
"query":{
"match_all": {}
}
}
查询指定列–GET /索引名称/_doc/1?_source=name,job
更新文档
全部更新，是直接把之前的老数据，标记为删除状态，然后，再添加一条更新的（使用PUT或者POST）局域更新，只是修改某个字段（使用POST）
全部更新
把刚才新增的请求方式改为PUT，就是修改了，不过修改必须指定id，如果id对应文档存在，则修改；如果id对应文档不存在，则新增
局部更新
POST /索引名/_update/{id}
{
"doc":{
"field":"value"
}
}
删除文档
根据id进行删除：
DELETE /索引名/_doc/{id}
删除所有文档
POST /my-index-000001/_delete_by_query
{
"query": {
"match": {
"user.id": "elkbee"
}
}
}
查询日期大于XXX的字段
GET /log-zero-pro-202203-alias1/_search
{
"query": {
"bool": {
"filter": [
{ "range": { "createTime": { "gte": "2022-03-31 08:00:00.000" }}}
]
}
}
}
方案操作文档
常规操作还有很多，后面慢慢补充吧，没有放很多复杂的东西进去，毕竟大家的业务都不一样，照着官网案例写就行了，我觉得8.X的文档写的比7.X的垃圾多了，不知道是不是我的错觉，少了很多案例。下面带来一些经典的ES实操案例，让大家快速了解ES。
ES集群添加插件（分词器）或修改配置-需要滚动重启
- 禁止分片自动分布。这个很好理解，避免新节点进来，分片数据重分配，不会影响数据的正确性，同时不用重分配也加速了咱们切换的时间。
PUT /_cluster/settings
{
"transient" : {
"cluster.routing.allocation.enable" : "none"
}
}
-
执行同步刷新。在关闭节点前，把内存中的数据刷入磁盘，避免丢失数据。
:::info
curl -X POST “localhost:9200/_flush/synced”
/_flush/synced API的主要的作用和场景有: -
强制执行挂起的索引刷新,使文档可搜索。默认情况下,Elasticsearch会定期自动刷新,但调用/_flush/synced可以手动刷新。
-
在做故障转移之前,调用该API可以确保主分片已经完成所有的索引操作。否则故障转移可能会失去数据。
-
与_flush不同,_synced会进行额外的处理,确保主分片和副本分片都完成了刷新。
::: -
关闭单个节点，添加分词器或者修改配置之类的，重启节点
-
观察该节点是否加入集群，检查下是否正常启动，都OK，就开启分片自动分片，等待集群状态恢复正常
PUT /_cluster/settings
{
"transient" : {
"cluster.routing.allocation.enable" : "all"
}
}
- 对剩余节点进行以上1-4重复操作，即可完成滚动重启
ES集群重建索引-无需重启
ElasticSearch不停机重建索引引申来的优化与思考-阅读5137点赞28收藏43，直接看我写的这篇文章吧，详细多了，就不赘述了。
Elasticsearch时区问题
Elasticsearch 滞后8个小时等时区问题，一网打尽！
推荐上面那篇文章，大佬写得很好，总结一下就是，ES默认时区UTC+0改不了，只能适应它，但是Kibana和查询API可以换时区曲线救国。当然我们不能指望查询时去改数据，最好做到输入到ES里的数据就是我们想要的时区。
“createTime”:{“type”:“date”,“format”:“yyyy-MM-dd HH:mm:ss.SSS”}，我的映射结构是这种的，我在输入数据的时候，考虑两种做法。第一种是如Filebeat+Kafka+数据处理服务+Elasticsearch+Kibana+Skywalking日志收集系统，文中的处理，在输入端，将日期时间主动修改为和ES默认一致的时区，这样转换后的数据依旧是我们想要的时间。
第二种是向ES发送请求时，比如是Java客户端，在JSON转换时加上时区@JsonFormat(pattern=“yyyy-MM-dd HH:mm:ss.SSS”,timezone=“GMT+8”)，注意我这里用的是Jackson序列化工具，所以注解用的JsonFormat，如果Spring全局替换为Fastjson就改下注解就行。
ES字段调整的另一个办法
不必Reindex，利用runtime_fields优雅地解决字段类型错误问题
这是ES社区写的一篇文章，里面提到了这个运行时字段，是ES较高版本给出的一个解决措施。里面只提到了它的优点，就是灵活性强且不占用存储空间，因为他是在查询期间动态运算的，所以运行时字段并不在实际的文档中存储。也就是说，你加了这个运行时字段，其实索引大小是不会变的，但是查询的时候，可以用这个字段查出数据，特定情况也算是提高了性能，如果是频繁修改索引的业务场景，那么使用运行时字段，就不会引发索引的频繁构建。
但是文章里没说缺点，这就很坑人了，所以我来说说。运行时处理，由这个关键词很容易想到，这是一种时间换空间的手法，必然会拉长查询速度，同时耗费多余的计算资源。总之使用的时候见仁见智吧，和前面的滚动停机以及不停机的两种方案各有优劣。
问题解决
高亮文本解析字符数超过默认值报错
The length of [msg] field of [WKO61oEB7lnawBKq29Pl] doc of [log-zero-uat-202207-alias1] index has exceeded [1000000] - maximum allowed to be analyzed for highlighting. This maximum can be set by changing the [index.highlight.max_analyzed_offset] index level setting. For large texts, indexing with offsets or term vectors is recommended!
该问题常见于Kibana查询时报错，因为我们带条件查询的时候，kibanna默认使用高亮查询，而ES为了加快响应速度将默认解析字符数设置为10w，我们在操作的时候可以将索引的相关设置调整为100w
PUT /索引名称/_settings
{ "index": { "highlight.max_analyzed_offset": 10000000 } }
text类型默认不支持聚合和排序
报错内容：
:::info
Text fields are not optimised for operations that require per-document field data like aggregations and sorting, so these operations are disabled by default. Please use a keyword field instead. Alternatively, set fielddata=true on [userId] in order to load field data by uninverting the inverted index. Note that this can use significant memory（文本字段未针对需要每个文档字段数据的操作（如聚合和排序）进行优化，因此默认情况下禁用这些操作。请改用关键字字段。或者，在 [userId] 上设置 fielddata=true，以便通过反转倒排索引来加载字段数据。请注意，这可能会占用大量内存）
:::
解决方案：
text类型默认不支持聚合和排序，因此要么修改mapping增加属性fielddata=true，或者直接修改字段类型为keyword
4万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
