淺談高性能數據庫集羣——分庫分表

做者 陳彩華
文章轉載交流請聯繫 caison@aliyun.com
複製代碼

最近學習了阿里資深技術專家李運華的架構設計關於分庫分表的教程，很有收穫，總結一下。數據庫

本文主要介紹高性能數據庫集羣分庫分表相關理論，基本架構，涉及的複雜度問題以及常看法決方案。bash

分庫分表概述

讀寫分離分散數據庫讀寫操做壓力，分庫分表分散存儲壓力微信

適用場景

相似讀寫分離，分庫分表也是肯定沒有其餘優化空間以後才採起的優化方案。那若是業務真的發展很快豈不是很快要進行分庫分表了？那爲什麼不一開始就設計好呢？markdown

按照架構設計的「三原則」（簡單原則，合適原則，演化原則），簡單分析一下：架構

首先，這裏的「若是」事實上發生的機率比較低，作10個業務有一個業務能活下去就很不錯了，更況且快速發展，和中彩票的機率差很少。若是咱們每一個業務上來就按照淘寶、微信的規模去作架構設計，不但會累死本身，還會害死業務。ide

其次，若是業務真的發展很快，後面進行分庫分表也不遲。由於業務發展好，相應的資源投入就會加大，能夠投入更多的人和更多的錢，那業務分庫帶來的代碼和業務複雜問題就能夠經過加人來解決，成本問題也能夠經過增長資金來解決。oop

增長表操做的次數post

相似讀寫分離，具體實現也是「程序代碼封裝」和「中間件封裝」，但具體實現複雜一些，由於還有要判斷SQL中具體操做的表，具體操做(例如count、order by、group by等)，根據具體操做作不一樣的處理。性能

參考學習