es对几十亿数据能达到秒级响应吗_分库代价高的情况下，如何优化ES解决亿级数据量检索...

数据平台已迭代三个版本，从一开始遇到很多常见的难题，到现在终于有片段时间整理一些已完善的文档，在此分享以供所需朋友的实现参考，但愿能帮助大家少走些弯路，在此篇幅中偏重于ElasticSearch的优化。

一、需求说明

项目背景：

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

改进版本目标：

数据能跨月查询，并且支持1年以上的历史数据查询与导出；

按条件的数据查询秒级返回。

二、ElasticSearch检索原理

1、ES和Lucene基础结构

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

一些基本概念：

Cluster：包含多个Node的集群；

Node：集群服务单元；

Index：一个ES索引包含一个或多个物理分片，它只是这些分片的逻辑命名空间；

Type：一个Index的不同分类，6.x后只能配置一个type，以后将移除；

Document：最基础的可被索引的数据单元，如一个JSON串；

Shards：一个分片是一个底层的工作单元，它仅保存全部数据中的一部分，它是一个Lucene实例 (一个Lucene索引最大包含2,147,483,519 (= Integer.MAX_VALUE - 128)个文档数量)；

Replicas：分片备份，用于保障数据安全与分担检索压力。

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

在Lucene中，分为索引(录入)与检索(查询)两部分：

索引部分包含分词器、过滤器、字符映射器等；

检索部分包