Tag Archives: MySQL

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

PHP 中执行排序与 MySQL 中排序

此文首发在 InfoQ 中文站。作者：明灵(dragon) , Fenng . Note：要转载的朋友请注意注明这篇文章的第一作者!
这篇文章是dragon 朋友来邮探讨后他做的一个总结。在 DB 中排序还是在 应用程序中排序是个很有趣的话题，dragon 第一份邮件中其实已经总结的很好了，我添加了一点建议而已。现在放上来，与大家共享。这篇文章也投稿到了 InfoQ 中文站 。

Q：列出在 PHP 中执行排序要优于在 MYSQL 中排序的原因？给一些必须在MYSQL中排序的实例？

A：通常来说，执行效率需要考虑 CPU、内存和硬盘等的负载情况，假定 MYSQL 服务器和 PHP 的服务器都已经按照最适合的方式来配置，那么系统的可伸缩性（Scalability）和用户感知性能（User-perceived Performance）是我们追求的主要目标。在实际运行中，MYSQL 中数据往往以 HASH tables、BTREE 等方式存贮于内存，操作速度很快；同时 INDEX 已经进行了一些预排序；很多应用中，MYSQL 排序是首选。而在应用层（PHP）中排序，也必然在内存中进行，与 MYSQL 相比具有如下优势：

  • 1、 考虑整个网站的可伸缩性和整体性能，在应用层（PHP）中排序明显会降低数据库的负载，从而提升整个网站的扩展能力。而数据库的排序，实际上成本是非常高的，消耗内存、CPU，如果并发的排序很多，DB 很容易到瓶颈。
  • 2、 如果在应用层(PHP)和MYSQL之间还存在数据中间层，合理利用，PHP会有更好的收益。
  • 3、 PHP在内存中的数据结构专门针对具体应用来设计，比数据库更为简洁、高效；
  • 4、 PHP不用考虑数据灾难恢复问题，可以减少这部分的操作损耗；
  • 5、 PHP不存在表的锁定问题；
  • 6、 MYSQL中排序，请求和结果返回还需要通过网络连接来进行，而PHP中排序之后就可以直接返回了，减少了网络IO。

至于执行速度，差异应该不会很大，除非应用设计有问题，造成大量不必要的网络IO。另外，应用层要注意PHP 的 Cache 设置，如果超出会报告内部错误；此时要根据应用做好评估，或者调整Cache。具体选择，将取决于具体的应用。

列出一些 PHP 中执行排序更优的情况：

  • 1、 数据源不在 MYSQL 中，存在硬盘、内存或者来自网络的请求等；
  • 2、 数据存在 MYSQL 中，量不大，而且没有相应的索引，此时把数据取出来用PHP排序更快；
  • 3、 数据源来自于多个 MYSQL 服务器，此时从多个 MYSQL 中取出数据，然后在PHP中排序更快；
  • 4、 除了 MYSQL 之外，存在其他数据源，比如硬盘、内存或者来自网络的请求等，此时不适合把这些数据存入 MYSQL 后再排序；

列出一些必须在 MYSQL 中排序的实例：

  • 1、 MYSQL 中已经存在这个排序的索引；
  • 2、 MYSQL 中数据量较大，而结果集需要其中很小的一个子集；比如 1000000 行数据，取TOP 10；
  • 3、 对于一次排序、多次调用的情况，比如统计聚合的情形，可以提供给不同的服务使用，那么在 MYSQL 中排序是首选的。另外，对于数据深度挖掘，通常做法是在应用层做完排序等复杂操作，把结果存入MYSQL即可，便于多次使用。
  • 4、 不论数据源来自哪里，当数据量大到一定的规模后，由于占用内存/Cache 的关系，不再适合 PHP 中排序了；此时把数据复制、导入或者存在 MYSQL ，并用 INDEX 优化，是优于 PHP 的。不过，用 Java，甚至 C++ 来处理这类操作会更好。 [有些类似大数据集聚合或者汇总的数据，在客户端排序得不偿失。当然，也有用类似搜索引擎的思路来解决类似应用的情况。]

从网站整体考虑，就必须加入人力和成本的考虑。假如网站规模和负载较小，而人力有限（人数和能力都可能有限），此时在应用层（PHP）做排序要做不少开发和调试工作，耗费时间，得不偿失；不如在 DB 中处理，简单快速。对于大规模的网站，电力、服务器的费用很高，在系统架构上精打细算，可以节约大量的费用，是公司持续发展之必要；此时如果能在应用层(PHP) 进行排序并满足业务需求，尽量在应用层进行。

–EOF–

明天将参加杭州 OpenSolaris 用户组活动

os_hangzhou_350.jpg明天下午将去参加 InfoQ 中文站主办的 体验基于OpenSolaris的Web/企业应用 活动，这也是杭州 OpenSolaris/OpenSource 用户组的第一次活动。

我应邀将在活动上做个关于数据库的分享，主题为 “设计可扩展的面向互联网应用的MySQL数据库” ，欢迎感兴趣的朋友光临指导。具体时间和地点 ? 就在上面的链接里 …

自从 Sun 把 MySQL 收购了之后，好像关于数据库的市场活动并不大，相反，倒是对操作系统做了一些不遗余力的推广。当然，现在的 Solaris 倒也并非没有长处，ZFS 和 Dtrace 就是两个很有趣的东西，而这两者对 MySQL 都是很好的互补，对 Linux 其实也是很好的互补，尤其是 ZFS ，最近一段时间，越来越觉得 Linux 的 EXT 文件系统在某些场景多少还有点短板。期待明天能听到关于 ZFS 和 Dtrace 的一些内容。

补充：听说 Sina 有一部分机器用了 OpenSolaris，但也应该是试水性质的吧。国内其他网站有没有用 OpenSolaris 的?

–EOF–

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

广而告之： 7月26日QClub杭州站-- 支付宝首席架构师程立与您分享"当SOA遭遇现实"的心得

再说存储引擎

继续上一篇的讨论，记录针对 MySQL 在大企业级商用上我的一些零星想法。网络上到处都有关于各个引擎之间的对比。这里要提醒一点是，注意各个引擎的锁的粒度。InnoDB 是行锁，锁的实现是依赖于索引的，MyISAM 只是表锁。锁粒度是衡量存储引擎的一个重要指标，其能力很大程度上决定并发能力。

至于 TRANSACTION ISOLATION LEVEL，则是另外一个需要衡量的指标。

老生常谈的，某某引擎适合什么类型的应用，归根结底还是由于其实现的机制决定了引擎的特性。

存储层的解决方案

相信没有人愿意在 MySQL 上用 RAW 设备，很多人几乎就是直接把数据文件放在文件系统上(个人认为，对于数据库这样的应用来说，文件系统可靠性还有所欠缺)。我还没发现 MySQL 上类似 Oracle ASM 的解决方案。如果用文件系统，单节点的数据存储能力肯定要受到制约–没有人喜欢把几个 T 的数据扔到一个 MySQL DB 上吧? 一旦某个文件系统故障，麻烦就来了。从这个角度考虑，或许 LVM2 是一个可选的方式。

当然，如果把数据文件扔到 SAN 上也还不错。一方面问题是，现在存储厂商对于 MySQL 的重视长度还远不如 Oracle、DB2 等老牌商业数据库。另一方面，很多 MySQL 用户没有 SAN 环境的，数据都是在本地磁盘上。

固态硬盘与 MySQL

前两天有朋友在上一篇分析留言，提及应注重闪存的应用。其实还不如布署固态硬盘 (SSD) 对 MySQL 可能的影响问题。 相信现在有很多企业需要在 DB 的 IOPS 上寻求突破，SSD 是个可能的突破口，但从目前我收集到的数据来看，还没有足够的数据说明启用了 SSD 的 MySQL 能有预期的数量级上的 IOPS 提升。

商业支持

现在 MySQL 的背后有 Sun ，但是，如果不购买服务的话，到哪里去找比较正规的商业支持(我是说软件集成商)? 即使购买了服务，如果问题出在存储引擎上，MySQL 能给即时、有效的技术响应么? 这也是 MySQL 没有自有存储引擎的一个弱点，因为衔接的环节多，一旦有商务上的问题，很容易陷入扯皮阶段。

–思路中断，这是这个系列不成熟的第二篇。如果有第三篇，我倒是想写几点关于 MySQL 的设想。

–EOF–

此文作者:, 位于 Database 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.