有一類業(yè)務(wù)場景，沒有固定的schema存儲，卻有著海量的數(shù)據(jù)行數(shù)，架構(gòu)上如何來實(shí)現(xiàn)這類業(yè)務(wù)的存儲與檢索呢?58核心的數(shù)據(jù)“帖子”的架構(gòu)實(shí)現(xiàn)技術(shù)細(xì)節(jié)，今天和大家聊一聊。

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

1. 什么是58核心的數(shù)據(jù)?

58是一個(gè)信息平臺，有很多垂直品類：招聘、房產(chǎn)、二手物品、二手車、黃頁等等，每個(gè)品類又有很多子品類，不管哪個(gè)品類，最核心的數(shù)據(jù)都是“帖子信息”。

畫外音：像不像一個(gè)大論壇?

2. 各分類帖子的信息有什么特點(diǎn)?

逛過58的朋友很容易了解到，這里的帖子信息：

• 各品類的屬性千差萬別，招聘帖子和二手帖子屬性完全不同，二手手機(jī)和二手家電的屬性又完全不同，目前恐怕有近萬個(gè)屬性;
• 數(shù)據(jù)量巨大，100億級別;
• 每個(gè)屬性上都有查詢需求，各組合屬性上都可能有組合查詢需求，招聘要查職位/經(jīng)驗(yàn)/薪酬范圍，二手手機(jī)要查顏色/價(jià)格/型號，二手要查冰箱/洗衣機(jī)/空調(diào);
• 吞吐量很大，每秒幾10萬吞吐;

如何解決100億數(shù)據(jù)量，1萬屬性，多屬性組合查詢，10萬并發(fā)查詢的技術(shù)難題呢?一步步來。

二、容易想到的方案

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

• 如何實(shí)現(xiàn)屬性擴(kuò)展性需求;
• 多屬性組合查詢需求。

畫外音：公司初期并發(fā)量和數(shù)據(jù)量都不大，必須先解決業(yè)務(wù)問題。

1. 如何滿足業(yè)務(wù)的存儲需求呢?

最開始，業(yè)務(wù)只有一個(gè)招聘品類，那帖子表可能是這么設(shè)計(jì)的：

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

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

最容易想到的是通過組合索引滿足查詢需求：

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

3. 隨著業(yè)務(wù)的發(fā)展，又新增了一個(gè)房產(chǎn)類別，存儲問題又該如何解決呢?

可以新增若干屬性滿足存儲需求，于是帖子表變成了：

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

其中：

• c1,c2,c3是招聘類別屬性
• c10,c11,c12,c13是房產(chǎn)類別屬性

通過擴(kuò)展屬性，可以解決存儲的問題。

4. 查詢需求，又該如何滿足呢?

首先，跨業(yè)務(wù)屬性一般沒有組合查詢需求。只能建立了若干組合索引，滿足房產(chǎn)類別的查詢需求。

畫外音：不敢想有多少個(gè)索引能覆蓋所有兩屬性查詢，三屬性查詢。

當(dāng)業(yè)務(wù)越來越多時(shí)，是不是發(fā)現(xiàn)玩不下去了?

三、垂直拆分是一個(gè)思路

新增屬性是一種擴(kuò)展方式，新增表也是一種方式，垂直拆分也是常見的存儲擴(kuò)展方案。

1. 如何按照業(yè)務(wù)進(jìn)行垂直拆分?

可以這么玩：

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

在業(yè)務(wù)各異，數(shù)據(jù)量和吞吐量都巨大的情況下，垂直拆分會遇到什么問題呢?

這些表，以及對應(yīng)的服務(wù)維護(hù)在不同的部門，看上去各業(yè)務(wù)靈活性強(qiáng)，研發(fā)閉環(huán)，這恰恰是悲劇的開始：

• tid如何規(guī)范?
• 屬性如何規(guī)范?
• 按照uid來查詢怎么辦(查詢自己發(fā)布的所有帖子)?
• 按照時(shí)間來查詢怎么辦(最新發(fā)布的帖子)?
• 跨品類查詢怎么辦(例如首頁搜索框)?
• 技術(shù)范圍的擴(kuò)散，有的用mongo存儲，有的用mysql存儲，有的自研存儲;
• 重復(fù)開發(fā)了不少組件;
• 維護(hù)成本過高;
• …

畫外音：想想看，電商的商品表，不可能一個(gè)類目一個(gè)表的。

四、58的玩法：三大中心服務(wù)

第一：統(tǒng)一帖子中心服務(wù)

平臺型創(chuàng)業(yè)型公司，可能有多個(gè)品類，各品類有很多異構(gòu)數(shù)據(jù)的存儲需求，到底是分還是合，無需糾結(jié)：基礎(chǔ)數(shù)據(jù)基礎(chǔ)服務(wù)的統(tǒng)一，是一個(gè)很好的實(shí)踐。

畫外音：這里說的是平臺型業(yè)務(wù)。

如何將不同品類，異構(gòu)的數(shù)據(jù)統(tǒng)一存儲起來呢?

• 全品類通用屬性統(tǒng)一存儲;
• 單品類特有屬性，品類類型與通用屬性json來進(jìn)行存儲;

更具體的：

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

• 一些通用的字段抽取出來單獨(dú)存儲;
• 通過cate, subcate, xxid等來定義ext是何種含義;

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

例如：

招聘的帖子，ext為：

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

而二手的帖子，ext為：

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

帖子數(shù)據(jù)，100億的數(shù)據(jù)量，分256庫，通過ext存儲異構(gòu)業(yè)務(wù)數(shù)據(jù)，使用mysql存儲，上層架了一個(gè)帖子中心服務(wù)，使用memcache做緩存，就是這樣一個(gè)并不復(fù)雜的架構(gòu)，解決了業(yè)務(wù)的大問題。這是58最核心的帖子中心服務(wù)IMC(Info Management Center)。

畫外音：該服務(wù)的底層存儲在16年全面切換為了自研存儲引擎，替換了mysql，但架構(gòu)理念仍未變。

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

• 每條記錄ext內(nèi)key都需要重復(fù)存儲，占據(jù)了大量的空間，能否壓縮存儲;
• cateid已經(jīng)不足以描述ext內(nèi)的內(nèi)容，品類有層級，深度不確定，ext能否具備自描述性;
• 隨時(shí)可以增加屬性，保證擴(kuò)展性;

解決完海量異構(gòu)數(shù)據(jù)的存儲問題，接下來，要解決的是類目的擴(kuò)展性問題。

第二：統(tǒng)一類目屬性服務(wù)

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

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

畫外音：帖子表只存元信息，不管業(yè)務(wù)含義。

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

畫外音：類目表存業(yè)務(wù)信息，以及約束信息，與帖子表解耦。

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

• 1代表job，屬于招聘品類下100子品類，其value必須是一個(gè)小于32的[a-z]字符;
• 4代表type，屬于二手品類下200子品類，其value必須是一個(gè)short;

這樣就對原來帖子表ext擴(kuò)展屬性：

{“1”:”driver”,”2”:8000,”3”:”bj”} 
{”4”:”iphone”,”5”:3500} 

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

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

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

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

這個(gè)ext就是不合法的，key=4的value=iphone不合法，而應(yīng)該是枚舉屬性，合法的應(yīng)該為：

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

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

• 一級類目是招聘、房產(chǎn)、二手…
• 二手下有二級類目二手家具、二手手機(jī)…
• 二手手機(jī)下有三級類目二手iphone，二手小米，二手三星…
• …

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

畫外音：類目、屬性服務(wù)像不像電商系統(tǒng)里的SKU擴(kuò)展服務(wù)?

• 品類層級關(guān)系，對應(yīng)電商里的類別層級體系;
• 屬性擴(kuò)展，對應(yīng)電商里各類別商品SKU的屬性;
• 枚舉值校驗(yàn)，對應(yīng)屬性的枚舉值，例如顏色：紅，黃，藍(lán);

通過品類服務(wù)，解決了key壓縮，key描述，key擴(kuò)展，value校驗(yàn)，品類層級的問題，還有這樣的一個(gè)問題沒有解決：每個(gè)品類下帖子的屬性各不相同，查詢需求各不相同，如何解決100億數(shù)據(jù)量，1萬屬性的檢索與聯(lián)合檢索需求呢?

第三：統(tǒng)一檢索服務(wù)

數(shù)據(jù)量很大的時(shí)候，不同屬性上的查詢需求，不可能通過組合索引來滿足所有查詢需求，“外置索引，統(tǒng)一檢索服務(wù)”是一個(gè)很常用的實(shí)踐：

• 數(shù)據(jù)庫提供“帖子id”的正排查詢需求;
• 所有非“帖子id”的個(gè)性化檢索需求，統(tǒng)一走外置索引。

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

• 對帖子進(jìn)行tid正排查詢，直接訪問帖子服務(wù);
• 對帖子進(jìn)行修改，帖子服務(wù)通知檢索服務(wù)，同時(shí)對索引進(jìn)行修改;
• 對帖子進(jìn)行復(fù)雜查詢，通過檢索服務(wù)滿足需求。

畫外音：這個(gè)檢索服務(wù)，扛起了58同城80%的請求(不管來自PC還是APP，不管是主頁、城市頁、分類頁、列表頁、詳情頁，最終都會轉(zhuǎn)化為一個(gè)檢索請求)，它就是58另一個(gè)統(tǒng)一的核心服務(wù)E-search，這個(gè)搜索引擎，是完全自研的。

對于這個(gè)內(nèi)核自研服務(wù)的搜索引擎架構(gòu)，簡單說明一下：

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

(1) 統(tǒng)一的代理層，作為入口，其無狀態(tài)性能夠保證增加機(jī)器就能擴(kuò)充系統(tǒng)性能;

(2) 統(tǒng)一的結(jié)果聚合層，其無狀態(tài)性也能夠保證增加機(jī)器就能擴(kuò)充系統(tǒng)性能;

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

• 為了滿足數(shù)據(jù)容量的擴(kuò)展性，索引數(shù)據(jù)進(jìn)行了水平切分，增加切分份數(shù)，就能夠無限擴(kuò)展性能
• 為了滿足一份數(shù)據(jù)的性能擴(kuò)展性，同一份數(shù)據(jù)進(jìn)行了冗余，理論上做到增加機(jī)器就無限擴(kuò)展性能

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

畫外音：入口層是Java研發(fā)的，聚合層與檢索層都是C語言研發(fā)的。

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

五、總結(jié)

文章寫了很長，最后做一個(gè)簡單總結(jié)，面對100億數(shù)據(jù)量，1萬列屬性，10萬吞吐量的業(yè)務(wù)需求，可以采用了元數(shù)據(jù)服務(wù)、屬性服務(wù)、搜索服務(wù)來解決：

• 一個(gè)解決存儲問題
• 一個(gè)解決品類解耦問題
• 一個(gè)解決檢索問題

任何復(fù)雜問題的解決，都是循序漸進(jìn)的。

思路比結(jié)論重要，希望大家有收獲。

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文