100億資料1萬屬性資料架構設計

hai0808發表於2017-10-27

一分鐘系列之《啥,又要為表增加一列屬性?》分享了兩種資料庫屬性擴充套件思路,被噴得厲害。第二天補充了一篇《這才是真正的表擴充套件方案》,分享了網際網路大資料高併發情況下,資料庫屬性擴容的成熟工具及思路。

 

對於version + ext方案,還是有很多朋友質疑“線上不可能這麼用”。本篇將講述一下58同城最核心的資料“帖子”的架構實現技術細節,說明不僅不是“不可能這麼用”,而是大資料,可變屬性,高吞吐場景下的“常用手段”。

 

一、背景描述及業務介紹

問:什麼是資料庫擴充套件的version + ext方案?

使用ext來承載不同業務需求的個性化屬性,使用version來標識ext裡各個欄位的含義


例如上述user表:

verion=0表示ext裡是passwd/nick

version=1表示ext裡是passwd/nick/age/sex

 

優點?

1)可以隨時動態擴充套件屬性,擴充套件性好

2)新舊兩種資料可以同時存在,相容性好

不足?

1ext裡的欄位無法建立索引

2ext裡的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)

這些表,這些服務維護在不同的部門,不同的研發同學手裡,看上去各業務線靈活性強,這恰恰是悲劇的開始

1tid如何規範?

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同城最核心的統一服務IMCImformation Management Center,注意這個最核心,是沒有之一。

 

解決了海量異構資料的儲存問題,遇到的新問題是:

1)每條記錄extkey都需要重複儲存,佔據了大量的空間,能否壓縮儲存

2cateid已經不足以描述ext內的內容,品類有層級,深度不確定,ext能否具備自描述性

3)隨時可以增加屬性,保證擴充套件性

 

【統一類目屬性服務】

每個業務有多少屬性,這些屬性是什麼含義,值的約束等揉不到帖子服務裡,怎麼辦呢?

58同城的先賢們抽象出一個統一的類目、屬性服務,單獨來管理這些資訊,而帖子庫ext欄位裡jsonkey,統一由數字來表示,減少儲存空間


如上圖所示,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}

keyvalue都做了統一約束

 

除此之外,如果ext裡某個keyvalue不是正則校驗的值,而是列舉值時,需要有一個對值進行限定的列舉表來進行校驗


這個列舉校驗,說明key=4的屬性(對應屬性表裡二手,手機型別欄位),其值不只是要進行“short型別”校驗,而是value必須是固定的列舉值。

ext : {”4”:”iphone”,”5”:3500}這個ext就是不合法的(key=4value=iphone不合法),合法的應該為

ext : {”4”:”5”,”5”:3500}

 

此外,類目屬性服務還能記錄類目之間的層級關係:

1)一級類目是招聘、房產、二手

2)二手下有二級類目二手傢俱、二手手機

3)二手手機下有三級類目二手iphone,二手小米,二手三星

4

 


協助解釋58同城最核心的帖子資料,描述品類層級關係,保證各類目屬性擴充套件性,保證各屬性值合理性校驗,就是58同城另一個統一的核心服務CMCCategory 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的方案,希望朋友有新的收穫和感觸,幫轉哈。

相關文章