Elasticsearch技术解析与实战

什么是Elasticsearch

Elasticsearch 是分布式搜索和分析引擎。
Elasticsearch 为各种数据类型提供接近实时的搜索和分析。而且，随着你数据和查询量的增长，Elasticsearch 分布式的特性允许你的部署能随着它无缝地增长匹配。

Elasticsearch 是一种分布式文档存储。Elasticsearch 不用列数据行存储信息，而是存储已序列化为 JSON 文档的复杂数据结构。

Elasticsearch 被构建为始终可用，并且能按需扩展。它是通过天然的分布式来实现的。你可以通过向集群添加服务器（节点）来增加容量，Elasticsearch 自动分布你的数据和查询到所有可用节点。

这是如何工作的？实际来讲，一个 Elasticsearch 索引只是一个或多个物理分片的逻辑组，其中每个分片实际上是一个独立索引。通过将索引中的文档分布在多个分片上，并将这些分片分布在多个节点上，Elasticsearch 能确保冗余，这既能防止硬盘损坏也能在节点添加到集群时增加查询容量。随着集群的伸缩，Elasticsearch 自动迁移分片以重新平衡集群。

有两种类型的分片：主分片和副本。索引中的每个文档都属于一个主分片。一个副本分片是一个主分片的复制。副本提供了数据冗余复制，以防止硬件故障，并增加服务读取请求——如搜索或者检索文档——的容量。

对于分片大小和索引主分片数量的配置，有许多性能的考虑和权衡。分片越多，仅维护这些索引的开销就越大。分片越大，在 Elasticsearch 需要重平衡集群时，移动分片的耗时越久。

Elasticsearch技术解析与实战

Elasticsearch入门

Elasticsearch是什么

Elasticsearch 是一个基于Lucene构建的开源、分布式、restful接口全文搜索引擎。
Elasticsearch 还是一个分布式文档数据库。

Elasticsearch 的优点有：

• 横向可扩展
  可以通过增加机器，扩展集群
• 分片机制提供更好的分布性
  同一个索引分成了多个分片（sharding），这点类似于HDFS的块机制。分而治之的方式可以提升处理效率
• 高可用
  提供复制（replica）机制，一个分片可以设置多个副本，使得某台服务器在宕机后，集群仍然可以正常运转，并会把服务器宕机丢失的数据信息复制恢复到其他可用节点上。

全文搜索

全文搜索（Full-Text Search）是一种在数据库、文件集合或任何大量文本数据中搜索特定信息的技术。它允许用户输入一个或多个关键词，并快速找到包含这些关键词的文档或文本片段。

与简单的字符串搜索或基于正则表达式的搜索相比，全文搜索具有以下几个显著特点：

• 索引化：全文搜索系统通常会对存储的文本数据进行索引处理。这意味着系统会在文本数据中识别出关键词，并将这些关键词与它们在文本中的位置信息存储在索引数据库中。索引数据库可以大大加快搜索过程，因为它允许系统直接定位到包含特定关键词的文本片段，而无需遍历整个文本数据集。
• 自然语言处理：为了提高搜索的准确性和相关性，全文搜索系统通常会采用自然语言处理技术（如分词、词干提取、同义词替换等）来处理文本数据。这些技术有助于消除文本中的冗余信息，提高搜索效率，并更好地匹配用户的查询意图。
• 排序和评分：全文搜索系统不仅返回包含查询关键词的文档，还会根据一定的算法对这些文档进行排序和评分。排序和评分的依据可能包括关键词在文档中的出现频率、关键词在文档中的位置、文档的长度等多个因素。通过这种方式，系统可以将与用户查询最相关的文档排在前面，提高用户的搜索体验。
• 支持复杂查询：全文搜索系统通常支持复杂的查询语法，允许用户构造包含多个关键词、逻辑运算符（如AND、OR、NOT）和通配符等的查询语句。这使得用户能够更精确地表达他们的搜索需求，并找到更符合他们期望的搜索结果。

lucene

lucene 是全球使用最广的全文搜索引擎开源库。

lucene 倒排索引

Lucene倒排索引是一种将文档集合中的每个词都映射到包含该词的文档列表的数据结构。这种索引方式与传统的正排索引（通过文档内容，查询文档关键词）相反，因此被称为“倒排索引”。

倒排索引一般表示为一个关键词，然后是它的频度（出现的次数），位置（出现在哪个文档中，及相关的作者、日期等信息）。

实现方式和原理

• 分词与标准化：对文档进行分词处理，并进行大小写转换、去停用词、词干提取等标准化操作。
• 索引构建：将处理后的词项按照词典序进行排序，并为每个词项建立倒排索引表。索引表通常使用基于内存的数据结构进行存储和查询，如哈希表、B树等。
• 查询处理：对查询语句进行分析和标准化处理，并在倒排索引表中查找包含查询关键词的文档列表。通过排序、过滤等操作得出最终的查询结果。

优化措施

为了减小索引文件的大小和提高查询效率，Lucene对索引还采用了多种优化措施：

• 压缩技术：对索引文件中的关键词和数字进行压缩处理，以减小索引文件的大小。
• 跳表技术：在索引表中引入跳表结构（如SkipData），以实现快速跳转和定位。
• 分块存储：将索引数据分块存储在不同的文件中（如.doc、.pay、.pos等后缀文件），以便于管理和查询。

示例：
假设有两篇文章。
文章1的内容为：Toms lives in GuangZhou，I live in GuangZhou too.
文章2的内容为：He once lived in Shanghai.

步骤：
1.取得关键词
文章1的所有关键词为：[tom][live][guangzhou][i][live][guangzhou]
文章2的所有关键词为：[he][live][shanghai]
2.建立倒排索引

索引

在Elasticsearch中，索引（Index）是其核心的数据结构，用于存储和管理数据。

索引是由多个分片（shards）组成的，这些分片可以是主分片（primary shards）或副本分片（replica shards），用于提高数据的可用性、可靠性和搜索性能。

索引的特点

• 分布式存储：Elasticsearch的索引是分布式的，这意味着索引可以被分成多个部分，这些部分可以分散存储在不同的节点上，从而实现数据的水平扩展。
• 近实时搜索：一旦文档被索引，它就可以被几乎实时地搜索到。虽然Elasticsearch的索引操作是异步的，但通常这些操作会很快完成，使得新添加的数据几乎立即可用于搜索。
• 高度可扩展：由于索引是分布式的，Elasticsearch可以很容易地通过添加更多的节点来扩展索引的容量和性能。
• 容错性：通过副本分片，Elasticsearch提供了数据的高可用性和容错性。如果某个节点或分片失败，副本分片可以接管其工作，确保数据的连续性和搜索的可用性。
• 灵活的数据模型：Elasticsearch使用JSON文档来存储数据，这为用户提供了极高的灵活性，因为几乎任何类型的数据都可以被索引和搜索。

索引优化
为了获得最佳的性能和存储效率，Elasticsearch提供了多种索引优化技术，包括：

• 分片：通过合理设置索引的分片数量，可以平衡数据的分布和搜索性能。
• 压缩：Elasticsearch支持对索引数据进行压缩，以减少存储空间的占用和提高搜索速度。
• 缓存：Elasticsearch使用多种缓存机制来加速搜索和聚合操作，包括查询缓存、字段数据缓存和请求缓存等。
• 性能调优：通过对Elasticsearch的配置和硬件进行优化，可以进一步提高索引的性能和稳定性。

文档

在Elasticsearch中，文档是一个JSON格式的字符串，它表示了一个可以被索引的实体。文档是Elasticsearch中的最小信息单元，可以是一个完整的网页、一篇博客文章、一个商品信息或者任何你想要索引的JSON格式的数据。

文档的结构
每个文档都有一个唯一的标识符，即_id字段。Elasticsearch通过_index和_id的组合来唯一标识一个文档。

文档的索引
索引是一个文档的集合，类似于传统关系数据库中的数据库或表，而一个文档类似于表的一条记录。

版本号

在Elasticsearch中，每个文档都拥有一个版本号（_version字段），用于管理和控制文档的更新和并发访问。这个版本号在文档被索引、更新或删除时自动递增，为文档的并发控制和历史变更追踪提供了基础。

文档版本号的作用

• 追踪历史变更：通过版本号，可以回溯文档的历史变更，了解文档从创建到最新状态的完整变更历史。
• 避免数据覆盖：在并发环境下，多个客户端可能同时操作同一个文档。文档版本号可以避免数据的覆盖，确保每次更新都是基于最新的文档版本进行的。
• 并发控制：Elasticsearch使用基于MVCC（Multi-Version Concurrency Control，多版本并发控制）的方式来实现文档的并发访问和更新。通过版本号，可以实现乐观并发控制，避免冲突和丢失更新的问题。

乐观并发控制
乐观并发控制（Optimistic Concurrency Control, OCC）是一种并发控制机制，它假设在绝大多数情况下，对同一个数据对象操作的冲突是较少的。Elasticsearch使用版本号来实现乐观并发控制。当进行写操作时，Elasticsearch会检查请求的版本号和实际存储的版本号是否一致，如果一致则进行更新操作，否则返回版本冲突的错误。这种方式避免了数据库级别的锁定，提高了并发性能。

外部版本控制
除了内部版本号外，Elasticsearch还支持外部版本控制。当文档的版本号由外部系统（如数据库）管理时，可以在索引、更新或删除文档时指定外部版本号。Elasticsearch会检查外部版本号与当前存储的版本号之间的关系，以决定是否接受操作。

分片选择机制

操作文档时分片的选择机制主要涉及文档的索引（写入）和查询（读取）过程。

一、索引（写入）过程

1. 哈希函数决定分片：

   • 当一个文档被索引到Elasticsearch时，Elasticsearch会使用一个哈希函数来计算文档应该存储在哪个主分片中。
   • 这个哈希函数通常基于文档的唯一标识符（如文档的ID）来计算出一个哈希值。
   • 然后，根据这个哈希值与主分片数量取模的结果，将文档存储到相应的主分片中。
   • 这种方式确保了文档的分布式存储，使得每个主分片都能均匀地分担文档的存储负载。

2. 路由策略：

   • 除了哈希函数，Elasticsearch还允许通过路由策略来决定文档应该存放到哪个分片中。
   • 路由策略可以根据文档的某个字段的值（如用户ID）来确定文档所在的分片。
   • 这使得具有相同路由键（如用户ID）的文档会被存储到同一个分片中，便于后续的用户相关查询。

3. 写入过程：

   • 所有的写操作（如索引和删除）都首先作用于主分片。
   • 主分片处理写请求，将数据写入到分片中。如果主分片处理失败，则整个操作直接失败
   • 然后，主分片将写操作同步到所有的副本分片，确保数据的一致性。
   • 虽然副本分片的写入是异步进行的（即不需要等待所有副本分片都写入成功才返回给客户端），但Elasticsearch允许通过wait_for_active_shards参数来指定写入操作需要等待的活跃副本分片数量。默认情况下，这个参数的值通常设置为“大多数”（majority），意味着在确认写入成功之前，需要等待足够数量的副本分片（通常是大多数副本分片）报告写入成功。
   • 当所有副本分片确认写操作后，Elasticsearch返回写操作的结果。
   • 在这个过程中，Elasticsearch的默认行为是，只要主分片写入成功，并且满足wait_for_active_shards参数指定的副本分片数量（通常是大多数副本分片）也成功写入，那么整个写入操作就被认为是成功的
   • 需要注意的是，虽然写入操作在主分片写入成功后就被认为是成功的，但Elasticsearch仍然会继续努力将更改同步到剩余的副本分片。如果某个副本分片长时间无法同步成功，Elasticsearch可能会将其标记为不可用，并在集群状态中反映出来。此时，可能需要管理员介入来检查并解决相关问题。

二、查询（读取）过程

1. 协调节点路由请求：

   • 客户端将查询请求发送到Elasticsearch集群中的任意节点，该节点作为协调节点处理请求。
   • 协调节点根据查询请求和分片信息，将请求路由到相关的主分片和副本分片。

2. 分片并行处理查询：

   • 主分片和副本分片并行处理查询请求，返回查询结果。
   • Elasticsearch会选择一个分片副本来处理查询，以平衡负载和提高查询性能。
   • 在某些场景下，Elasticsearch可能会选择当前集群状态下能快速响应的副本，从而使搜索快速响应。

3. 协调节点汇总结果：

   • 协调节点汇总所有分片的查询结果，并返回给客户端。

三、分片选择的影响因素

• 分片数量：分片数量越多，每个分片上的数据量就越少，但管理开销也会增加。因此，需要合理设置分片数量以平衡性能和管理开销。
• 副本数量：副本数量可以提高数据的可用性和查询性能，但也会增加存储和复制的开销。
• 集群状态：集群的当前状态（如节点的健康状况、负载情况等）也会影响分片的选择和查询性能。

四、最佳实践

• 合理设置分片数量，根据数据量和集群节点数量进行设置。
• 确保分片和副本均匀分布在集群的不同节点上，避免单点故障。
• 监控和调整分片和副本的状态，根据需要调整配置以优化性能和可用性。

索引（写入）过程的数据一致性

在Elasticsearch中，索引过程保证数据一致性主要通过以下几种机制来实现：

1. 乐观锁与版本控制

• 版本号（_version）：Elasticsearch为每个文档维护一个版本号。每当文档被更新时，版本号会自动增加。在索引过程中，如果多个请求尝试同时更新同一个文档，Elasticsearch会检查请求中指定的版本号（如果指定了）与当前存储的版本号是否一致。如果版本号不一致，说明文档已被其他操作修改，此时Elasticsearch会拒绝执行更新操作，并返回版本冲突错误。这确保了文档的更新操作具有原子性，从而保持数据一致性。

2. 分布式协调

• 分片与副本：Elasticsearch采用分片（Sharding）和副本（Replication）机制来分散存储数据和提供容错能力。索引过程首先将数据写入主分片，然后主分片将更改同步到副本分片。这种机制确保了即使某个节点发生故障，数据也不会丢失，并且可以从其他节点恢复。
• 分布式一致性协议：Elasticsearch使用如Raft或Zen等分布式一致性协议来确保数据在不同节点间的一致性。这些协议通过选举和协商机制，保证了数据分片的副本在集群中的一致性。

3. 写入确认与等待策略

• wait_for_active_shards：在索引过程中，可以设置wait_for_active_shards参数来指定写入操作需要等待的活跃副本数量。只有当指定数量的副本确认写入成功后，操作才会被认为成功。这有助于确保数据在多个副本间的一致性。

4. 索引刷新与持久化

• 索引刷新（Refresh）：Elasticsearch通过索引刷新机制将内存中的更改持久化到磁盘。默认情况下，每个分片会定期（如每秒）执行刷新操作，将内存中的更改写入到文件系统缓存中，并生成新的段（segment）供查询使用。虽然这不是真正的磁盘写入，但它确保了数据的可见性和一致性。
• 段合并（Merge）与磁盘写入（Flush）：随着时间的推移，分片中会产生许多小的段。Elasticsearch会定期执行段合并操作来减少段的数量，提高查询性能。同时，当满足一定条件时（如TransLog达到一定大小或经过一定时间），Elasticsearch会将段从文件系统缓存中刷新到磁盘上，完成真正的持久化。

#####5. 事务日志（TransLog）

• TransLog：Elasticsearch使用TransLog来记录所有对索引的修改操作。这些操作首先被写入到TransLog中，然后再被应用到内存中。如果节点发生故障，Elasticsearch可以在重启后根据TransLog恢复数据到故障前的状态。这确保了数据的持久性和一致性。

综上所述，Elasticsearch通过乐观锁与版本控制、分布式协调、写入确认与等待策略、索引刷新与持久化以及事务日志等多种机制来确保索引过程中数据的一致性。这些机制共同作用，使得Elasticsearch成为一个可靠、高性能的分布式搜索和分析引擎。

映射

映射（Mapping）是索引的关键组成部分，它定义了ES的索引结构、字段类型、分词器等属性。类似于数据库中的“表结构”，包含了字段名称、字段类型、索引信息等。

映射决定了文档中的每个字段如何被索引和存储，包括字段的数据类型、是否分词、是否创建索引等。

映射的类型

1. 动态映射：

   • 根据写入文档的内容，自动推断字段和数据类型，并创建索引结构。
   • ES默认启用动态映射，但可以通过设置来控制其行为，如禁用日期检测、自定义日期格式等。

2. 显式映射：

   • 在创建索引时，明确指定每个字段的数据类型、分词器等属性。
   • 对于需要精细控制字段映射的场景，显式映射是更好的选择。

常见的字段类型：

• 文本类型（Text）：用于全文搜索，支持分词。
• 关键字类型（Keyword）：用于精确值搜索，不进行分词。

元字段

元字段是系统为每个文档自动配置的内置字段，它们主要用于Elasticsearch内部的相关操作，如索引、查询、排序和聚合等。元字段以下划线"_"开头，以下是一些常见的Elasticsearch元字段及其说明：

• _index：表示文档所属的索引。
• _id：表示文档的唯一标识。与_index和（在旧版本中）_type一起，唯一标识和定位一个文档。
• _source：包含文档的原始JSON内容。这个字段本身不建立索引，但会被存储。搜索文档时默认返回该字段及其内容，但无法直接通过该字段进行搜索。

搜索

搜索方式

POST请求参数搜索

请求: POST http://127.0.0.1:9200/secisland/log/_search。参数在请求头中。
参数是JSON格式的查询领域语法（query dsl）​。例如

{
  "from" : 0, "size" : 10,
  "query": {
    "term": {"type": "syslog"}
  }, 
  "script_fields": {
    "test1": {"script": "doc['type'].value * 2"}
  }
}

from表示从第几行开始，size表示查询多少条文档。from默认为0，size默认为10。

script_fields可以通过脚本进行操作。

query

一、基本含义

• 定义搜索条件：query参数包含了执行搜索所需的条件，这些条件决定了哪些文档会被检索出来。
• 灵活多变：Elasticsearch提供了多种查询类型，如match、match_phrase、multi_match、<