多维度查询的最佳实践

背景

有2种常见的多维度查询场景，分别是：

• 带多个筛选条件的列表查询
• 不含分库分表列的其他维度查询

普通的数据库查询，很难实现上述需求场景，更不用提模糊查询、全文检索了。

下面结合楼主的经验和知识，介绍初级方案、进阶方案（上ElasticSearch），大部分情况下推荐使用ElasticSearch来实现多维度查询，赶时间的读者可以直接跳到“进阶方案：将ElasticSearch添加到现有系统中”。

初级方案

1、根据常见查询场景，增加相应字段的组合索引

这个是为了实现带多个筛选条件的列表查询的。

优点

• 非常简单
• 读写不一致时间较短：取决于数据库主从同步延时，一般为毫秒级别

缺点

• 非常局限：除非筛选条件比较固定，否则难以应付后续新增或修改筛选条件
• 如果每次来新的筛选查询字段的需求，就新增索引，最终导致索引过于庞大，影响性能

于是就出现了经典的一幕：产品提需求说要支持某个新字段的筛选查询，开发反馈说做不了、或者成本很高，于是不了了之 :）

2、异构出多份数据

更加优雅的方式，是异构出多份数据。
例如，C端按用户维度查询，B端按店铺维度查询，如果还有供应商，按供应商维度查询。一个数据库只能按一种维度来分库。

（1）程序写入多个数据源

优点是：非常简单。

缺点

• 跨库写存在一致性问题（除非不同维度的表使用公共的分库，事务写入），性能低
• 不能灵活支持更多其他维度的查询

（2）借助Canal实现数据的自动同步

通过Canal同步数据，异构出多个维度的数据源。详见之前写的这篇文章：架构师必备：巧用Canal实现异步、解耦的架构

优点是：更加优雅，无需改动程序主流程。

缺点

• 仍然无法解决不断变化的需求，不可能为了支持新维度就异构出一份新数据

进阶方案：将ElasticSearch添加到现有系统中

应用架构

现有系统一般都会用到MySQL数据库，需要引入ES，为系统增强多维度查询的功能。
MySQL继续承担业务的实时读写请求、事务操作，ES承担近实时的多维度查询请求，ES可支撑十万级别q