minx_blog

minx_blog

http://blog.livedoor.jp/nipotan/archives/50538571.html

blog内容：

------------------------

■mixi 是？

・根据Alexa，访问量是国内第三

・active用户率 70%

・每个用户停留的平均时间是国内第一 (从「ネットレイティングス」调查)

■系统构成

・所谓的"LAMP"构成

・Linux 2.6

・Apache 2.0

・MySQL (4.0, 4.1, 5.0)

・Perl 5.8

・memcached

・Squid

・从mod_perl 保存到 memcached 后调用 HOT OBJECT ，如果没被保存就从 DB 调用。

■MySQL

・现在是 100 台以上

・每个月平均增设 10 台

・non-persistent connection

・大部分的 Table Type (Strage Engine) 是 InnoDB (日志系是 MyISAM)

・DB partitioning

・--skip-grant-tables (建立时去掉权限和认证实现高速化)

■初期的 DB

・不断增加 slave、 write到master、从 slave read

・read 虽然分散了，但 write 频率由于过高，发生数据延迟

■MySQL 的参照和更新比率

・日志

・read 85%

・write 15%

・信息

・read 75%

・write 25%

■DB partitioning (DB scale)

・vertical partition - 纵向 (每个用户)的scale -

・需要一次性作业时，实时的移行比较难。

・horizontal partition - 横向 (每个表)的scale -

・对象是比较慢的表 (信息、日志等)

・→ 取名叫level 1 、采取了这个方法

■到level 1 的移行手顺

・同时往OLD DB 和 NEW DB 里 write 、 从 OLD read

・从OLD 到 NEW INSERT (移行) 完了后、允许从NEW read ■partitioning 的问题点

・不能 JOIN

・取benchmark的结果是、比起JOIN、从应用软件调用两次更快，所以没有问题

■level 1 的问题点

・但是，光日志和信息等的 partitioning 就变得很慢

・→ 采取了level 2 (vertical partition)

■level 2 的 partitioning key

・user id, message id 等

・如果 partitioning 细一点，性能tuning可能容易些，但partition map会变大

■partition map for level 2

・不能简单地放到 configuration file 等

・manager base

・写入DB

・algorithm base

・如果用算法算出更新和参照的地址， read 和 write 将变成同样的节点

■manager base

・比如，向manager DB 询问 user_id = 14 的节点地址

・优点

・容易管理

・容易追加新的节点

・节点间的数据容易移行

・缺点

・节点询问的查询将在 manager DB 频繁发生

■algorithm base

・node_id = (member_id % 2) + 1

・优点

・不需要向 manager DB 询问

・缺点

・不易管理

・很难平衡

・需要同时运行相同配置的机器

■节点的追加方法

・old_node_id = (member_id % 2) + 1

・new_node_id = (member_id % 4) + 1

・算出write 地址。如果上述的两个计算结果不同，write 就在两个地址进行

・追加之前，read 在 old 进行

・移行完了后、read 和 write 都在新的节点进行、删除旧的节点中的数据

■partitioning 的问题点

・为了显示成员的昵称、或community名等，查询 DB的次数会变多

・很小的数据保存到 memcached

■缓存

・使用 memcached

・memcached 和 mod_perl 放到相同的机器里运营

・内存： memcached 确保 2GB、mod_perl 使用 2GB (搭载4GB)

・memcached 有 39 台

・persistent connection 、一台约有6,000个 连接

■图片

・半年前左右，大概有8TB

・每天平均增加23GB

・管理使用的是 MySQL、实际的图片是保存在文件系统上

■图片文件有两种

・数量少、但访问频率比较高的图片

・用户的icon

・community的icon

・数量也多，size也大、但访问频率不高的图片

・日记的照片

・相册

・community揭示板上传的照片

■访问频率高的图片

・size达到数百 GB

・按 FTP 保存、通过Squid

・利用 3rd party CDN

・因为缓存的hit率比较高 (约 96%)、所以storage的hit率比较低

■访问频率低的图片

・size达到了数 TB

・比起配信、存贮比较难

・特性：新的文件访问频率高

・缓存的hit率很低 (一个都达不到 10 次的程度)

・不使用Squid 、直接从storage配信

■manager DB

・向 manager DB 询问图片的保存地址

・询问结果要有两个地址

・保存到那两个地址 (为了备份等目的)

・显示方法是、mod_perl 一方向 manager DB 询问图片的保存地址、构成FQDN后、

用户直接输入该 URL 显示

■TO DO

・也想研究一下使用 MySQL Cluster 等

・算法基础比较难

・consistent hashing

・linear hashing

・level 3 partitioning

・比如、想用時系列 split

------------------------------------------------------