QClub - 豆瓣存储经验分享
Thursday, April 15th, 2010上周六QClub上听了豆瓣的存储经验分享，豆瓣对问题分而治之的策略应用的很到位，有收获。
目前豆瓣的数据量是：
- 200G 结构化数据（关系、广播等，特点：记录小、结构固定、经常关系查询）
- 800G 文本数据（9点的博文）
- 10T 图片
- 6T 音乐
对数据库的关注主要是：可靠性（持久化、一致性），可用性，伸缩性，性能，成本 …
而通常一个数据库只能解决两方面的问题。关系型数据库的优势是一致性和可用性，Key-Value数据库的特点是可用性和伸缩性，所以针对不同类型的数据，要采用不同的存储方式
豆瓣使用关系数据库的经验：
- 使用 InnoDB，并发性能好
- 使用基本查询，避免 join，在应用层做连接处理
- 分离大的文本字段
- 使用 master(rw) - master - slave 结构，读写都使用一个 master，另外一个做 fail-over 的备份，slave 做备份用，双master手动切换，多实例混合部署，没有用 replication，因为存在复制延时。硬盘使用双 SCSI 做 raid0
豆瓣对 MySQL 使用垂直分表，设计时控制好表的宽度，无关数据分开存储（如书、影、音的收藏），单表1亿条数据性能没问题。
使用双master结构便于运维，比如修改表结构时，可以修改备用的 master，然后同步
小文件（图片、博文、音乐）的特点：
- 主要是 get, set, delete请求，一般不会 update
- 高可用性，要有 fail-over 机制
- 占用空间大，10K-5M，增长非常快
- 因为修改少，对一致性要求低
- 访问带有高随机性
对小文件的单机文件系统存储系统可以用 reiserfs 3.x (4.x 不能用)，远程文件系统可以用 WebDAV，比NFS靠谱，要设计要目录结构，备份可以用 rsync。
多机文件系统存储可以用 MogileFS，瓶颈在 Tracker 上，因为文件的索引信息都记录在一个中心节点的 MySQL 上，适合几十万到一百万的量级，机器故障时数据迁移很慢，因为要拷贝大量小文件。
BeansDB 是豆瓣为解决自己的业务场景开发的一款 key-value 数据库，现已贡献到开源社，此物具备以下特点:
- hash 路由，无需中心节点，一个简单的路由表即可
- 数据存储使用 tokyo cabinet
- 读策略：依次读，直到读到数据为止
- 利用 HashTree 同步
- 保证最终一致性，短时间内不保证一致性
- API接口遵循 memcached 协议
目前豆瓣一年多的时间，部署5台服务器，存储了4T，1.5亿个文件，冗余3份
日志文件存储：
- 文件大，10M - 10G
- 重要，不修改，可打包存储
- 数量少，一天几个
- 不能阻塞业务逻辑
- 偶尔使用，可用性要求低
可以使用类GFS分布式存储，豆瓣用的是MooseFS，有FUSE client, Web 界面, 支持 hadoop cluster。日志分析导入数据仓库处理，使用 InfoBright（开源）,商业的可以选择KDB+,更多规模可以自行使用 hadoop 的 map-reduce 构建。
另外豆瓣的全文检索用的是 Xapian
