1、核心功能

• 全文搜索：Elasticsearch 最重要的功能之一是全文搜索。它能够对文本数据进行高效的索引和搜索，支持复杂的查询语法，例如模糊搜索、短语匹配、多字段搜索等。
• 实时分析：数据写入 Elasticsearch 后，几乎可以立即被搜索和分析。这种实时性使得它非常适合需要快速响应的场景，如实时监控、日志分析等。
• 分布式架构：Elasticsearch 是一个分布式系统，数据被分片存储在多个节点上，能够自动进行负载均衡和容错。这种架构不仅提高了系统的可扩展性，还增强了数据的可靠性和可用性。

 

2、主要用途

• 日志分析：Elasticsearch 常用于收集、存储和分析日志数据。结合 Logstash（用于日志采集和处理）和 Kibana（用于可视化），它们共同构成了著名的 ELK Stack，广泛应用于日志管理和监控系统。
• 搜索引擎：它可以作为网站或应用程序的后端搜索引擎，提供快速、准确的搜索功能。例如，电商网站可以通过 Elasticsearch 实现商品搜索、自动补全等功能。
• 数据分析：Elasticsearch 支持对海量数据进行聚合分析，可以用于业务数据分析、用户行为分析等场景。它能够快速生成报表、统计图表等，帮助用户洞察数据背后的规律。

 

3、数据模型

• 文档（Document）：Elasticsearch 中的数据以 JSON 格式的文档存储，每个文档都有一个唯一标识符（ID）。
• 索引（Index）：类似于关系数据库中的“数据库”，是一个逻辑命名空间，用于存储和管理文档集合。
• 分片（Shard）：为了实现分布式存储，索引被分成多个分片，每个分片可以独立存储在不同的节点上。
• 副本（Replica）：分片的副本用于提高系统的容错能力和读取性能。

 

4、优势

• 高性能：Elasticsearch 的倒排索引结构使其能够快速处理复杂的查询，即使在海量数据的情况下也能保持高效的性能。
• 易用性：它提供了丰富的 RESTful API，方便开发者进行数据操作和管理。同时，Kibana 提供了直观的可视化界面，降低了使用门槛。
• 灵活性：支持多种数据类型（如文本、数字、日期等），并且可以根据需求灵活调整索引结构和查询逻辑。

 

5、映射

在 Elasticsearch 中，映射（Mapping） 是定义索引中字段及其属性的过程，类似于关系型数据库中的表结构定义。映射决定了字段的数据类型、如何索引这些字段以及如何处理这些字段的查询。以下是关于 Elasticsearch 映射的核心内容：

5.1 映射的作用

• 定义字段类型：指定字段的数据类型（如 text、keyword、integer、date 等），这些类型决定了字段如何被索引和搜索。
• 控制字段索引方式：可以指定字段是否需要建立倒排索引、是否存储原始值、是否支持排序和聚合等。
• 优化搜索性能：通过合理配置映射，可以提高查询效率和相关性。

5.2 字段数据类型

Elasticsearch 提供了多种字段类型，每种类型适用于不同的数据处理需求：

• 文本类型：
  • text：用于全文搜索，会经过分词器处理。
  • keyword：用于精确匹配，不会分词，适合排序和聚合。
• 数值类型：如 integer、float、double 等。
• 日期类型：如 date、datetime。
• 布尔类型：boolean。
• 复杂类型：
  • object：用于嵌套对象。
  • nested：用于独立索引对象数组。
• 地理位置类型：如 geo-point、geo-shape。

5.3 动态映射与显式映射

• 动态映射：当索引新文档时，Elasticsearch 会自动根据字段值推断其类型并创建映射。可以通过设置 dynamic 属性控制动态映射的行为：
  • true：自动创建新字段。
  • false：忽略新字段。
  • strict：抛出异常。
• 显式映射：在创建索引时预先定义字段的映射规则，这种方式更灵活且能避免动态映射可能带来的类型推断错误。

5.4 映射设置

映射中可以包含以下设置：

• index：是否将字段索引，使其可搜索。
• store：是否存储字段的原始值。
• doc_values：是否为字段创建列式存储，用于排序和聚合。
• analyzer：指定字段的分词器。
• copy_to：将字段内容复制到其他字段，便于联合搜索。

5.5 多字段与元字段

• 多字段：一个字段可以有多个用途（如 text 和 keyword），通过 fields 属性定义。
• 元字段：如 _id、_source、_routing 等，用于控制文档的存储和检索。

5.6 映射的创建与管理

• 在创建索引时，可以通过 PUT 请求定义映射。
• 可以通过 _mapping API 查看或更新索引的映射。

5.7 映射优化建议

• 显式定义映射：避免动态映射带来的类型推断错误。
• 合理选择字段类型：根据查询需求选择合适的字段类型，例如使用 keyword 而非 text 进行排序。
• 控制字段数量：过多的字段会增加存储和查询开销。

 

6、 倒排索引

6.1 倒排索引的基本概念

倒排索引由两部分组成：

• 单词列表（Term List）：包含所有单词的集合，通常是经过分词处理后的唯一单词。

• 倒排记录表（Inverted List）：每个单词对应一个列表，记录该单词在哪些文档中出现，以及出现的位置。

  简单来说，倒排索引是一种“单词到文档”的映射关系，它将单词作为索引键，将文档的引用作为索引值。

6.2 倒排索引的工作原理

假设我们有以下三个文档：

文档1：Elasticsearch 是一个强大的搜索引擎。
文档2：Elasticsearch 基于 Lucene 构建。
文档3：Lucene 是一个开源的全文检索库。

构建倒排索引的步骤：

1. 分词：将每个文档的文本内容拆分成单词（或词汇单元）。

   • 文档1：Elasticsearch、是、一个、强大的、搜索引擎
   • 文档2：Elasticsearch、基于、Lucene、构建
   • 文档3：Lucene、是、一个、开源的、全文检索库

2. 建立索引：将单词作为键，文档的引用作为值，构建倒排索引。

   Elasticsearch -> [文档1, 文档2]
   是 -> [文档1, 文档3]
   一个 -> [文档1, 文档3]
   强大的 -> [文档1]
   搜索引擎 -> [文档1]
   基于 -> [文档2]
   Lucene -> [文档2, 文档3]
   构建 -> [文档2]
   开源的 -> [文档3]
   全文检索库 -> [文档3]
   

3. 查询：当用户输入查询词时，搜索引擎通过倒排索引快速找到包含该词的文档列表。

   • 查询“Elasticsearch”：返回 [文档1, 文档2]
   • 查询“Lucene”：返回 [文档2, 文档3]

6.3 倒排索引的优势

• 高效查询：通过单词到文档的直接映射，查询速度非常快，适合处理海量数据。
• 灵活性：可以轻松扩展到多字段搜索、模糊搜索等复杂查询。
• 节省空间：相比正排索引（文档到单词的映射），倒排索引通常更紧凑，占用存储空间更小。

6.4 倒排索引的实现细节

• 分词：将文本拆分成单词的过程。分词的质量直接影响倒排索引的效果。不同的语言和应用场景可能需要不同的分词策略。
• 停用词过滤：忽略一些常见的、对搜索意义不大的单词（如“的”、“是”、“在”等），以减少索引大小和提高查询效率。
• 词干提取和同义词处理：将单词归一化为基本形式（如“running”归一化为“run”），或者将同义词合并，以提高搜索的召回率。
• 存储优化：倒排记录表通常会进行压缩和编码，以减少存储空间和提高读取速度。

6.5 倒排索引的局限性

• 更新成本高：倒排索引是静态的，当文档更新（如添加、删除或修改内容）时，需要重新构建索引，这可能是一个耗时的过程。
• 不适合范围查询：倒排索引主要用于单词匹配，对于数值范围查询或地理查询等，可能需要额外的索引结构（如 B+树）。

 

7、段

段是 Lucene（Elasticsearch 的底层搜索引擎库）中倒排索引的物理存储单元。每个段是一个独立的、不可变的倒排索引文件，包含了一部分文档的索引信息。段是 Elasticsearch 存储和检索数据的基础。

7.1 段的特点

• 不可变性：一旦段被创建，它的内容是不可修改的。如果需要更新数据，Elasticsearch 会创建新的段来存储变更后的数据。
• 独立性：每个段都是一个完整的倒排索引，可以独立进行搜索操作。这种设计使得段可以并行处理查询，从而提高搜索效率。
• 合并机制：为了优化性能和存储空间，Elasticsearch 会定期将多个小段合并为一个更大的段。这个过程称为 段合并（Segment Merge）。

7.2 段的增删改

索引文件分段存储并且不可修改，那么新增、更新和删除如何处理呢

• 新增，新增很好处理，由于数据是新的，所以只需要对当前文档新增一个段就可以了。
• 删除，由于不可修改，所以对于删除操作，不会把文档从旧的段中移除而是通过新增一个 .del 文件，文件中会列出这些被删除文档的段信息。这个被标记删除的文档仍然可以被查询匹配到， 但它会在最终结果被返回前从结果集中移除。
• 更新，不能修改旧的段来进行反映文档的更新，其实更新相当于是删除和新增这两个动作组成。会将旧的文档在 .del 文件中标记删除，然后文档的新版本被索引到一个新的段中。可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就会被移除。

7.3 段的不变性的优缺点

优点

• 不需要锁。如果你从来不更新索引，你就不需要担心多进程同时修改数据的问题。
• 一旦索引被读入内核的文件系统缓存，便会留在哪里，由于其不变性。只要文件系统缓存中还有足够的空间，那么大部分读请求会直接请求内存，而不会命中磁盘。这提供了很大的性能提升。
• 其它缓存(像 Filter 缓存)，在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建，因为数据不会变化。
• 写入单个大的倒排索引允许数据被压缩，减少磁盘 I/O 和需要被缓存到内存的索引的使用量。

缺点

• 当对旧数据进行删除时，旧数据不会马上被删除，而是在 .del 文件中被标记为删除。而旧数据只能等到段更新时才能被移除，这样会造成大量的空间浪费。
• 若有一条数据频繁的更新，每次更新都是新增新的标记旧的，则会有大量的空间浪费。
• 每次新增数据时都需要新增一个段来存储数据。当段的数量太多时，对服务器的资源例如文件句柄的消耗会非常大。
• 在查询的结果中包含所有的结果集，需要排除被标记删除的旧数据，这增加了查询的负担。

7.4 延迟写策略

为了提升写的性能，ES 并没有每新增一条数据就增加一个段到磁盘上，而是采用延迟写的策略。

为了避免丢失数据，Elasticsearch 添加了事务日志（Translog），事务日志记录了所有还没有持久化到磁盘的数据。

1. 一个新文档被索引之后，先被写入到内存中，但是为了防止数据的丢失，会追加一份数据到事务日志Translog中。
   不断有新的文档被写入到内存，同时也都会记录到事务日志中。这时新数据还不能被检索和查询。

2. 当达到默认的刷新时间或内存中的数据达到一定量后，会触发一次 Refresh，将内存中的数据以一个新段形式刷新到文件缓存系统中并清空内存。这时虽然新段未被提交到磁盘，但是可以提供文档的检索功能且不能被修改。

3. 随着新文档索引不断被写入，当日志数据大小超过 512M 或者时间超过 30 分钟时，会触发一次 Flush。
   内存中的数据被写入到一个新段同时被写入到文件缓存系统，文件系统缓存中数据通过 Fsync 刷新到磁盘中，生成提交点，日志文件被删除，创建一个空的新日志。

通过这种方式当断电或需要重启时，ES 不仅要根据提交点去加载已经持久化过的段，还需要根据Translog 里的记录，把未持久化的数据重新持久化到磁盘上，避免了数据丢失的可能。

7.5 段合并

由于自动刷新流程每秒会创建一个新的段 ，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。

每一个段都会消耗文件句柄、内存和 CPU 运行周期。更重要的是，每个搜索请求都必须轮流检查每个段然后合并查询结果，所以段越多，搜索也就越慢。

Elasticsearch 通过在后台定期进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档不会被拷贝到新的大段中。合并的过程中不会中断索引和搜索。

段合并在进行索引和搜索时会自动进行，合并进程选择一小部分大小相似的段，并且在后台将它们合并到更大的段中，这些段既可以是未提交的也可以是已提交的。

合并结束后老的段会被删除，新的段被 Flush 到磁盘，同时写入一个包含新段且排除旧的和较小的段的新提交点，新的段被打开可以用来搜索。

段合并的计算量庞大， 而且还要吃掉大量磁盘 I/O，段合并会拖累写入速率，如果任其发展会影响搜索性能。Elasticsearch 在默认情况下会对合并流程进行资源限制，所以搜索仍然有足够的资源很好地执行。

 

8、文档分片、路由和副本

8.1 分片

ES 支持 PB 级全文搜索，当索引上的数据量太大的时候，ES 通过水平拆分的方式将一个索引上的数据拆分出来分配到不同的数据块上，拆分出来的数据库块称之为一个分片。

在一个多分片的索引中写入数据时，通过路由来确定具体写入哪一个分片中，所以在创建索引的时候需要指定分片的数量，并且分片的数量一旦确定就不能修改。

ES 默认为一个索引创建 5 个主分片, 并分别为每个分片创建一个副本。

PUT /myIndex  
{  
   "settings" : {  
      "number_of_shards" : 5,  
      "number_of_replicas" : 1  
   }  
}  

ES 通过分片的功能使得索引在规模上和性能上都得到提升，每个分片都是 Lucene 中的一个索引文件，每个分片必须有一个主分片和零到多个副本。

8.2 路由

Elasticsearch 中，文档被分配到哪个分片是通过 路由（Routing） 机制决定的。默认情况下，Elasticsearch 使用文档的 _id 作为路由值，通过哈希函数和模运算来确定文档应该存储在哪个主分片上。

文档分片分配的具体过程

1. 计算路由值：

   • Elasticsearch 使用哈希函数（如 Murmur3）对文档的 _routing 值进行哈希处理。默认情况下，_routing 是文档的 _id，但也可以通过自定义 _routing 参数来指定。

2. 确定分片编号：

   • 哈希值通过模运算确定文档应该分配到的主分片编号，公式为：

     shard_num = hash(_routing) % num_primary_shards
     

     其中，num_primary_shards 是索引的主分片数量。

3. 路由到主分片：

   • 根据计算出的分片编号，文档被路由到对应的主分片上。主分片负责处理写入操作，并将数据同步到副本分片。

shard = hash(routing) % number_of_primary_shards  

这就解释了为什么我们要在创建索引的时候就确定好主分片的数量并且永远不会改变这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。

由于在 ES 集群中每个节点通过上面的计算公式都知道集群中的文档的存放位置，所以每个节点都有处理读写请求的能力。

在一个写请求被发送到某个节点后，该节点即为前面说过的协调节点，协调节点会根据路由公式计算出需要写到哪个分片上，再将请求转发到该分片的主分片节点上。

8.3 副本

副本就是对分片的 Copy，每个主分片都有一个或多个副本分片，当主分片异常时，副本可以提供数据的查询等操作。

主分片和对应的副本分片是不会在同一个节点上的，所以副本分片数的最大值是 N-1（其中 N 为节点数）。

对文档的新建、索引和删除请求都是写操作，必须在主分片上面完成之后才能被复制到相关的副本分片。

ES 为了提高写入的能力这个过程是并发写的，同时为了解决并发写的过程中数据冲突的问题，ES 通过乐观锁的方式控制，每个文档都有一个 _version （版本）号，当文档被修改时版本号递增。

一旦所有的副本分片都报告写成功才会向协调节点报告成功，协调节点向客户端报告成功。

 

9、集群

9.1 节点角色

每个节点既可以是候选主节点也可以是数据节点，通过在配置文件 …/config/elasticsearch.yml 中设置即可，默认都为 true。

node.master: true  //是否候选主节点  
node.data: true    //是否数据节点  

• 数据节点：负责数据的存储和相关的操作，例如对数据进行增、删、改、查和聚合等操作，所以数据节点（Data 节点）对机器配置要求比较高，对 CPU、内存和 I/O 的消耗很大。

• 主节点：负责创建索引、删除索引、跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点、追踪集群中节点的状态等，稳定的主节点对集群的健康是非常重要的。

  一个节点既可以是候选主节点也可以是数据节点，但是由于数据节点对 CPU、内存核 I/O 消耗都很大。所以如果某个节点既是数据节点又是主节点，那么可能会对主节点产生影响从而对整个集群的状态产生影响。

9.2 主节点选举

9.2.1 选举触发条件

主节点选举会在以下情况下触发：

• 集群初始化时：当集群首次启动且没有已知的主节点时。
• 当前主节点失效：主节点因故障、网络分区或宕机而不可用时。
• 集群拓扑变化：当有新的主节点候选节点加入或现有主节点候选节点离开时。

9.2.2 选举机制

关键步骤

1. 节点发现（Discovery Phase）：
   • 节点启动时，通过 discovery.seed_hosts 配置的种子节点列表发现集群中的其他节点。
   • 节点通过发送 ping 请求来确认其他节点的活动状态。
2. 预投票（Pre-Voting）：
   • 在正式选举前，潜在的主节点会发送预投票请求，评估是否有足够的支持。
   • 预投票阶段主要比较节点的任期（Term）和集群状态的版本号，选择最新的状态。
3. 正式投票（Election Phase）：
   • 满足预投票条件的节点会发起正式的选举请求（JoinRequest），请求其他节点的投票。
   • 节点会根据集群状态的最新性和节点的任期等信息决定投票给谁。
4. 确认新主节点（Master Confirmation）：
   • 一旦某个节点获得超过半数的投票，它将成为新的主节点，并向其他节点发送确认消息。
   • 其他节点更新状态，承认新的主节点。

9.3 状态更新

主节点是唯一一个能够更新集群状态的节点。主节点一次处理一个群集状态更新，应用所需的更改并将更新的群集状态发布到群集中的所有其他节点。当其他节点接收到状态时，先确认收到消息，但是不应用最新状态。如果主节点在规定时间（discovery.zen.commit_timeout ，默认30s）内没有收到大多数节点(discovery.zen.minimum_master_nodes)的确认，集群状态更新不被通过。

一旦足够的节点响应了更新的消息，新的集群状态(cluster state)被提交并且会发送一条消息给所有的节点。这些节点开始在内部应用新的集群状态。在继续处理队列中的下一个更新之前，主节点等待所有节点响应，直到超时(discovery.zen.publish_timeout，默认设置为30秒)。上述两个超时设置都可以通过集群更新设置api动态更改。

9.4 脑裂

如果由于网络或其他原因导致集群中选举出多个 Master 节点，使得数据更新时出现不一致，这种现象称之为脑裂，即集群中不同的节点对于 Master 的选择出现了分歧，出现了多个 Master 竞争

原因：

• 网络问题： 集群间的网络延迟导致一些节点访问不到 Master，认为 Master 挂掉了从而选举出新的 Master，并对 Master 上的分片和副本标红，分配新的主分片。
• 节点负载： 主节点的角色既为 Master 又为 Data，访问量较大时可能会导致 ES 停止响应（假死状态）造成大面积延迟，此时其他节点得不到主节点的响应认为主节点挂掉了，会重新选取主节点。
• 内存回收： 主节点的角色既为 Master 又为 Data，当 Data 节点上的 ES 进程占用的内存较大，引发 JVM 的大规模内存回收，造成 ES 进程失去响应

优化：

• 适当调大响应时间，减少误判。 通过参数 discovery.zen.ping_timeout 设置节点状态的响应时间，默认为 3s，可以适当调大。

  如果 Master 在该响应时间的范围内没有做出响应应答，判断该节点已经挂掉了。调大参数（如 6s，discovery.zen.ping_timeout:6），可适当减少误判。

• 选举触发。 我们需要在候选集群中的节点的配置文件中设置参数 discovery.zen.munimum_master_nodes 的值

  当小于这个值的时候，无法触发选举行为，集群无法使用，不会造成分片混乱的情况。

• 角色分离。 即是上面我们提到的候选主节点和数据节点进行角色分离，这样可以减轻主节点的负担，防止主节点的假死状态发生，减少对主节点“已死”的误判。

10、es和mysql的区别

10.1 适用场景

• MySQL：
  • 事务处理：适合需要事务支持的业务系统，如银行系统、电商平台等。
  • 结构化数据存储：适合存储关系型数据，如用户信息、订单记录等。
  • 复杂查询：适合需要多表连接、分组、排序等复杂查询的场景。
• Elasticsearch：
  • 全文搜索：适合需要快速全文搜索的场景，如搜索引擎、电商商品搜索等。
  • 日志分析：适合处理海量日志数据，如服务器日志、应用日志等。
  • 实时分析：适合需要实时数据分析的场景，如用户行为分析、监控系统等。

10.2 数据一致性

• MySQL：
  • 强一致性：数据在写入后立即可见，适合对一致性要求较高的场景。
• Elasticsearch：
  • 最终一致性：数据在写入后可能会有短暂的延迟，适合对实时性要求不高但对检索性能要求高的场景。
     

11、ES6、ES7、ES8对比

11.1 Elasticsearch 6.0

• 移除多类型支持：一个索引中只能有一个类型（_type），默认为 doc。
• 稀疏性 Doc Values：优化了列式存储，减少了字段稀疏性带来的开销。
• 索引排序（Index Sorting）：支持在索引阶段对文档进行排序，适合不经常变动的索引。
• 负载感知分片路由：基于节点负载动态调整请求分配，优化性能。
• 关闭索引的副本自动处理：确保数据可靠性。
• 顺序号支持：每个操作都有唯一顺序编号，便于数据一致性管理。
• 无缝滚动升级：支持平滑升级。

11.2 Elasticsearch 7.0

• 彻底移除 _type：索引不再支持多个类型，简化了数据模型。
• 默认单分片索引：新索引默认为单分片模式，优化资源使用。
• Lucene 8 集成：引入最新版本的 Lucene，提升索引和查询性能。
• 跨集群搜索优化：减少跨集群搜索的延迟。
• 集群协调改进：引入新的集群协调机制，提高稳定性。
• 内存管理增强：优化内存管理，防止内存溢出。
• SQL 支持增强：提供更强大的 SQL 查询能力。
• 安全功能改进：默认捆绑 JDK，简化环境配置。
• 评分脚本查询升级：引入 FunctionScore 2.0，增强查询灵活性。

11.3 Elasticsearch 8.0

• 原生支持 NLP：直接支持自然语言处理任务（如情感分析、命名实体识别），无需额外插件。
• 默认开启安全功能：自管理集群默认启用用户认证、授权和 TLS 加密。
• 存储空间优化：更新倒排索引编码，减少存储空间。
• 向量搜索增强：支持上传 PyTorch 模型，提供近似最近邻搜索（KNN）。
• 地理空间性能提升：优化 geo_point 和 geo_shape 的索引效率。
• API 改动：彻底删除 _type，兼容 7.x 的请求。
• 内置索引保护：增强对内置索引的保护，限制写入权限。

11.4 对比

版本对比总结

特性/版本	Elasticsearch 6.0	Elasticsearch 7.0	Elasticsearch 8.0
类型支持	单类型（doc）	完全移除 _type	完全移除 _type
索引默认分片数	5	1	1
安全功能	需手动配置	提供安全功能，需手动启用	默认启用安全功能
NLP 支持	需插件或脚本	有限支持	原生支持
向量搜索	有限支持	有限支持	原生支持，优化 KNN
存储优化	无	无	倒排索引优化，减少空间
地理空间性能	无优化	无优化	提升索引效率

 
如有错误，烦请指出，感谢！