數據庫分庫分表有哪些利弊

這篇文章主要介紹“數據庫分庫分表有哪些利弊”，在日常操作中，相信很多人在數據庫分庫分表有哪些利弊問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”數據庫分庫分表有哪些利弊”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

為什么要分庫分表？

當一張表的數據達到幾千萬時，查詢一次所花的時間會變長。這時候，如果有聯合查詢的話，可能會卡死在那兒，甚至把系統給拖垮。
而分庫分表的目的就在于此：減小數據庫的負擔，提高數據庫的效率，縮短查詢時間。另外，因為分庫分表這種改造是可控的，底層還是基于RDBMS，因此整個數據庫的運維體系以及相關基礎設施都是可重用的。
目前我們系統將近20億數據，每張表最大的接近600w條/表，每條數據大約3k，每個表將近1.5G的數據。查詢經常超時，單條SQL執行count(*)查詢時間達到了最大260ms，0.26s（標準是超過0.1s的數據為慢SQL）。
為了說明我們為什么要分庫分表，我們看一下sql的執行過程。
mysql執行一條sql的過程如下：
1、收到sql
2、把sql放到排隊隊列中
3、執行sql
4、返回結果
在這個執行過程中最花時間的地方在于：
1.排隊等待的時間，
2.sql的執行時間。
如果有2個sql都要同時修改同一張表的同一條數據，mysql對這種情況的處理是：一種是表鎖定（MyISAM存儲引擎），一個是行鎖定（InnoDB存儲引擎）。
表鎖定表示其他操作都不能對這張表進行操作，必須等當前對表的操作完才行。行鎖定也一樣，別的sql必須等這條數據操作完了，其他人才能對這條數據進行操作。
如果數據太多，一次執行的時間太長，等待的時間就越長，這也是我們為什么要分表的原因。

分庫分表術語：

讀寫分離: 不同的數據庫，同步相同的數據，分別只負責數據的讀和寫；
分區: 指定分區列表達式，把記錄拆分到不同的區域中(必須是同一服務器，可以是不同硬盤)，應用看來還是同一張表，沒有變化；
分庫: 一個系統的多張數據表，存儲到多個數據庫實例中；
分表: 對于一張多行(記錄)多列(字段)的二維數據表，又分兩種情形：
垂直分表: 豎向切分，不同分表存儲不同的字段，可以把不常用或者大容量、或者不同業務的字段拆分出去；
水平分表(最復雜): 橫向切分，按照特定分片算法，不同分表存儲不同的記錄。

在實際生產中，通常的進化過程是：單庫單表->單庫多表->多庫多表；；分區->分表->分庫（垂直分庫 - 水平分庫 - 讀寫分離）

單庫單表
單庫單表是最常見的數據庫設計，例如，有一張訂單表(order)放在數據庫中，所有的訂單都可以在order表中查到。
單庫多表
隨著訂單數量的增加，order表的數據量會越來越大，當數據量達到一定程度的時候，對order表的查詢會變慢，從而影響整個DB的性能。
另外，隨著需求的迭代，如果增加添加一列的時候，mysql會鎖表，期間所有的讀寫操作只能等待，別無他法。
這時候，可以將order進行水平的切分，產生多個表結構完全一樣的order表。比如：order_01,order_02…,order_n，那么order_01+order_02+order_n的數據是一份完整的訂單數據。
這個水平切分，簡單的做法如：
按數量切分，1 ~ 1000的存在第一張表，1001 ~ 2000存在第二張表；
按時間切分，比如：2019年1月份存在第一張表，2019年2月份存在第二張表；還可以按照id的哈希值進行切分，等等等等
多庫多表
隨著數據量增加，單臺數據庫的硬件存儲不夠了，并且，隨著查詢量的增加，單臺數據庫服務器已經沒辦法支撐。這時候就需要對數據庫進行水平區分。
比如按地區分庫，一個省份在一個物理數據庫等等

分庫分表后引入的新問題

1.分布式事務問題
做了垂直分庫或者水平分庫以后,就必然會涉及到跨庫執行SQL的問題,就會引發互聯網界的老大難問題-“分布式事務”。那么要如何解決這個問題呢？
使用分布式事務中間件
使用MySQL自帶的針對跨庫的事務一致性方案(XA),不過性能要比單庫的慢10倍左右。
能否避免掉跨庫操作(比如將用戶和商品放在同一個庫中)
2.跨庫join的問題
分庫分表后，表之間的關聯操作將受到限制，就無法join位于不同分庫的表，也無法join分表粒度不同的表， 結果原本一次查詢能夠完成的業務，可能需要多次查詢才能完成。
那么要如何解決這個問題呢？
簡單的解決方法：
全局表：基礎數據，所有庫都拷貝一份。
字段冗余：把需要join的字段冗余在各個表中，這樣有些字段就不用join去查詢了。
系統層組裝：應用端先分別查詢出所有復核條件的，然后在應用端組裝起來，類似于一個mapreduce的過程（較復雜）。
3.橫向擴容的問題
當我們使用哈希取模做分表的時候,針對數據量的遞增,可能需要動態的增加表,此時就需要考慮數據遷移的問題。
原來使用的是hash后對8進行取模，那么，數據是均分在8個表(庫)上。
如果8個表不夠的時候，我們要擴展到16個表，這時候，我們hash后對16取模，新數據是沒有問題的，舊數據就會發生錯亂。
如果哈希后是9，那么，原來我們對8取模后，是1，會到表1進行查詢；但是，現在我們是對16取模，那么是到表9進行查詢的，而這個數據在表9又不存在，因此，就會找不到數據了
4.結果集合并、排序的問題
因為我們是將數據分散存儲到不同的庫、表里的,當我們查詢指定數據列表時,數據來源于不同的子庫或者子表,就必然會引發結果集合并、排序的問題。
如果每次查詢都需要排序、合并等操作,性能肯定會受非常大的影響。

到此，關于“數據庫分庫分表有哪些利弊”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！