接上文。
Cache Money雖然解決了數據的讀取性能瓶頸；但開發大網站數據庫面臨的問題遠不至讀壓力。
首先是容量。
上千萬/億的數據量並不罕見，單一物理數據庫服務器即便單純承擔寫壓力也會是瓶頸。更何況Cache Money僅僅是在理想狀況下纔可以做到數據庫0讀。緩存服務器更新，新增查詢，複雜查詢等等都還會造成讀壓力。
比較常見的做法是採用分表，也就是所謂的Sharding，把數據按照一定的規則，分別存儲至多臺數據庫服務器上去。
其次是變動。
業務需求是不可預測的；無論一開始數據庫表結構定義得如何完備，總會有新需求出來，需要對錶結構做調整纔可以實現。
數據量過了百萬之後，每次對生產服務器做alter table/create index等調整都是痛苦的經歷。
針對容量與變動這兩個問題，FriendFeed提出的schema-less database design給出了一個相當漂亮的解決方案。
強烈推薦閱讀FriendFeed的原文。
FriendFeed的方案大致是這樣：
- 只有一種表結構，只有兩個列：id + blob/binary(max)
- id本身是UUID，這本身可以很容易做sharding
- blob可以反序列化爲任意結構
- 查詢通過另外建表實現，比方說users表的blob列反序列化出來的結構中包含一個age的int屬性；要查詢select * from users where age = 18; 那麼就另外建表如user_age，僅包括兩列id / age；先查詢此表獲得id，再查詢原本的users表獲得完整數據
- 索引表可以異步建立，而且，建立的時候它都是跟查詢相關，可以根據查詢條件做sharding；如上面所的age。
FriendFeed的方案相當聰明，數據本身結構及其簡單，sharding很容易做。寫/讀壓力一下子就分佈出去。
blob列用於序列化（數據甚至是先zip過再存，CPU強勁，磁盤IO是瓶頸），所以結構可以隨時變化；只需要保證序列化算法可以兼容不同版本即可。
而靈活的序列化，恰恰是Facebook Thrift所解決的！
（還記得一開始使用Memcached做object cache時採用了Thrift做序列化麼？）
先不考慮Sharding分佈方案，在MoSonic中將各個類定義爲類似下面的結構：
- id(int)
- properties(blob)
- user_name(varchar)
- age(int)
- ...
- ...
以後要修改數據結構，直接改Thrift的定義文件，然後重新生成代碼就成。properties列中存的數據可能跟最新的結構不一直，但Thrift並不要求嚴格的匹配（BinaryFormatter則不然），它會自動忽略那些不符合的列；而一但Object被重新存入，數據就又會被重新序列化完整。
======================
FriendFeed的分佈式方案要求表主建是uuid，而cache money卻要求所有表必須要有自增的ID主健。
這其實不是衝突，把database_name + table_name + id看成一個uuid即可。
而FriendFeed的分佈式索引，跟cache money中Vector Cache有異曲同工之妙。
都是根據查詢條件做處理/sharding。
之前爲MoSonic添加Vector Cache，已經需要判斷查詢的表名/查詢條件；符合即查詢緩存；這裏套用FriendFeed的方案則變成，符合即查詢分佈式索引！
執行select id from users where age=18 limit order by id desc 0,10時
邏輯變成這樣：
- 檢查Vector Cache，存在便返回
- 檢查分佈式索引表規則，獲得新的數據庫連接字符串
- 執行查詢
- 寫入Vector Cache
插入數據時，之前僅是更新Vector Cache，現在則需多一步去插入索引表。
實際運行中，因爲是先插入數據表，同步更新Vector Cache，後續的插敘已經會命中緩存；索引表的更新實質變成是備份，可以異步插入。
Thrift / Cache Money / Schema-less Database Design實際上是三個不同團隊爲了解決不同方面的技術問題而做出的方案，但糅合進MoSonic中時，我感到的不是衝突，而更多的是一種不謀而合的美妙。
下篇會繼續講更多一些細節。