深入理解ElasticSearch（八）：索引管理

索引管理

1、创建一个索引

到目前为止, 我们已经通过索引一篇文档创建了一个新的索引。这个索引采用的是默认的配置，新的字段通过动态映射的方式被添加到类型映射。现在我们需要对这个建立索引的过程做更多的控制：我们想要确保这个索引有数量适中的主分片，并且在我们索引任何数据之前，分析器和映射已经被建立好。

为了达到这个目的，我们需要手动创建索引，在请求体里面传入设置或类型映射，如下所示：

PUT /my_index
{"settings": { ... any settings ... },"mappings": {"type_one": { ... any mappings ... },"type_two": { ... any mappings ... },...}
}

如果你想禁止自动创建索引，你可以通过在 config/elasticsearch.yml 的每个节点下添加下面的配置：

action.auto_create_index: false

2、删除一个索引

用以下的请求来删除索引:

DELETE /my_index

你也可以这样删除多个索引：

DELETE /index_one,index_two
DELETE /index_*

你甚至可以这样删除全部索引：

DELETE /_all
DELETE /*

3、索引设置

下面是两个最重要的设置：

number_of_shards

每个索引的主分片数，默认值是 5 。这个配置在索引创建后不能修改。

number_of_replicas

每个主分片的副本数，默认值是 1 。对于活动的索引库，这个配置可以随时修改。
例如，我们可以创建只有一个主分片，没有副本的小索引：

PUT /my_temp_index
{"settings": {"number_of_shards" :   1,"number_of_replicas" : 0}
}

然后，我们可以用 update-index-settings API 动态修改副本数：

PUT /my_temp_index/_settings
{"number_of_replicas": 1
}

4、配置分析器

第三个重要的索引设置是 analysis 部分，用来配置已存在的分析器或针对你的索引创建新的自定义分析器。

在分析与分析器，我们介绍了一些内置的分析器，用于将全文字符串转换为适合搜索的倒排索引。

standard 分析器是用于全文字段的默认分析器，对于大部分西方语系来说是一个不错的选择。它包括了以下几点：

standard 分词器，通过单词边界分割输入的文本。
standard 语汇单元过滤器，目的是整理分词器触发的语汇单元（但是目前什么都没做）。
lowercase 语汇单元过滤器，转换所有的语汇单元为小写。
stop 语汇单元过滤器，删除停用词–对搜索相关性影响不大的常用词，如 a ， the ， and ， is 。

默认情况下，停用词过滤器是被禁用的。如需启用它，你可以通过创建一个基于 standard 分析器的自定义分析器并设置 stopwords 参数。可以给分析器提供一个停用词列表，或者告知使用一个基于特定语言的预定义停用词列表。

在下面的例子中，我们创建了一个新的分析器，叫做 es_std ，并使用预定义的西班牙语停用词列表：

PUT /spanish_docs
{"settings": {"analysis": {"analyzer": {"es_std": {"type":      "standard","stopwords": "_spanish_"}}}}
}

es_std 分析器不是全局的–它仅仅存在于我们定义的 spanish_docs 索引中。为了使用 analyze API来对它进行测试，我们必须使用特定的索引名：

GET /spanish_docs/_analyze?analyzer=es_std
El veloz zorro marrón

简化的结果显示西班牙语停用词 El 已被正确的移除：

{"tokens" : [{ "token" :    "veloz",   "position" : 2 },{ "token" :    "zorro",   "position" : 3 },{ "token" :    "marrón",  "position" : 4 }]
}

5、自定义分析器

虽然Elasticsearch带有一些现成的分析器，然而在分析器上Elasticsearch真正的强大之处在于，你可以通过在一个适合你的特定数据的设置之中组合字符过滤器、分词器、词汇单元过滤器来创建自定义的分析器。

在分析与分析器我们说过，一个分析器就是在一个包里面组合了三种函数的一个包装器，三种函数按照顺序被执行:

字符过滤器
字符过滤器用来整理一个尚未被分词的字符串。例如，如果我们的文本是HTML格式的，它会包含像

或者

这样的HTML标签，这些标签是我们不想索引的。我们可以使用 html清除字符过滤器来移除掉所有的HTML标签，并且像把 Á 转换为相对应的Unicode字符 Á 这样，转换HTML实体。

一个分析器可能有0个或者多个字符过滤器。

分词器
一个分析器必须有一个唯一的分词器。分词器把字符串分解成单个词条或者词汇单元。标准分析器里使用的标准分词器把一个字符串根据单词边界分解成单个词条，并且移除掉大部分的标点符号，然而还有其他不同行为的分词器存在。

例如，关键词分词器完整地输出接收到的同样的字符串，并不做任何分词。空格分词器只根据空格分割文本。正则分词器根据匹配正则表达式来分割文本。

词单元过滤器
经过分词，作为结果的词单元流会按照指定的顺序通过指定的词单元过滤器。

词单元过滤器可以修改、添加或者移除词单元。我们已经提到过 lowercase 和 stop 词过滤器，但是在 Elasticsearch 里面还有很多可供选择的词单元过滤器。词干过滤器把单词遏制为词干。 ascii_folding 过滤器移除变音符，把一个像 “très” 这样的词转换为 “tres” 。 ngram 和 edge_ngram 词单元过滤器可以产生适合用于部分匹配或者自动补全的词单元。

在深入搜索，我们讨论了在哪里使用，以及怎样使用分词器和过滤器。但是首先，我们需要解释一下怎样创建自定义的分析器。

创建一个自定义分析器
和我们之前配置 es_std 分析器一样，我们可以在 analysis 下的相应位置设置字符过滤器、分词器和词单元过滤器:

PUT /my_index
{"settings": {"analysis": {"char_filter": { ... custom character filters ... },"tokenizer":   { ...    custom tokenizers     ... },"filter":      { ...   custom token filters   ... },"analyzer":    { ...    custom analyzers      ... }}}
}

作为示范，让我们一起来创建一个自定义分析器吧，这个分析器可以做到下面的这些事:

1、使用 html清除字符过滤器移除HTML部分。
2、使用一个自定义的映射字符过滤器把 & 替换为 ” 和 ” ：

"char_filter": {"&_to_and": {"type":       "mapping","mappings": [ "&=> and "]}
}

3、使用标准分词器分词。
4、小写词条，使用小写词过滤器处理。
5、使用自定义停止词过滤器移除自定义的停止词列表中包含的词：

"filter": {"my_stopwords": {"type":        "stop","stopwords": [ "the", "a" ]}
}

我们的分析器定义用我们之前已经设置好的自定义过滤器组合了已经定义好的分词器和过滤器：

"analyzer": {"my_analyzer": {"type":           "custom","char_filter":  [ "html_strip", "&_to_and" ],"tokenizer":      "standard","filter":       [ "lowercase", "my_stopwords" ]}
}

汇总起来，完整的创建索引请求看起来应该像这样：

PUT /my_index
{"settings": {"analysis": {"char_filter": {"&_to_and": {"type":       "mapping","mappings": [ "&=> and "]}},"filter": {"my_stopwords": {"type":       "stop","stopwords": [ "the", "a" ]}},"analyzer": {"my_analyzer": {"type":         "custom","char_filter":  [ "html_strip", "&_to_and" ],"tokenizer":    "standard","filter":       [ "lowercase", "my_stopwords" ]}}
}}}

索引被创建以后，使用 analyze API 来测试这个新的分析器：

GET /my_index/_analyze?analyzer=my_analyzer
The quick & brown fox

下面的缩略结果展示出我们的分析器正在正确地运行：

{"tokens" : [{ "token" :   "quick",    "position" : 2 },{ "token" :   "and",      "position" : 3 },{ "token" :   "brown",    "position" : 4 },{ "token" :   "fox",      "position" : 5 }]
}

这个分析器现在是没有多大用处的，除非我们告诉 Elasticsearch在哪里用上它。我们可以像下面这样把这个分析器应用在一个 string 字段上：

PUT /my_index/_mapping/my_type
{"properties": {"title": {"type":      "string","analyzer":  "my_analyzer"}}
}

6、类型和映射

类型在 Elasticsearch 中表示一类相似的文档。类型由名称 —比如 user 或 blogpost —和映射组成。

映射, 就像数据库中的 schema ，描述了文档可能具有的字段或属性、每个字段的数据类型—比如 string, integer 或 date —以及Lucene是如何索引和存储这些字段的。

类型可以很好的抽象划分相似但不相同的数据。但由于 Lucene 的处理方式，类型的使用有些限制。

6.1、Lucene 如何处理文档

在 Lucene 中，一个文档由一组简单的键值对组成。每个字段都可以有多个值，但至少要有一个值。类似的，一个字符串可以通过分析过程转化为多个值。Lucene 不关心这些值是字符串、数字或日期–所有的值都被当做不透明字节。

当我们在 Lucene 中索引一个文档时，每个字段的值都被添加到相关字段的倒排索引中。你也可以将未处理的原始数据存储起来，以便这些原始数据在之后也可以被检索到。

6.2、类型是如何实现的

Elasticsearch 类型是以 Lucene 处理文档的这个方式为基础来实现的。一个索引可以有多个类型，这些类型的文档可以存储在相同的索引中。

Lucene 没有文档类型的概念，每个文档的类型名被存储在一个叫 _type 的元数据字段上。当我们要检索某个类型的文档时, Elasticsearch 通过在 _type 字段上使用过滤器限制只返回这个类型的文档。

Lucene 也没有映射的概念。映射是 Elasticsearch 将复杂 JSON 文档映射成 Lucene 需要的扁平化数据的方式。

例如，在 user 类型中， name 字段的映射可以声明这个字段是 string 类型，并且它的值被索引到名叫 name 的倒排索引之前，需要通过 whitespace 分词器分析：

"name": {"type":     "string","analyzer": "whitespace"
}

6.3、避免类型陷阱

这导致了一个有趣的思想实验：如果有两个不同的类型，每个类型都有同名的字段，但映射不同（例如：一个是字符串一个是数字），将会出现什么情况？

简单回答是，Elasticsearch 不会允许你定义这个映射。当你配置这个映射时，将会出现异常。

详细回答是，每个 Lucene 索引中的所有字段都包含一个单一的、扁平的模式。一个特定字段可以映射成 string 类型也可以是 number 类型，但是不能两者兼具。因为类型是 Elasticsearch 添加的优于 Lucene 的额外机制（以元数据 _type 字段的形式），在 Elasticsearch 中的所有类型最终都共享相同的映射。

以 data 索引中两种类型的映射为例：

{"data": {"mappings": {"people": {"properties": {"name": {"type": "string",},"address": {"type": "string"}}},"transactions": {"properties": {"timestamp": {"type": "date","format": "strict_date_optional_time"},"message": {"type": "string"}}}}}
}

每个类型定义两个字段 (分别是 "name"/"address" 和 "timestamp"/"message" )。它们看起来是相互独立的，但在后台 Lucene 将创建一个映射，如:

{"data": {"mappings": {"_type": {"type": "string","index": "not_analyzed"},"name": {"type": "string"}"address": {"type": "string"}"timestamp": {"type": "long"}"message": {"type": "string"}}}
}

注: 这不是真实有效的映射语法，只是用于演示

对于整个索引，映射在本质上被扁平化成一个单一的、全局的模式。这就是为什么两个类型不能定义冲突的字段：当映射被扁平化时，Lucene 不知道如何去处理。

6.4、类型结论

那么，这个讨论的结论是什么？技术上讲，多个类型可以在相同的索引中存在，只要它们的字段不冲突（要么因为字段是互为独占模式，要么因为它们共享相同的字段）。

重要的一点是: 类型可以很好的区分同一个集合中的不同细分。在不同的细分中数据的整体模式是相同的（或相似的）。

类型不适合完全不同类型的数据。如果两个类型的字段集是互不相同的，这就意味着索引中将有一半的数据是空的（字段将是稀疏的），最终将导致性能问题。在这种情况下，最好是使用两个单独的索引。

总结：

正确: 将 kitchen 和 lawn-care 类型放在 products 索引中, 因为这两种类型基本上是相同的模式
错误: 将 products 和 logs 类型放在 data 索引中, 因为这两种类型互不相同。应该将它们放在不同的索引中。

7、根对象

映射的最高一层被称为根对象，它可能包含下面几项：

一个 properties 节点，列出了文档中可能包含的每个字段的映射
各种元数据字段，它们都以一个下划线开头，例如 _type 、 _id 和 _source
设置项，控制如何动态处理新的字段，例如 analyzer 、 dynamic_date_formats 和 dynamic_templates
其他设置，可以同时应用在根对象和其他 object 类型的字段上，例如 enabled 、 dynamic 和 include_in_all

7.1、属性

我们已经在核心简单域类型和复杂核心域类型章节中介绍过文档字段和属性的三个最重要的设置：

type
字段的数据类型，例如 string 或 date
index
字段是否应当被当成全文来搜索（ analyzed ），或被当成一个准确的值（ not_analyzed ），还是完全不可被搜索（ no ）
analyzer
确定在索引和搜索时全文字段使用的 analyzer

我们将在本书的后续部分讨论其他字段类型，例如 ip 、 geo_point 和 geo_shape 。

7.2、元数据: _source 字段

默认地，Elasticsearch 在 _source 字段存储代表文档体的JSON字符串。和所有被存储的字段一样， _source 字段在被写入磁盘之前先会被压缩。

这个字段的存储几乎总是我们想要的，因为它意味着下面的这些：

搜索结果包括了整个可用的文档——不需要额外的从另一个的数据仓库来取文档。
如果没有 _source 字段，部分 update 请求不会生效。
当你的映射改变时，你需要重新索引你的数据，有了_source字段你可以直接从Elasticsearch这样做，而不必从另一个（通常是速度更慢的）数据仓库取回你的所有文档。
当你不需要看到整个文档时，单个字段可以从 _source 字段提取和通过 get 或者 search 请求返回。
调试查询语句更加简单，因为你可以直接看到每个文档包括什么，而不是从一列id猜测它们的内容。

然而，存储 _source 字段的确要使用磁盘空间。如果上面的原因对你来说没有一个是重要的，你可以用下面的映射禁用 _source 字段：

PUT /my_index
{"mappings": {"my_type": {"_source": {"enabled":  false}}}
}

在一个搜索请求里，你可以通过在请求体中指定 _source 参数，来达到只获取特定的字段的效果：

GET /_search
{"query":   { "match_all": {}},"_source": [ "title", "created" ]
}

这些字段的值会从 _source 字段被提取和返回，而不是返回整个 _source 。

7.3、元数据: _all 字段

在轻量搜索中，我们介绍了 _all 字段：一个把其它字段值当作一个大字符串来索引的特殊字段。 query_string 查询子句(搜索 ?q=john )在没有指定字段时默认使用 _all 字段。

_all 字段在新应用的探索阶段，当你还不清楚文档的最终结构时是比较有用的。你可以使用这个字段来做任何查询，并且有很大可能找到需要的文档：

GET /_search
{"match": {"_all": "john smith marketing"}
}

随着应用的发展，搜索需求变得更加明确，你会发现自己越来越少使用 _all 字段。 _all 字段是搜索的应急之策。通过查询指定字段，你的查询更加灵活、强大，你也可以对相关性最高的搜索结果进行更细粒度的控制。如果你不再需要 _all 字段，你可以通过下面的映射来禁用：

PUT /my_index/_mapping/my_type
{"my_type": {"_all": { "enabled": false }}
}

通过 include_in_all 设置来逐个控制字段是否要包含在 _all 字段中，默认值是 true。在一个对象(或根对象)上设置include_in_all 可以修改这个对象中的所有字段的默认行为。

你可能想要保留 _all 字段作为一个只包含某些特定字段的全文字段，例如只包含 title，overview，summary 和 tags。相对于完全禁用_all 字段，你可以为所有字段默认禁用 include_in_all 选项，仅在你选择的字段上启用：

PUT /my_index/my_type/_mapping
{"my_type": {"include_in_all": false,"properties": {"title": {"type":           "string","include_in_all": true},...}}
}

记住，_all 字段仅仅是一个经过分词的 string 字段。它使用默认分词器来分析它的值，不管这个值原本所在字段指定的分词器。就像所有 string 字段，你可以配置 _all 字段使用的分词器：

PUT /my_index/my_type/_mapping
{"my_type": {"_all": { "analyzer": "whitespace" }}
}

7.4、元数据：文档标识

文档标识与四个元数据字段相关：

_id
文档的 ID 字符串
_type
文档的类型名
_index
文档所在的索引
_uid
_type 和 _id 连接在一起构造成 type#id
默认情况下， _uid 字段是被存储（可取回）和索引（可搜索）的。 _type 字段被索引但是没有存储， _id 和 _index 字段则既没有被索引也没有被存储，这意味着它们并不是真实存在的。

尽管如此，你仍然可以像真实字段一样查询 _id 字段。Elasticsearch 使用 _uid 字段来派生出 _id 。虽然你可以修改这些字段的 index 和 store 设置，但是基本上不需要这么做。

8、动态映射

当 Elasticsearch 遇到文档中以前未遇到的字段，它用 dynamic mapping 来确定字段的数据类型并自动把新的字段添加到类型映射。

有时这是想要的行为有时又不希望这样。通常没有人知道以后会有什么新字段加到文档，但是又希望这些字段被自动的索引。也许你只想忽略它们。如果Elasticsearch是作为重要的数据存储，可能就会期望遇到新字段就会抛出异常，这样能及时发现问题。

幸运的是可以用 dynamic 配置来控制这种行为，可接受的选项如下：

true
动态添加新的字段–缺省
false
忽略新的字段
strict
如果遇到新字段抛出异常
配置参数 dynamic 可以用在根 object 或任何 object 类型的字段上。你可以将 dynamic 的默认值设置为 strict , 而只在指定的内部对象中开启它, 例如：

PUT /my_index
{"mappings": {"my_type": {"dynamic":      "strict", "properties": {"title":  { "type": "string"},"stash":  {"type":     "object","dynamic":  true }}}}
}

使用上述动态映射，你可以给 stash 对象添加新的可检索的字段：

PUT /my_index/my_type/1
{"title":   "This doc adds a new field","stash": { "new_field": "Success!" }
}

但是对根节点对象 my_type 进行同样的操作会失败：

PUT /my_index/my_type/1
{"title":     "This throws a StrictDynamicMappingException","new_field": "Fail!"
}

9、缺省映射

通常，一个索引中的所有类型共享相同的字段和设置。 default 映射更加方便地指定通用设置，而不是每次创建新类型时都要重复设置。 default 映射是新类型的模板。在设置 default 映射之后创建的所有类型都将应用这些缺省的设置，除非类型在自己的映射中明确覆盖这些设置。

例如，我们可以使用 default 映射为所有的类型禁用 _all 字段，而只在 blog 类型启用：

PUT /my_index
{"mappings": {"_default_": {"_all": { "enabled":  false }},"blog": {"_all": { "enabled":  true  }}}
}

default 映射也是一个指定索引 dynamic templates 的好方法。

10、重新索引你的数据

尽管可以增加新的类型到索引中，或者增加新的字段到类型中，但是不能添加新的分析器或者对现有的字段做改动。如果你那么做的话，结果就是那些已经被索引的数据就不正确，搜索也不能正常工作。

对现有数据的这类改变最简单的办法就是重新索引：用新的设置创建新的索引并把文档从旧的索引复制到新的索引。

字段 _source 的一个优点是在Elasticsearch中已经有整个文档。你不必从源数据中重建索引，而且那样通常比较慢。

为了有效的重新索引所有在旧的索引中的文档，用 scroll 从旧的索引检索批量文档，然后用 bulk API 把文档推送到新的索引中。

从Elasticsearch v2.3.0开始， Reindex API 被引入。它能够对文档重建索引而不需要任何插件或外部工具。

批量重新索引

同时并行运行多个重建索引任务，但是你显然不希望结果有重叠。正确的做法是按日期或者时间这样的字段作为过滤条件把大的重建索引分成小的任务：

GET /old_index/_search?scroll=1m
{"query": {"range": {"date": {"gte":  "2014-01-01","lt":   "2014-02-01"}}},"sort": ["_doc"],"size":  1000
}

如果旧的索引持续会有变化，你希望新的索引中也包括那些新加的文档。那就可以对新加的文档做重新索引，但还是要用日期类字段过滤来匹配那些新加的文档。

11、索引别名和零停机

在前面提到的，重建索引的问题是必须更新应用中的索引名称。索引别名就是用来解决这个问题的！

索引别名就像一个快捷方式或软连接，可以指向一个或多个索引，也可以给任何一个需要索引名的API来使用。别名带给我们极大的灵活性，允许我们做下面这些：

在运行的集群中可以无缝的从一个索引切换到另一个索引
给多个索引分组 (例如， last_three_months)
给索引的一个子集创建视图

在后面我们会讨论更多关于别名的使用。现在，我们将解释怎样使用别名在零停机下从旧索引切换到新索引。

有两种方式管理别名： _alias 用于单个操作， _aliases 用于执行多个原子级操作。

在本章中，我们假设你的应用有一个叫 my_index 的索引。事实上， my_index 是一个指向当前真实索引的别名。真实索引包含一个版本号： my_index_v1 ， my_index_v2 等等。

首先，创建索引 my_index_v1 ，然后将别名 my_index 指向它：

PUT /my_index_v1
PUT /my_index_v1/_alias/my_index

你可以检测这个别名指向哪一个索引：

GET /*/_alias/my_index

或哪些别名指向这个索引：

GET /my_index_v1/_alias/*

两者都会返回下面的结果：

{"my_index_v1" : {"aliases" : {"my_index" : { }}}
}

然后，我们决定修改索引中一个字段的映射。当然，我们不能修改现存的映射，所以我们必须重新索引数据。首先, 我们用新映射创建索引 my_index_v2 ：

PUT /my_index_v2
{"mappings": {"my_type": {"properties": {"tags": {"type":   "string","index":  "not_analyzed"}}}}
}

然后我们将数据从 my_index_v1 索引到 my_index_v2 ，下面的过程在重新索引你的数据中已经描述过。一旦我们确定文档已经被正确地重索引了，我们就将别名指向新的索引。

一个别名可以指向多个索引，所以我们在添加别名到新索引的同时必须从旧的索引中删除它。这个操作需要原子化，这意味着我们需要使用 _aliases 操作：

POST /_aliases
{"actions": [{ "remove": { "index": "my_index_v1", "alias": "my_index" }},{ "add":    { "index": "my_index_v2", "alias": "my_index" }}]
}

你的应用已经在零停机的情况下从旧索引迁移到新索引了。