相对于单例数据库的查询操作,分布式数据查询会有很多技术难题。
本文记录 Mysql 分库分表 和 Elasticsearch Join 查询的实现思路,了解分布式场景数据处理的设计方案。
文章从常用的关系型数据库 MySQL 的分库分表 Join 分析,再到非关系型 ElasticSearch 来分析 Join 实现策略。逐步深入 Join 的实现机制。
①Mysql 分库分表 Join 查询场景
分库分表场景下,查询语句如何分发,数据如何组织。相较于 NoSQL 数据库,Mysql 在 SQL 规范的范围内,相对比较容易适配分布式场景。
基于 sharding-jdbc 中间件的方案,了解整个设计思路。
sharding-jdbc
- sharding-jdbc 代理了原始的 datasource, 实现 jdbc 规范来完成分库分表的分发和组装,应用层无感知。 
- 执行流程:SQL 解析 => 执行器优化 => SQL 路由 => SQL 改写 => SQL 执行 => 结果归并 - io.shardingsphere.core.executor.ExecutorEngine#execute
 
 
- Join 语句的解析,决定了要分发 SQL 到哪些实例节点上。对应 SQL 路由。 
- SQL 改写就是要把原始(逻辑)表名,改为实际分片的表名。 
- 复杂情况下,Join 查询分发的最多执行的次数 = 数据库实例 × 表 A 分片数 × 表 B 分片数 
Code Insight
示例代码工程:git@github.com:cluoHeadon/sharding-jdbc-demo.git
 /** * 执行查询 SQL 切入点,从这里可以完整 debug 执行流程 * @see ShardingPreparedStatement#execute() * @see ParsingSQLRouter#route(String, List, SQLStatement) Join 查询实际涉及哪些表,就是在路由规则里匹配得出来的。 */public boolean execute() throws SQLException {    try {        // 根据参数(决定分片)和具体的SQL 来匹配相关的实际 Table。        Collection<PreparedStatementUnit> preparedStatementUnits = route();        // 使用线程池,分发执行和结果归并。        return new PreparedStatementExecutor(getConnection().getShardingContext().getExecutorEngine(), routeResult.getSqlStatement().getType(), preparedStatementUnits).execute();    } finally {        JDBCShardingRefreshHandler.build(routeResult, connection).execute();        clearBatch();    }}
   复制代码
 SQL 路由策略
启用 sql 打印,直观看到实际分发执行的 SQL
 # 打印的代码,就是在上述route 得出 ExecutionUnits 后,打印的sharding.jdbc.config.sharding.props.sql.show=true
   复制代码
 
sharding-jdbc 根据不同的 SQL 语句,会有不同的路由策略。我们关注的 Join 查询,实际相关就是以下两种策略。
 -- 参数不明,不能定位分片的情况select * from order o inner join order_item oi on o.order_id = oi.order_id 
-- 路由结果-- Actual SQL: db1 ::: select * from order_1 o inner join order_item_1 oi on o.order_id = oi.order_id -- Actual SQL: db1 ::: select * from order_1 o inner join order_item_0 oi on o.order_id = oi.order_id -- Actual SQL: db1 ::: select * from order_0 o inner join order_item_1 oi on o.order_id = oi.order_id -- Actual SQL: db1 ::: select * from order_0 o inner join order_item_0 oi on o.order_id = oi.order_id -- Actual SQL: db0 ::: select * from order_1 o inner join order_item_1 oi on o.order_id = oi.order_id -- Actual SQL: db0 ::: select * from order_1 o inner join order_item_0 oi on o.order_id = oi.order_id -- Actual SQL: db0 ::: select * from order_0 o inner join order_item_1 oi on o.order_id = oi.order_id -- Actual SQL: db0 ::: select * from order_0 o inner join order_item_0 oi on o.order_id = oi.order_id
   复制代码
 ②Elasticsearch Join 查询场景
首先,对于 NoSQL 数据库,要求 Join 查询,可以考虑是不是使用场景和用法有问题。
然后,不可避免的,有些场景需要这个功能。Join 查询的实现更贴近 SQL 引擎。
基于 elasticsearch-sql 组件的方案,了解大概的实现思路。
elasticsearch-sql
Code Insight
源码地址:git@github.com:NLPchina/elasticsearch-sql.git
 /** * Execute the ActionRequest and returns the REST response using the channel. * @see ElasticDefaultRestExecutor#execute * @see ESJoinQueryActionFactory#createJoinAction Join 算法选择 */@Overridepublic void execute(Client client, Map<String, String> params, QueryAction queryAction, RestChannel channel) throws Exception{    // sql parse    SqlElasticRequestBuilder requestBuilder = queryAction.explain();
    // join 查询    if(requestBuilder instanceof JoinRequestBuilder){        // join 算法选择。包括:HashJoinElasticExecutor、NestedLoopsElasticExecutor        // 如果关联条件为等值(Condition.OPEAR.EQ),则使用 HashJoinElasticExecutor        ElasticJoinExecutor executor = ElasticJoinExecutor.createJoinExecutor(client,requestBuilder);        executor.run();        executor.sendResponse(channel);    }    // 其他类型查询 ...}
   复制代码
 ③More Than Join
Join 算法
- 常用三种 Join 算法:Nested Loop Join,Hash Join、 Merge Join 
- MySQL 只支持 NLJ 或其变种,8.0.18 版本后支持 Hash Join 
- NLJ 相当于两个嵌套循环,用第一张表做 Outter Loop,第二张表做 Inner Loop,Outter Loop 的每一条记录跟 Inner Loop 的记录作比较,最终符合条件的就将该数据记录。 
- Hash Join 分为两个阶段; - build构建阶段和- probe探测阶段。
 
- 可以使用 Explain 查看 MySQL 使用哪种 Join 算法。 需要的语法关键字: FORMAT=JSON or FORMAT=Tree 
 EXPLAIN FORMAT=JSON  SELECT * FROM    sale_line_info u    JOIN sale_line_manager o ON u.sale_line_code = o.sale_line_code;
   复制代码
 
 {    "query_block": {        "select_id": 1,        // 使用的join 算法: nested_loop        "nested_loop": [            // 涉及join 的表以及对应的 key,其他的信息与常用explain 类似            {                "table": {                    "table_name": "o",                    "access_type": "ALL"                }            },            {                "table": {                    "table_name": "u",                    "access_type": "ref"                }            }        ]    }}
   复制代码
 Elasticsearch Nested 类型
分析 Elasticsearch 业务数据以及使用场景,还有一种选择是直接存储关联信息的文档。在 Elasticsearch 中,是以完整文档形式提供查询和检索,彻底避开使用 Join 相关的技术。
这样就牵扯到关联是归属类型的数据还是公用类型的数据、关联数据量的大小、关联数据的更新频率等。这些都是使用 Nested 类型需要考虑的因素。
更多的使用方法,可以从网上和官网找到,不做赘述。
我们现在有个业务功能正好使用到 Nested 类型, 在查询和优化过程中,解决了非常大的难题。
总结
通过运行原理分析,对于运行流程有了清晰和深入的认知。
对于中间件的优化和技术选型更加有目的性,使用上会更加谨慎和小心。
明确的筛选条件,更小的筛选范围,limit 取值数据,都可以减少计算陈本,提高性能。
参考
作者:京东物流 杨攀
来源:京东云开发者社区
评论