一分鐘系列之《啥，又要為表增加一列屬性？》分享了兩種資料庫屬性擴充思路，被噴得厲害。第二天補充了一篇《這才是真正的表擴充方案》，分享了網際網路大資料高并發情況下，資料庫屬性擴容的成熟工具及思路。
對于version + ext方案，還是有很多朋友質疑“線上不可能這麼用”。本篇将講述一下58同城最核心的資料“文章”的架構實作技術細節，說明不僅不是“不可能這麼用”，而是大資料，可變屬性，高吞吐場景下的“常用手段”。
一、背景描述及業務介紹
問：什麼是資料庫擴充的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短一些
問：什麼是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）…
想想看，電商的商品表，不可能一個類目一個表的。
四、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會定期全量重建索引，以保證即使資料不一緻，也不會持續很長的時間。
五、總結
文章寫了很長，最後做一個簡單總結，面對100億資料量，1萬列屬性，10萬吞吐量的業務需求，58同城的經驗，是采用了中繼資料服務、屬性服務、搜尋服務來解決的。
再回到文首version + ext的方案，希望朋友有新的收獲和感觸，幫轉哈。
==【完】==