近年来公司业务迅猛发展,数据量爆炸式增长,随之而来的的是海量数据查询等带来的挑战,我们需要数据量在十亿,甚至百亿级别的规模时依然能以秒级甚至毫秒级的速度返回,这样的话显然离不开搜索引擎的帮助,在搜索引擎中,ES(ElasticSearch)毫无疑问是其中的佼佼者,连续多年在 DBRanking 的搜索引擎中评测中排名第一,也是绝大多数大公司的首选,那么它与传统的 DB 如 MySQL 相比有啥优势呢,ES 的数据又是如何生成的,数据达到 PB 时又是如何保证 ES 索引数据的实时性以更好地满足业务的需求的呢。
本文会结合我司在 ES 上的实践经验与大家谈谈如何构建准实时索引的一些思路,希望对大家有所启发。本文目录如下
为什么要用搜索引擎,传统 DB 如 MySQL 不香吗
MySQL 的不足
ES 简介
ES 索引数据构建
PB 级的 ES 准实时索引数据构建之道
为什么要用搜索引擎,传统 DB 如 MySQL 不香吗
MySQL 的不足
MySQL 架构天生不适合海量数据查询,它只适合海量数据存储,但无法应对海量数据下各种复杂条件的查询,有人说加索引不是可以避免全表扫描,提升查询速度吗,为啥说它不适合海量数据查询呢,有两个原因:
与其说上面列的这些点是 MySQL 的不足,倒不如说 MySQL 本身就不是为海量数据查询而设计的,术业有专攻,海量数据查询还得用专门的搜索引擎,这其中 ES 是其中当之无愧的王者,它是基于 Lucene 引擎构建的开源分布式搜索分析引擎,可以提供针对 PB 数据的近实时查询,广泛用在全文检索、日志分析、监控分析等场景。
通过类比的形式不难看出 ES 的以下几个概念 1、 MySQL 的数据库(DataBase)相当于 Index(索引),数据的逻辑集合,ES 的工作主要也是创建索引,查询索引。 2、 一个数据库里会有多个表,同样的一个 Index 也会有多个 type 3、 一个表会有多行(Row),同样的一个 Type 也会有多个 Document。 4、 Schema 指定表名,表字段,是否建立索引等,同样的 Mapping 也指定了 Type 字段的处理规则,即索引如何建立,是否分词,分词规则等 5、 在 MySQL 中索引是需要手动创建的,而在 ES 一切字段皆可被索引,只要在 Mapping 在指定即可
那么 ES 中的索引为何如此高效,能在海量数据下达到秒级的效果呢?它采用了多种优化手段,最主要的原因是它采用了一种叫做倒排索引的方式来生成索引,避免了全文档扫描,那么什么是倒排索引呢,通过文档来查找关键词等数据的我们称为正排索引,返之,通过关键词来查找文档的形式我们称之为倒排索引,假设有以下三个文档(Document)
一个 ES 集群由多个 node 节点组成,每个 index 是以分片(Shard,index 子集)的数据存在于多个 node 节点上的,这样的话当一个查询请求进来,分别在各个 node 查询相应的结果并整合后即可,将查询压力分散到多个节点,避免了单个节点 CPU,磁盘,内存等处理能力的不足。
另外当新节点加入后,会自动迁移部分分片至新节点,实现负载均衡,这个功能是 ES 自动完成的,对比一个下 MySQL 的分库分表需要开发人员引入 Mycat 等中间件并指定分库分表规则等繁琐的流程是不是一个巨大的进步?这也就意味着 ES 有非常强大的水平扩展的能力,集群可轻松扩展致几百上千个节点,轻松支持 PB 级的数据查询。
当然 ES 的强大不止于此,它还采用了比如主备分片提升搜索吞率,使用节点故障探测,Raft 选主机制等提升了容灾能力等等,这些不是本文重点,读者可自行查阅,总之经过上面的简单总结大家只需要明白一点:ES 的分布式架构设计天生支持海量数据查询。
那么 ES 的索引数据(index)如何生成的呢,接下来我们一起来看看本文的重点
如何构建 ES 索引
要构建 ES 索引数据,首先得有数据源,一般我们会使用 MySQL 作为数据源,你可以直接从 MySQL 中取数据然后再写入 ES,但这种方式由于直接调用了线上的数据库查询,可能会对线上业务造成影响,比如考虑这样的一个场景:
这种方案由于直接在 MySQL 中执行 join 操作,在商品达到千万级时会对线上的 DB 服务产生极大的性能影响,所以显然不可行,那该怎么生成中间表呢,既然直接在 MySQL 中操作不可行,能否把 MySQL 中的数据同步到另一个地方再做生成中间表的操作呢,也就是加一个中间层进行处理,这样就避免了对线上 DB 的直接操作,说到这相信大家又会对计算机界的名言有进一步的体会:没有什么是加一个中间层不能解决的,如果有,那就再加一层。