相对于单例数据库的查询操作，分布式数据查询会有很多技术难题。
本文记录 Mysql 分库分表 和 Elasticsearch Join 查询的实现思路，了解分布式场景数据处理的设计方案。
文章从常用的关系型数据库 MySQL 的分库分表Join 分析，再到非关系型 ElasticSearch 来分析 Join 实现策略。逐步深入Join 的实现机制。
分库分表场景下，查询语句如何分发，数据如何组织。相较于NoSQL 数据库，Mysql 在SQL 规范的范围内，相对比较容易适配分布式场景。
基于 sharding-jdbc 中间件的方案，了解整个设计思路。
io.shardingsphere.core.executor.ExecutorEngine#execute示例代码工程：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
# 打印的代码，就是在上述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
首先，对于 NoSQL 数据库，要求 Join 查询，可以考虑是不是使用场景和用法有问题。
然后，不可避免的，有些场景需要这个功能。Join 查询的实现更贴近SQL 引擎。
基于 elasticsearch-sql 组件的方案，了解大概的实现思路。
源码地址：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 算法选择
*/
@Override
public 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);
}
// 其他类型查询 ...
}
build 构建阶段和 probe 探测阶段。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 业务数据以及使用场景，还有一种选择是直接存储关联信息的文档。在 Elasticsearch 中，是以完整文档形式提供查询和检索，彻底避开使用 Join 相关的技术。
这样就牵扯到关联是归属类型的数据还是公用类型的数据、关联数据量的大小、关联数据的更新频率等。这些都是使用 Nested 类型需要考虑的因素。
更多的使用方法，可以从网上和官网找到，不做赘述。
我们现在有个业务功能正好使用到 Nested类型， 在查询和优化过程中，解决了非常大的难题。
通过运行原理分析，对于运行流程有了清晰和深入的认知。
对于中间件的优化和技术选型更加有目的性，使用上会更加谨慎和小心。
明确的筛选条件，更小的筛选范围，limit 取值数据，都可以减少计算陈本，提高性能。
作者：京东物流 杨攀
来源：京东云开发者社区