问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
最近在调研ElasticSearch(简称ES)，从中了解到了一些ES的设计原理，不过也产生了几个疑问，和大家讨论讨论~
默认为每一个字段创建索引
该做法是否会影响数据的插入、删除、更新的速度？
会存储文档的所有字段，直接从ES中返回查询结果，而不需要去关联查询db
该做法增加了磁盘资源的使用（如果你还不得不在db中存储一份数据的话），当然，可以只在ES中存储那些需要检索的数据字段，但这就会和其他搜索引擎一样（速度上），并且同样会造成数据一致性问题，大家平时都是怎么权衡的？
文档相对少，核心开发人员只有一个，没有经历过时间上的洗礼（太年轻）
关于这个观点，大家又是如何理解？
其实是因为ELK才认识到ES的存在的，在处理日志数据的时候，感觉ES的设计理念还是很贴近场景的，但是如果使用在整个项目的搜索场景，我个人是有些犹豫的。大家又是怎么看的呢？
最后附上一个对比链接：
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
默认为每一个字段创建索引
其实是没有必要的，哪个字段创建索引根据业务来定。例如像直接靠数据库的索引能解决了的就没必要，但是像中文名，文本类的模糊匹配这类在mysql检索速度很慢的字段，就可以将这种字段与他的主键id一起在es创建索引。
会存储文档的所有字段，直接从ES中返回查询结果，而不需要去关联查询db
这个问题属于第一个的引申，应用将文本查询的检索执行后，得到该条记录在数据库的主键id，再用id去数据库里查相关信息。如果涉及到A表x字段和B表y字段的联合模糊检索，那么创建索引的时候将这两个表的x与y字段在es中同一个Type里创建索引。检索后可以得到结果在A表和B表各自的主键id，再根据自身业务去数据库里取相应记录即可。
关于数据的一致性问题，大概有三个方案
1，应用上自己控制，增删改的时候相应的去维护索引信息。一致性的维护就靠程序实现，比较麻烦，但是比较灵活。
2，通过bin-log去自动创建索引， github上有这个项目，自己配置好数据源就自动创建索引了。靠binlog同步一致性能做到最好，但是不太灵活，完全根据数据库表结构创建所有字段的索引，并且联表查询也比较麻烦。
3，通过river去自定义创建索引， github上也有这个项目，是es的一个插件，通过jdbc将自定义好的sql语句从mysql中同步过来。通过sql可自定义需要索引的字段，另外表结构里需要有一个update_time的字段供sql去查找新增或者更新的数据，以保证索引的一致性，删除数据的一致性需要在程序里控制。这个方法虽然也不完美，但是也算结合了1和2方式的优缺点把。
文档相对少，核心开发人员只有一个，没有经历过时间上的洗礼（太年轻）
看看官网上的USE CASES就可以不用担心这个问题了
如果使用在整个项目的搜索场景，我个人是有些犹豫的。大家又是怎么看的呢？
搜索还是看场景，能够通过数据库搜索的就靠数据库，预期数据库解决不了的再切换到es上。
全放在es上，效率和数据的安全性肯定不如db与es结合的高。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
最近也在搭建实时的log分析系统，es很好用，感觉你看的文章有点过时了，建议仔细阅读elastic的官网
同步到新浪微博
分享到微博？
你好！看起来你挺喜欢这个内容，但是你还没有注册帐号。 当你创建了帐号，我们能准确地追踪你关注的问题，在有新答案或内容的时候收到网页和邮件通知。还能直接向作者咨询更多细节。如果上面的内容有帮助，记得点赞 (????)? 表示感谢。
明天提醒我
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：
扫扫下载 AppElasticsearch 索引创建 - 简书
Elasticsearch 索引创建
最近计划把Elasticsearch升级到当前最新版本2.3.3。 我在本地虚拟机上搭建了一个ES集群。
elastic: 2.3.3
os: redhat 6
es 插件: head
创建索引的时候通过REST或head插件创建索引都提示成功，但是es集群的健康显示为red。 也就是我创建的这个索引没有加入到集群的任何节点好像这个索引从这个集群脱落一样
最开始怀疑是我的集群配置不对 但是我在Windows上原样配置是可以正确创建索引的
也怀疑过是用户权限的问题 因为从elastic 2 开始就不能用root用户启动
最后在启动elastic的时候发现启动日志里面有个警告日志 大概意思是说你存储数据的磁盘空闲率太低 最后扩展虚拟机内存这个问题就解决了
最终解决方法是：查看存储数据的磁盘是否空间不足 或可使用空间太少
遇到问题多看下程序的日志 包括启动过程中的日志
安逸使人失去进取索引管理本文翻译自Elasticsearch官方指南的一章我们已经了解了ES是如何在不需要任何复杂的计划和安装就能让我们很容易地开始开发一个新的应用的。但是，用不了多久你就会想要仔细调整索引和搜索过程来更好的适配你的用例。几乎所有的定制都和索引(Index)以及其中的类型(Type)相关。本章我们就来讨论用于管理索引和类型映射的API，以及最重要的设置。创建索引到现在为止，我们已经通过索引一份文档来完成了新索引的创建。这个索引是使用默认的设置创建的，新的域通过动态映射(Dynamic Mapping)的方式被添加到了类型映射(Type Mapping)中。现在我们对这个过程拥有更多的控制：我们需要确保索引被创建时拥有合适数量的主分片(Primary Shard)，并且在索引任何数据之前，我们需要设置好解析器(Analyzers)以及映射(Mappings)。因此我们需要手动地去创建索引，将任何需要的设置和类型映射传入到请求正文中，就像下面这样：[code]PUT /my_index{
"settings": { ... },
"mappings": {
"type_one": { ... },
"type_two": { ... },
}}[/code]事实上，如果你想阻止索引被自动创建，可以通过添加下面的设置到每个节点的config/elasticsearch.yml文件中：[code]action.auto_create_index: false将来，我们会讨论如何使用来预先定义自动生成的索引。这个功能在索引日志数据的时候有用武之地：索引的名字中会包含日期，每天都有一个有着合适配置的索引被自动地生成。删除索引使用下面的请求完成索引的删除：[code]DELETE /my_index[/code]你也可以删除多个索引：[code]DELETE /index_one,index_two
DELETE /index_*你甚至还可以删除所有的索引：[code]DELETE /_all索引设置虽然索引的种种行为可以通过介绍的那样进行配置，但是……TIPES中提供了一些很好的默认值，只有当你知道它是干什么的，以及为什么要去修改它的时候再去修改。两个最重要的设置：number_of_shards一个索引中含有的主分片(Primary Shard)的数量，默认值是5。在索引创建后这个值是不能被更改的。number_of_replicas每一个主分片关联的副本分片(Replica Shard)的数量，默认值是1。这个设置在任何时候都可以被修改。比如，我们可以通过下面的请求创建一个小的索引 - 只有一个主分片 - 同时没有副本分片：[code]PUT /my_temp_index{
"settings": {
"number_of_shards" :
"number_of_replicas" : 0
}}[/code]将来，我们可以动态地通过update-index-settings API完成对副本分片数量的修改：[code]PUT /my_temp_index/_settings{
"number_of_replicas": 1}[/code]配置解析器第三个重要的索引设置就是解析(Analysis)，可以利用已经存在的解析器(Analyzer)进行配置，或者是为你的索引定制新的解析器。在中，我们介绍了一些内置的解析器，它们用来将全文字符串转换成适合搜索的倒排索引(Inverted Index)。对于全文字符串字段默认使用的是standard解析器，它对于多数西方语言而言是一个不错的选择。它包括：standard分词器。它根据词语的边界进行分词。standard token过滤器。用来整理上一步分词器得到的tokens，但是目前是一个空操作(no-op)。lowercase token过滤器。将所有tokens转换为小写。stop token过滤器。移除所有的stopwords，比如a，the，and，is等默认下stopwords过滤器没有被使用。可以通过创建一个基于standard解析器的解析器并设置stopwords参数来启用。要么提供一个stopwords的列表或者告诉它使用针对某种语言预先定义的stopwords列表。在下面的例子中，我们创建了一个名为es_std的解析器，它使用了预先定义的西班牙语中的stopwords列表：[code]PUT /spanish_docs{
"settings": {
"analysis": {
"analyzer": {
"es_std": {
"standard",
"stopwords": "_spanish_"
}}[/code]es_std解析器不是全局的 - 它只作用于spanish_docs索引。可以通过制定索引名，使用analyze API进行测试：[code]GET /spanish_docs/_analyze?analyzer=es_std{
El veloz zorro marrón}[/code]下面的部分结果显示了西班牙语中的stopword El已经被正确地移除了：[code]{
"tokens" : [
{ "token" :
"position" : 2 },
{ "token" :
"position" : 3 },
{ "token" :
"marrón",
"position" : 4 }
]}[/code]自定义解析器(Custom Analyzers)虽然ES本身已经提供了一些解析器，但是通过组合字符过滤器(Character Filter)，分词器(Tokenizer)以及词条过滤器(Token Filter)来创建你自己的解析器才会显示出其威力。在中，我们提到过解析器(Analyzer)就是将3种功能打包得到的，它会按照下面的顺序执行：字符过滤器(Character Filter) 字符过滤器用来在分词前将字符串进行"整理"。比如，如果文本是HTML格式，那么它会含有类似&p&或者&div&这样的HTML标签，但是这些标签我们是不需要索引的。我们可以使用移除所有的HTML标签，并将所有的像?这样的HTML实体(HTML Entity)转换为对应的Unicode字符：?。分词器(Tokenizers) 一个解析器必须有一个分词器。分词器将字符串分解成一个个单独的词条(Term or Token)。在standard解析器中使用的，通过单词边界对字符串进行划分来得到词条，同时会移除大部分的标点符号。另外还有其他的分词器拥有着不同的行为。比如，它不会进行任何分词，直接原样输出。则只通过对空白字符进行划分来得到词条。而则根据正则表达式来进行分词。词条过滤器(Token Filter) 在分词后，得到的词条流(Token Stream)会按照顺序被传入到指定的词条过滤器中。词条过滤器能够修改，增加或者删除词条。我们已经提到了和，但是ES中还有许多其它可用的词条过滤器。会对单词进行词干提取来得到其词根形态(Root Form)。则会移除变音符号(Diacritics)，将类似于très的词条转换成tres。和会产生适用于部分匹配(Partial Matching)或者自动完成(Autocomplete)的词条。在中，我们会通过例子来讨论这些分词器和过滤器的使用场景和使用方法。但是首先，我们需要解释如何来创建一个自定义的解析器。创建一个自定义的解析器和上面我们配置es_std解析器的方式相同，我们可以在analysis下对字符过滤器，分词器和词条过滤器进行配置：PUT /my_index
"settings": {
"analysis": {
"char_filter": { ... custom character filters ... },
"tokenizer":
custom tokenizers
custom token filters
"analyzer":
custom analyzers
}比如，要创建拥有如下功能的解析器：使用html_strip字符过滤器完成HTML标签的移除。将&字符替换成" and "，使用一个自定义的mapping字符过滤器。"char_filter": {
"&_to_and": {
"mapping",
"mappings": [ "&=& and "]
}使用standard分词器对文本进行分词。使用lowercase词条过滤器将所有词条转换为小写。使用一个自定义的stopword列表，并通过自定义的stop词条过滤器将它们移除："filter": {
"my_stopwords": {
"stopwords": [ "the", "a" ]
}我们的解析器将预先定义的分词器和过滤器和自定义的过滤器进行了结合："analyzer": {
"my_analyzer": {
"char_filter":
[ "html_strip", "&_to_and" ],
"tokenizer":
"standard",
[ "lowercase", "my_stopwords" ]
}因此，整个create-index请求就像下面这样：PUT /my_index
"settings": {
"analysis": {
"char_filter": {
"&_to_and": {
"mapping",
"mappings": [ "&=& and "]
"filter": {
"my_stopwords": {
"stopwords": [ "the", "a" ]
"analyzer": {
"my_analyzer": {
"char_filter":
[ "html_strip", "&_to_and" ],
"tokenizer":
"standard",
[ "lowercase", "my_stopwords" ]
}}}创建索引之后，使用analyze API对新的解析器进行测试：GET /my_index/_analyze?analyzer=my_analyzer
The quick & brown fox得到的部分结果如下，表明我们的解析器能够正常工作：{
"tokens" : [
{ "token" :
"position" : 2 },
{ "token" :
"position" : 3 },
{ "token" :
"position" : 4 },
{ "token" :
"position" : 5 }
}我们需要告诉ES这个解析器应该在什么地方使用。我们可以将它应用在string字段的映射中：PUT /my_index/_mapping/my_type
"properties": {
"title": {
"analyzer":
"my_analyzer"
}类型和映射(Types and Mappings)在ES中的类型(Type)代表的是一类相似的文档。一个类型包含了一个名字(Name) - 比如user或者blogpost - 以及一个映射(Mapping)。映射就像数据库的模式那样，描述了文档中的字段或者属性，和每个字段的数据类型 -string，integer，date等 - 这些字段是如何被Lucene索引和存储的。在中，我们说一个类型就好比关系数据库中的一张表。尽管一开始这样思考有助于理解，但是对类型本身进行更细致的解释 - 它们到底是什么，它们是如何在Lucene的基础之上实现的 - 仍然是有价值的。Lucene是如何看待文档的Lucene中的文档包含的是一个简单field-value对的列表。一个字段至少要有一个值，但是任何字段都可以拥有多个值。类似的，一个字符串值也可以通过解析阶段而被转换为多个值。Lucene不管值是字符串类型，还是数值类型或者什么别的类型 - 所有的值都会被同等看做一些不透明的字节(Opaque bytes)。当我们使用Lucene对文档进行索引时，每个字段的值都会被添加到倒排索引(Inverted Index)的对应字段中。原始值也可以被选择是否会不作修改的被保存到索引中，以此来方便将来的获取。类型是如何实现的ES中的type是基于以下简单的基础进行实现的。一个索引中可以有若干个类型，每个类型又有它自己的mapping，然后类型下的任何文档可以存储在同一个索引中。可是Lucene中并没有文档类型这一概念。所以在具体实现中，类型信息通过一个元数据字段_type记录在文档中。当我们需要搜索某个特定类型的文档时，ES会自动地加上一个针对_type字段的过滤器来保证返回的结果都是目标类型上的文档。同时，Lucene中也没有映射的概念。映射是ES为了对复杂JSON文档进行扁平化(可以被Lucene索引)而设计的一个中间层。比如，user类型的name字段可以定义成一个string类型的字段，而它的值则应该被whitespace解析器进行解析，然后再被索引到名为name的倒排索引中。"name": {
"analyzer": "whitespace"
}避免类型中的陷阱由于不同类型的文档能够被添加到相同的索引中，产生了一些意想不到的问题。比如在我们的索引中，存在两个类型：blog_en用来保存英文的博文，blog_es用来保存西班牙文的博文。这两种类型中都有一个title字段，只不过它们使用的解析器分别是english和spanish。问题可以通过下面的查询反映：GET /_search
"query": {
"match": {
"title": "The quick brown fox"
}我们在两个类型中搜索title字段。查询字符串(Query String)需要被解析，但是应该使用哪个解析器：是spanish还是english？答案是会利用首先找到的title字段对应的解析器，因此对于部分文档这样做是正确的，对于另一部分则不然。我们可以通过将字段命名地不同 - 比如title_en和title_es - 或者通过显式地将类型名包含在字段名中，然后对每个字段独立查询来避免这个问题：GET /_search
"query": {
"multi_match": {
"The quick brown fox",
"fields": [ "blog_en.title", "blog_es.title" ]
}multi_match查询会对指定的多个字段运行match查询，然后合并它们的结果。以上的查询中对blog_en.title字段使用english解析器，对blog_es.title字段使用spanish解析器，然后对两个字段的搜索结果按照相关度分值进行合并。这个解决方案能够在两个域是相同数据类型时起作用，但是考虑下面的场景，当向相同索引中添加两份文档时会发生什么：类型user{ "login": "john_smith" }类型event{ "login": "" }Lucene本身不在意类型一个字段是字符串类型，而另一个字段是日期类型 - 它只是愉快地将它们当做字节数据进行索引。但是当我们试图去针对event.login字段进行排序的时候，ES需要将login字段的值读入到内存中。根据提到的，ES会将索引中的所有文档都读入，无论其类型是什么。取决于ES首先发现的login字段的类型，它会试图将这些值当做字符串或者日期类型读入。因此，这会产生意料外的结果或者直接失败。Tip 为了避免发生这些冲突，建议索引中，每个类型的同名字段都使用相同的映射方式。根对象(Root Object)映射的最顶层被称为根对象。它包含了：属性区域(Properties Section)，列举了文档中包含的每个字段的映射信息。各种元数据(Metadata)字段，它们都以_开头，比如_type，_id，_source。控制用于新字段的动态探测(Dynamic Detection)的设置，如analyzer，dynamic_date_formats和dynamic_templates。其它的可以用在根对象和object类型中的字段上的设置，如enabled，dynamic和include_in_all。属性(Properties)我们已经在和复杂核心字段类型(Complex Core Field Type)中讨论了对于文档字段或属性最为重要的三个设置：type：字段的数据类型，比如string或者date。index：一个字段是否需要被当做全文(Full text)进行搜索(analyzed)，被当做精确值(Exact value)进行搜索('not_analyzed')，或者不能被搜索(no)。analyzer：全文字段在索引时(Index time)和搜索时(Search time)使用的analyzer。我们会在后续章节中合适的地方讨论诸如ip，geo_point和geo_shape等其它字段类型。元数据：_source字段默认，ES会将表示文档正文的JSON字符串保存为_source字段。和其它存储的字段一样，_source字段也会在保存到磁盘上之前被压缩。这个功能几乎是总被需要的，因为它意味着：完整的文档在搜索结果中直接就是可用的 - 不需要额外的请求来得到完整文档_source字段让部分更新请求(Partial Update Request)成为可能当映射发生变化而需要对数据进行重索引(Reindex)时，你可以直接在ES中完成，而不需要从另外一个数据存储(Datastore)(通常较慢)中获取所有文档在你不需要查看整个文档时，可以从_source直接抽取出个别字段，通过get或者search请求返回调试查询更容易，因为可以清楚地看到每个文档包含的内容，而不需要根据一个ID列表来对它们的内容进行猜测即便如此，存储_store字段确实会占用磁盘空间。如果以上的任何好处对你都不重要，你可以使用以下的映射来禁用_source字段：PUT /my_index
"mappings": {
"my_type": {
"_source": {
"enabled":
}在一个搜索请求中，你可以只要求返回部分字段，通过在请求正文(Request body)中指定_source参数：GET /_search
{ "match_all": {}},
"_source": [ "title", "created" ]
}这些字段的值会从_source字段中被抽取出来并返回，而不是完整的_source。存储字段(Stored fields)除了将一个字段的值索引外，你还可以选择将字段的原始值(Original field value)进行store来方便将来的获取。有过使用Lucene经验的用户会使用存储字段来选择在搜索结果中能够被返回的字段。实际上，_source字段就是一个存储字段。在ES中，设置个别的文档字段为存储字段通常都是一个错误的优化。整个文档已经通过_source字段被保存了。使用_source参数来指定需要抽取的字段几乎总是更好的方案。元数据：_all字段在中我们介绍了_all字段：它是一个特殊的字段，将其它所有字段的值当做一个大的字符串进行索引。query_string查询语句(以及?q=john这种形式的查询)在没有指定具体字段的时候，默认搜索的就是_all字段。_all字段在一个新应用的探索阶段有用处，此时你对文档的最终结构还不太确定。你可以直接使用任何搜索字符串，并且也能够得到需要的结果：GET /_search
"match": {
"_all": "john smith marketing"
}随着你的应用逐渐成熟，对搜索要求也变的更加精确，你就会越来越少地使用_all字段。 _all字段是一种搜索的霰弹枪策略(Shotgun approach)。通过查询个别字段，你可以对搜索结果有更灵活，强大和细粒度的控制，来保证结果是最相关的。在中一个重要的考量因素是字段的长度：字段越短，那么它就越重要。一个出现在较短的title字段中的词条会比它出现在较长的content字段中时要更重要。而这个关于字段长度的差别在_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": {
"include_in_all": true
}需要记住的是，_all字段也只不过是一个被解析过的string字段。它使用默认的解析器来解析其值，无论来源字段中设置的是什么解析器。和任何string字段一样，你也可以配置_all字段应该使用的解析器：PUT /my_index/my_type/_mapping
"my_type": {
"_all": { "analyzer": "whitespace" }
}元数据：文档ID(Document Identity)和文档ID相关的有四个元数据字段：_id：文档的字符串ID_type：文档的类型_index：文档属于的索引_uid：_type和_id的结合，type#id默认情况下，_uid字段会被保存和索引。意味着它可以被获取，也可以被搜索。_type字段会被索引但不会被保存。_id和_index既不会被索引也不会被保存，也就是说它们实际上是不存在的。尽管如此，你还是能够查询_id字段，就好像它是一个实实在在的字段一样。ES使用_uid字段来得到_id。尽管你可以为这些字段修改index和store设置，但是你几乎不需要这么做。_id字段有一个你也许会用到的设置：path，它用来告诉ES：文档应该从某个字段中抽取一个值来作为它自身的_id。PUT /my_index
"mappings": {
"my_type": {
"path": "doc_id"
"properties": {
"doc_id": {
"not_analyzed"
}以上请求设置_id来源于doc_id字段。然后，当你索引一份文档：POST /my_index/my_type
"doc_id": "123"
}得到的结果是这样的：{
"my_index",
"my_type",
"_version": 1,
"created":
}警告这样做虽然很方便，但是它对于bulk请求(参考)有一些性能影响。处理请求的节点不能够利用优化的批处理格式：仅通过解析元数据行来得知哪个分片(Shard)应该接受该请求。相反，它需要解析文档正文部分。动态映射(Dynamic Mapping)当ES在文档中碰到一个以前没见过的字段时，它会利用动态映射来决定该字段的类型，并自动地对该字段添加映射。有时这正是需要的行为，但有时不是。你或许不知道在以后你的文档中会添加哪些字段，但是你想要它们能够被自动地索引。或许你只是想要忽略它们。或者 - 尤其当你将ES当做主要的数据存储使用时 - 大概你会希望这些未知的字段会抛出异常来提醒你注意这一问题。幸运的是，你可以通过dynamic设置来控制这一行为，它能够接受以下的选项：true：默认值。动态添加字段false：忽略新字段strict：如果碰到陌生字段，抛出异常dynamic设置可以适用在根对象上或者object类型的任意字段上。你应该默认地将dynamic设置为strict，但是为某个特定的内部对象启用它：PUT /my_index
"mappings": {
"my_type": {
"dynamic":
"properties": {
{ "type": "string"},
"dynamic":
}在my_type对象上如果碰到了未知字段则会抛出一个异常。 在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
"This throws a StrictDynamicMappingException",
"new_field": "Fail!"
}NOTE将dynamic设置为false并不会改变_source字段的内容 - _source字段仍然会保存你索引的整个JSON文档。只不过是陌生的字段将不会被添加到映射中，以至于它不能被搜索到。自定义动态映射如果你知道你需要动态的添加的新字段，那么你也许会启用动态映射。然而有时动态映射的规则又有些不够灵活。幸运的是，你可以调整某些设置来让动态映射的规则更加适合你的数据。date_detection当ES碰到一个新的字符串字段时，它会检查该字串是否含有一个可被识别的日期，比如。如果存在，那么它会被识别为一个date类型的字段。否则会将它作为string进行添加。有时这种行为会导致一些问题。如果你想要索引一份这样的文档：{ "note": "" }假设这是note字段第一次被发现，那么根据规则它会被作为date字段添加。但是如果下一份文档是这样的：{ "note": "Logged out" }这时该字段显然不是日期，但是已经太迟了。该字段的类型已经是日期类型的字段了，因此这会导致一个异常被抛出。可以通过在根对象上将date_detection设置为false来关闭日期检测：PUT /my_index
"mappings": {
"my_type": {
"date_detection": false
}有了以上的映射，一个字符串总是会被当做string类型。如果你需要一个date字段，你需要手动地添加它。NOTEES中识别日期的方法可以通过改变。dynamic_templates通过dynamic_templates，你可以拥有对新字段的动态映射规则拥有完全的控制。你设置可以根据字段名称或者类型来使用一个不同的映射规则。每个模板都有一个名字，可以用来描述这个模板做了什么。同时它有一个mapping用来指定具体的映射信息，和至少一个参数(比如match)用来规定对于什么字段需要使用该模板。模板的匹配是有顺序的 - 第一个匹配的模板会被使用。比如我们可以为string字段指定两个模板：es：以_es结尾的字段应该使用spanish解析器en：其它所有字段使用english解析器我们需要将es模板放在第一个，因为它相比能够匹配所有字符串字段的en模板更加具体：PUT /my_index
"mappings": {
"my_type": {
"dynamic_templates": [
"match_mapping_type": "string",
"mapping": {
"analyzer":
"match_mapping_type": "string",
"mapping": {
"analyzer":
}}}match_mapping_type允许你只对特定类型的字段使用模板，正如标准动态映射规则那样，比如string，long等。match参数只会匹配字段名，path_match参数用于匹配对象中字段的完整路径，比如address.*.name可以匹配如下字段：{
"address":
"name": "New York"
}unmatch和path_unmatch模式能够用来排除某些字段，没有被排除的字段则会被匹配。更多的配置选项可以在中找到。默认映射(Default Mapping)一般情况下，索引中的所有类型都会有相似的字段和设置。因此将这些常用设置在_default映射中指定会更加方便，这样就不需要在每次创建新类型的时候都重复设置。_default映射的角色是新类型的模板。所有在_default映射之后创建的类型都会包含所有的默认设置，除非显式地在类型映射中进行覆盖。比如，我们使用_default映射对所有类型禁用_all字段，唯独对blog类型启用它。可以这样实现：PUT /my_index
"mappings": {
"_default_": {
"_all": { "enabled":
"_all": { "enabled":
}_default_映射同时也是一个声明作用于整个索引的动态模板(Dynamic Templates)的好地方。数据重索引虽然你可以向索引中添加新的类型，或者像类型中添加新的字段，但是你不能添加新的解析器或者对现有字段进行修改。如果你这么做了，就会让已经索引的数据变的不正确，导致搜索不能正常的进行。为已经存在的数据适用这些更改的最简单的方法就是重索引(Reindex)：新建一个拥有最新配置的索引，然后将所有旧索引中的数据拷贝到新的索引中。_source字段的一个优势是在ES中你已经拥有了整个文档。你不需要通过数据库来重建你的索引，这种方法通常会更慢。为了从旧索引中高效地对所有文档进行重索引，可以使用来批量地从旧索引中获取文档，然后使用bulk API将它们添加到新索引中。批量重索引你可以同时执行多个重索引任务，但是你显然不想要它们的结果有任何重叠。可以根据date或者timestamp字段对重索引的任务进行划分，成为规模较小的任务：GET /old_index/_search?search_type=scan&scroll=1m
"query": {
"range": {
}如果你正在持续地更改旧索引中的数据，想必你也希望这些更改也会被反映到新索引中。这可以通过再次运行重索引任务来完成，但是还是可以通过对日期字段进行过滤来得到在上次重索引开始后才被添加的文档。索引别名和零停机时间(Index Alias and Zero Downtime)重索引的问题在于你需要更新你的应用让它使用新的索引名。而索引别名可以解决这个问题。一个索引别名就好比一个快捷方式(Shortcut)或一个符号链接(Symbolic Link)，索引别名可以指向一个或者多个索引，可以在任何需要索引名的API中使用。使用别名可以给我们非常多的灵活性。它能够让我们：在一个运行的集群中透明地从一个索引切换到另一个索引让多个索引形成一个组，比如last_three_months为一个索引中的一部分文档创建一个视图(View)我们会在本书的后面讨论更多关于别名的其它用途。现在我们要解释的是如何在零停机时间的前提下，使用别名来完成从旧索引切换到新索引。有两个用来管理别名的端点(Endpoint)：_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": {
"not_analyzed"
}紧接着，我们会根据中的流程将my_index_v1中的数据重索引到my_index_v2。一旦我们确定了文档已经被正确地索引，我们就能够将别名切换到新的索引上了。一个别名能够指向多个索引，因此当我们将别名指向新的索引时，我们还需要删除别名原来到旧索引的指向。这个改变需要是原子的，即意味着我们需要使用_aliases端点：POST /_aliases
"actions": [
{ "remove": { "index": "my_index_v1", "alias": "my_index" }},
{ "index": "my_index_v2", "alias": "my_index" }}
}现在你的应用就在零停机时间的前提下，实现了旧索引到新索引的透明切换。TIP即使你认为当前的索引设计是完美的，将来你也会发现有一些部分需要被改变，而那个时候你的索引已经在生产环境中被使用了。在应用中使用索引别名而不是索引的真实名称，这样你就能够在任何需要的时候执行重索引操作。应该充分地使用别名。原文来自：
原文翻译自：
如果您想留下此文，您可以将其发送至您的邮箱(将同时以邮件内容&PDF形式发送)
相关文章推荐
(Ctrl+Enter提交) &&
已有0人在此发表见解
&在& 14:48收藏到了
&&在信息爆炸的时代，您的知识需要整理，沉淀，积累！Lai18为您提供一个简单实用的文章整理收藏工具，在这里您可以收藏对您有用的技术文章，自由分门别类，在整理的过程中，用心梳理自己的知识！相信，用不了多久，您收藏整理的文章将是您一生的知识宝库！
· 蜀ICP备号-1