DBA notes

好多 Windows 平台的 DBA 一定比较烦操作系统升级时 "重启动才能生效" 这个问题，可能就是因为这个原因，可能没多少人愿意管理 Windows 平台的数据库。其实 Linux 有的时候也有类似的毛病，对 Kernel 打 Patch 基本也要重启动操作系统，除非你不去理它。而最近 Slashdot 一则关于 Linux 的新闻值得关注， Ksplice: Rebootless Linux kernel security updates，对于非常关注系统可用性的 DBA 来说，这是个很关键的技术改进。

提高可用性技术，前期细致周密的规划是重要一环。比如大文件系统的 fsck 问题，默认情况下达到一定 mount 次数或者超过一定时间，系统会自动启动 fsck 检验操作。而一个运行一段时间的 Linux Server 如果崩溃 reboot 后，文件系统校验时间漫长的叫人绝望。如果最初对这个问题进行预处理，即可避免不必要的停机时间。

另外维护中能尽量积累那些"可用性高"的技术或技巧也是必不可少的。比如 Kernel 重新读取分区表的问题，Fdisk 命令是搞不定的，而这里提到的 partprobe 命令 刚好派上用场。

以前我也记录过类似 Linux 如何不重启而识别新增的 LUN 的话题，积少成多，也就有用了。

--EOF--

Posted by Fenng at 9:09 PM | Permalink | Comments (-1)

继续我的学习笔记之旅。Flickr 的 DBA Dathan Pattishall 在前几天的 MySQL 大会上分享了 Scaling Heavy Concurrent Writes In Real Time (Record every Referral for Flickr Realtime) ，其中介绍了 Flickr Stats 的设计经验。国内好多 Web 站点其实也在设计类似的功能，只是不知道细节罢了。

数据结构原型

字段               数据类型         
Path_query         Varchar(255)        PK         
Domain             Varchar(50)                         
Owner              Bigint                              
When               Date                                
Object-ID          Bigint                              
Object-Type        Tinyint                             
Counts and stuff   Various ints        May be some keys

主键是字符串，开销太大。其他的索引如果做主键，也比较大。当表大小超过内存的时候，插入速度很慢，I/O 能力也上不来。

优化数据结构

数据预处理，通过 CONV(SUBSTR(MD5(Url),0,16),16,10) 把 Path_query 修改为 64 位的 ID (8字节), 主键为 ID+Owner+object+object-type，这个统计信息很容易抽象到一个数据对象，这个索引的设计也在于此。

另外补充一点，利用 PHP 的 ip2long() 和 long2ip() 函数对 IP 地址作预处理，耗费的存储空间只为原来地 25%，这是个很有趣的技巧。

数据 Sharding

对于海量的数据，以一个礼拜为间隔，水平分割。按照不同的数据力度每周一个表，每年一个全局表，再加上一个汇总表。数据量越大，InnoDB 存储引擎针对字符串的索引浪费的空间就越大。单个查询的 I/O 也自然大了起来。

所有应用对 DB 的响应要求 是 300 毫秒。但高并发写入的时候响应时间就糟糕起来。Flickr 的 Java 牛人实现了 Referral 队列，每 4000 条做批量处理。这样 IO 拥塞的就解决掉了。

总体的服务器规模过去 介绍过，对专业版用户的数据是永久保留的，而普通用户则只保留几周，为节省空间，采用 MyISAM 引擎，当用户转为专业版时，迁移数据。

补充一下，抓取 URL 是用的 curl 。最后，这篇 PPT 在线观看。

--EOF--

Posted by Fenng at 9:00 PM | Permalink | Comments (1)

炙手可热的 Facebook 是用 PHP 开发的。随着一些技术交流，逐渐能看到 Facebook 技术人员分享的经验。近期这个 geekSessions 站点上看到 Facebook 的 Lucas Nealan 分享的文档比较有参考价值。

Cache 为 王

任何一个成功的站点都有一套最合适自己的 Cache 策略。

Note：这个层次图画的稍微有点问题，不是严格从上到下的。

The Alternative PHP Cache , APC

Facebook 平均每个用户每天要访问超过 50 个页面，PHP的页面载入时间的优化就比较重要了。在 PHP Cache 层，Facebook 采用了 APC。

Lucas Nealan 的 PPT 举了一个例子，一个页面显示的时间从 4000 多毫秒降到了 100 多 毫秒。在 apc.stat 关闭的模式下，性能还要更好一些。不过需要重启动或用apc_cache_clear() 来通知更新。

Memcached 层

APC Cache 的是非用户相关的信息，而用户相关的数据 Cache 当然是在 Memcached 中。

Facebook 部署了超过 400 台 Memcached 服务器，超过 5TB 的数据在 Memcached 中。这是当前世界上最大的 Memcached 集群了。也给 Memcached 贡献了不少代码，包括 UDP 的支持和性能上的提升(性能提升超过 20%)。

程序 Profiling

Facebook 开发人员大量采用 Callgrind 、APD、 xdebug 、KCachegrind 等工具进行基准性能测试。任何一个 Web 项目，这也是不可或缺，也是比较容易忽略的一环。所有开发人员都应该具备熟练使用这些工具的能力才好。

补充一下：语言的选择

为什么 Facebook 选择 PHP 而不是其他语言? 用Flickr 的 Cal Henderson 这句话就能说明了: "Languages's don't Scale, Architecture Scale"。

从 80-20 的原则看，APC 和 Memcached 是最主要的。在这两个环节上下功夫，受益/开销比要大于另外几个环节。

(上面的图是从 Lucas Nealan 的文档截的，版权所有是他的)

--EOF--

Posted by Fenng at 6:35 PM | Permalink | Comments (11)

自从 MySQL 被 Sun 收购后，相信很多对该收购不放心的朋友会转而看好 PostgreSQL 的前途。虽然比较大的 Web 2.0 站点数据库方案基本都采用 MySQL ，不过也有用 PostgreSQL 并且跑的不错的。今天看到 Skype Plans for PostgreSQL to Scale to 1 Billion Users 这个帖子，对 PostgreSQL 在大型网站应用上的部署算是有了一点了解。

Skype 在数据库上的横向扩展能力以 PL/Proxy 为基础的。其实几乎所有部署 MySQL 的站点也都在考虑 Scale Out (相比 Scale Up) 的扩展方案，也有 MySQL Proxy 这样的产品推出来，只是看起来还不够成熟。PL/Proxy 的设计思想类似 Teradata 的 Hash 机制，数据存储对客户端是透明的，客户请求发送到 PL/Proxy 后，由这里分布式存储过程调用，统一分发，示意图如下：

PL/Proxy 的设计初衷就是在这一层充当"数据总线"的职责，所以，当数据吞吐量支撑不住的时候，只需要增加更多的 PL/Proxy 服务器即可。（虽然随着服务器越多，通信的开销越大，但只要不大于某个规模，似乎还不足以成为比较大的问题)

随着数据总线层的水平扩展，连接池的问题就凸显出来。Skype 在连接池上的解决方案是采用 PgBouncer，PgBouncer 极大地增强了 PostgreSQL 的连接数扩展能力。顺便说一下，"池"有三种级别：Session 池、事务池、语句池。

Skype 另外开发了一套工具包： SkyTools 来进行数据库的维护，主要是解决数据的复制与队列以及失败接管问题。

整体看下来，围绕着 PostgreSQL 的解决方案其实蛮成熟的。BTW，看起来挺适合阿里旺旺的 :)

--EOF--

Posted by Fenng at 6:55 PM | Permalink | Comments (1)