分类归档: Database

eBay 的 Personalization Platform 采用 MySQL

过去写过很多关于 eBay 数据平台架构的帖子，过去eBay 的信息架构里 DB 都是采用 Oracle 的，大多数 DBA 朋友也都知道 eBay 在 Oracle 方面的技术搞得非常好。这次的 The 2008 MySQL Conference & Expo 披露出来的信息，eBay 在 MySQL 上做了很大胆的尝试，eBay Personalization Platform 就是用 MySQL 打造的。Sun 当然不会放弃这个大好的宣传机会(这两家在技术上的合作一向也比较多)，所以年度最佳应用给了 eBay (一同获奖的还有 Virgin Mobile France 和 Facebook )。

面临的应用场景：客户端 Cookie 最大 4K，如果要传递更多定制化信息就不好搞了。作为电子商务站点，肯定有要为用户提供更具有关联性的商品信息的业务需求，这样就要跳出原有的窠臼。通过数据库集群来存储类似的信息就是有必要的，但 eBay 原有 Oracle 数据库上的压力已经很大。

eBay 采用 MySQL Memory Engine 做数据库 Cache 层解决方案(如果纯粹用 Memcached 类似的方案也不太适合的，读写比例接近)， eBay 工程师 Igor Chernyshev 对内存引擎做了质的改进，而这些改进是开放出来的(Mysql-heap-dynamic-rows 项目，对 VARCHAR 列的内存开销算法做了革命性的改进)。另外一个 Patch 扩充了并发能力，一台普通的 Sun 4100 上能支撑 20000 个并发连接。每秒钟处理 13000 个 TPS，读写各半。25 台机器组成的集群，每天支撑 40 亿次的读写请求，为每个用户传递的定制数据平均大小 40 K，从 4K 到 40K ，足够多的定制信息可以存储了。

架构示意图(来源)：

这个个性化平台系统虽说关键，但是存储的数据并非不能丢失的。这也是 eBay 大胆采用 MySQL 的一个考虑因素吧。

MySQL 更大规模部署时代似乎来临。

–EOF–

为 MySQL 选择更合适的硬件

MySQL 爱好者关注的 2008 MySQL Conference & Expo 落幕后，很多文档都能看到了。今天读了一下这篇 Scaling Out MySQL: Hardware Today and Tomorrow。感兴趣的朋友也不防下载下来研究一下。

用什么样的硬件做 MySQL ，真不是三言两语能说清楚的。不过该讲座中还是能总结出来几点关键点的。

CPU 选择

首先如有可能就选择 64 位CPU，这样才可以安装 64 位操作系统，有了 64 位操作系统才能利用好更大的内存。如果非要抬杠的话，不是 64 位芯片也可以安装 64 位操作系统，也就是 Intel 的 EM64T 的解决方案(这也是文档中没提及的) 。

我个人倒是比较喜欢 AMD 64 位 CPU 的，物美价廉，性能也不错。

注意： MySQL 在多核上的 Bug 问题。

内存，来者不拒

第二点是尽可能配置比较大的内存，当然，只配置内存如果 MySQL 参数配置有问题，还是摆设，如何设置各个引擎的 Cache 相关参数，够写一本书的了。

现在市场上内存是越来越便宜了。我个人的感觉内存降价的程度比 CPU 和硬盘都夸张很多。所以，考虑到人力越来越贵，内存越来越便宜，配置服务器的时候就别太吝啬了。

硬盘–唯快不破

国内用 MySQL ，绝大多数都是直接仍在本机磁盘上的。这个磁盘的选择要慎重一点点。尽量选择 15K 而不要 10K 慢速磁盘，大多数数据库的磁盘问题都在速度上，如果只在磁盘上多花费 30%的钱而能得到总体性能的 30％收益，那么还是值得的，而容量多数情况下不会出现问题，现在的硬盘容量就是一个大。

至于选择什么类型的磁盘，SCSI 与 SAS 都可选，SATA 倒是够便宜，特定的应用再考虑吧。

这三板斧看是简单活，但是实际的应用场景下可未必就能做出更优的选择。最简单的东西也有人不知道不是?

–EOF–

用 Oracle EM 管理 MySQL

一个很有意思的技术嫁接。Pythian 发布了一个 MySQL 插件，通过该插件，Oracle 10g 的 Enterprise Manager Grid Control 能够用来管理 MySQL 。

在 Oracle 10g 刚发布那会儿，EM 的地位在整个链条中倒是挺重要的，几年下来，似乎并没有占领多少市场。我个人觉得这个工具挺”重”的，倒是很少看到有 DBA 用这个工具。

尽管这个 MySQL 插件应用场景可能不多，但这还是第一次看到第三方给 Oracle EM 带来扩展能力。

比较关注即将召开的 The 2008 MySQL Conference & Expo，Sun 收购 MySQL 之后第一次大规模亮相，能带来什么? 新版本的特性基本了解了，还有呢?

Updated: InnoDB Plugin 1.0 for MySQL 5.1 也需要关注一下。

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