MoSonic：對SubSonic的分布式儲存、緩衝改進嘗試(3)

接上文。

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)
  • ...
• ...

使用時可以直接這樣：User.FetchById(XXX).properties.user_name。因為一開始已經把Thrift序列化代碼產生做到SubSonic模板時，這裡要給資料多增加一層結構也並非難事；有點水到渠成的感覺。

以後要修改資料結構，直接改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時

邏輯變成這樣：

 

1. 檢查Vector Cache，存在便返回
2. 檢查分布式索引表規則，獲得新的資料庫連接字串
3. 執行查詢
4. 寫入Vector Cache

 

插入資料時，之前僅是更新Vector Cache，現在則需多一步去插入索引表。

實際運行中，因為是先插入資料表，同步更新Vector Cache，後續的插敘已經會命中緩衝；索引表的更新實質變成是備份，可以非同步插入。

Thrift / Cache Money / Schema-less Database Design實際上是三個不同團隊為瞭解決不同方面的技術問題而做出的方案，但糅合進MoSonic中時，我感到的不是衝突，而更多的是一種不謀而合的美妙。

下篇會繼續講更多一些細節。