网站域名和空间,seo技术大师,网络存储上做网站,张家界公司网站建设目录 一、ShardingSphere分库分表产品介绍
二、客户端分库分表与服务端分库分表
1、ShardingJDBC客户端分库分表
2、ShardingProxy服务端分库分表
3、ShardingSphere混合部署架构
三、分库分表#xff0c;能不分就不分#xff01;
1、为什么要分库分表#xff1f;
2、…目录 一、ShardingSphere分库分表产品介绍
二、客户端分库分表与服务端分库分表
1、ShardingJDBC客户端分库分表
2、ShardingProxy服务端分库分表
3、ShardingSphere混合部署架构
三、分库分表能不分就不分
1、为什么要分库分表
2、分库分表的优势
3、分库分表的挑战 一、ShardingSphere分库分表产品介绍 shardingsphere官网地址Apache ShardingSphere ShardingSphere是一款起源于当当网内部的应用框架。2015年在当当网内部诞生最初就叫ShardingJDBC。2016年的时候由其中一个主要的开发人员张亮带入到京东数科组件团队继续开发。在国内历经了当当网、电信翼支付、京东数科等多家大型互联网企业的考验在2017年开始开源。并逐渐由原本只关注于关系型数据库增强工具的ShardingJDBC升级成为一整套以数据分片为基础的数据生态圈更名为ShardingSphere。到2020年4月已经成为了Apache软件基金会的顶级项目。发展至今已经成为了业界分库分表最成熟的产品。
ShardingSphere这个词可以分为两个部分其中Sharding就是我们之前介绍过的数据分片。从官网介绍上就能看到他的核心功能就是可以将任意数据库组合转换成为一个分布式的数据库提供整体的数据库集群服务。只是给自己的定位并不是Database而是Database plus。其实这个意思是他自己并不做数据存储而是对其他数据库产品进行整合。整个ShardingSphere其实就是围绕数据分片这个核心功能发展起来的。
后面的Sphere是生态的意思。这意味着ShardingSphere不是一个单独的框架或者产品而是一个由多个框架以及产品构成的一个完整的技术生态。目前ShardingSphere中比较成型的产品主要包含核心的ShardingJDBC以及ShardingProxy两个产品以及一个用于数据迁移的子项目ElasticJob。另外现在也提供了基于公有云的云上服务ShardingSphere-on-Cloud。
ShardingSphere经过这么多年的发展已经不仅仅只是用来做分库分表而是形成了一个围绕分库分表核心的技术生态。他的核心功能已经包括了数据分片、分布式事务、读写分离、高可用、数据迁移、联邦查询、数据加密、影子库、DistSQL庞大的技术体系。
目前ShardingSphere已经演进到了5.x大版本。在这个大版本中ShardingSphere的核心是可插拔。其核心设计哲学就是连接、增强以及可拔插。这是官网对于其整个设计哲学的核心描述。 二、客户端分库分表与服务端分库分表
ShardingSphere最为核心的产品有两个一个是ShardingJDBC这是一个进行客户端分库分表的框架。另一个是ShardingProxy这是一个进行服务端分库分表的产品。他们代表了两种不同的分库分表的实现思路。 1、ShardingJDBC客户端分库分表
ShardingSphere-JDBC 定位为轻量级 Java 框架在 Java 的 JDBC 层提供的额外服务。 它使用客户端直连数据库以 jar 包形式提供服务无需额外部署和依赖可理解为增强版的 JDBC 驱动完全兼容 JDBC 和各种 ORM 框架。
适用于任何基于 JDBC 的 ORM 框架如JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC支持任何第三方的数据库连接池如DBCP, C3P0, BoneCP, HikariCP 等支持任意实现 JDBC 规范的数据库目前支持 MySQLPostgreSQLOracleSQLServer 以及任何可使用 JDBC 访问的数据库。 这是ShardingSphere最初的产品形态。 2、ShardingProxy服务端分库分表
ShardingSphere-Proxy 定位为透明化的数据库代理端通过实现数据库二进制协议对异构语言提供支持。 目前提供 MySQL 和 PostgreSQL 协议透明化数据库操作对 DBA 更加友好。
向应用程序完全透明可直接当做 MySQL/PostgreSQL 使用兼容 MariaDB 等基于 MySQL 协议的数据库以及 openGauss 等基于 PostgreSQL 协议的数据库适用于任何兼容 MySQL/PostgreSQL 协议的客户端如MySQL Command Client, MySQL Workbench, Navicat 等。 3、ShardingSphere混合部署架构
这两个产品都各有优势。ShardingJDBC跟客户端在一起使用更加灵活。而ShardingProxy是一个独立部署的服务所以他的功能相对就比较固定。他们的整体区别如下 ShardingSphere-JDBC ShardingSphere-Proxy 数据库 任意 MySQL/PostgreSQL 连接消耗数 高 低 异构语言 仅 Java 任意 性能 损耗低 损耗略高 无中心化 是 否 静态入口 无 有
另外在产品图中Governance Center也是其中重要的部分。他的作用有点类似于微服务架构中的配置中心可以使用第三方服务统一管理分库分表的配置信息当前建议使用的第三方服务是Zookeeper同时也支持NacosEtcd等其他第三方产品。
由于ShardingJDBC和ShardingProxy都支持通过Governance Center将配置信息交个第三方服务管理因此也就自然支持了通过Governance Center进行整合的混合部署架构。 三、分库分表能不分就不分
1、为什么要分库分表
数据库应该是一个应用当中最为核心的价值所在也是开发过程中必须熟练掌握的工具。之前我们就学习过很多对MySQL的调优。但是随着现在互联网应用越来越大数据库会频繁的成为整个应用的性能瓶颈。我们经常使用的MySQL数据库也就不断面临数据量太大、数据访问太频繁、数据读写速度太快等一系列的问题。而传统的这些调优方式在真正面对海量数据冲击时往往就会显得很无力。因此现在互联网对于数据库的使用也越来越小心谨慎。例如添加Redis缓存、增加MQ进行流量削峰等。但是数据库本身如果性能得不到提升这就相当于是水桶理论中的最短板。
要提升数据库的性能最直接的思路当然是对数据库本身进行优化。例如对MySQL进行调优优化SQL逻辑优化索引结构甚至像阿里等互联网大厂一样直接优化MySQL的源码。但是这种思路在面对互联网环境时会有很多非常明显的弊端。
数据量和业务量快速增长会带来性能瓶颈、服务宕机等很多问题。单点部署的数据库无法保证服务高可用。单点部署的数据库无法进行水平扩展难以应对业务爆发式的增长。
这些问题背后的核心还是数据。数据库不同于上层的一些服务他所管理的数据甚至比服务本身更重要。即要保证数据能够持续稳定的写入又不能因为服务故障造成数据丢失。现在互联网上的大型应用动辄几千万上亿的数据量就算做好数据的压缩随随便便也可以超过任何服务器的存储能力。并且服务器单点部署也无法真正解决把鸡蛋放在一个篮子里的问题。将数据放在同一个服务器上如果服务器出现崩溃就很难保证数据的安全性。这些都不是光靠优化MySQL产品优化服务器配置能够解决的问题。 2、分库分表的优势
那么自然就需要换另外一种思路了。我们可以像微服务架构一样来维护数据库的服务。把数据库从单体服务升级到数据库集群这样才能真正全方位解放数据库的性能瓶颈并且能够通过水平扩展的方式灵活提升数据库的存储能力。这也就是我们常说的分库分表。通过分库分表可以给数据库带来很大的好处
提高系统性能分库分表可以将大型数据库分成多个小型数据库每个小型数据库只需要处理部分数据因此可以提高数据库的并发处理能力和查询性能。提高系统可用性分库分表可以将数据复制到多个数据库中以提高数据的可用性和可靠性。如果一个数据库崩溃了其他数据库可以接管其工作以保持系统的正常运行。提高系统可扩展性分库分表可以使系统更容易扩展。当数据量增加时只需要增加更多的数据库和表而不是替换整个数据库因此系统的可扩展性更高。提高系统灵活性分库分表可以根据数据的使用情况对不同的数据库和表进行不同的优化。例如可以将经常使用的数据存储在性能更好的数据库中或者将特定类型的数据存储在特定的表中以提高系统的灵活性。降低系统成本分库分表可以使系统更加高效因此可以降低系统的运营成本。此外分库分表可以使用更便宜的硬件和存储设备因为每个小型数据库和表需要的资源更少。 3、分库分表的挑战
可能你会说分库分表嘛 也不是很难。一个库存不下那就把数据拆分到多个库。一张表数据太多了就把同一张表的数据拆分到多张。至于怎么做也不难啊。要操作多个数据库那么建立多个JDBC连接就行了。要写到多张表修改下SQL语句就行了。
如果你也这么觉得那么就大错特错了。分库分表也并不是字面意义上的将数据分到多个库或者多个表这么简单他需要的是一系列的分布式解决方案。
因为数据的特殊性造成数据库服务其实是几乎没有试错的成本的。在微服务阶段从单机架构升级到微服务架构是很灵活的中间很多细节步骤都可以随时做调整。比如对于微服务的接口限流功能你并不需要一上来就用Sentinel这样复杂的流控工具。一开始不考虑性能自己进行限流是很容易的事情。然后你可以慢慢尝试用Guava等框架提供的一些简单的流控工具进行零散的接口限流。直到整个应用的负载真正上来了之后流控的要求更高更复杂了再开始引入Sentinel进行统一流控这都没有问题。这种试错的过程其实是你能够真正用好一项技术的基础。
但是对于数据库就不一样了。当应用中用来存储数据的数据库从一个单机的数据库服务升级到多个数据库组成的集群服务时需要考虑的除了分布式的各种让人摸不着边际的复杂问题外还要考虑到一个更重要的因素数据。数据的安全性甚至比数据库服务本身更重要因此如果你在一开始做分库分表时的方案不太成熟对数据的规划不是很合理那么这些问题大概率会随着数据永远沉淀下去成为日后对分库分表方案进行调整时最大的拦路虎。
所以在决定进行分库分表之前一定需要提前对于所需要面对的各种问题进行考量。如果你没有考虑清楚数据要如何存储、计算、使用或者你对于分库分表的各种问题都还没有进行过思考那么千万不要在真实项目中贸然的进行分库分表。 分库分表也称为Sharding。Sharding表示将数据拆分到不同的数据片中。由于数据往往是一个应用的基础随着数据从单体服务拆分到多个数据分片应用层面也需要面临很多新的问题。比如
主键避重问题
在分库分表环境中由于表中数据同时存在不同数据库中某个分区数据库生成的ID就无法保证全局唯一。因此需要单独设计全局主键以避免跨库主键重复问题。
数据备份问题
随着数据库由单机变为集群整体服务的稳定性也会随之降低。如何保证集群在各个服务不稳定的情况下依然保持整体服务稳定就是数据库集群需要面对的重要问题。而对于数据库还需要对数据安全性做更多的考量。
数据迁移问题
当数据库集群需要进行扩缩容时集群中的数据也需要随着服务进行迁移。如何在不影响业务稳定性的情况下进行数据迁移也是数据库集群化后需要考虑的问题。
分布式事务问题
原本单机数据库有很好的事务机制能够帮我们保证数据一致性。但是分库分表后由于数据分布在不同库甚至不同服务器不可避免会带来分布式事务问题。
SQL路由问题
数据被拆分到多个分散的数据库服务当中每个数据库服务只能保存一部分的数据。这时在执行SQL语句检索数据时如何快速定位到目标数据所在的数据库服务并将SQL语句转到对应的数据库服务中执行也是提升检索效率必须要考虑的问题。
跨节点查询归并问题
跨节点进行查询时每个分散的数据库中只能查出一部分的数据这时要对整体结果进行归并时就会变得非常复杂。比如常见的limit、order by等操作。
在实际项目中遇到的问题还会更多。从这里可以看出Sharding其实是一个很复杂的问题往往很难通过项目定制的方式整体解决。因此大部分情况下都是通过第三方的服务来解决Sharding的问题。比如像TiDB、ClickHouse、Hadoop这一类的NewSQL产品大部分情况下是将数据问题整体封装到一起从而提供Sharding方案。但是这些产品毕竟太重了。更灵活的方式还是使用传统数据库通过软件层面来解决多个数据库之间的数据问题。这也诞生了很多的产品比如早前的MyCat还有后面我们要学习的ShardingSphere等。
另外关于何时要开始考虑分库分表呢当然是数据太大了数据库服务器压力太大了就要进行分库分表。但是这其实是没有一个具体的标准的需要根据项目情况进行灵活设计。业界目前唯一比较值得参考的详细标准是阿里公开的开发手册中提到的建议预估三年内单表数据超过500W或者单表数据大小超过2G就需要考虑分库分表。
