100億數(shù)據(jù)1萬屬性數(shù)據(jù)架構設計

作者：58沈劍 2017-01-19 18:20:59

本篇將講述一下58同城最核心的數(shù)據(jù)“帖子”的架構實現(xiàn)技術細節(jié)，說明不僅不是“不可能這么用”，而是大數(shù)據(jù)，可變屬性，高吞吐場景下的“常用手段”。

一分鐘系列之《啥，又要為表增加一列屬性?》分享了兩種數(shù)據(jù)庫屬性擴展思路，被噴得厲害。第二天補充了一篇《這才是真正的表擴展方案》，分享了互聯(lián)網大數(shù)據(jù)高并發(fā)情況下，數(shù)據(jù)庫屬性擴容的成熟工具及思路。

對于version + ext方案，還是有很多朋友質疑“線上不可能這么用”。本篇將講述一下58同城最核心的數(shù)據(jù)“帖子”的架構實現(xiàn)技術細節(jié)，說明不僅不是“不可能這么用”，而是大數(shù)據(jù)，可變屬性，高吞吐場景下的“常用手段”。

一、背景描述及業(yè)務介紹

問：什么是數(shù)據(jù)庫擴展的version + ext方案?

使用ext來承載不同業(yè)務需求的個性化屬性，使用version來標識ext里各個字段的含義。

例如上述user表：

verion=0表示ext里是passwd/nick

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

優(yōu)點

(1)可以隨時動態(tài)擴展屬性，擴展性好

(2)新舊兩種數(shù)據(jù)可以同時存在，兼容性好

不足

(1)ext里的字段無法建立索引

(2)ext里的key值有大量冗余，建議key短一些

問：什么是58同城最核心的數(shù)據(jù)?

58同城是一個信息平臺，有很多垂直品類：招聘、房產、二手物品、二手車、黃頁等等，每個品類又有很多子品類，不管哪個品類，最核心的數(shù)據(jù)都是“帖子信息”(業(yè)務像一個大論壇?)。

問：帖子信息有什么特點?

大家去58同城的首頁上看看就知道了：

(1)每個品類的屬性千差萬別，招聘帖子和二手帖子屬性完全不同，二手手機和二手家電的屬性又完全不同，目前恐怕有近萬個屬性

(2)帖子量很大，100億級別

(3)每個屬性上都有查詢需求(各組合屬性上都可能有組合查詢需求)，招聘要查職位/經驗/薪酬范圍，二手手機要查顏色/價格/型號，二手要查冰箱/洗衣機/空調

(4)查詢量很大，每秒幾10萬級別

如何解決100億數(shù)據(jù)量，1萬屬性，多屬性組合查詢，10萬并發(fā)查詢的技術難題，是今天要討論的內容。

二、最容易想到的方案

每個公司的發(fā)展都是一個從小到大的過程，撇開并發(fā)量和數(shù)據(jù)量不談，先看看

(1)如何實現(xiàn)屬性擴展性需求

(2)多屬性組合查詢需求

最開始，可能只有一個招聘品類，那帖子表可能是這么設計的：

tiezi(tid,uid, c1, c2, c3)

那如何滿足各屬性之間的組合查詢需求呢?

最容易想到的是通過組合索引：

index_1(c1,c2) index_2(c2, c3) index_3(c1, c3)

隨著業(yè)務的發(fā)展，又新增了一個房產類別，新增了若干屬性，新增了若干組合查詢，于是帖子表變成了：

tiezi(tid,uid, c1, c2, c3, c10, c11, c12, c13)

其中c1,c2,c3是招聘類別屬性，c10,c11,c12,c13是房產類別屬性，這兩塊屬性一般沒有組合查詢需求

但為了滿足房產類別的查詢需求，又要建立了若干組合索引(不敢想有多少個索引能覆蓋所有兩屬性查詢，三屬性查詢)

是不是發(fā)現(xiàn)玩不下去了?

三、友商的玩法

新增屬性是一種擴展方式，新增表也是一種方式，有友商是這么玩的，按照業(yè)務進行垂直拆分：

tiezi_zhaopin(tid,uid, c1, c2, c3) 
tiezi_fangchan(tid,uid, c10, c11, c12, c13)

這些表，這些服務維護在不同的部門，不同的研發(fā)同學手里，看上去各業(yè)務線靈活性強，這恰恰是悲劇的開始：

(1)tid如何規(guī)范?

(2)屬性如何規(guī)范?

(3)按照uid來查詢怎么辦(查詢自己發(fā)布的所有帖子)?

(4)按照時間來查詢怎么辦(最新發(fā)布的帖子)?

(5)跨品類查詢怎么辦(例如首頁搜索框)?

(6)技術范圍的擴散，有的用mongo存儲，有的用mysql存儲，有的自研存儲

(7)重復開發(fā)了不少組件

(8)維護成本過高

(9)…

想想看，電商的商品表，不可能一個類目一個表的。

四、58同城的玩法

【統(tǒng)一帖子中心服務】

平臺型創(chuàng)業(yè)型公司，可能有多個品類，例如58同城的招聘房產二手，很多異構數(shù)據(jù)的存儲需求，到底是分還是合，無需糾結：基礎數(shù)據(jù)基礎服務的統(tǒng)一，無疑是58同城技術路線發(fā)展roadmap上最正確的決策之一，把這個方針堅持下來，@老崔 @曉飛這些高瞻遠矚的先賢功不可沒，業(yè)務線會有“擴展性”“靈活性”上的微詞，后文看看先賢們如何通過一些巧妙的技術方案來解決的。

如何將不同品類，異構的數(shù)據(jù)統(tǒng)一存儲起來，采用的就是類似version+ext的方式：

tiezi(tid,uid, time, title, cate, subcate, xxid, ext)

(1)一些通用的字段抽取出來單獨存儲

(2)通過cate, subcate, xxid等來定義ext是何種含義(和version有點像?)

(3)通過ext來存儲不同業(yè)務線的個性化需求

例如招聘的帖子：

ext : {“job”:”driver”,”salary”:8000,”location”:”bj”}

而二手的帖子：

ext : {”type”:”iphone”,”money”:3500}

58同城最核心的帖子數(shù)據(jù)，100億的數(shù)據(jù)量，分256庫，異構數(shù)據(jù)mysql存儲，上層架了一個服務，使用memcache做緩存，就是這樣一個簡單的架構，一直堅持這這么多年。上層的這個服務，就是58同城最核心的統(tǒng)一服務IMC(Imformation Management Center)，注意這個最核心，是沒有之一。

解決了海量異構數(shù)據(jù)的存儲問題，遇到的新問題是：

(1)每條記錄ext內key都需要重復存儲，占據(jù)了大量的空間，能否壓縮存儲

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

(3)隨時可以增加屬性，保證擴展性

【統(tǒng)一類目屬性服務】

每個業(yè)務有多少屬性，這些屬性是什么含義，值的約束等揉不到帖子服務里，怎么辦呢?

58同城的先賢們抽象出一個統(tǒng)一的類目、屬性服務，單獨來管理這些信息，而帖子庫ext字段里json的key，統(tǒng)一由數(shù)字來表示，減少存儲空間。

如上圖所示，json里的key不再是”salary” ”location” ”money” 這樣的長字符串了，取而代之的是數(shù)字1,2,3,4，這些數(shù)字是什么含義，屬于哪個子分類，值的校驗約束，統(tǒng)一都存儲在類目、屬性服務里。

這個表里對帖子中心服務里ext字段里的數(shù)字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都做了統(tǒng)一約束。

除此之外，如果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)…

協(xié)助解釋58同城最核心的帖子數(shù)據(jù)，描述品類層級關系，保證各類目屬性擴展性，保證各屬性值合理性校驗，就是58同城另一個統(tǒng)一的核心服務CMC(Category Management Center)。

多提一句，類目、屬性服務像不像電商系統(tǒng)里的SKU擴展服務?

(1)品類層級關系，對應電商里的類別層級體系

(2)屬性擴展，對應電商里各類別商品SKU的屬性

(3)枚舉值校驗，對應屬性的枚舉值，例如顏色：紅，黃，藍

解決了key壓縮，key描述，key擴展，value校驗，品類層級的問題，還有這樣的一個問題沒有解決：每個品類下帖子的屬性各不相同，查詢需求各不相同，如何解決100億數(shù)據(jù)量，1萬屬性的查詢需求，是58同城面臨的新問題。

【統(tǒng)一檢索服務】

數(shù)據(jù)量很大的時候，不同屬性上的查詢需求，不可能通過組合索引來滿足所有查詢需求，怎么辦呢?

58同城的先賢們，從一早就確定了“外置索引，統(tǒng)一檢索服務”的技術路線：

(1)數(shù)據(jù)庫提供“帖子id”的正排查詢需求

(2)所有非“帖子id”的個性化檢索需求，統(tǒng)一走外置索引

元數(shù)據(jù)與索引數(shù)據(jù)的操作遵循：

(1)對帖子進行tid正排查詢，直接訪問帖子服務

(2)對帖子進行修改，帖子服務通知檢索服務，同時對索引進行修改

(3)對帖子進行復雜查詢，通過檢索服務滿足需求

這個扛起58同城80%終端請求(不管來自PC還是APP，不管是主頁、城市頁、分類頁、列表頁、詳情頁，很可能這個請求最終會是一個檢索請求)的服務，就是58同城另一個統(tǒng)一的核心服務E-search，這個搜索引擎的每一行代碼都來自58同城@老崔 @老龔等先賢們，目前系統(tǒng)維護者，就是“架構師之路”里屢次提到的@龍神。

對于這個服務的架構，簡單展開說明一下：