天道酬勤,学无止境

sharding-jdbc垂直分库分表实战

  • 资料
    分库分表的概念及应用场景详解
    分库分表带来的一些问题
    sharding-jdbc水平垂直分库分表环境搭建
    sharding-jdbc水平分库分表实战
    sharding-jdbc垂直分库分表实战

  • 垂直分库分表目的
    1.主从表结构拆分,也在一定程度缓解索引性能,同时可以使主从表可以并发操作,不被行锁限制(垂直分表)
    2.微服务架构情况下,为了业务更好的区分,采用多schema模式,不同模块使用不同的schema(伪垂直分库)
    3.微服务架构情况下,由于某些模块业务量非常大,导致单库性能下降,影响其它模块,一般会单独拆到另外一个库中(真垂直分库)

  • 垂直分表实现
    垂直分表就不做实验了,我们每天都在做垂直分表,比如主从表的结构

  • 垂直分库实现

    public class springJdbcTest {
        public static void main(String[] args) throws SQLException {
    
            //获取数据源
            DataSource dataSource = getDataSource();
    
            //获取jdbctemplate
            JdbcTemplate jdbcTemplate = getJdbcTemplate(dataSource);
    
    
            //执行插入语句
            for(int i=1;i<=10;i++) {
                //执行插入用户语句
                jdbcTemplate.update("insert into t_user(user_name,user_age,user_type) values (?,?,?)",i,i,i);
                //执行插入订单语句
                jdbcTemplate.update("insert into t_order(user_id,order_price) values (?,?)",i,i);
            }
    
        }
    
    
        public static JdbcTemplate getJdbcTemplate( DataSource dataSource){
            JdbcTemplate jdbcTemplate = new JdbcTemplate();
            jdbcTemplate.setDataSource(dataSource);
            return jdbcTemplate;
        }
    
        
    
        public static DataSource getDataSource() throws SQLException {
            // 配置真实数据源
            Map<String, DataSource> dataSourceMap = new HashMap<>();
    
            // 配置第 1 个数据源
            DruidDataSource dataSource1 = new DruidDataSource();
            dataSource1.setDriverClassName("com.mysql.jdbc.Driver");
            dataSource1.setUrl("jdbc:mysql://localhost:3306/ds0?characterEncoding=utf-8&useSSL=false");
            dataSource1.setUsername("root");
            dataSource1.setPassword("123456");
            dataSourceMap.put("ds0", dataSource1);
    
            // 配置第 2 个数据源
            DruidDataSource dataSource2 = new DruidDataSource();
            dataSource2.setDriverClassName("com.mysql.jdbc.Driver");
            dataSource2.setUrl("jdbc:mysql://localhost:3307/ds0?characterEncoding=utf-8&useSSL=false");
            dataSource2.setUsername("root");
            dataSource2.setPassword("123456");
            dataSourceMap.put("ds1", dataSource2);
    
            // 配置表规则
            ShardingRuleConfiguration shardingRuleConfiguration=new ShardingRuleConfiguration();
    
            //用户表配置
            //配置逻辑表和实际表分布情况,配置用户表分布情况
            TableRuleConfiguration tableRuleConfiguration1 = new TableRuleConfiguration("t_user","ds0.t_user");
            //生成主键策略
            KeyGeneratorConfiguration keyGeneratorConfiguration1 = new KeyGeneratorConfiguration("snowflake","user_id");
            //用户表的表和库路由配置,都是单库单表情况,相当于多数据源情况,库和表都是固定
            ShardingStrategyConfiguration shardingStrategyConfiguration1 = new InlineShardingStrategyConfiguration("user_id","t_user");
            ShardingStrategyConfiguration shardingStrategyConfiguration2 = new InlineShardingStrategyConfiguration("user_id","ds0");
            tableRuleConfiguration1.setKeyGeneratorConfig(keyGeneratorConfiguration1);
            tableRuleConfiguration1.setTableShardingStrategyConfig(shardingStrategyConfiguration1);
            tableRuleConfiguration1.setDatabaseShardingStrategyConfig(shardingStrategyConfiguration2);
    
    
            //订单表配置
            //配置逻辑表和实际表分布情况,配置订单表分布情况
            TableRuleConfiguration tableRuleConfiguration2 = new TableRuleConfiguration("t_order","ds1.t_order");
            //生成主键策略
            KeyGeneratorConfiguration keyGeneratorConfiguration2 = new KeyGeneratorConfiguration("snowflake","order_id");
            //订单表的表和库路由配置,都是单库单表情况,相当于多数据源情况,库和表都是固定
            ShardingStrategyConfiguration shardingStrategyConfiguration3 = new InlineShardingStrategyConfiguration("order_id","t_order");
            ShardingStrategyConfiguration shardingStrategyConfiguration4 = new InlineShardingStrategyConfiguration("order_id","ds1");
            tableRuleConfiguration2.setKeyGeneratorConfig(keyGeneratorConfiguration2);
            tableRuleConfiguration2.setTableShardingStrategyConfig(shardingStrategyConfiguration3);
            tableRuleConfiguration2.setDatabaseShardingStrategyConfig(shardingStrategyConfiguration4);
    
            //实际表生成主键策略
            shardingRuleConfiguration.setTableRuleConfigs(Arrays.asList(tableRuleConfiguration1,tableRuleConfiguration2));
    
            return ShardingDataSourceFactory.createDataSource(dataSourceMap, shardingRuleConfiguration, new Properties());
        }
    }
    
    
  • 垂直分库效果
    在这里插入图片描述
    在这里插入图片描述

受限制的 HTML

  • 允许的HTML标签:<a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • 自动断行和分段。
  • 网页和电子邮件地址自动转换为链接。

相关推荐
  • sharding-jdbc水平垂直分库分表环境搭建
    资料 分库分表的概念及应用场景详解 分库分表带来的一些问题 sharding-jdbc水平垂直分库分表环境搭建 sharding-jdbc水平分库分表实战 sharding-jdbc垂直分库分表实战 使用docker启动两个mysql数据库 docker run -it -e MYSQL_ROOT_PASSWORD=123456 -p 3306:3306 mysql docker run -it -e MYSQL_ROOT_PASSWORD=123456 -p 3307:3306 mysql 水平分表使用表创建 1.结构如下: 2.表sql create table t_user_1 ( user_id bigint null, //用户id user_name varchar(20) null, //用户名称 user_age int null, //用户年龄 user_type int null //用户类型 1 会员 2 普通用户 ); create table t_user_2 ( user_id bigint null, //用户id user_name varchar(20) null, //用户名称 user_age int null, //用户年龄 user_type int null //用户类型 1 会员 2 普通用户 ); 水平分库使用表创建 1.结构如下
  • Sharding-JDBC分库分表
    文章目录 分库分表是什么分库分表的方式垂直分表垂直分库水平分库水平分表小结 分库分表带来的问题事务一致性问题跨节点关联查询跨节点分页、排序函数主键避重公共表 Sharding-JDBC介绍Sharding-JDBC与JDBC性能对比 Sharding-JDBC快速入门需求说明编写程序 分库分表是什么 比如小明是一家初创电商平台的开发人员,他负责卖家模块的功能开发,其中涉及了店铺、商品的相关业务,设计如下数据库 通过以下SQL能够获取到商品相关的店铺信息、地理区域信息: SELECT p.*,r.[地理区域名称],s.[店铺名称],s.[信誉] FROM [商品信息] p LEFT JOIN [地理区域] r ON p.[产地] = r.[地理区域编码] LEFT JOIN [店铺信息] s ON p.id = s.[所属店铺] WHERE p.id = ? 形成类似以下列表展示: 随着公司业务快速发展,数据库中的数据量猛增,访问性能也变慢了,优化迫在眉睫。分析一下问题出现在哪儿呢? 关系型数据库本身比较容易成为系统瓶颈,单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后,由于查询维度较多,即使添加从库、优化索引,做很多操作时性能仍下降严重。 方案1 通过提升服务器硬件能力来提高数据处理能力,比如增加存储容量 、CPU等,这种方案成本很高
  • Sharding-JDBC视频
    1 课程内容介绍 本课程讲解关系型数据库分库分表解决方案,包括:垂直分库、垂直分表、水平分库、水平分表、读写分离,涵盖了分库分表的各种方案,并且深入讲解Sharding-JDBC框架的原理及使用方法, 本课程从思想原理、技术框架、案例实操三个方面去学习,可以快速的将分库分表技术应用到生产实践中,解决大数据存储与处理的问题。 2 课程章节 章节一:概述 什么是分库分表分库分表的方式分库分表带来的问题Sharding-JDBC介绍 章节二:Sharding-JDBC快速入门需求说明环境搭建流程分析其它集成方式 章节三:Sharding-JDBC执行原理基本概念SQL解析SQL路由SQL改写SQL执行结果归并小结 章节四:Sharding-JDBC分库分表水平分表水平分库垂直分库公共表读写分离 章节五:综合案例需求分析数据库设计搭建环境实例开发 章节六:课程总结分库分表方案回顾最佳实践 3 课程视频下载 第一天: 链接:https://pan.baidu.com/s/1tYnDfQIagm1Hk8BhptVQww 提取码:c7f2 第二天: 关注公众号,发布“Sharding-JDBC”获取全部链接 来源:https://blog.csdn.net/weixin_44062339/article/details/101794046
  • 分库分表实战及中间件(一)
    分库分表实战及中间件 背景描述 在项目中,使用单库单个mysql去存储数据,其中我们某个表的数据量目前是3000w 、某个表由于客户一些创建的数据几乎每天增量数据是几十万,而且每个客户相对对应的数据增量也不仅相同。考虑到之后到某个节点时间数据可能会达到上限1个亿。 我们都知道mysql单表数据量是3000w-5000w左右,如果增量再多,单表的查询效率会变慢。 对此我们需要将其分开存储,也就是需要考虑分库分表的时候了。那我们如何进行分库分表操作呢? 为什么要分表 上面也说了,由于单表的数据量在未来会达到一个亿级别甚至更高,单表查询效率会变慢。 这儿是单表查询数据量会变大。故此我们采用分表操作,业务并不需要分库操作。 即单表数据量太大 在之后的查询、插入、更新操作都会变慢,在加字段、加索引、机器迁移都会产生高负载,影响服务。 对于分表我们怎么选择? 分表分为水平分表和垂直分表 水平分表 针对数据量巨大的单张表(比如订单表),按照规则把一张表的数据切分到多张表里面去。但是这些表还是在同一个库中,所以库级别的数据库操作还是有IO瓶颈。 缺点是:并没有解决单个数据库并发以及IO的提升,如需要提升可增加机器配置,或者进行水平分库又分表。 好处就不用多说了。 水平分表规则 RANGE 时间:按照年、月、日去切分。例如order_2020、order_202005、order_20200501
  • Apache——ShardingSphere(分布式数据库中间件、分库分表的利器)
    ShardingSphere官网:https://shardingsphere.apache.org/ 什么是ShardingSphere? 官网说明: Apache ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈,它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar(规划中)这3款相互独立,却又能够混合部署配合使用的产品组成。它们均提供标准化的数据分片、分布式事务和数据库治理功能,可适用于如Java同构、异构语言、云原生等各种多样化的应用场景。 ShardingSphere定位为关系型数据库中间件,旨在充分合理地在分布式的场景下里用关系型数据库的计算和存储能力,而并非实现一个全新的关系型数据库,它通过关注不变,进而抓住事物本质。关系型数据库当今依然占有巨大市场,是各个公司核心业务的基石,未来也难于撼动,我们目前阶段更加关注在原有基础上的增量,而非颠覆。 ShardingSphere已经在2020年4月16日成为Apache顶级项目(Apache官网发布从4.0.0版本开始)。 小结: 1. 是一套开源的分布式数据库中间件解决方案 2. 有三个产品Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar(TODO)组成 3. 定位为一个关系型数据库中间件
  • 跟着小刘一起入门一下Sharding jdbc
    文章目录 sharding jdbc -缘起分库分表的出现小结分库分表带来问题Sharding JDBC 介绍快速入门 sharding jdbc -缘起 前段时间,在工作接手了一个新的项目,我问Boss,这个项目使用的是什么技术,老板轻描淡写的说到,还是那一套 Springboot ,就是 用了一下了那个分库分表技术,你端午节,去了解一下这个技术 ,Sharding jdbc 唉! 又要了解新技术,还真是活到老,学到老啊! 天天都有去了解新技术,这东西居然没听过,加上我不喜欢看视频,然后就默默打开官网,看到了上面那幅图 emmmmm … 最后切换了中文 默默的点开了文档,仔细一看,哦哟!怎么工整的吗? 于是点进去,就开始学了起来,官网的文章较为抽象,可能没有项目中实际的案例,所以这里,就有小刘,带大家走一遍! 分库分表的出现 首先要了解Sharding JDBC,就得知道,为什么会出现Sharding JDBC ,这里我们,传统的思路慢慢转变 ,首先,小刘是一家公司的架构师 ,有一天,公司最近在做电商项目, 他负责卖家模块的设计和优化,其中涉及了店铺、商品的相关业务,设计如下 数据库 通过以下SQL能够获取到商品相关的店铺信息、地理区域信息: SELECT p.*,r.[地理区域名称],s.[店铺名称],s.[信誉] FROM [商品信息] p LEFT JOIN [地理区域]
  • (基础)Sharding-JDBC 第一章 快速入门
    Sharding-JDBC 第一章 快速入门 概述1.1.分库分表是什么1.1.1. 分库分表的应用场景1.1.2 JDBC规范DataSourceConnectionStatementResultSet基于适配器模式的 JDBC 重写实现方案ShardingSphere 重写 JDBC 规范示例:ShardingConnectionAbstractConnectionAdapterWrapperAdapterAbstractUnsupportedOperationConnection 1.1.2. Sharding-JDBC1.1.3. Sharding-Proxyshardingsphere基础设施shardingsphere分片引擎shardingsphere分布式事务shardingsphere治理与集成 1.2.分库分表的方式1.2.1.垂直分表(大表分小表)1.2.2.垂直分库(专库专用)1.2.3.水平分库(一表多库)1.2.4.水平分表(一表多表)1.2.5 小结 1.3.分库分表带来的问题1.3.1.事务一致性问题1.3.2.跨节点关联查询1.3.3.跨节点分页、排序函数1.3.4.主键避重1.3.5.公共表1.3.6.代理机制 1.4 Sharding-JDBC介绍1.4.1 Sharding-JDBC介绍1.4.2 与jdbc性能对比 Sharding
  • 亿级数据量性能优化必备之分库分表
    每个业务系统根据业务拆分成不同的系统,用不同的数据库,比如客户系统-》客户DB Oracle, 合同系统-》合同DB MySQL 放款系统-》放款DB Postgresql 1.什么情况下分库分表,分库分表解决什么问题 分库分表的好处 1.提升数据的查询速度 2.缓解数据库的压力 3.提升存储容量 4. 高可用:某个数据库出现了问题,其他业务不影响 消费金融核心系统 客户、账户、商户、产品、放款、还款、合同、信审、资金拆分这些模块,单独开发,部署 单张表数据量超载 数据水平拆分,分散存储 单表行数达到多少时适合分表? 单表行数超过500万行时或者单表容量超过2GB时,才推荐使用分库分表。 如果项目中预计三年以上的时间数据量才能达到这个级别时,请不要在创建表时就进行分库分表。 核心数据库-Oracle 客户表、账户表、商户表、产品表、放款表、还款表、合同表、 信审表、批扣表、资金表、风控表、催收表 2. 数据库表到了分库分表的地步,怎么分库分表 要从哪些纬度分库分表,垂直和水平切分, 垂直切分,按照表结构或说字段划分,得到不同业务相关的表(客户或合同业务相关的表放到一个数据库),单张表拆分成多张表也是一类 水平切分,基于数据划分,划分的结果是表结构相同,数据量不同;单库或多库的水平切分 单库的水平切分:比如交易历史表,拆分成当天,当月,历史(在历史记录上按月份分区) 分库的话,多个库
  • 大型分布式业务平台数据库优化方法(下)
    输入标题“当数据库单表达到千万以上级别时,如何应对?高效改造方案一手资料奉上!当MySQL数据库的单表数据量达到千万级别以上时,不管是业务逻辑的查询,还是更新,或者删除都会使得数据库的平均响应时间过长。这时再通过(上)篇中的单表SQL优化技术解决方案收效就微乎其微了。对于如此大量数据,我们还可以利用以下几种业务平台的架构方案进行进一步的技术改造。一、分离热点数据方案当单库数据量比较大影响了查询/更新/删除的SQL执行效率时,我们可以直接想到在不影响业务逻辑的前提下,如果可以直接减少数据库中单表的数据量,那就能够达到我们的优化数据库的目标。该种方案称之为“分离热点数据”。基于最近时间段内写入数据一般会成为热点数据的假设,同时考虑到在业务平台中对于存量历史数据的需求基本都是查询,而对于平台中的最近时段生成的数据一般会涉及查询/更新/删除等操作。因此可以设定一个时间的阀值,比如6个月,根据这个时间点来进行分表。对于6个月以内的数据,存热点库的数据表,6个月以上的数据存在历史库数据表里,业务平台的应用工程通过配置多数据源以及增加代理层即可实现服务对于不同数据库的访问,用以区分对热点数据库和历史库的访问。由于历史存量数据会越来越多,因此可以根据业务需要对历史库内的数据进行实现MYSQL分区表
  • 大型分布式业务平台数据库优化方法(下)
    输入标题“当数据库单表达到千万以上级别时,如何应对?高效改造方案一手资料奉上!当MySQL数据库的单表数据量达到千万级别以上时,不管是业务逻辑的查询,还是更新,或者删除都会使得数据库的平均响应时间过长。这时再通过(上)篇中的单表SQL优化技术解决方案收效就微乎其微了。对于如此大量数据,我们还可以利用以下几种业务平台的架构方案进行进一步的技术改造。一、分离热点数据方案当单库数据量比较大影响了查询/更新/删除的SQL执行效率时,我们可以直接想到在不影响业务逻辑的前提下,如果可以直接减少数据库中单表的数据量,那就能够达到我们的优化数据库的目标。该种方案称之为“分离热点数据”。基于最近时间段内写入数据一般会成为热点数据的假设,同时考虑到在业务平台中对于存量历史数据的需求基本都是查询,而对于平台中的最近时段生成的数据一般会涉及查询/更新/删除等操作。因此可以设定一个时间的阀值,比如6个月,根据这个时间点来进行分表。对于6个月以内的数据,存热点库的数据表,6个月以上的数据存在历史库数据表里,业务平台的应用工程通过配置多数据源以及增加代理层即可实现服务对于不同数据库的访问,用以区分对热点数据库和历史库的访问。由于历史存量数据会越来越多,因此可以根据业务需要对历史库内的数据进行实现MYSQL分区表
  • 我的架构梦:(五十三) 分库分表实战及中间件之ShardingSphere实战
    上一篇:我的架构梦:(五十二) 分库分表实战及中间件之实战背景 分库分表实战及中间件之ShardingSphere实战 二、ShardingSphere实战 1、ShardingSphere 2、Sharding-JDBC 3、数据分片剖析实战 5、强制路由剖析实战 6、数据脱敏剖析实战 7、分布式事务剖析实战 8、SPI 加载剖析 9、编排治理剖析 10、Sharding-Proxy实战 二、ShardingSphere实战 1、ShardingSphere Apache ShardingSphere是一款开源的分布式数据库中间件组成的生态圈。它由Sharding-JDBC、 Sharding-Proxy和Sharding-Si 来源:https://riemann.blog.csdn.net/article/details/109037291
  • Sharding-jdbc的实战入门之水平分表(一)
    前言 上一篇文章中老顾介绍了sharding-jdbc的基本概念,今天老顾就来介绍一下如何使用。 经常碰到一些小伙伴的问题,就是我们到达什么量级才会分库分表? 分库分表经验值 mysql单表经验 300W Mysql 可以轻松抗住600W 数据开始卡,优化可以解决(表结构,索引设计)800W ~ 1000W 牛逼的DBA 优化都会遇到瓶颈 一般MySQL单表1000W左右的数据是可以不需要考虑分表的。当然,除了考虑当前的数据量和性能情况时,我们需要提前考虑系统半年到一年左右的业务增长情况。但是要避免过度设计(考虑了很多未来几年的需求,例如一张表在未来几年内数据预计会达到几千万,这个就过渡考虑了) 根据数据量增长速度,选择实现步骤 第一步:不分库不分表 第二步:同库内的分表 第三步:分库分表 不要过度设计,一上来玩大的就进行分库分表 分库如果多个实例存在同一台服务器上,只是解决了数据库最大连接数的问题,但是 io(数据库数据是存储在硬盘上,每次获取都需要去硬盘把数据捞出来),cpu 等服务器资源瓶颈并没有解决。数据库的性能取决于服务器等性能 搭建环境 我们采用SpringBoot + MybatisPlus + Shrading-JDBC + Druid链接池 POM.xml依赖 老顾用了相对比较新的版本,SpringBoot 2.2.9,Sharding-Jdbc4.1.1版本
  • 3、Sharding-JDBC----垂直分库----使用案例---专库专表
    1、Sharding-JDBC----水平分库----使用案例 2、Sharding-JDBC----水平分表----使用案例 3、Sharding-JDBC----垂直分库----使用案例 4、Sharding-JDBC----垂直分表----使用案例 垂直分库实际上就是专库专表 垂直分裤就是将表单独存一个库 创建数据库 CREATE DATABASE user_db; USE user_db; SET NAMES utf8mb4; SET FOREIGN_KEY_CHECKS = 0; -- ---------------------------- -- Table structure for t_user -- ---------------------------- DROP TABLE IF EXISTS `t_user`; CREATE TABLE `t_user` ( `user_id` bigint(20) NOT NULL, `username` varchar(100) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL, `ustatus` varchar(50) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL, PRIMARY KEY (`user
  • 一文搞懂数据库分库分表最佳实践及面试题
    春风如贵客,一到便繁华。各位看官点赞再看,养成好习惯(●´∀`●) 目录: 前言: 水平拆表: 水平拆分的优点: 水平切分的缺点: 垂直拆表: 垂直切分的优点: 垂直切分的缺点: 面试题: 前言: 目前很多互联网系统都存在单表数据量过大的问题,这就降低了查询速度,影响了客户体验。为了提高查询速度,我们可以优化sql语句,优化表结构和索引,不过对那些百万级千万级的数据库表,即便是优化过后,查询速度还是满足不了要求。这时候我们就可以通过分表降低单次查询数据量,从而提高查询速度, 分表的方式有两种:水平拆分和垂直拆分,两者各有利弊,适用于不同的情况。 分库的工具有很多:这里推荐两种(工具的利弊,请自行调研,官网和社区优先,面试题部分会简单介绍下。) Sharding-Sphere:jar,前身是sharding-jdbc; Mycat:中间件。 首先要明确的一点是,分库分表,首先得知道瓶颈在哪里,然后才能合理地拆分。明确了瓶颈在哪里,才可以选择合适的方法进行操作,做到事半功倍的效果。 水平拆表: 水平拆分:指的是按照数据库表行的拆分。 根据阿里巴巴设计规范:单表一到两年内数据量超过500w或数据容量超过10G考虑分表。这时可以把一张的表的数据拆成多张表来存放。 以user表为例:有两种拆分方法: 1、提前建好若干张表。 经过业务评估,创建5张user表可以满足业务未来三到五年的业务增长量
  • 使用 ShardingSphere 实操MySQL分库分表实战
    ShardingSphere 分库分表 什么是 ShardingSphere Apache ShardingSphere 是一套开源的分布式数据库中间件解决方案组成的生态圈,它由 JDBC、Proxy 和 Sidecar(规划中)这 3 款相互独立,却又能够混合部署配合使用的产品组成。 它们均提供标准化的数据分片、分布式事务和数据库治理功能,可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。 一套开源的分布式数据库中间件解决方案。有三个产品:JDBC、Proxy、Sidecar。 什么是分库分表 当我们使用读写分离、索引、缓存后,数据库的压力还是很大的时候,这就需要使用到数据库拆分了。 数据库拆分简单来说,就是指通过某种特定的条件,按照某个维度,将我们存放在同一个数据库中的数据分散存放到多个数据库(主机)上面以达到分散单库(主机)负载的效果。 分库分表之垂直拆分 专库专用。一个数据库由很多表的构成,每个表对应着不同的业务,垂直切分是指按照业务将表进行分类,分布到不同的数据库上面,这样也就将数据或者说压力分担到不同的库上面。如下图: 优点: 拆分后业务清晰,拆分规则明确。系统之间整合或扩展容易。数据维护简单。 缺点: 部分业务表无法 join,只能通过接口方式解决,提高了系统复杂度。受每种业务不同的限制存在单库性能瓶颈,不易数据扩展跟性能提高。事务处理复杂。
  • SpringBoot+Sharding-JDBC操作分库分表(超超超详细)
    什么是Sharding-JDBC?什么是分库分表?为什么要分库分表? 可查看本篇博客: Apache——ShardingSphere(分布式数据库中间件、对于分库分表的操作利器) Sharding-JDBC操作水平分表 一、搭建环境 基础环境:SpringBoot2.2.1 + MybatisPlus + Sharding-JDBC + Druid连接池创建SpringBoot工程 修改SpringBoot项目版本为2.2.1 引入相关依赖 <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> <exclusions> <exclusion> <groupId>org.junit.vintage</groupId> <artifactId>junit-vintage-engine</artifactId> </exclusion
  • Sharding-JDBC分库分表配置
    依赖 <dependency> <groupId>org.apache.shardingsphere</groupId> <artifactId>sharding‐jdbc‐spring‐boot‐starter</artifactId> <version>4.0.0‐RC1</version> </dependency> 水平分表 ###第一步:配置数据源 spring.shardingsphere.datasource.names = m1 #数据源m1 spring.shardingsphere.datasource.m1.type = com.alibaba.druid.pool.DruidDataSource spring.shardingsphere.datasource.m1.driver‐class‐name = com.mysql.jdbc.Driver spring.shardingsphere.datasource.m1.url = jdbc:mysql://localhost:3306/order_db_1?useUnicode=true spring.shardingsphere.datasource.m1.username = root spring.shardingsphere.datasource.m1.password = root ###第二步
  • 五、Sharding-JDBC 垂直分库
    1、简介   前面已经介绍过,垂直分库是指按照业务将表进行分类,分布到不同的数据库上面,每个库可以放在不同的服务器上,它的核心理念是专库专用。接下来看一下如何使用 Sharding-JDBC 实现垂直分库。 2、实现 2.1 创建数据库和表 /* SQLyog Ultimate v12.08 (32 bit) MySQL - 8.0.11 : Database - order_db ********************************************************************* */ /*!40101 SET NAMES utf8 */; /*!40101 SET SQL_MODE=''*/; /*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */; /*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */; /*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL
  • ShardingSphere之分库分表——水平、垂直拆分数据库与表 及Sharding-JDBC实现数据分片、公共表、读写分离、数据脱敏
    一. 简介: 1. 什么是ShardingSphere Apache ShardingSphere 是一套开源的分布式数据库中间件解决方案组成的生态圈,它由 JDBC、Proxy 和 Sidecar(规划中)这 3 款相互独立,却又能够混合部署配合使用的产品组成。 它们均提供标准化的数据分片、分布式事务和数据库治理功能,可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。 2. ShardingSphere的定位 Apache ShardingSphere 定位为关系型数据库中间件,旨在充分合理地在分布式的场景下利用关系型数据库的计算和存储能力,而并非实现一个全新的关系型数据库。 它通过关注不变,进而抓住事物本质。关系型数据库当今依然占有巨大市场,是各个公司核心业务的基石,未来也难于撼动,我们目前阶段更加关注在原有基础上的增量,而非颠覆。 二. 分库分表: 1. 为什么么要进行分库分表? 我们都知道,数据库的数据量是不可控的,就好比大型的电商项目,随着时间的发展, 数据量会越来越多,一旦达到某个量,我们再去对数据库进行分库分表操作的时候,就会遇到性能瓶颈的问题,解决方案之一,便是对数据库进行分库分表操作.如下图: 2. 分库分表的方式: ⑴. 垂直拆分 垂直拆分又可分为: ①.垂直分库: 把单一业务按照业务进行划分,专库专表,分别把不同的数据库存放到不同的服务器
  • springboot整合sharding-jdbc
    前言 生产环境中,当单表数据达到一定的量级的时候,查询性能的瓶颈迟早会暴露出来,这个时候,解决思路可以考虑两种,一是从架构上对当前应用进行优化,比如使用es或mongodb等非关系型数据库进行配合使用,当然这种方式需要考虑一定的改造成本和团队开发人员的学习成本,另一种就是分库分表 我们常说分库分表,但是具体怎么分?为什么要分?以及使用什么样的技术进行分?这些都是需要提前考虑的问题,下面介绍一个行业中应用比较成熟的分库分表的中间件sharding-jdbc,由当当网开源的一款用于实现分库分表、读写分离等功能的中间件 基本概念 数据表切分方式 水平切分 垂直切分 考虑在应用中有一张这样的表,t_order表,即用于保存订单数据的表,当数据量比较小,可以直观的认为数据量在100万以下的时候,查询的时候,对于5.7以上的mysql引擎来说问题不是很大,但是当量级达到1000万甚至更大的时候,单表的读写性能会因为数据量过大带来的IO性能瓶颈越来越严重 这时候单纯从优化查询的性能考虑,可以有2种思路 第一,降低查询表的数据量,比如单表1000万数据和单表100万数据,这样的查询性能谁更快一目了然,因此方案一可以考虑进行分表,将单表拆分成多表,这种方式可以认为是水平拆分; 来源:https://blog.csdn.net/zhangcongyi420/article/details