ShardingSphere-Proxy介绍

ShardingSphere-Proxy，可以让用户像使用原生数据库一样使用 Apache ShardingSphere。

了解一项技术的开始，一般从官网开始。先来看一看官网对 ShardingSphere-Proxy 的定义是什么样的：

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

先明确一个概念，ShardingSphere-Proxy 是一个服务进程。从客户端程序连接来说，它和 MySQL 数据库并没有什么区别。

处理层。

非JAVA的人使用这个就很舒服，

在做了分库分表或其他规则的情况下，数据会分散到多个数据库实例上，在管理上难免会有一些不便；或者使用非 Java 语言的开发者，需要 ShardingSphere 所提供的能力…… 以上这些情况，正是 ShardingSphere-Proxy 力所能及之处。

我们举例工作中真实存在的几个场景：

1. 测试同学想看下用户 ID 123456 的信息在数据库表里情况，需要你提供下用户在哪一张分表；

1. 公司领导需要技术提供一份 2022 年用户的增长总量以及用户信息；

1. 公司举行 8 周年活动，需要技术提供一份注册日期超过 8 周年的活跃老用户名单。

因为数据分库分表后，数据是散落在不同的库表中，对于上述的场景实现并不容易；如果为了实现类似临时需求，每次都需要开发代码，显得有些笨重。这个时候就需要文章主角 ShardingSphere-Proxy 登场了。

ShardingSphere-Proxy 隐藏了后端实际数据库，对于客户端来说就是在使用一个数据库，不需要关心 ShardingSphere 如何协调背后的数据库，对于使用非 Java 语言的开发者或 DBA 更友好。

2. JDBC 和 Proxy 的区别

看了上面的描述，怎么感觉 ShardingSphere-Proxy 和 ShardingSphere-JDBC 这么像，两者有什么区别？

ShardingSphere-JDBC	ShardingSphere-Proxy
数据库	任意	基于 MySQL / PostgreSQL 协议的数据库
连接消耗数	高	低
异构语言	支持 Java 等基于 JVM 语言	任意
性能	损耗低	损耗略高
无中心化	是	否
静态入口	无	有

1，水平分割：

例：QQ的登录表。假设QQ的用户有100亿，如果只有一张表，每个用户登录的时候数据库都要从这100亿中查找，会很慢很慢。如果将这一张表分成100份，每张表有1亿条，就小了很多，比如qq0,qq1,qq1...qq99表。

用户登录的时候，可以将用户的id%100，那么会得到0-99的数，查询表的时候，将表名qq跟取模的数连接起来，就构建了表名。比如123456789用户，取模的89，那么就到qq89表查询，查询的时间将会大大缩短。

2、垂直分表

垂直分割指的是：表的记录并不多，但是字段却很长，表占用空间很大，检索表的时候需要执行大量的IO，严重降低了性能。这时需要把大的字段拆分到另一个表，并且该表与原表是一对一的关系。

例如学生答题表tt：有如下字段：

Id name 分数 题目 回答

其中题目和回答是比较大的字段，id name 分数比较小。

如果我们只想查询id为8的学生的分数：select 分数 from tt where id = 8;虽然知识查询分数，但是题目和回答这两个大字段也是要被扫描的，很消耗性能。但是我们只关心分数，并不想查询题目和回答。这就可以使用垂直分割。我们可以把题目单独放到一张表中，通过id与tt表建立一对一的关系，同样将回答单独放到一张表中。这样我们插叙tt中的分数的时候就不会扫描题目和回答了。