本文翻自于 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ù)大多存儲(chǔ)在紙、磁帶或某種類型的磁盤上。當(dāng)時(shí)人均生產(chǎn)和消費(fèi)的數(shù)據(jù)量較少，所以這些方式可以有效支持存儲(chǔ)、管理和訪問數(shù)據(jù)。

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

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

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

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

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

據(jù) DB-Engines 統(tǒng)計(jì)，目前已有超過 350 個(gè)數(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 個(gè)值得關(guān)注且具有差異的數(shù)據(jù)庫管理系統(tǒng)。

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

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

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

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

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

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

分片技術(shù)可將數(shù)據(jù)拆分為單獨(dú)的行和列，并將其保存在單獨(dú)的數(shù)據(jù)庫服務(wù)器實(shí)例上，以分散流量負(fù)載。每個(gè)小表稱為一個(gè)分片。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)：

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

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

? 顯著提高查詢性能

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RANGE

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

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

MOD

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

TAG

需按單元格的值對(duì)數(shù)據(jù)進(jìn)行分片時(shí)，建議使用 TAG 分片算法。假設(shè)，為遵守通用數(shù)據(jù)保護(hù)條例（GDPR），需將所有歐盟相關(guān)數(shù)據(jù)存儲(chǔ)在位于歐盟的服務(wù)器上，為此，我們?cè)撊绾尾僮饕粋€(gè)基于分片的分布式數(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", 由此，必須從整個(gè)分布式系統(tǒng)計(jì)算最終結(jié)果的分布式查詢被簡化成來自一個(gè)分片的單個(gè)查詢。

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

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

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

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

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

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

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

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

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

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

應(yīng)禁止所有更新請(qǐng)求以保持分布式數(shù)據(jù)一致性。但可以允許查詢，因?yàn)椴樵儾粫?huì)引起分布式系統(tǒng)中的任何變動(dòng)。

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

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

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

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

怎樣才是好的分片？

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

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

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

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

使用分片和副本

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)與趨勢(shì)

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

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

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

所有這些都表明，對(duì)新趨勢(shì)持開放態(tài)度固然很好，但也不要忘記，有時(shí)現(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ù)庫智能平臺(tái)的設(shè)計(jì)與研發(fā)，現(xiàn)專注于分布式數(shù)據(jù)庫 & 中間件生態(tài)及開源領(lǐng)域。被評(pí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