XiaoHui.Net 笑汇程序员论坛
→ 数据库 Database
豆瓣存储经验分享
|
豆瓣存储经验分享
上周六QClub上听了豆瓣的存储经验分享，豆瓣对问题分而治之的策略应用的很到位，有收获。
目前豆瓣的数据量是：
* 200G 结构化数据（关系、广播等，特点：记录小、结构固定、经常关系查询）
* 800G 文本数据（9点的博文）
* 10T 图片
* 6T 音乐
对数据库的关注主要是：可靠性（持久化、一致性），可用性，伸缩性，性能，成本 …
而通常一个数据库只能解决两方面的问题。关系型数据库的优势是一致性和可用性，Key-Value数据库的特点是可用性和伸缩性，所以针对不同类型的数据，要采用不同的存储方式
转自： [url=http://www.surui.net/2010/04/15/qclub-%E8%B1%86%E7%93%A3%E5%AD%98%E5%82%A8%E7%BB%8F%E9%AA%8C%E5%88%86%E4%BA%AB/]QClub - 豆瓣存储经验分享[/url] |
|
豆瓣使用关系数据库的经验：
* 使用 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 |
|