上篇文章講解了傳統(tǒng)數(shù)據(jù)庫(kù)的一些設(shè)計(jì)注意點(diǎn)。
本篇為第二篇，在大數(shù)據(jù)量的情況下，如何去提前設(shè)計(jì)這個(gè)表結(jié)構(gòu)，來(lái)達(dá)到一個(gè)比較好的效果。對(duì)于團(tuán)隊(duì)，對(duì)于后續(xù)的維護(hù)和擴(kuò)展都帶來(lái)更大的便利。

自增id

自增id還是可以有，但是不是必須的了。但是建議還是每張表中有一個(gè)自增id。 為什么，還是那句話，做數(shù)據(jù)查詢，遷移，排序的時(shí)候，有著天然的一些優(yōu)勢(shì)。

唯一標(biāo)識(shí)

這個(gè)標(biāo)識(shí)無(wú)論是token，還是其他例如訂單的訂單號(hào)或者其他唯一標(biāo)識(shí)都行。 重點(diǎn)是唯一，不只是在單系統(tǒng)中唯一，而是需要在并發(fā)的情況，也能夠保持唯一。

關(guān)于分布式id的生成方案，網(wǎng)上已經(jīng)有很多了，這里就不重復(fù)了。谷歌搜索搜索，自己看下原理，跑跑demo，能夠滿足自己業(yè)務(wù)的最大并發(fā)情況下的唯一即可。

比如說(shuō)你未來(lái)幾年的最大并發(fā)也就是100，搞個(gè)能支持在幾千并發(fā)下不會(huì)出現(xiàn)標(biāo)識(shí)重復(fù)的實(shí)現(xiàn)方案即可，并發(fā)幾萬(wàn)，幾十萬(wàn)，真的需要嗎？

后續(xù)如果真的能夠達(dá)到幾萬(wàn)并發(fā)，那說(shuō)明什么？說(shuō)明業(yè)務(wù)火爆了啊。難道還抽不出時(shí)間，抽不出人來(lái)做一個(gè)id生成方案的改造？這里有比較重要的一點(diǎn)，不要太過超前設(shè)計(jì)，沒必要，也沒那個(gè)時(shí)間。

創(chuàng)建時(shí)間&修改時(shí)間

創(chuàng)建時(shí)間和修改時(shí)間還是要有的，而且建議時(shí)間精確到毫秒級(jí)別，在上一篇，我沒有說(shuō)精確多少，那是因?yàn)椴l(fā)不高，秒級(jí)完全夠了。但是在大數(shù)據(jù)量的情況下，可能一秒有幾十、幾百、上千、上萬(wàn)的數(shù)據(jù)新增都是有可能的。那么秒級(jí)在這種情況下完全就不夠看了，選擇毫秒級(jí)別是一個(gè)比較好的選擇。

分庫(kù)分表

前面的唯一標(biāo)識(shí)/創(chuàng)建時(shí)間可以說(shuō)就是為了這步準(zhǔn)備的。

但是怎么來(lái)設(shè)計(jì)分庫(kù)分表，選擇什么方式，范圍還是hash，選擇哪個(gè)字段，還是選擇幾個(gè)字段。平滑遷移還是停機(jī)遷移。

這些都沒有唯一答案。只能是根據(jù)場(chǎng)景來(lái)區(qū)分不同的情況。下面舉幾個(gè)例子來(lái)進(jìn)行一個(gè)講解，不是標(biāo)準(zhǔn)答案，同一個(gè)場(chǎng)景為了滿足不同的需求，也可能有不同的一個(gè)設(shè)計(jì)。

1：支付訂單的場(chǎng)景

例如，訂單每日新增千萬(wàn)級(jí)，那么在這個(gè)情況下。我們還需要區(qū)分一下。

1.1 訂單號(hào)包含了時(shí)間戳

那么強(qiáng)烈建議按照時(shí)間維度進(jìn)行分庫(kù)分表。 也強(qiáng)烈建議在訂單號(hào)中將時(shí)間戳放進(jìn)去。
優(yōu)點(diǎn)：

• 單表的大小是可以預(yù)知的，一天多少訂單量，一個(gè)月多少訂單量
  非常便于水平擴(kuò)展，后期如果想對(duì)整個(gè)分片集群擴(kuò)容時(shí)，只需要添加庫(kù)表即可，不需要對(duì)已經(jīng)存在的分片數(shù)據(jù)進(jìn)行遷移。使用訂單號(hào)進(jìn)行范圍查找時(shí)，可以快速定位查詢，避免了跨片查詢的問題。

缺點(diǎn)：

• 最近的訂單會(huì)存在著熱點(diǎn)數(shù)據(jù)，可以通過其他方式進(jìn)行解決，例如緩存等

1.2 訂單號(hào)不包含時(shí)間戳

不包含時(shí)間戳，你可以選擇創(chuàng)建時(shí)間來(lái)做范圍分片。 或者使用訂單號(hào)來(lái)做hash分片，也就是取模運(yùn)算分片。

hash分片的缺點(diǎn)就是后期擴(kuò)容會(huì)涉及到老數(shù)據(jù)的遷移，但是現(xiàn)在有一種方案可以避免該缺點(diǎn)，那就是使用虛節(jié)點(diǎn)，先占位，但不使用，需要的節(jié)點(diǎn)需要是2的次方個(gè)才行。大家可以去網(wǎng)上了解一下，這里就不展開了。 另外一個(gè)缺點(diǎn)就是跨片查詢的性能問題，當(dāng)查詢條件中沒有訂單號(hào)的時(shí)候，會(huì)無(wú)法定位到數(shù)據(jù)庫(kù)表，所以會(huì)遍歷所有的庫(kù)表，進(jìn)行查詢，再在內(nèi)存中合并數(shù)據(jù)，取最小集返回，在這種情況下，分庫(kù)分表反而會(huì)成為累贅。

其他一些分庫(kù)分表帶來(lái)的事務(wù)問題大家可以看看現(xiàn)在的一些分布式事務(wù)解決方案，都還挺不錯(cuò)的。阿里的Seata可以了解一下。

最后，分庫(kù)分表，并不是一定要分庫(kù)的，也可以只分表，這樣很多分庫(kù)分表的問題就不存在了。 分庫(kù)分表還是要跟進(jìn)實(shí)際的數(shù)據(jù)增長(zhǎng)速度來(lái)評(píng)估，比如說(shuō)，每年數(shù)據(jù)才幾十萬(wàn)或者百萬(wàn)，那么沒有必要進(jìn)行一個(gè)過渡設(shè)計(jì)，單表即可。等數(shù)據(jù)庫(kù)到了瓶頸，可以再考慮優(yōu)化。

很多時(shí)候，瓶頸也不一定是在數(shù)據(jù)庫(kù)。

性能優(yōu)化

在這里，對(duì)于性能優(yōu)化提一句，因?yàn)樽约阂矂偼瓿梢粋€(gè)性能優(yōu)化的需求不久，提升性能2倍左右。這次優(yōu)化完全沒有動(dòng)數(shù)據(jù)庫(kù)。 主要優(yōu)化點(diǎn)在：同步方法異步調(diào)用第三方服務(wù)、計(jì)算異步處理、批量單次調(diào)用、部分不變數(shù)據(jù)緩存 重點(diǎn)：拿資源（空間、線程）換時(shí)間

總結(jié)

當(dāng)數(shù)據(jù)量大了之后，其實(shí)很多設(shè)計(jì)和傳統(tǒng)的數(shù)據(jù)庫(kù)還是沒有很大變化的。

主要是要考慮到數(shù)據(jù)量大之后，該表如果分庫(kù)分表，那么怎么設(shè)計(jì)更加合理一點(diǎn)，也許當(dāng)下不需要分庫(kù)分表，但是可以給以后少埋點(diǎn)坑。

但是注意，還是那句話，不要過度設(shè)計(jì)，也不要不去設(shè)計(jì)。簡(jiǎn)單的說(shuō)，可以預(yù)估到以后的業(yè)務(wù)每日數(shù)據(jù)量新增是萬(wàn)級(jí)幾十萬(wàn)以上的，就可以考慮下以后的分表，但是當(dāng)期并不需要做。 但如果是日增百萬(wàn)千萬(wàn)級(jí)別，那么這個(gè)分庫(kù)分表肯定是當(dāng)期就需要進(jìn)行的。 假如是日增幾百幾千的表，那么就不要花過多時(shí)間去考慮什么分庫(kù)分表的方案了，真的用不上。

建議的一個(gè)提前思考時(shí)間，1年左右的思考維度設(shè)計(jì)比較好。即不會(huì)超前，也不會(huì)因?yàn)榈艘粌纱螛I(yè)務(wù)就有人提出，不知道哪個(gè)**設(shè)計(jì)的結(jié)構(gòu)，又得重新來(lái)設(shè)計(jì)。

最后，能夠在技術(shù)方案時(shí)就明確的事情，絕不留到寫代碼的時(shí)候再去明確！ 技術(shù)方案越清晰（注意：不是說(shuō)超前設(shè)計(jì)，這里面有個(gè)度，只可意會(huì)不可言傳），寫代碼越輕松，團(tuán)隊(duì)協(xié)作越流暢。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的设计大数据量表结构的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。