當(dāng)業(yè)務(wù)規(guī)模達(dá)到?定規(guī)模之后，像淘寶?訂單量在5000萬(wàn)單以上，美團(tuán)3000萬(wàn)單以上。數(shù)據(jù)庫(kù)?對(duì)海量的數(shù)據(jù)壓?，分庫(kù)分表就是必須進(jìn)?的操作了。?分庫(kù)分表之后?些常規(guī)的查詢可能都會(huì)產(chǎn)?問(wèn)題，最常?的就是?如分?查詢的問(wèn)題。?般我們把分表的字段稱作shardingkey，?如訂單表按照?戶ID作為shardingkey，那么如果查詢條件中不帶?戶ID查詢?cè)趺醋龇?？??如更多的多維度的查詢都沒(méi)有shardingkey?怎么查詢？

唯?主鍵

?般我們數(shù)據(jù)庫(kù)的主鍵都是?增的，那么分表之后主鍵沖突的問(wèn)題就是?個(gè)?法避免的問(wèn)題，最簡(jiǎn)單的辦法就是以?個(gè)唯?的業(yè)務(wù)字段作為唯?的主鍵，?如訂單表的訂單號(hào)肯定是全局唯?的。常?的分布式?成唯?ID的?式很多，最常?的雪花算法Snowflake、滴滴Tinyid、美團(tuán)Leaf。以雪花算法舉例來(lái)說(shuō)，?毫秒可以?成4194304多個(gè)ID。第?位不使?，默認(rèn)都是0，41位時(shí)間戳精確到毫秒，可以容納69年的時(shí)間，10位?作機(jī)器ID?5位是數(shù)據(jù)中?ID，低5位是節(jié)點(diǎn)ID，12位序列號(hào)每個(gè)節(jié)點(diǎn)每毫秒累加，累計(jì)可以達(dá)到2^12 4096個(gè)ID。

分表

第?步，分表后要怎么保證訂單號(hào)的唯?搞定了，現(xiàn)在考慮下分表的問(wèn)題。?先根據(jù)?身的業(yè)務(wù)量和增量來(lái)考慮分表的??。舉個(gè)例?，現(xiàn)在我們?單量是10萬(wàn)單，預(yù)估?年后可以達(dá)到?100萬(wàn)單，根據(jù)業(yè)務(wù)屬性，?般我們就?持查詢半年內(nèi)的訂單，超過(guò)半年的訂單需要做歸檔處理。那么以?訂單100萬(wàn)半年的數(shù)量級(jí)來(lái)看，不分表的話我們訂單量將達(dá)到100萬(wàn)X180=1.8億，以這個(gè)數(shù)據(jù)量級(jí)部分表的話肯定單表是扛不住的，就算你能扛RT的時(shí)間你也根本?法接受吧。根據(jù)經(jīng)驗(yàn)單表?百萬(wàn)的數(shù)量對(duì)于數(shù)據(jù)庫(kù)是沒(méi)什么壓?的，那么只要分256張表就?夠了，1.8億/256≈70萬(wàn)，如果為了保險(xiǎn)起?，也可以分到512張表。那么考慮?下，如果業(yè)務(wù)量再增?10倍達(dá)到1000萬(wàn)單每天，分表1024就是?較合適的選擇。通過(guò)分表加上超過(guò)半年的數(shù)據(jù)歸檔之后，單表70萬(wàn)的數(shù)據(jù)就?以應(yīng)對(duì)?部分場(chǎng)景了。接下來(lái)對(duì)訂單號(hào)hash，然后對(duì)256取模的就可以落到具體的哪張表了。

那么，因?yàn)槲?主鍵都是以訂單號(hào)作為依據(jù)，以前你寫的那些根據(jù)主鍵ID做查詢的就不能?了，這就涉及到了歷史?些查詢功能的修改。不過(guò)這都不是事?對(duì)吧，都改成以訂單號(hào)來(lái)查就?了。這都不是問(wèn)題，問(wèn)題在我們的標(biāo)題說(shuō)的點(diǎn)上。

C端查詢

說(shuō)了半天，總算到了正題了，那么分表之后查詢和分?查詢的問(wèn)題怎么解決？?先說(shuō)帶shardingkey的查詢，?如就通過(guò)訂單號(hào)查詢，不管你分?還是怎么樣都是能直接定位到具體的表來(lái)查詢的，顯然查詢是不會(huì)有什么問(wèn)題的。如果不是shardingkey的話，上?舉例說(shuō)的以訂單號(hào)作為shardingkey的話，像APP、?程序這種?般都是通過(guò)?戶ID查詢，那這時(shí)候我們通過(guò)訂單號(hào)做的sharding怎么辦？很多公司訂單表直接??戶ID做shardingkey，那么很簡(jiǎn)單，直接查就完了。那么訂單號(hào)怎么辦，?個(gè)很簡(jiǎn)單的辦法就是在訂單號(hào)上帶上?戶ID的屬性。舉個(gè)很簡(jiǎn)單的例?，原本41位的時(shí)間戳你覺(jué)得?不完，?戶ID是10位的，訂單號(hào)的?成規(guī)則帶上?戶ID，落具體表的時(shí)候根據(jù)訂單號(hào)中10位?戶ID hash取模，這樣?論根據(jù)訂單號(hào)還是?戶ID查詢效果都是?樣的。

當(dāng)然，這種?式只是舉例，具體的訂單號(hào)?成的規(guī)則，多少位，包含哪些因素根據(jù)??的業(yè)務(wù)和實(shí)現(xiàn)機(jī)制來(lái)決定。

好，那么?論你是訂單號(hào)還是?戶ID作為shardingkey，按照以上的兩種?式都可以解決問(wèn)題了。那么還有?個(gè)問(wèn)題就是如果既不是訂單號(hào)?不是?戶ID查詢?cè)趺崔k？最直觀的例?就是來(lái)?商戶端或者后臺(tái)的查詢，商戶端都是以商戶或者說(shuō)賣家的ID作為查詢條件來(lái)查的，后臺(tái)的查詢條件可能就更復(fù)雜了，像我碰到的有些后臺(tái)查詢條件能有??個(gè)，這怎么查？？？別急，接下來(lái)分開(kāi)說(shuō)B端和后臺(tái)的復(fù)雜查詢。現(xiàn)實(shí)中真正的流量?頭都是來(lái)?于?戶端C端，所以本質(zhì)上解決了?戶端的問(wèn)題，這個(gè)問(wèn)題就解了?半，剩下來(lái)?商戶賣家端B端、后臺(tái)?持運(yùn)營(yíng)業(yè)務(wù)的查詢流量并不會(huì)很?，這個(gè)問(wèn)題就好解。

其他端查詢

針對(duì)B端的?shardingkey的查詢有兩個(gè)辦法解決。雙寫，雙寫就是下單的數(shù)據(jù)落兩份，C端和B端的各?保存?份，C端?你可以?單號(hào)、?戶ID做shardingkey都?，B端就?商家賣家的ID作為shardingkey就好了。有些同學(xué)會(huì)說(shuō)了，你雙寫不影響性能嗎？因?yàn)閷?duì)于B端來(lái)說(shuō)輕微的延遲是可以接受的，所以可以采取異步的?式去落B端訂單。你想想你去淘寶買個(gè)東?下單了，賣家稍微延遲個(gè)?兩秒收到這個(gè)訂單的消息有什么關(guān)系嗎？你點(diǎn)個(gè)外賣商戶晚?兩秒收到這個(gè)訂單有什么太?影響嗎？

這是?個(gè)解決?案，另外?個(gè)?案就是?離線數(shù)倉(cāng)或者ES查詢，訂單數(shù)據(jù)落庫(kù)之后，不管你通過(guò)binlog還是MQ消息的都形式，把數(shù)據(jù)同步到數(shù)倉(cāng)或者ES，他們?持的數(shù)量級(jí)對(duì)于這種查詢條件來(lái)說(shuō)就很簡(jiǎn)單了。同樣這種?式肯定是稍微有延遲的，但是這種可控范圍的延遲是可以接受的。

?針對(duì)管理后臺(tái)的查詢，?如運(yùn)營(yíng)、業(yè)務(wù)、產(chǎn)品需要看數(shù)據(jù)，他們天然需要復(fù)雜的查詢條件，同樣?ES或者數(shù)倉(cāng)都可以做得到。如果不?這個(gè)?案，?要不帶shardingkey的分?查詢，兄弟，這就只能掃全表查詢聚合數(shù)據(jù)，然后?動(dòng)做分?了，但是這樣查出來(lái)的結(jié)果是有限制的。?如你256個(gè)?，查詢的時(shí)候循環(huán)掃描所有的分?，每個(gè)?取20條數(shù)據(jù)，最后聚合數(shù)據(jù)??分?，那必然是不可能查到全量的數(shù)據(jù)的。

總結(jié)

分庫(kù)分表后的查詢問(wèn)題，對(duì)于有經(jīng)驗(yàn)的同學(xué)來(lái)說(shuō)其實(shí)這個(gè)問(wèn)題都知道，但是我相信其實(shí)?部分同學(xué)做的業(yè)務(wù)可能都沒(méi)來(lái)到這個(gè)數(shù)量級(jí)，分庫(kù)分表可能都停留在概念階段，?試被問(wèn)到后就???措了，因?yàn)闆](méi)有經(jīng)驗(yàn)不知道怎么辦。分庫(kù)分表?先是基于現(xiàn)有的業(yè)務(wù)量和未來(lái)的增量做出判斷，?如拼多多這種?單量5000萬(wàn)的，半年數(shù)據(jù)得有百億級(jí)別了，那都得分到4096張表了對(duì)吧，但是實(shí)際的操作是?樣的，對(duì)于你們的業(yè)務(wù)分4096那就沒(méi)有必要了，根據(jù)業(yè)務(wù)做出合理的選擇。對(duì)于基于shardingkey的查詢我們可以很簡(jiǎn)單的解決，對(duì)于?shardingkey的查詢可以通過(guò)落雙份數(shù)據(jù)和數(shù)倉(cāng)、ES的?案來(lái)解決，當(dāng)然，如果分表后數(shù)據(jù)量很?的話，建好索引，掃全表查詢其實(shí)也不是什么問(wèn)題。