正文

有一類業務場景，沒有固定的schema存儲，卻有著海量的數據行數，架構上如何來實現這類業務的存儲與檢索呢？58最核心的數據“帖子”的架構實現技術細節，今天和大家聊一聊。

背景描述及業務介紹

什么是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）…

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

統一帖子中心服務

平臺型創業型公司，可能有多個品類，各品類有很多異構數據的存儲需求，到底是分還是合，無需糾結：基礎數據基礎服務的統一，是一個很好的實踐。

畫外音：這里說的是平臺型業務。

如何將不同品類，異構的數據統一存儲起來呢？

（1）全品類通用屬性統一存儲；

（2）單品類特有屬性，品類類型與通用屬性json來進行存儲；

更具體的：

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

（1）一些通用的字段抽取出來單獨存儲；

（2）通過cate, subcate, xxid等來定義ext是何種含義；