公司推广发帖网站怎么做,外贸网站建设公司市场,wordpress不能显示分类页,合肥大型互联网公司一 文档简介
1.1 分库分表诞生的前景
随着系统用户运行时间还有用户数量越来越多#xff0c;整个数据库某些表的体积急剧上升#xff0c;导致CRUD的时候性能严重下降#xff0c;还容易造成系统假死。
这时候系统都会做一些基本的优化#xff0c;比如加索引…
一 文档简介
1.1 分库分表诞生的前景
随着系统用户运行时间还有用户数量越来越多整个数据库某些表的体积急剧上升导致CRUD的时候性能严重下降还容易造成系统假死。
这时候系统都会做一些基本的优化比如加索引、缓存、读写分离/主从复制增删改都走主库查询走从库。数据量过大基本优化方式参考百度安全验证
但是这样没法提升主库写的能力因为主库只有一个。这时候就要考虑分库分表了一般数据库在设计的时候就会提前考虑到是否有分库分表场景需要避免后期带来迁移的问题而且最好对表的查询足够简单尽量避免跨表跨库查询。
1.2 单表数据量的分析
业界流传着单表数量建议最大2kw条但是实际情况还可以进行具体分析https://linpxing.cn/mysql_big_table_limit_990912/https://linpxing.cn/mysql_big_table_limit_990912/
在阿里巴巴开发手册中建议预估三年内单表行数超过500万行或者单表容量超过2GB才推荐进行分库分表。
二 分表详述
2.1 分库分表的方式垂直拆分水平复制
一般系统模块都是访问同一个数据库资源所有的表都存放在一个库里面 2.1.1 垂直分库
把单一的数据库进行业务划分专库专表 经过垂直拆分之后每个模块都使用各自独立的数据库减轻了数据库的压力业务也更加清晰拓展也更容易了但是会增加连表查询以及事务处理的复杂度无法解决单表数据量太大的问题 2.1.2 垂直分表
垂直拆分表主要解决一张表太多字段某个字段存储值为大文本会对io查询有损耗所以把本来属于同一个对象描述的属性拆分多个表分布式微服务分库分表尽量不要严苛遵守数据库的3大范式可参考不可严格遵循
相当于把一个大表根据字段拆分成多个小表 一个10w数据的表变成两个10w数据的表
这样拆分的好处就是假如只显示列表不需要显示详细信息就很方便例如一个订单是包含很多信息的但是在后台通常不需要去获取订单的详情信息用作展示一般只需要展示概要信息下单用户、下单时间、金额等等重要信息。于是可以把一个订单表垂直拆分为两个表来处理
2.1.3 水平分库
把一个数据库分散成多个结构相同的数据库本质就是复制操作 2.1.4 水平分表
一个表数据量太大将一个表按不同的条件分散多个表中把1000w的表拆分为两个500w的表
2.2 分表的规则 2.2.1 取范围
根据时间范围或者id范围分布到不同的库中例如把2020年前的数据放到一个表中之后的数据放到一个表中。把用户ID 0100000放到一个表中100000200000的数据放到一个表中。
优点使用分片字段范围查询比较方便
缺点某段范围内热点数据可能被频繁读写其他数据很少被查询
时间维度使用ShardingJDBC实现按时间维度分表轻松支撑千万级数据_sharding jdbc按时间分表-CSDN博客参考链接
2.2.2 数值hash取模运算
根据某个字段进行运算均匀的分配到不同的表中
优点分散比较均匀不容易存在热点数据
缺点数据太分散导致范围查询比较麻烦需要查询分库之后再合并
水平拆分的时候会导致多库多表的联合查询难度变大以及多数据源管理的问题
2.3 分表的中间件
2.3.1 Cobar
阿里 b2b 团队开发和开源的属于 proxy 层方案就是介于应用服务器和数据库服务器之间。应用程序通过 JDBC 驱动访问 Cobar 集群Cobar 根据 SQL 和分库规则对 SQL 做分解然后分发到 MySQL 集群不同的数据库实例上执行。早些年还可以用但是最近几年都没更新了基本没啥人用差不多算是被抛弃的状态吧。而且不支持读写分离、存储过程、跨库 join 和分页等操作。由于Cobar发起人的离职Cobar停止维护
2.3.2 TDDL
淘宝团队开发的属于 client 层方案。支持基本的 crud 语法和读写分离但不支持 join、多表查询等语法。目前使用的也不多因为还依赖淘宝的 diamond 配置管理系统。
2.3.3 Atlas
是360团队基于mysql proxy改写功能还需完善高并发下不稳定
2.3.4 Sharding Sphere
Sharding-JDBC是从当当网的内部架构 ddframe 里面的一个分库分表的模块脱胎出来的用来解决当当的分库分表的问题把跟业务相关的敏感的代码剥离后就得到了 Sharding-JDBC。
2018 年 5 月因为增加了 Proxy 的版本和 Sharding-Sidecar尚未发布Sharding-JDBC 更名为 Sharding Sphere从一个客户端的组件变成了一个套件
2018 年 11 月Sharding-Sphere 正式进入 Apache 基金会孵化器这也是对Sharding-Sphere 的质量和影响力的认可。
2.3.5 Mycat
基于 Cobar 改造的解决了cobar存在的问题并且加入了许多新的功能在其中。青出于蓝而胜于蓝属于 proxy 层方案支持的功能非常完善而且目前应该是非常火的而且不断流行的数据库中间件社区很活跃也有一些公司开始在用了。但是确实相比于 Sharding jdbc 来说年轻一些经历的锤炼少一些。
三 Sharding Sphere
3.1 基本特性
定位为轻量级Java框架在Java的JDBC层提供的额外服务。 它使用客户端直连数据库以jar包形式提供服务无需额外部署和依赖可理解为增强版的JDBC驱动完全兼容JDBC和各种ORM框架。
在 maven 的工程里面我们使用它的方式是引入依赖然后进行配置就可以了原来是 SSMSpringSpringMVCMyBatis 连接数据库还是 SSM因为它是支持 MyBatis 的。
3.2 核心概念
3.2.1 逻辑表
水平拆分的数据库表的相同逻辑和数据结构表的总称。例订单数据根据主键尾数拆分为10张表分别是t_order_0到t_order_9他们的逻辑表名为t_order。
3.2.2 真实表
在分片的数据库中真实存在的物理表。即上个示例中的t_order_0到t_order_9。
3.2.3 数据结点
数据分片的最小单元。由数据源名称和数据表组成例ds_0.t_order_0。
3.2.4 绑定表
指分片规则一致的主表和子表。例如t_order表和t_order_item表均按照order_id分片则此两张表互为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联关联查询效率将大大提升。
其中t_order在FROM的最左侧ShardingSphere将会以它作为整个绑定表的主表。所有路由计算将会只使用主表的策略那么t_order_item表的分片计算将会使用t_order的条件。故绑定表之间的分区键要完全相同。
3.2.5 广播表
指所有的分片数据源中都存在的表表结构和表中的数据在每个数据库中均完全一致。适用于数据量不大且需要与海量数据的表进行关联查询的场景例如字典表。
3.2.6 分片键
用于分片的数据库字段是将数据库(表)水平拆分的关键字段。例将订单表中的订单主键的尾数取模分片则订单主键为分片字段。 SQL中如果无分片字段将执行全路由性能较差。 除了对单分片字段的支持ShardingSphere也支持根据多个字段进行分片。
3.2.7 分片算法
通过分片算法将数据分片支持通过、、、、、BETWEEN和IN分片。分片算法需要应用方开发者自行实现可实现的灵活度非常高。 目前提供4种分片算法。由于分片算法和业务实现紧密相关因此并未提供内置分片算法而是通过分片策略将各种场景提炼出来提供更高层级的抽象并提供接口让应用开发者自行实现分片算法
精确分片算法
对应PreciseShardingAlgorithm用于处理使用单一键作为分片键的与IN进行分片的场景。需要配合StandardShardingStrategy使用。 范围分片算法
对应RangeShardingAlgorithm用于处理使用单一键作为分片键的BETWEEN AND、、、、进行分片的场景。需要配合StandardShardingStrategy使用。 复合分片算法
对应ComplexKeysShardingAlgorithm用于处理使用多键作为分片键进行分片的场景包含多个分片键的逻辑较复杂需要应用开发者自行处理其中的复杂度。需要配合ComplexShardingStrategy使用。 Hint分片算法
对应HintShardingAlgorithm用于处理使用Hint行分片的场景。需要配合HintShardingStrategy使用。
3.2.8 分片策略
包含分片键和分片算法由于分片算法的独立性将其独立抽离。真正可用于分片操作的是分片键 分片算法也就是分片策略。目前提供5种分片策略。 标准分片策略
对应StandardShardingStrategy。提供对SQL语句中的, , , , , IN和BETWEEN AND的分片操作支持。StandardShardingStrategy只支持单分片键提供PreciseShardingAlgorithm和RangeShardingAlgorithm两个分片算法。PreciseShardingAlgorithm是必选的用于处理和IN的分片。RangeShardingAlgorithm是可选的用于处理BETWEEN AND, , , , 分片如果不配置RangeShardingAlgorithmSQL中的BETWEEN AND将按照全库路由处理。 复合分片策略
对应ComplexShardingStrategy。复合分片策略。提供对SQL语句中的, , , , , IN和BETWEEN AND的分片操作支持。ComplexShardingStrategy支持多分片键由于多分片键之间的关系复杂因此并未进行过多的封装而是直接将分片键值组合以及分片操作符透传至分片算法完全由应用开发者实现提供最大的灵活度。 行表达式分片策略
对应InlineShardingStrategy。使用Groovy的表达式提供对SQL语句中的和IN的分片操作支持只支持单分片键。对于简单的分片算法可以通过简单的配置使用从而避免繁琐的Java代码开发如: t_user_$-{u_id % 8} 表示t_user表根据u_id模8而分成8张表表名称为t_user_0到t_user_7。 Hint分片策略
对应HintShardingStrategy。通过Hint指定分片值而非从SQL中提取分片值的方式进行分片的策略。 不分片策略
对应NoneShardingStrategy。不分片的策略。
相关链接
Sharding-JDBC介绍 - 简书
ShardingSphere介绍与使用-CSDN博客
按时间分表:https://www.cnblogs.com/wang1221/p/16325709.html
分库分表-分片算法运用_分库和分表分片-CSDN博客策略
