ElasticSearch 入门
简介
ElasticSearch，一个基于Lucene构建的搜索和分析引擎，可以高效、可靠地处理、存储和检索海量数据。它的设计目标是简单、高效地存储、搜索和分析大量数据。ElasticSearch支持近实时搜索，这意味着一旦数据被索引，用户就可以在极短的时间内对其进行搜索，从而保证了数据的时效性和相关性。ElasticSearch支持分布式系统，可以扩展到数十个甚至数百个节点，从而支持处理PB级别的数据，无论是存储还是检索，都能保持高效的性能。为了方便与各种编程语言和应用程序集成，ElasticSearch提供了灵活的RESTful API。
优点：
- 高性能：ElasticSearch具有快速的搜索和分析能力，能够处理大规模的数据。它基于Lucene构建，提供了高性能的倒排索引和搜索算法，使得数据检索变得迅速而高效。
- 可扩展性：ElasticSearch是一个分布式系统，可以轻松地扩展到多个节点，以处理大量的数据和请求。通过增加节点和配置集群，它可以实现水平扩展，满足不断增长的数据量和查询需求。
- 实时性：ElasticSearch支持近实时搜索，这意味着数据在索引后可以在几秒钟内被搜索到。它提供了实时更新和索引的功能，使得用户可以快速获取最新的信息。
- 分布式：ElasticSearch使用分布式架构，可以在多个节点上存储和处理数据，提高了系统的可靠性和容错性。它采用副本机制和分片技术，确保数据的高可用性和持久性。
- 易用性：ElasticSearch提供了简单易用的API和丰富的查询语言，使得开发人员可以快速上手并进行复杂的数据分析。它支持RESTful接口，可以轻松地与各种编程语言和应用程序集成。
- 开源免费：ElasticSearch是开源免费的软件，用户可以自由使用和定制。这为开发人员提供了更大的灵活性和成本效益。
- 生态系统丰富：ElasticSearch的生态系统非常丰富，有大量的第三方插件和工具可供选择和使用。这些插件和工具可以扩展和增强ElasticSearch的功能，满足各种特定需求。
ElasticSearch 的基本概念
存储
- 索引：类似于MySQL中的表
- 文档：类似于MySQL中的一行数据
- 一个索引下可以有多个文档
部署
- 分片：类似于MySQL等关系型数据库的分库分表，根据一定的规则将数据落在不同的库/表里，降低单表压力
- 副本：类似于数据库的从库。防止节点崩溃数据丢失
倒排索引：相对于正排索引而言
- 正排索引：找到数据了才知道它的属性。比如老师找到班长了，知道了他的年级排名。
- 倒排索引：从属性出发，找到包含这些属性的数据。比如老师根据年级排名在前100这个条件，得到了一些学生的信息。
- 倒排索引的例子：文档的属性有姓名和个性签名，那么在ES里存储的时候，就会存储在两张表格里，name表格存储姓名的相关信息，关键词是name的值；signature表格存储个性签名的相关信息，关键词是signature的值。预期搜索为，如果搜索的条件是name=Jeffy，就去name的表格里查找；如果搜索的条件为signature=“Life is a movie”，就去signature的表格里查找。而且为了提高查找的速度，表格通常会排序。
FST：ES存储表格的数据结构就是FST，是共享后缀的前缀树。
前缀树：相同前缀的合并
FST：相同前缀的合并，相同后缀的也链接。
ElasticSearch 的查询流程
先介绍下节点和实例的概念，在ES服务里，一个节点一般指一个实例，而一个实例可以扮演多种角色。主要有以下几种角色：
- 主节点：创建索引
- 候选主节点：相当于主节点的从节点，当主节点挂掉以后启用该节点
- 数据节点：存储数据的节点
- 协调节点：因为数据在存储的时候是分片的，比如name=Tom的文档在数据节点1上，name=Jeffy的文档在数据节点2上，请求查询数据的时候并不知道该查询哪个数据节点，协调节点就负责协调请求的处理过程，类似于为了解决分库分表查询的MySQL代理
所以，查询的过程就是，请求打到协调节点上，协调节点再请求各个数据节点拿到数据
ElasticSearch 的更新流程
这里姑且把插入文档和更新文档都叫做更新流程，也就是把数据写入到ES的过程，主要分为以下几步：
- 文档被写到Buffer里
- 当客户端发送一个写入请求（如索引一个文档）到ElasticSearch时，该文档首先会被写入到一个内部缓冲区（Buffer）中。这个阶段，文档还没有被持久化到磁盘，只是在内存中等待进一步的处理。
- 定时刷新数据到Page Cache里
- 也就是
refresh过程。在ElasticSearch中，refresh是一个周期性的操作，默认是每秒执行一次。它的作用是将Buffer中的文档刷新（flush）到操作系统的页面缓存（Page Cache）中。 - 一旦数据被刷新到Page Cache，它就变得可以被搜索了。这是因为ElasticSearch在执行搜索查询时，会首先从Page Cache中读取数据。
- 但是，需要注意的是，虽然数据在Page Cache中是可以被搜索的，但它还没有被持久化到磁盘。这意味着如果此时发生系统故障或节点宕机，这些数据可能会丢失。
- 在refresh过程中，Buffer中的数据会被组织成一个个的段（Segment）。每个段都是一个不可变的、持久化的数据结构，包含多个文档。这些段是ElasticSearch索引的基本存储单位。
- 也就是
- 刷新到磁盘里：
- 数据从Page Cache刷新到磁盘的操作通常是由操作系统的文件系统自动处理的，而不是由ElasticSearch直接控制的。当操作系统认为需要将这些数据写入磁盘时（例如，当Page Cache中的数据量达到一定阈值时），它会异步地将数据写入磁盘。
- 一旦数据被写入磁盘，它就变得持久化了，即使发生系统故障或节点宕机，数据也不会丢失。
因为refresh的过程是定时的，所以ES实际上做到的不是实时的查询，而是近实时的查询
