ElasticSearch 模板文件配置

时间 2019-11-17

原文原文链接

首先是推荐一下参考资料

中文资料：http://kibana.logstash.es/content/elasticsearch/index.html
官方文档：https://www.elastic.co/guide/index.html
中文资料：http://es.xiaoleilu.com/

2016年3月3日：更新非文件方式模板配置和模板order覆盖问题javascript

后面若是再写ElasticSearch(后面简称 ES)文章，从新整理一下参考文档汇总一下。html

为何采用索引模板文件

ES的http接口很是好用，索引配置实际上是能够经过接口完成的。可是
你确定不但愿每次从新部署ES都从新到本身的笔记上复制粘贴配置文件，采用索引模板文件来配置ES索引，模板就和其余服务器好比：Nginx apache的conf文件，能够方便经过相似rsync等工具分发，固然将索引配置保存于数据库中也是能够的，但这里主要是说明文件的方式，比较符合运维习惯。java

在什么地方放置模板配置文件？

config路径下面的templates目录，正常可能长成这样：/usr/local/elasticsearch-1.7.1/config/templates/node

配置内容说明

{
    "order": 10,
    "myaccess": { //模板名称，用于更新和识别这个模板
        "mappings": { //mappings下面是模板的具体配置了
            "system": { //这里坑比较多，system只不过是一个命名空间而已，你也能够取别的名字，好比官方喜欢用tweet
                "properties": {//这里面就能够放具体每一个索引的配置了
                    "@timestamp": {//这是专门给kibana用的一个字段，时间索引
                        "doc_values": true,//未知
                        "format": "dateOptionalTime",//数据格式，也能够是Y-m-d H:i:s等等，具体能够看中文文档
                        "index": "not_analyzed",//常见的分析模式，analyzed 和 not_analyzed 通常来讲，not_analyzed会致使没法进行分词查询，默认不写这个属性的话，就是analyzed（可分词和模糊查询）
                        "type": "date"//日期类型，其余常见类型包括float integer string等，具体见文档说明
                    },
                    "status": {
                        "index": "analyzed",
                        "type": "short"
                    },
                    "ua": {
                        "type": "string"
                    },
                    "uri": {//uri 嵌套了2级
                        "fields": {//第二级索引的访问方式很简单，就是uri.raw（raw是本身取的名字）,这样你能够方便的对同一个字段作多种分析索引，以应对不一样的查询方式
                            "raw": {
                                "index": "not_analyzed",
                                "type": "string"
                            }
                        },
                        "index": "analyzed",
                        "type": "string"
                    }
                }
            }
        },
   "settings": {
            "index.number_of_replicas": 0, //副本的个数，也就是同一份数据有额外多少个拷贝，默认1，若是你本地起一个节点测试，最好改成0，由于这边若是不是0，集群会一直提示说少一个节点来放副本，这个值能够动态修改
            "index.number_of_shards": 5//索引分片数量，具体做用还没有阅读文档，下面有一些经过文档介绍的理解
        },
        "template": "myaccess*"//什么样的索引能够采用当前的模板，这是一个通配符（wildcard 这单词会常常出如今ES中），若是咱们按月分索引好比 myaccess-2015.08这种索引，就会使用这个模板。
    }
}

比较常见的问题是，我新建模板要不要重启 ES？或者作一个什么reload config的操做？
当模板新建完成是不须要重启ES的，有新索引被建立，这个模板文件会被应用到这新索引当中，一旦索引创建完毕，模板和索引就没有什么太大关系了。修改模板只会致使下一个被建立的索引的改动。若是要让索引使用新的模板，须要经过API来配置。python

参数index.num_of_shards

当执行一个查询时，查询用的节点服务器须要查询的数据总量是：nginx

number_of_shards * (from + size)git

就是说，若是分片为5，要查第10页，每页30条数据，须要查询的数据就是：
5 * （270 + 30） = 1500 条
每一个分片都须要查300条数据，并取最后的30条，这和MySQ limit的原理是同样的，更多的分片致使更多的CPU消耗是必然。
至于分片做用：下面节选一段shell

Indexes in elasticsearch are not 1:1 mappings to Lucene indexes, they are in fact sharded across a configurable number of Lucene indexes, 5 by default, with 1 replica per shard. A single machine may have a greater or lesser number of shards for a given index than other machines in the cluster. Elasticsearch tries to keep the total data across all indexes about equal on all machines, even if that means that certain indexes may be disproportionately represented on a given machine. Each shard has a configurable number of full replicas, which are always stored on unique instances. If the cluster is not big enough to support the specified number of replicas the cluster’s health will be reported as a degraded ‘yellow’ state. The basic dev setup for elasticsearch, consequently, always thinks that it’s operating in a degraded state given that by default indexes, a single running instance has no peers to replicate its data to. Note that this has no practical effect on its operation for development purposes. It is, however, recommended that elasticsearch always run on multiple servers in production environments. As a clustered database, many of data guarantees hinge on multiple nodes being available.
大致能够认为分片能够将同一个请求的负载分到集群的不一样节点上。数据库

关于大分页

从上面的shard的原理来看，大的分页查询对于集群来讲，开销很是巨大。apache

正常对于一个搜索的应用来讲，当用户没法在前三页搜索到须要的内容时，应该引导用户增长搜索条件以便缩小搜索范围，而不是不断日后翻，这样不只服务器压力大，体验也很差。

还有什么方式来管理模板？（2016年3月3日更新）

还能够经过ES提供的接口来管理模板。这种管理方式最近用的比较多，相比以前我认为文件的管理方式来讲，会更直观一些。

curl -XPUT http://127.0.0.1:9200/_template/user -d '
{
     ...模板配置
}'

经过上面的方式，直接更新ES集群中名称为user的模板

-如何管理？

如今用的方式是将模板保存为一个个.json文件，而且放在git库中。另外用python写一个脚原本代替curl繁琐的指令操做，脚本功能以下，这样管理起来就方便了。

Usage: utp.py [options] <template file name>

Examples:
  utp.py -f 0-base.json

Options:
  -h, --help            show this help message and exit
  -a, --all             遍历全部目录的模板发送到服务器
  -d, --delete          删除指定文件的模板，若是和--all一块儿使用，删除所有以目录中模板名相同的模板
  -f FILE, --file=FILE  指定模板文件，模板文件也能够直接跟在最后
  -n NODE, --node=NODE  Elasticsearch 节点ip [default:127.0.0.1]
  -p PORT, --port=PORT  Elasticsearch 节点端口 [default:9200]

关于模板相互覆盖的问题

若是你正好在作一个ELK 日志管理的项目，应该会遇到这个问题，就是不少日志的格式实际上是相同的，咱们并不但愿反复去写模板。处理这个问题有不少手段，并且这些手段每每须要一块儿使用。

模板覆盖
默认模板
动态字段

-模板覆盖

在上面的模板配置中，有一个order字段。以前我没太在乎，由于项目要的模板是很特殊的，无法通用。

好比我有一个日志系统，里面要放nginx日志，而公司项目不少，并不但愿公用一个索引。当咱们创建模板的时候，能够创建这样几个。

nginx 只有mappings的配置，字段名和类型，匹配全部 *-nginx-* 的模板，order=0。
base 只有settings的配置，主要是配置分片规则、备份规则等等，匹配全部 * 的模板 order=0
项目名模板（好比user）基本能够是空的，匹配全部user-*的模板 order = 1（或者更高）

如今创建一个索引叫作 user-nginx-2016.03.03，系统会发现符合 * 的匹配规则，调用base模板，进行配置，而后会发现也符合-nginx-规则，调用nginx模板进行配置，最后发现符合项目名模板的配置user-*，再调用项目模板。order越大，优先权也越大，一样一个配置，系统会采用order更大的模板。

这样，当有另个项目的nginx日志过来，就不用在创建新的模板了，除非这个项目有特殊需求。

-默认模板

其实就是_default_。好比你的一个索引下面有多个type，格式相同，能够创建一个名为_default_的type。当新建任意type的时候，都会先读取这个配置。能够看下面一个代码例子。

-动态字段

有时候服务器可能传一些咱们没有配置好的字段过来，好比日志系统咱们但愿doc_values最好能是true的时候，就是true。没有分词需求的字符串字段，不要analyze。这些均可以经过动态字段来完成。好比下面一个若是遇到整数要怎么处理。

"mappings": {
    "_default_": {
      "dynamic_templates": [
        {
          "integer field": {
            "mapping": {
              "doc_values": true,
              "type": "integer"
            },
            "match": "*",
            "match_mapping_type": "integer"
          }
        },

参考资料

stackoverflow上的讨论：http://stackoverflow.com/questions/23926644/how-to-configure-number-of-shards-per-cluster-in-elasticsearch
中文资料：http://kibana.logstash.es/content/elasticsearch/index.html
官方文档：https://www.elastic.co/guide/index.html