ShardingSphere：基本概念

简介

ShardingSphere官网：http://shardingsphere.apache.org/index_zh.html

Apache ShardingSphere 是一套开源的分布式数据库解决方案组成的生态圈，它由 JDBC、Proxy 和 Sidecar（规划中）这 3 款既能够独立部署，又支持混合部署配合使用的产品组成。 它们均提供标准化的数据水平扩展、分布式事务和分布式治理等功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。

Apache ShardingSphere 旨在充分合理地在分布式的场景下利用关系型数据库的计算和存储能力，而并非实现一个全新的关系型数据库。 关系型数据库当今依然占有巨大市场份额，是企业核心系统的基石，未来也难于撼动，我们更加注重在原有基础上提供增量，而非颠覆。

image-20210330132905893

ShardingSphere-JDBC

定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。它使用客户端直连数据库，以 jar 包形式 提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。

  • 适用于任何基于 JDBC 的 ORM 框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或直接 使用 JDBC。

  • 支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP 等。

  • 支持任意实现 JDBC 规范的数据库，目前支持 MySQL，Oracle，SQLServer，PostgreSQL 以及任何 遵循 SQL92 标准的数据库。

image-20210330132838529

ShardingSphere-Proxy

定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支 持。目前提供 MySQL 和 PostgreSQL 版本，它可以使用任何兼容 MySQL/PostgreSQL 协议的访问客户端 (如：MySQL Command Client, MySQL Workbench, Navicat 等) 操作数据，对 DBA 更加友好。

  • 向应用程序完全透明，可直接当做 MySQL/PostgreSQL 使用。

  • 适用于任何兼容 MySQL/PostgreSQL 协议的的客户端。

image-20210330132947176

ShardingSphere-Sidecar（TODO）

定位为 Kubernetes 的云原生数据库代理，以 Sidecar 的形式代理所有对数据库的访问。通过无中心、零 侵入的方案提供与数据库交互的啮合层，即 Database Mesh，又可称数据库网格。

Database Mesh 的关注重点在于如何将分布式的数据访问应用与数据库有机串联起来，它更加关注的是 交互，是将杂乱无章的应用与数据库之间的交互进行有效地梳理。使用 Database Mesh，访问数据库的 应用和数据库终将形成一个巨大的网格体系，应用和数据库只需在网格体系中对号入座即可，它们都是 被啮合层所治理的对象。

image-20210330133114357

混合架构

ShardingSphere‐JDBC 采用无中心化架构，适用于 Java 开发的高性能的轻量级 OLTP 应用； ShardingSphere‐Proxy 提供静态入口以及异构语言的支持，适用于 OLAP 应用以及对分片数据库 进行管理和运维的场景。

Apache ShardingSphere 是多接入端共同组成的生态圈。通过混合使用 ShardingSphere‐JDBC 和 ShardingSphere‐Proxy，并采用同一注册中心统一配置分片策略，能够灵活的搭建适用于各种场景的应 用系统，使得架构师更加自由地调整适合与当前业务的最佳系统架构。

image-20210330133324829

分库分表

分库分表有两种方式：垂直分片和水平分片。

垂直切分

按照业务拆分的方式称为垂直分片，又称为纵向拆分，它的核心理念是专库专用。在拆分之前，一个数据库由多个数据表构成，每个表对应着不同的业务。而拆分之后，则是按照业务将表进行归类，分布到不同的数据库中，从而将压力分散至不同的数据库。下图展示了根据业务需要，将用户表和订单表垂直分片到不同的数据库的方案。

image-20210330135150398

垂直分片往往需要对架构和设计进行调整。通常来讲，是来不及应对互联网业务需求快速变化的；而且， 它也并无法真正的解决单点瓶颈。垂直拆分可以缓解数据量和访问量带来的问题，但无法根治。如果垂直拆分之后，表中的数据量依然超过单节点所能承载的阈值，则需要水平分片来进一步处理。

水平切分

水平分片又称为横向拆分。相对于垂直分片，它不再将数据根据业务逻辑分类，而是通过某个字段（或 某几个字段），根据某种规则将数据分散至多个库或表中，每个分片仅包含数据的一部分。例如：根据主键分片，偶数主键的记录放入0 库（或表），奇数主键的记录放入1库（或表），如下图所示。 水平分片从理论上突破了单机数据量处理的瓶颈，并且扩展相对自由，是分库分表的标准解决方案。

image-20210330135341524

尽量透明化分库分表所带来的影响，让使用方尽量像使用一个数据库一样使用水平分片之后的数据库集 群，是 Apache ShardingSphere 数据分片模块的主要设计目标。

分库分表应用和问题

应用

1.在数据库设计时候考虑垂直分库和垂直分表

2.随着数据库数据量增加，不要马上考虑水平切分，首先考虑缓存处理、读写分离、使用索引等等。如果这些方式不能从根本上解决问题，再考虑做水平分库。

问题

1.跨节点连接查询问题（分页、排序）

2.多数据源管理问题

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/wwjj4811/p/14596653.html