1萬屬性，100億數據，每秒10萬吞吐，架構如何設計？
有一類業務場景，沒有固定的schema存儲，卻有著海量的數據行數，架構上如何來實現這類業務的存儲與檢索呢?58最核心的數據“帖子”的架構實現技術細節，今天和大家聊一聊。
一、背景描述及業務介紹
什么是58最核心的數據?
58是一個信息平臺，有很多垂直品類：招聘、二手物品、二手車、黃頁等等，每個品類又有很多子品類，不管哪個品類，最核心的數據都是“帖子信息”。
畫外音：像不像一個大論壇?
各分類帖子的信息有什么特點?
逛過58的朋友很容易了解到，這里的帖子信息：
- 各品類的屬性千差萬別，招聘帖子和二手帖子屬性完全不同，二手手機和二手家電的屬性又完全不同，目前恐怕有近萬個屬性;
- 數據量巨大，100億級別;
- 每個屬性上都有查詢需求，各組合屬性上都可能有組合查詢需求，招聘要查職位/經驗/薪酬范圍，二手手機要查顏色/價格/型號，二手要查冰箱/洗衣機/空調;
- 吞吐量很大，每秒幾10萬吞吐;
如何解決100億數據量，1萬屬性，多屬性組合查詢，10萬并發查詢的技術難題呢?一步步來。
二、最容易想到的方案
每個公司的發展都是一個從小到大的過程，撇開并發量和數據量不談，先看看
- 如何實現屬性擴展性需求;
- 多屬性組合查詢需求;
畫外音：公司初期并發量和數據量都不大，必須先解決業務問題。
如何滿足業務的存儲需求呢?
最開始，業務只有一個招聘品類，那帖子表可能是這么設計的：
- 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);
在業務各異，數據量和吞吐量都巨大的情況下，垂直拆分會遇到什么問題呢?
這些表，以及對應的服務維護在不同的部門，看上去各業務靈活性強，研發閉環，這恰恰是悲劇的開始：
- tid如何規范?
- 屬性如何規范?
- 按照uid來查詢怎么辦(查詢自己發布的所有帖子)?
- 按照時間來查詢怎么辦?
- 跨品類查詢怎么辦(例如首頁搜索框)?
- 技術范圍的擴散，有的用mongo存儲，有的用mysql存儲，有的自研存儲;
- 重復開發了不少組件;
- 維護成本過高;
- …
畫外音：想想看，電商的商品表，不可能一個類目一個表的。
四、58的玩法：三大中心服務
一 統一帖子中心服務
平臺型創業型公司，可能有多個品類，各品類有很多異構數據的存儲需求，到底是分還是合，無需糾結：基礎數據基礎服務的統一，是一個很好的實踐。
畫外音：這里說的是平臺型業務。
如何將不同品類，異構的數據統一存儲起來呢?
- 全品類通用屬性統一存儲;
- 單品類特有屬性，品類類型與通用屬性json來進行存儲;
更具體的：
- tiezi(tid, uid, time, title, cate, subcate, xxid, ext);
- 一些通用的字段抽取出來單獨存儲;
- 通過cate, subcate, xxid等來定義ext是何種含義;
- 通過ext來存儲不同業務線的個性化需求
例如：
招聘的帖子，ext為：
- {“job”:”driver”,”salary”:8000,”location”:”bj”}
而二手的帖子，ext為：
- {”type”:”iphone”,”money”:3500}
帖子數據，100億的數據量，分256庫，通過ext存儲異構業務數據，使用mysql存儲，上層架了一個帖子中心服務，使用memcache做緩存，就是這樣一個并不復雜的架構，解決了業務的大問題。這是58最核心的帖子中心服務IMC(Info Management Center)。
畫外音：該服務的底層存儲在16年全面切換為了自研存儲引擎，替換了mysql，但架構理念仍未變。
解決了海量異構數據的存儲問題，遇到的新問題是：
- 每條記錄ext內key都需要重復存儲，占據了大量的空間，能否壓縮存儲;
- cateid已經不足以描述ext內的內容，品類有層級，深度不確定，ext能否具備自描述性;
- 隨時可以增加屬性，保證擴展性;
解決完海量異構數據的存儲問題，接下來，要解決的是類目的擴展性問題。
第二：統一類目服務
每個業務有多少屬性，這些屬性是什么含義，值的約束等，耦合到帖子服務里顯然是不合理的，那怎么辦呢?
抽象出一個統一的類目，單獨來管理這些信息，而帖子庫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擴展屬性：
- {“1”:”driver”,”2”:8000,”3”:”bj”}
- {”4”:”iphone”,”5”:3500}
key和value都做了統一約束。
除此之外，如果ext里某個key的value不是正則校驗的值，而是枚舉值時，需要有一個對值進行限定的枚舉表來進行校驗：
這個枚舉校驗，說明key=4的屬性(對應屬性表里二手，手機類型字段)，其值不只是要進行“short類型”校驗，而是value必須是固定的枚舉值。
- {”4”:”iphone”,”5”:3500}
這個ext就是不合法的，key=4的value=iphone不合法，而應該是枚舉屬性，合法的應該為：
- {”4”:”5”,”5”:3500}
此外，類目服務還能記錄類目之間的層級關系：
- 一級類目是招聘、二手…
- 二手下有二級類目二手家具、二手手機…
- 二手手機下有三級類目二手iphone，二手小米，二手三星…
- …
類目服務解釋了帖子數據，描述品類層級關系，保證各類目屬性擴展性，保證各屬性值合理性校驗，就是58另一個統一的核心服務CMC(Category Management Center)。
畫外音：服務像不像電商系統里的SKU擴展服務?
- 品類層級關系，對應電商里的類別層級體系;
- 屬性擴展，對應電商里各類別商品SKU的屬性;
- 枚舉值校驗，對應屬性的枚舉值，例如顏色：紅，黃，藍;
通過品類服務，解決了key壓縮，key描述，key擴展，value校驗，品類層級的問題，還有這樣的一個問題沒有解決：每個品類下帖子的屬性各不相同，查詢需求各不相同，如何解決100億數據量，1萬屬性的檢索與聯合檢索需求呢?
第三：統一檢索服務
數據量很大的時候，不同屬性上的查詢需求，不可能通過組合索引來滿足所有查詢需求，“外置索引，統一檢索服務”是一個很常用的實踐：
- 數據庫提供“帖子id”的正排查詢需求;
- 所有非“帖子id”的個性化檢索需求，統一走外置索引;
元數據與索引數據的操作遵循：
- 對帖子進行tid正排查詢，直接訪問帖子服務;
- 對帖子進行修改，帖子服務通知檢索服務，同時對索引進行修改;
- 對帖子進行復雜查詢，通過檢索服務滿足需求;
畫外音：這個檢索服務，扛起了58同城80%的請求(不管來自PC還是APP，不管是主頁、城市頁、分類頁、列表頁、詳情頁，最終都會轉化為一個檢索請求)，它就是58另一個統一的核心服務E-search，這個搜索引擎，是完全自研的。
對于這個內核自研服務的搜索引擎架構，簡單說明一下：
為應對100億級別數據量、幾十萬級別的吞吐量，業務線各種復雜的復雜檢索查詢，擴展性是設計重點：
(1)統一的代理層，作為入口，其無狀態性能夠保證增加機器就能擴充系統性能;
(2)統一的結果聚合層，其無狀態性也能夠保證增加機器就能擴充系統性能;
(3)搜索內核檢索層，服務和索引數據部署在同一臺機器上，服務啟動時可以加載索引數據到內存，請求訪問時從內存中load數據，訪問速度很快：
- 為了滿足數據容量的擴展性，索引數據進行了水平切分，增加切分份數，就能夠擴展性能
- 為了滿足一份數據的性能擴展性，同一份數據進行了冗余，理論上做到增加機器就擴展性能
系統時延，100億級別帖子檢索，包含請求分合，拉鏈求交集，從聚合層均可以做到10ms返回。
畫外音：入口層是Java研發的，聚合層與檢索層都是C語言研發的。
帖子業務，一致性不是主要矛盾，E-search會定期全量重建索引，以保證即使數據不一致，也不會持續很長的時間。
五、總結
文章寫了很長，做一個簡單總結，面對100億數據量，1萬列屬性，10萬吞吐量的業務需求，可以采用了元數據服務、搜索服務來解決：
- 一個解決存儲問題
- 一個解決品類解耦問題
- 一個解決檢索問題
任何復雜問題的解決，都是循序漸進的。
思路比結論重要，希望大家有收獲。
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
