背景
隨著網際網路的發展,線上業務越來越普及,使用者量也是越來越大,那麼必定導致使用者量的增加,業務壓力增大. 伺服器的處理請求壓力已經通過分散式微服務解決, 那麼儲存層的壓力也需要有解決方案,那麼這個解決方案就是分庫分表.
水平分表
水平分表可以很好緩解資料儲存大,導致即使使用了索引,那檢索很慢的問題. 比如mysql上千萬條資料時,使用索引效能也開始下降了,這時候分表,那麼每張表只有500萬資料,可以很好解決索引瓶頸問題.
垂直分表
垂直分表有兩個好處. 可以一定解決索引的瓶頸,因為可以讓一顆b+樹儲存更多的資料,比如有圖片大文字資料,垂直分表,就有主從表的概念,這樣大大提高檢索效率; 可以提高並行操作,可以達到同時修改兩張表的資料,不會侷限於行鎖.
水平分庫
水平分庫一般不是因為索引瓶頸導致的, 而是因為業務並行量太大造成的, 一個資料庫已經不能夠及時處理所有的業務請求了,必須將資料庫請求進行分攤處理.如果不是因為資料庫處理不過來,一般水平分表就夠用了,水平分表只是解決儲存量大的索引瓶頸問題
垂直分庫
垂直分庫一般也不是因為索引瓶頸導致的,也是因為業務量大造成的,一般是指單塊業務就很大,必須獨立使用一臺資料庫服務才能及時處理. 否則業務量不大情況,所有模組業務表分不同schema即可.
使用場景
水平分表: 業務並行量不大, 單表資料大,檢索資料慢
垂直分表: 業務並行量不大, 大表,存大文字
水平分庫:業務並行量大,單表資料大
垂直分庫: 業務並行量大, 業務模組分庫,單模組業務量大
總結
1.如果只是資料量大,達到了索引瓶頸,那麼只需要分表即可
2.如果是資料量和並行量都大, 那麼達到了io和cpu瓶頸,那麼需要分庫