一分鐘系列之《啥，又要爲表增長一列屬性？》分享了兩種數據庫屬性擴展思路，被噴得厲害。次日補充了一篇《這纔是真正的表擴展方案》，分享了互聯網大數據高併發狀況下，數據庫屬性擴容的成熟工具及思路。mysql
對於version + ext方案，仍是有不少朋友質疑「線上不可能這麼用」。本篇將講述一下58同城最核心的數據「帖子」的架構實現技術細節，說明不只不是「不可能這麼用」，而是大數據，可變屬性，高吞吐場景下的「經常使用手段」。sql
1、背景描述及業務介紹
問：什麼是數據庫擴展的version + ext方案？
使用ext來承載不一樣業務需求的個性化屬性，使用version來標識ext裏各個字段的含義。
例如上述user表：
verion=0表示ext裏是passwd/nick
version=1表示ext裏是passwd/nick/age/sex
數據庫
優勢？
（1）能夠隨時動態擴展屬性，擴展性好
（2）新舊兩種數據能夠同時存在，兼容性好
不足？
（1）ext裏的字段沒法創建索引
（2）ext裏的key值有大量冗餘，建議key短一些
json
問：什麼是58同城最核心的數據？
58同城是一個信息平臺，有不少垂直品類：招聘、房產、二手物品、二手車、黃頁等等，每一個品類又有不少子品類，無論哪一個品類，最核心的數據都是「帖子信息」（業務像一個大論壇？）。緩存
問：帖子信息有什麼特色？
你們去58同城的首頁上看看就知道了：
（1）每一個品類的屬性千差萬別，招聘帖子和二手帖子屬性徹底不一樣，二手手機和二手家電的屬性又徹底不一樣，目前恐怕有近萬個屬性
（2）帖子量很大，100億級別
（3）每一個屬性上都有查詢需求（各組合屬性上均可能有組合查詢需求），招聘要查職位/經驗/薪酬範圍，二手手機要查顏色/價格/型號，二手要查冰箱/洗衣機/空調
（4）查詢量很大，每秒幾10萬級別
架構
如何解決100億數據量，1萬屬性，多屬性組合查詢，10萬併發查詢的技術難題，是今天要討論的內容。併發
2、最容易想到的方案
每一個公司的發展都是一個從小到大的過程，撇開併發量和數據量不談，先看看
（1）如何實現屬性擴展性需求
（2）多屬性組合查詢需求
iphone
最開始，可能只有一個招聘品類，那帖子表多是這麼設計的：
tiezi(tid,uid, c1, c2, c3)
ide
那如何知足各屬性之間的組合查詢需求呢？
最容易想到的是經過組合索引：
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是房產類別屬性，這兩塊屬性通常沒有組合查詢需求
但爲了知足房產類別的查詢需求，又要創建了若干組合索引（不敢想有多少個索引能覆蓋全部兩屬性查詢，三屬性查詢）
是否是發現玩不下去了？
3、友商的玩法
新增屬性是一種擴展方式，新增表也是一種方式，有友商是這麼玩的，按照業務進行垂直拆分：
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）…
想一想看，電商的商品表，不可能一個類目一個表的。
4、58同城的玩法
【統一帖子中心服務】
平臺型創業型公司，可能有多個品類，例如58同城的招聘房產二手，不少異構數據的存儲需求，究竟是分仍是合，無需糾結：基礎數據基礎服務的統一，無疑是58同城技術路線發展roadmap上最正確的決策之一，把這個方針堅持下來，@老崔 @曉飛 這些高瞻遠矚的先賢功不可沒，業務線會有「擴展性」「靈活性」上的微詞，後文看看先賢們如何經過一些巧妙的技術方案來解決的。
如何將不一樣品類，異構的數據統一存儲起來，採用的就是相似version+ext的方式：
tiezi(tid,uid, time, title, cate, subcate, xxid, ext)
（1）一些通用的字段抽取出來單獨存儲
（2）經過cate, subcate, xxid等來定義ext是何種含義（和version有點像？）
（3）經過ext來存儲不一樣業務線的個性化需求
例如招聘的帖子：
ext : {「job」:」driver」,」salary」:8000,」location」:」bj」}
而二手的帖子：
ext : {」type」:」iphone」,」money」:3500}
58同城最核心的帖子數據，100億的數據量，分256庫，異構數據mysql存儲，上層架了一個服務，使用memcache作緩存，就是這樣一個簡單的架構，一直堅持這這麼多年。上層的這個服務，就是58同城最核心的統一服務IMC（Imformation Management Center），注意這個最核心，是沒有之一。
解決了海量異構數據的存儲問題，遇到的新問題是：
（1）每條記錄ext內key都須要重複存儲，佔據了大量的空間，可否壓縮存儲
（2）cateid已經不足以描述ext內的內容，品類有層級，深度不肯定，ext可否具有自描述性
（3）隨時能夠增長屬性，保證擴展性
【統一類目屬性服務】
每一個業務有多少屬性，這些屬性是什麼含義，值的約束等揉不到帖子服務裏，怎麼辦呢？
58同城的先賢們抽象出一個統一的類目、屬性服務，單獨來管理這些信息，而帖子庫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裏的
ext : {「1」:」driver」,」2」:8000,」3」:」bj」}
ext : {」4」:」iphone」,」5」:3500}
key和value都作了統一約束。
除此以外，若是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）…
協助解釋58同城最核心的帖子數據，描述品類層級關係，保證各種目屬性擴展性，保證各屬性值合理性校驗，就是58同城另外一個統一的核心服務CMC（Category Management Center）。
多提一句，類目、屬性服務像不像電商系統裏的SKU擴展服務？
（1）品類層級關係，對應電商裏的類別層級體系
（2）屬性擴展，對應電商裏各種別商品SKU的屬性
（3）枚舉值校驗，對應屬性的枚舉值，例如顏色：紅，黃，藍
解決了key壓縮，key描述，key擴展，value校驗，品類層級的問題，還有這樣的一個問題沒有解決：每一個品類下帖子的屬性各不相同，查詢需求各不相同，如何解決100億數據量，1萬屬性的查詢需求，是58同城面臨的新問題。
【統一檢索服務】
數據量很大的時候，不一樣屬性上的查詢需求，不可能經過組合索引來知足全部查詢需求，怎麼辦呢？
58同城的先賢們，從一早就肯定了「外置索引，統一檢索服務」的技術路線：
（1）數據庫提供「帖子id」的正排查詢需求
（2）全部非「帖子id」的個性化檢索需求，統一走外置索引
元數據與索引數據的操做遵循：
（1）對帖子進行tid正排查詢，直接訪問帖子服務
（2）對帖子進行修改，帖子服務通知檢索服務，同時對索引進行修改
（3）對帖子進行復雜查詢，經過檢索服務知足需求
這個扛起58同城80%終端請求（無論來自PC仍是APP，不論是主頁、城市頁、分類頁、列表頁、詳情頁，極可能這個請求最終會是一個檢索請求）的服務，就是58同城另外一個統一的核心服務E-search，這個搜索引擎的每一行代碼都來自58同城@老崔 @老龔 等先賢們，目前系統維護者，就是「架構師之路」裏多次提到的@龍神 。
對於這個服務的架構，簡單展開說明一下：
爲應對100億級別數據量、幾十萬級別的吞吐量，業務線各類複雜的複雜檢索查詢，擴展性是設計重點：
（1）統一的Java代理層集羣，其無狀態性可以保證增長機器就能擴充系統性能
（2）統一的合併層C服務集羣，其無狀態性也可以保證增長機器就能擴充系統性能
（3）搜索內核檢索層C服務集羣，服務和索引數據部署在同一臺機器上，服務啓動時能夠加載索引數據到內存，請求訪問時從內存中load數據，訪問速度很快
（3.1）爲了知足數據容量的擴展性，索引數據進行了水平切分，增長切分份數，就可以無限擴展性能
（3.2）爲了知足一份數據的性能擴展性，同一份數據進行了冗餘，理論上作到增長機器就無限擴展性能
系統時延，100億級別帖子檢索，包含請求分合，拉鍊求交集，從merger層都可以作到10ms返回。
58同城的帖子業務，一致性不是主要矛盾，E-search會按期全量重建索引，以保證即便數據不一致，也不會持續很長的時間。
5、總結
文章寫了很長，最後作一個簡單總結，面對100億數據量，1萬列屬性，10萬吞吐量的業務需求，58同城的經驗，是採用了元數據服務、屬性服務、搜索服務來解決的。
再回到文首version + ext的方案，但願朋友有新的收穫和感觸，幫轉哈。==【完】==相關閱讀：《啥，又要爲表增長一列屬性？》 <- 相關《這纔是真正的表擴展方案》 <- 相關《究竟啥纔是互聯網架構「高可用」》 <- 火《究竟啥纔是互聯網架構「高併發」》 <- 火