创业之路

近年来公司业务迅猛发展，数据量爆炸式增长，随之而来的的是海量数据查询等带来的挑战，我们需要数据量在十亿，甚至百亿级别的规模时依然能以秒级甚至毫秒级的速度返回。

这样的话显然离不开搜索引擎的帮助，在搜索引擎中，ES（ElasticSearch）毫无疑问是其中的佼佼者，连续多年在 DBRanking 的搜索引擎中评测中排名第一，也是绝大多数大公司的首选。

那么它与传统的 DB 如 MySQL 相比有啥优势呢，ES 的数据又是如何生成的，数据达到 PB 时又是如何保证 ES 索引数据的实时性以更好地满足业务的需求的呢。

本文会结合我司在 ES 上的实践经验与大家谈谈如何构建准实时索引的一些思路，希望对大家有所启发。

为什么要用搜索引擎，MySQL 不香吗

MySQL 架构天生不适合海量数据查询，它只适合海量数据存储，但无法应对海量数据下各种复杂条件的查询。

有人说加索引不是可以避免全表扫描，提升查询速度吗，为啥说它不适合海量数据查询呢？

有两个原因：

①加索引确实可以提升查询速度，但在 MySQL 中加多个索引最终在执行 SQL 的时候它只会选择成本最低的那个索引如。

果没有索引满足搜索条件，就会触发全表扫描，而且即便你使用了组合索引，也要符合最左前缀原则才能命中索引。

但在海量数据多种查询条件下很有可能不符合最左前缀原则而导致索引失效，而且我们知道存储都是需要成本的。

如果你针对每一种情况都加索引，以 innoDB 为例，每加一个索引，就会创建一颗 B+ 树。

如果是海量数据，将会增加很大的存储成本，之前就有人反馈说他们公司的某个表实际内容的大小才 10G, 而索引大小却有 30G！这是多么巨大的成本！所以千万不要觉得索引建得越多越好。

②有些查询条件是 MySQL 加索引都解决不了的，比如我要查询商品中所有 title 带有「格力空调」的关键词，如果你用 MySQL 写，会写出如下代码：
SELECT * FROM product WHERE title like ‘%格力空调%’

这样的话无法命中任何索引，会触发全表扫描，而且你不能指望所有人都能输对他想要的商品，是人就会犯错误，我们经常会犯类似把「格力空调」记成「格空间」的错误。

那么 SQL 语句就会变成：
SELECT * FROM product WHERE title like ‘%格空调%’

这种情况下就算你触发了全表扫描也无法查询到任何商品，综上所述，MySQL 的查询确实能力有限。

与其说上面列的这些点是 MySQL 的不足，倒不如说 MySQL 本身就不是为海量数据查询而设计的。

术业有专攻，海量数据查询还得用专门的搜索引擎，这其中 ES 是其中当之无愧的王者。

它是基于 Lucene 引擎构建的开源分布式搜索分析引擎，可以提供针对 PB 数据的近实时查询，广泛用在全文检索、日志分析、监控分析等场景。

它主要有以下三个特点:
轻松支持各种复杂的查询条件：它是分布式实时文件存储，会把每一个字段都编入索引（倒排索引），利用高效的倒排索引，以及自定义打分、排序能力与丰富的分词插件等，能实现任意复杂查询条件下的全文检索需求。
可扩展性强：天然支持分布式存储，通过极其简单的配置实现几百上千台服务器的分布式横向扩容，轻松处理 PB 级别的结构化或非结构化数据。
高可用，容灾性能好：通过使用主备节点，以及故障的自动探测与恢复，有力地保障了高可用。

如何构建 ES 索引

要构建 ES 索引数据，首先得有数据源，一般我们会使用 MySQL 作为数据源，你可以直接从 MySQL 中取数据然后再写入 ES，但这种方式由于直接调用了线上的数据库查询，可能会对线上业务造成影响。

比如考虑这样的一个场景：在电商 APP 里用的最多的业务场景想必是用户输入关键词来查询相对应的商品了，那么商品会有哪些信息呢？

一个商品会有多个 sku（sku 即同一个商品下不同规格的品类，比如苹果手机有 iPhone 6，iPhone 6s 等），会有其基本属性如价格，标题等，商品会有分类（居家，服饰等），品牌，库存等。

为了保证表设计的合理性，我们会设计几张表来存储这些属性。

假设有 product_sku（sku 表），product_property（基本属性表），sku_stock（库存表），product_category（分类表）这几张表。

那么为了在商品展示列表中展示所有这些信息，就必须把这些表进行 join，然后再写入 ES，这样查询的时候就会在 ES 中获取所有的商品信息了。

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以邮件至 chaofa_vip@126.com