突破性能瓶颈！ElasticSearch百亿级数据检索优化案例

一、前言

本文中的数据平台已迭代三个版本，从头开始遇到很多常见的难题，终于有片段时间整理一些已完善的文档，在此分享以供所需朋友的。实现参考，少走些弯路，在此篇幅中偏重于ES的优化，目前生产已存储百亿数据，性能良好，关于HBase，Hadoop的设计优化估计有很多文章可以参考，不再赘述。

二、需求说明

项目背景：在一业务系统中，部分表每天的数据量过亿，已按天分表，但业务上受限于按天查询，并且DB中只能保留3个月的数据(硬件高配)，分库代价较高。

改进版本目标：

1. 数据能跨月查询，并且支持1年以上的历史数据查询与导出。
2. 按条件的数据查询秒级返回。

三、elasticsearch检索原理

3.1 关于ES和Lucene基础结构

谈到优化必须能了解组件的基本原理，才容易找到瓶颈所在，以免走多种弯路，先从ES的基础结构说起(如下图)：

image

一些基本概念:

Cluster          包含多个Node的集群
Node             集群服务单元
Index             一个ES索引包含一个或多个物理分片，它只是这些分片的逻辑命名空间
Type              一个index的不同分类，6.x后只能配置一个type，以后将移除
Document    最基础的可被索引的数据单元，如一个JSON串
Shards          一个分片是一个底层的工作单元，它仅保存全部数据中的一部分，它是一个Lucence实例 (一个lucene索引最大包含2,147,483,519 (= Integer.MAX_VALUE - 128)个文档数量)
Replicas       分片备份，用于保障数据安全与分担检索压力

ES依赖一个重要的组件Lucene，关于数据结构的优化通常来说是对Lucene的优化，它是集群的一个存储于检索工作单元，结构如下图：

image

在Lucene中，分为索引(录入)与检索(查询)两部分，索引部分包含 分词器、过滤器、字符映射器 等&