分库分表中间件 sharding

任何一个技术的出现，都不是为了秀肌肉而产生的。

sharding jdbc 这个分库分表技术要解决的问题就是，随着数据量级的提升，物理硬件达到瓶颈，单表的性能优化也带来了瓶颈。而数据量仍然要突破的难题。

这个问题的解决方案，其实就是一种分治的思想。用一句白话来解释，就是大事化小，举个简答的例子，就是让你查一斤大米确切的有几个，如果让你一个人来查花费时间太多，假如需要花费三个小时。那么找两个人，把一斤大米分成两份，花费的时间大约就是一个半小时。如果分成六份，六个人来查，大概就是花费半个小时。这就是分治的思想，效果又很明显，从三个小时，到半个小时。

把这个问题还原成数据库的问题，数据库有库的概念，表的概念。那么解决问题就是要分库分表。

如果还不了解分库分表的概念请看我一篇文章：https://blog.csdn.net/star1210644725/article/details/104375267

# # 分库分表带来的问题

在 https://blog.csdn.net/star1210644725/article/details/104375267 这篇文章里的已经介绍了一些问题。

此外，还有一些问题是一定要解决的：比如对数据源问题，分库以后在不同的服务器上，访问ip地址都不一样了。等等

# # sharding jdbc

轻量级框架，以jar包的形式使用，相当于是增强版的jdbc驱动。

核心功能是：提供数据分片，和读写分离。

优点所在是：应用可以透明的使用 jdbc 访问数据库，达到让应用程序对分库分表无感知。也就是说，分库分表明明带来的问题，但是就是又有人帮你做处理，让应用程序仍然按照之前的逻辑来写，并不用因为分库分表了做任何改变。

# # 问题解决过程

因为数据库性能瓶颈，所以需要进行分库分表。

因为引入了分库分表，所以引入多数据源问题。

因为有多数据源问题，所以代码逻辑需要修改。

应为sharding 的出现，所以解决了修改逻辑的难题，

最终做到让业务无感多数据源，做到分库分表。

# # 无感的解决问题，带来的是：单机性能损耗的问题。

为什么会消耗内存呢？

其实中间多了一层 sql 截取和重装的过程，因为对数据库操作的本质还是sql，因为数据库只认识sql

因为是分库分表，所以结果还是要汇总的。

# # sharding jdbc 的使用

就像是jdbc 驱动一样，先配置数据源。

然后再配置数据节点

配置主键生成测测咯，主键不能是数据库自增了，要使用全局主键。

上图所谓的表名是逻辑表名

看最后一行：其实这是逻辑表名和实际数据库表名形成映射的关键所在后边加上数字，就是实际数据库的表名。而逻辑表名实际上就是我们写的sql 的表名。

# # 相关概念

逻辑表：就是我们在操作过程中写的 sql 中表名，所谓的逻辑就是假装有。

真实表: 就是数据库中真实存在的，这里的真实是和逻辑相映射的。

数据节点：如下，带逻辑表名，以及后边根据算法而来的真实表名。

绑定表：这个一般用于和子表关联，这样不用产生笛卡尔积。比如 a 和 b表，a分表后是 a1 和 a2 ，b分后是 b1 和 b2 ，如果是笛卡尔积，那就是四种情况，发四条sql 语句。如果是绑定表，则只需要两条。

广播表：就是在每个库上都建一个表，一个操作，同时操作多份。

分片键：就是根据这个字段进行算法分表的。

分片算法：

分片策略：=分片键+分片算法尾数取模，哈希，时间，等等

自增主键生成策略：解决分布式主键冲突问题，用全局自增主键。

# # 执行过程

先进行sql 语法解析，解析后，进行路由，然后sql 重新组装，执行sql，然后结果归并。

# # 查询结果归并

流式归并，内存归并，装饰者归并

# # sharding 需要特别注意的问题

如果我们设置了分片键，在做查询的时候，查询就要加上分片键。否则就是扫描全部的表，也就是说打比方分了三个库，每个库三个表。如果你业务上的sql 没有带上分片键，也就是说sharding 无法根据你sql解析来路由到哪里，也就是说知道到九个表中做全部的查询，也就是说不做分库分表，是一条语句，分库分表后，如果不带分片键就是 9条sql。这就造成了不必要的资源浪费。

从这个角度上来讲，其实 sharding 并不是说的那么好。并不是业务对sql是无感，很准确的说，我们的sql，要强行加分片键，否则结果就是造成不必要的性能损耗，甚至说不如不做分库分表来的好。

# # 公共表（一般用来关联查询的时候字典表）

# # sharding 读写分离

先配置数据库能够读写分离，这一块sharding 不能帮，需要我们自己操作。

配置成以后，路由问题，可以交给 sharding 来管理，

任何一个数据源都要告诉 sharding，先把从库的数据源告诉sharding ，就是通过配置的形式。

明显最上边能做的的仅仅是知道了数据源，sharding也不能通过名字就知道谁是主库，谁是从库。

于是有下边的红框的内容告诉 sharding ，谁是主库，谁是从库。

这也还不够，还需要在数据节点上，添加这个读写分离的操作。

分库分表中间件 sharding相关推荐

【分布式mysql分库分表中间件sharding】
分布式mysql分库分表中间件,sharding领域的一站式解决方案.具备丰富.灵活的路由算法支持,能够方便DBA实现库的水平扩容和降低数据迁移成本.shark采用应用集成架构,放弃通用性,只为换取更 ...
一文快速入门分库分表中间件 Sharding-JDBC （必修课）
书接上文 <一文快速入门分库分表(必修课)>,这篇拖了好长的时间,本来计划在一周前就该写完的,结果家庭内部突然人事调整,领导层进行权利交接,随之宣布我正式当爹,紧接着家庭地位滑落至第三名, ...
一文快速入门分库分表中间件 Sharding-JDBC
一.Sharding-JDBC 简介 Sharding-JDBC 最早是当当网内部使用的一款分库分表框架,到2017年的时候才开始对外开源,这几年在大量社区贡献者的不断迭代下,功能也逐渐完善,现已更名 ...
【Sharding-JDBC系列二】一文快速入门分库分表中间件 Sharding-JDBC （必修课）
作为Sharding-JDBC 分库分表实战系列的开篇文章,我们在前文中回顾了一下分库分表的基础知识,对分库分表的拆分方式有了一定的了解,下边我们介绍一下 Sharding-JDBC框架和快速的搭建一 ...
【数据库与事务系列】分库分表中间件
前面讲了利用mybatis插件进行多数据源切换和分表的方案,但是对业务侵入性较强,当然给予mybatis-plus的对业务侵入性还好,但是支持的策略有限.场景有限. 所以业界诞生了很多分库分表中间件来 ...
关系型数据库分库分表中间件之选型
写在前面本文主要介绍关系型数据库分库分表的中间件,主要包含中间件介绍.选项及其对比.虽然市面上很多分库分表中间件,但是大多数都是不友好或者社区活跃度不高的项目,当然还是有很多淘汰的中间件.目前,在实 ...
数据库分库分表中间件对比（很全）
数据库(分库分表)中间件对比分区:对业务透明,分区只不过把存放数据的文件分成了许多小块,例如mysql中的一张表对应三个文件.MYD,MYI,frm. 根据一定的规则把数据文件(MYD)和索引文件( ...
支付宝分库分表中间件--zdal简介
中间件, 如果仅仅作为一名用户的话, 主要关注一下如何使用即可, 大多数情况下也就是配置. 下面简单的介绍一下支付宝的分库分表中间件--->zdal在web项目中的配置. 1, 在网上查阅相关资 ...
oracle 分表设计,oracle 分库分表（sharding）
数据库Sharding的基本思想和切分策关于垂直切分Vertical Sharding的粒度数据库分库分表(sharding)系列(一) 拆分实施策略和示例演示数据库分库分表(sharding) ...
分库分表中间件Sharding-JDBC
数据库分库分表从互联网时代开启至今,一直是热门话题.在NoSQL横行的今天,关系型数据库凭借其稳定.查询灵活.兼容等特性,仍被大多数公司作为首选数据库.因此,合理采用分库分表技术应对海量数据和高并发对 ...

分库分表中间件 sharding

分库分表中间件 sharding相关推荐

最新文章

热门文章