每個公司都是從大到小的發展
（1）如何實作屬性擴充性需求
（2）多屬性組合查詢需求
如何設計？
1.原始的，隻有一個分類A
tiezi(tid,uid, c1, c2, c3)
c1,c2,c3是A屬性
如何滿足各屬性之間的組合查詢需求，通過組合索引：
index_1(c1,c2) index_2(c2, c3) index_3(c1, c3)
如果增加一個新的類别B
tiezi(tid,uid, c1, c2, c3, c10, c11, c12, c13)
其中c1,c2,c3是A，c10,c11,c12,c13是B
如何滿足各屬性之間的組合查詢需求，再通過是以就不行了
是以這種結構不可取
2.按照業務進行垂直拆分
tiezi_A(tid,uid, c1, c2, c3)
tiezi_B(tid,uid, c10, c11, c12, c13)
這可以通過索引查詢
但是也會有新的問題
（1）tid如何規範
（2）屬性如何規範
（3）按照uid來查詢怎麼辦
（4）按照時間來查詢怎麼辦
（5）跨品類查詢怎麼辦（例如首頁搜尋）
……
3.存儲異構資料
- 基礎資料基礎服務的統一
tiezi(tid,uid, time, title, cate, subcate, xxid, ext)
（1）一些通用的字段抽取出來單獨存儲
（2）通過cate, subcate, xxid等來定義ext是何種含義
（3）通過ext來存儲不同業務線的個性化需求
這種異構資料的存儲後遇到的新問題是：
（1）每條記錄ext内key都需要重複存儲，占據了大量的空間，能否壓縮存儲
（2）cateid已經不足以描述ext内的内容，品類有層級，深度不确定，ext能否具備自描述性
（3）随時可以增加屬性，保證擴充性
- 統一類目屬性服務
抽象出一個統一的類目、屬性服務，單獨來管理這些資訊，而ext字段裡json的key，統一由數字來表示，減少存儲空間。
協助解釋最核心的資料，描述品類層級關系，保證各類目屬性擴充性，保證各屬性值合理性校驗
基礎資料
屬性
中心服務裡ext字段裡的數字key進行了解釋：
1代表job，屬于招聘品類下100子品類，其value必須是一個小于32的字元
3代表type，屬于二手品類下200子品類，其value必須是一個short
如果ext裡某個key的value不是正則校驗的值，而是枚舉值時，需要有一個對值進行限定的枚舉表來進行校驗
例如type
key=4的屬性（對應屬性表裡二手，手機類型字段），其值不隻是要進行“short類型”校驗，而是value必須是固定的枚舉值
合法的ext : {”4”:”5”,”5”:3500}
如果是電商系統裡的SKU擴充
（1）類别
（2）類别商品SKU的屬性
（3）枚舉值校驗，對應屬性的枚舉值，例如顔色：紅，黃，藍
- 統一檢索服務
資料量很大的時候，不同屬性上的查詢需求，不可能通過組合索引來滿足所有查詢需求
外置索引，統一檢索服務
（1）資料庫提供tid的正排查詢需求
（2）所有非tid的個性化檢索需求，統一走外置索引
中繼資料與索引資料的操作遵循：
（1）進行tid正排查詢，直接通路服務
（2）進行修改，文章服務通知檢索服務，同時對索引進行修改
（3）進行複雜查詢，通過檢索服務滿足需求
大吞吐量，業務複雜的檢索查詢，擴充性是設計重點：
（1）統一的Java代理層叢集，其無狀态性能夠保證增加機器就能擴充系統性能
（2）統一的合并層C服務叢集，其無狀态性也能夠保證增加機器就能擴充系統性能
（3）搜尋核心檢索層C服務叢集，服務和索引資料部署在同一台機器上，服務啟動時可以加載索引資料到記憶體，請求通路時從記憶體中load資料，通路速度很快
為了滿足資料容量的擴充性，索引資料進行了水準切分，增加切分份數，就能夠無限擴充性能