<!--秀川譯--> ### 分析控制 查詢只能查找在倒排索引中出現的詞，所以確保在文檔索引的時候以及字符串查詢的時候使用同一個分析器是很重要的，為了查詢的詞能夠在倒排索引中匹配到。 盡管我們說文檔中每個字段的分析器是已經定好的。但是字段可以有不同的分析器，通過給那個字段配置一個指定的分析器或者直接使用類型，索引，或節點上的默認分析器。在索引的時候，一個字段的值會被配置的或者默認的分析器分析。 舉個例子，讓我們添加一個字段到`my_index`： ```Javascript PUT /my_index/_mapping/my_type { "my_type": { "properties": { "english_title": { "type": "string", "analyzer": "english" } } } } ``` 現在我們可以通過`analyze`API分析`Foxes`詞來比較`english_title`字段中的值以及`title`字段中的值在創建索引的時候是怎么被分析的： ```Javacript GET /my_index/_analyze?field=my_type.title <1> Foxes GET /my_index/_analyze?field=my_type.english_title <2> Foxes ``` <1> 使用`standard`分析器的`title`字段將會返回詞`foxes`。 <2> 使用`english`分析器的`english_title`字段將會返回詞`fox`。 這意味著，如果我們為精確的詞`fox`執行一個低級別的`term`查詢，`english_title`字段會匹配而`title`字段不會。 像`match`查詢一樣的高級別的查詢可以知道字段的映射并且能夠在被查詢的字段上使用正確的分析器。我們可以在`validate-query` API的執行中看到這個： ```Javacript GET /my_index/my_type/_validate/query?explain { "query": { "bool": { "should": [ { "match": { "title": "Foxes"}}, { "match": { "english_title": "Foxes"}} ] } } } ``` 它會返回`explanation`： (title:foxes english_title:fox) `match`查詢為每個字段使用合適的分析器用來確保在那個字段上可以用正確的格式查詢這個詞。 #### 默認分析器 雖然我們可以在字段級別指定一個分析器，但是如果我們在字段級別沒有指定分析器的話，那要怎么決定某個字段使用什么分析器呢？ 分析器可以在好幾個地方設置。Elasticsearch會查找每個級別直到找到它可以使用的分析器。在創建索引的時候，Elasticsearch查找分析器的順序如下： * 在映射文件中指定字段的`analyzer`，或者 * *在文檔的`_analyzer`字段上指定分析器，或者* * 在映射文件中指定類型的默認分析器`analyzer` * 在索引映射文件中設置默認分析器`default` * 在節點級別設置默認分析器`default` * `standard`分析器 查找索引的時候，Elasticsearch查找分析器的順序稍微有點不一樣： * *在查詢參數中指定`analyzer`，或者* * 在映射文件中指定字段的`analyzer`，或者 * 在映射文件中指定類型的默認分析器`analyzer` * 在索引映射文件中設置默認分析器`default` * 在節點級別設置默認分析器`default` * `standard`分析器 > 提示： > > 上面列表中用斜體字的兩行突出了創建索引以及查詢索引的時候Elasticsearch查找分析器的區別。`_analyzer`字段允許你為每個文檔指定默認的分析器(比如, english, french, spanish)，雖然在查詢的時候指定`analyzer`參數，但是在一個索引中處理多種語言這并不是一個好方法，因為在多語言環境下很多問題會暴露出來。 有時候，在創建索引與查詢索引的時候使用不同的分析器也是有意義的。舉個例子：在創建索引的時候想要索引同義詞 (比如, 出現quick的時候，我們也索引 fast, rapid, 和 speedy)。但是在查詢索引的時候，我們不需要查詢所有的同義詞，我們只要查詢用戶輸入的一個單詞就可以了，它可以是`quick`, `fast`, `rapid`, 或者 `speedy`。 為了滿足這種差異，Elasticsearch也支持`index_analyzer` 和 `search_analyzer` 參數，并且分析器被命名為`default_index`和`default_search`。 把這些額外的參數考慮進去，Elasticsearch查找所有的分析器的順序實際上像下面的樣子： * 在映射文件中指定字段的`index_analyzer`，或者 * 在映射文件中指定字段的`analyzer`，或者 * 在文檔的`_analyzer`字段上指定分析器，或者 * 在映射文件中指定類型的創建索引的默認分析器`index_analyzer` * 在映射文件中指定類型的默認分析器`analyzer` * 在索引映射文件中設置創建索引的默認分析器`default_index` * 在索引映射文件中設置默認分析器`default` * 在節點級別設置創建索引的默認分析器`default_index` * 在節點級別設置默認分析器`default` * `standard`分析器 以及查詢索引的時候: * 在查詢參數中指定`analyzer`，或者 * 在映射文件中指定字段的`search_analyzer`，或者 * 在映射文件中指定字段的`analyzer`，或者 * 在映射文件中指定類型的查詢索引的默認分析器`analyzer` * 在索引映射文件中設置查詢索引的默認分析器`default_search` * 在索引映射文件中設置默認分析器`default_search` * 在節點級別設置查詢索引的默認分析器`default_search` * 在節點級別設置默認分析器`default` * `standard` 分析器 #### 實際配置分析器 可以指定分析器的地方實在是太多了，但實際上，指定分析器很簡單。 #### 用索引配置，而不是用配置文件 第一點要記住的是，盡管你開始使用Elasticsearch僅僅只是為了一個簡單的目的或者是一個應用比如日志，但很可能你會發現更多的案例（use cases翻譯成案例不知道合不合適，如果有更好的用詞，請聯系我，Tks），結局是在同一個集群中運行著好幾個不同的應用。每一個索引都需要是獨立的，并且可以被獨立的配置。你不要想著給一個案例設置默認值，但是不得不重寫他們來適配后面的案例。 這個規則把節點級別的配置分析器方法排除在外了。另外，節點級別的分析器配置方法需要改變每個節點的配置文件并且重啟每個節點，這將成為維護的噩夢。保持Elasticsearch持續運行并通過API來管理索引的設置是一個更好的方法。 #### 保持簡便性 大多數時間，你可以預先知道文檔會包含哪些字段。最簡單的方法是在你創建索引或者添加類型映射的時候為每一個全文檢索字段設置分析器。雖然這個方法有點啰嗦，但是它可以很容易的看到哪個字段應用了哪個分析器。 通常情況下，大部分的字符串字段是確切值`not_analyzed`字段（索引但不分析字段）比如標簽，枚舉，加上少數全文檢索字段會使用默認的分析器，像`standard` 或者 `english` 或者其他語言。然后你可能只有一到兩個字段需要定制分析：或許`title`字段需要按照你查找的方式去索引來支持你的查找。（指的是你查找的字符串用什么分析器，創建索引就用什么分析器） 你可以在索引設置`default`分析器的地方為幾乎所有全文檢索字段設置成你想要的分析器，并且只要在一到兩個字段指定專門的分析器。如果，在你的模型中，你每個類型都需要不同的分析器，那么在類型級別使用`analyzer`配置來代替。 > 提示： > 一個普通的像日志一樣的基于時間軸的工作流數據每天都得創建新的索引，忙著不斷的創建索引。雖然這種工作流阻止你預先創建索引，但是你可以使用索引模板來指定新的索引的配置和映射。 <!-- === Controlling Analysis Queries can find only terms that actually ((("full text search", "controlling analysis")))((("analysis", "controlling")))exist in the inverted index, so it is important to ensure that the same analysis process is applied both to the document at index time, and to the query string at search time so that the terms in the query match the terms in the inverted index. Although we say _document_, analyzers are determined per field.((("analyzers", "determined per-field"))) Each field can have a different analyzer, either by configuring a specific analyzer for that field or by falling back on the type, index, or node defaults. At index time, a field's value is analyzed by using the configured or default analyzer for that field. For instance, let's add a new field to `my_index`: [source,js] -------------------------------------------------- PUT /my_index/_mapping/my_type { "my_type": { "properties": { "english_title": { "type": "string", "analyzer": "english" } } } } -------------------------------------------------- // SENSE: 100_Full_Text_Search/30_Analysis.json Now we can compare how values in the `english_title` field and the `title` field are analyzed at index time by using the `analyze` API to analyze the word `Foxes`: [source,js] -------------------------------------------------- GET /my_index/_analyze?field=my_type.title <1> Foxes GET /my_index/_analyze?field=my_type.english_title <2> Foxes -------------------------------------------------- // SENSE: 100_Full_Text_Search/30_Analysis.json <1> Field `title`, which uses the default `standard` analyzer, will return the term `foxes`. <2> Field `english_title`, which uses the `english` analyzer, will return the term `fox`. This means that, were we to run a low-level `term` query for the exact term `fox`, the `english_title` field would match but the `title` field would not. High-level queries like the `match` query understand field mappings and can apply the correct analyzer for each field being queried.((("match query", "applying appropriate analyzer to each field"))) We can see this in action with ((("validate query API")))the `validate-query` API: [source,js] -------------------------------------------------- GET /my_index/my_type/_validate/query?explain { "query": { "bool": { "should": [ { "match": { "title": "Foxes"}}, { "match": { "english_title": "Foxes"}} ] } } } -------------------------------------------------- // SENSE: 100_Full_Text_Search/30_Analysis.json which returns this `explanation`: (title:foxes english_title:fox) The `match` query uses the appropriate analyzer for each field to ensure that it looks for each term in the correct format for that field. ==== Default Analyzers While we can specify an analyzer at the field level,((("full text search", "controlling analysis", "default analyzers")))((("analyzers", "default"))) how do we determine which analyzer is used for a field if none is specified at the field level? Analyzers can be specified at several levels. Elasticsearch works through each level until it finds an analyzer that it can use. At index time, the order ((("indexing", "applying analyzers")))is as follows: * The `analyzer` defined in the field mapping, else * _The analyzer defined in the `_analyzer` field of the document, else_ * The default `analyzer` for the `type`, which defaults to * The analyzer named `default` in the index settings, which defaults to * The analyzer named `default` at node level, which defaults to * The `standard` analyzer At search time, the ((("searching", "applying analyzers")))sequence is slightly different: * _The `analyzer` defined in the query itself, else_ * The `analyzer` defined in the field mapping, else * The default `analyzer` for the `type`, which defaults to * The analyzer named `default` in the index settings, which defaults to * The analyzer named `default` at node level, which defaults to * The `standard` analyzer [NOTE] ==== The two lines in italics in the preceding lists highlight differences in the index time sequence and the search time sequence. The `_analyzer` field allows you to specify a default analyzer for each document (for example, `english`, `french`, `spanish`) while the `analyzer` parameter in the query specifies which analyzer to use on the query string. However, this is not the best way to handle multiple languages in a single index because of the pitfalls highlighted in <<languages>>. ==== Occasionally, it makes sense to use a different analyzer at index and search time.((("analyzers", "using different analyzers at index and search time"))) For instance, at index time we may want to index synonyms (for example, for every occurrence of `quick`, we also index `fast`, `rapid`, and `speedy`). But at search time, we don't need to search for all of these synonyms. Instead we can just look up the single word that the user has entered, be it `quick`, `fast`, `rapid`, or `speedy`. To enable this distinction, Elasticsearch also supports ((("index_analyzer parameter")))((("search_analyzer parameter")))the `index_analyzer` and `search_analyzer` parameters, and((("default_search parameter"))) ((("default_index analyzer")))analyzers named `default_index` and `default_search`. Taking these extra parameters into account, the _full_ sequence at index time really looks like this: * The `index_analyzer` defined in the field mapping, else * The `analyzer` defined in the field mapping, else * The analyzer defined in the `_analyzer` field of the document, else * The default `index_analyzer` for the `type`, which defaults to * The default `analyzer` for the `type`, which defaults to * The analyzer named `default_index` in the index settings, which defaults to * The analyzer named `default` in the index settings, which defaults to * The analyzer named `default_index` at node level, which defaults to * The analyzer named `default` at node level, which defaults to * The `standard` analyzer And at search time: * The `analyzer` defined in the query itself, else * The `search_analyzer` defined in the field mapping, else * The `analyzer` defined in the field mapping, else * The default `search_analyzer` for the `type`, which defaults to * The default `analyzer` for the `type`, which defaults to * The analyzer named `default_search` in the index settings, which defaults to * The analyzer named `default` in the index settings, which defaults to * The analyzer named `default_search` at node level, which defaults to * The analyzer named `default` at node level, which defaults to * The `standard` analyzer ==== Configuring Analyzers in Practice The sheer number of places where you can specify an analyzer is quite overwhelming.((("full text search", "controlling analysis", "configuring analyzers in practice")))((("analyzers", "configuring in practice"))) In practice, though, it is pretty simple. ===== Use index settings, not config files The first thing to remember is that, even though you may start out using Elasticsearch for a single purpose or a single application such as logging, chances are that you will find more use cases and end up running several distinct applications on the same cluster. Each index needs to be independent and independently configurable. You don't want to set defaults for one use case, only to have to override them for another use case later. This rules out configuring analyzers at the node level. Additionally, configuring analyzers at the node level requires changing the config file on every node and restarting every node, which becomes a maintenance nightmare. It's a much better idea to keep Elasticsearch running and to manage settings only via the API. ===== Keep it simple Most of the time, you will know what fields your documents will contain ahead of time. The simplest approach is to set the analyzer for each full-text field when you create your index or add type mappings. While this approach is slightly more verbose, it enables you to easily see which analyzer is being applied to each field. Typically, most of your string fields will be exact-value `not_analyzed` fields such as tags or enums, plus a handful of full-text fields that will use some default analyzer like `standard` or `english` or some other language. Then you may have one or two fields that need custom analysis: perhaps the `title` field needs to be indexed in a way that supports _find-as-you-type_. You can set the `default` analyzer in the index to the analyzer you want to use for almost all full-text fields, and just configure the specialized analyzer on the one or two fields that need it. If, in your model, you need a different default analyzer per type, then use the type level `analyzer` setting instead. [NOTE] ==== A common work flow for time based data like logging is to create a new index per day on the fly by just indexing into it. While this work flow prevents you from creating your index up front, you can still use http://bit.ly/1ygczeq[index templates] to specify the settings and mappings that a new index should have. ==== -->