分布式数据库 Join 查询设计与实现浅析

这篇具有很好参考价值的文章主要介绍了分布式数据库 Join 查询设计与实现浅析。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

相对于单例数据库的查询操作,分布式数据查询会有很多技术难题。

本文记录 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 查询,实际相关就是以下两种策略。

  • StandardRoutingEngine binding-tables 模式
  • ComplexRoutingEngine 最复杂的情况,笛卡尔组合关联关系
-- 参数不明,不能定位分片的情况
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

  • 这是个elasticsearch 插件,通过提供http 服务实现类 SQL 查询的功能,高版本的elasticsearch 已经具备该功能⭐
  • 因为 elasticsearch 没有 Join 查询的特性,所以实现 SQL Join 功能,需要提供更加底层的功能,涉及到 Join 算法。

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 算法选择
 */
@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);
    }
    // 其他类型查询 ...
}

③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 取值数据,都可以减少计算陈本,提高性能。

参考

  • 如何在分布式数据库中实现 Hash Join
  • 一文详解MySQL——Join的使用优化 - 掘金

作者:京东物流 杨攀

来源:京东云开发者社区文章来源地址https://www.toymoban.com/news/detail-476666.html

到了这里,关于分布式数据库 Join 查询设计与实现浅析的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 分布式数据库HBase

    HBase是一个高可靠、高性能、 面向列 、可伸缩的分布式数据库,是谷歌BigTable的开源实现,主要用来存储非结构化和把结构化的松散数据。 HBase的目标是处理非常庞大的表,可以通过水平扩展的方式,利用 廉价计算机集群 处理由超过10亿行数据和数百万列元素组成的数据表。

    2024年02月09日
    浏览(46)
  • 【大数据】分布式数据库HBase

    目录 1.概述 1.1.前言 1.2.数据模型 1.3.列式存储的优势 2.实现原理 2.1.region 2.2.LSM树 2.3.完整读写过程 2.4.master的作用 本文式作者大数据系列专栏中的一篇文章,按照专栏来阅读,循序渐进能更好的理解,专栏地址: https://blog.csdn.net/joker_zjn/category_12631789.html?spm=1001.2014.3001.5482 当

    2024年04月27日
    浏览(32)
  • 分布式数据库-事务一致性

    version: v-2023060601 author: 路__ 分布式数据库的“强一致性”应该包含两个方面: serializability(串行) and linearizability(线性一致) ,上述图为“Highly Available Transactions: Virtues and Limitations”论文中对于一致性模型的介绍。图中箭头表示一致性模型之间的关系。对于异步网络上的分

    2024年02月08日
    浏览(39)
  • 分布式数据库NoSQL(二)——MongoDB 数据库基本操作

    MongoDB 是一个基于分布式文件存储的数据库。由 C++ 语言编写。旨在为 WEB 应用提供可扩展的高性能数据存储解决方案。 MongoDB 是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的。它支持的数据结构非常松散,是类似 json 的

    2024年02月06日
    浏览(36)
  • 聊聊分布式 SQL 数据库Doris(七)

    Doris的存储结构是类似LSM-Tree设计的,因此很多方面都是通用的,先阅读了解LSM相关的知识,再看Doris的底层存储与读取流程会清晰透彻很多,LSM基本知识如下: 原理:把各种数据先用log等形式组织在内存中(该数据结构称为MemTable,且有序);到达一定数据量后再批量merge写入磁

    2024年02月05日
    浏览(38)
  • 聊聊分布式 SQL 数据库Doris(二)

    Doris中,Leader节点与非Leader节点和Observer节点之间的元数据高可用和一致性,是通过bdbje(全称:Oracle Berkeley DB Java Edition)的一致性和高可用实现的。 元数据与同步流程 元数据主要存储四类数据: 用户数据信息. 包括数据库, 表的schema, 分片信息等 各类作业信息. 如导入作业, clo

    2024年02月05日
    浏览(52)
  • 聊聊分布式 SQL 数据库Doris(四)

    FE层的架构都能在网上找到说明. 但BE层的架构模式、一致性保障、与FE层之间的请求逻辑,数据传输逻辑等,我个人暂时没有找到相应的博客说明这些的。当然这些是我个人在学习与使用Doris过程中,对内部交互逻辑与实现感兴趣才有这些疑问. 还好现在有GPT这类大模型,有了

    2024年02月05日
    浏览(42)
  • 11.云原生分布式数据库之TIDB

    云原生专栏大纲 从后端视角、运维视角和基础架构视角来看,使用 TiDB 作为数据库系统可以获得分布式架构、高可用性、强一致性、事务支持、水平扩展、高性能、简化运维、灵活的扩展和配置、集成的监控和告警等优势。这些优势使得 TiDB 成为处理大规模数据和高并发请求

    2024年02月01日
    浏览(55)
  • 聊聊分布式 SQL 数据库Doris(五)

    阅读 Doris SQL 原理解析,总结下Doris中SQL解析流程: 词法识别:解析原始SQL文本,拆分token 语法识别:将token转换成AST 单机逻辑查询计划:将AST经过一系列的优化(比如,谓词下推等)成查询计划,提高执行性能与效率。 分布式逻辑查询计划:根据分布式环境(数据分布信息

    2024年02月05日
    浏览(43)
  • 聊聊分布式 SQL 数据库Doris(三)

    在 Doris 的存储引擎规则: 表的数据是以分区为单位存储的,不指定分区创建时,默认就一个分区. 用户数据首先被划分成若干个分区(Partition),划分的规则通常是按照用户指定的分区列进行范围划分,比如按时间划分。 在每个分区内,数据被进一步的按照Hash的方式分桶,分

    2024年02月05日
    浏览(42)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包