100億資料1萬屬性資料架構設計
一分鐘系列之《啥,又要為表增加一列屬性?》分享了兩種資料庫屬性擴充套件思路,被噴得厲害。第二天補充了一篇《這才是真正的表擴充套件方案》,分享了網際網路大資料高併發情況下,資料庫屬性擴容的成熟工具及思路。
對於version + ext方案,還是有很多朋友質疑“線上不可能這麼用”。本篇將講述一下58同城最核心的資料“帖子”的架構實現技術細節,說明不僅不是“不可能這麼用”,而是大資料,可變屬性,高吞吐場景下的“常用手段”。
一、背景描述及業務介紹
問:什麼是資料庫擴充套件的version + ext方案?
使用ext來承載不同業務需求的個性化屬性,使用version來標識ext裡各個欄位的含義。
例如上述user表:
verion=0表示ext裡是passwd/nick
version=1表示ext裡是passwd/nick/age/sex
優點?
(1)可以隨時動態擴充套件屬性,擴充套件性好
(2)新舊兩種資料可以同時存在,相容性好
不足?
(1)ext裡的欄位無法建立索引
(2)ext裡的key值有大量冗餘,建議key短一些
問:什麼是58同城最核心的資料?
58同城是一個資訊平臺,有很多垂直品類:招聘、房產、二手物品、二手車、黃頁等等,每個品類又有很多子品類,不管哪個品類,最核心的資料都是“帖子資訊”(業務像一個大論壇?)。
問:帖子資訊有什麼特點?
大家去58同城的首頁上看看就知道了:
(1)每個品類的屬性千差萬別,招聘帖子和二手帖子屬性完全不同,二手手機和二手家電的屬性又完全不同,目前恐怕有近萬個屬性
(2)帖子量很大,100億級別
(3)每個屬性上都有查詢需求(各組合屬性上都可能有組合查詢需求),招聘要查職位/經驗/薪酬範圍,二手手機要查顏色/價格/型號,二手要查冰箱/洗衣機/空調
(4)查詢量很大,每秒幾10萬級別
如何解決100億資料量,1萬屬性,多屬性組合查詢,10萬併發查詢的技術難題,是今天要討論的內容。
二、最容易想到的方案
每個公司的發展都是一個從小到大的過程,撇開併發量和資料量不談,先看看
(1)如何實現屬性擴充套件性需求
(2)多屬性組合查詢需求
最開始,可能只有一個招聘品類,那帖子表可能是這麼設計的:
tiezi(tid,uid, c1, c2, c3)
那如何滿足各屬性之間的組合查詢需求呢?
最容易想到的是通過組合索引:
index_1(c1,c2) index_2(c2, c3) index_3(c1, c3)
隨著業務的發展,又新增了一個房產類別,新增了若干屬性,新增了若干組合查詢,於是帖子表變成了:
tiezi(tid,uid, c1, c2, c3, c10, c11, c12, c13)
其中c1,c2,c3是招聘類別屬性,c10,c11,c12,c13是房產類別屬性,這兩塊屬性一般沒有組合查詢需求
但為了滿足房產類別的查詢需求,又要建立了若干組合索引(不敢想有多少個索引能覆蓋所有兩屬性查詢,三屬性查詢)
是不是發現玩不下去了?
三、友商的玩法
新增屬性是一種擴充套件方式,新增表也是一種方式,有友商是這麼玩的,按照業務進行垂直拆分:
tiezi_zhaopin(tid,uid, c1, c2, c3)
tiezi_fangchan(tid,uid, c10, c11, c12, c13)
這些表,這些服務維護在不同的部門,不同的研發同學手裡,看上去各業務線靈活性強,這恰恰是悲劇的開始:
(1)tid如何規範?
(2)屬性如何規範?
(3)按照uid來查詢怎麼辦(查詢自己釋出的所有帖子)?
(4)按照時間來查詢怎麼辦(最新發布的帖子)?
(5)跨品類查詢怎麼辦(例如首頁搜尋框)?
(6)技術範圍的擴散,有的用mongo儲存,有的用mysql儲存,有的自研儲存
(7)重複開發了不少元件
(8)維護成本過高
(9)…
想想看,電商的商品表,不可能一個類目一個表的。
四、58同城的玩法
【統一帖子中心服務】
平臺型創業型公司,可能有多個品類,例如58同城的招聘房產二手,很多異構資料的儲存需求,到底是分還是合,無需糾結:基礎資料基礎服務的統一,無疑是58同城技術路線發展roadmap上最正確的決策之一,把這個方針堅持下來,@老崔 @曉飛 這些高瞻遠矚的先賢功不可沒,業務線會有“擴充套件性”“靈活性”上的微詞,後文看看先賢們如何通過一些巧妙的技術方案來解決的。
如何將不同品類,異構的資料統一儲存起來,採用的就是類似version+ext的方式:
tiezi(tid,uid, time, title, cate, subcate, xxid, ext)
(1)一些通用的欄位抽取出來單獨儲存
(2)通過cate, subcate, xxid等來定義ext是何種含義(和version有點像?)
(3)通過ext來儲存不同業務線的個性化需求
例如招聘的帖子:
ext : {“job”:”driver”,”salary”:8000,”location”:”bj”}
而二手的帖子:
ext : {”type”:”iphone”,”money”:3500}
58同城最核心的帖子資料,100億的資料量,分256庫,異構資料mysql儲存,上層架了一個服務,使用memcache做快取,就是這樣一個簡單的架構,一直堅持這這麼多年。上層的這個服務,就是58同城最核心的統一服務IMC(Imformation Management Center),注意這個最核心,是沒有之一。
解決了海量異構資料的儲存問題,遇到的新問題是:
(1)每條記錄ext內key都需要重複儲存,佔據了大量的空間,能否壓縮儲存
(2)cateid已經不足以描述ext內的內容,品類有層級,深度不確定,ext能否具備自描述性
(3)隨時可以增加屬性,保證擴充套件性
【統一類目屬性服務】
每個業務有多少屬性,這些屬性是什麼含義,值的約束等揉不到帖子服務裡,怎麼辦呢?
58同城的先賢們抽象出一個統一的類目、屬性服務,單獨來管理這些資訊,而帖子庫ext欄位裡json的key,統一由數字來表示,減少儲存空間。
如上圖所示,json裡的key不再是”salary” ”location” ”money” 這樣的長字串了,取而代之的是數字1,2,3,4,這些數字是什麼含義,屬於哪個子分類,值的校驗約束,統一都儲存在類目、屬性服務裡。
這個表裡對帖子中心服務裡ext欄位裡的數字key進行了解釋:
1代表job,屬於招聘品類下100子品類,其value必須是一個小於32的[a-z]字元
4代表type,屬於二手品類下200子品類,其value必須是一個short
這樣就對原來帖子表ext裡的
ext : {“1”:”driver”,”2”:8000,”3”:”bj”}
ext : {”4”:”iphone”,”5”:3500}
key和value都做了統一約束。
除此之外,如果ext裡某個key的value不是正則校驗的值,而是列舉值時,需要有一個對值進行限定的列舉表來進行校驗:
這個列舉校驗,說明key=4的屬性(對應屬性表裡二手,手機型別欄位),其值不只是要進行“short型別”校驗,而是value必須是固定的列舉值。
ext : {”4”:”iphone”,”5”:3500}這個ext就是不合法的(key=4的value=iphone不合法),合法的應該為
ext : {”4”:”5”,”5”:3500}
此外,類目屬性服務還能記錄類目之間的層級關係:
(1)一級類目是招聘、房產、二手…
(2)二手下有二級類目二手傢俱、二手手機…
(3)二手手機下有三級類目二手iphone,二手小米,二手三星…
(4)…
協助解釋58同城最核心的帖子資料,描述品類層級關係,保證各類目屬性擴充套件性,保證各屬性值合理性校驗,就是58同城另一個統一的核心服務CMC(Category Management Center)。
多提一句,類目、屬性服務像不像電商系統裡的SKU擴充套件服務?
(1)品類層級關係,對應電商裡的類別層級體系
(2)屬性擴充套件,對應電商裡各類別商品SKU的屬性
(3)列舉值校驗,對應屬性的列舉值,例如顏色:紅,黃,藍
解決了key壓縮,key描述,key擴充套件,value校驗,品類層級的問題,還有這樣的一個問題沒有解決:每個品類下帖子的屬性各不相同,查詢需求各不相同,如何解決100億資料量,1萬屬性的查詢需求,是58同城面臨的新問題。
【統一檢索服務】
資料量很大的時候,不同屬性上的查詢需求,不可能通過組合索引來滿足所有查詢需求,怎麼辦呢?
58同城的先賢們,從一早就確定了“外接索引,統一檢索服務”的技術路線:
(1)資料庫提供“帖子id”的正排查詢需求
(2)所有非“帖子id”的個性化檢索需求,統一走外接索引
後設資料與索引資料的操作遵循:
(1)對帖子進行tid正排查詢,直接訪問帖子服務
(2)對帖子進行修改,帖子服務通知檢索服務,同時對索引進行修改
(3)對帖子進行復雜查詢,通過檢索服務滿足需求
這個扛起58同城80%終端請求(不管來自PC還是APP,不管是主頁、城市頁、分類頁、列表頁、詳情頁,很可能這個請求最終會是一個檢索請求)的服務,就是58同城另一個統一的核心服務E-search,這個搜尋引擎的每一行程式碼都來自58同城@老崔 @老龔 等先賢們,目前系統維護者,就是“架構師之路”裡屢次提到的@龍神 。
對於這個服務的架構,簡單展開說明一下:
為應對100億級別資料量、幾十萬級別的吞吐量,業務線各種複雜的複雜檢索查詢,擴充套件性是設計重點:
(1)統一的Java代理層叢集,其無狀態效能夠保證增加機器就能擴充系統效能
(2)統一的合併層C服務叢集,其無狀態性也能夠保證增加機器就能擴充系統效能
(3)搜尋核心檢索層C服務叢集,服務和索引資料部署在同一臺機器上,服務啟動時可以載入索引資料到記憶體,請求訪問時從記憶體中load資料,訪問速度很快
(3.1)為了滿足資料容量的擴充套件性,索引資料進行了水平切分,增加切分份數,就能夠無限擴充套件效能
(3.2)為了滿足一份資料的效能擴充套件性,同一份資料進行了冗餘,理論上做到增加機器就無限擴充套件效能
系統時延,100億級別帖子檢索,包含請求分合,拉鍊求交集,從merger層均可以做到10ms返回。
58同城的帖子業務,一致性不是主要矛盾,E-search會定期全量重建索引,以保證即使資料不一致,也不會持續很長的時間。
五、總結
文章寫了很長,最後做一個簡單總結,面對100億資料量,1萬列屬性,10萬吞吐量的業務需求,58同城的經驗,是採用了後設資料服務、屬性服務、搜尋服務來解決的。
再回到文首version + ext的方案,希望朋友有新的收穫和感觸,幫轉哈。
相關文章
- 1萬屬性,100億資料,每秒10萬吞吐,架構如何設計?架構
- 資料脫敏大資料架構設計大資料架構
- 使用者中心,1億資料,架構如何設計?架構
- 架構設計之資料分片架構
- 主流資料庫架構設計資料庫架構
- 資料庫設計---即資料庫架構設計的幾個步驟資料庫架構
- 大資料平臺架構設計探究大資料架構
- 資料倉儲架構分層設計架構
- 架構設計(二):資料庫複製架構資料庫
- 網際網路資料庫架構設計資料庫架構
- 企業級大資料架構設計【2】大資料架構
- 資料密集型系統架構設計架構
- App架構設計經驗談:資料層的設計APP架構
- 資料中臺:資料服務的架構設計實踐架構
- 圖資料庫 Nebula Graph 的資料模型和系統架構設計資料庫模型架構
- 【虹科乾貨】Lambda資料架構和Kappa資料架構——構建現代資料架構架構APP
- 按照業務領域畫資料架構圖 業務架構 資料架構架構
- 系統架構設計筆記(97)—— 資料包架構筆記
- 架構之:資料流架構架構
- 資料庫架構和物件、定義資料完整性-SQL Server資料庫架構物件SQLServer
- 架構師日記-從資料庫發展歷程到資料結構設計探析架構資料庫資料結構
- 多層結構下分散式資料庫資料容災概要性設計分散式資料庫
- 讀資料工程之道:設計和構建健壯的資料系統07資料架構的原則架構
- 資料架構建設方法及案例架構
- Unity應用架構設計(6)——設計動態資料集合ObservableListUnity應用架構
- 資料湖+資料倉儲 = 資料湖庫架構架構
- 金融級分散式資料庫架構設計要點分散式資料庫架構
- orientDB學習筆記(三)資料庫 構架設計筆記資料庫
- 架構設計、區塊鏈、人工智慧、大資料架構區塊鏈人工智慧大資料
- 怎樣的架構設計才是真正的資料倉儲架構(轉載)架構
- 資料治理實踐:後設資料管理架構的演變架構
- 遊戲開發架構中的資料與後設資料遊戲開發架構
- 訂單中心,1億資料架構,這次服了架構
- .NET併發程式設計-資料結構不可變性程式設計資料結構
- 雲端計算時代,資料庫架構設計有哪些改變?資料庫架構
- 資料管理架構:單體資料架構與分散式資料網格比較 - enyo架構分散式
- 讀資料湖倉04資料架構與資料工程架構
- 大資料架構師大資料架構