問(wèn)答專欄Q & A COLUMN
分庫(kù)分表是比較靠后的優(yōu)化手段，因?yàn)槌杀颈容^高。
遇到數(shù)據(jù)庫(kù)瓶頸:
- 首先考慮sql優(yōu)化，這是最簡(jiǎn)單的方法。對(duì)現(xiàn)有系統(tǒng)基本沒有影響。
- 其次就是考慮數(shù)據(jù)庫(kù)的讀寫分離，這也是相對(duì)簡(jiǎn)單的方法。在數(shù)據(jù)庫(kù)層面進(jìn)行配置，系統(tǒng)層面只需要調(diào)整一下獲取數(shù)據(jù)庫(kù)連接的邏輯。讀數(shù)據(jù)時(shí)即可以獲取主庫(kù)連接，也可以獲取從庫(kù)連接。寫數(shù)據(jù)時(shí)只獲取主庫(kù)連接。
- 再考慮增加緩存層。將數(shù)據(jù)緩存到緩存中，當(dāng)再次訪問(wèn)時(shí)不再?gòu)臄?shù)據(jù)庫(kù)獲取。一般緩存層對(duì)系統(tǒng)是透明的，基本對(duì)系統(tǒng)本身沒有影響。但是引入緩存，也引入了相應(yīng)的需要考慮的問(wèn)題，比如雪崩，命中率，分布式緩存等
- 還有一種非技術(shù)手段，就是改需求。引起性能問(wèn)題的原因是否是需求不合理？或者需求太復(fù)雜？是否可以簡(jiǎn)化需求？此方法對(duì)系統(tǒng)的影響也相對(duì)較小。
- 最后才考慮分庫(kù)分表。優(yōu)先分庫(kù)，因?yàn)橄鄬?duì)分表更簡(jiǎn)單。將對(duì)應(yīng)的表移動(dòng)到新庫(kù)，調(diào)整系統(tǒng)獲取數(shù)據(jù)庫(kù)連接的邏輯。這里需要考慮要移動(dòng)哪些表，在提高性能的前提下，首先盡量避免分布式事務(wù)。
- 最最后，考慮分表。分表的主要原因是單表數(shù)據(jù)量太大。分表又分縱切和橫切?？v切就是按列切，比如用戶表，常用信息為基本信息表，其它信息為詳情表。橫切就是按行切，比如一億數(shù)據(jù)量的表切分為十張一千萬(wàn)的表。這里就涉及數(shù)據(jù)該存放到哪張表，或從哪張表里取。分表后又可以分庫(kù)，來(lái)進(jìn)一步優(yōu)化。
- 如果涉及到分布式事務(wù)，又要考慮如何保證分布式事務(wù)。理論方面2pc，3pc，paxos，cap，base。對(duì)應(yīng)的中間件的使用。
對(duì)系統(tǒng)的設(shè)計(jì)和優(yōu)化不是人云亦云，需要根據(jù)實(shí)際的場(chǎng)景來(lái)進(jìn)行處理。
評(píng)論0
加載中...
大部分的軟件架構(gòu)、組件或解決方案，都是在解決一些問(wèn)題的同時(shí)，會(huì)帶來(lái)另外的問(wèn)題。
數(shù)據(jù)庫(kù)的分庫(kù)分表，又可以分為垂直拆分和水平拆分（可能大家常說(shuō)的分庫(kù)分表主要指的是后者）：
垂直拆分：這是一種比較常見的數(shù)據(jù)庫(kù)設(shè)計(jì)方法，就是把一個(gè)字段比較多的大表，拆分成多個(gè)小表，特別是在現(xiàn)在分布式、微服務(wù)的架構(gòu)下，可以把各個(gè)小表按照業(yè)務(wù)模型，劃分到不同的數(shù)據(jù)庫(kù)中，這樣就可以利用多臺(tái)數(shù)據(jù)庫(kù)服務(wù)器的性能；但當(dāng)被拆分出來(lái)小表的數(shù)據(jù)量不斷增長(zhǎng)，到了一個(gè)極限的時(shí)候，還是需要考慮水平拆分。
水平拆分：將表中的數(shù)據(jù)，按照一定的規(guī)則分布到不同的數(shù)據(jù)庫(kù)中，比如對(duì)主鍵進(jìn)行Hash和取模操作后，按照結(jié)果把數(shù)據(jù)路由到對(duì)應(yīng)的數(shù)據(jù)庫(kù)上；水平分庫(kù)分表，可以降低每張表的數(shù)據(jù)量，這也是現(xiàn)在大部分公司所使用的方法。
上文中說(shuō)到，水平拆分常用的手段是對(duì)主鍵進(jìn)行Hash和取模操作后，按照結(jié)果把數(shù)據(jù)路由到對(duì)應(yīng)的數(shù)據(jù)庫(kù)上；但如果被拆分的子表，數(shù)據(jù)量也達(dá)到極限值以后，就要面對(duì)數(shù)據(jù)庫(kù)擴(kuò)容的問(wèn)題，比如開始規(guī)劃分成8個(gè)庫(kù)，現(xiàn)在要擴(kuò)到16個(gè)庫(kù)；
路由規(guī)則發(fā)生變化:hash(id)%8 變成了 hash(id)%16，那么歷史數(shù)據(jù)也就要面臨遷移的問(wèn)題；這種情況，要么做數(shù)據(jù)遷移，要么增加分表算法的復(fù)雜性，讓算法可以兼容增加分表前后的數(shù)據(jù)路由。
在單庫(kù)時(shí)代，復(fù)雜的關(guān)聯(lián)查詢是很容易實(shí)現(xiàn)的，但是數(shù)據(jù)庫(kù)被拆分后，數(shù)據(jù)被保存在了不同的數(shù)據(jù)庫(kù)服務(wù)器上，那么夸庫(kù)的join就成了很大的問(wèn)題。通常解決方案有：
如果是垂直拆分，那么可以考慮做一定程度的字段冗余，避免跨表關(guān)聯(lián)；或者可以做數(shù)據(jù)同步，把需要的表同步到同一個(gè)庫(kù)中，進(jìn)行表關(guān)聯(lián)；
代碼層面組裝，也就是把兩邊的數(shù)據(jù)都拿出來(lái)，然后在代碼里面關(guān)聯(lián)組裝；或者先獲取主表數(shù)據(jù)，再把其余字段補(bǔ)齊；但是從實(shí)際情況來(lái)看，這個(gè)方案在大多數(shù)場(chǎng)景下，實(shí)現(xiàn)起來(lái)都比較困難；
現(xiàn)在一個(gè)比較主流的做法，是引入ES或ES+HBase或solr+HBase，把部分字段的全量數(shù)據(jù)保存在同一個(gè)地方。
在水平拆分的場(chǎng)景下，一單一張表被拆分成多張表部署在多個(gè)數(shù)據(jù)庫(kù)中，那么就不能使用數(shù)據(jù)庫(kù)自身的主鍵生成機(jī)制了；這時(shí)候就需要由我們自己來(lái)考慮主鍵生成策略：
主鍵生成中心：可以利用數(shù)據(jù)庫(kù)、Redis、MongoDB、zookeeper等組件實(shí)現(xiàn)，需要生產(chǎn)主鍵的時(shí)候，調(diào)用主鍵生成中心的接口；缺點(diǎn)也很明顯，增加了網(wǎng)絡(luò)開銷，并且主鍵生成中心如果發(fā)生問(wèn)題，后果會(huì)很嚴(yán)重。
UUID：本地生成，不需要第三方組件，生成比較簡(jiǎn)單，性能好；不過(guò)缺點(diǎn)也不少，長(zhǎng)度長(zhǎng)，不利于存儲(chǔ)，并且沒有排序，是個(gè)字符串，不利于查詢。
一些唯一性ID的生成算法：比如Snowflake、UidGenerator、Leaf等等。
單庫(kù)的時(shí)候，解決事務(wù)問(wèn)題很簡(jiǎn)單，但是現(xiàn)在要保證跨庫(kù)的事務(wù)問(wèn)題，需要額外的成本；
這種場(chǎng)景下（性能要求高，一致性要求不是那么的高），大部分公司會(huì)放棄事務(wù)的【實(shí)時(shí)】一致性，只要在一定的時(shí)間內(nèi)，事務(wù)【最終】一致即可。
評(píng)論0
加載中...
1.優(yōu)化SQL加索引
2.業(yè)務(wù)是否可以垂直拆分，業(yè)務(wù)拆分了可以分庫(kù)
3.業(yè)務(wù)單邊數(shù)據(jù)量還是大，是否可以把一些字段獨(dú)立出去，表垂直拆分。水平拆分表可以按時(shí)間，或者id的has值進(jìn)行拆分
4.分庫(kù)分表必然帶來(lái)很多問(wèn)題，比如關(guān)聯(lián)查詢，聚合等操作，可以嘗試下NewSQL，業(yè)務(wù)不再關(guān)心分庫(kù)分表操作了。國(guó)內(nèi)開源實(shí)現(xiàn)有TiDB，可以了解下，NewSQL應(yīng)該是未來(lái)的趨勢(shì)。
可以關(guān)注我，后面分享一些存儲(chǔ)方面的文章。
評(píng)論0
加載中...
不到萬(wàn)不得已，不要分庫(kù)分表。
數(shù)據(jù)庫(kù)遇到瓶頸，應(yīng)該首先考慮優(yōu)化。sql服務(wù)器硬件優(yōu)化，sql語(yǔ)句優(yōu)化，索引優(yōu)化，讀寫分離，緩存層。
如果都不行，那就只能考慮分庫(kù)分表了，可以利用mycat,DBProxy等中間件。
一旦分庫(kù)分表，就會(huì)引出分布式事物，應(yīng)該盡量避免。關(guān)聯(lián)查詢，聚合統(tǒng)計(jì)等操作等地方也有坑，一定要注意！
個(gè)人建議：一般到了分庫(kù)分表的地步，都是因?yàn)閿?shù)據(jù)量到了一定級(jí)別，單臺(tái)服務(wù)器無(wú)法承受。一般都是某幾張表或者某個(gè)庫(kù)數(shù)據(jù)量過(guò)大。與其費(fèi)力分庫(kù)分表，倒不如考慮一些新興的數(shù)據(jù)庫(kù)，例如HBase或者TiDB等newSQL甚至ES。如果這些大表，不涉及復(fù)雜，需要考慮事物的業(yè)務(wù)，完全可以頂上。
回答完畢，謝謝，希望對(duì)你有所幫助！！
本人專注互聯(lián)網(wǎng)前沿動(dòng)態(tài)，大數(shù)據(jù)，數(shù)據(jù)采集，數(shù)據(jù)處理，數(shù)據(jù)治理，望交流！
評(píng)論0
加載中...
0
回答0
回答1
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
