架构师必备：多维度查询的优秀实践

背景

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

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

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

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

初级方案

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

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

优点非常简单读写不一致时间较短：取决于数据库主从同步延时，一般为毫秒级别缺点非常局限：除非筛选条件比较固定，否则难以应付后续新增或修改筛选条件如果每次来新的筛选查询字段的需求，就新增索引，最终导致索引过于庞大，影响性能

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

2、异构出多份数据

更加优雅的方式，是异构出多份数据。

例如，C端按用户维度查询，B端按店铺维度查询，如果还有供应商，按供应商维度查询。一个数据库只能按一种维度来分库。

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

优点是：非常简单。

缺点跨库写存在一致性问题（除非不同维度的表使用公共的分库，事务写入），性能低不能灵活支持更多其他维度的查询（2）借助Canal实现数据的自动同步

通过Canal同步数据，异构出多个维度的数据源。详见之前写的这篇文章：