Tag Archives: Database

为 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

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.png

PL/Proxy 的设计初衷就是在这一层充当”数据总线”的职责,所以,当数据吞吐量支撑不住的时候,只需要增加更多的 PL/Proxy 服务器即可。(虽然随着服务器越多,通信的开销越大,但只要不大于某个规模,似乎还不足以成为比较大的问题)

随着数据总线层的水平扩展,连接池的问题就凸显出来。Skype 在连接池上的解决方案是采用 PgBouncer,PgBouncer 极大地增强了 PostgreSQL 的连接数扩展能力。顺便说一下,”池”有三种级别:Session 池、事务池、语句池。

Skype 另外开发了一套工具包: SkyTools 来进行数据库的维护,主要是解决数据的复制与队列以及失败接管问题。

整体看下来,围绕着 PostgreSQL 的解决方案其实蛮成熟的。BTW,看起来挺适合阿里旺旺的 :)

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