對比 Vitess，ShardingSphere 有哪些不一樣

本篇爲InfoQ中文站供稿

原文連接：

https://www.infoq.cn/article/...*MfpLiTiTTEu5?from=timeline&isappinstalled=0

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。

MySQL 實例中的拓撲結構以下圖。

從 MySQL 實例的拓撲看出，Vitess 在每個分片數據庫實例中，都建立了一個 vt_${keyspace_name}的庫，而且將建表語句廣播到全部數據庫執行。

一樣模仿 ShardingSphere 的官方樣例，在 Sharding-Proxy 中配置 test_keyspace 分庫及 t_order，t_order_item 兩張分表。爲了區別 ShardingSphere 和 Vitess 的分片能力，這裏選用同時分庫分表的方式進行分片，經過 user_id 取餘進行分庫、order_id 取餘進行分表。

在進行配置的時候，能夠利用 InlineShardingStrategy 直接使用 Groovy 表達式簡化配置，如本例中可簡化配置爲：

test_keyspace_${user_id % 2}

t_order_${order_id % 2}

t_order_item_${order_id % 2}

在建表完畢後，經過 DataGrip 客戶端分別鏈接 Sharding-Proxy 和實際 MySQL 實例進行查看。

Sharding-Proxy 執行 show databases 和 show tables：

MySQL 實例中的拓撲結構：

一樣經過表格，直觀的展現二者分片上的區別：

因而可知，ShardingSphere 和 Vitess 在分片模式上有着很大的區別，ShardingSphere 具備更豐富更自由的分片方式，可以應付更多的應用場景。

SQL 支持

因爲 SQL 語法靈活複雜，分佈式數據庫和單機數據庫的查詢場景又不徹底相同，不免有和單機數據庫不兼容的 SQL 出現。針對該問題，Vitess 和 ShardingSphere 都在官方文檔中進行了說明。

在 ShardingSphere 中，對於已支持和未支持的 SQL 種類做出了明確的標註，對於經常使用的分頁、排序、分組、聚合都進行了支持，並支持部分關聯查詢，具體內容能夠經過官方文檔 使用規範 > SQL 中進行查閱。

而 Vitess 暫時沒有明確的文檔標明已支持和未支持的 SQL 種類，只在 FAQ 中的test-case標註了當前已經出現的未支持的 SQL 的狀況。

爲了更直觀地展現二者 SQL 支持狀況，這裏選取了一部分經常使用的 SQL 類型，根據文檔說明並結合實際測試結果，列出參考列表：

SQL 類型	測試 SQL	Vitess	ShardingSphere
全表查詢	SELECT * FROM t_order;	支持	支持
等值查詢	SELECT FROM t_order WHERE user_id = 7; SELECT FROM t_order WHERE user_id = 7 and order_id=9;	支持	支持
範圍查詢	SELECT FROM t_order WHERE user_id in (7, 9); SELECT FROM t_order WHERE user_id BETWEEN 7 AND 10; SELECT FROM t_order WHERE user_id=7 or user_id=11; SELECT FROM t_order WHERE user_id > 1;	支持	支持
累加聚合	SELECT count(*) FROM t_order; SELECT sum(user_id) FROM t_order;	支持	支持
比較聚合	SELECT max(user_id) FROM t_order; SELECT min(user_id) FROM t_order;	支持	支持
平均聚合	SELECT avg(order_id) FROM t_order;	不支持	支持
分組	SELECT user_id, MAX(order_id) FROM t_order GROUP BY user_id; SELECT sum(user_id), order_id FROM t_order GROUP BY order_id; SELECT sum(user_id), test_int FROM t_order GROUP BY test_int; SELECT count(order_id), status FROM t_order GROUP BY status; (status 爲 VARCHAR 類型)	前 3 句支持 第 4 句不支持	支持
排序 / 分頁	SELECT FROM t_order ORDER BY user_id; SELECT FROM t_order ORDER BY user_id LIMIT 10, 10;	不支持	支持
去重	SELECT DISTINCT test_int FROM t_order;	支持	不支持
算式	SELECT * FROM t_order WHERE user_id=7+1;	支持	支持
關聯查詢	SELECT a.user_id, a.order_id, a.status, b.item_id FROM t_order a JOIN t_order_item b ON a.order_id = b.order_id; SELECT a.user_id, a.test_int, a.status, b.item_id, b.user_id FROM t_order a JOIN t_order_item b ON a.test_int = b.user_id;	支持	支持
子查詢	SELECT x.user_id,x.status,x.item_id FROM (SELECT a.user_id, a.order_id, a.status, b.item_id FROM t_order a JOIN t_order_item b ON a.order_id = b.order_id) x; SELECT count(x.item_id) FROM (SELECT a.user_id, a.order_id, a.status, b.item_id FROM t_order a JOIN t_order_item b ON a.order_id = b.order_id) x; SELECT * FROM t_order WHERE test_int in (SELECT test_int FROM t_order);	第 1 句支持 後 2 句不支持	前 2 句支持 第 3 句不支持
UNION	SELECT user_id, order_id, status FROM t_order UNION ALL SELECT item_id, order_id, user_id FROM t_order_item	不支持	不支持
INSERT	INSERT INTO t_order (order_id, user_id, status, test_int) VALUES (1000, 1, 「INIT」, 1); INSERT INTO t_order (order_id, user_id, status, test_int) VALUES (1001, 2, 「INIT」, 2), (1002, 3, 「INIT」, 3);	支持	支持
無列名 INSERT	INSERT INTO t_order VALUES (1000, 1, 「INIT」, 1);	不支持	支持
DELETE	DELETE FROM t_order WHERE user_id=1; (條件有分片鍵) DELETE FROM t_order WHERE test_int=1;(條件無分片鍵)	支持	支持
UPDATE	UPDATE t_order SET test_int=1 WHERE user_id=0;	支持	支持
分片鍵	UPDATE UPDATE t_order SET user_id=1 WHERE user_id=0;	不支持	不支持
CREATE	CREATE TABLE messages (page BIGINT(20) UNSIGNED,time_created_ns BIGINT(20) UNSIGNED,message VARCHAR(10000),PRIMARY KEY (page, time_created_ns)) ENGINE=InnoDB	支持	支持
ALTER	ALTER TABLE messages ADD COLUMN status VARCHAR(50);	支持	支持
DROP	DROP TABLE messages;	支持	支持
TCL	BEGIN; COMMIT; ROLLBACK;	支持	支持
DAL	USE test_keyspace; DESC t_order; SHOW CREATE TABLE t_order;	支持	支持
DCL	CREATE USER ‘test_user’@’%’ IDENTIFIED BY ‘test’; GRANT SELECT, INSERT ON test_keyspace. TO ‘test_user’@’%’; REVOKE INSERT ON test_keyspace. FROM ‘test_user’@’%’; DROP USER ‘test_user’@’%’;	不支持	支持

從測試結果看來，對於經常使用的 SQL 類型，不管是 Vitess 仍是 ShardingSphere 均可以比較好的支持。可是 Vitess 沒法支持排序，所以也沒法支持分頁對於部分應用來講多是比較嚴重的問題。相比 Vitess，ShardingSphere 除 DISTINCT 關鍵字之外，其餘類型的 SQL 支持程度均持平或略有優點。經過 SharingSphere 的官方 issue 列表中可知，DISTINCT 的支持目前正在進行中，相信不久以後就會支持。

分片路由

分佈式數據庫將數據進行分片的主要目的之一就是但願執行的操做能分散在一個或其中數個分片中，而不是在全部分片中，所以如何觸發分片路由，縮小分片範圍也是須要重點關注的功能。

Vitess 在 VSchema Guide 文檔說明 Select、Update、Delete 經過 Where 條件中的等值條件進行路由，等值條件僅包括了 = 及 IN；Insert 則根據插入字段是否包含分片鍵來進行分片路由。

ShardingSphere 除了支持 Where 條件中的 = 及 IN 進行分片路由以外，還能夠經過 BETWEEN 進行分片路由 (須要使用 RangeShardingAlgorithm 或 ComplexShardingStrategy)，Insert 時一樣根據插入字段來進行分片路由。

爲了驗證分片路由的執行條件，首先要開啓 MySQL 數據庫的 GENERAL_LOG 參數。

SET GLOBAL GENERAL_LOG = 1;
SHOW VARIABLES LIKE '%general_log%';

開啓該參數以後，MySQL 數據庫將會記錄全部執行過的 SQL，經過查看分片庫中實際執行的 SQL，來判斷是分片路由仍是廣播。

以後在 Vitess 中執行數個測試 SQL：

SELECT * FROM t_order WHERE user_id = 7;
SELECT * FROM t_order WHERE user_id in (7, 9);
SELECT * FROM t_order WHERE user_id=7 or user_id=11;
SELECT * FROM t_order WHERE user_id BETWEEN 7 AND 11;

從 Vitess 分片 1 的 general_log，找到 Mysql 實際執行了以下 SQL：

select * from t_order where user_id in (9)
select * from t_order where (user_id = 7 or user_id = 11)
select * from t_order where user_id between 7 and 11

從 Vitess 分片 2 的 general_log，找到 Mysql 實際執行了以下 SQL：

select * from t_order where user_id = 7
select * from t_order where user_id in (7)
select * from t_order where (user_id = 7 or user_id = 11)
select * from t_order where user_id between 7 and 11

因爲 user_id=7 屬於分片 2，因此 SQL1 不會分發到分片 1 中，而 SQL2 也被實際改寫，只將 user_id=9 分發到了分片 1，說明對於 = 以及 IN，Vitess 的確可以正確進行路由分片； 由於 user_id 7 和 11 均屬於分片 2，因此對於等值 OR 查詢 Vitess 並無解析到條件內部，而是直接執行了廣播。

而後在 ShardingSphere 中執行測試 SQL：

SELECT * FROM t_order WHERE order_id = 1007 AND user_id=7;
SELECT * FROM t_order WHERE order_id = 1007;
SELECT * FROM t_order WHERE order_id in (1007, 1008);
SELECT * FROM t_order WHERE order_id in (1007, 1009);
SELECT * FROM t_order WHERE order_id=1007 or order_id=1011;

從 ShardingSphere 分片 1 的 general_log，發現 Mysql 實際執行了以下 SQL：

SELECT * FROM t_order_1 WHERE order_id = 1007
SELECT * FROM t_order_0 WHERE order_id in (1007, 1008)
SELECT * FROM t_order_1 WHERE order_id in (1007, 1008)
SELECT * FROM t_order_1 WHERE order_id in (1007, 1009)
SELECT * FROM t_order_1 WHERE order_id=1007 or order_id=1011
SELECT * FROM t_order_1 WHERE order_id=1007 or order_id=1010
SELECT * FROM t_order_0 WHERE order_id=1007 or order_id=1010

從 ShardingSphere 分片 2 的 general_log，發現 Mysql 實際執行了以下 SQL：

SELECT * FROM t_order_1 WHERE order_id = 1007 AND user_id=7
SELECT * FROM t_order_1 WHERE order_id = 1007
SELECT * FROM t_order_0 WHERE order_id in (1007, 1008)
SELECT * FROM t_order_1 WHERE order_id in (1007, 1008)
SELECT * FROM t_order_1 WHERE order_id in (1007, 1009)
SELECT * FROM t_order_1 WHERE order_id=1007 or order_id=1011
SELECT * FROM t_order_1 WHERE order_id=1007 or order_id=1010
SELECT * FROM t_order_0 WHERE order_id=1007 or order_id=1010

ShardingSphere 的等值查詢和 Vitess 同樣，能準確的肯定對應分片表進行查詢，當 SQL 中存在庫級分片鍵 user_id 時（SQL1），ShardingSphere 只將 SQL 定位在了分片 2 的 t_order_1 分表；而查詢不帶有庫級分片時（SQL2），ShardingSphere 進行了庫級的廣播，但仍然可以將 SQL 定位在 t_order_1 表；而對於 IN 方式，雖然可以準確的定位到分片表，可是不會對 IN 的條件進行重寫（分片 1 的 SQL2-4）；對於 OR 的等值查詢，ShardingSphere 可以定位到具體的分片，比 Vitess 優秀；最後因爲測試用例使用的是 InlineShardingStrategy，所以沒法對 BETWEEN AND 的 SQL 進行測試。

通過測試，Vitess 和 ShardingSphere 均可以對等值條件進行準確的分片路由；ShardingSphere 相比於 Vitess 多支持了 OR 等值的分片路由，而且在實現了特定算法或特定策略時，還可以支持 BETWEEN AND 的分片路由。

另外，對於強制分片路由，Vitess 在 FAQ 中回答須要用戶直接鏈接到對應分片的 vttablet 進行操做，而 ShardingSphere 支持 Hint 方式進行強制分片路由，依舊使得分片對應用透明。由此看來，ShardingSphere 在分片路由上的功能，也要略強於 Vitess。

結果歸併

當分片路由將 SQL 路由到多個分片，或沒法使用分片路由而進行廣播時，如何將多個分片的結果合併爲一個正確的結果，就涉及到結果歸併。

Vitess 在文檔中沒有對結果歸併詳細的說明，從在以前的 SQL 測試中可以發現，Vitess 對於通常的結果僅是簡單的將各個分片的結果集按照分片順序鏈接起來；對於部分聚合的結果歸併，如 count 和 sum，Vitess 可以正確的進行合併；可是對於一些複雜的歸併類型，好比 avg 或 order by 的結果歸併，就沒法支持；在測試過程當中，還發現 Vitess 會對 Limit 的分頁 SQL 進行改寫，好比分頁 SQL

SELECT * FROM t_order LIMIT 10,10;

就會改寫成

SELECT * FROM t_order LIMIT 20;

而後將 2 個分片的結果集合並以後再獲取 10～20 的結果。

ShardingSphere 在文檔 歸併引擎 一節中對結果歸併有很是詳細的描述，將歸併分類爲遍歷、排序、分組、分頁和聚合 5 種類型。不只和 Vitess 同樣可以將分片的結果集普通地鏈接起來，並且還支持了 avg 和 order by 的結果歸併。同時對於 Limit 分頁 SQL，也進行了改寫。

正是因爲 ShardingSphere 對結果歸併有着更好的支持，因此 ShardingSphere 在 SQL 支持上可以比 Vitess 表現的更好。

分佈式事務

事務是數據庫中一個重要且經常使用的功能，對於分佈式數據庫而言一樣不可或缺。所以 Vitess 和 ShardingSphere 都提供了一些可選的分佈式事務功能。

Vitess 提供了 3 個級別的分佈式事務，單庫事務、多庫事務、兩階段提交事務，用戶可選擇其中一種做爲 Vitess 的分佈式事務實現：

• 單庫事務指的是僅容許單個數據庫事務。嘗試超出單個數據庫的任何事務都將失敗。
• 多庫事務容許事務跨越多個數據庫，但每一個數據庫均爲單獨提交，即弱 XA，可能會出現部分提交致使數據不一致，且沒法回滾。
• 兩階段提交相似於多庫事務，但能保持多數據庫間的原子性，即其中一個數據庫提交失敗時，其餘數據庫的提交將會回滾以保持數據一致。

ShardingSphere 一樣提供了 3 種類型的分佈式事務，本地事務、XA 事務及柔性事務（開發中，預計 3.1.0 發佈）：

• 本地事務相似於 Vitess 的多庫事務，各個數據庫獨立提交，即弱 XA。
• XA 事務即兩階段提交事務，默認採用 Atomikos 事務管理器。
• 柔性事務採用 SAGA 模型進行事務控制，以保證數據的最終一致性。其中 ShardingSphere 在 3.x 以前的版本也使用過最大努力送達型事務，但因爲無回滾能力，所以已經廢棄，轉而使用能力更增強大的 SAGA。

Vitess 和 ShardingSphere 當前版本的分佈式事務功能至關，可是 Vitess 的官方文檔和 roadmap 計劃中，彷佛沒有實現柔性事務的計劃，所以一旦 ShardingSphere 3.1.0 中支持柔性事務，在分佈式事務功能上將能支持更多的應用場景。

讀寫分離

Vitess 的不提供默認的讀寫分離功能，可是提供在 SQL 中經過 @指定的方式進行從庫的查詢，例如在 SQL 中經過 ks@master 將查詢指向主庫，而使用 ks@replica 或 ks@rdonly 將查詢指向從庫或備庫。

ShardingSphere 的讀寫分離功能只須要在配置中指定主庫和從庫，ShardingSphere 能自動地將 DML 路由至主庫，DQL 路由至從庫；同時 ShardingSphere 容許多個從庫並配置負載均衡策略將請求疏導到不一樣的從庫；另外 ShardingSphere 還能夠經過 Hint 進行強制主庫路由。

ShardingSphere 的讀寫分離功能，不管從對 SQL 的入侵程度，仍是從功能的實現程度，都略強於 Vitess 的讀寫分離。

分佈式主鍵

Vitess 的分佈式主鍵，用戶可經過設定全局非分片的外部查詢表來實現。如 Vitess 在官方文檔中的用例，將 user_id（主分片鍵）列配上全局序列表 user_seq，組成自增分佈式主鍵；
ShardingSphere 提供靈活的配置分佈式主鍵生成策略方式。 在分片規則配置中可配置每一個表的主鍵生成策略，默認使用雪花算法（snowflake）生成 64bit 的長整型數據。ShardingSphere 的雪花算法的時間紀元從 2016 年 11 月 1 日零點開始，可使用到 2156 年，相信能知足絕大部分系統的要求。

管理功能對比

配置管理

Vitess 將數據庫信息、分片信息等元數據信息，存儲在 zookeeper 或 Etcd 註冊中心中，並配以 GUI 系統 vtctld 和命令行系統 vtctl 對 Vitess 的功能進行管理和控制。同時 Vitess 提供 workflows，將一些經常使用操做流程，變成可控制的工做流，使運維人員可以自動快速地執行諸如主從切換、數據遷移、平衡分片等操做。

ShradingSphere 一樣能夠將分片信息，配置信息等元數據，存儲在 zookeeper 或 Etcd 註冊中心中，但暫時沒有提供 GUI 或命令控制檯功能，對配置和 ShardingSphere 程序進行控制和管理，用戶須要在 zookeeper 或 Etcd 的 API 或自帶的控制檯中，修改其中的信息。

監控

Vitess 在 vtagate 和 vttablet 中提供了簡易的 GUI，用戶經過 GUI 頁面不只可以查看 Vitess 自己部分組件的健康情況，QPS 等信息，還能獲取一部分底層數據庫的監控信息。

ShardingSphere 自身並不提供監控，可是能夠經過一些 APM 系統進行應用監控。目前 ShardingSphere 提供兩種方式對接應用性能監控系統：

使用 OpenTracing API 發送性能追蹤數據。面向 OpenTracing 協議的 APM 產品均可以和 ShardingSphere 自動對接，好比 SkyWalking，Zipkin 和 Jaeger。

使用 SkyWalking 的自動探針。

數據庫管理

Vitess 提供了備份數據庫數據的功能，能將數據庫的數據、配置，連同 vttablet 一同備份到 NFS、雲存儲或本地文件系統中，在備份的過程當中，還能進行自動壓縮以提升備份效率，而且 Vitess 能夠從備份中快速建立出 vttable 並加入集羣中。Vitess 還提供了主從切換和重設主從關係的功能，該功能不只能夠由 DBA 有計劃的使用 workflow 執行，還能夠在數據庫節點失效或有問題時自動執行。Vitess 也提供了重分片 (Resharding) 的數據遷移方式，使得用戶可以在修改分片規則後平滑地將舊分片的數據遷移到新分片上，Vitess 會在新分片上覆制，驗證和保持數據最新，而現有分片繼續提供實時讀寫流量。當 Vitess 準備切換時，只需幾秒鐘的只讀停機時間便可進行遷移。在切換執行期間，能夠讀取現有數據，但沒法寫入新數據。

ShardingSphere 目前僅提供了熔斷實例和禁用從庫的功能，在 roadmap 中還規劃實現多數據副本和彈性伸縮的功能。

總結

Vitess 和 ShardingSphere 做爲當下優秀的數據庫中間件和分佈式數據庫解決方案，在數據分片、分佈式事務和數據庫治理等功能上均有所建樹，可是雙方在功能側重上有部分差別。

關於數據分片、分佈式事務等 OTLP 應用功能方面，ShardingSphere 比 Vitess 提供了更豐富和自由的分片方式、提供了更多的 SQL 支持和更容易觸發的分片路由、提供了侵入性更低的讀寫分離並即將提供更多種的分佈式事務類型。所以 ShardingSphere 在應用功能方面要強於 Vitess。

而關於管理方面的功能，Vitess 相比 ShardingSphere 增長了 GUI 的控制方式、提供了數據庫的備份和主從切換功能、並提供部分自身和數據庫的監控。所以 Vitess 在管理方面的功能要優於 ShardingSphere。

ShardingSphere 還在快速發展中，將來也會對數據庫治理及彈性數據遷移作大量工做。若是目前想找一個完美的在線功能 + 管理功能的解決方案，能夠混合部署，在線查詢更新用 ShardingSphere，而後使用 Vitess 進行數據的管理和監控，並能夠自行開發插件，同步 Vitess 和 ShardingSphere 的註冊中心配置，使其動態生效。

最後，經過一個簡單的表格，總結一下 Vitess 和 ShardingSphere 的對比結論：

對比	Vitess	ShardingSphere
分片模式	僅分庫	分庫 + 分表 + 分庫分表
SQL 支持	略少於 ShardingSphere	略多於 Vitess
分片路由	支持 = 和 IN	支持 =、IN、OR、BETWEEN AND 容許用戶 Hint 強制路由
分佈式事務	1PC（弱 XA）和 2PC（強 XA）	1PC（弱 XA）、2PC（強 XA） 將支持柔性事務 SAGA
讀寫分離	在 SQL 中指向主庫或從庫	配置以後由 ShardingSphere 自動路由
分佈式主鍵	經過全局非分片序列表實現	實現接口，默認使用雪花算法
配置管理	支持 Zookeeper 和 Etcd 提供 2 類管理端	支持 Zookeeper 和 Etcd 暫無管理端
數據庫治理	提供簡單數據庫監控 提供數據備份、主從切換、重分片數據遷移等	僅提供熔斷、禁用從庫功能