Skype 用 PostgreSQL 支撑海量用户

自从 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–

婺源看了油菜花

上周末去了婺源，号称”中国最美的乡村”，看油菜花。橡树网的网友组织的，因为还有杭州尼康俱乐部提供了部分赞助费用，自理的费用极低，而吃住都不错，其乐融融。

很多人去婺源都是为了拍照，不过我们这个团因装备比较齐全，在熙熙攘攘的人流中看起来还是很拉风的。我在其中有一最：设备最差的 … 因为只算随从，所以在人少的地方掏出维修后赠送的佳能 A510 偷着拍了几张。摄影这东西我可不懂，每次随老婆（她的相册）出去受罪，我只能算提供”构思、创意”的。明天就又放假了，大家对付着看吧。

–EOF–

MySQL 优化之 Slow Query Log

从一种 DB 转到另一种 DB 的最初阶段，往往要找自己原来熟悉的工具。拿我自己来说，算是有点 Oracle 的经验，有时被问及 MySQL 优化的东西，就希望找到 MySQL 上类似 Oracle 等待接口或是 SQL Trace 之类的工具，多少有些路径依赖。

Slow Query Log 是 MySQL 的基本 Log 之一。这个优化思路基本上是用 SQL 执行时间 作基准(类似 Oracle 基于等待的优化思想。另外，在 MySQL 中我还没发现根据 逻辑 IO 作基准的方法，这样对于存储层的性能控制就有些不好入手)具体如何操作我就不赘述了。默认情况下，在产品环境中如果临时决定起用该特性是影响可用性的。另外，旧一些的版本时间粒度相对比较大(最小 1 秒钟)。可以通过 Microslow Patch 来解决这个问题(粒度可以到百万分之一秒)。这个 Patch 在开发测试环境也很有用武之地，有些公司的线下开发环境数据不能达到产品环境的规模，如果也把眼光放到抓取执行时间大于 1 秒钟的 SQL 无疑会漏掉很多潜在的问题语句。

在 MySQL 5.0 之后，利用 –log-queries-not-using-indexes 参数可以抓到未使用索引的慢查询。为什么 SQL 没有使用索引，这恐怕是开发 DB 应用的朋友要问的最常见的问题之一。

关于 Slow Query Log 的分析，MySQL 自带有 mysqldumpslow 分析工具，除此之外，也有包装的更好(?)一点的开源工具，比如 MyProfi，以及 Mysql-log-filter。

Sun 收购 MySQL 之后，相信很多人都会对 Dtrace 能否集成到 MySQL 比较感兴趣。其实原来就有人利用 Dtrace 来分析 MySQL 性能问题。不过这个方式门槛还比较高，也没有形成比较清晰的方法论。

网上关于 MySQL 优化的文章汗牛充栋，我这篇就当是读书笔记吧。

–EOF–

PHP 与 Oracle DRCP

Oracle 对 PHP 的支持一直是不错的(只是国内好像 PHP + Oracle 的开发并不多)。 Oracle 11g 中的新特性数据库驻留连接池(Database Resident Connection Pool，DRCP) 对 PHP 应用进一步扩展带来了一种可能。

这个特性应该重点针对 PHP 应用的。PHP 不支持真正的多线程，非持久连接非常消耗 CPU 资源，扩展性也差；持久连接扩展性好了一点，但是又额外占用更多的内存资源(PHP 之父在几年前的一个 Step-by-Step 优化演示的文章中很形象的说明了连接开销对应用的影响)。DRCP 的出现能更好的缓解上述两个问题，其共享连接能跨 Apache 与中间件节点，但共享的连接是基于数据库用户的，比如 Scott 用户登录到 DB 上的所有连接间共享。

Oracle 官方披露的测试数据是，在 4 CPU Intel Xeon MP 2.80GHz 机器上，2GB RAM, 32bit RHEL 4. 支撑到 14000 个链接的时候，CPU 使用率在 65% 左右。这个…还是太惊人了，根据我找到的另外一份测试结果，看来要大打折扣才能有参考性。

–EOF–