Database 类别下的文章

贴出Troubleshooting Oracle Performance 一书第一章《性能问题》的翻译稿的部分节录(初稿)。排版有点差。请多提意见。翻译的过程得到了很多朋友的大力协助,最后我会单独一一致谢!

TOP.jpg
(此书中文名字还未敲定)


如何解决性能问题?

简单而言,一个应用的目标是为使用它的业务提供便利。所以,优化一个应用性能的理由就是要最大化这种便利。这并不意味着性能的最大化,而是找到成本与性能之间的最佳平衡点。实际上,优化任务包括的努力总要从你期望获得的好处得到补偿。这意味着从商业的角度看,性能优化不总是有意义的。

业务视角 vs. 系统视角

优化一个应用的性能是为了给一个业务提供好处。所以当你着手接近(approaching)性能问题的时候,必须先理解业务问题和需求。然后才跳入应用的细节。图1-2演示了一个具有业务视角的人(一个用户)和一个具有系统视角的人(一个工程师)之间的典型不同。

TOP_CH01_01.png

图 1-2. 不同的观察者有不同的角度

认识到两种视角之间的因果关系是重要的,虽然结果必须从业务视角来识别,其原因必须从系统视角来确定。所以,如果你不想去诊断不存在或不相干的问题(强迫调优失调症),理解从业务视角看问题就变得更重要 -- 即使这需要更多精细的工作。

把问题分类

对付性能问题的第一步是要从业务视角确定它们并为每个问题设定一个优先级和目标。如图1-3所示。

从业务视角来确定问题 > 设定每个问题的优先级 > 设定每个问题的优化目标

业务问题不能通过观察系统统计发现,而必须从业务视角来确定。如果代之以监控服务等级协议,很明显,可以从没有满足期望的操作来确定性能问题。否则,除了询问用户或者负责的人之外没有其他可能性。这种讨论将涉及一系列操作。例如:注册一个新用户,运行一个报告或加载一批可能很慢的数据。

你知道哪些是有问题的操作,就该给他们排个优先级了。考虑类似这样的问题:如果我们只能处理5个问题,应该如何做呢?当然,最好是全部解决它们。但有时候时间或预算是有限的。此外,缺乏必要措施的情况下,不可能解决不同问题的相互冲突。要强调的是在设定优先级时,当前的性能可能是不相干的。例如,如果你处理一整套报告,不一定最慢的那个具有最高的优先级。可能最快的那个也是执行最频繁的那个,因此有可能具有最高优先级并需要首先优化。再说一次,是业务需求在驱动你。

对每项操作,你应当为优化设定一个可量度的目标。诸如"当创建用户按钮按下以后,处理时间最多2秒"。如果性能需求甚至服务等级协议可以得到,可能目标已经知道了。否则,再强调一次,必须考虑业务需求去确定目标。注意,没有目标就不知道何时停止研究一个更好的解决方案。换言之,优化可以是无止境的。记住,努力永远要和获利取得平衡。

解决问题

诊断整个系统比诊断一个单独的组件要复杂得多。因此,任何可能的时候,你应当一次只解决一个问题,简单地从问题列表按照优先级从高到低的顺序解决。

对每个问题,如图1-4所示,必须回答3个问题:

  • 时间花在哪里了?首先,你必须确定时间花在哪里了。例如,如果一个特定操作用时10秒,你必须找到这10秒里绝大部分花在哪个模块或组件。

  • 时间是如何耗费的?一旦你知道时间花在哪里了,你必须找到时间是如何耗费的。例如,你发现应用用了4.2秒在CPU上,0.4秒做I/O操作,5.1秒等待另一个组件发出队列出队消息。
  • 如何减少时间耗费?最后,才是找出怎样使操作更快的时候。要做到这个,重要的是聚焦到处理中最大时间消费的部分。例如,如果I/O操作占整个处理时间的4%,那么即使它很慢也没必要对他进行调整。
时间花在哪里了? > 时间是如何耗费的? > 如何减少时间耗费? 

要注意由于副作用的益处,有时候修复一个特定问题的同时也会修复另一个问题。当然,相反的情况也会发生。采取的措施可能引入新的问题。所以,很有必要认真考虑修复过程中可能引起的所有副作用。显然,所有改变在应用到生产环境前都要经过仔细测试。

--EOF--

SQL 标准

前段时间因为写稿的缘故回顾了一下过去几年来的 SQL 标准的事儿。如果不考虑太久远的 SQL/92(SQL2) 的话,那么自从 SQL:99 之后,SQL 标准一共发布了三版。

SQL:2003

这个版本针对 SQL:99 的一些问题进行了改进,支持 XML,支持 Window 函数、Merge 语句等。对于 Merge 语句,很多从事数据仓库的朋友耳熟能详了。这个东西也是先有了事实标准然后纳入规范的。且说 SQL:99 发布后,各大数据库厂商纷纷宣布新的版本中对该标准的支持,这是他们一贯的姿态。

SQL:2006

继续增强 XML方面的特性。这个版本发布后,几乎没什么动静。增强 XML 对数据处理的能力。实际上,至少在现在应用中发现 XML 多少让大家都高估了它,也或许背后有商业力量驱动吧。有几家公司不是要凭借 XML DB 超越对手来着?

SQL:2008

去年发布的。几乎没看到有技术圈子的人讨论这个事情。这个版本其实还是和 XML 较劲。从SQL:99 到 SQL:2008,可以看到标准修订的周期越来越短,多少也反映了对技术的需求变化之快。

--EOF--

近期在和几位同事一起翻译这本 Troubleshooting Oracle Performance (TOP),这是2008 年国外 Oracle 相关书籍中唯一一本值得期待的作品。

本来撺掇同事童家旺写书,不过他谦虚到底,说宁愿翻译,而且一般的图书看不上,只对这本 TOP 感兴趣,家旺慧眼识珠,我也只得勉为其难,助他完成这事儿(其实我对这书也非常感兴趣)。翻译图书是吃力不讨好的活,考虑到各自工作也比较繁重,又拉来同事胡怡文,三个人乐观估计可以拿下这本厚达 600 页的大作。没想到几个月过去,还是耽误了进度不少--出版社估计已经准备扣稿费了 :)

TOP.jpg

这本书的作者Christian Antognini,对 Oracle 数据库的理解精深,凭借此书已经奠定 Oracle Guru 地位。其人也是 OakTable 的成员,说起 Oak Table ,这是一群 Oracle "科学家(Scientist)" 的圈子,没有几手绝活只凭忽悠那是不能位列其中的。

目前这本书已经倒了后期校稿阶段,近期准备放点样章上来供大家参考。翻译得是否得体,亦或佶屈聱牙,还请各位别吝惜手里的板砖,尽管拍来。

--EOF--

Greenplum 短板

初接触 Greenplum 的确让人挺惊艳的,计算能力给习惯于 RDBMS 传统处理能力的 DBA 会留下很深刻的印象。有点一招鲜吃遍天的感觉。

Greenplum 还可以结合 Solaris 进行虚拟化 -- Sun 任何时候都能搭配上自己的东西。

GreenPlum Solaris.jpg

看上去都很美,问题就是海量数据每天怎么导入到 Greenplum 中来? 借助传统的 ETL 工具(Informatica / DataStage ...) 或者自己写 ETL 功能脚本来做。这就是个麻烦事。海量数据的载入与导出,对于 Greenplum 来说,似乎只能用传统的老办法。如果 Greenplum 带一个 ETL 工具就真的强了。

在大哥大电话刚流行的年代,有个笑话说,发明家发明了一款超小超轻的手机,向另外一个人推销,价格还贼便宜。顾客买下刚要走,被发明家叫住:这里还有个大箱子是送给你的。这是什么? 这是这个手机的电池......

--EOF--

Greenplum 支持的这个 Bizgres 最近两年倒是好像停滞了。免费的午餐不是没有,但不会长久倒是真的。

2008年数据库技术领域掠影

此为《程序员》杂志投稿。应该刊登在 2009 年第二期。

"预测"不是件容易的事儿,"回顾"就好操作的多。2008 年发生了很多大事,相比之下,数据库技术领域的这些事儿多少有些微不足道。

0) Sun 收购 MySQL

2008 年初第一笔业界大并购,在上一波.com 大潮中 Sun 赚得盆满钵满,在这一波 Web 2.0 大潮中,Sun 还要做 Web 2.0 中的这个"点"(Dot)? 我个人对此并不看好

这是今年数据库领域的最大的事件,但也仅此而已,一年下来,MySQL 联合创始人 David Axmark 都因为"痛恨每天都要遵守的各种制度"从而离开了 Sun ,而到目前为止也没看到 Sun 针对 MySQL有什么新东西拿出来,倒是狂推预装了各项软件的硬件盒子。前不久发布的 MySQL 5.1 GA 质量更无法让人满意,很多 MySQL 旧将纷纷抱怨,连著名的 MySQL Performance Blog 也不失时机的抛出"MySQL 质量将不再如昔"的论断,大浇冷水。

1) Amazon 推出 SimpleDB

云计算喊了一整年, Amazon 也没闲着,不停地推出新服务。SimpleDB 服务让Jeff Bezos 把手伸向数据库服务,现在仍看不到该服务有大行其道的趋势,但是"提供数据索引与查询的核心数据库功能的 Web 服务" 无疑会逐渐吸引更多潜在的用户。到了年底,Amazon 干脆打出了在一段时间内 SimpleDB 免费的服务来招徕用户,用心良苦。

最近若干分析家下了论断 "未来网络产业将仅剩亚马逊与 Google 两强相争",的确,Amazon 的技术实力不容小视,在 2009 年相信有更多精彩。

2) 主流存储厂商试水 SSD

让人没料到的是 EMC 作为业界存储领头羊,会率先推出支持 固态硬盘(Solid-State Drives, SSD) 的存储设备,Sun 、HP 等厂商也都不甘落后,纷纷宣布将拥抱 SSD。确实,SSD 的某些特性表现是如此抢眼,很多 DBA 都等着它来解决或者缓解 I/O 问题呢,毕竟这是近年来能看到的最大的硬件领域的突破。"钱能解决的问题就不是技术问题",可惜,目前光有钱,买回来的 SSD 可能还是解决不了问题。SSD 的可擦写次数问题仍然让很多用户心下狐疑。

相信2009 年会是 SSD 爆发的一年,主流存储厂商都会纷纷推出支持 SSD 的产品。假以时日,SSD 应该不负众望。

3) Oracle 联手 HP 进军硬件领域

今年 Oracle 整体在 DB 方面实在没什么亮点,如果非要说有,那么在 Open World 上亮相的 Exadata Storage Server 倒是值得一提。

微软和 IBM 这一年来尽管都有升级产品推出,但实际上也就是升级产品推出而已,仍看不出什么新生机。其实很多用户已经非常厌倦不停地增加新功能的软件新版本,每发布一个版本不失时机的宣布打破什么 TPC-C 记录之类的事情已经难以引起用户兴奋。如何在廉价硬件上实现大规模平滑扩展是所有的数据库厂商必须要面对的问题。

4)面向列存储的数据库技术

面向列的数据库(Column-Oriented Database)这不是什么新技术,但是非常适合某些数据分析或者统计类的应用需求。常见的RDBMS 都是面向行(Row-Oriented Database)存储的,在对某一列汇总计算的时候几乎不可避免的要进行额外的 I/O 寻址扫描,而面向列存储的DB 能够连续进行 I/O 操作,减少了 I/O 开销,从而达到数量级上的性能提升。

其实在 Google BigTable / Hadoop HBase 中很早就看到这一思想的运用,在过去这一年中,列存储数据库也更多的引起了重视。

5) GreenPlum= MapReduce + SQL

MapReduce ,让很多面向数据分析的 DBA 还是挺眼馋的,GreenPlum 的出现把 MapReduce 和 SQL 有机的衔接起来,给海量数据分析能力带来了新的可能。年末的时候, GreenPlum 又宣布进军中国市场,不知道用户实际接受程度如何。

顺便说一下,GreenPlum 背后的大东家是 Sun。

6) 从 Drizzle 到 Percona XtraDB 存储引擎

MySQL 的生命力不在大公司手中,而是来自开源技术、Web 2.0 网站的需求上。Drizzle 这个"精简 MySQL" 版本的出现多少证明了这一点。Percona XtraDB 存储引擎的推出也值得 MySQL DBA 惊喜。

除此之外,DRBD、MySQL Proxy 与 Memcached 等 MySQL 相关组件的灵活搭配与定制,给用户解决超大规模应用上带来了更大的可能。数据库市场不可能不受经济危机的影响,商业数据库厂商日子要吃紧是可以想见的事情。

7)Hadoop 的生命力

Yahoo! 公司在 2008 年表现不佳,但是 Yahoo! 支持的 Hadoop 项目可是左右逢源,再一次让我们认识到开放带来的生命力。Facebook、Amazon、AOL、阿里巴巴等公司(当然也包括 Yahoo!)都在纷纷构建 Hadoop 集群来解决大规模数据处理与分析问题!。期待在 2009 年 Doug Cutting,这位 Hadoop 项目的带头人不要被 Google 挖角。

N)2009 年会怎么样? 谁知道呢。

--EOF--

后记:这算是 2008 年末的时候数据库技术小观察吧。因为投稿的缘故,现在才发出来。在过去这短时间里,自己一些观点可能也有所变化。如有时间,再做补充或者修订。请注意该文的时效性。

补充:对于 SSD,最近一件重要的事件是 Steve Wozniak 加入了 SSD 厂商 Fusion-IO

作者:孙毓波 (AKCMS 作者)

SQLite 是一个类似Access的轻量级数据库系统,但是更小、更快、容量更大,并发更高。为什么说 SQLite 最适合做 CMS (内容管理系统)呢?并不是说其他数据库不好, Oracle、MySQL、SQLServer 也都是非常优秀的 DBS,只不过他们设计目标不同,特性不同,所以只有更适用某个应用场景,没有绝对的好坏之分。

我归纳的中小型站点的CMS的特点如下:

  • 1、数据量不超过10万
  • 2、日页面访问量不超过10万
  • 3、 一部分网站全部生成静态页面,一部分网站实时查询数据库动态访问
  • 4、 站长不懂技术,不懂得复杂的数据库维护,只会用 FTP 管理网站
  • 5 、个人站点基本上是一个人管理,一般情况下只有一个人在访问后台,没有并发
  • 6、 对数据库来说是读多写少,只有在站长访问后台的时候才会写入
  • 7、 多运行于虚拟主机,大部分PHP主机均同时支持MySQL,小部分PHP主机需要单独购买MySQL,PHP+MySQL的主机价格较PHP主机价格高。 (以万网为例:最便宜的PHP空间780元,最便宜的PHP+MySQL的PHP空间1150元)
  • 8、 多数中小站点的HTTP服务与MySQL部署在同一服务器上

SQLite 的优点在中小网站CMS应用场景下表现突出:

  • 1、与MySQL相比,它更彻底的免费,并且没有任何使用上的限制
  • 2、非常小巧,PHP5以上版本中无需任何配置即可支持SQLite
  • 3、无需单独购买数据库服务,无服务器进程,配置成本为零
  • 4、整个数据库存储在一个单个的文件中,数据导入导出备份恢复都是复制文件,维护难度为零
  • 5、读速度快,在数据量不是很大的情况下速度较快,更重要的是:省掉了一次数据库远程链接没有复杂的权限验证,打开就能操作

SQLite的缺点在中小网站 CMS 应用场景下被规避:

  • 1、并发低 动态访问时当访问量不超过10万PV的时候,SQLite 超过 Access 的并发能力已经绰绰有余;生成静态页后更无需考虑数据库的并发问题
  • 2、在大数据量的情况下表现较差 但是中小站点一般情况下数据量不超过10万,而SQlite 在 100 万数据量之下表现还不错,因为省掉了对数据库服务器的远程连接甚至会更快
  • 3、写入较慢 默认配置下的 SQlite 的写入速度比MySQL慢了很多,但是 CMS 应用场景的写入操作较少。在插入新文章的时候基本感受不到慢。集中的写数据库操作只有在安装的时候会出现,不过只出现一次,可以忽略
  • 4、为已有的表加索引较慢 但是在中小站点CMS中不会有这样的需求,可以忽略
  • 5、无法将 MySQL 部署到与前端机不同的服务器上,但是中小站点也没有分开部署的需求

综上所述:在中小站点 CMS 的应用场景下 SQLite 能最大限度的降低建站成本,降低维护难度,又很好得规避了自身的缺点。所以我认为未来支持 SQLite 的 CMS 系统一定会大行其道。

--EOF--


Fenng 注:这是网友来稿,转载请注明本文作者。刊载此文不代表我赞同文中所有观点。其实,我觉得 Berkeley DB 或许也不错。另外,如果一个 CMS 日访问量小于 10 万,通过一些 Web 前端优化,后端的压力就会非常之小。

RAIDb 简介

RAID(Redundant Array of Independent Disks),是现在 SAN 存储的非常核心的概念,可能很多朋友都熟悉的。这里介绍一个比较旧的新词:RAIDb 。所谓 RAIDb 也就是 Redundant Arrays of Inexpensive Databases (Db)。

RAIDb 其实是和 Sharding 技术概念有些地方是相通的。如果看概念上的验证还可以看 MySQL DRBD 的解决方案。 这个概念似乎较早见于 C-JDBC 的设计说明,不过近年来也被一些新的解决方案所引用。(比如sequoia)。

RAIDb-0

表级别. 类似数据库的分区,但 RAIDb-0 是不同表之间,RAIDb-0 不提供容错机制。RAIDb 控制器是整个 RAIDb 的核心。这一组件决定 RAIDb 的可靠性、可用性。

RAIDb-0.gif

RAIDb-1

DB 的镜像或者复制。也是至少需要两个后端 DB 节点。具备容错机制。和 RAID-1 类似,写操作会慢一点。因为是全复制或者镜像,所以对存储空间的需求是比较大的。

RAIDb-1.gif

RAIDb-2

部分复制,算是前两种方式的折衷。

RAIDb-2.gif

RAIDb-1-0

RAIDb-1-0.gif


RAIDb-0-1


RAIDb-0-1.gif

示意图乍看起来是一样的,RAIDb-1-0 与 RAIDb-0-1 的主要差异在控制器(controller)上。

RAIDb 概念把数据库水平切分的思想抽象出来一个很好的模型。旧瓶装新酒,只要调制合理。

--EOF--

封装业务逻辑:存储过程

在商业数据库软件的实践方式上,利用存储过程封装业务逻辑是非常通用的做法(也有很大一部分原因是 IT 架构演化造成的)。MySQL 5 之后也支持存储过程,如果要把 Oracle/DB2 等的就有逻辑迁移到 MySQL 当然不是容易的事情。最好的办法可能是:不在存储过程上动脑筋,在应用层想办法。

谁是"推手"?

让我们回过头来,看看当年 Linux 与 FreeBSD ,为什么 Linux 走入企业市场,而 FreeBSD 仍然算非主流。最为主要的一个原因是 Oracle 选择了 Linux 而不是 FreeBSD ,从而带给 Linux 极大的机会。如果说 Oracle 是 Linux 成功背后的推手,那么今天的 MySQL 推手在哪里? 云计算? 前一段时间可能还不能看的很清楚,不过经济危机倒有可能会给 MySQL 带来大规模部署的可能,如何 省钱,是现在很多企业必须要考虑的问题。。

可裁减的 MySQL

类似 Drizzle 这样经过精简后而用户某种特定应用的形式,相信能够在一些企业内部运用,并且成为主体架构的有效补充。

关于 ZFS

这里可能要修正一下之前的某些看法,在存储层其实 ZFS 是个不错的途径。ZFS 可发挥的空间不小,只是看什么时候能够在 Solaris 系之外的操作系统上跑起来。

用户学习成本

相比其他商业数据库软件,MySQL 总体学习成本更低,但如果深入到架构层并非易事。至少国内目前仍然大量缺乏 MySQL 好手。如果 Sun 能在 MySQL 的技术推广上继续深挖,相信会有一大批技术人员投入其中。当然,一个企业采用 MySQL 与否,还要看很多因素。但起码要能改变 MySQL 技术人员"很山寨"这个固定的思维模式。

结语:如果非要写个结语的话,还是觉得 MySQL 下一步能有多大的成就,要看 Sun 如何对待这个宝贝。买椟还珠的事情常有。

--EOF--

关于归档

本页包含 Database 类别下的所有文章.

上一类别为 Arch.

Geek 为下一类别.

回到 首页 查看最近发表的文章或者查看所有 归档文章.