1. 引言

為什么企業(yè)招不到人，求職者也說找不到工作？

前段時間公司的師兄在面試候選人之后，發(fā)出了這樣感慨：2023 年，企業(yè)太難招到人了！

而同時，脈脈（技術圈社交軟件）上也是一片哀鴻，說今年互聯(lián)網(wǎng)行情非常差。

圖片來源：脈脈，侵刪

也正如脈脈這位網(wǎng)友所言，現(xiàn)在做普通業(yè)務的后臺開發(fā)基本都是 CRUD（數(shù)據(jù)庫 “增刪改查” 的意思，形容沒有技術含量的活），正常情況下很少涉及高并發(fā)、海量數(shù)據(jù)的實踐場景。

畢竟，技術服務于業(yè)務，如果你的業(yè)務每天就幾百人使用，咱搞個能抗幾千萬并發(fā)的系統(tǒng)又有什么意義呢？

性價比不高！

但是，這些企業(yè) HR 能不知道嗎？企業(yè)面試官也不是傻子，天天在簡歷和面試上挑挑揀揀的，也耽誤時間。有這功夫，不如在工位多摸一會魚，不香嗎？

所以啊，你用沒用過，和你知不知道是兩個概念。面評里一般會有幾個等級的打分，分別是：

• 差：和簡歷完全不符，懷疑簡歷造假。
• 中：可以略答一二，但核心要點說不清楚。
• 良：可以說清楚，但實踐不足。
• 優(yōu)：邏輯清晰，表達精準，實踐豐富。

但是，有面評的前提是：你得通過簡歷。

如果你的簡歷全是 CRUD，那面試官根本不會想和你聊！

所以，為了擺脫 CRUD-candidate 的身份，今天小?和大家聊一聊數(shù)據(jù)量增長和高并發(fā)帶來的數(shù)據(jù)庫問題以及如何解決。

1.2 用戶激增，怎么破？

當用戶量和數(shù)據(jù)量激增時，對于 MySQL 這樣的關系型數(shù)據(jù)庫管理系統(tǒng)，如何有效地應對高并發(fā)、高性能成了工程師們一項重要的任務。

在這篇文章中，我們將探討兩種常見的數(shù)據(jù)庫架構設計策略：MySQL 的拆表（Sharding）和分片（Table Partitioning）。

圖片

這兩種策略都旨在應對數(shù)據(jù)規(guī)模的增大以及高并發(fā)訪問的問題，但它們各有特點，適用于不同的場景和需求。

本文將通過深入拆表和分片的原理、應用場景以及優(yōu)缺點，為大家揭示如何在面對不斷增長的數(shù)據(jù)和流量時，保持數(shù)據(jù)庫的高性能和可用性。

無論您是一名數(shù)據(jù)庫工程師、開發(fā)人員，還是對數(shù)據(jù)庫架構設計感興趣的朋友，本文都將為您提供有價值的見解，幫助您更好地應對數(shù)據(jù)庫擴展的挑戰(zhàn)。

而且，數(shù)據(jù)庫擴展是架構設計繞不開的一項重要話題，更是簡歷和面試中合理 Zhuangbility 的要點內(nèi)容。

低投入，高回報，性價比極高！

接下來讓我們一起深入探討 MySQL 拆表和分片，為構建可靠的系統(tǒng)架構鋪平道路吧~~

2. 拆表

拆表是一種常見的數(shù)據(jù)庫分割技術，通常用于解決單表數(shù)據(jù)量過大、查詢性能下降以及維護困難等問題，下面是拆表的一些場景及其優(yōu)缺點。

什么時候拆表？

1. 大數(shù)據(jù)量表：拆表適用于那些包含大量數(shù)據(jù)的表，例如日志表、歷史數(shù)據(jù)表、交易記錄表等。當單個表的數(shù)據(jù)量已經(jīng)超過數(shù)據(jù)庫服務器的處理能力時，拆分成多個子表可以提高查詢性能。
2. 數(shù)據(jù)分區(qū)：某些應用需要按照時間、地理位置等維度對數(shù)據(jù)進行分區(qū)存儲，以便更有效地管理和查詢數(shù)據(jù)。拆表可以將不同分區(qū)的數(shù)據(jù)存儲在不同的子表中，提高數(shù)據(jù)管理的效率。
3. 權限控制：在某些情況下，不同用戶或應用程序需要訪問相同表的不同數(shù)據(jù)集。通過拆分表，可以更容易地實現(xiàn)數(shù)據(jù)的權限控制。

怎么拆表？

假設有一個 ChatGPT 人機對話系統(tǒng)，其中有一個對話表，每個對話包含多條對話句子。

在對話表 dialog 有一問一答兩條數(shù)據(jù)：

可以發(fā)現(xiàn)，數(shù)據(jù)庫的 dialog_id、user_id、state 等信息重復冗余了。當數(shù)據(jù)量增多時，類似的數(shù)據(jù)不僅會大量浪費磁盤空間，還會在查詢時影響整體性能，所以我們可以將其拆為兩個表：

dialog 對話表

sentence 對話句子表

這只是個相對簡單的拆表例子，還有一些拆表可能根據(jù)用戶，或者時間來拆表。

圖片

比如，對于時間敏感的查詢業(yè)務，可以將主表按年、月、日來拆為多個表，以提升查詢性能。

拆表的好處

1. 提高查詢性能：拆表可以將大表拆分成多個較小的子表，從而加快查詢速度。查詢只需要針對特定子表進行，減少了掃描的數(shù)據(jù)量。
2. 靈活性：拆表可以根據(jù)不同的業(yè)務需求進行定制，例如按時間、地理位置、用戶等維度進行拆分，提高數(shù)據(jù)管理的靈活性。
3. 維護和備份：拆表可以使備份和維護更加容易，可以單獨備份和維護每個子表，而不影響其他子表的正常運行。

拆表的壞處

1. 復雜性：拆表需要額外的管理和維護工作，包括數(shù)據(jù)遷移、查詢路由、子表之間的關聯(lián)等。增加了系統(tǒng)復雜性。
2. 查詢路由：在查詢時需要確定查詢應該路由到哪個子表，這可能需要額外的路由邏輯和代碼。
3. 跨子表查詢：如果查詢需要涉及多個子表的數(shù)據(jù)，可能需要更復雜的 SQL 查詢語句和邏輯。
4. 數(shù)據(jù)一致性：在拆表的環(huán)境下，確保數(shù)據(jù)一致性可能會更加復雜，需要額外的措施。

綜合考慮，拆表是一種有效的數(shù)據(jù)庫性能優(yōu)化方法，但需要根據(jù)具體的業(yè)務需求和數(shù)據(jù)特點來決定是否采用，以及如何進行拆表設計。

3. 分片

分片 是將大型數(shù)據(jù)庫分成多個小片段的方法，每個片段獨立運行。

使用分片場景包括：

• 高并發(fā)寫入：當一個表需要頻繁進行插入、更新或刪除操作，可能會導致鎖競爭和性能下降。通過拆分表，可以將寫入操作分散到多個分片，減輕鎖競爭，提高并發(fā)性能。
• 多租戶系統(tǒng)：在多租戶系統(tǒng)中，不同租戶的數(shù)據(jù)可以存儲在不同的分片中，確保數(shù)據(jù)隔離。

分片也需要考慮數(shù)據(jù)一致性和查詢路由的問題。通常，分片數(shù)據(jù)庫需要一個中心控制節(jié)點來管理數(shù)據(jù)分布和查詢路由。

比如，在上述 dialog 表例子上，我們用 user_id 作為哈希鍵分片。

圖片

具體做法為：把數(shù)據(jù)的 user_id 對數(shù)據(jù)分片數(shù)量取余，假設我們一共有 8 個分片，user_id 為 10 時，就將該數(shù)據(jù)插入 dialog_2 的分片中（10%8 = 2）。

查詢時也是先哈希，再去對應的分片上查找數(shù)據(jù)，以此減少每個分片的數(shù)據(jù)量，提升數(shù)據(jù)庫的響應速度，分片的優(yōu)缺點如下。

分片的好處

1. 水平擴展：分片允許數(shù)據(jù)庫系統(tǒng)水平擴展，通過添加更多的分片來增加存儲容量和吞吐量。
2. 高并發(fā)：每個分片可以并行處理寫入操作，減少鎖競爭，提高并發(fā)性能。
3. 數(shù)據(jù)隔離：不同分片之間的數(shù)據(jù)相互隔離，有助于保持數(shù)據(jù)的完整性和隱私性。

分片的壞處

1. 復雜性：分片增加了系統(tǒng)的復雜性，包括數(shù)據(jù)路由、分片鍵選擇、數(shù)據(jù)遷移等方面的管理工作。
2. 跨分片查詢：在跨越多個分片的查詢中，需要合并和聚合數(shù)據(jù)，可能導致性能下降。
3. 數(shù)據(jù)一致性：確保跨分片數(shù)據(jù)的一致性是一個挑戰(zhàn)，可能需要實施額外的措施。

看到這里，大家可能有點疑惑。對于數(shù)據(jù)量的增加，拆表和分片都可以起到一定的作用，也都會出現(xiàn)數(shù)據(jù)一致性問題，那他們的區(qū)別是啥呢？

別急，接著往下看。

4. 拆表 VS 分片

MySQL的拆表和分片都是用于處理大規(guī)模數(shù)據(jù)的技術，但它們的應用場景和方式有所不同，以下是它們的聯(lián)系和區(qū)別。

相同點

1. 處理大規(guī)模數(shù)據(jù)：拆表和分片都是為了應對數(shù)據(jù)量巨大的情況而設計的。它們可以提高數(shù)據(jù)庫系統(tǒng)的性能和擴展性，以應對高并發(fā)和大量數(shù)據(jù)存儲需求。
2. 水平擴展：拆表和分片都支持水平擴展，允許將數(shù)據(jù)分布在多個物理存儲位置上，以分攤負載并提高性能。

不同點

應用場景不同

• 拆表：通常在單一表中存儲的數(shù)據(jù)量已經(jīng)非常龐大，難以繼續(xù)擴展或查詢性能下降時，考慮拆分表。拆表是將單一表按照某種規(guī)則或邏輯分割成多個較小的表，通常是為了提高查詢性能或簡化數(shù)據(jù)管理。每個拆分的表通常保留原表的一部分數(shù)據(jù)。
• 分片：適用于整個數(shù)據(jù)庫的數(shù)據(jù)量已經(jīng)無法容納在一臺服務器上，或者需要跨多臺服務器水平擴展的情況。分片是將數(shù)據(jù)庫中的數(shù)據(jù)按照某種規(guī)則或策略分布到多個物理服務器上，每個服務器稱為一個分片。分片通常是為了提高整體系統(tǒng)的性能、可用性和擴展性。

數(shù)據(jù)分布方式不同

• 拆表：拆表是在邏輯上將數(shù)據(jù)拆分為多個表，但這些表通常仍然存儲在同一個數(shù)據(jù)庫實例中。各個表之間可能存在關聯(lián)關系，但它們在同一數(shù)據(jù)庫中。
• 分片：分片是將數(shù)據(jù)分布到多個物理服務器上，每個服務器上都有自己的數(shù)據(jù)庫實例。各個分片之間通常是獨立的，可以在不同的服務器上運行。

管理復雜度不同

• 拆表：相對于分片，拆表的管理復雜度較低，因為所有數(shù)據(jù)仍然在同一個數(shù)據(jù)庫中。但需要注意表之間的關聯(lián)和查詢性能。
• 分片：分片可能涉及到跨多個服務器的數(shù)據(jù)同步、故障恢復、路由管理等復雜問題，管理上相對復雜一些。

查詢方式不同

• 拆表：查詢通常需要在多個表之間進行聯(lián)合或使用應用程序邏輯來合并結果，查詢性能可能會因此受到一定影響。
• 分片：分片系統(tǒng)通常具有路由層，負責將查詢路由到正確的分片上，因此查詢通常更為直接和高效。

綜上所述，拆表和分片都是用于處理大規(guī)模數(shù)據(jù)的技術，但在應用場景、管理復雜度、數(shù)據(jù)分布方式和查詢方式等方面存在差異。

選擇哪種技術取決于具體的需求和系統(tǒng)架構，一般情況下，應對高并發(fā)和海量數(shù)據(jù)，分片拆表（又叫分庫分表）都會用到。

數(shù)據(jù)一致性問題

拆表和分片都可能引入數(shù)據(jù)一致性問題，但問題的性質(zhì)和解決方法有所不同。

拆表的數(shù)據(jù)一致性問題

還以上述的對話表舉例，原始的 dialog 表是一個單一的表，每個對話項都以對話 ID 關聯(lián)。

現(xiàn)在，為了優(yōu)化查詢性能，決定將對話表拆分為兩個表：dialog 和 sentence 表。

在這種情況下，數(shù)據(jù)一致性問題可能出現(xiàn)在以下情況下：

• 當向 dialog 表插入新對話時，如果在插入 sentence 之前發(fā)生了錯誤，可能導致對話主表和對話句子表之間的數(shù)據(jù)不一致。
• 當從 dialog 表刪除對話時，如果在刪除相關的對話句子之前發(fā)生了錯誤，也可能導致數(shù)據(jù)不一致。

解決這些問題的方法通常包括使用事務或一致性哈希等技術來確保數(shù)據(jù)操作的原子性。如果數(shù)據(jù)一致性對業(yè)務非常重要，建議使用數(shù)據(jù)庫事務來處理這些操作。

不了解事務的朋友可以看我之前的這篇文章，解鎖MySQL的黑科技：事務與隔離

分片的數(shù)據(jù)一致性問題

假設有一個社交媒體應用程序，用戶數(shù)據(jù)表存儲了全球 10 億用戶的數(shù)據(jù)，現(xiàn)在決定將用戶數(shù)據(jù)分片到不同的數(shù)據(jù)庫服務器上，以提高性能。

分片的方式可能是按用戶 ID 的范圍進行劃分，每個分片負責一定范圍內(nèi)的用戶數(shù)據(jù)。

在這種情況下，數(shù)據(jù)一致性問題可能出現(xiàn)在以下情況下：

• 當用戶在不同分片之間進行互動（例如，用戶 A 在分片 1 上，用戶 B 在分片 2 上）時，需要確保跨分片的操作具有一致性。
• 如果一個分片的服務器發(fā)生故障，需要確保用戶數(shù)據(jù)可以遷移到其他分片而不丟失或破壞。

解決這些問題的方法通常包括使用分布式事務或一致性哈希等分片技術。例如，可以使用分布式事務來確?？绶制牟僮魇窃有缘?，或者使用數(shù)據(jù)復制和備份來確保故障恢復。

總之，拆表和分片都可能引入數(shù)據(jù)一致性問題，但可以通過適當?shù)募夹g和設計來解決這些問題，以確保數(shù)據(jù)的完整性和一致性。

5. 小結

MySQL 拆表和分片的設計策略，為應對不斷增長的數(shù)據(jù)和高并發(fā)訪問提供了可行的解決方案，同時也伴隨著各自的優(yōu)勢和挑戰(zhàn)。

拆表，像一位精巧的工匠，把復雜的數(shù)據(jù)庫切割成可管理的小塊，為數(shù)據(jù)的水平擴展提供了堅實的基礎。

而分片，似一位智慧的園丁，將數(shù)據(jù)按照規(guī)則有序地分類，使得數(shù)據(jù)庫的維護和查詢更加高效。

但是，無論是選擇拆表還是分片，都需要根據(jù)實際需求和場景來進行權衡和決策。

本文我們剖析了這兩種策略的內(nèi)部工作原理，還深入探討了它們的使用場景、優(yōu)點和限制。通過這些知識，相信屏幕前的你已經(jīng)對如何更好地構建和維護 MySQL 數(shù)據(jù)庫有了更清晰的認識。

無論您是一名數(shù)據(jù)庫專業(yè)人士，還是對技術探索充滿激情的讀者，都希望這篇文章能為您帶來價值和啟發(fā)。