Tag Archives: PostgreSQL

Cocolog 从 PostgreSQL 迁移到 MySQL 的经验

 Tips: 10 月 9 日我将去南京，参加支付宝 2008 校园招聘 南京大学站。

Cocolog 是日本领先的 Blog 社区，基于 SixApart 的 TypePad 技术框架。运营公司是 NIFTY（最新的调查报告显示，NIFTY 在日本流量排名第 10 ）。前一段时间看到这篇 Migrating from PostgreSQL to MySQL at Cocolog, Japan’s Largest Blog Community ，比较详细的描述了从 PostgreSQL 迁移到 MySQL 的经验，很有参考价值(日本互联网技术特点?)，在这里做一篇学习笔记。

核心系统的支撑软件

Linux 2.4/2.6
Apache 1.3/2.0/2.2 & mod_perl
Perl 5.8+CPAN
PostgreSQL 8.1
MySQL 5.0
Memcached/TheSchwartz/cfengine

都是一些司空见惯的东西, cfengine 是用作软件维护、部署、分发的玩意儿。

初期技术架构示意图

这是我第一次知道 TypePad 除了 SixApart 自己的服务之外还支撑了第三方的站点(孤陋寡闻!)。

初期 PostgreSQL 基本上是用来存储本地注册用户信息。这个阶段数据库分区之前，服务器数量在 10 个以下。

第二阶段

这阶段数据库分区之前，服务器数量在 50 个以下，可以看到 DB 还额外存储了富内容模板等元数据信息。系统各个模块紧耦合，数据库 Schema 变更有些费劲了。

第三阶段

Web API 的引入在一定程度上消除了紧耦合的问题，Memcached 的引入很大程度减轻了 DB 的负担。服务器数量在 200 个以下，未分区之前。

第四阶段

数据库分区之前，服务器数量在 300 个以下，增加对移动互联网的支持能力。这个时候 PostgreSQL 貌似还是单实例的样子。数据超过 100GB，40% 是索引。要忍受比较严重的数据碎片问题，备份是个麻烦事儿。

在此之前，PostgreSQL 服务器在硬件上一直是 Scale Up 的思路，内存从最初的 1GB 扩展到 07 年底迁移前的 16GB，磁盘换到了阵列上，阵列是富士通的 E8000 。国内倒是很少遇到有把 PostgreSQl 扔到企业存储上的案例。

现阶段

这是迁移后的架构示意图。引入了多个 MySQL 实例。从原来的 Scale Up 切换到 Scale Out 的路线上。数据库分区，服务器数量 150 个。

集群软件采用了 NEC 的 ClusterPro 。数据库是共享存储的，不过 I/O 瓶颈应该消除了，因为读的压力分散在每个 MySQL 服务器上，内存承担了大部分工作。写操作的压力在一台存储上，问题不会很大。

实施步骤

1. 服务器准备；
2. 全局写问题（Global Write）　应对策略：写用户信息到全局 DB 中；
3. 全局读问题应对策略：读、写用户信息在全局 DB 中折腾；
4. 迁移序列　应对策略：全局 DB 承担；
5. 用户数据迁移（User Data Move）　应对策略：移动用户数据到用户分区中；
6. 新用户分区（New User Partition）　应对策略：所有新用户直接保存到新用户分区1中；
7. 新用户数据处理策略　　根据需求设定一个策略；
8. 非用户数据迁移。

这几个过程都不难理解，数据迁移的一节倒是值得描述一下：

对上图做个解释(其实也是翻译 PPT 上的注释):

1 Job 服务器提交一个新的Schwartz Job 迁移已有的用户数据，用户数据异步迁移；
2 迁移中的用户发布的留言保存到 Schwartz ，稍后发布；
3 迁移完毕后，所有用户数据存放在用户角色 DB 分区；
4 一旦所有用户数据迁移完毕，只有非用户相关数据存在 PostgreSQL 中。

这个迁移的技术细节其实可能不那么重要，但重要的是必须有个迁移流程的制定过程，任何所谓的迁移，如果没有制定详细的计划，无疑会吃苦头。

迁移后的备份示意图：

最后看一下架构概览图(点击可放大)：

Tip：这个架构图中关于 NAS 部分，可能不那么可靠的。

上面引用的图版权归原 PPT 作者所有。转载我这篇流水帐的网站请不要随便给图片打水印。

–EOF–

P.S. 如果你有耐心看完前面的部分，你或许应该提出如下疑问：

1）为什么要迁移到 MySQL ? PostgreSQL 也是支持分区的啊 …
2) 这其实就是个数据 Sharding (分片)的问题, 作者为啥不直接说?
3) 第五阶段, 服务器数量为什么变少了?
4) 迁移全是在线进行的么? 有没有影响用户访问?

如果一个问题都没有, 其实和没看差不多。

又及：PPT 里面提到的监控指标也需要注意一下，你的网站监控了这些内容么?

response time of each post
number of spam comments/trackbacks
number of comments/trackbacks
source IP address of spam
number of entries
number of comments via mobile devices
page views via mobile devices
time of batch completion
amount of API usage
bandwidth usage

MySQL 大企业级应用可行性分析(之一)

前两天在上海参加技术研讨，讨论了关于 MySQL 的一些面向企业级应用的思路，今天和几位同事开会，也谈及了能否用 MySQL 替代当前 Oracle 的问题。干脆整理一下思路，算是做个备忘。

首先说明一点的是，我不是说 MySQL 没有大企业级的应用，事实上，可以看到越来越多的成功布署 MySQL 的应用，但是，还不够多，还有许多大企业的关键应用还不敢用 MySQL。或许这篇小文能和大家一起探讨一些比较”虚”的东西。

存储引擎

由于 MySQL 自己一直没有一个成熟可靠的存储引擎，估计这让他们深感痛处(尤其是目前最成熟的事务型引擎 InnoDB 又在 Oracle 手里)。MySQL 寄予厚望的 Falcon 在开发了两年多之后，建树不大，而该项目带头人 Jim Starkey 前不久又离开了 MySQL，陋屋偏逢连夜雨。

Sun 会给 MySQL 一个稳健的引擎么? 我看短时间内未必能达到。除非，Sun 从 Oracle 手里把 InnoDB 买回来。

如果进行大企业级应用，考虑到引擎本身的稳定性，似乎可选的也只有 InnoDB 了，但 InnoDB 的备份工具又是收费的。至于 MyISAM ，尽管有人的确喜欢用，但对于并发能力要求稍微严格一点，MyISAM 根本不行。

在线 DDL 锁表问题

MySQL 中，在线对表对象做 DDL 操作是要锁表的，对于可用性要求比较高，而应用变化又比较频繁的环境，这是个非常很糟糕瓶颈。没想到有什么好的办法，除非，像大家开玩笑说的，把所有的表都预留出足够的空闲列，减少类似增加列的变更麻烦。

这个 MySQL 天生的缺陷在 PostgreSQL 中是不存在的，比如创建索引，可以用CREATE INDEX CONCURRENTLY 的方式来减小影响。(MySQL 后续的版本中在逐渐改善这个问题：添加了 ONLINE 关键字)

这个看似是个小问题，但实际上却是对很多人最为困扰的。

在线备份问题

谢天谢地，MySQL 6.0 后终于具备在线备份的能力了。但现在，恐怕比较激进的用户也只能用版本 5 而已。

很多 MySQL 资深用户能够根据自己应用的特点布署适合自己的备份方式(尽管可能也会有缺陷，比如基于时间点的恢复)。

至于另一个常用来衡量 DB 可扩展性的特性：分区，现在 MySQL 已经能够支持了，尽管实现的的确有点晚。而使用 MySQL 的用户，一般都采取 Sharding 的策略对数据进行切分，所以，分区的问题倒似乎并不是最为关键的。

因为是整理思路，这算是这个系列的第一篇。

Yahoo! 的数据仓库: 世界上最大最忙

微软对 Yahoo! 的收购持久战可能让很多人都新闻疲劳了。但今天看到的这个关于 Yahoo！的技术新闻还是值得看一下的：Size matters: Yahoo claims 2-petabyte database is world’s biggest, busiest 。Yahoo! 的 VP Waqar Hasan 在文中披露 Yahoo！的数据仓库当前容量为 2PB。用于分析每月5亿的用户访问行为，每天处理 240 亿次的事件，号称世界上单个最大、最忙的数据库。

尽管有的数据仓库容量要比雅虎的大。但那些 DB 或是存储非关系性数据，或是存储的压缩后的原始数据，不能进行即时分析，雅虎之前的也有数百 T 这样的数据。眼下 Yahoo！数据仓库存储的是结构化、可分析的数据。预计下一年可能膨胀到数十 PB 。eBay 号称数据总量有 6PB ，不过根据一些消息来看，单个最大的 DB 只有 1.4 PB。

Yahoo! 在 2005 年买了一家叫 Mahat Technologies 的初创公司（就是 Waqar Hasan 操刀的)，这家公司以 PostgreSQL 数据库为基础，开发了一个新型 DB，其特点是 基于列 的而不是 基于行 的模式。不难理解，这样数据写入的速度会慢下来，但是读取的速度会快很多【去年的侠客行上，雷鸣在演讲的时候讲过他在百度的时候做的一个优化的例子。和这个思想非常相似，所以当时我说对我”有启发“】。Yahoo! 买了之后，对该产品进行了持续性的改进(内部代号: ELCARO ?) ，比如压缩，并行处理能力加强、优化查询等等特性的添加改进。而针对使用者的接口仍是 PostgreSQL 。这应该也算 PostgreSQL 在顶级企业又一个成功案例。

这么大的数据库并没有采用传统的 SMP 架构构建，而是采用普通 PC 作集群(用了不到 1000 台) 。很明显这是 Share Nothing 而不是 Share Storage 的 DB 集群。通过上述独特的设计方式，能够对此海量数据进行有效的分析，这是个不小的技术革新，也是与 Google Map Reduce 完全不同的计算模式。

让人感慨的是关于世界上的超大数据库一文中罗列的数据，现在看起来已经并不惊人了。以前总说信息爆炸，这个时代刚刚来临。

–EOF–

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–