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