Tag Archives: Arch

Amoeba — 国内开发者贡献的数据库 Proxy 开源项目

Amoeba (阿米巴, 就是变形虫的意思) 是陈思儒开发的开源软件项目。尽管很早就知道了他的这个项目，但是一直没时间测试一下。软件设计目标 (分布式数据库 Proxy) 应该是参考了 MySQL Proxy 的设计思路，版本的更新也挺快。有机会去采访一下。

作者现在把 Amoeba 定义为一个框架，在其下面已经有 Amoeba for MySQL 与 Amoeba for Aladdin 两个产品了。

Amoeba.png

其实国内开发者贡献的数据库也有一些，还有一些被错过的项目……

–EOF–

Cocolog 从 PostgreSQL 迁移到 MySQL 的经验 

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

logo_cocolog.gifCocolog 是日本领先的 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 自己的服务之外还支撑了第三方的站点(孤陋寡闻!)。

Cocolog_phase_1.png

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

第二阶段

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

Cocolog_phase_2.png

第三阶段

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

Cocolog_phase_3.png

第四阶段

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

Cocolog_phase_4.png

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

现阶段

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

Cocolog_phase_5.png

集群软件采用了 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. 非用户数据迁移。

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

Cocolog_data_migrate.png

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

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

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

迁移后的备份示意图：

Cocolog_data_backup.png

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

Cocolog_Overview.png

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

Greenplum : SQL + MapReduce

提起 MapReduce ，第一直觉会想起 Google 的 BigTable + MapReduce 经典组合。MapReduce 已经是大规模集群计算”杀人灭口、居家旅行”的必备之物了。而 SQL+ MapReduce 无疑是充满想象力的，意味着 BigTable 可以用 DB 来替代，DBA 们感觉有戏了。

Greenplum 设计初衷是面向大规模数据分析的，能轻松扩展到 Petabyte 级别，通过 Greenplum 的并行数据流引擎能够让程序员玩 MapReduce， DBA 跑 SQL ，可谓两全其美。

Greenplum_overview.jpg

类似的思路已经给数据仓库市场带来了一场革命，Greenplum 的间接竞争对手其实应该是 Hadoop 。Teradata 好日子不多了。

–EOF–

Updated: Aster 也是和 Greenplumn 相类似的架构:

Aster_architecture_png.png
有趣的是，MySpace 采用了 Aster ：
Aster_Myspace.jpg

《Web 信息架构》 读后随感

IA.gif这本书也不写书评了，写也写不过小容的这篇《敢问北极熊，路在何方？》，何况小容在信息架构方面已经有比较深入的钻研了。

小容把这本书列为信息架构师必读书之一。我也是因为这个豆列对这本书感兴趣的。之前，什么是信息架构，什么人是信息架构师，还真是不容易搞明白(我曾经接到过的名片中，也没有一个人自称是信息架构师的)。

什么是信息架构呢? 这本书其实也没给一个清晰的定义，似乎有些可意会不可言传的意味。我的理解信息架构做的事情就是组织、梳理总体信息使之达到更可用。如果这样说的话，大一点的面向内容的 Web 站点（比如淘宝）都需要信息架构师的。又比如中大型门户网站，如果缺乏整体的内容梳理、组织，访问用户就不能得到更好的用户信息获取体验，甚至会信息偏差、缺失，对于网站来说，是无形中的损失。

信息架构师，国内有哪家公司有这样的职位么? 应该没有。

这本书也是我认为的 Web 2.0 网站架构不可或缺的图书 之一。当然，CTO 们是最应该看看洗洗脑，问题是，CTO 们都在开会呢，哪有时间看书哇。

附注： 购买《Web 信息架构》请点击。在下一篇，我可能说一下有关时间管理。

–EOF–