Suave’s Blog » Blog Archive » QClub - 豆瓣存储经验分享

上周六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