當業務規模達到一定規模之後,像淘寶日訂單量在5000萬單以上,美團3000萬單以上。資料庫面對海量的資料壓力,分庫分錶就是必須進行的操作了。而分庫分錶之後一些常規的查詢可能都會產生問題,最常見的就是例如分頁查詢的問題。一般我們把分錶的欄位稱為shardingkey,例如訂單表依照使用者ID作為shardingkey,那麼如果查詢條件中不帶使用者ID查詢怎麼做分頁?又例如更多的多維度的查詢都沒有shardingkey又怎麼查詢?
一般我們資料庫的主鍵都是自增的,那麼分錶之後主鍵衝突的問題就是一個無法避免的問題,最簡單的辦法就是以一個唯一的業務欄位作為唯一的主鍵,例如訂單表的訂單號碼肯定是全域唯一的。
常見的分散式產生唯一ID的方式很多,最常見的雪花演算法Snowflake、滴滴Tinyid、美團Leaf。以雪花演算法舉例來說,一毫秒可以產生4194304多個ID。
第一位不使用,預設都是0,41位元時間戳精確到毫秒,可以容納69年的時間,10位元工作機器ID高5位是資料中心ID,低5位是節點ID,12位元序號每個節點每毫秒累加,累計可以達到2^12 4096個ID。
第一步,分錶後要怎麼保證訂單號碼的唯一搞定了,現在考慮下分錶的問題。首先根據自身的業務量和增量來考慮分錶的大小。
舉個例子,現在我們日單量是10萬單,預估一年後可以達到日100萬單,根據業務屬性,一般我們就支持查詢半年內的訂單,超過半年的訂單需要做歸檔處理。
那麼以日訂單100萬半年的數量級來看,不分錶的話我們訂單量將達到100萬X180=1.8億,以這個數據量級部分錶的話肯定單表是扛不住的,就算你能扛RT的時間你也根本無法接受吧。根據經驗單表數百萬的數量對於資料庫是沒什麼壓力的,那麼只要分256張表就足夠了,1.8億/256≈70萬,如果為了保險起見,也可以分到512張表。那麼考慮一下,如果業務量再成長10倍達到1000萬單每天,分錶1024就是比較適合的選擇。
透過分錶加上超過半年的資料歸檔之後,單表70萬的資料就足以應付大部分場景了。接下來對訂單號碼hash,然後對256取模的就可以落到具體的哪張表了。
那麼,因為唯一主鍵都是以訂單號碼作為依據,以前你寫的那些根據主鍵ID做查詢的就不能用了,這就涉及到了歷史一些查詢功能的修改。不過這都不是事兒對吧,都改成以訂單號碼來查就行了。這都不是問題,問題在我們的標題說的點上。
說了半天,總算到了正題了,那麼分錶之後查詢和分頁查詢的問題怎麼解決?
首先說帶shardingkey的查詢,比如就透過訂單號查詢,不管你分頁還是怎麼樣都是能直接定位到具體的表來查詢的,顯然查詢是不會有什麼問題的。
如果不是shardingkey的話,上面舉例說的以訂單號碼作為shardingkey的話,像APP、小程式這種一般都是透過使用者ID查詢,那這時候我們透過訂單號碼做的sharding怎麼辦?很多公司訂單表直接用用戶ID做shardingkey,那麼很簡單,直接查就完了。那麼訂單號碼怎麼辦,一個很簡單的方法就是在訂單號碼上帶上用戶ID的屬性。舉個很簡單的例子,原本41位的時間戳你覺得用不完,用戶ID是10位的,訂單號的生成規則帶上用戶ID,落具體表的時候根據訂單號中10位用戶ID hash取模,這樣無論根據訂單號碼或用戶ID查詢效果都是一樣的。
當然,這種方式只是舉例,具體的訂單號碼產生的規則,多少位,包含哪些因素根據自己的業務和實現機制來決定。
#好,那麼無論你是訂單號碼還是用戶ID作為shardingkey,按照以上的兩種方式都可以解決問題了。那麼還有一個問題就是如果既不是訂單號碼又不是使用者ID查詢呢?最直觀的例子就是來自商家端或後台的查詢,商家端都是以商家或說賣家的ID作為查詢條件來查的,後台的查詢條件可能就更複雜了,像我碰到的有些後台查詢條件能有幾十個,怎麼查? ? ?別急,接下來分開說B端和後台的複雜查詢。
現實中真正的流量大頭都是來自於用戶端C端,所以本質上解決了用戶端的問題,這個問題就解了大半,剩下來自商家賣家端B端、後台支援營運業務的查詢流量並不會很大,這個問題就好解。
針對B端的非shardingkey的查詢有兩個辦法可以解決。
雙寫,雙寫就是下單的資料落兩份,C端和B端的各自保存一份,C端用你可以用單號、用戶ID做shardingkey都行,B端就用商家賣家的ID當shardingkey就好了。有些同學會說了,你雙寫不影響表現嗎?因為對於B端來說輕微的延遲是可以接受的,所以可以採取非同步的方式去落B端訂單。你想想你去淘寶買東西下單了,賣家稍微延遲個一兩秒收到這個訂單的消息有什麼關係嗎?你點個外送商戶晚一兩秒收到這個訂單有太大影響嗎?
這是一個解決方案,另外一個方案就是走離線數倉或ES查詢,訂單資料落庫之後,不管你透過binlog還是MQ訊息的都形式,把資料同步到數倉或ES,他們支援的數量級對於這種查詢條件來說就很簡單了。同樣這種方式肯定是稍微有延遲的,但是這種可控範圍的延遲是可以接受的。
而針對管理後台的查詢,例如營運、業務、產品需要看數據,他們天然需要複雜的查詢條件,同樣走ES或數倉都可以做得到。如果不用這個方案,又要不帶shardingkey的分頁查詢,兄弟,這就只能掃全表查詢聚合數據,然後手動做分頁了,但是這樣查出來的結果是有限制的。
例如你256個片,查詢的時候循環掃描所有的分片,每個片取20條數據,最後聚合數據手工分頁,那必然是不可能查到全量的數據的。
分庫分錶後的查詢問題,對於有經驗的同學來說其實這個問題都知道,但是我相信其實大部分同學做的業務可能都沒來到這個數量級,分庫分錶可能都停留在概念階段,面試被問到後就手足無措了,因為沒有經驗不知道怎麼辦。
分庫分錶首先是基於現有的業務量和未來的增量做出判斷,比如拼多多這種日單量5000萬的,半年數據得有百億級別了,那都得分到4096張表了對吧,但是實際的操作是一樣的,對於你們的業務分4096那就沒有必要了,根據業務做出合理的選擇。
對於基於shardingkey的查詢我們可以很簡單的解決,對於非shardingkey的查詢可以透過落雙份資料和數倉、ES的方案來解決,當然,如果分錶後資料量很小的話,建好索引,掃表查詢其實也不是什麼問題。
相關免費學習推薦:mysql影片教學
以上是了解百億級資料分錶後的 分頁查詢的詳細內容。更多資訊請關注PHP中文網其他相關文章!