对比 Vitess，ShardingSphere 有哪些不同？

ShardingSphere 是什么？

ShardingSphere 是一套开源的分布式数据库中间件解决方案组成的生态圈，它由 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar（规划中）这 3 款相互独立的产品组成。他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如 Java 同构、异构语言、容器、云原生等各种多样化的应用场景。ShardingShpere 在刚刚过去的双十一之前通过了 Apache 基金会的投票，正式进入孵化器，成为 Apache 的首个分布式数据库中间件。

ShardingSphere 可以采用混合使用 Sharding-JDBC 和 Sharding-Proxy 的部署方式满足在线 + 管理的能力，也可以独立使用 Sharding-JDBC 或 Sharding-Proxy。ShardingSphere 希望可以通过多元化的接入端架构去满足不同需求。

 

 

Vitess 是什么？

Vitess源起于 Youtube，现已属于 PlanetScale 的开源产品。它致力于部署、扩展和管理大型 MySQL 实例集群的数据库解决方案。它结合了许多重要的 MySQL 功能和 NoSQL 数据库的可扩展性，提供数据分片、分布式事务以及管理大量 MySQL 实例等功能。

 

 

Vitess 由负责元数据存储的 Topology、负责应用接入和 SQL 路由的 vtgate、负责重写和执行 SQL 的 vttablet 以及两类管理工具 vtctl(用于命令行) 和 vtctld(用于图形界面) 等服务组件共同构成。用户可以通过支持 MySQL 协议的客户端，或使用 Vitess 的客户端 API 使用 Vitess。

应用功能对比

面对这两个同样优秀的产品，用户该在何种场景下选用哪款产品，想必有所纠结。本文接下来将使用 Vitess v2.2 和 ShardingSphere 3.0.0，从应用功能和管理功能的角度，以官方文档为基础，进行测试对比，尽可能展示出两者在已有功能和实现思路侧重点上的不同。

接入方式

Vitess 通过组件 vtgate 作为中心化的接入代理，用户可以通过 Vitess 的 gRPC 连接器或各类 MySQL 原生驱动进行连接。Vitess 的 gRPC 连接器目前仅支持 Java 和 Go 两种语言，若使用原生驱动则没有语言限制，目前 Vitess 支持 MySQL 和 MariaDB 两种数据库。

ShardingSphere 提供 Proxy 和 JDBC 两种接入方式，其中 Sharding-Proxy 和 vtgate 类似，提供了中心化的接入代理，用户可以通过 MySQL 原生驱动进行连接，理论上支持所有开发语言，目前同样支持 MySQL 和 MariaDB 数据库；Sharding-JDBC 可理解为增强版的 JDBC 驱动，提供无中心化的轻量级运行方式，让客户端直连数据库，无网络二次转发的消耗。由于是 JDBC 的增强，因此没有数据库类型的限制，可以支持 MySQL、Oracle、SQLServer 和 PostgreSQL 等。

通过表格，可以更直观的比较双方的接入方式区别：

 

 

分片模式

Vitess 在分片上采用了每个数据库实例均创建一个分库，并且不进行分表的方式，即多实例单库单表。由于 Vitess 的分片模式相对固定，因此在配置分片时通过 JSON 指定分片表、分片字段和分片算法，分片之后的库名由 Vitess 自动管理，表名不变。

ShardingSphere 支持单独分库、单独分表和同时分库分表的分片方式，并且提供四种不同的分片策略以及能够让用户自行实现分片算法，使得用户能够更加自由地控制数据分片。

单纯描述有些抽象，接下来分别创建一个分片的例子进行测试.

首先模仿 Vitess 官方文档的测试用例，创建了一个名为 test_keyspace 的键空间（keyspaces），为其设置了 2 个分片。同时指定了 t_order 和 t_order_item 两张分表，分别使用 user_id 和 order_id 进行 Hash 分片。

在建表完毕后，通过 DataGrip 客户端分别连接 vtgate 和实际 MySQL 实例进行查看。

vtgate 执行 show databases 和 show tables。