MK
摩柯社区 - 一个极简的技术知识社区
AI 面试

版本支持在ElasticSearch中的重要性

2023-06-222.9k 阅读

版本兼容性对功能特性的影响

新功能的引入与使用

在ElasticSearch的发展历程中，每个新版本都会带来一系列新的功能特性。例如，从ElasticSearch 6.0开始，引入了索引生命周期管理（ILM）功能。ILM允许用户定义策略，自动管理索引的生命周期，包括创建、滚动、热温冷数据分层存储以及删除等操作。

假设我们要创建一个基于ILM策略的索引，可以通过如下代码实现：

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size": "50gb",
            "max_age": "30d"
          }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

然后在创建索引时关联该策略：

PUT my_index-000001
{
  "settings": {
    "index.lifecycle.name": "my_policy",
    "index.lifecycle.rollover_alias": "my_index"
  }
}

然而，如果使用的是旧版本的ElasticSearch，比如5.x版本，是无法使用ILM功能的。这就意味着在功能实现上会受到极大的限制，开发人员不得不手动编写复杂的脚本或程序来模拟类似的索引管理功能，这不仅增加了开发成本，还可能带来维护上的困难。

旧功能的废弃与替代

随着版本的更新，ElasticSearch也会废弃一些旧的功能。以ElasticSearch 7.0为例，它废弃了类型（type）的概念。在早期版本中，一个索引可以包含多个类型，例如在一个“blog”索引中，可以有“article”类型和“comment”类型。

PUT blog
{
  "mappings": {
    "article": {
      "properties": {
        "title": { "type": "text" },
        "content": { "type": "text" }
      }
    },
    "comment": {
      "properties": {
        "author": { "type": "text" },
        "text": { "type": "text" }
      }
    }
  }
}

但从7.0版本开始，这种多类型的设计不再被支持，每个索引只能有一个隐式的类型。如果应用程序依赖于多类型的功能，在升级到7.0及以上版本时，就需要对数据结构和查询逻辑进行重大调整。例如，之前的查询可能是针对特定类型的：

GET blog/article/_search
{
  "query": {
    "match": {
      "title": "ElasticSearch"
    }
  }
}

升级后，查询需要改为针对整个索引：

GET blog/_search
{
  "query": {
    "match": {
      "title": "ElasticSearch"
    }
  }
}

这种旧功能的废弃，如果开发人员没有提前了解和做好相应的版本兼容性规划，可能会导致应用程序在升级后出现严重的功能故障。

性能优化与版本的关系

底层存储引擎的改进

ElasticSearch的底层存储引擎在不同版本中有显著的改进，这直接影响到性能。例如，从Lucene（ElasticSearch基于Lucene构建）6.0版本开始，引入了新的段合并策略。在旧版本中，段合并可能会导致较长的I/O阻塞时间，影响查询性能。而新版本的段合并策略采用了更加智能的算法，能够在合并过程中更好地平衡I/O负载。

假设我们有一个包含大量文档的索引，在旧版本下进行索引构建和查询时，由于段合并带来的I/O压力，查询响应时间可能会较长。以一个简单的查询为例：

SearchResponse response = client.prepareSearch("my_index")
      .setQuery(QueryBuilders.matchAllQuery())
      .get();

在新版本中，由于段合并策略的优化，同样的查询在相同硬件环境下，响应时间可能会大幅缩短。这是因为新版本在处理段合并时，能够更有效地利用系统资源，减少了对查询操作的干扰。

搜索算法的优化

不同版本的ElasticSearch在搜索算法上也有优化。例如，ElasticSearch 5.0引入了新的评分算法，对相关性分数的计算进行了改进。在旧版本中，文档的相关性评分可能不够准确，导致搜索结果的排序不能很好地满足用户需求。 假设我们有一个电商搜索场景，用户搜索“运动鞋”。在旧版本中，可能会出现一些与运动鞋不太相关的运动服装类商品排在前面的情况。而在5.0及之后的版本中，通过改进的评分算法，能够更准确地将真正的运动鞋商品排在前列。

GET products/_search
{
  "query": {
    "match": {
      "product_name": "运动鞋"
    }
  }
}

这种搜索算法的优化，如果应用程序使用的是旧版本，就无法享受到更精准的搜索结果带来的优势，从而影响用户体验和业务效果。

安全与版本支持

漏洞修复与安全更新

ElasticSearch的版本更新中包含了大量的安全漏洞修复。例如，在早期版本中，曾存在过一些与认证授权相关的漏洞，恶意用户可能利用这些漏洞绕过身份验证，访问敏感数据。ElasticSearch的开发团队会在后续版本中及时修复这些漏洞。 假设我们使用的是存在漏洞的旧版本，并且没有及时升级，黑客可能通过如下恶意请求尝试绕过认证：

GET /_search HTTP/1.1
Host: your-elasticsearch-server:9200
Authorization: Basic YWRtaW46YWRtaW4= # 错误的认证方式可能被绕过

而在修复了相关漏洞的新版本中，这种恶意请求将被正确拦截，保障数据的安全性。开发人员必须关注版本的安全更新，及时升级ElasticSearch，以避免安全风险。

新安全特性的引入

新版本还会引入新的安全特性。从ElasticSearch 6.8开始，增强了对传输层加密（TLS）的支持。通过配置TLS，我们可以对节点间通信以及客户端与集群的通信进行加密，防止数据在传输过程中被窃取或篡改。 以下是配置节点间TLS的部分配置示例（elasticsearch.yml）：

xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: /path/to/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: /path/to/elastic-certificates.p12

对于客户端连接，也可以通过相应的配置启用TLS加密。如果使用的是旧版本，就无法利用这些新的安全特性来提升系统的安全性，使数据在传输过程中处于相对危险的状态。

集群管理与版本一致性

节点版本兼容性

在ElasticSearch集群中，节点的版本一致性至关重要。不同版本的节点可能会导致集群运行异常。例如，如果一个集群中同时存在6.x版本和7.x版本的节点，可能会出现数据同步问题。 假设我们尝试将一个7.x版本的节点加入到一个6.x版本的集群中。在数据复制和同步过程中，由于不同版本对数据格式和传输协议的差异，可能会导致数据丢失或损坏。ElasticSearch的集群管理机制依赖于节点之间的协同工作，版本不一致可能会破坏这种协同。

# 尝试启动不同版本节点加入集群（错误操作示例）
./elasticsearch-6.8.10/bin/elasticsearch -Ecluster.name=my_cluster -Enode.name=node-6x
./elasticsearch-7.10.2/bin/elasticsearch -Ecluster.name=my_cluster -Enode.name=node-7x

正确的做法是确保所有节点的版本一致，在升级集群时，要按照官方文档的指导，逐步进行节点升级，保证集群的稳定性。

集群功能依赖于版本

一些集群级别的功能在不同版本中有不同的实现方式和可用性。例如，ElasticSearch 7.0引入了跨集群复制（CCR）功能，允许将一个集群的数据复制到另一个集群，用于数据备份、容灾或者跨地域数据分发。 要配置CCR，首先需要在源集群和目标集群中进行相应的设置。在源集群中：

PUT _cluster/settings
{
  "persistent": {
    "cluster.remote.<remote_cluster_name>.seeds": ["<remote_cluster_ip>:9300"]
  }
}

在目标集群中：

PUT _ccr/follow/my_follower_index
{
  "remote_cluster": "<remote_cluster_name>",
  "leader_index": "my_leader_index"
}

如果集群中的节点版本不一致，特别是存在不支持CCR功能的旧版本节点，就无法正常使用这一集群级别的功能。这对于需要实现数据跨集群复制的企业应用来说，是一个关键的问题，直接影响到数据的安全性和可用性。

应用开发与版本支持

客户端库的版本适配

在使用ElasticSearch进行应用开发时，客户端库的版本必须与ElasticSearch服务器版本相适配。例如，Java客户端库在不同版本中与ElasticSearch服务器的交互方式可能会有所不同。 如果使用的是较旧的Java客户端库版本，而ElasticSearch服务器已经升级到较新的版本，可能会出现方法调用不兼容的情况。以创建索引为例，在旧版本的Java客户端中可能是这样的代码：

CreateIndexRequest createIndexRequest = new CreateIndexRequest("my_index");
CreateIndexResponse createIndexResponse = client.admin().indices().create(createIndexRequest).actionGet();

而在新版本的Java客户端中，代码可能变为：

CreateIndexRequest createIndexRequest = new CreateIndexRequest("my_index");
CreateIndexResponse createIndexResponse = client.indices().create(createIndexRequest, RequestOptions.DEFAULT);

如果开发人员没有及时更新客户端库版本，应用程序可能会出现编译错误或者运行时异常，导致无法正常与ElasticSearch服务器进行交互。

开发实践与版本特性

不同版本的ElasticSearch特性会影响开发实践。例如，ElasticSearch 8.0引入了向量搜索功能，这对于处理文本相似度搜索、图像搜索等场景非常有用。 假设我们要进行文本相似度搜索，在8.0版本中，可以通过如下方式实现：

PUT my_vector_index
{
  "mappings": {
    "properties": {
      "text_vector": {
        "type": "dense_vector",
        "dims": 768
      }
    }
  }
}

然后插入带有向量数据的文档：

POST my_vector_index/_doc
{
  "text": "这是一段示例文本",
  "text_vector": [0.1, 0.2, 0.3, ..., 0.768]
}

在进行搜索时：

GET my_vector_index/_search
{
  "query": {
    "script_score": {
      "query": { "match_all": {} },
      "script": {
        "source": "cosineSimilarity(params.query_vector, 'text_vector') + 1.0",
        "params": {
          "query_vector": [0.1, 0.2, 0.3, ..., 0.768]
        }
      }
    }
  }
}

如果开发人员仍然使用旧版本进行开发，就无法利用向量搜索这一强大的功能，需要采用其他较为复杂的方式来实现类似的相似度搜索功能，增加了开发的难度和成本。

版本升级与迁移策略

升级前的准备工作

在进行ElasticSearch版本升级之前，需要进行充分的准备工作。首先，要对当前集群的状态进行全面评估，包括索引数量、文档数量、磁盘使用情况、内存使用情况等。可以通过ElasticSearch提供的API获取这些信息。 例如，获取集群健康状态：

GET _cluster/health

获取索引统计信息：

GET _cat/indices?v

同时，要备份重要的数据。虽然ElasticSearch在升级过程中通常会尽量保证数据的完整性，但为了以防万一，还是需要进行数据备份。可以使用快照和恢复功能进行备份。

PUT _snapshot/my_backup_repository
{
  "type": "fs",
  "settings": {
    "location": "/path/to/backup"
  }
}

然后创建快照：

PUT _snapshot/my_backup_repository/my_snapshot_1

此外，还需要对应用程序进行测试，确保其与新版本的ElasticSearch兼容。可以搭建一个与生产环境相似的测试环境，在测试环境中进行版本升级和应用程序的功能测试。

升级过程与注意事项

在升级过程中，要按照官方文档的指导逐步进行。对于单节点集群，升级相对简单，只需要停止ElasticSearch服务，安装新版本，然后启动即可。但对于多节点集群，需要更加谨慎。 通常建议采用滚动升级的方式，即每次只升级一个节点，等待该节点成功加入集群并恢复正常后，再升级下一个节点。例如，在升级一个三节点集群时：

  1. 停止第一个节点的ElasticSearch服务，安装新版本，启动该节点，等待其重新加入集群并恢复健康状态。
  2. 重复上述步骤，对第二个节点进行升级。
  3. 最后对第三个节点进行升级。 在升级过程中，要密切关注集群的健康状态和日志信息。如果出现问题，及时查阅官方文档或社区论坛寻求解决方案。例如，如果在升级过程中出现节点无法加入集群的情况，可能需要检查网络配置、节点名称配置等是否正确。

迁移后的验证与优化

升级完成后，要对集群和应用程序进行全面的验证。首先，检查索引数据是否完整，文档数量是否正确。可以通过与升级前的备份数据进行对比来验证。 然后，对应用程序的各项功能进行测试，确保搜索、索引、更新等操作都能正常进行。同时，还可以对新功能进行测试和评估，看是否能够为应用程序带来性能提升或功能增强。 例如，如果升级到了支持向量搜索的版本，可以测试向量搜索功能在应用程序中的实际效果。此外，还可以对集群的性能进行优化，根据新版本的特性调整配置参数，如调整内存分配、优化索引设置等，以充分发挥新版本的优势。