我们已经看到 Elasticsearch 如何在不需要任何预先计划和设置的情况下, 轻松地开发一个新的应用. 并且, 在你想调整索引和搜索过程来更好地适应你特殊的使用需求前, 不会花较长的时间. 它包含几乎所有的和索引及类型相关的定制选项.
在这一章, 将介绍管理索引和类型映射的 API 以及最重要的设置.
创建索引
手动创建索引, 在请求中加入所有设置和类型映射, 如下所示:
- PUT /my_index
- { "settings": { ... any settings ...},
- "mappings": {
- "type_one": { ... any mappings ... },
- "type_two": { ... any mappings ... },
- ...
- }
复制代码
事实上, 你可以通过在
config/elasticsearch.yml
中添加下面的配置来防止自动创建索引.
action.auto_create_index: false
复制代码
删除索引
使用以下的请求来删除索引:
DELETE /my_index
复制代码
你也可以用下面的方式删除多个索引
- DELETE /index_one,index_two
- DELETE /index_*
复制代码
你甚至可以删除所有索引
DELETE /_all
复制代码
索引设置
你可以通过很多种方式来自定义索引行为, 但是: Elasticsearch 提供了优化好的默认配置. 除非你明白这些配置的行为和为什么要这么做, 请不要修改这些配置.
下面是两个最重要的设置:
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
- }
复制代码
配置分析器
第三个重要的索引设置是 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 }
- ]
- }
复制代码
自定义分析器
虽然 Elasticsearch 内置了一系列的分析器, 但是真正的强大之处在于定制你自己的分析器. 你可以通过在配置文件中组合字符过滤器, 分词器和标记过滤器, 来满足特定数据的需求.
分析器 是三个顺序执行的组件的结合(字符过滤器, 分词器, 标记过滤器).
字符过滤器
字符过滤器是让字符串在被分词前变得更加 "整洁".
例如, 如果我们的文本是 html 格式, 它可能会包含一些我们不想被索引的 HTML 标签, 诸如 <p> 或 <div>.
我们可以使用 html_strip 字符过滤器 来删除所有的 HTML 标签, 并且将 HTML 实体转换成对应的 Unicode 字符,
比如将 Á 转成 Á.
一个分析器可能包含零到多个字符过滤器.
复制代码
分词器
一个分析器 必须 包含一个分词器.
分词器将字符串分割成单独的词 (terms) 或标记(tokens).
standard 分析器使用 standard 分词器将字符串分割成单独的字词, 删除大部分标点符号,
但是现存的其他分词器会有不同的行为特征.
例如, keyword 分词器输出和它接收到的相同的字符串, 不做任何分词处理.
[whitespace 分词器]只通过空格来分割文本.
[pattern 分词器]可以通过正则表达式来分割文本.
复制代码
标记过滤器
分词结果的 标记流 会根据各自的情况, 传递给特定的标记过滤器.
标记过滤器可能修改, 添加或删除标记.
我们已经提过 lowercase 和 stop 标记过滤器, 但是 Elasticsearch 中有更多的选择.
stemmer 标记过滤器将单词转化为他们的根形态(root form).
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_strip 字符过滤器去除所有的 HTML 标签
2. 将 & 替换成 and, 使用一个自定义的 mapping 字符过滤器
- "char_filter": {
- "&_to_and": {
- "type": "mapping",
- "mappings": [ "&=> and"]
- }
- }
复制代码
1. 使用 standard 分词器分割单词
2. 使用 lowercase 标记过滤器将词转为小写
3. 用 stop 标记过滤器去除一些自定义停用词.
- "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"
- }
- }
- }
复制代码
元数据:_source 字段
默认情况下, Elasticsearch 用 JSON 字符串来表示文档主体保存在_source 字段中 . 像其他保存的字段一样,_source 字段也会在写入硬盘前压缩.
这几乎始终是需要的功能, 因为:
1. 搜索结果中能得到完整的文档 -- 不需要额外去别的数据源中查询文档
2. 如果缺少 _source 字段, 部分 更新 请求不会起作用
3. 当你的映射有变化, 而且你需要重新索引数据时, 你可以直接在 Elasticsearch 中操作而不需要重新从别的数据源中取回数据.
4. 你可以从 _source 中通过 get 或 search 请求取回部分字段, 而不是整个文档.
5. 这样更容易排查错误, 因为你可以准确的看到每个文档中包含的内容, 而不是只能从一堆 ID 中猜测他们的内容.
即便如此, 存储 _source 字段还是要占用硬盘空间的. 假如上面的理由对你来说不重要, 你可以用下面的映射禁用 _source 字段:
- PUT /my_index
- {
- "mappings": {
- "my_type": {
- "_source": {
- "enabled": false
- }
- }
- }
- }
复制代码
在搜索请求中你可以通过限定_source 字段来请求指定字段:
- GET /_search
- {
- "query": { "match_all": {}},
- "_source": [ "title", "created" ]
- }
复制代码
这些字段会从 _source 中提取出来, 而不是返回整个 _source 字段.
文档 ID
文档唯一标识由四个元数据字段组成:
_id: 文档的字符串 ID
_type: 文档的类型名
_index: 文档所在的索引
_uid:_type 和 _id 连接成的 type#id
默认情况下,_uid 是被保存 (可取回) 和索引 (可搜索) 的._type 字段被索引但是没有保存,_id 和 _index 字段则既没有索引也没有储存, 它们并不是真实存在的.
尽管如此, 你仍然可以像真实字段一样查询 _id 字段. Elasticsearch 使用_uid 字段来追溯 _id. 虽然你可以修改这些字段的 index 和 store 设置, 但是基本上不需要这么做.
_id 字段有一个你可能用得到的设置: path 设置告诉 Elasticsearch 它需要从文档本身的哪个字段中生成_id
- PUT /my_index
- {
- "mappings": {
- "my_type": {
- "_id": {
- "path": "doc_id" <1>
- },
- "properties": {
- "doc_id": {
- "type": "string",
- "index": "not_analyzed"
- }
- }
- }
- }
- }
复制代码
<1> 从 doc_id 字段生成 _id
然后, 当你索引一个文档时:
- POST /my_index/my_type
- {
- "doc_id": "123"
- }
复制代码
_id 值由文档主体的 doc_id 字段生成.
- {
- "_index": "my_index",
- "_type": "my_type",
- "_id": "123", <1>
- "_version": 1,
- "created": true
- }
复制代码
动态映射
当 Elasticsearch 处理一个位置的字段时, 它通过[动态映射] 来确定字段的数据类型且自动将该字段加到类型映射中.
有时这是理想的行为, 有时却不是. 或许你不知道今后会有哪些字段加到文档中, 但是你希望它们能自动被索引.
或许你仅仅想忽略它们. 特别是当你使用 Elasticsearch 作为主数据源时, 你希望未知字段能抛出一个异常来警示你.
幸运的是, 你可以通过 dynamic 设置来控制这些行为, 它接受下面几个选项:
true: 自动添加字段(默认)
false: 忽略字段
strict: 当遇到未知字段时抛出异常
dynamic 设置可以用在根对象或任何 object 对象上. 你可以将 dynamic 默认设置为 strict, 而在特定内部对象上启用它:
- PUT /my_index
- {
- "mappings": {
- "my_type": {
- "dynamic": "strict", <1>
- "properties": {
- "title": { "type": "string"},
- "stash": {
- "type": "object",
- "dynamic": true <2>
- }
- }
- }
- }
- }
复制代码
- <1> 当遇到未知字段时, my_type 对象将会抛出异常
- <2> stash 对象会自动创建字段
通过这个映射, 你可以添加一个新的可搜索字段到 stash 对象中:
- PUT /my_index/my_type/1
- {
- "title": "This doc adds a new field",
- "stash": { "new_field": "Success!" }
- }
复制代码
但是在顶层做同样的操作则会失败:
- PUT /my_index/my_type/1
- {
- "title": "This throws a StrictDynamicMappingException",
- "new_field": "Fail!"
- }
复制代码
备注: 将 dynamic 设置成 false 完全不会修改 _source 字段的内容._source 将仍旧保持你索引时的完整 JSON 文档. 然而, 没有被添加到映射的未知字段将不可被搜索.
自定义动态索引
如果你想在运行时的增加新的字段, 你可能会开启动态索引. 虽然有时动态映射的 规则 显得不那么智能, 幸运的是我们可以通过设置来自定义这些规则.
日期检测
当 Elasticsearch 遇到一个新的字符串字段时, 它会检测这个字段是否包含一个可识别的日期, 比如 2014-01-01. 如果它看起来像一个日期, 这个字段会被作为 date 类型添加, 否则, 它会被作为 string 类型添加.
有些时候这个规则可能导致一些问题. 想象你有一个文档长这样:
{ "note": "2014-01-01" }
复制代码
假设这是第一次见到 note 字段, 它会被添加为 date 字段, 但是如果下一个文档像这样:
{ "note": "Logged out" }
复制代码
使用这个映射, 字符串将始终是 string 类型. 假如你需要一个 date 字段, 你得手动添加它.
动态模板
使用 dynamic_templates, 你可以完全控制新字段的映射, 你设置可以通过字段名或数据类型应用一个完全不同的映射.
每个模板都有一个名字用于描述这个模板的用途, 一个 mapping 字段用于指明这个映射怎么使用, 和至少一个参数 (例如 match) 来定义这个模板适用于哪个字段.
模板按照顺序来检测, 第一个匹配的模板会被启用. 例如, 我们给 string 类型字段定义两个模板:
es: 字段名以 _es 结尾需要使用 spanish 分析器.
en: 所有其他字段使用 english 分析器.
我们将 es 模板放在第一位, 因为它比匹配所有字符串的 en 模板更特殊一点
- PUT /my_index
- {
- "mappings": {
- "my_type": {
- "dynamic_templates": [
- { "es": {
- "match": "*_es", <1>
- "match_mapping_type": "string",
- "mapping": {
- "type": "string",
- "analyzer": "spanish"
- }
- }},
- { "en": {
- "match": "*", <2>
- "match_mapping_type": "string",
- "mapping": {
- "type": "string",
- "analyzer": "english"
- }
- }}
- ]
- }}}
复制代码
- <1> 匹配字段名以 _es 结尾的字段.
- <2> 匹配所有字符串类型字段.
match_mapping_type 允许你限制模板只能使用在特定的类型上, 就像由标准动态映射规则检测的一样,(例如 strong 和 long)
match 参数只匹配字段名, path_match 参数则匹配字段在一个对象中的完整路径, 所以 address.*.name 规则将匹配一个这样的字段:
- {
- "address": {
- "city": {
- "name": "New York"
- }
- }
- }
复制代码
unmatch 和 path_unmatch 规则将用于排除未被匹配的字段.
默认映射
通常, 一个索引中的所有类型具有共享的字段和设置. 用 _default_ 映射来指定公用设置会更加方便, 而不是每次创建新的类型时重复操作.
_default 映射像新类型的模板. 所有在 _default_映射 之后 的类型将包含所有的默认设置, 除非在自己的类型映射中明确覆盖这些配置.
例如, 我们可以使用 _default_ 映射对所有类型禁用 _all 字段, 而只在 blog 字段上开启它:
- PUT /my_index
- {
- "mappings": {
- "_default_": {
- "_all": { "enabled": false }
- },
- "blog": {
- "_all": { "enabled": true }
- }
- }
- }
复制代码
_default_ 映射也是定义索引级别的动态模板的好地方.
重新索引数据
虽然你可以给索引添加新的类型, 或给类型添加新的字段, 但是你不能添加新的分析器或修改已有字段.
假如你这样做, 已被索引的数据会变得不正确而你的搜索也不会正常工作.
修改在已存在的数据最简单的方法是重新索引: 创建一个新配置好的索引, 然后将所有的文档从旧的索引复制到新的上.
_source 字段的一个最大的好处是你已经在 Elasticsearch 中有了完整的文档, 你不再需要从数据库中重建你的索引, 这样通常会比较慢.
为了更高效的索引旧索引中的文档, 使用[scan-scoll] 来批量读取旧索引的文档, 然后将通过[bulk API] 来将它们推送给新的索引.
索引别名和零停机时间
前面提到的重新索引过程中的问题是必须更新你的应用, 来使用另一个索引名. 索引别名正是用来解决这个问题的!
索引 别名 就像一个快捷方式或软连接, 可以指向一个或多个索引, 也可以给任何需要索引名的 API 使用.
别名带给我们极大的灵活性, 允许我们做到:
1. 在一个运行的集群上无缝的从一个索引切换到另一个
2. 给多个索引分类(例如, last_three_months)
3. 给索引的一个子集创建 视图
这里有两种管理别名的途径: _alias 用于单个操作,_aliases 用于原子化多个操作.
我们假设你的应用采用一个叫 my_index 的索引. 而事实上, my_index 是一个指向当前真实索引的别名. 真实的索引名将包含一个版本号: my_index_v1, my_index_v2 等等.
开始, 我们创建一个索引 my_index_v1, 然后将别名 my_index 指向它:
- PUT /my_index_v1 <1>
- PUT /my_index_v1/_alias/my_index <2>
复制代码
- <1> 创建索引 my_index_v1.
- <2> 将别名 my_index 指向 my_index_v1.
你可以检测这个别名指向哪个索引:
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" }}
- ]
- }
复制代码
这样, 你的应用就从旧索引迁移到了新的, 而没有停机时间.
提示: 在应用中使用别名而不是索引. 然后你就可以在任何时候重建索引. 别名的开销很小, 应当广泛使用.
复制代码
参考: es 权威指南 https://es.xiaoleilu.com/070_Index_Mgmt/55_Aliases.html
来源: https://juejin.im/post/5b7c10e7f265da436e74cadf