关键词：
每一个系统都拥有很多概念，这些概念是作者在设计与实现时为不同的模块或功能做的定义。概念本身只是一个名词，往往会跟随作者的喜好不同而不同，重要的是理解其设计的初衷以及要表达的实际内容，否则很快就会忘记其意义。作为专栏文章的第二篇，本文将从多个方面对Elasticsearch的核心概念进行整理，尽可能由浅入深的交代清楚每个概念，而相关的使用技巧会在后续博文中介绍。本文写作背景是Elasticsearch 5.5。
为了方便查阅，这里首先列出会涉及到的概念，读者可以根据需要选择性阅读。
1. 数据组织
1.1 逻辑组织
假设我们在一个业务系统中选择MySQL做数据存储，那么我们需要先创建一个database，再创建一组相关的table。几乎所有的数据存储系统都有类似的设计，这样做的一个基本目的在于对数据进行抽象分类，将描述同种特性的数据放在一起，可以更好的做压缩存储、查询优化等。另一方面，通过这样在逻辑层面对数据进行组织后，可以屏蔽底层的具体细节，方便在应用程序中进行操作。
Elasticsearch同样具有这样的概念，如下图所示，使用index和doc_type来组织数据。doc_type中的每条数据称为一个document，是一个JSON Object，相关的schema信息通过mapping来定义。mapping不仅仅包括数据类型的定义，还有很多其他元信息的设置，它们共同决定了数据如何被存储和索引。这四个概念实现了Elasticsearch的逻辑数据组织，假设有一批结构化或半结构化数据需要存储，我们会先对数据进行分类，设计相应的index与doc_type，再为每个doc_type设置相关的mapping信息。如果不指定mapping，Elasticsearch会使用默认值，并自动为你推导每个字段的类型，即支持schema free的特性。但是，这种灵活性也会带来一些问题，一方面会失去对数据的控制，即会越来越不清楚你的数据结构，另一方面，自动推导出来数据类型可能不是预期的，会带来写入和查询问题。所以，笔者建议，尽最大可能对schema加以约束。
通常情况下，我们都会拿Elasticsearch的这些概念跟关系型数据库对比来更好的理解，比如index等价于database，doc_type等价于table，mapping等价于db schema。但是，需要注意的是，对于关系型数据库而言，table与table之间是完全独立的，不同table的schema是完全隔离的，而Elasticsearch中的doc_type则不是。同一个index下不同doc_type中的字段在底层是合并在一起存储的，意味着假设两个doc_type中都有一个叫name的字段，那么这两个字段的mapping必须一样。基于这个原因，Elasticsearch官方从6.0开始淡化doc_type的概念，推荐一个index只拥有一个doc_type，并计划在8.x完全废弃doc_type。因此，在当前的index设计中，最好能遵循这个规则。
1.2 物理组织
Elasticsearch是一个分布式系统，其数据会分散存储到不同的节点上。为了实现这一点，需要将每个index中的数据划分到不同的块中，然后将这些数据块分配到不同的节点上存储。这里的数据块，就是shard。通过"分"的思想，可以突破单机在存储空间和处理性能上的限制，这是分布式系统的核心目的。而对于分布式存储而言，还有一个重要特性是"冗余"，因为分布式的前提是：接受系统中某个节点因为某些故障退出。为了保证在故障节点退出后数据不丢失，同一份数据需要拷贝多份存在不同节点上。因此，shard从角色上划分为primary shard和replica shard两种，数据会首先写入primary shard，然后同步到replica shard中。
shard是Elasticsearch中最小的数据分配单位，即一个shard总是作为一个整体被分配到某个节点，而不会只分配其中一部分。那么，shard中的数据又是如何组织的？答案是segment。一个shard包含一组segment，segment是最小的数据单元，Elasticsearch每隔一段时间产生一个新的segment，里面包含了新写入的数据。segment是immutable的，即不可改变，这样设计的考量是：一方面，不支持修改就不用对读写操作加锁，省去了相关开销；另一方面，因为文件内容不会修改，可以更好的利用filesystem cache进行缓存，提高查询性能。但是，任何设计都不是完美的，伴随而来的问题是：如果segment不可修改，怎么实现数据的更新与删除呢？这个问题将在下面“数据写入”一节介绍。
2. 数据分布
上面提到，Elasticsearch将每个index中的数据划分到不同的shard中，然后将shard分配到不同的节点上，实现分布式存储。这里面涉及到两个概念：一个是数据到shard的映射（route），另一个是shard到节点的映射（shard allocate）。
一方面，插入一条数据时，Elasticsearch会根据指定的key来计算应该落到哪个shard上。默认key是自动分配的id，可以自定义，比如在我们的业务中采用CompanyID作为key。因为primary shard的个数是不允许改变的，所以同一个key每次算出来的shard是一样的，从而保证了准确定位。
shard_num = hash(_routing) % num_primary_shards
另一方面，master节点会为每个shard分配相应的data节点进行存储，并维护相关元信息。通过route计算出来的shard序号，在元信息中找到对应的存储节点，便可完成数据分布。shard allocate的映射关系并不是完全不变的，当检测到数据分布不均匀、有新节点加入或者有节点挂掉等情况时就会进行调整，称为relocate。
关于数据分布，可以参考阅读博文《谈Elasticsearch下分布式存储的数据分布》。
3. 集群角色
一个分布式系统，是由多个节点各司其职、相互协作完成整体服务的，从架构上可以分为有中心管理节点和无中心管理节点两种，Elasticsearch属于前者。中心管理节点负责维护整个系统的状态和元信息，为了保证高可用性，通常是从一组候选节点中选举出来的，而非直接指定。按照职责，Elasticsearch将节点分为三种：master-eligible节点、data节点、ingest节点。master-eligible节点就是中心节点的候选人，通过选举算法从这些候选人中推选出大家公认的中心节点。data节点负责数据存储、查询，也是整个系统中负载最重的部分。ingest节点是针对Elasticsearch一个特定功能而设定的，Elasticsearch支持在数据写入前对数据进行相关的转换、处理，而这类节点就是负责这样的工作，从笔者遇到的实践来看，使用这类节点的并不多。
这三种角色是通过配置来设定的，可以同时设置到同一个节点上，即一个节点可以同时具备这三种功能。但是这种做法只适用于数据量小、业务较轻的场景，因为不同角色承担的功能所带来的负载是不同的，很可能因为数据写入/查询负载较重导致master节点通信受到影响，从而导致系统不稳定。所以，推荐将不同角色分离开，某个节点只负责其中一个功能，通常会设置dedicated master-eligible节点、data/ingest节点。前者负载很轻，只需要分配较低配置的机器，而后者对CPU、IO、Memory要求较高，需要配置更好的机器，实践中根据性能测试结果来调整。
前面提到，中心节点(master)是从一组候选人(master-eligible)中选举出来的，那设置多少个候选人是合理的？原则是要保证任何时候系统只有一个确定的master节点。考虑到一致性，只有被半数以上候选节点都认可的节点才能成为master节点，否则就会出现多主的情况。只有1个候选节点显然不能保证高可用；有2个时，半数以上（n/2+1）的个数也是2，任何一个出现故障就无法继续工作了；有3个时，半数以上的值仍然是2，恰好可以保证master故障或网络故障时系统可以继续工作。因此，3个dedicated master-eligible节点是最小配置，也是目前业界标配。
Elasticsearch以REST API形式对外提供服务，数据写入与查询都会发送HTTP(S)请求到服务端，由负载均衡将请求分发到集群中的某个节点上（任何非dedicated master-eligible节点）。如下图所示，节点1收到请求后，会根据相关的元信息将请求分发到shard所在的节点（2和3）上进行处理，处理完成后，节点2和3会将结果返回给节点1，由节点1合并整理后返回给客户端。这里的节点1扮演着协调者的角色，称为coordinate节点，任何节点在收到请求后就开始发挥协调者的角色，直到请求结束。在实际使用中，可以根据需要增加一些专用的coordinate节点，用于性能调优。
4. 数据写入
通过上面的整理，我们知道，当有数据写入时，请求会先到达集群中的某个节点上，由该节点根据routing信息和元信息将相应的数据分发到对应的shard所在的节点上，可能是一个也可能是多个节点，取决于写入的数据。这些节点在收到分发出来的请求后，会经过一系列过程，最终将数据以segment的形式落地到磁盘上，这些过程就是本节要聊的内容，其包含同步与异步两个过程，如下图所示。
同步过程：
同步过程是指在请求返回前做的事情，即包含在一个HTTP请求的过程中，客户端需要等其做完才能拿到结果。简单来看，这个过程需要完成三件事：第一，将操作记录写入到translog中，我们后面再来谈它的作用；第二，根据数据生成相应的数据结构，并写入到in-memory buffer，注意是写入到一个内存buffer中，不是磁盘；第三，将数据同步到所有replica shard中。完成这些之后，就会生成相应的结果返回给coordinate节点了。
异步过程：
我们知道，写磁盘很慢，且非常耗费CPU与IO，在同步过程中，为了让请求尽快返回，并没有将数据直接落盘。Elasticsearch的最小数据单元是segment，而此时数据还在in-memory buffer中，因此这部分数据是不能被查询请求访问到的。只有当发生refresh动作，才会产生一个新的segment，将内存buffer中的数据写入到里面，同时清空buffer。默认refresh的时间间隔是1秒，可以配置，需要在实时性与性能之间进行权衡。
此时虽然已经生成了新的segment文件，但是只是停留在filesystem cache中，并没有真正的落到磁盘中。这些动作的目的都是为了将“写磁盘”这件事尽可能的延后并变得低频，但是数据一直留在内存中始终是不安全的，很容易因为断电等原因导致数据丢失，因此每隔一段时间，Elasticsearch会真正做一次磁盘flush，完成数据的持久化。
从写入请求过来到数据最终落盘，中间很长一段时间数据是停留在内存中的，那么如果在此期间机器断电岂不是会丢失数据？为了解决这个问题，就要用到上面所述的translog了。在请求返回前，必须要将操作记录写入到translog中并落盘，保证机器重启后可以恢复数据。显然这件事本身是会消耗性能的，但这也是保证数据不丢失的一个牺牲了，必须要做的。
segment是由refresh动作产生的，因此随着时间推移，会产生很多小segment，而每个segment都需要占用一定的资源，比如文件句柄、缓存等等，过多的segment势必会导致性能下降。因此每隔一段时间，Elasticsearch会做一次segment merge，将多个小的segment合并成一个大的segment。
最后再来看下前面提到的一个问题：因为segment是不可改变的，如何实现数据更新与删除？以删除为例，Elasticsearch将要删除的数据记录到一个叫.del文件中，每次查询时会将匹配到的数据跟这个文件中的数据做一次对比，去掉被删除的数据。直到segment merge时，会将.del文件和相应的segment文件一起加载进行合并，这时才真正删除了数据。
5. 存储结构
在讲存储结构之前，先来看看两种常见的查询需求（以一组博文信息数据为例，有作者、标题等信息）。一种是精确匹配，比如查找作者姓名为"Bruce"的信息；另一种是全文检索，比如从1000个文章的标题中搜索出包含"分布式"的文章。对于第一个需求，我们只需要将每个名字作为一个term即可，“是"或"不是”；对于第二个，我们如果想知道标题中是否包含"分布式"，就需要提前将每个标题分解为多个term，比如"浅谈分布式存储系统"，可能会产生"浅谈"、“分布式”、“存储”、"系统"等多个term，具体取决于使用了哪一种分析器。
不管哪种情况，最后都是产生一组term，问题是用一个什么样的存储结构可以实现快速检索。这就是Elasticsearch的核心：inverted index。inverted index是一个二维结构，如下所示，包含一组排好序的term，每个term都关联有一些信息，这些信息指出哪些document包含了这个term。当需要查询包含关键词"分布式"的数据时，系统会先从inverted index中找出对应的term，获取到其对应的document id，然后就可以根据document id找出其信息了。
sample data：
1. "author": "Bruce", "title": "浅谈分布式存储系统"
2. "author": "Bruce", "title": "常见的分布式系统"
3. "author": "David", "title": "分布式存储原理"
inverted index for field "author":
-------------------------------
term | doc id
-------------------------------
Bruce | 1, 2
David | 3
-------------------------------
inverted index for field "title":
-------------------------------
term | doc id
-------------------------------
常见 | 3
存储 | 1, 3
分布式 | 1, 2, 3
浅谈 | 1
系统 | 1, 2
原理 | 3
-------------------------------
通过inverted index，我们可以根据关键词快速搜索出相关的document，除了这种查询，还有一种常见的需求是求聚合，即关系型数据库中的GROUP BY功能。比如查看写"分布式"相关的文章最多的10位作者，首先根据上述方法通过inverted index找到与"分布式"相关的所有document，然后需要对这些document的作者进行归类并计数，最后再排序取出TOP10。在"归类"时，我们需要知道每个document的作者名字，但是通过inverted index是无法直接查找到的，因为他是term-to-doc_id形式的，而我们这里需要的是doc_id-to-term形式的数据，只有通过循环迭代才能知道某个document的作者姓名是什么，这样做的效率无疑是很低的。
为了解决聚合的效率问题，Elasticsearch建立了一个与inverted index反向的数据结构：doc values，如下所示。
-------------------------------
doc id | terms
-------------------------------
1 | Bruce
2 | Bruce
3 | David
-------------------------------
inverted index和doc values都是在数据写入时建立的，即上述的同步过程第二步中完成的。他们都是针对per segment而言的，数据最终以文件的形式存储，并且是immutable的。数据查询时，如果每次都去读取磁盘文件，其效率显然是无法接受的，Elasticsearch将这些文件内容映射到内存中，通过充分利用文件系统缓存来提高查询性能，因此在实践中建议保留足够的memory给系统。
以上便是笔者认为使用Elasticsearch过程中应该掌握的核心概念与原理，这些知识点对使用和理解实践中Elasticsearch表现出来的行为有很大的帮助。当然，并不意味着必须要从一开始就完全掌握，任何认知都是需要伴随实践来提高的。另外，在本文的描述中，笔者淡化了Elasticsearch与Lucene的关系，其实有不少概念是Lucene里面的，而Elasticsearch是在Lucene的基础上开发的，淡化的原因是笔者认为没有必要刻意去区分这二者，除非你想深入研究源码。当然，概念远不止这些，读者也可以参考阅读笔者的其他博文。
（全文完，本文地址：https://blog.csdn.net/zwgdft/article/details/83619905 ）
（版权声明：本人拒绝不规范转载，所有转载需征得本人同意，并且不得更改文字与图片内容。大家相互尊重，谢谢！）
Bruce
2018/12/03 晚
elasticsearch最佳实践之index与shard设计(代码片段)
Index与Shard，这两个概念在《Elasticsearch最佳实践之核心概念与原理》一文有详细的介绍，分别对应了Elasticsearch的两种数据组织方式：逻辑组织和物理组织。逻辑层面上，Index与业务数据的结构、类型、使用方... 查看详情
php核心技术与最佳实践——全局浏览
难得买到并喜欢一本好书，‘PHP核心技术与最佳实践’。几天时间，先看了个大概，总结一下整体是什么样子的，怎么看怎么学。 1、总共14章； 2、第1、2章讲PHP的OOP；其中第一章侧重于PHP的OOP与Java等的对比，面... 查看详情
elasticsearch最佳实践之使用场景
序 最开始使用Elasticsearch是两年多前，在一家创业公司负责数据系统的建设，当时也有写一些博文来分享使用方法。然而回过头去想，觉得当时的很多认知不够深入，或者说是当时的业务场景下没有遇到更多的... 查看详情
elasticsearch最佳实践之使用场景
序 最开始使用Elasticsearch是两年多前，在一家创业公司负责数据系统的建设，当时也有写一些博文来分享使用方法。然而回过头去想，觉得当时的很多认知不够深入，或者说是当时的业务场景下没有遇到更多的... 查看详情
redis核心原理与实践--列表实现原理之ziplist(代码片段)
列表类型可以存储一组按插入顺序排序的字符串，它非常灵活，支持在两端插入、弹出数据，可以充当栈和队列的角色。>LPUSHfruitapple(integer)1>RPUSHfruitbanana(integer)2>RPOPfruit"banana">LPOPfruit"apple"本文探... 查看详情
15分钟掌握elasticsearch8大核心概念与基础用法
...tic已经形成了一个较为庞大的生态，这个生态的核心就是Elasticsearch。初学者的重点就是如何快速地了解并使用Elasticsearch，本文总结了Elasticsearch的8大核心概念和安装、用法，15分钟实现入门并且掌握Elasticsearch的简单使用。Elastics... 查看详情
elasticsearchelasticsearch日志场景最佳实践(代码片段)
1.概述转载：Day12-Elasticsearch日志场景最佳实践相似文章：【Elasticsearch】Elasticsearch最佳实践系列之分片恢复并发故障Elasticsearch可广泛应用于日志分析、全文检索、结构化数据分析等多种场景，大幅度降低维护多套专用... 查看详情
elasticsearch核心概念与rest风格说明(代码片段)
ElasticSearch核心概念与REST风格说明ElasticSearch核心概念索引(index)类型(type)映射(mapping)文档(document)字段集群节点分片和副本倒排索引IK分词器(elasticsearch插件)使用ik_smartik_max_wordstandardRest风格说明基本Rest命令说明关于索引的基本操作... 查看详情
zabbix最佳实践一：zabbixserver的安装与配置(代码片段)
一.概述在开始之前，一些概念和定义需要我们提前了解一下（以下内容摘自官方网站）。1.1几个概念架构Zabbix由几个主要的功能组件组成，其职责如下所示。ServerZabbixserver是Zabbixagent向其报告可用性、系统完整性信息和统计信息... 查看详情
生产环境中的 Elasticsearch 配置和最佳实践
】生产环境中的Elasticsearch配置和最佳实践【英文标题】：Elasticsearchconfigurationandbestpracticesinproduction【发布时间】：2022-01-1405:49:44【问题描述】：我是使用ELK堆栈的新手，我正在处理存储在物理服务器上的10TB，所以如果有关于多... 查看详情
elasticsearch全文检索—elasticsearch核心概念(代码片段)
ElasticSearch核心概念-Cluster 1）代表一个集群，集群中有多个节点，其中有一个为主节点，这个主节点是可以通过选举产生的，主从节点是对于集群内部来说的。es的一个概念就是去中心化，字面上理解就是无中心节点，这是对... 查看详情
《深度学习核心技术与实践》pdf资料分享学习+猿辅导研究团队
《深度学习核心技术与实践》主要介绍深度学习的核心算法，以及在计算机视觉、语音识别、自然语言处理中的相关应用。作者:猿辅导研究团队《深度学习核心技术与实践》PDF，530页，带书签目录，文字可以复制。配套代码和... 查看详情
《angularjs深度剖析与最佳实践》笔记:第二章概念介绍
第二章概念介绍2.1什么是UI?用户界面包括内容(静态信息+动态信息),外观,交互.在前端技术栈中分别由HTML,CSS和JS负责.进一步抽象,分别对应于MVC三个主要部分:Model,View和Controller对应到AngularJS中, 内容:静态内容---模板动态内容---s... 查看详情
java书单
1.《深入理解Java虚拟机：JVM高级特性与最佳实践》2.《HotSpot实战》3.《Java并发编程实战》4.《Java多线程编程核心技术》5.《EffectiveJava中文版》6.《深入分析JavaWeb技术内幕》7.《大型网站技术架构核心原理与案例分析》8.《大型网... 查看详情
大数据生态安全框架的实现原理与最佳实践（下篇）
大数据生态安全框架的实现原理与最佳实践（下篇）前言数字化转型大背景下，数据作为企业重要的战略资产，其安全的重要性不言而喻。我们会通过系列文章，来看下大数据生态中安全框架的实现原理与最... 查看详情
大数据生态安全框架的实现原理与最佳实践（下篇）
大数据生态安全框架的实现原理与最佳实践（下篇）前言数字化转型大背景下，数据作为企业重要的战略资产，其安全的重要性不言而喻。我们会通过系列文章，来看下大数据生态中安全框架的实现原理与最... 查看详情
guavacache原理分析与最佳实践(代码片段)
...的优秀框架比较他们各自的优缺点、应用场景、项目中的最佳实践以及原理分 查看详情
图计算思维与实践核心概念与算法
前言在前文《图计算思维与实践（一）概览》中，我们介绍了以知识图谱、网络分析为主的图计算的应用，阐述了图思维的方式。本文我们将进入第二部分：图相关的核心概念与算法，这些是进行图探索的... 查看详情