基于Elasticsearch的缓存索引最优更新方案咨询

场景与索引映射 #

将Elasticsearch作为缓存表使用，索引映射结构如下：

{
    "mappings": {
        "dynamic": false,
        "properties": {
            "query_str": {"type": "text"},
            "search_results": {
                "type": "object", 
                "enabled": false
            },
            "query_embedding": {
                "type": "dense_vector",
                "dims": 768
            }
        }
    }
}

缓存逻辑：通过新查询的嵌入向量与缓存中向量的相似度判断命中，命中则返回search_results字段。

当前需求是每小时更新缓存结果，且更新过程中服务需高效使用缓存，现有两种候选方案，需判断最优或提供更优方案：

现有候选方案分析 #

方案1：逐个顺序更新文档（不销毁索引） #

• 操作逻辑：直接在现有索引中逐个更新或新增文档
• 顾虑：担心每次更新触发索引重建，导致缓存查询变慢

方案2：创建新索引后交换 #

• 操作逻辑：先创建包含新缓存结果的全新索引，再将当前缓存索引与新索引交换
• 存在问题：
  • 未找到优雅的索引交换方式
  • 认为用户获取缓存结果的速度慢于方案1

最优方案推荐及改进建议 #

优先选择方案2的优化版（索引别名切换） #

方案2的核心是用索引别名实现无缝切换，这是Elasticsearch官方推荐的无停机更新方案，完全解决你的顾虑：

1. 优雅的索引交换方式：
   • 具体步骤：
     1. 创建带版本/时间戳的新索引（比如cache_v2或cache_20240520_1000），写入最新的缓存数据
     2. 数据写入完成后，执行刷新确保数据可查：POST /cache_v2/_refresh
     3. 原子性切换别名：将指向旧索引的业务别名（比如cache）切换到新索引

        POST /_aliases
        {
            "actions": [
                {"remove": {"index": "cache_v1", "alias": "cache"}},
                {"add": {"index": "cache_v2", "alias": "cache"}}
            ]
        }
        

   • 该操作是原子性的，切换过程中服务通过别名cache查询不会出现中断或数据不一致
2. 查询性能问题：新索引完成写入和刷新后，查询性能和旧索引完全一致，甚至因为批量写入生成的segment更规整，性能可能更优，不存在比方案1慢的情况

方案1的弊端 #

方案1的逐个更新会带来明显问题：

• 频繁单文档更新会产生大量小segment，Elasticsearch后台需持续进行segment合并，消耗CPU和IO资源，导致查询性能波动，小时级批量更新场景下波动会更显著
• 若更新涉及大量文档，逐个更新的总耗时远高于批量写入新索引，更新期间索引状态不稳定，查询延迟会上升

额外优化技巧 #

• 索引命名规范：给索引加版本号或时间戳，方便后续管理和清理旧索引
• 批量写入：使用Bulk API批量写入新缓存数据，大幅提升写入效率
• 异步清理旧索引：切换别名后，异步删除旧索引，避免占用存储空间
• 新索引预热：切换别名前，执行若干模拟查询触发缓存加载，确保切换后第一时间查询性能稳定

内容的提问来源于stack exchange，提问作者Nick Zorander