100億數(shù)據(jù)1萬(wàn)屬性數(shù)據(jù)架構(gòu)設(shè)計(jì)

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

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

---

問(wèn)：什么是數(shù)據(jù)庫(kù)擴(kuò)展的version + ext方案？

使用ext來(lái)承載不同業(yè)務(wù)需求的個(gè)性化屬性，使用version來(lái)標(biāo)識(shí)ext里各個(gè)字段的含義。

例如上述user表：

verion=0表示ext里是passwd/nick

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

優(yōu)點(diǎn)？

（1）可以隨時(shí)動(dòng)態(tài)擴(kuò)展屬性，擴(kuò)展性好

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

不足？

（1）ext里的字段無(wú)法建立索引

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

問(wèn)：什么是58同城最核心的數(shù)據(jù)？

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

問(wèn)：帖子信息有什么特點(diǎn)？

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

（1）每個(gè)品類(lèi)的屬性千差萬(wàn)別，招聘帖子和二手帖子屬性完全不同，二手手機(jī)和二手家電的屬性又完全不同，目前恐怕有近萬(wàn)個(gè)屬性

（2）帖子量很大，100億級(jí)別

（3）每個(gè)屬性上都有查詢(xún)需求（各組合屬性上都可能有組合查詢(xún)需求），招聘要查職位/經(jīng)驗(yàn)/薪酬范圍，二手手機(jī)要查顏色/價(jià)格/型號(hào)，二手要查冰箱/洗衣機(jī)/空調(diào)

（4）查詢(xún)量很大，每秒幾10萬(wàn)級(jí)別

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

二、最容易想到的方案

---

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

（1）如何實(shí)現(xiàn)屬性擴(kuò)展性需求

（2）多屬性組合查詢(xún)需求

最開(kāi)始，可能只有一個(gè)招聘品類(lèi)，那帖子表可能是這么設(shè)計(jì)的：

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

那如何滿(mǎn)足各屬性之間的組合查詢(xún)需求呢？

最容易想到的是通過(guò)組合索引：

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

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

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

其中c1,c2,c3是招聘類(lèi)別屬性，c10,c11,c12,c13是房產(chǎn)類(lèi)別屬性，這兩塊屬性一般沒(méi)有組合查詢(xún)需求

但為了滿(mǎn)足房產(chǎn)類(lèi)別的查詢(xún)需求，又要建立了若干組合索引（不敢想有多少個(gè)索引能覆蓋所有兩屬性查詢(xún)，三屬性查詢(xún)）

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

三、友商的玩法

---

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

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

tiezi_fangchan(tid,uid, c10, c11, c12, c13)

這些表，這些服務(wù)維護(hù)在不同的部門(mén)，不同的研發(fā)同學(xué)手里，看上去各業(yè)務(wù)線靈活性強(qiáng)，這恰恰是悲劇的開(kāi)始：

（1）tid如何規(guī)范？

（2）屬性如何規(guī)范？

（3）按照uid來(lái)查詢(xún)?cè)趺崔k（查詢(xún)自己發(fā)布的所有帖子）？

（4）按照時(shí)間來(lái)查詢(xún)?cè)趺崔k（最新發(fā)布的帖子）？

（5）跨品類(lèi)查詢(xún)?cè)趺崔k（例如首頁(yè)搜索框）？

（6）技術(shù)范圍的擴(kuò)散，有的用mongo存儲(chǔ)，有的用mysql存儲(chǔ)，有的自研存儲(chǔ)

（7）重復(fù)開(kāi)發(fā)了不少組件

（8）維護(hù)成本過(guò)高

（9）…

想想看，電商的商品表，不可能一個(gè)類(lèi)目一個(gè)表的。

四、58同城的玩法

---

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

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

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

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

（1）一些通用的字段抽取出來(lái)單獨(dú)存儲(chǔ)

（2）通過(guò)cate, subcate, xxid等來(lái)定義ext是何種含義（和version有點(diǎn)像？）

（3）通過(guò)ext來(lái)存儲(chǔ)不同業(yè)務(wù)線的個(gè)性化需求

例如招聘的帖子：

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

而二手的帖子：

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

58同城最核心的帖子數(shù)據(jù)，100億的數(shù)據(jù)量，分256庫(kù)，異構(gòu)數(shù)據(jù)mysql存儲(chǔ)，上層架了一個(gè)服務(wù)，使用memcache做緩存，就是這樣一個(gè)簡(jiǎn)單的架構(gòu)，一直堅(jiān)持這這么多年。上層的這個(gè)服務(wù)，就是58同城最核心的統(tǒng)一服務(wù)IMC（Imformation Management Center），注意這個(gè)最核心，是沒(méi)有之一。

解決了海量異構(gòu)數(shù)據(jù)的存儲(chǔ)問(wèn)題，遇到的新問(wèn)題是：

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

（2）cateid已經(jīng)不足以描述ext內(nèi)的內(nèi)容，品類(lèi)有層級(jí)，深度不確定，ext能否具備自描述性

（3）隨時(shí)可以增加屬性，保證擴(kuò)展性

【統(tǒng)一類(lèi)目屬性服務(wù)】

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

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

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

這個(gè)表里對(duì)帖子中心服務(wù)里ext字段里的數(shù)字key進(jìn)行了解釋?zhuān)?/p>

1代表job，屬于招聘品類(lèi)下100子品類(lèi)，其value必須是一個(gè)小于32的[a-z]字符

4代表type，屬于二手品類(lèi)下200子品類(lèi)，其value必須是一個(gè)short

這樣就對(duì)原來(lái)帖子表ext里的

ext : {“1”:”driver”,”2”:8000,”3”:”bj”}

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

key和value都做了統(tǒng)一約束。

除此之外，如果ext里某個(gè)key的value不是正則校驗(yàn)的值，而是枚舉值時(shí)，需要有一個(gè)對(duì)值進(jìn)行限定的枚舉表來(lái)進(jìn)行校驗(yàn)：

這個(gè)枚舉校驗(yàn)，說(shuō)明key=4的屬性（對(duì)應(yīng)屬性表里二手，手機(jī)類(lèi)型字段），其值不只是要進(jìn)行“short類(lèi)型”校驗(yàn)，而是value必須是固定的枚舉值。

ext : {”4”:”iphone”,”5”:3500}這個(gè)ext就是不合法的（key=4的value=iphone不合法），合法的應(yīng)該為

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

此外，類(lèi)目屬性服務(wù)還能記錄類(lèi)目之間的層級(jí)關(guān)系：

（1）一級(jí)類(lèi)目是招聘、房產(chǎn)、二手…

（2）二手下有二級(jí)類(lèi)目二手家具、二手手機(jī)…

（3）二手手機(jī)下有三級(jí)類(lèi)目二手iphone，二手小米，二手三星…

（4）…

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

多提一句，類(lèi)目、屬性服務(wù)像不像電商系統(tǒng)里的SKU擴(kuò)展服務(wù)？

（1）品類(lèi)層級(jí)關(guān)系，對(duì)應(yīng)電商里的類(lèi)別層級(jí)體系

（2）屬性擴(kuò)展，對(duì)應(yīng)電商里各類(lèi)別商品SKU的屬性

（3）枚舉值校驗(yàn)，對(duì)應(yīng)屬性的枚舉值，例如顏色：紅，黃，藍(lán)

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

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

數(shù)據(jù)量很大的時(shí)候，不同屬性上的查詢(xún)需求，不可能通過(guò)組合索引來(lái)滿(mǎn)足所有查詢(xún)需求，怎么辦呢？

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

（1）數(shù)據(jù)庫(kù)提供“帖子id”的正排查詢(xún)需求

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

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

（1）對(duì)帖子進(jìn)行tid正排查詢(xún)，直接訪問(wèn)帖子服務(wù)

（2）對(duì)帖子進(jìn)行修改，帖子服務(wù)通知檢索服務(wù)，同時(shí)對(duì)索引進(jìn)行修改

（3）對(duì)帖子進(jìn)行復(fù)雜查詢(xún)，通過(guò)檢索服務(wù)滿(mǎn)足需求

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

對(duì)于這個(gè)服務(wù)的架構(gòu)，簡(jiǎn)單展開(kāi)說(shuō)明一下：

為應(yīng)對(duì)100億級(jí)別數(shù)據(jù)量、幾十萬(wàn)級(jí)別的吞吐量，業(yè)務(wù)線各種復(fù)雜的復(fù)雜檢索查詢(xún)，擴(kuò)展性是設(shè)計(jì)重點(diǎn)：

（1）統(tǒng)一的Java代理層集群，其無(wú)狀態(tài)性能夠保證增加機(jī)器就能擴(kuò)充系統(tǒng)性能

（2）統(tǒng)一的合并層C服務(wù)集群，其無(wú)狀態(tài)性也能夠保證增加機(jī)器就能擴(kuò)充系統(tǒng)性能

（3）搜索內(nèi)核檢索層C服務(wù)集群，服務(wù)和索引數(shù)據(jù)部署在同一臺(tái)機(jī)器上，服務(wù)啟動(dòng)時(shí)可以加載索引數(shù)據(jù)到內(nèi)存，請(qǐng)求訪問(wèn)時(shí)從內(nèi)存中l(wèi)oad數(shù)據(jù)，訪問(wèn)速度很快

（3.1）為了滿(mǎn)足數(shù)據(jù)容量的擴(kuò)展性，索引數(shù)據(jù)進(jìn)行了水平切分，增加切分份數(shù)，就能夠無(wú)限擴(kuò)展性能

（3.2）為了滿(mǎn)足一份數(shù)據(jù)的性能擴(kuò)展性，同一份數(shù)據(jù)進(jìn)行了冗余，理論上做到增加機(jī)器就無(wú)限擴(kuò)展性能

系統(tǒng)時(shí)延，100億級(jí)別帖子檢索，包含請(qǐng)求分合，拉鏈求交集，從merger層均可以做到10ms返回。

58同城的帖子業(yè)務(wù)，一致性不是主要矛盾，E-search會(huì)定期全量重建索引，以保證即使數(shù)據(jù)不一致，也不會(huì)持續(xù)很長(zhǎng)的時(shí)間。

五、總結(jié)

---

文章寫(xiě)了很長(zhǎng)，最后做一個(gè)簡(jiǎn)單總結(jié)，面對(duì)100億數(shù)據(jù)量，1萬(wàn)列屬性，10萬(wàn)吞吐量的業(yè)務(wù)需求，58同城的經(jīng)驗(yàn)，是采用了元數(shù)據(jù)服務(wù)、屬性服務(wù)、搜索服務(wù)來(lái)解決的。