Elasticsearch shrink and rollover api

用shrink和rollover api 高效管理基于时间的索引

创建索引时要先定义分片的数量， 在索引创建完之后将无法增加或减少分片的数量

分片越多，索引吞吐量越大，查询速度越慢，需要的资源越多

随着数据的增长，扩容将成为必须，上面这两个问题就会成为集群的性能和管理的超级障碍

假设每天都要为日志创建一个包含5个分片的索引，那这个行为每年都会创建出 1825 个分片来。 而且，假如不会再查询旧索引，那么在集群中保存那么多分片就没有意义了。

shrink API

shrink API 可以让用户将一个现有索引的朱分片减少，最终生成一个 新索引

收缩的过程

首先创建一个与源索引有相同定义的目标索引，但是主分片数会更少

然后创建硬连接，将源索引中的段连接到目标索引 （如果文件系统不支持硬连接，就把所有段拷贝到新索引中，这样的过程当然会更耗时）

最后对目标索引执行恢复流程，就好像它是一个已经关闭了的索引，现在刚刚被再次打开一样

多匹配类型

best_fields 从多字段中，找一个评分最高的
most_fields 为每一个字段评分，把所有评分综合考虑
cross_fields 把所有字段当做一个大字段考虑
phrase 匹配词组
phrase_prefix

1.最佳字段(Best fields):

指的就是搜索结果中应该返回某一个字段匹配到了最多的关键词的文档。

2.多数字段(Most fields):

一个用来调优相关度的常用技术是将相同的数据索引到多个字段中。它用来尽可能多地匹配文档。

ES会为每个字段生成一个match查询，然后将它们包含在一个bool查询中。

指的就是搜索结果应该返回匹配了更多的字段的document优先返回回来。

most_fields 会告诉 Elasticsearch 合并所有匹配字段的评分：

most_fields 方式的问题

用 most_fields 这种方式搜索也存在某些问题，这些问题并不会马上显现：

• 它是为多数字段匹配 任意 词设计的，而不是在 所有字段 中找到最匹配的。
• 它不能使用 operator 或 minimum_should_match 参数来降低次相关结果造成的长尾效应。
• 词频对于每个字段是不一样的，而且它们之间的相互影响会导致不好的排序结果。

3.跨字段(Cross fields):

对于一些实体，标识信息会在多个字段中出现，每个字段中只含有一部分信息：

• Person: first_name 和 last_name
• Book: title, author, 和 description
• Address: street, city, country, 和 postcode

此时，我们希望在任意字段中找到尽可能多的单词。我们需要在多个字段中进行查询，就好像这些字段是一个字段那样。

指的是一个唯一标识，跨域了多个字段，它将所有的字段视为一个大的字段，然后在任一字段中搜索每个词条

match_phrase

比如，有如下查询

{
    “match”: {
        “content”: “java spark”
    }
}

match query，只能搜索到包含java和spark的document，但是不知道java和spark是不是离的很近。

如果希望搜索java spark，中间不能插入任何其他的字符，那这个时候match去做全文检索是无法做到的，此时需要使用match_phrase 

slop

要经过几次移动才能与一个document的field中的匹配，这个移动的次数，就是slop

match_phrase_prefix

原理跟match_phrase类似，唯一的区别，就是把最后一个term作为前缀去搜索

hello就是去进行match，搜索对应的doc
w，会作为前缀，去扫描整个倒排索引，找到所有w开头的doc
然后找到所有doc中，即包含hello，又包含w开头的字符的doc

Elasticsearch 中的数据建模方法

要想让查询速度更快，让更新更容易而且代价更小，定义数据结构是要解决的关键问题之一。

扁平式结构

在扁平式结构中，用简单的键值对索引文档，有时候也用简单对象的形式，这些最简单最快。

数据存储成这种格式就可以 索引更快，也可以查询更快。

但是这样索引文档会导致难以维护不同实体之间的关系，因为Elasticsearch并不知道实体时间应该是怎样的关系。

使用扁平结构之后，就经常要在应用程序中做关联，以发现文档之间的关系。

数据反范式化

即把其他文档内的相关字段多复制一份，目的只是为了维护实体之间的关系。

这种方法可以用来维护扁平式结构，也可以通过在没分文档中多保存一到多个字段来维护它们之间的关系，但是会占用大量空间

嵌套与父子关系

这些关系是 Elasticsearch 为管理关系型数据而自带的解决方案

Elasticsearch 性能优化

Elasticsearch 提供了专门的 _validate REST 端点来验证查询，并且不会真正的执行它们。

获得详细查询执行报告的查询分析器

通过 Profile API 用户可以了解查询请求在底层是怎样执行的

profile.shard.id 响应中包含的每个分片的唯一 ID

  "profile" : {
    "shards" : [
      {
        "id" : "[esdfsdfgdfghsdf-40jfQ][.apm-agent-configuration][0]",
        "searches" : [
          {
            "query" : [
              {
                "type" : "MatchNoDocsQuery",
                "description" : """MatchNoDocsQuery("unmapped fields [org]")""",
                "time_in_nanos" : 1229,

profile.shard.searches 包含查询执行详细信息的数组

profile.shard.rewrite_time 一次完整的查询改写过程所花费的总时间，单位是 纳秒

profile.shard.collector 这一部分是关于运行查询的 Lucene 收集器的内容

Lucene的工作实际上是定义一个收集器，负责协调对所匹配文档的遍历、评分和收集。收集器的内容也包括一个查询如何记录聚合结果、执行全局查询、执行查询后的过滤器等。

热点线程

通过使用

/_nodes/hot_threads 或者 /_nodes/{nodeornodes}/hot_threads 端点

http://172.16.184.194:9200/_nodes/hot_threads

自动创建副本

Elasticsearch 允许在集群足够大时自动扩展副本

index.auto_expand_replicas 0-all

冗余和高可用

Elasticsearch 的副本机制不仅可以处理更高的查询吞吐量，同时也给了冗余和高可用。

防止分片及其副本部署在同一个节点上

elasticsearch.yml 文件中设置如下

node.attr.server_name: server1

另外再添加

cluster.routing.allocation.awareness.attributes: server_name

这告诉 Elasticsearch 不要把主分片 和 它的副本放到具有相同 node.attr.server_name 属性的节点上

集群节点角色

Elasticsearch 在任意给定时间只需要一个主节点，如果有3个master节点，通过设置

discovery.zen.minimum_master_nodes: 2 

可以防止脑裂

ELasticsearch 优化的一般建议

索引刷新频率

索引刷新频率是指 文档需要多长时间才能出现在结果中

规则非常简单：刷新率越高，查询越慢，且索引文档的吞吐量月底

刷新率默认是 1秒，这基本上意味着索引查询器每隔1秒重新打开一次

刷新率为 1秒 时，使用一个Elasticsearch节点大概每秒能够索引 1000份文档。

刷新率为 5秒 时，索引吞吐量可以提升 25%，大概每秒 1280 份文档

刷新率为 25秒 时，索引量可以提升超过 70%，大概每秒 1700份文档

无限制地增加刷新时间是没有意义的，因为超过某一定值（取决于负载和数据量）之后，性能提升将变得微乎其微。

线程池调优

只有遇到

节点的队列已经被填满，并且仍有计算能力剩余，而且这些算力可以被用于处理等待的作业

时，才需要考虑调整默认的线程池配置

数据分布

Elasticsearch 的每个索引都可以被分成多个分片，并且每个分片都有多个副本。

当有若干个 Elasticsearch节点，并且索引被分割成多个分片时，数据的平均分布对于平衡集群的负载就是十分重要的了，不要让某些节点做了比其他节点多太多的工作。

节点查询缓存和分片查询缓存

第一个有助于查询性能的缓存是 节点查询缓存

Elasticsearch 的节点查询缓存会在一个节点上的全部索引间共享，可以使用

indices.queries.cache.size

属性来控制缓存的大小

它表示在给定节点上能够被节点查询缓存使用的全部内存数量，默认是 10%

如果查询已经使用了过滤器，就应该监控缓存的大小和逐出。

如果看到了过多的逐出，那么缓存可能太小了，应该考虑增加缓存的大小。

缓存过小可能会对查询的性能造成负面影响

第二个缓存是分片查询缓存

分片缓存的目的是 缓存 聚合、建议器 和 命中数 （它不会缓存返回的文档，因此，只在查询的size=0时起作用）
当查询使用了聚合或者建议时，最好启用这个缓存（默认是关闭的）

index.requests.cache.enable：true

请记住如果不使用聚合或者建议器，那么使用分片查询缓存就毫无意义

常见的聚合一般是 max min sum avg

分片查询缓存默认使用的内存量，默认不会超过分配给 Elasticsearch 节点的 JVM 堆栈的 1%。

indices.requests.cache.size

要修改默认的缓存过期时间

indices.requests.cache.expire

适当使用过滤器

不使用过滤器

GET /_search
{
    "query": {
        "bool": {
            "must": [{
                "match": {
                    "org": "男性用"
                }
            }, {
                "match": {
                    "store_code": "0696"
                }
            }]
        }
    }
}

使用 term 避免分词

GET /_search
{
    "query": {
        "bool": {
            "must": [{
                "match": {
                    "org": "男性用"
                }
            }, {
                "term": {
                    "store_code": "0001"
                }
            }]
        }
    }
}

使用过滤器

GET /_search
{
    "query": {
        "bool": {
            "must": [{
                "match": {
                    "org": "男性用"
                }
            }],
            "filter": [
              {
                "term": {
                    "store_code": "0002"
                }
              }
            ]
        }
    }
}

使用filter子句来引入过滤器，把绝大多数静态的、不分词的字段移动到过滤器里

这使得很容易在执行下一次查询时重用它们，并且避免对这些字段进行评分。

使用路由

如果数据支持路由，那么就应该考虑在查询的时候也使用路由

有着相同路由值的数据都会被保存到相同的分片上。

于是，可以避免在请求特定数据时查询所有的分片。

例如：如果保存客户的数据，可以使用客户 ID 作为路由。这会允许把同一客户的数据保存在同一个分片里。

在不使用路由的情况下，Elasticsearch 会先搜索全部的索引分片。

如果索引包含数十个分片，只要单个Elasticsearch 实例还能容纳得下分片的数据，使用路由对性能提升就会非常明显

不是每种情况都适合使用路由。

想要使用，首先数据需要是可分割的，这样它们才能够分布在不同的分片上。

例如，拥有十个非常小的分片 和 一个庞大的分片 是没有意义的，因为这个庞大的分片性能不会很好

将查询并行起来

通常被忘记的一件事是并行查询。

假设集群中有一个 索引，只保存在一个分片上。如果索引很大，查询性能可能比期望的要差。

如果增加副本数量不会有什么帮助，因为一个查询还是只会在索引的一个分片上执行

真正有帮助的是，把索引分割成多个分片，分片的数量取决于硬件和部署的方式

一般来说，建议把数据平均分配，于是各个节点可以有相同的负载。

例如，4个Elasticsearch节点和2个索引，可以设置成4个分片

size 和 shard_size

在处理 使用聚合的查询时，对于某些查询可以使用两个属性 size 和 shard_size

size参数定义最后的 聚合结果 返回多少组 数据

聚合最终结果的节点会从每个返回结果的分片获取靠前的结果，并且只会返回前size个结果给客户端

shard_size 参数具有相同的含义，只是它作用在分片上。 增加 shard_size 会让聚合结果更加准确(比如重点词的聚合)，代价是更大的网络开销和内存使用。

降低这个参数会让聚合的结果不那么精确，但却有着网络开销小和内存使用低的好处

高索引吞吐量场景与Elasticsearch

关系到 每秒可以向Elasticsearch推送多少数据，另一些是索引相关的

批量索引的线程池 默认等于 CPU 核数，另有一个大小为 50 的请求队列

当逐个索引文档时，每秒能稳定的索引大约30份文档

以 10 为批量索引时，每秒大约能处理200份文档

掌控文档的字段

要索引的数量不同，效果也不同

文档的大小 和 对它们的解析度也同样重要

对于较大的文档，不仅能够看到索引增长，还能看到索引的速度有所减慢。

要让存储的字段尽可能的少，或者完全不要使用它们，大多数情况下，需要存储的字段只是 _source

除了 _source 字段，Elasticsearch 会默认索引 _all 字段。

_all 字段 是 ELasticsearch 用来从其他文本字段收集数据的。大多数场景下，这个字段不会被使用，因此最好关闭它。

"all_": {"enable": false}

ElasticSearch 有两个内部结构_all和_source

_all是所有字段的大杂烩,默认情况下,每个字段的内容,都会拷贝到_all字段.
这样可以忽略字段信息进行搜索,非常方便.
但是这样带来了额外的存储压力和CPU处理压力.

_source字段用于存储最初发送给elasticsearch的整个源文档。它用作搜索结果，可供检索。您无法搜索。实际上，它是在Lucene中存储的字段，未进行索引。

_all字段用于索引来自文档组成的所有字段的所有内容。您可以搜索它，但永远不要返回它，因为它已被索引但没有存储在lucene中。

_all字段成为我们所谓的倒排索引的一部分，用于为文本建立索引，并能够对其进行全文搜索，而该_source字段只是作为lucene文档的一部分存储

_source仅当您返回结果时，您才永远不会在查询中使用该字段，因为这是默认情况下Elasticsearch返回的结果

另一方面，该_all字段只是默认的“全部捕获”字段，您可以在只想搜索所有可用字段而又不想在查询中全部指定它们时使用。它很方便，但我不会在生产中过分依赖它，最好在不同的字段上运行更复杂的查询，每个字段具有不同的权重。如果您不使用它，则可能要禁用它，与_source我认为禁用它相比，其影响要小一些。

_source字段默认是存储的， 什么情况下不用保留_source字段？如果某个字段内容非常多，业务里面只需要能对该字段进行搜索，最后返回文档id，查看文档内容会再次到mysql或者hbase中取数据，把大字段的内容存在Elasticsearch中只会增大索引

调整预写日志

• ELasticsearch 有一个内部模块叫做 translog

一个文档被索引之后，就会被添加到内存缓冲区，并且 追加到了 translog

• 分片每秒被刷新（refresh）一次，

这些在内存缓冲区的文档被写入到一个新的段中，且没有进行 fsync 操作。

这个段被打开，使其可被搜索。

内存缓冲区被清空。

• 每隔一段时间—​例如 translog 变得越来越大—​索引被刷新（flush）；一个新的 translog 被创建，并且一个全量提交被执行

所有在内存缓冲区的文档都被写入一个新的段。

缓冲区被清空。

一个提交点被写入硬盘。

文件系统缓存通过 fsync 被刷新（flush）。

老的 translog 被删除。

translog 提供所有还没有被刷到磁盘的操作的一个持久化纪录。当 Elasticsearch 启动的时候， 它会从磁盘中使用最后一个提交点去恢复已知的段，并且会重放 translog 中所有在最后一次提交后发生的变更操作。

translog 也被用来提供实时 CRUD 。当你试着通过ID查询、更新、删除一个文档，它会在尝试从相应的段中检索之前， 首先检查 translog 任何最近的变更。这意味着它总是能够实时地获取到文档的最新版本。

ELasticsearch 默认在事务日志中保留最多5000个操作，或者最多占用512MB空间

如果愿意付出更大的索引吞吐量，愿意付出数据在更长时间不能被索引到的代价，可以调高这些默认值

index.translog.flush_threshold_ops

index.translog.flush_threshold_size

两者都是在索引级别生效，并能通过ELasticsearch API 实时更新

一旦发生事故，对于拥有大量事务日志的节点来说，它的分片的初始化会慢一些，这是因为ELasticsearch需要在分片生效前处理完 全部的事务日志

可供索引缓存使用的内存越多，ELasticsearch 在内存中容纳的文档就越多

indices.memeory.index_buffer_size 

默认会使用10%

这是设置节点的，而不是分片。

所以如果给Elasticsearch节点 分配 20GB 堆空间，并且节点上有 10个 活动分片，那么 Elasticsearch 默认会给每个分片大约 200MB

Elasticsearch 查询与分片

匹配一个值，且输入的值不会被分词器分词

{
    "query":{
        "term":{
            "foo": "hello world"
        }
    }
}

文本“I say hello world”会被分词进行存储，不会存在“hello world”这整个词，那么不会返回任何值

但是如果使用“hello”作为查询条件，则只要数据中包含“hello”的数据都会被返回，分词对这个查询影响较大。

match_phase习语匹配，查询确切的phase，在对查询字段定义了分词器的情况下，会使用分词器对输入进行分词，然后返回满足下述两个条件的document:

　　1.match_phase中的所有term都出现在待查询字段之中

　　2.待查询字段之中的所有term都必须和match_phase具有相同的顺序

{ "foo":"I just said hello world" }
 
{ "foo":"Hello world" }
 
{ "foo":"World Hello" }

前两条会被命中

模糊匹配，先对输入进行分词，对分词后的结果进行查询，文档只要包含match查询条件的一部分就会被返回

9200作为Http协议，主要用于外部通讯

9300作为Tcp协议，jar之间就是通过tcp协议通讯

ES集群之间是通过9300进行通讯

Elasticsearch config 目录下的

jvm.options 文件

-Xms1g

-Xmx1g

默认的堆大小（最大和最小都是）为 2GB

默认配置为 5 个分片 1个副本

最理想的分片数量应该依赖于节点数量

因此，如果计划将来使用10个节点，那么就给索引配置10个分片。

为了保证 高可用 和 查询吞吐量，需要配置副本，如果副本量为 1

最终会生成 20 个分片，10个主分片，10个从分片（10个副本)

所需最大节点数 = 分片数 * （副本数+1）

20 = 10 * （1+1）

Elasticsearch一个分片实际上是一个 Lucene 索引

更多的分片意味着每个较小的 Lucene 索引上执行的操作会更快（尤其是索引过程）。

有时，这是一个很好的理由去使用更多的分片。

当然，将查询拆散成对每个分片的请求然后再合并结果，这也是有代价的。

这个对于 使用具体的参数来过滤 查询的应用程序是可以避免的。这时需要使用路由

拥有多个分片 和 拥有多个索引 有什么不同？

从技术上讲，他们的区别不大

默认情况下，Elasticsearch 只为每个索引分片创建一个副本

不同于分片的数量，副本的数量可以通过相关的API 随时更改。

使用副本可以应对不断增长的并发查询，
增加副本数量可以让查询负载分散到更多机器上

该功能能让构建

– index 体现了逻辑空间的概念，是一个逻辑意义上的聚合。
– shard 分片体现了物理空间的观念，索引中的数据具体存放的地方。

一个 Elasticsearch 集群可以 包含多个 索引 ，相应的每个索引可以包含多个 类型 。 这些不同的类型存储着多个 文档 ，每个文档又有 多个 属性

使用分片能够存储超过单节点容量限制的数据

使用副本则解决了 日渐增长的 吞吐量、高可用 和 容错 的问题

使用过多副本的缺点也很明显，占用存储空间 和 构建副本的开销，主从分片 以及 副本之间的数据同步也存在开销

{ "foo":"I just said hello world" }
 
{ "foo":"Hello world" }
 
{ "foo":"World Hello" }

• match query知道分词器的存在，会对filed进行分词操作，然后再查询
• match_all:查询所有文档

返回所有

GET _search
{
  "query":{"match_all":{"boost":"1.2"}}
}

还可以加boost

GET _search
{
  "query":{"match_all":{"boost":"1.2"}}
}

• multi_match:可以指定多个字段

GET _search
{
  "query": {
    "multi_match": {
      "query": "の",
      "type": "best_fields",
      "fields": [
        "title",
        "content"
      ],
      "tie_breaker": 0.3,
      "minimum_should_match": "30%"
    }
  }
}

• match_phrase:短语匹配查询，ElasticSearch引擎首先分析（analyze）查询字符串，从分析后的文本中构建短语查询，这意味着必须匹配短语中的所有分词，并且保证各个分词的相对位置不变

{
  "query": {
    "match_phrase": {
      "foo": "Hello World"
    }
  }
}

会返回前两条

返回版本号，并且控制 size

GET _search
{
  "version":true,
  "from":0,
  "size":1,
  "query": {
    "multi_match": {
      "query": "の",
      "type": "best_fields",
      "fields": [
        "org",
        "voice_type"
      ],
      "tie_breaker": 0.3,
      "minimum_should_match": "30%"
    }
  }
}

指定返回的字段

GET _search
{
  "version":true,
  "from":0,
  "size":1,
  "_source":["ask_type","post_date_time"],
  "query": {
    "multi_match": {
      "query": "の",
      "type": "best_fields",
      "fields": [
        "org",
        "voice_type"
      ],
      "tie_breaker": 0.3,
      "minimum_should_match": "30%"
    }
  }
}

text类型

1:支持分词，全文检索,支持模糊、精确查询,不支持聚合,排序操作;
2:text类型的最大支持的字符长度无限制,适合大字段存储；
使用场景：
    存储全文搜索数据, 例如: 邮箱内容、地址、代码块、博客文章内容等。
    默认结合standard analyzer(标准解析器)对文本进行分词、倒排索引。
    默认结合标准分析器进行词命中、词频相关度打分。

keyword

GET /_search
{
  "query": {
    "match": {
      "org": "男性用"
    }
  },
  "sort":[
      {
        "store_code.keyword":{
          "order":"desc", 
          "unmapped_type" : "long"
        }
      }
    ]
}

1:不进行分词，直接索引,支持模糊、支持精确匹配，支持聚合、排序操作。
2:keyword类型的最大支持的长度为——32766个UTF-8类型的字符,可以通过设置ignore_above指定自持字符长度，超过给定长度后的数据将不被索引，无法通过term精确匹配检索返回结果。

使用场景：
存储邮箱号码、url、name、title，手机号码、主机名、状态码、邮政编码、标签、年龄、性别等数据。
用于筛选数据(例如: select * from x where status='open')、排序、聚合(统计)。
直接将完整的文本保存到倒排索引中。

Dynamic

dynamic属性：默认值为true，允许动态地向文档类型中加入新的字段。推荐设置为false，禁止向文档中添加字段，这样，文档类型的所有字段必须在索引映射的properties属性中显式定义，在properties字段中未定义的字段都将会ElasticSearch忽略。
dynamic设置为ture：默认值，新增加的字段被添加到索引映射中；
dynamic设置为false：新增加的字段会被忽略；
dynamic设置为strict：当向文档中新增字段时，ElasticSearch引擎抛出异常；

GET /_search
{
    "query": {
        "wildcard": {
             "store_name": "*店"
        }
    }
}

允许使用通配符* 和 ?来进行查询
*代表0个或多个字符
？代表任意一个字符

term query会去倒排索引中寻找确切的term，它并不知道分词器的存在。这种查询适合keyword 、numeric、date。

term:查询某个字段里含有某个关键词的文档

terms:查询某个字段里含有多个关键词的文档

a、term 和 terms 是 包含（contains） 操作，而非 等值（equals） （判断）

b、不知道分词器的存在，所以不会去分词，

c、所谓的包含是文档分词结果某个分词是否相等，即文档是否包含这个分词

d、因为是在分词结果中匹配，所以大写要转换为小写，大写字母是匹配不到

GET /_search
{
  "query":{"term":{ "country_code.keyword":"JP"}}
}

GET /_search
{
  "query":{"terms":{ "country_code.keyword":["JP","US"]}}
}

fuzzy 查询是 term 查询的模糊等价。

a、是 包含（contains） 操作，而非 等值（equals） （判断）。

b、不知道分词器的存在，所以不会去分词，

c、所谓的包含是文档分词结果某个分词是否包含，不是整个文档是否包含

d、因为是在分词结果中匹配，所以大写要转换为小写，大写字母是匹配不到

value：查询的关键字
boost：查询的权值，默认值是1.0
min_similarity:设置匹配的最小相似度，默认值为0.5，对于字符串，取值为0-1(包括0和1);对于数值，取值可能大于1;对于日期型取值为1d,1m等，1d就代表1天
prefix_length:指明区分词项的共同前缀长度，默认是0
max_expansions:查询中的词项可以扩展的数目，默认可以无限大

GET /_search
{
  "query":{"fuzzy":{ "store_name":"店"}}
  , "highlight": {"fields": {"store_code": {}}}
}

Elasticsearch 核心概念

Lucene中，查询 query 通常被分割为 词项 与 操作符

Lucene中的词项可以是单个词，也可以是一个短语（用双引号括起来的一个词组）

如果查询被设置为要被分析，那么预先选定的分析器将会对查询中的所有词项进行处理

Lucene 中所有数据都存储在 字段 field 中，而字段又是文档的组成单位。

为了实现针对某个字段的查询，用户需要提供字段名称，再加上 冒号 以及 将要对该字段执行查询的从句。

title：Elasticsearch

Elasticsearch 基本概念

Elasticsearch 存储数据的逻辑名字空间，在有分片和副本的情况下可能由一个或多个Lucene索引构成

文档就是 JSON 对象，包含的实际数据 由 键值对 构成。

一旦某个字段上生成了索引，Elasticsearch 就会为那个字段创建一个数据类型，从2.x 版本开始，都会进行严格的类型检查

文档类型代表了一类相似的文档。

类型有两个重要组成部分，一是 名字，二是 字段的数据类型 和 Lucene 配置之间的映射关系

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

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

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

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

运行在 服务器 上的单个 Elasticsearch 服务实例被称为 节点

1. 数据节点

用来存储数据，同时提供对这些数据的搜索功能

2. 主节点

作为监督者控制其他节点的工作

3. 客户端节点

用于查询路由

4. 部落节点

在Elasticsearch1.0版引入的部落节点，可以像桥梁一样将多个集群关联起来，允许在多个集群之上执行几乎所有可以在单集群Elasticsearch上执行的功能

5. Ingest 节点

可用于在构建索引之前，先进行简单的数据转换和处理。

任意一个节点都可以配置成 ingest 节点，而且非常轻量级。

Ingest 节点就是一个Java版的Logstash过滤器，而且是ELasticsearch自带的。

分片就是可以存储在一个 或者 多个节点上的 容器

由 Lucene 段 组成，索引由一个到多个 分片 组成 ，让数据可以分不开。

分片的数量在索引创建时就配置好了，之后无法增减。

分片也有主从之分。

所有改动索引的操作都发生在 主分片上，从分片的数据由主分片复制而来，支持数据快速检索和高可用。如果主分片所在的服务器宕机了，从分片会自动升级为主分片。

副本是为了支持高可用而保存在分片上的另一份数据。副本也有助于提供快速检索

查询在协调节点上进行解析，并用二进制格式序列化到不同节点上。

饱和度是用于限制 词频 在具体文档中的影响的参数。

通过调节参数 k 可以调节词频的影响。

TF-IDF 中饱和度是没有限制的，尽管公式中已经用词频的平方根与对数值相乘，在文档中出现频率更高的词项总会得到更高的 权重。

BM25中引入 k1作为饱和度参数，这样就解决了这个问题

为什么说 BM25 比 TF-IDF 更好一些

饱和点

在 TF-IDF 中由饱和度引起的评分问题：

如果你的布尔查询条件中的 N 个词项里，某一个词项在某份文档中出现了许多次

那么，这份文档的评分就会极高，因为它的词项饱和度 sqrt （termFreq）很弱 。

如果 x or y 是查询条件，而某份文档中 有 1000 个 x 和 0 个 y ， TF-IDF 不会考虑 y 从没有出现过，仍然会给它极高的分数。

协调因子 coord 就是用来弱化这种行为的

BM25 天生喜欢那些尽量多的查询词项都出现过的文档

因为它提供了参数 k1 ， 可以对词项饱和度提供更有力的控制。

即使查询条件中的某个词出现了很多次，它所增加的分数也远比不上另一个词项出现的次数从 0 变为 1

文档平均长度

TF-IDF 和 BM25 的另一个显著区别是 BM25 也考虑了文档长度的影响。

例如在 1000个词的文档中，旅行 这个词出现了 一两次，那它的内容与旅行应该没有太大关系。但是如果 旅行 这个词 在一篇很短的推文中就出现了两次，那这篇推文肯定和旅行有很大关系。

BM25 针对这种情况进行了补偿，引入了调节参数 b， 文档长度 dl，平均文档长度 avdl 等来调节词项因子

Elasticsearch Lucene索引的基本概念

Lucene索引的基本概念

在 Elasticsearch 中，术语 文档 有着特定的含义。它是指最顶层或者根对象, 这个根对象被序列化成 JSON 并存储到 Elasticsearch 中，指定了唯一 ID

文档可以被索引

{
    "name":         "John Smith",
    "age":          42,
    "confirmed":    true,
    "join_date":    "2014-06-01",
    "home": {
        "lat":      51.5,
        "lon":      0.1
    },
    "accounts": [
        {
            "type": "facebook",
            "id":   "johnsmith"
        },
        {
            "type": "twitter",
            "id":   "johnsmith"
        }
    ]
}

_index文档在哪存放

_type文档表示的对象类别

_id文档唯一标识

上面文档中包含字段

name、age、confirmed

注意字段对应的类型，可能是 字符串、布尔、数字等

倒排索引里，记录的是由 词项–>文档x,文档y,…文档z的这么一种关系，是一种反向的信息

词项是搜索时的一个单位

{
	"query": {
		"term": {
			"title": "程序"
		}
	}
}

{
	"query": {
		"terms": {
			"title": ["程序","性能"]
		}
	}
}
查询title字段中包含 “程序” 或者 “性能”的文档

词项在字段中的一次出现

{
  "tokens": [
    {
      "token": "orj2t4r8rlgz",
      "start_offset": 0,
      "end_offset": 12,
      "type": "<ALPHANUM>",
      "position": 0
    },
    {
      "token": "988y947mmas5zuu",
      "start_offset": 13,
      "end_offset": 28,
      "type": "<ALPHANUM>",
      "position": 1
    }
  ]
}

Apache Lucene 将写入的所有信息组织成 inverted index 的结构形式。

倒排索引是一种将 词项 映射到 文档 的数据结构

一个 索引 由多个 段 组成

每个 段 只会写入一次，但是会被查询多次。

索引期间，一个段创建之后就不会被修改。例如，当段中的摸个文档被删除，有关它的信息会被单独保存在一个文件中，而段本身不会被修改

多个段将会在 段合并 （segment merge）阶段被合并在一起。

段合并 操作或被强制执行，或由 Lucene 的内在机制决定在某个时刻执行，

合并之后 段的数量更少，但是每个段的体积更大。段合并操作耗费 I/O 非常严重，合并期间有些不再使用的信息会被清理掉，例如被删除的文档。

对于容纳相同数据量的索引，搜索一个大段比搜索多个小段速度更快

norm 存储归一化结果，用于计算查询的相关得分。

norm 基于索引时的文档加权值 （boost）计算得出，与文档一起被索引。

使用 norm 可以让 Lucene 在建立索引时考虑不同文档的权重，代价仅仅是需要一些额外的磁盘空间 和 内存 来索引和存储 norm 信息。

词项向量 是一种针对每个文档的微星倒排索引。

词项向量 由词项 和 词项 的出现频率结对组成，还可以包含词项的位置信息。Lucene 和 Elasticsearch 默认都禁用词项向量索引，不过要启用诸如关键词高亮之类 的功能，就需要启用这个选项 。

文档导入Elasticsearch之后，会经历一个必要的分析阶段，以生成倒排索引

文本分析过程由分析器来执行，分析器包含一个 分词器、零到多个 词条过滤器 和 零到多个 字符过滤器。

Lucene 分词器 用来将 文本切割成 词条， 词条是携带各种额外信息的词项。

这些信息包括词项在原始文本中的位置和词项的长度。由分词器得到的结果被称为词条流，因为这些词条被一个接一个地推送给过滤器处理。

过滤器用来移除、修改词条流中的词条，甚至可以生成新的词条。

Lucene 中有很多现成的过滤器

小写过滤器

ASCII 过滤器

同义词过滤器

多语言词干还原过滤器

在查询时也会经过分析阶段，但是可以选择其他路径而不分析查询条件

Elasticsearch中有些查询会被分析，而有些不会被分析

例如

前缀查询 prefix query 不会被分析

匹配查询 match query 会被分析

关于 索引期 与 检索期 的查询分析，只有当查询 query 语句经过 分词过程 得到的 词项 能与索引中的词项 匹配时，才会返回预期的文档集。

例如，如果 在索引期 使用了词干还原 与 小写转换，那么在查询期，也 应该对查询串做相同的处理，否则，查询可能不会返回任何结果。