如何掌握架构师必备的多维度查询最佳实践技巧？
- 内容介绍
- 文章标签
- 相关推荐
本文共计2405个文字，预计阅读时间需要10分钟。
背景：有两种常见的多维度查询场景，分别是：
1. 带有多个筛选条件的列表查询，不包含数据库分区表列的其他维度查询。
2.普通的数据库查询，实现难度较高，更不常用模糊查询、全文检索等。
背景有2种常见的多维度查询场景，分别是：
- 带多个筛选条件的列表查询
- 不含分库分表列的其他维度查询
普通的数据库查询，很难实现上述需求场景，更不用提模糊查询、全文检索了。
下面结合楼主的经验和知识，介绍初级方案、进阶方案（上ElasticSearch），大部分情况下推荐使用ElasticSearch来实现多维度查询，赶时间的读者可以直接跳到“进阶方案：将ElasticSearch添加到现有系统中”。
初级方案 1、根据常见查询场景，增加相应字段的组合索引这个是为了实现带多个筛选条件的列表查询的。
优点- 非常简单
- 读写不一致时间较短：取决于数据库主从同步延时，一般为毫秒级别
- 非常局限：除非筛选条件比较固定，否则难以应付后续新增或修改筛选条件
- 如果每次来新的筛选查询字段的需求，就新增索引，最终导致索引过于庞大，影响性能
于是就出现了经典的一幕：产品提需求说要支持某个新字段的筛选查询，开发反馈说做不了、或者成本很高，于是不了了之 :）
2、异构出多份数据更加优雅的方式，是异构出多份数据。
例如，C端按用户维度查询，B端按店铺维度查询，如果还有供应商，按供应商维度查询。一个数据库只能按一种维度来分库。
优点是：非常简单。
缺点- 跨库写存在一致性问题（除非不同维度的表使用公共的分库，事务写入），性能低
- 不能灵活支持更多其他维度的查询
通过Canal同步数据，异构出多个维度的数据源。详见之前写的这篇文章：架构师必备：巧用Canal实现异步、解耦的架构
优点是：更加优雅，无需改动程序主流程。
缺点- 仍然无法解决不断变化的需求，不可能为了支持新维度就异构出一份新数据
现有系统一般都会用到MySQL数据库，需要引入ES，为系统增强多维度查询的功能。
MySQL继续承担业务的实时读写请求、事务操作，ES承担近实时的多维度查询请求，ES可支撑十万级别qps（取决于节点数、分片数、副本数）。
需要注意的是：同步数据至ES是秒级延迟（主要耗费在索引refresh），而查询已进入索引的文档，是在数毫秒到数百毫秒级别。
需要同步机制，来把MySQL中的数据导入到ES中，主要流程如下：
- 预先定义ES索引的mapping配置，而不依赖ES自动生成mapping
- 初始全量导入，后续增量导入：Canal+MQ数据管道同步，不需要或仅需少量代码工作
- 数据过滤：不导入无需检索的字段，减小索引大学，提高性能
- 数据扁平化处理：如果数据库中有json字段列，需要从中提取业务字段，避免嵌套类型的字段，提高性能
-
从ES 8.x版本开始，建议使用Java api client，并且要Java 8及以上环境，因为可使用各种lambda函数，来提高代码可读性
- 优点是新客户端与server代码完全耦合（相比于原Java transport client，在8.x版本已废弃），并且API风格与www.elastic.co/guide/en/elasticsearch/client/index.html
数据模型转换
因为既有MySQL，又有ES，所以有2种异构的数据模型。需要在代码中定义2种数据模型，并且实现类型互相转换的工具类。
- MySQL数据VO
- ES数据VO
- MySQL数据VO、ES数据VO互相转换工具
- 业务层BO
- 接口DTO
ES之所以比MySQL，能胜任多维度查询、全文检索，是因为底层数据结构不同：
- ES倒排索引
- 如果是全文检索字段：会先分词，然后生成 term -> document 的倒排索引，查询时也会把query分词，然后检索出相关的文档。相关度算法如TF-IDF（term frequency–inverse document frequency），取决于：词在该文档中出现的频率（TF，term frequency），越高代表越相关；以及词在所有文档中出现的频率（IDF，inverse document frequency），越高代表越不相关，相当于是一个通用的词，对相关性影响较小。
- 如果是精确值字段：则无需分词，直接把query作为一个整体的term，查询对应文档。
- 因为文档中的所有字段，都生成了倒排索引，所以能处理多维度组合查询
- MySQL B+树
- B+树的非叶子节点记录了孩子节点值的范围，而叶子节点记录了真正的一组值，并且在同一层，形成了一个有序链表
- 组合索引需要显式创建：选择需索引的字段、并且顺序是重要的，所以如果待查询的字段不在索引中，就无法高效查询，可能演变为全表扫描（对聚簇索引的叶子节点做一次遍历）
另外简要回顾一下ES的架构要点：
- 节点分为主节点、数据节点，一个节点上可以有多个分片，分片分为主分片、副本分片，1对多，主分片与副本分片分布在不同的节点，来实现高可用
- 主分片数在创建时，就需要指定，在创建后不能随意更改（如果变化，路由就会出错）；而副本分片可以增加，来提高ES集群的查询QPS
- 路由算法：id % 主分片数，如果创建文档时不指定id，则ES会自动生成；一般会传自定义业务id
- 支持各字段的多维度组合查询，无惧未来新增字段（主要成本在于新增字段后、重建索引）
- 与现有系统完全解耦，适合架构演进
- 在数据量级上远胜Mysql，最大支持PB级数据的存储和查询
- 读写不一致时间在秒级：因为有2个耗时阶段，一是同步阶段将数据从MySQL数据库写入ES，二是ES索引refresh阶段，数据从buffer写入索引后才可查到
- 因此一个trick就是，在写入操作后，前端延迟调用后端的列表查询接口，比如延迟1秒后再展示
- 超高并发下存在瓶颈，存在稳定性问题：目前原生版本支持大约 3-5 万分片，性能已经到达极限，创建索引基本到达 30 秒+ 甚至分钟级。节点数只能到 500 左右基本是极限了。但依然能满足绝大部分场景。数据来源：elasticsearch.cn/slides/259#page=30
- 只把需要搜索的数据导入ES，避免索引过大
- 数据扁平化，不用嵌套结构，提高性能
- 合理设置字段类型，预先定义mapping配置，而不依赖ES自动生成mapping
- 精确值的类型指定为keyword（mapping配置），并且使用term查询
- 精确值是指无需进行range范围查询的字段，既可以是字符串，比如书的作者名字，也可以是数值，比如商品id、订单id、图书ISBN编号、枚举值。在使用中，大部分场景是以id类作为精确值
- 避免无路由查询：无路由查询会并发在多个索引上查询、归并排序结果，会使得集群cpu飙升，影响稳定性
- 避免深度分页查询：如有大量数据查询，推荐用scroll滚动查询
- 设置合理的文件系统缓存（filesytem cache）大小，提高性能：因为ES查询的热数据在文件系统缓存中
- ES分片数在创建后不能随意改动，但是副本数可以随时增加，来提高最大QPS。如果单个分片压力过大，需要扩容。
前面提到ES超高并发下存在瓶颈，极端情况下可能遇到OOM，因此超高并发下需要C++实现的专用搜索引擎
例如：- 百度：通用搜索引擎，根据文字、图片搜索信息
- 电商垂类：电商专用搜索引擎，比如根据关键词查找商品，或根据品牌、价格筛选商品，可总结为商品的搜索、广告、推荐
- 优点是新客户端与server代码完全耦合（相比于原Java transport client，在8.x版本已废弃），并且API风格与www.elastic.co/guide/en/elasticsearch/client/index.html
数据模型转换
本文共计2405个文字，预计阅读时间需要10分钟。
背景：有两种常见的多维度查询场景，分别是：
1. 带有多个筛选条件的列表查询，不包含数据库分区表列的其他维度查询。
2.普通的数据库查询，实现难度较高，更不常用模糊查询、全文检索等。
背景有2种常见的多维度查询场景，分别是：
- 带多个筛选条件的列表查询
- 不含分库分表列的其他维度查询
普通的数据库查询，很难实现上述需求场景，更不用提模糊查询、全文检索了。
下面结合楼主的经验和知识，介绍初级方案、进阶方案（上ElasticSearch），大部分情况下推荐使用ElasticSearch来实现多维度查询，赶时间的读者可以直接跳到“进阶方案：将ElasticSearch添加到现有系统中”。
初级方案 1、根据常见查询场景，增加相应字段的组合索引这个是为了实现带多个筛选条件的列表查询的。
优点- 非常简单
- 读写不一致时间较短：取决于数据库主从同步延时，一般为毫秒级别
- 非常局限：除非筛选条件比较固定，否则难以应付后续新增或修改筛选条件
- 如果每次来新的筛选查询字段的需求，就新增索引，最终导致索引过于庞大，影响性能
于是就出现了经典的一幕：产品提需求说要支持某个新字段的筛选查询，开发反馈说做不了、或者成本很高，于是不了了之 :）
2、异构出多份数据更加优雅的方式，是异构出多份数据。
例如，C端按用户维度查询，B端按店铺维度查询，如果还有供应商，按供应商维度查询。一个数据库只能按一种维度来分库。
优点是：非常简单。
缺点- 跨库写存在一致性问题（除非不同维度的表使用公共的分库，事务写入），性能低
- 不能灵活支持更多其他维度的查询
通过Canal同步数据，异构出多个维度的数据源。详见之前写的这篇文章：架构师必备：巧用Canal实现异步、解耦的架构
优点是：更加优雅，无需改动程序主流程。
缺点- 仍然无法解决不断变化的需求，不可能为了支持新维度就异构出一份新数据
现有系统一般都会用到MySQL数据库，需要引入ES，为系统增强多维度查询的功能。
MySQL继续承担业务的实时读写请求、事务操作，ES承担近实时的多维度查询请求，ES可支撑十万级别qps（取决于节点数、分片数、副本数）。
需要注意的是：同步数据至ES是秒级延迟（主要耗费在索引refresh），而查询已进入索引的文档，是在数毫秒到数百毫秒级别。
需要同步机制，来把MySQL中的数据导入到ES中，主要流程如下：
- 预先定义ES索引的mapping配置，而不依赖ES自动生成mapping
- 初始全量导入，后续增量导入：Canal+MQ数据管道同步，不需要或仅需少量代码工作
- 数据过滤：不导入无需检索的字段，减小索引大学，提高性能
- 数据扁平化处理：如果数据库中有json字段列，需要从中提取业务字段，避免嵌套类型的字段，提高性能
-
从ES 8.x版本开始，建议使用Java api client，并且要Java 8及以上环境，因为可使用各种lambda函数，来提高代码可读性
- 优点是新客户端与server代码完全耦合（相比于原Java transport client，在8.x版本已废弃），并且API风格与www.elastic.co/guide/en/elasticsearch/client/index.html
数据模型转换
因为既有MySQL，又有ES，所以有2种异构的数据模型。需要在代码中定义2种数据模型，并且实现类型互相转换的工具类。
- MySQL数据VO
- ES数据VO
- MySQL数据VO、ES数据VO互相转换工具
- 业务层BO
- 接口DTO
ES之所以比MySQL，能胜任多维度查询、全文检索，是因为底层数据结构不同：
- ES倒排索引
- 如果是全文检索字段：会先分词，然后生成 term -> document 的倒排索引，查询时也会把query分词，然后检索出相关的文档。相关度算法如TF-IDF（term frequency–inverse document frequency），取决于：词在该文档中出现的频率（TF，term frequency），越高代表越相关；以及词在所有文档中出现的频率（IDF，inverse document frequency），越高代表越不相关，相当于是一个通用的词，对相关性影响较小。
- 如果是精确值字段：则无需分词，直接把query作为一个整体的term，查询对应文档。
- 因为文档中的所有字段，都生成了倒排索引，所以能处理多维度组合查询
- MySQL B+树
- B+树的非叶子节点记录了孩子节点值的范围，而叶子节点记录了真正的一组值，并且在同一层，形成了一个有序链表
- 组合索引需要显式创建：选择需索引的字段、并且顺序是重要的，所以如果待查询的字段不在索引中，就无法高效查询，可能演变为全表扫描（对聚簇索引的叶子节点做一次遍历）
另外简要回顾一下ES的架构要点：
- 节点分为主节点、数据节点，一个节点上可以有多个分片，分片分为主分片、副本分片，1对多，主分片与副本分片分布在不同的节点，来实现高可用
- 主分片数在创建时，就需要指定，在创建后不能随意更改（如果变化，路由就会出错）；而副本分片可以增加，来提高ES集群的查询QPS
- 路由算法：id % 主分片数，如果创建文档时不指定id，则ES会自动生成；一般会传自定义业务id
- 支持各字段的多维度组合查询，无惧未来新增字段（主要成本在于新增字段后、重建索引）
- 与现有系统完全解耦，适合架构演进
- 在数据量级上远胜Mysql，最大支持PB级数据的存储和查询
- 读写不一致时间在秒级：因为有2个耗时阶段，一是同步阶段将数据从MySQL数据库写入ES，二是ES索引refresh阶段，数据从buffer写入索引后才可查到
- 因此一个trick就是，在写入操作后，前端延迟调用后端的列表查询接口，比如延迟1秒后再展示
- 超高并发下存在瓶颈，存在稳定性问题：目前原生版本支持大约 3-5 万分片，性能已经到达极限，创建索引基本到达 30 秒+ 甚至分钟级。节点数只能到 500 左右基本是极限了。但依然能满足绝大部分场景。数据来源：elasticsearch.cn/slides/259#page=30
- 只把需要搜索的数据导入ES，避免索引过大
- 数据扁平化，不用嵌套结构，提高性能
- 合理设置字段类型，预先定义mapping配置，而不依赖ES自动生成mapping
- 精确值的类型指定为keyword（mapping配置），并且使用term查询
- 精确值是指无需进行range范围查询的字段，既可以是字符串，比如书的作者名字，也可以是数值，比如商品id、订单id、图书ISBN编号、枚举值。在使用中，大部分场景是以id类作为精确值
- 避免无路由查询：无路由查询会并发在多个索引上查询、归并排序结果，会使得集群cpu飙升，影响稳定性
- 避免深度分页查询：如有大量数据查询，推荐用scroll滚动查询
- 设置合理的文件系统缓存（filesytem cache）大小，提高性能：因为ES查询的热数据在文件系统缓存中
- ES分片数在创建后不能随意改动，但是副本数可以随时增加，来提高最大QPS。如果单个分片压力过大，需要扩容。
前面提到ES超高并发下存在瓶颈，极端情况下可能遇到OOM，因此超高并发下需要C++实现的专用搜索引擎
例如：- 百度：通用搜索引擎，根据文字、图片搜索信息
- 电商垂类：电商专用搜索引擎，比如根据关键词查找商品，或根据品牌、价格筛选商品，可总结为商品的搜索、广告、推荐
- 优点是新客户端与server代码完全耦合（相比于原Java transport client，在8.x版本已废弃），并且API风格与www.elastic.co/guide/en/elasticsearch/client/index.html
数据模型转换