ElasticSearch

"揭秘腾讯万亿级ES实战：从原理到优化的深度解析！本次分享将带你深入ElasticSearch核心：一、腾讯ES海量规模下的挑战与内核优化，涵盖集群架构、查询/索引/硬件配置优化策略；二、硬核原理剖析，详解文档读取/索引流程及底层机制；三、实战宝典，包括DSL查询、聚合分析（Metric/Bucket/Pipeline）、索引模板管理等高频应用四、生态认知与部署指南，从Elastic Stack基础概念到Kibana安装。最后探讨开源贡献与未来演进方向。

ElasticSearch

• 什么是倒排索引： 对文档的分词结果进行遍历，如果 keyword 命中该分词，那么通过该分词便可以找到所有含有这个分词的文档，性能相对较高。 倒排索引包含两个部分： - 单词词典（Term Dictionary），记录所有文档的单词，记录单词倒排列表的关联关系。单词词典一般比较大，可以通过B+树或者哈希拉链法实现，以满足高性能的插入与查询 - 倒排列表（Posting List），记录了单词对应的文档结合，由倒排索引组成。倒排索引项包含：文档ID，词频TF（该单词在文档中出现的次数，用于相关性评分），位置（Position，单词在文档中分词的位置。用于语句搜索（phrase query）），偏移（Offset，记录单词的开始结束位置，实现高亮显示） Elasticsearch的倒排索引：Elasticsearch的JSON文档中的每个字段，都有自己的倒排索引。但是可以对某些字段不做索引，优点是可以节省存储空间，缺点是该字段将无法被搜索。 es索引流程： 
• 认知
  • ElasticSearch基础概念
    • 为什么要学习ES？
      • 1.搜索是一个平台的基本功能，学习ES可以为响应软件打造出良好的搜索体验 2.ES具备非常强大的数据分析能力 3.ES使用非常方便 4.应用广泛，非常多的公司在使用ES 5.当今时代，数据才是核心竞争力
    • 什么是ElaticSearch
      • ES是一个开源，分布式搜索分析引擎，可以以极快的速度搜索数据
      • ElaticSearch的由来
        • 许多年前，一个刚结婚的名叫 Shay Banon 的失业开发者，跟着他的妻子去了伦敦，他的妻子在那里学习厨师。 在寻找一个赚钱的工作的时候，为了给他的妻子做一个食谱搜索引擎，他开始使用 Lucene 的一个早期版本。 直接使用 Lucene 是很难的，因此 Shay 开始做一个抽象层，Java 开发者使用它可以很简单的给他们的程序添加搜索功能。 他发布了他的第一个开源项目 Compass。 后来 Shay 获得了一份工作，主要是高性能，分布式环境下的内存数据网格。这个对于高性能，实时，分布式搜索引擎的需求尤为突出， 他决定重写 Compass，把它变为一个独立的服务并取名 Elasticsearch。 第一个公开版本在2010年2月发布，从此以后，Elasticsearch 已经成为了 Github 上最活跃的项目之一，他拥有超过300名 contributors(目前736名 contributors )。 一家公司已经开始围绕 Elasticsearch 提供商业服务，并开发新的特性，但是，Elasticsearch 将永远开源并对所有人可用。 据说，Shay 的妻子还在等着她的食谱搜索引擎…
      • 为什么不是直接使用Lucene
        • Lucene 可以说是当下最先进、高性能、全功能的搜索引擎库。 但是 Lucene 仅仅只是一个库。为了充分发挥其功能，你需要使用 Java 并将 Lucene 直接集成到应用程序中。 更糟糕的是，您可能需要获得信息检索学位才能了解其工作原理。Lucene 非常 复杂。 Elasticsearch 也是使用 Java 编写的，它的内部使用 Lucene 做索引与搜索，但是它的目的是使全文检索变得简单，通过隐藏 Lucene 的复杂性，取而代之的提供一套简单一致的 RESTful API。 然而，Elasticsearch 不仅仅是 Lucene，并且也不仅仅只是一个全文搜索引擎。 它可以被下面这样准确的形容： 一个分布式的实时文档存储，每个字段 可以被索引与搜索 一个分布式实时分析搜索引擎 能胜任上百个服务节点的扩展，并支持 PB 级别的结构化或者非结构化数据
      • ElasticSearch的主要功能和应用场景
        • 主要功能
          • 1）海量数据的分布式存储以及集群管理，达到了服务与数据的高可用以及水平扩展； 2）近实时搜索，性能卓越。对结构化、全文、地理位置等类型数据的处理； 3）海量数据的近实时分析（聚合功能）
        • 应用场景
          • 1）网站搜索、垂直搜索、代码搜索； 2）日志管理与分析、安全指标监控、应用性能监控、Web抓取舆情分析；
    • ElasticSearch的基础概念
      •  数据库和ES的对比
      • Near Realtime（NRT）
        • 实时。数据提交索引后，立马就可以搜索到。
      • Cluster 集群
        • 一个集群由一个唯一的名字标识，默认为“elasticsearch”。集群名称非常重要，具有相同集群名的节点才会组成一个集群。集群名称可以在配置文件中指定。
      • Node 节点
        • 存储集群的数据，参与集群的索引和搜索功能。像集群有名字，节点也有自己的名称，默认在启动时会以一个随机的UUID的前七个字符作为节点的名字，你可以为其指定任意的名字。通过集群名在网络中发现同伴组成集群。一个节点也可是集群。
      • Index 索引
        • 一个索引是一个文档的集合（等同于solr中的集合）。每个索引有唯一的名字，通过这个名字来操作它。一个集群中可以有任意多个索引。
      • Type 类型
        • 指在一个索引中，可以索引不同类型的文档，如用户数据、博客数据。从6.0.0 版本起已废弃，一个索引中只存放一类数据。
      • Document 文档
        • 被索引的一条数据，索引的基本信息单元，以JSON格式来表示。
      • Shard 分片
        • 在创建一个索引时可以指定分成多少个分片来存储。每个分片本身也是一个功能完善且独立的“索引”，可以被放置在集群的任意节点上。
      • Replication 备份
        • 一个分片可以有多个备份（副本）
  • Elastic Stack生态和场景方案
    • Elatic Stack生态
      • Beats
        • Beats是一个面向轻量型采集器的平台，这些采集器可以从边缘机器向Logstash、ElasticSearch发送数据，它是由Go语言进行开发的，运行效率方面比较快。从下图中可以看出，不同Beats的套件是针对不同的数据源。
      • Logstash
        • Logstash是动态数据收集管道，拥有可扩展的插件生态系统，支持从不同来源采集数据，转换数据，并将数据发送到不同的存储库中。其能够与ElasticSearch产生强大的协同作用，后被Elastic公司在2013年收购。 作用： 1）实时解析和转换数据； 2）可扩展，具有200多个插件； 3）可靠性、安全性。Logstash会通过持久化队列来保证至少将运行中的事件送达一次，同时将数据进行传输加密； 4）监控；
      • ElasticSearch
        • ElasticSearch对数据进行搜索、分析和存储，其是基于JSON的分布式搜索和分析引擎，专门为实现水平可扩展性、高可靠性和管理便捷性而设计的。 它的实现原理主要分为以下几个步骤： 1）首先用户将数据提交到ElasticSearch数据库中； 2）再通过分词控制器将对应的语句分词； 3）将分词结果及其权重一并存入，以备用户在搜索数据时，根据权重将结果排名和打分，将返回结果呈现给用户；
      • Kibana
        • Kibana实现数据可视化，其作用就是在ElasticSearch中进行民航。Kibana能够以图表的形式呈现数据，并且具有可扩展的用户界面，可以全方位的配置和管理ElasticSearch。 Kibana最早的时候是基于Logstash创建的工具，后被Elastic公司在2013年收购。 1）Kibana可以提供各种可视化的图表； 2）可以通过机器学习的技术，对异常情况进行检测，用于提前发现可疑问题；
    • 从日志收集系统看ES Stack的发展
      • 一个典型的日志系统包括： （1）收集：能够采集多种来源的日志数据 （2）传输：能够稳定的把日志数据解析过滤并传输到存储系统 （3）存储：存储日志数据 （4）分析：支持 UI 分析 （5）警告：能够提供错误报告，监控机制
      • Beats + elasticsearch + kibana
        • Beats采集数据后，存储在ES中，有Kibana可视化的展示。 
      • beats + logstath + elaticsearch + kibana
        •  该框架是在上面的框架的基础上引入了logstash，引入logstash带来的好处如下： （1）Logstash具有基于磁盘的自适应缓冲系统，该系统将吸收传入的吞吐量，从而减轻背压。 （2）从其他数据源（例如数据库，S3或消息传递队列）中提取。 （3）将数据发送到多个目的地，例如S3，HDFS或写入文件。 （4）使用条件数据流逻辑组成更复杂的处理管道。
      • beats + MQ + logstash + elasticsearch + kibana
    • Elatic Stack最佳实践
      • 日志收集系统
      • Metric收集和APM性能监控
      • 多数据方案
• 安装
  • ElasticSearch和Kibana安装
• 入门
  • 查询和聚合的基础使用
    • 入门：从索引文档开始
    • 学习准备：批量索引文档
    • 查询数据
      • 查询所有
        • match_all表示查询所有的数据，sort即按照什么字段排序 GET /bank/_search { "query": { "match_all": {} }, "sort": [ { "account_number": "asc" } ] }
      • 分页查询（from + size）
        • 本质上就是from和size两个字段 GET /bank/_search { "query": { "match_all": {} }, "sort": [ { "account_number": "asc" } ], "from": 10, "size": 10 }
      • 指定字段查询：match
        • match：模糊匹配，需要指定字段名，但是输入会进行分词，比如"hello world"会进行拆分为hello和world，然后匹配，如果字段中包含hello或者world，或者都包含的结果都会被查询出来，也就是说match是一个部分匹配的模糊查询。查询条件相对来说比较宽松。 GET /bank/_search { "query": { "match": { "address": "mill lane" } } } （由于ES底层是按照分词索引的，所以上述查询结果是address 字段中包含 mill 或者 lane的数据）
      • 查询段落匹配：match_phase
        • match_phase：会对输入做分词，但是需要结果中也包含所有的分词，而且顺序要求一样。以"hello world"为例，要求结果中必须包含hello和world，而且还要求他们是连着的，顺序也是固定的，hello that word不满足，world hello也不满足条件。 GET /bank/_search { "query": { "match_phrase": { "address": "mill lane" } } }
      • 多条件查询
        • 如果要构造更复杂的查询，可以使用bool查询来组合多个查询条件。 例如，以下请求在bank索引中搜索40岁客户的帐户，但不包括居住在爱达荷州（ID）的任何人 GET /bank/_search { "query": { "bool": { "must": [ { "match": { "age": "40" } } ], "must_not": [ { "match": { "state": "ID" } } ] } } }
      • 查询条件：query or filter
        • must, should, must_not 和 filter 都是bool查询的子句。那么filter和上述query子句有啥区别呢？ 先看下如下查询, 在bool查询的子句中同时具备query/must 和 filter GET /bank/_search { "query": { "bool": { "must": [ { "match": { "state": "ND" } } ], "filter": [ { "term": { "age": "40" } }, { "range": { "balance": { "gte": 20000, "lte": 30000 } } } ] } } } 两者都可以写查询条件，而且语法也类似。区别在于，query 上下文的条件是用来给文档打分的，匹配越好 _score 越高；filter 的条件只产生两种结果：符合与不符合，后者被过滤掉。
    • 聚合查询
      • 简单聚合
        • 比如我们希望计算出account每个州的统计数量， 使用aggs关键字对state字段聚合，被聚合的字段无需对分词统计，所以使用state.keyword对整个字段统计 GET /bank/_search { "size": 0, "aggs": { "group_by_state": { "terms": { "field": "state.keyword" } } } }
      • 嵌套聚合
        • ES还可以处理个聚合条件的嵌套。 比如承接上个例子， 计算每个州的平均结余。涉及到的就是在对state分组的基础上，嵌套计算avg(balance): GET /bank/_search { "size": 0, "aggs": { "group_by_state": { "terms": { "field": "state.keyword" }, "aggs": { "average_balance": { "avg": { "field": "balance" } } } } } }
      • 对聚合结果排序
        • 可以通过在aggs中对嵌套聚合的结果进行排序 比如承接上个例子， 对嵌套计算出的avg(balance)，这里是average_balance，进行排序 GET /bank/_search { "size": 0, "aggs": { "group_by_state": { "terms": { "field": "state.keyword", "order": { "average_balance": "desc" } }, "aggs": { "average_balance": { "avg": { "field": "balance" } } } } } }
• 索引
  • 索引管理详解
    • 索引管理的引入
      • 我们在前文中增加文档时，如下的语句会动态创建一个customer的index： PUT /customer/_doc/1 { "name": "John Doe" } 而这个index实际上已经自动创建了它里面的字段（name）的类型。我们不妨看下它自动创建的mapping： { "mappings": { "_doc": { "properties": { "name": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } } } } } } 那么如果我们需要对这个建立索引的过程做更多的控制：比如想要确保这个索引有数量适中的主分片，并且在我们索引任何数据之前，分析器和映射已经被建立好。那么就会引入两点：第一个禁止自动创建索引，第二个是手动创建索引。 禁止自动创建索引 可以通过在 config/elasticsearch.yml 的每个节点下添加下面的配置： action.auto_create_index: false
    • 索引的格式
      • 在请求体里面传入设置或类型映射，如下所示： PUT /my_index { "settings": { ... any settings ... }, "mappings": { "properties": { ... any properties ... } } } settings: 用来设置分片,副本等配置信息 mappings: 字段映射，类型等 properties: 由于type在后续版本中会被Deprecated, 所以无需被type嵌套
    • 索引管理操作
      • 创建索引
        • 我们创建一个user 索引test-index-users，其中包含三个属性：name，age, remarks; 存储在一个分片一个副本上。 PUT /test-index-users { "settings": { "number_of_shards": 1, "number_of_replicas": 1 }, "mappings": { "properties": { "name": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } }, "age": { "type": "long" }, "remarks": { "type": "text" } } } }
      • 修改索引
        • PUT /test-index-users/_settings { "settings": { "number_of_replicas": 0 } }
      • 打开/关闭索引
        • 一旦索引被关闭，那么这个索引只能显示元数据信息，不能够进行读写操作。
        • 关闭索引
          • post /index/_close
        • 打开索引
          • post /index/_open
      • 删除索引
        • DELETE /test-index-users
      • 查看索引
        • 由于test-index-users被删除，所以我们看下之前bank的索引的信息 mapping: GET /bank/_mapping settings GET /bank/_settings
    • Kibana管理索引
  • 索引模板(Index Template)详解
    • 索引模板
      • 索引模板是一种告诉Elasticsearch在创建索引时如何配置索引的方法。 使用方式 在创建索引之前可以先配置模板，这样在创建索引（手动创建索引或通过对文档建立索引）时，模板设置将用作创建索引的基础。
      • 模板类型
      • 索引模板中的优先级
      • 内置索引模板
    • 模拟多组件模板
      • 模拟某个索引结果
      • 模拟组件模板结果
• 查询
  • DSL查询之复合查询详解
    • 复合查询引入
    • bool query(布尔查询)
      • 通过布尔逻辑将较小的查询组合成较大的查询，只要有一个条件不匹配，那结果就不会出现
      • 概念
        • Bool查询语法有以下特点 子查询可以任意顺序出现 可以嵌套多个查询，包括bool查询 如果bool查询中没有must条件，should中必须至少满足一条才会返回结果。 bool查询包含四种操作符，分别是must,should,must_not,filter。他们均是一种数组，数组里面是对应的判断条件。 must： 必须匹配。贡献算分 must_not：过滤子句，必须不能匹配，但不贡献算分 should： 选择性匹配，至少满足一条。贡献算分 filter： 过滤子句，必须匹配，但不贡献算分
      • 一些例子
    • boosting query(提高查询)
      • 不同于bool查询，bool查询中只要一个子查询条件不匹配那么搜索的数据就不会出现。 而boosting query则是降低显示的权重/优先级（即score)。
      • 概念
      • 例子
    • constant_score（固定分数查询）
      • 查询某个条件时，固定的返回指定的score；显然当不需要计算score时，只需要filter条件即可，因为filter context忽略score。
      • 例子
        • GET /test-dsl-constant/_search { "query": { "constant_score": { "filter": { "term": { "content": "apple" } }, "boost": 1.2 } } }
    • dis_max(最佳匹配查询）
      • 分离最大化查询（Disjunction Max Query）指的是： 将任何与任一查询匹配的文档作为结果返回，但只将最佳匹配的评分作为查询的评分结果返回 。
    • function_score(函数查询）
      • 简而言之就是用自定义function的方式来计算_score
  • DSL查询之全文搜索详解
    • 基于文本的查询
    • Match类型
      • match查询的步骤
        • 1.检查字段类型
          • 标题 title 字段是一个 string 类型（ analyzed ）已分析的全文字段，这意味着查询字符串本身也应该被分析
        • 2.分析查询字符串
          • 将查询的字符串 QUICK! 传入标准分析器中，输出的结果是单个项 quick 。因为只有一个单词项，所以 match 查询执行的是单个底层 term 查询。
        • 3.查找匹配文档
          • 用 term 查询在倒排索引中查找 quick 然后获取一组包含该项的文档，本例的结果是文档：1、2 和 3 。
        • 4.为每个文档评分
          • 用 term 查询计算每个文档相关度评分 _score ，这是种将词频（term frequency，即词 quick 在相关文档的 title 字段中出现的频率）和反向文档频率（inverse document frequency，即词 quick 在所有文档的 title 字段中出现的频率），以及字段的长度（即字段越短相关度越高）相结合的计算方式。
      • match多个词深入
        • 因为 match 查询必须查找两个词（ ["brown","dog"] ），它在内部实际上先执行两次 term 查询，然后将两次查询的结果合并作为最终结果输出。为了做到这点，它将两个 term 查询包入一个 bool 查询中， match多个词的逻辑 上面等同于should（任意一个满足），是因为 match还有一个operator参数，默认是or, 所以对应的是should。
      • 控制match的匹配精度
        • 如果用户给定 3 个查询词，想查找只包含其中 2 个的文档，该如何处理？ 将 operator 操作符参数设置成 and 或者 or 都是不合适的。 match 查询支持 minimum_should_match 最小匹配参数，这让我们可以指定必须匹配的词项数用来表示一个文档是否相关。我们可以将其设置为某个具体数字，更常用的做法是将其设置为一个百分数，因为我们无法控制用户搜索时输入的单词数 GET /test-dsl-match/_search { "query": { "match": { "title": { "query": "quick brown dog", "minimum_should_match": "75%" } } } }
      • 其他match类型
        • match_pharse
          • 相当于将两个词作为一个词来查询，但是不能匹配前缀 GET /test-dsl-match/_search { "query": { "match_phrase": { "title": { "query": "quick brown" } } } }
        • match_pharse_prefix
          • ELasticSearch在match_phrase基础上提供了一种可以查最后一个词项是前缀的方法 GET /test-dsl-match/_search { "query": { "match_phrase_prefix": { "title": { "query": "quick brown f" } } } }
        • match_bool_prefix
          • GET /test-dsl-match/_search { "query": { "match_bool_prefix": { "title": { "query": "quick brown f" } } } } match_bool_prefix本质上可以转换为 GET /test-dsl-match/_search { "query": { "bool" : { "should": [ { "term": { "title": "quick" }}, { "term": { "title": "brown" }}, { "prefix": { "title": "f"}} ] } } } 这个查询是无序的
        • multi_match
          • 如果我们期望一次对多个字段查询，怎么办呢？ElasticSearch提供了multi_match查询的方式 { "query": { "multi_match" : { "query": "Will Smith", "fields": [ "title", "*_name" ] } } }
    • query string类型
      • query_string
        • 此查询使用语法根据运算符（例如AND或）来解析和拆分提供的查询字符串NOT。然后查询在返回匹配的文档之前独立分析每个拆分的文本。 可以使用该query_string查询创建一个复杂的搜索，其中包括通配符，跨多个字段的搜索等等。尽管用途广泛，但查询是严格的，如果查询字符串包含任何无效语法，则返回错误。 GET /test-dsl-match/_search { "query": { "query_string": { "query": "(lazy dog) OR (brown dog)", "default_field": "title" } } }
      • query_string_simple
        • 该查询使用一种简单的语法来解析提供的查询字符串并将其拆分为基于特殊运算符的术语。然后查询在返回匹配的文档之前独立分析每个术语。 尽管其语法比query_string查询更受限制 ，但simple_query_string 查询不会针对无效语法返回错误。而是，它将忽略查询字符串的任何无效部分。 GET /test-dsl-match/_search { "query": { "simple_query_string" : { "query": "\"over the\" + (lazy | quick) + dog", "fields": ["title"], "default_operator": "and" } } }
    • Interval类型
  • DSL查询之Term详解
    • 基于词项的查询
    • Term查询引入
    • Term查询
      • 字段是否存在:exist
        • 由于多种原因，文档字段的索引值可能不存在： 源JSON中的字段是null或[] 该字段已"index" : false在映射中设置 字段值的长度超出ignore_above了映射中的设置 字段值格式错误，并且ignore_malformed已在映射中定义
      • id查询Ids
        • GET /test-dsl-term-level/_search { "query": { "ids": { "values": [3, 1] } } }
      • 前缀：prefix
        • GET /test-dsl-term-level/_search { "query": { "prefix": { "name": { "value": "Jan" } } } }
      • 分词匹配：term
        • GET /test-dsl-term-level/_search { "query": { "term": { "programming_languages": "php" } } }
      • 多个分词匹配：terms
        • GET /test-dsl-term-level/_search { "query": { "terms": { "programming_languages": ["php","c++"] } } }
      • 按某个数字字段分词匹配：term set
        • 设计这种方式查询的初衷是用文档中的数字字段动态匹配查询满足term的个数 GET /test-dsl-term-level/_search { "query": { "terms_set": { "programming_languages": { "terms": [ "java", "php" ], "minimum_should_match_field": "required_matches" } } } }
      • 通配符：wildcard
        • 通配符匹配，比如* GET /test-dsl-term-level/_search { "query": { "wildcard": { "name": { "value": "D*ai", "boost": 1.0, "rewrite": "constant_score" } } } }
      • 范围：range
        • 常常被用在数字或者日期范围的查询 GET /test-dsl-term-level/_search { "query": { "range": { "required_matches": { "gte": 3, "lte": 4 } } } }
      • 正则：regexp
        • 正则:regexp 通过正则表达式查询 以"Jan"开头的name字段 GET /test-dsl-term-level/_search { "query": { "regexp": { "name": { "value": "Ja.*", "case_insensitive": true } } } }
      • 模糊匹配：fuzzy
        • 官方文档对模糊匹配：编辑距离是将一个术语转换为另一个术语所需的一个字符更改的次数。这些更改可以包括： 更改字符（box→ fox） 删除字符（black→ lack） 插入字符（sic→ sick） 转置两个相邻字符（act→ cat）
• 聚合
  • ElasticSearch中桶在概念上类似于 SQL 的分组（GROUP BY），而指标则类似于 COUNT() 、 SUM() 、 MAX() 等统计方法。 桶（Buckets） 满足特定条件的文档的集合 指标（Metrics） 对桶内的文档进行统计计算 所以ElasticSearch包含3种聚合（Aggregation)方式 桶聚合,指标聚合,管道聚合 聚合管道化，简单而言就是上一个聚合的结果成为下个聚合的输入； （PS:指标聚合和桶聚合很多情况下是组合在一起使用的，其实你也可以看到，桶聚合本质上是一种特殊的指标聚合，它的聚合指标就是数据的条数count)
  • 聚合查询之Bucket聚合详解
    • 桶（Buckets） 满足特定条件的文档的集合 类似mysql中的group by
    • 如何理解Bucket聚合
    • 按知识点学习聚合
      • 准备数据
      • 标准的聚合
        • 有了数据，开始构建我们的第一个聚合。汽车经销商可能会想知道哪个颜色的汽车销量最好，用聚合可以轻易得到结果，用 terms 桶操作： GET /test-agg-cars/_search { "size" : 0, "aggs" : { "popular_colors" : { "terms" : { "field" : "color.keyword" } } } } 1.聚合操作被置于顶层参数 aggs 之下（如果你愿意，完整形式 aggregations 同样有效） 2.然后，可以为聚合指定一个我们想要名称，本例中是： popular_colors 。 3.最后，定义单个桶的类型 terms 。
      • 多个聚合
        • 同时计算两种桶的结果：对color和对make。 GET /test-agg-cars/_search { "size" : 0, "aggs" : { "popular_colors" : { "terms" : { "field" : "color.keyword" } }, "make_by" : { "terms" : { "field" : "make.keyword" } } } }
      • 聚合的嵌套
        • 这个新的聚合层让我们可以将 avg 度量嵌套置于 terms 桶内。实际上，这就为每个颜色生成了平均价格。 GET /test-agg-cars/_search { "size" : 0, "aggs": { "colors": { "terms": { "field": "color.keyword" }, "aggs": { "avg_price": { "avg": { "field": "price" } } } } } }
      • 动态脚本的聚合
    • 按分类学习Bucket聚合
      • 前置条件的过滤：filter
        • 在当前文档集上下文中定义与指定过滤器(Filter)匹配的所有文档的单个存储桶。通常，这将用于将当前聚合上下文缩小到一组特定的文档。 GET /test-agg-cars/_search { "size": 0, "aggs": { "make_by": { "filter": { "term": { "type": "honda" } }, "aggs": { "avg_price": { "avg": { "field": "price" } } } } } }
      • 对filter进行分组聚合：filters
      • 对number类型聚合：Range
        • 基于多桶值源的聚合，使用户能够定义一组范围-每个范围代表一个桶。在聚合过程中，将从每个存储区范围中检查从每个文档中提取的值，并“存储”相关/匹配的文档。请注意，此聚合包括from值，但不包括to每个范围的值。 GET /test-agg-cars/_search { "size": 0, "aggs": { "price_ranges": { "range": { "field": "price", "ranges": [ { "to": 20000 }, { "from": 20000, "to": 40000 }, { "from": 40000 } ] } } } }
      • 对IP类型聚合：IP Range
        • 专用于IP值的范围聚合。 GET /ip_addresses/_search { "size": 10, "aggs": { "ip_ranges": { "ip_range": { "field": "ip", "ranges": [ { "to": "10.0.0.5" }, { "from": "10.0.0.5" } ] } } } }
      • 对日期类型聚合Date Range
        • 专用于日期值的范围聚合。 GET /test-agg-cars/_search { "size": 0, "aggs": { "range": { "date_range": { "field": "sold", "format": "yyyy-MM", "ranges": [ { "from": "2014-01-01" }, { "to": "2014-12-31" } ] } } } }
      • 对柱状图功能：Histrogram
  • 聚合查询之Metric聚合详解
    • 指标（Metrics） 对桶内的文档进行统计计算 对bucket中的值进行计算
    • 如何理解metric
      • Metric聚合分析分为单值分析和多值分析两类 根据具体的应用场景设计了一些分析api, 比如地理位置，百分数等等
    • 单值分析：标准stat类型
      • avg平均值
        • POST /exams/_search?size=0 { "aggs": { "avg_grade": { "avg": { "field": "grade" } } } }
      • max最大值
        • 计算销售最高价 POST /sales/_search?size=0 { "aggs": { "max_price": { "max": { "field": "price" } } } }
      • min最小值
        • POST /sales/_search?size=0 { "aggs": { "min_price": { "min": { "field": "price" } } } }
      • sum和
        • POST /sales/_search?size=0 { "query": { "constant_score": { "filter": { "match": { "type": "hat" } } } }, "aggs": { "hat_prices": { "sum": { "field": "price" } } } }
      • value_count数量
        • POST /sales/_search?size=0 { "aggs" : { "types_count" : { "value_count" : { "field" : "type" } } } }
    • 单值分析：其他类型
      • weighted_avg带权重的avg
        • POST /exams/_search { "size": 0, "aggs": { "weighted_grade": { "weighted_avg": { "value": { "field": "grade" }, "weight": { "field": "weight" } } } } }
      • cardiality基数（distinct去重）
        • POST /sales/_search?size=0 { "aggs": { "type_count": { "cardinality": { "field": "type" } } } }
      • median_absolute_deviation中位值
        • GET reviews/_search { "size": 0, "aggs": { "review_average": { "avg": { "field": "rating" } }, "review_variability": { "median_absolute_deviation": { "field": "rating" } } } }
    • 非单位值分析：starts型
      • percentiles 百分数范围
        • 针对从聚合文档中提取的数值计算一个或多个百分位数。
      • percentile_ranks 百分数排行
        • 根据从汇总文档中提取的数值计算一个或多个百分位等级。
    • 非单值分析：地理位置型
      • geo_bounds Geo bounds
        • POST /museums/_search?size=0 { "query": { "match": { "name": "musée" } }, "aggs": { "viewport": { "geo_bounds": { "field": "location", "wrap_longitude": true } } } }
      • geo_centroid Geo-centroid
        • POST /museums/_search?size=0 { "aggs": { "centroid": { "geo_centroid": { "field": "location" } } } }
      • geo_line Geo-Line
        • 将存储桶中的所有geo_point值聚合到由所选排序字段排序的LineString中。 POST /test/_search?filter_path=aggregations { "aggs": { "line": { "geo_line": { "point": {"field": "my_location"}, "sort": {"field": "@timestamp"} } } } }
    • 非单值分析：Top型
      • top_hits 分桶后的top hits
      • top_metrics
  • 聚合查询之Pipline聚合详解
    • 如何理解pipeline聚合
      • 管道机制的常见场景
      • ElasticSearch设计管道机制
    • 一些例子
      • Average bucket 聚合
      • Stats bucket 聚合
• 原理
  • 从图解构筑对ES原理的初步认知
    • 介绍
      • 本文先自上而下，后自底向上的介绍ElasticSearch的底层工作原理，试图回答以下问题： 为什么我的搜索 *foo-bar* 无法匹配 foo-bar ？ 为什么增加更多的文件会压缩索引（Index）？ 为什么ElasticSearch占用很多内存？
    • 图解ElasticSearch
    • 图解Lucene
      • Segment
        • Inverted Index
        • Stored Field字段查找
        • Document Values为了排序，聚合
      • 搜索发生时
      • 缓存的故事
      • 在Shard中搜索
    • 一个真实的请求
    • 参考来源
  • ES原理知识点补充和整体结构
    • ElasticSearch整体结构
    • 补充:Lucene索引结构
    • 补充:Lucene处理流程
      • 
    • 补充:ElasticSearch分析器
      • 内置分析器
      • 什么时候使用分析器
  • ES原理之索引文档流程详解
    • 文档索引步骤顺序
      • 单个文档
      • 多个文档
    • 文档索引过程详解
      • 整体的索引流程
      • 分步骤看数据持久化过程
    • 深入ElasticSearch索引文档的实现机制
      • 写操作的关键点
      • Lucene的写
      • Elasticsearch的写
      • Elasticsearch写入请求类型
        • Client Node
        • Primary Node
        • Replica Node
  • ES原理之读取文档流程详解
    • 文档查询步骤顺序
    • 文档读取过程详解
    • 深入ElasticSearch读取文档的实现机制
      • 读操作
      • Lucene的读
      • Elasticsearch的读
      • Elasticsearch查询流程
        • Client Node
        • Query Phase
        • Fetch Phase
• 优化
  • ElasticSearch性能优化详解
    • 硬件配置优化
      • cpu配置
      • 内存配置
        • 内存分配
        • 禁止swap
        • GC设置
      • 磁盘
    • 索引优化设置
      • 批量提交
      • 增加 Refresh 时间间隔
      • 修改 index_buffer_size 的设置
      • 修改 translog 相关的设置
      • 注意 _id 字段的使用
      • 注意 _all 字段及 _source 字段的使用
      • 合理的配置使用 index 属性
      • 减少副本数量
    • 查询方面优化
      • 路由优化
      • Filter VS Query
      • 深度翻页
      • 脚本（script）合理使用
      • Cache的设置及使用
      • 更多查询优化经验
      • 通过开启慢查询配置定位慢查询
    • 数据结构优化
      • 尽量减少不需要的字段
      • Nested Object vs Parent/Child
      • 选择静态映射，非必需时，禁止动态映射
      • document 模型设计
    • 集群架构设计
      • 主节点、数据节点和协调节点分离
      • 关闭 data 节点服务器中的 http 功能
      • 一台服务器上最好只部署一个 node
      • 集群分片设置
• 大厂实践
  • 腾讯万亿级 Elasticsearch 技术实践
    • 一、ES 在腾讯的海量规模背景
    • 二、痛点与挑战
    • 三、腾讯 ES 内核优化剖析
    • 四、开源贡献及未来规划