博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
elasticsearch 创建index 原则
阅读量:4184 次
发布时间:2019-05-26

本文共 2134 字,大约阅读时间需要 7 分钟。

        相信有不少读者用elasticsearch的时候第一个难题就是如何创建好一个index。下面给出具体的样例和原则,帮助大家创建一个相对适合自己业务场景的index,有助于开展后续的开发工作。

        先上创建index的模板:

curl -XPUT 'http://127.0.0.1:9200/my_index_name_v1?pretty' -d '{  "aliases": {    "my_index_name": {}   },  "settings": {    "index": {      "refresh_interval": "10s",      "number_of_shards" : "12",      "number_of_replicas" : "1",      "search.slowlog.threshold.query.warn": "5s",      "search.slowlog.threshold.query.info": "1s",      "search.slowlog.threshold.fetch.warn": "1s",      "search.slowlog.threshold.fetch.info": "800ms",      "indexing.slowlog.threshold.index.warn": "12s",      "indexing.slowlog.threshold.index.info": "5s"    }  },  "mappings": {    "my_type_name": {      "properties": {        "xxx_id": {          "type": "keyword"        },        "timestamp" : {          "type": "long"        },        "@timestamp" : {          "type": "date"        },        "xxx_status": {          "type": "integer"        },        "xxx_content": {          "type": "text"        }      }    }  }}'

        现在讲该模板进行分类讲解:

URI部分

  1. http方法:首先要注意是put方法,es的http接口严格遵从restful风格,创建属于put。大家在用某些工具注意选择正确的方法,比如cerebro插件的默认方法是post,方法使用不当,除了命令执行失败以外还有可能会污染mapping结构。
  2. index名字:若业务类型只需要建立一个固定的index进行业务访问,强烈推荐让你的index名字加后缀_v1,方便后续因为主分片数调整或者调整某字段类型等原因需要reindex。若不加后缀,且没有指定好index的别名,最终的结果是reindex需要业务线停止写入,且需要改代码将访问index名字改为index的别名,这时可能会取名为xxx_v1,导致额外的工作。总之,建议index名字为your_indexname_v1,而别名为index_name。
  3. pretty标记,建议加入,但不强制。

设置部分

  1. refresh_interval:该设置主要是每隔多久刷新数据,可以让刚刚写入的数据被查到。若写入数据量较大或者业务对于变更后及时查到的要求不高,则可以设置时间大一些。推荐一些粗糙的准则,若一天的写入能超过100g的数据量,则建议至少设置为10s,500g设置为60s,1T以上设置为120s。具体的以当时集群硬件配置和所有index读取写入的情况而定。
  2. number_of_shards和number_of_replicas:主分片数和副本分片数,推荐直接设置为12,副本分片数设置为1。具体可以参考文章:
  3. 慢日志设置:建议读取写入根据业务访问情况进行设置,唯一需要注意的是不要设置过小,则可能会将磁盘打满,甚至影响数据存储。强烈推荐必须设置,方便后续观察业务使用情况。

mapping部分

  1. type名字:一般来讲,推荐一个index对应一个type,若有多个type,则所有的type的字段大部分应该是相同的。若全部不同,推荐将type设置为index的名字,分成多个index,防止由于文档字段稀疏导致浪费存储。
  2. 字段名称包含id,推荐用keyword类型,若业务能确认一定是字符串类型,则可以用long型
  3. 时间戳类型,推荐为long型,方便业务访问,或者date类型,方便kibana和grafana访问。
  4. status或者type字段,推荐用integer类型,便于枚举
  5. content字段,推荐确认对应的分词器,设置为text类型,不推荐用keyword。特别是字段很长的情况。
  6. 聚合类字段推荐设置成keyword,即使是数字类型也需要这样设置,强制将字段的数据组织成倒排索引而非kd-tree提升聚合查询速度。

转载地址:http://aauoi.baihongyu.com/

你可能感兴趣的文章
kafka 消息服务
查看>>
从零开始玩转JMX(一)——简介和Standard MBean
查看>>
究竟啥才是互联网架构中的高并发!
查看>>
数据库水平扩展与垂直扩展
查看>>
异地多活问题
查看>>
Http_load测试说明
查看>>
nginx优化——包括https、keepalive等
查看>>
记一次压力测试和对nginx/tomcat配置的调整
查看>>
第二章 HttpClient 连接管理
查看>>
tcpdump抓包分析TCP三次握手过程
查看>>
tcpdump过滤某个端口
查看>>
TCP协议中FLAG的含义
查看>>
详解 Tomcat 的连接数与线程池
查看>>
tomcat中server.xml配置详解
查看>>
tomcat架构分析(概览)
查看>>
构分析(connector BIO 实现)
查看>>
Java并发之AQS详解
查看>>
Thread类的使用
查看>>
java如何处理中断
查看>>
Java8内存模型—永久代(PermGen)和元空间(Metaspace)
查看>>