【轉載】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的方案,希望朋友有新的收獲和感觸,幫轉哈。
==【完】==
【轉自】58沈劍 架構師之路
【轉載】100億數據1萬屬性數據架構設計