本文翻自于 Apache ShardingSphere PMC 潘娟發(fā)表于 Stack Overflow 上技術(shù)文章 “How sharding a database can make it faster”。

原文鏈接：https://stackoverflow.blog/2022/03/14/how-sharding-a-database-can-make-it-faster/

數(shù)據(jù)分片往往是分布式數(shù)據(jù)庫用以提高性能的眾多首選方法之一，而近些年來的技術(shù)創(chuàng)新使其逐漸成為最佳選擇。

如今，數(shù)據(jù)庫受到廣泛關(guān)注，這是因?yàn)槠涔芾碇咀钪匾臄?shù)據(jù)資產(chǎn)。30 年前，數(shù)據(jù)大多存儲在紙、磁帶或某種類型的磁盤上。當(dāng)時人均生產(chǎn)和消費(fèi)的數(shù)據(jù)量較少，所以這些方式可以有效支持存儲、管理和訪問數(shù)據(jù)。

然而，“數(shù)據(jù)為王”的時代，情況早已截然不同。隨著智能手機(jī)的出現(xiàn)與普及，日常生活越來越離不開手機(jī)，手機(jī)應(yīng)用程序所消耗和產(chǎn)生的數(shù)據(jù)量之大，是十五年前人們無法想象的。海量數(shù)據(jù)意味著數(shù)據(jù)庫集群需要處理龐大的流量，一些頭部網(wǎng)站和服務(wù)器每周接收訪問甚至達(dá)到數(shù)十億次級，數(shù)據(jù)庫集群承受著巨大壓力。

我們又該如何處理這些到達(dá)數(shù)據(jù)庫集群的龐大數(shù)據(jù)流量呢？

答案可能是采用數(shù)據(jù)分片。也許，你從未聽說過數(shù)據(jù)分片，或者你早已將其視為無法應(yīng)對當(dāng)代挑戰(zhàn)的過時解決方案，而選擇忽略它。數(shù)據(jù)庫分片架構(gòu)聽起來可能不像其他解決方案一樣搶眼或是花里胡哨，但它絕對兼具有效性和實(shí)用性。

近期，數(shù)據(jù)分片方式實(shí)現(xiàn)了重大技術(shù)創(chuàng)新，而不久前人們還是無法想象的（例如能夠使分片更易于實(shí)現(xiàn)和管理的分布式 SQL/DistSQL）。也許這就是在一些尋求實(shí)現(xiàn)數(shù)據(jù)可擴(kuò)展性的區(qū)塊鏈公司中越來越受歡迎的原因。

數(shù)據(jù)庫碎片化

數(shù)據(jù)庫誕生距今已有 50 多年，在此期間你可能認(rèn)為數(shù)據(jù)庫已無創(chuàng)新的空間。但事實(shí)上，數(shù)據(jù)庫碎片化已成為科技行業(yè)發(fā)展最快的垂直領(lǐng)域之一，因?yàn)楝F(xiàn)有數(shù)據(jù)基礎(chǔ)設(shè)施的復(fù)雜性似乎只會惡化。

許多現(xiàn)代應(yīng)用程序都建立在多個并且通常是特定用途的數(shù)據(jù)庫之上。單個應(yīng)用程序可能包括用于存儲和訪問內(nèi)容的關(guān)系數(shù)據(jù)庫（例如 PostgreSQL）、用于內(nèi)容緩存的內(nèi)存數(shù)據(jù)庫（例如 Redis）、自定義數(shù)據(jù)庫（例如時間序列數(shù)據(jù)庫）和用于分析的數(shù)據(jù)倉庫?，F(xiàn)在，試想一下，一家企業(yè)擁有多種應(yīng)用程序，或者不同部門各自采用不同的應(yīng)用，又或者更糟糕的，不同供應(yīng)商同時應(yīng)用不同數(shù)據(jù)庫時會發(fā)生什么？

如上所述，數(shù)據(jù)已成為所有企業(yè)最重要的資產(chǎn)之一，而數(shù)據(jù)庫技術(shù)近期迅猛發(fā)展，離不開高速發(fā)展的人工智能、機(jī)器學(xué)習(xí)、區(qū)塊鏈和云技術(shù)。

據(jù) DB-Engines 統(tǒng)計(jì)，目前已有超過 350 個數(shù)據(jù)庫管理系統(tǒng)，當(dāng)然還有更多數(shù)據(jù)庫系統(tǒng)甚至沒有被其列入名單。

根據(jù)卡內(nèi)基梅隆大學(xué)設(shè)計(jì)并維護(hù)的 “Database of Databases” 網(wǎng)站統(tǒng)計(jì)，目前已有 792 個值得關(guān)注且具有差異的數(shù)據(jù)庫管理系統(tǒng)。

行業(yè)中存在這么多不同的數(shù)據(jù)庫管理系統(tǒng)（Database Management Systems，簡稱 DBMS）也反映出企業(yè)在數(shù)據(jù)庫管理系統(tǒng)選型時有著多種潛在需求。

例如，銀行或其他金融機(jī)構(gòu)可能會選擇 SQL Server 或 PostgreSQL 等關(guān)系 DBMS 以確保其結(jié)構(gòu)化數(shù)據(jù)具有ACID（Atomicity, Consistency, Isolation & durability）事務(wù)特性。對于有著大型在線多人游戲或在線會話的 Web 應(yīng)用程序業(yè)務(wù)的企業(yè)而言，通常偏好 Redis 等鍵值 NoSQL 數(shù)據(jù)庫。從事社交媒體分析的企業(yè)通常會選擇圖形數(shù)據(jù)庫，而物聯(lián)網(wǎng)（IoT）企業(yè)會選擇時間序列數(shù)據(jù)庫來支持其傳感器或網(wǎng)絡(luò)數(shù)據(jù)。

如果你認(rèn)為這些選擇不錯，隨著未來幾年更多的解決方案進(jìn)入市場，你也會喜歡這種多樣化的選擇。這些解決方案可能是由具有創(chuàng)新性的初創(chuàng)公司實(shí)現(xiàn)，而更成熟的數(shù)據(jù)庫供應(yīng)商也將繼續(xù)發(fā)布新產(chǎn)品或增強(qiáng)已有解決方案。

不久后，數(shù)據(jù)庫市場碎片化趨勢會更加明顯，而碎片化也帶來了重大挑戰(zhàn)，例如需考慮供應(yīng)商技術(shù)是否具有兼容性、舊系統(tǒng)是否具有適應(yīng)性和高昂的更換成本等。

為什么需要數(shù)據(jù)分片？

傳統(tǒng)數(shù)據(jù)庫難以處理海量數(shù)據(jù)和查詢流量，因此 NoSQL 和 NewSQL 概念日益流行，受此啟發(fā)，越來越多新型數(shù)據(jù)庫產(chǎn)品正在投放市場，但是，僅憑這些概念并不能實(shí)際解決數(shù)據(jù)增長問題。

分片技術(shù)可將數(shù)據(jù)拆分為單獨(dú)的行和列，并將其保存在單獨(dú)的數(shù)據(jù)庫服務(wù)器實(shí)例上，以分散流量負(fù)載。每個小表稱為一個分片。Apache HBase 或 MongoDB 等 NoSQL 產(chǎn)品具有分片功能，此外分片架構(gòu)也內(nèi)置于一些 NewSQL 系統(tǒng)中。

讓我們看一下一種特定類型的 NewSQL 架構(gòu)，即與當(dāng)今的 OLTP 問題息息相關(guān)的分片架構(gòu)。

雖然許多解決方案都可以最大限度地減少數(shù)據(jù)庫負(fù)載，但數(shù)據(jù)分片解決方案具有以下優(yōu)點(diǎn)：

? 在多臺機(jī)器上實(shí)現(xiàn)分布式數(shù)據(jù)存儲

? 輕松平衡不同分片上的流量負(fù)載

? 顯著提高查詢性能

? 無需額外操作即可擴(kuò)展數(shù)據(jù)庫

? 高效實(shí)現(xiàn)重用和升級傳統(tǒng) DBMS

? 使用代理支持多租戶，實(shí)現(xiàn)多個數(shù)據(jù)庫跨用戶使用單個服務(wù)器或云計(jì)算資源。

如何進(jìn)行數(shù)據(jù)庫分片

接下來，我們將通過介紹數(shù)據(jù)分片的基本流程，展示如何為 DBMS 實(shí)現(xiàn)分片。此外，在介紹完配置和基本概念之后，也會更深入地解釋一些重點(diǎn)內(nèi)容。

創(chuàng)建分片的最佳技術(shù)之一是將數(shù)據(jù)拆分為多個小表，也稱為分區(qū)。

原表可以分為垂直分片或水平分片，即將一列或多列存儲在單獨(dú)的表中，或者將一行或多行存儲在單獨(dú)的表中。這些表可以標(biāo)記為垂直分片的 “VS1” 和水平分片的 “HS1”，其中數(shù)字代表第一個表或第一個 schema，以此類推。這些數(shù)據(jù)子集綜合構(gòu)成了該表的原始 schema。

以下是分片相關(guān)的兩個關(guān)鍵概念：

? 分片鍵：特定的列值，用于表示該行存儲在哪個分片中。

? 分片算法：一種將數(shù)據(jù)分布到一個或多個分片的算法。

步驟 1：分析場景查詢和數(shù)據(jù)分布情況以確定適合的分片鍵和分片算法

確定存儲指定行的分片，需將分片算法應(yīng)用于分片鍵。不同的分片策略適合不同的場景，常見分片策略包括：

• MOD：Modulo 的縮寫，取模分片算法，用于將每第 n 行或每列發(fā)送到特定的分片。例如，MOD 3 算法會將第一、四、七行發(fā)送到第一個分片，將第二、五、八行發(fā)送到第二個分片，將第三、六、九行發(fā)送到第三個分片，以此類推。
• HASH：哈希取模分片算法，將 Hash 分片在分片之間均勻隨機(jī)分布數(shù)據(jù)。根據(jù)對該行的分片列值計(jì)算的一致 Hash 將每行放置在一個分片中。
• RANGE：基于分片邊界的范圍分片算法，將特定范圍的行或列發(fā)送到各個分片。
• TAG：發(fā)送與特定值匹配的所有行或列。

例如，如果分片鍵是“ID”且分片算法是“ID modulo 2”（即拆分偶數(shù)行和奇數(shù)行），則行將按如下方式進(jìn)行分配：

因此，要做的就是設(shè)計(jì)一個使用該分片鍵的合適算法，而分片策略將會極大程度影響查詢效率和未來的水平擴(kuò)展。不正確或較差的分片算法總是會在不同的分片之間創(chuàng)建冗余數(shù)據(jù)進(jìn)行計(jì)算，最終導(dǎo)致整體計(jì)算性能不佳。

在決定如何進(jìn)行數(shù)據(jù)庫分片時，需考慮的關(guān)鍵點(diǎn)在于明確業(yè)務(wù)查詢和數(shù)據(jù)分布的特征。雖然每個數(shù)據(jù)庫都會有影響數(shù)據(jù)分片策略選擇的個性因素，但我們可以通過提供場景案例來解釋好的分片算法如何可以有效地實(shí)現(xiàn)數(shù)據(jù)分布。

RANGE

例如，當(dāng)對包括時間戳日志詳細(xì)信息的表進(jìn)行分片時，建議使用以創(chuàng)建日期作為分片鍵的 RANGE 分片算法，因?yàn)槿藗儌鹘y(tǒng)上傾向于只在特定的時間范圍內(nèi)查詢這些詳細(xì)記錄。

然而，使用日期-時間時，RANGE 算法可能會導(dǎo)致另外一個問題：由于歷史記錄的更新頻率通常較低，而最近的記錄更新和查詢頻繁，大多數(shù)查詢會針對有最新存儲記錄的分片，導(dǎo)致大多數(shù)查詢相互進(jìn)行競爭以獲得更新該數(shù)據(jù)的專屬權(quán)利。

MOD

MOD 分片算法則可以有效避免上述的激烈競爭。它通過 shardingKey MOD shards number 分割行，最新的行將被拆分為不同的分片，以便將最新的查詢發(fā)送到不同的分片，避免最新的行之間的競爭。分片鍵是字符串值（并且可能對泄露敏感）時，可以使用 HASH 算法創(chuàng)建一個值，MOD 算法可以使用該值將數(shù)據(jù)分布到分表上。

TAG

需按單元格的值對數(shù)據(jù)進(jìn)行分片時，建議使用 TAG 分片算法。假設(shè)，為遵守通用數(shù)據(jù)保護(hù)條例（GDPR），需將所有歐盟相關(guān)數(shù)據(jù)存儲在位于歐盟的服務(wù)器上，為此，我們該如何操作一個基于分片的分布式數(shù)據(jù)庫系統(tǒng)呢？假設(shè)，該數(shù)據(jù)庫管理員（Databse Administrator, DBA) 使用 TAG 分片算法，則可以將帶有標(biāo)記國家/地區(qū)的數(shù)據(jù)的行發(fā)送到位于特定國家/地區(qū)的指定分片，如果想了解有多少記錄受到影響，該分片數(shù)據(jù)庫系統(tǒng)只需從與歐盟相關(guān)分片返回 COUNT(*) 即可回答此查詢 SELECT COUNT(*) FROM registrant_table WHERE region = "EU", 由此，必須從整個分布式系統(tǒng)計(jì)算最終結(jié)果的分布式查詢被簡化成來自一個分片的單個查詢。

沒有哪種方法是放之四海而皆準(zhǔn)的。要獲得最佳數(shù)據(jù)庫性能，就得多花些時間對特定業(yè)務(wù)場景進(jìn)行深入分析。當(dāng)然，為實(shí)現(xiàn)用戶快速入門，基于分片的分布式數(shù)據(jù)庫系統(tǒng)開發(fā)者通常會選擇滿足大多數(shù)用戶案例的通用策略。

步驟 2: 遷移現(xiàn)有數(shù)據(jù)

如果決定執(zhí)行分片，不需要將所有原始數(shù)據(jù)遷移至某一分片集群中。但這樣做是有風(fēng)險的，你將面臨以下問題：

• 如何在分片的同時保證業(yè)務(wù)不間斷運(yùn)轉(zhuǎn)
• 如何在新的分片集群中重放增量數(shù)據(jù)
• 如何比較原數(shù)據(jù)庫和新分片集群的數(shù)據(jù)
• 如何找到將流量切換到新分片集群的最佳時機(jī)

但是，如果你決定將歷史數(shù)據(jù)遷移至分片，傳統(tǒng)方法如下：

1. 首先，通過分片算法將歷史數(shù)據(jù)劃分至新的數(shù)據(jù)庫分片集群。建議使用一個自動數(shù)據(jù)遷移程序，它將運(yùn)行所需的所有 SQL 查詢。

2. 其次，運(yùn)行平臺或程序來拉取和解析數(shù)據(jù)庫日志，以了解數(shù)據(jù)劃分過程中發(fā)生了哪些變更，并將這些變更應(yīng)用至新的分片集群（增量數(shù)據(jù)分片）。

3. 第三，選擇一種數(shù)據(jù)檢查策略來比較原始數(shù)據(jù)庫和新分片集群中的數(shù)據(jù)。這些數(shù)據(jù)檢查策略很靈活，既可以選擇高精度檢查也可以選擇快速檢查，亦或選擇折中的檢查策略。是比較每個單元格，還是只檢查總額，都由你來決定。為達(dá)到最精確的數(shù)據(jù)檢查策略，可以采取逐行比較，這也是最為費(fèi)力的一種檢查方式。而只比較原始數(shù)據(jù)庫和新集群的行值是最為快速的檢查方式，但準(zhǔn)確性也就大打折扣。其他策略，如 CRC32，正在實(shí)現(xiàn)準(zhǔn)確性和速度之間的平衡。

步驟 3：將流量轉(zhuǎn)移至新集群

假設(shè)上述步驟已順利完成，那么下一步就是將在線流量切換到新的分片集群。該操作適用于無法寫入數(shù)據(jù)庫集群的時間段，以便兩個數(shù)據(jù)集保持一致并保留可選查詢——非高峰時間此步驟為常見選擇。

應(yīng)禁止所有更新請求以保持分布式數(shù)據(jù)一致性。但可以允許查詢，因?yàn)椴樵儾粫鸱植际较到y(tǒng)中的任何變動。

這個過程很簡單，但每個部分處理起來可能會有難度。自動執(zhí)行將最大限度縮短停機(jī)時間，但由于處理的數(shù)據(jù)十分重要，建議應(yīng)保持謹(jǐn)慎。

不過，好消息是，你并非第一個面臨這些挑戰(zhàn)的人。開源項(xiàng)目幫助我們站在了巨人的肩膀上。

整個分片過程是 Apache ShardingSphere（我也是該項(xiàng)目的 Contributor 之一） 的主要功能之一。它提供各種分片策略、數(shù)據(jù)遷移、重新分片和管理現(xiàn)有分片等功能。

它還提供了許多更為高級的功能來幫助解決我們在下一節(jié)中將提到的問題。此外，有一個額外的好處是，ApacheShardingSphere 擁有一個活躍的社區(qū)，這意味著你的大多數(shù)問題已經(jīng)得到了解決。

怎樣才是好的分片？

現(xiàn)在我們已經(jīng)了解了分片工作流程以及在數(shù)據(jù)庫上執(zhí)行分片的必要步驟。但是好的分片應(yīng)該是什么樣的呢？

無須對邊緣理論或背景和場景特定要求進(jìn)行太多擴(kuò)展，好的分片通常具有六個特點(diǎn)。

如果負(fù)責(zé)運(yùn)行操作的 DBA（數(shù)據(jù)庫管理員）發(fā)生了變動，分片應(yīng)易于設(shè)置和理解。分片具有高可用性、彈性伸縮能力、高分布式系統(tǒng)性能、可觀察性和低遷移成本。

這六個要素代表了理想的分片，但它還取決于你所選擇的分片客戶端。

使用分片和副本

由于數(shù)據(jù)庫場景多種多樣，而需求會隨著應(yīng)用程序的擴(kuò)展而變化，因此除了上述核心流程之外，你還需要了解以下內(nèi)容。

提升數(shù)據(jù)庫性能和擴(kuò)展性的另一種方法是通過副本。副本會創(chuàng)建獨(dú)立的重復(fù)數(shù)據(jù)庫節(jié)點(diǎn)，寫入某一節(jié)點(diǎn)的數(shù)據(jù)將被復(fù)制到另一個重復(fù)節(jié)點(diǎn)上。

一般來說，無論是專業(yè)人士還是致力于 passion projects 的開發(fā)人員都在努力最大限度地利用數(shù)據(jù)庫，以實(shí)現(xiàn)高可用和高性能。然而，分片和副本的體系架構(gòu)可能會讓數(shù)據(jù)庫管理和路由策略復(fù)雜化。

設(shè)想每個分片都有副本節(jié)點(diǎn)，結(jié)果將如下圖所示。如果一個主節(jié)點(diǎn)有多個副本，則訪問它們的應(yīng)用程序情況會更為復(fù)雜。

那么，分片和副本有何不同呢？如上所述，分片意味著將一個大表拆分為幾個小表以創(chuàng)建許多分片；另一方面，副本將對原始表創(chuàng)建多個副本。每個副本將包含原始節(jié)點(diǎn)（主節(jié)點(diǎn)）的全部數(shù)據(jù)。

分片可以幫助用戶對存在于多個服務(wù)器上的數(shù)據(jù)進(jìn)行負(fù)載均衡，以實(shí)現(xiàn)可擴(kuò)展性；而副本將創(chuàng)建主庫備份，以提高系統(tǒng)可用性。這兩種不同的體系架構(gòu)給分布式系統(tǒng)帶來了不同的優(yōu)勢?；谶@一論證，一些用戶希望同時擁有這兩種功能，因此同時利用分片和副本的體系架構(gòu)并不少見。

如下圖所示，用戶可能會希望跨不同的服務(wù)器（如P1、P2、P3）對一個包含大量數(shù)據(jù)的數(shù)據(jù)庫進(jìn)行分片。每次查詢也會被分成不同的分片，以提高該分布式數(shù)據(jù)庫系統(tǒng)的 TPS 或 QPS。但是，一旦其中一個分片崩潰下線，可用性將降至 2/3。不僅如此，重新調(diào)用離線副本非常耗時，這會造成嚴(yán)重?fù)p失。為提高該分片系統(tǒng)的可用性，對每個分片進(jìn)行復(fù)制，即對前面提到的主節(jié)點(diǎn) P1、P2、P3 進(jìn)行復(fù)制，將是一種高效的方法。

R1、R2、R3 的存在能很好的解釋我上面說到的解決方案。當(dāng) P1 不可用時，其副本 R1 將成為主節(jié)點(diǎn)以服務(wù)于業(yè)務(wù)。這是一個安全的選擇，其理念是停機(jī)率越小，業(yè)務(wù)和服務(wù)的損失就越小。

這個想法乍聽上去不錯，但是這一分布式分片數(shù)據(jù)庫系統(tǒng)的拓?fù)浣Y(jié)構(gòu)讓應(yīng)用程序訪問變得十分復(fù)雜。假設(shè)每個主節(jié)點(diǎn)有兩個副本，那么由 P1、P2、P3 和它們的六個副本組成的網(wǎng)絡(luò)就會讓開發(fā)人員感到困惑和負(fù)擔(dān)。他們可能會提出這樣的問題：哪個主節(jié)點(diǎn)適合該查詢？如何訪問他們的副本？如何在不同副本之間進(jìn)行負(fù)載均衡？一旦主節(jié)點(diǎn)無法正常工作，誰來負(fù)責(zé)重新路由此查詢？

在這一假設(shè)場景中，開發(fā)人員負(fù)責(zé)代碼編寫以保證業(yè)務(wù)效率。這種架構(gòu)的確有其優(yōu)勢，但其復(fù)雜性也意味著難以對其加以利用和維護(hù)。

如何對應(yīng)用程序隱藏這種復(fù)雜性？

一般來說，有兩種客戶端或訪問模式可供用戶選擇，外加一種新的“額外”類型客戶端。用戶可以通過專門的數(shù)據(jù)庫連接驅(qū)動程序或通過將應(yīng)用程序連接到路由數(shù)據(jù)的代理應(yīng)用程序來啟動分片。

Sidecar 是可用分片模式中相對較新的概念，它起源于 service meshes。簡單地說，它是一個與某種服務(wù)一起部署的代理實(shí)例，用于處理不同服務(wù)之間的通信、監(jiān)控等。這種模式的操作方式類似于摩托車的跨斗。就是說跨斗被附加到母應(yīng)用程序上，同時為該應(yīng)用程序提供支持性功能。

如果我們使用專門的驅(qū)動程序或代理而非使用 Sidecar，它將僅僅是單個數(shù)據(jù)庫服務(wù)器，能夠幫助用戶管理數(shù)據(jù)庫集群。如此一來，應(yīng)用程序就不會受到這些復(fù)雜的訪問拓?fù)涞挠绊?，也不必進(jìn)行重構(gòu)代碼以適應(yīng)新的框架。

總結(jié)與趨勢

分片是解決網(wǎng)絡(luò)應(yīng)用迅速發(fā)展所帶來新挑戰(zhàn)的方法之一。其他解決方案包括 DBaaS（或云上數(shù)據(jù)庫）、新的數(shù)據(jù)庫體系架構(gòu)，或者僅僅是增加用于存儲的數(shù)據(jù)庫數(shù)量這一老辦法。

兜了一大圈，希望這篇文章至少能幫助你了解分片架構(gòu)。如果你早已聽說過分片架構(gòu)，但認(rèn)為它已經(jīng)過時了，那么希望這篇文章能改變你的想法。

實(shí)際上，我不喜歡時尚這個詞，因?yàn)樗o我的感覺是轉(zhuǎn)瞬即逝的，因?yàn)榻裉斓臅r尚明天就有可能過時。雖然生活中有許多事物的確如此，尤其是技術(shù)，但我更愿意以技術(shù)在特定場景下的實(shí)用性、效率和成本優(yōu)勢來評判一項(xiàng)技術(shù)。

所有這些都表明，對新趨勢持開放態(tài)度固然很好，但也不要忘記，有時現(xiàn)有和成熟的技術(shù)可能才是最佳解決方案。

作者介紹

潘娟，SphereEx聯(lián)合創(chuàng)始人兼CTO，Apache member、 Apache ShardingSphere PMC、Apache brpc(Incubating) & Apache AGE(Incubating) mentor、中國木蘭開源社區(qū)導(dǎo)師。曾負(fù)責(zé)京東數(shù)科數(shù)據(jù)庫智能平臺的設(shè)計(jì)與研發(fā)，現(xiàn)專注于分布式數(shù)據(jù)庫 & 中間件生態(tài)及開源領(lǐng)域。被評為《2020 中國開源先鋒人物》，OSCAR尖峰開源人物。

*參考?文檔

[1] https://db.cs.cmu.edu/papers/2016/pavlo-newsql-sigmodrec2016.pdf

[2] https://github.com/apache/shardingsphere

[3] https://opensource.com/article/21/9/distsql