优化Elasticsearch批量写入性能：从单分片瓶颈到多索引架构

问题背景

在通过Python服务向Elasticsearch批量写入300万条科学文献数据时，遇到了严重的性能瓶颈：

• 写入目标：300万条数据
• 实际写入：仅50万条
• 瓶颈现象：索引文档数卡在52万左右无法继续增长
• 索引配置：单分片（1 shard）+ 1副本，存储已达55.1GB

从ES索引状态可以看出，scihub_updating索引已经接近单分片的容量极限，这直接导致了写入性能的急剧下降。

问题分析

1. 单分片容量瓶颈

Elasticsearch官方最佳实践建议：

• 单个分片存储：不超过20-50GB
• 单分片文档数：没有硬性限制，但通常建议控制在2000万到5000万之间

我们的实际情况：

• 单分片存储：55.1GB（已超出建议上限）
• 文档数：52万（虽然数量不算多，但单个文档较大，约110KB）
• 问题根源：索引创建时未使用mapping，导致使用了默认配置（只有1个分片）

2. 写入失败的原因

通过代码分析发现：

• ES.bulk() 方法虽然返回了错误列表，但 add_docs() 函数始终返回 len(cks)
• 没有检查实际的写入成功数量
• 大量写入超时和错误被静默忽略

3. 架构设计问题

• 所有数据写入单一索引，无法水平扩展
• 索引创建逻辑不够健壮，未使用正确的mapping配置
• 缺少并发写入的控制机制

解决方案

方案设计：多索引 + Alias架构

基于分析和ES最佳实践，我们采用了多索引 + Alias的方案：

容量规划

• 每个索引：40万文档，约40GB
• 分片配置：2个分片（每个分片约20GB，符合最佳实践）
• 索引命名 ：scihub_XXXX_YYYY（按corpus编号200个一组分配）
• 访问方式：使用Alias统一访问多个底层索引

优势

1. ✅ 符合最佳实践：每个分片20GB，在推荐范围内
2. ✅ 水平扩展：可轻松添加新索引
3. ✅ 写入分散：降低单索引压力
4. ✅ 滚动更新：便于索引维护和重建
5. ✅ 查询透明：通过Alias查询，代码无需改动

并发策略

根据硬件配置（3台32G机器，6个节点：2个master + 4个data节点），确定了最优并发数：

• 推荐并发：3-4个索引同时写入
• 单索引内：bulk写入串行执行
• 多索引间：并发写入，充分利用多节点资源

实现细节

1. 新增 /build/scihub 接口

实现按corpus编号自动分配索引的逻辑：

def get_index_name_from_corpus(corpus_dir_name: str, corpus_per_index: int = 200) -> str:
    """根据corpus目录名计算对应的索引名
    
    例如：corpus_704 -> scihub_600_799（每200个一组）
    """
    match = re.search(r'corpus_(\d+)', corpus_dir_name, re.IGNORECASE)
    corpus_num = int(match.group(1))
    group_id = corpus_num // corpus_per_index
    start_num = group_id * corpus_per_index
    end_num = (group_id + 1) * corpus_per_index - 1
    return f"scihub_{start_num}_{end_num}"

2. 索引创建优化

# 检查索引是否存在，不存在则使用mapping创建
if not ES.indexExist(index_name):
    logger.info(f"Creating index {index_name} with mapping...")
    ES.createIdx(index_name)  # 自动使用mapping.json（2分片配置）

确保每个新索引都使用正确的mapping配置（2个分片）。

3. 目录解析逻辑

保持与原有 /build/sci 接口一致的目录解析逻辑：

• 支持 corpus_XXX/scihub_updating/文档 的目录结构
• 按corpus编号hash到对应索引，而非使用目录名

4. 日志系统优化

问题：Docker环境下日志缺失

解决方案：

• 统一使用Python logging 模块
• 替换所有 print() 为 logger.info()
• 添加关键步骤的详细日志：
  • 请求接收和参数解析
  • 索引创建/检查
  • 目录扫描和文档统计
  • 写入进度和结果汇总
  • 错误处理和异常捕获

日志级别：

• INFO：正常流程信息
• WARNING：警告信息（如目录为空）
• ERROR：错误信息（如索引创建失败）
• DEBUG：调试信息（如缺失文件）

5. 新增时间戳字段

添加 create_time_long 字段，记录准确的入库时间：

# 在接口调用时获取系统时间戳
start_time = time()
create_time = int(start_time)

# 传递给文档创建函数
base_info = {
    # ... 其他字段 ...
    'create_time_long': create_time,  # long类型，匹配mapping中的*_long模板
}

字段特点：

• 字段名：create_time_long（使用 _long 后缀）
• 类型：long（整数时间戳）
• 值：API调用时的系统时间戳
• 作用：准确记录文档入库时间，与 save_date（非严格时间）区分

代码结构

关键函数

1. get_index_name_from_corpus()：索引名映射函数
2. add_files_to_es_scihub()：新的批量写入接口
3. build_corpus()：文档构建函数（支持create_time参数）
4. collect_base_info()：文档信息收集（添加create_time_long字段）

数据流

API调用 
  → 提取corpus编号 
  → 计算索引名（如scihub_600_799）
  → 检查/创建索引（使用mapping.json）
  → 解析目录结构
  → 并发写入多个子目录
  → 每个文档添加create_time_long字段
  → 返回统计结果

性能优化效果

优化前

• ❌ 单分片，容量55.1GB（超标）
• ❌ 卡在52万文档
• ❌ 大量写入失败被忽略
• ❌ 日志缺失，难以排查

优化后

• ✅ 2分片，每分片约20GB（最佳实践）
• ✅ 支持水平扩展（多个索引）
• ✅ 完善的错误处理和日志
• ✅ 准确的入库时间记录
• ✅ 3-4个索引并发写入，充分利用集群资源

最佳实践总结

1. 分片规划：单分片不超过50GB，推荐20-30GB
2. 索引拆分：大数据量使用多索引+Alias架构
3. 并发控制：根据集群节点数合理设置并发度
4. 错误处理：检查bulk写入的实际成功数量
5. 日志记录：使用标准logging，记录关键步骤
6. 时间字段：使用精确的时间戳而非日期字符串

后续优化方向

1. Alias管理：实现自动Alias切换机制
2. 监控告警：添加写入速度和失败率监控
3. 动态调整：根据集群负载动态调整并发度
4. 批量大小 ：优化 ES_BULK_SIZE 参数（当前64，可尝试128-256）

总结

通过这次优化，我们不仅解决了单分片容量瓶颈问题，还建立了可扩展的多索引架构。关键改进包括：

1. 架构层面：从单索引转向多索引+Alias
2. 代码层面：完善的错误处理和日志系统
3. 数据层面：添加准确的时间戳字段
4. 运维层面：详细的日志便于问题排查

这次优化为后续的大规模数据写入奠定了坚实的基础，同时也为类似场景提供了可复用的解决方案。

---

技术栈：

• Python 3.x
• Elasticsearch 8.x
• FastAPI
• asyncio（并发处理）

关键词：Elasticsearch、性能优化、分片规划、多索引架构、批量写入、日志系统