随着业务快速发展，跨表join查询需求越来越多，业务数据量也越来越大，应用系统的慢查询不断涌现，引入Elasticsearch 来实现聚合查询势在必行。Elasticsearch是一个基于 Lucene 的搜索引擎，通过将业务主表及辅表的索引字段及需要like查询字段同步到Elasticsearch中，每张表的索引字段最终汇总成一个联合索引，来实现多个表的跨表搜索。
一、单索引和多索引
在Elasticsearch中，一个Index可以理解为一个MySQL数据库，从Elasticsearch 6.x开始，只能一个Type对应一个Index。
如果业务端对查询性能要求很高的话，还是建议使用单索引，也就是宽表化处理的方式，这样也可以比较好地应对聚合的需求。
二、索引字段数量
由于业务主表及其扩展信息字段较多，如果将这些信息全量同步到 Elasticsearch会导致其他问题。
- 索引字段过多，索引文件也会随之变大，检索效率会受到影响。
- 不需要索引的字段过多，否则会导致新的io问题。
在实际项目中，尽可能的自定义mapping，不要存储与搜索无关的数据。关于Elasticsearch中数据是如何存储的，可以查阅小编的相关文章。
在实际业务场景中，存宽表是个不错的方案，究竟多宽也需要认真思考。
通常都需要结合其中的多个方法来得到最终的解决方案。如果业务端对查询性能要求很高的话，还是建议使用宽表化处理的方式，这样也可以比较好地应对聚合的需求。
常规建议：一个宽表维护业务主表的基本信息及其强依赖的扩展信息。
三、Hbase存储详情组装数据
Hbase 是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统。可以通过 MapReduce 来处理 HBase 中的海量数据。
我们可以将宽表存入至Hbase，历史数据采用 BulkLoad 导入，增量数据采用消息同步写入，以订单号为 rowKey 为订单号。
那如何保证Elasticsearch和Hbase的实时性与一致性呢？
可采用Change Data Capture方案，监听 binlog 然后同步到消息队列Kafka中，业务消费处理同步到 Elasticsearch和 Hbase。另外，对报警监控的指标进行关注，失败重试补偿就即可。
MySQL到ES的同步策略，采取如下的机制：
步骤1： 基Debezium的binlog机制，将MySQL数据同步到Kafka。
步骤2： 基于Kafka connector机制，将kafka数据同步到Elasticsearch。
建立实时性的监控指标（差值）：
一个消息的处理时间：binlogTime->receiveMqTime->msgProcessTime->addEsOrHbaseTime
閱讀更多 軟件架構 的文章
