Archive for the ‘Facebook’ tag
大系统的数据量级
首先需要说明这篇文章的来源是这里[1]
另外发表的时间是2010年的6月30号，数字只会越来越大。
几个计量的单位需要注明一下：
1 PB = 1024 TB
1 TB = 1024 GB
GB 以下大家肯定知道了。
Facebook:
- 36 PB 的未压缩数据
- 2250台机器
- 23000个 core， 这么算下来平均一台机器10个core，看来都是很高级的机器，像什么 nehalem 这样的机器吧。
- 一天处理 80 – 90 TB的数据
Yahoo：
- HDFS里存放着70PB的数据
- 全球有170PB的数据
- 34000个服务器
- 每天处理3PB的数据（是Facebook的36倍）
- 每天流过Hadoop的数据有120TB（处理的25分之一经过Hadoop）
Twitter：
- 每天 7 TB 的数据进入 HDFS
LinkedIn：
- 120 Billion 个关系（大嘴牛想象的关系应该算作是两个点之间的一条边，那么如果按照每个人之间都认识来计算，那么LinkedIn 的注册人数大约有 500000，当然这只是一个理论上的最小值，实际上这个图应该是稀疏的，实际人数远远大于这个数字。）
- 每天的 Hadoop 工作有 82个。
- 中间数据有16 TB
- 只有两个工程师（这个实在太让大嘴牛感慨了）
对程序员的三大误解
以大嘴牛的个人经历，大嘴牛觉得其他行业对于咱们干 IT 的，或者说普通的开发人员，存在着三大误解：
误解一：程序员都会修电脑。
别人一听你是个学计算机的，马上就会想到家里的电脑好像启动不了了，需要你帮个忙，以为你一到，电脑马上就起死回生。大嘴牛已经数不清多少次给这个阿姨，那个叔叔重装过无数次电脑，简单的修理了很多东西，换换内存，更新硬盘等等。要知道，其实，不是每个做开发的都什么熟悉计算机硬件，老实说，我们的实用知识可能还没有数码商铺里面到处吆喝的小哥来的精通。
误解二：程序员都会做网站。
“哦。你学计算机的啊？我们公司要做一个简单的网站，帮个忙吧？”要知道，不是每个学计算机的人都会做网站的，这个观点无疑贬低了网站开发的难度，谁一个人可以随便做出一个 facebook 来？当然了，话也可以反回来说，有些低质量的网站确实只需要通过 GUI 工具拖动来拖动去就可以实现的。
误解三：程序员都会偷帐号。
“我的 QQ 号被盗了，帮我弄回来吧！” 这种需求也是经常对程序员说的，殊不知，这个观点混淆了一个普通的开发人员与一名黑客的身份。要知道，不是每个开发人员都会、都愿意（即使他有这样的能力）做这样的事情。
Facebook中使用的MySQL
大嘴牛最近对数据库突然感兴趣起来，今天又看了这个视频，讲的是在Facebook公司中使用MySQL的情况。
没有看到可以下载keynote的地方，所以，大嘴牛就在这里每张截图了一把，然后尝试着翻译，主要是增进自己的理解，也希望各位看起来更加方便 
页1
- 有n多台服务器
- 每台服务器上都进行了数据切分
- 主从备份
- 从去年开始进行了多次比较重要的版本升级
- 使用的一直都是InnoDB的数据引擎
- 在MySQL之前利用Memcached做缓存
页2 负载类型
- OLTP的负载类型
- query一般都很快
- 简单的连接操作
- 短事务
- 二次索引对性能很重要
- 有些行访问非常频繁
页3 一个繁忙的数据库
- 查询时间：7ms的读；20ms的写
- 每秒网络流量：高峰26GB；平均21GB
- 每秒查询数：高峰13M，平均10M
- 每秒读取的行数：高峰370M，平均210M
- 每秒修改的行数：高峰3.5M，平均1.9M
- 每秒InnoDB的磁盘操作次数：高峰4.4M，平均3.3M
- （可以看到facebook的访问是读远远大于写，大约有100倍）
页4 团队
- 现在有8人负责运营
- 4人负责MySQL的开发和性能调优
页5 目标
- 不要拒绝一个连接请求
- 及时完成所有的查询操作
- 允许负载按照优先级进行操作
- 最主要的目的还是增加每个服务器的每秒查询数
页6 我们做了些什么
- 让他们变得更快 – 包括查询、schema、处理器和整个系统
- 出事了需要救火
- 让其他人更加方便，开发地更快，我们提供这样的平台
页7 让MySQL更好
- 性能：使之在现代的硬件设备上更加出色
- 有效性：让从备份的MySQL可以抵御crash；同时让回复变地更快
- 有管理性：监测load
页8 通常MySQL并不是主要的问题
- 很多事情会影响性能：文件系统、硬件、IO调度器、应用程序、schema
- 监测数据的缺乏使得人们很容易指责MySQL
- 性能调优十分困难，需要专家的介入
页9 让查询变得更快
- 通过limit的换页操作可以是O(n^2) （大嘴牛不是很懂这句话，有谁解释一下么？）
- 让平常的事情变得快捷
- 长事务会影响并发数 -将对写入频繁的行移到事务的最后
- 使用查询注释来支持调试（大嘴牛有点迷茫。。。）
页10 让schema变得更快
- 和性能极其相关的查询必须是通过index的，否则会很慢
- 如果可以知道有些index是从来不用的，可以考虑删除他们
- 使用InnoDB的附加功能：主键扫描是走index的；主键的列在二次索引中
页11 让处理器更快
- 使用给予帐号的连接限制（大嘴牛觉得有点像性能隔离）
- 将更多的应用移动到独立的帐号上
- 有些时候，鱼和熊掌无法兼得：长事务和InnoDB的purge操作；带读锁的清空表和一个繁忙的主服务器
- 增加监测
页12 让系统更快
- 文件系统由ext-3变成XFS
- 对XFS进行调整
- 将IO调度从cfq改成deadline
- 增加innodb_thread_concurrency从8到32
- 减少innodb_lock_wait_timeout从50到15
- 取消InnoDB的预读机制
页13 我们是怎么做的
- 得到了其他人的帮助
- 阅读代码、搜索
- 先Hack，然后再自动化（这里特别提到了给这个工具取个好的名字，这样方便运营部门和你进行沟通）
页14 其他人的帮助
- MySQL的支持
- Facebook的运营部门
- MySQL-5.1 5.5
- Replicaiton – 基于行的，半同步
- Percona – 借鉴了很多想法
- Maatkit – mk-query-digest, mk-slave-prefetch, mk-upgrade
页15 通过调优MySQL就可以解决的问题
- my.cnf参数
- 有时候使用gdb
页16 性能调优
- 我们想知道线程什么时候被block并且被什么所block
- 收集以及合并这些线程栈的信息
页17 一个很不错的性能工具
- 自己看图吧。。。呵呵
页18 通常的查询
- 如何决定查询的来源：使用tcpdump；使用慢查询的log和mk-query-digest
- 如何决定查询错误的来源：使用tcpdump
页19 最多的五个查询
- 大嘴牛觉得还是看图吧，上面很清楚，怕万一抄错了。。。
页20 挑战
- 多个主服务器，这个时候的冲突消除
- 如何有效利用最新的硬件
- 在线操作
- 在load下尽可能表现地平稳
- 监测
页21 最大的每秒IO数
页22 在load下尽可能表现地平稳
页23 未来
- 和其他系统比如HBase，Cassandra，Hive分享数据中心
- 对性能的专注：SSD、多核和大内存
- 关注社区：让PBXT,Maatlit,MariaDB,Drizzle,XtraDB和XtraBackup更好