需求
250M entities, entities表共有2.5億條記錄，當然是分庫的。
典型解決方案:RDBMS
問題：由於業務需要不定期更改表結構，但是在2.5億記錄的表上增刪字段、修改索引需要鎖表，最長需要1小時到1天以上。
Key value方案
評估Document類型數據庫，如CouchDB
CouchDB問題： Performance？ 廣泛使用？ 穩定性？ 抗壓性？
MySQL方案
MySQL相比Document store優點：
- 不用擔心丟數據或數據損壞
- Replication
- 非常熟悉它的特性及不足，知道如何解決
結論
綜合取舍，使用MySQL來存儲key/value(schema-less)數據,value中可以放：
Python dict
JSON object
實際friendfeed存放的是zlib壓縮的Python dict數據，當然這種綁定一種語言的做法具有爭議性。
表結構及Index設計模式
feed數據基本上都存在entities表中，它的結構為
mysql> desc entities; +----------+------------+------+-----+-------------------+----------------+ | Field | Type | Null | Key | Default | Extra | +----------+------------+------+-----+-------------------+----------------+ | added_id | int(11) | NO | PRI | NULL | auto_increment | | id | binary(16) | NO | UNI | | | | updated | timestamp | YES | MUL | CURRENT_TIMESTAMP | | | body | mediumblob | YES | | NULL | | +----------+------------+------+-----+-------------------+----------------+
假如里面存的數據如下
{ "id": "71f0c4d2291844cca2df6f486e96e37c", "user_id": "f48b0440ca0c4f66991c4d5f6a078eaf", "feed_id": "f48b0440ca0c4f66991c4d5f6a078eaf", "title": "We just launched a new backend system for FriendFeed!", "link": "http://friendfeed.com/e/71f0c4d2-2918-44cc-a2df-6f486e96e37c", "published": 1235697046, "updated": 1235697046, }
如果要對link字段進行索引，則用另外一個表來存儲。
mysql> desc index_link; +-----------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-----------+--------------+------+-----+---------+-------+ | link | varchar(255) | NO | PRI | | | | entity_id | binary(16) | NO | PRI | | | +-----------+--------------+------+-----+---------+-------+ 2 rows in set (0.00 sec)
優點是
- 增加索引時候只需要 1. CREATE TABLE，2.更新程序
- 刪除索引時候只需要 1. 程序停止寫索引表(實際就是一個普通表)，2. DROP TABLE 索引表
這種索引方式也是一種值得借鑒的設計模式，特別是key value類型的數據需要索引其中的內容時。