背景
有2种常见的多维度查询场景,分别是:
-
带多个筛选条件的列表查询
-
不含分库分表列的其他维度查询
普通的数据库查询,很难实现上述需求场景,更不用提模糊查询、全文检索了。
初级方案
1、根据常见查询场景,增加相应字段的组合索引
这个是为了实现带多个筛选条件的列表查询的。
优点
-
非常简单
-
读写不一致时间较短:取决于数据库主从同步延时,一般为毫秒级别
缺点
-
非常局限:除非筛选条件比较固定,否则难以应付后续新增或修改筛选条件
-
如果每次来新的筛选查询字段的需求,就新增索引,最终导致索引过于庞大,影响性能
于是就出现了经典的一幕:产品提需求说要支持某个新字段的筛选查询,开发反馈说做不了、或者成本很高,于是不了了之 :)
2、异构出多份数据
更加优雅的方式,是异构出多份数据。 例如,C端按用户维度查询,B端按店铺维度查询,如果还有供应商,按供应商维度查询。一个数据库只能按一种维度来分库。
(1)程序写入多个数据源
优点是:非常简单。
缺点
-
跨库写存在一致性问题(除非不同维度的表使用公共的分库,事务写入),性能低
-
不能灵活支持更多其他维度的查询
(2)借助Canal实现数据的自动同步
通过Canal同步数据,异构出多个维度的数据源。详见之前写的这篇文章:架构师必备:巧用Canal实现异步、解耦的架构
编辑切换为居中
添加图片注释,不超过 140 字(可选)
优点是:更加优雅,无需改动程序主流程。
缺点
-
仍然无法解决不断变化的需求,不可能为了支持新维度就异构出一份新数据
进阶方案:将ElasticSearch添加到现有系统中
应用架构
现有系统一般都会用到MySQL数据库,需要引入ES,为系统增强多维度查询的功能。 MySQL继续