Database 类别下的文章

数据库与用户体验

简要概括一下在 2010 数据库技术大会 上分享的这个关于"数据库与用户体验"的话题。

关于数据库与用户体验,在这个分享中我谈到了如下三点:

  • 响应速度(Response Time)
  • 可用性(Usability and Availability)
  • 数据交互策略(Data Interactive Policy)

其中响应速度(或者是响应时间,英文用了Time)这一部分,首先强调了一下面向最终用户的响应时间对用户体验的重要性。"慢"终归不是好事情。建议技术人员应该了解 Web 架构中各个组件之间的性能数据,并且能够建立端到端的性能数据分析。额外强调了一下延迟(Latency)的意义以及对于用户体验和架构扩展的重要性。这一部分最后提出了三个问题,意在希望能建立起一个具备基本性能度量能力的Web环境,我真的不知道有多少人仔细考虑过这样的问题。

对于可用性,用 PPT 中的这三句话即可概括:

  • 不具备可用性则没有意义
  • 好的可用性 != 好的用户体验
  • 差的可用性 =糟糕的用户体验

这里有必要再次强调一下第一句,很多 DBA 认为只看好自己的一亩三分地即可,对系统中的其它环节采取旁观态度,窃认为这是不可取的。补充一句:产品设计者实际上也应该注意过度设计带来的可用性风险。

第三部分看似篇幅挺大,但除了分析一个具体的案例之外,其实没说什么有价值的东西。至于 BASE 、CAP 这些内容,其实都是老生常谈的内容。费了不少口舌,如果要提炼出几个词的话,可能就是"权衡"与"取舍",当然,这个要建立在一定的实践之上的。

必须要承认,这个话题因为比较跨界,也有我偏颇或考虑不够周详的地方。希望以后在能有更多的朋友加入到这一话题的讨论中来,我更想听听大家的看法。用户体验是个大话题,我这样的门外汉也来掺和似乎有些过分啊...

(现场用的 PPT 有几页展示效果不够好,在 Web 上看应该还成)

--EOF--

今天晚上和几个同事飞赴北京,参加明天开始的 2010 数据库技术大会

在明天(4月2号)下午我将做一个演讲,题目有点偏,关于"数据库与用户体验"。我相信在此之前,没有谁会做这样的话题,所以这个话题在做数据库的技术人员眼里有点陌生或是有点忽悠。我的出发点是这样的:可能绝大多数 DBA 都会认为自己的工作和用户体验(User Experience) 是风马牛不相及的事情。实际情况并非如此,DBA 很多关键的工作都会和用户体验相关联,理解到其中的细微之处,能让 DBA 在技术团队发挥更大的作用,创造更大的价值。希望我的演讲到时候会对一些有困惑的朋友真的有帮助。

应主办方要求,演讲时间将控制在 45 分钟左右,所用的 PPT 几经修改已经定稿。在会后我将尽快分享到 SlideShare 上,并将做一个简洁一点的描述,核心的内容可能用较短的篇幅即可说清。

这次会议,阿里巴巴集团旗下各家子公司去了不少同事,当然,都是带着演讲主题去的,我对他们即将分享的技术话题也很期待。

另外,支付宝当前的 DB 团队仍然需要资深 DBA。如果有哪位朋友有意向来杭州发展,在会场我们不妨沟通一下。

--EOF--

最近事情比较多,这里更新较少。再过一段时间,我会有机会做更多的总结,与朋友们分享一些心得。

2009年数据库技术领域回顾

简要回顾一下 2009 年数据库技术领域。过去的一年,差不多也可以说是过度的一年,数据库技术以及数据存储产品等都都或多或少发生一些方向上的转变。

Oracle 收购 Sun,MySQL 前途未卜

Oracle 收购 Sun 可谓一波三折。在获得美国司法部门的批准后,欧盟委员会又开始调查,Oracle 随后抛出一个"十条保证",眼看着欧盟就要点头,没想到 MySQL 创始人 Michael Widenius(Monty) 则在这个当口不失时机的搞出来一个"拯救 MySQL"的抵制活动,让 Oracle 头疼不已。Monty 这人多少也有点上纲上线,现在已经将 MySQL 的命运和 "Internet Free"这个大话题绑在一起了。

没有人会相信 Oracle 会善待 MySQL,谁会干放虎归山的事情呢? 换了你也会把 MySQL 雪藏起来,毕竟商业公司就要逐利。但是,也很难说一旦收购完成后 ,MySQL 会在短期内消失,基于 MySQL 众多开源分支以及解决方案也都发展的不错,我相信最终决定权还是在用户的手里。就算没有 MySQL,也没准儿会有 YourSQL 出来的...

尽管口水战还在进行,MySQL 的开发者倒是没闲着,在年底发布了 5.5 第二个里程碑版本,原来站点上的 6.0 系列的信息全部撤掉。5.5 更像一个集成版本,将不少第三方贡献的功能改进(比如 Google 的 Patch)融合了进来。

而 Oracle 这一年在产品上的一个标志性事件是推出了 Exadata 存储第二版,与第一个版本不同的是,这一个版本在 OLTP 方面增强了许多。从这个版本开始,Oracle 正式拥有自己的存储硬件(第一版是和 HP 合作的产物)。RDBMS 上,除了发布 11g 第二版之外,也在做功能上的调整,这一次,面向的是数据中心。

NoSQL 的兴起

这是今年数据库领域最有趣的话题。NoSQL 的由来大约是这样的:当时还效力于 Last.FM 的 Johan Oskarsson (现在已经投靠 Twitter 了)组织了一个技术会议,话题是关于"open source, distributed, non relational databases",为了方便一点,想出来一个 "NoSQL" 的术语。然后由 Rackspace 的 Eric Evans 引用,进而流传开来(refer)。NoSQL 在基于 Key-value 的存储解决方案上提倡去 SQL 化,尤其避免表连接,并且通过一些变通的办法提供 RDBMSACID 功能(如果需要的话)。

NoSQL 的理念能够短时间内被技术圈所接受,离不开基本的理论支撑:最终一致性BASECAP 这三大基石;一方面是基于 Key-Value 的数据存储解决方案更加成熟,

所谓 NoSQL ,是针对当前对关系型数据库的过度依赖与运用而言,不要将其当成万能药,也没必要过于激进的推行 NoSQL 的模式。在我看来,NoSQL 是针对争夺应用模式上的一种理念上的运用。对多数企业来说,仍属屠龙之技,没必要照搬解决方案。至于传统的 RDBMS 是不是已经走向末路,我认为不尽然。RDBMS 依然尤其广泛的应用场景,而NoSQL如果要有更大的作为也要有来自商业上的更大支持才会有所突破。

SSD 被更多企业接受

Jim Gray 在 2006 年的那句名言:Tape is Dead,Disk is Tape,Flash is Disk,RAM Locality is King ,现在正在被现实所验证。2009 这一年,用户已经开始进一步试水 SSD 产品,包括 MySpace、Last.FM 等网站已经开始在关键应用上部属 SSD(refer: 1, 2)。而国内也有很多企业对 SSD 进行尝试性的使用,这其中包括阿里巴巴、优酷。

更多的存储厂商已经在高端存储中兼容 SSD ,除了去年的 EMC 尝鲜之外,现在 IBM、HDS 、NetApp 都加入了这一阵营。

随着 SSD 的价格迅速下降,很多存储厂商已经开始调整硬件架构,现在有个看似可行的趋势是在 Cache 层与磁盘层之间多构建一个 SSD 存储层,在成本与性能之间做一个折衷。

在去年年底的回顾中,我曾大言不惭的说"相信2009 年会是 SSD 爆发的一年",总体来看,2009 年对 SSD 的部属还谈不上"爆发"。中规中矩而已。

Amazon EC2 对 MySQL 企业版的支持

尽管我不愿意谈云计算,不过 Amazon 这一年在云计算方面还是做了很大的突破,Amazon EC2 上面现在已经可以跑 MySQL 企业版了,采取按照增长付费 ('Pay-as-we-Grow') 的模式让初创公司有更多的选择,这比 SimpleDB 可以说是前进了一大步。 这种模式在国内是否可行,考虑到当前内容审查的问题,还有待商榷。

国内 Key-Value 产品

这一年来国内对 Key-Value 产品的研究与运用和国外基本没太大的距离,豆瓣网先作出了不错的表率,发布了 BeansDB 存储系统,这是一个豆瓣风格的 Dynamo 实现,采用类似 Memcached 的去中心化结构。而最近得到的消息说人人网也要将其内部使用的存储系统 Nuclear 开源。相信在新的一年可供参考的 Key-Value 会层出不穷。

其它方面

Hadoop 过去一年中没有太大的变化,上了一点规模的网站都在用,快成了 Web 数据分布式计划的标准组件了。Doug Cutting 出走 Yahoo! 还是带来了一定的影响 ,不知道今后 Yahoo! 在 Hadoop 方面的支持力度会如何。至于面向列的 DB 发展情况,在过去的一年中进展不大。SQL Server 和 DB2 等方面似乎没什么可圈可点的大事,倒是 PostgreSQL 因为 MySQL 的不确定性而取得了不小的增长。

有一点要补充的是,假以时日,Open Data 或许也将成为一个趋势。

当然,这份回顾有浓郁的个人色彩,有不同意见请留言探讨吧。

--EOF--

本文发表在《程序员》杂志,不过这里的有些许更新。本文写作时,Oracle 收购 Sun 还没有尘埃落定,现在看起来,一切都变化太快。

Oracle Exadata 技术浅析

自从 Oracle 和 HP 推出 Exadata 之后,我就很关注这个产品,之前也写了一篇Oracle Database Machine介绍它。去年,Oracle和SUN合并后,推出了Oracle Exadata V2,相比较上一代产品有几个变化:第一,使用 SUN 的硬件;第二,宣称支持 OLTP 应用;第三,Oracle 11g R2 提供了更多的新特性。

Exadata Smart Flash Cache

Exadata V2整体架构并没有太多改变,换用了 SUN 的硬件,除了采用 Intel 最新的 Nehalem CPU 以外,每台 Storage Cell 更是配置了 384GB 的 Flash,这也是为什么 V2 可以支持 OLTP 应用的关键。

Flash Cache 完全是自动管理,Oracle 会根据数据的访问情况,决定哪些数据放在 Flash Cache 中。所有的数据都是先被写到普通磁盘上,再根据访问情况读入 Flash Cache 的,所以如果 Flash Card 发生故障,数据不会丢失。当然,Oracle提供了方式,可以让用户手动将表或者索引 Pin 在 Flash Cache 中。

在自动管理的方式之外,Oracle还允许用户人工创建flash disks,和普通磁盘一样,这些 Flash Disks 通过 ASM 输出给数据库使用,用户可以把一些访问非常频繁的数据文件放在上面。这些 Flash Disks 不仅仅是 Cache 了,所以 ASM 会在Cell 和 Cell 之间做镜像。如果某块卡发生故障,那么整个 Storage Cell 上的 Flash Disks 会 offline,保证数据不会丢失。

Smart Scan

Smart Scan是 Exadata 最重要的一个功能,它的作用就是把 SQL 放在每个 Cell 上去运行,然后每个 Cell 只返回符合条件的数据给数据库,这样就极大的降低了数据库服务器的负载和网络流量,并充分利用了 Cell 的计算资源和 IO 资源。

传统方式:所有的数据都需要返回给数据库服务器,网络带宽要求高,所有的计算在数据库服务器上完成。

Smart scan:只返回符合条件的数据,减少网络带宽,并充分利用了 Cell 上的计算和 IO 资源。

这里有一点要注意,在使用 Smart Scan 时,每个 Cell 返回给 DB Server 的是结果集,而不再是传统的 Block, DB Server 完成结果集的处理,并返回给客户端。

Smart Scan 如何处理 Join ?

这是我一直想要搞清楚的问题。事实上, Smart Scan 只能处理 Join filtering,而真正 Join 的工作必须在 DB Server上完成,而且Smart Scan 仅适合于处理 DSS 环境的复杂 Join,对于 OLTP 类型的简单 Join,Smart Scan 并不能发挥其优势。设想下面的查询:

select e.ename,d.dname from emp e, dept d where and e.ename='Jacky' and e.deptno=d.deptno;

假设采用 nested loops join,Smart Scan 只能完成 e.ename='Jacky' 这个条件的过滤,然后将符合条件的 emp 表的数据返回到 DB server,然后由 DB Server 完成 join 的工作,逐条查询dept表 (e.deptno=d.deptno) 的数据。所以 Smart Scan 并不适合nested loop join(我认为 Smart Scan 只有在适合的条件下才会启用),只有 DSS 环境的大数据量复杂join才会发挥出优势。而且 Smart Scan 只能完成filtering的工作,而不能真正完成 Join 的工作,这个与 Greenplum 数据库是不同的(有兴趣可以看我的文章,Greenplum技术浅析)。设想下面的查询(emp和dept都是大表):

select e.ename,d.dname from emp e, dept d where e.deptno=d.deptno;

假设采用 Hash Join ,由于没有任何过滤条件, Smart Scan 只能把两个表的数据全部返回到 DB Server 上进行join操作,不过 Smart Scan 也不是一点用都没有,至少还可以进行 column 的过滤,只返回需要的字段就可以了。

Oracle 的文档中,曾经提到对于一个大表和小表join时, Smart Scan 会采用bloom filter来快速定位(可以看我以前的文章,有趣的 bloom filter )。方法是把小表build成为bloom filter,然后在每个storage cell上对大表做scan,利用bloom filter快速定位符合条件的结果,并返回给 DB Server 作 join。

Storage Index

存储索引,顾名思义是在存储级别建立的索引,简单的说就是为表中的每一列数据建立一个索引,每个index entry记录一段数据区间的最大值,最小值以及它们的物理位置,文档上说1MB数据对应一条index entry,见下图:

如果我们查询B<2,或者B>8的数据,根据存储索引,我们就可以跳过这些不在min和max之间的数据块,极大的提高了扫描的速度,这就是存储索引的意义。

Hybrid Columnar Compress

首先我们要搞清楚,什么是行压缩,什么叫列压缩。我们熟悉的数据库,如Oracle、MySQL等都是基于行的数据库,就是行的不同字段物理上存放在一起,还有一种是基于列的数据库,就是每个字段的不同行物理上存放在一起。他们的优缺点同样突出:

基于行的数据库,访问一行非常方便,但是由于同一列的数据是分开存放的,如果要针对某一列进行查询时,几乎要扫描整个表才能得到结果。基于行数据库的压缩,称为行压缩。

基于列的数据库,因为同一列的数据物理上放在一起,所以访问一列非常方便,也就是说如果针对某一列进行查询时,不需要扫描整个表,只需要扫描这一列的数据就可以了,但是访问一行的全部字段非常不方便(又是废话)。基于列数据库的压缩,称为列压缩。

Oracle 通常说的 compress 功能(包括11g R2的Advanced compress),都是行压缩,因为Oracle是个基于行的数据库。大概的方法就是在block头部存放一个symbol table,然后将相同的值放在那里,每行上相同的数据指向symbol table,以此来达到压缩的目的。行压缩的效果通常不好,因为我们知道行与行之间,其实相同的数据并不多。但是列压缩则不同,因为相同列的数据类型相同,很容易达到很好的压缩效果。

行压缩和列压缩都有其优缺点,而Oracle的混合列压缩技术,实际上是融合了列压缩的高压缩比和行数据库的访问特性,将两者的优点结合起来。Oracle提出了 CU 的概念(compress unit),在一个 CU 内,是一个基于列的存储方式,采用列压缩,但是一个 CU 内保存了行的所有字段信息,所以在CU与CU之间,Oracle还是一个基于行的数据库,访问某一行,总是只在一个 CU 内。每个CU由一些连续的block组成,CU header中记录了每一行的各个列在CU中的分布情况,在混合列压缩模式下,一行通常是跨多个block的。

所以说混合列压缩,结合了列压缩和行访问的特点,即可以提供非常高的压缩率,又很好的保证了基于行类型的访问。

Exadata的另一个重要功能是 IO resource management,如果我们在一个 Exadata 上部署了很多个数据库,可以用它来管理 IO 资源,这里就不作阐述了。

目前,我还没有了解到在国内有 Exadata 的应用,而且资料也是比较少的。希望有机会可以真实的测试一下它的性能,我不怀疑他在 DSS 环境下的表现,但是对于 OLTP 类型的应用,是否真的象 Oracle 说的那么强劲,还有待于验证。

-EOF-

稿件来源

Oracle 发布了关于 Exadata 的混合列压缩(Hybrid Columnar Compression)功能的白皮书(refer)。到现在这方面中文资料还比较少,所以分享一下我读这篇白皮书的笔记。Oracle 在这个文档中也提出了 数据仓库压缩(Warehouse Compression)与归档压缩(Archive Compression)两个概念上的"新"功能。

Oracle Block via http://www.dbasupport.com/img/gupta1.gif我们知道 Oracle 数据库引擎默认是以数据块(block)为存储单位,以数据行(row)作为存储与组织方式,当然理想情况是在一个数据块内存储更多的数据行,而实际上这样的方式对于一些列数较多的表不可避免的会带来存储空间的浪费。相反,以列(columnar)的方式组织、存储数据在空间上会带来很好的收益,但是对于依赖于行的查询,也是我们最常用的查询方式,则性能会差很多,而对于数据分析方面常见的汇总之类的查询,因为只需要扫描较少的数据块,就会达到很好的性能。可实际环境中,人们往往要熊掌与鱼兼得,为了达到空间和性能上的折衷,Oracle 引入了新的方式:用行与列混合的方式来存储数据。

Logical Compression Unit.jpg

如上面的示意图,从高一层抽象上看,引入了一个新的叫做压缩单元(compression unit,cu)的结构用于存储混合列压缩的行的集合。新的数据载入后,列值追加到旧有的行集合的后面,然后进行排序与分组等操作后进行压缩。这一系列动作完成后,组成一个压缩单元。直接一点说,也就是对列存储做分段处理,而压缩单元用来维系不同分段之间的关系。有个特别之处是,要使用批量装载(Bulk Loading)的方式,对于已经存储的数据依然可以应用 DML 操作。而 Exadata 引擎对待已经存入的数据的策略是按需进行解压缩。

这是与传统的 Oracle 数据库引擎所说的压缩截然不同的方式。至于数据仓库压缩与归档压缩的功能,看起来只是针对不同的场景而设置了不同的压缩密度而已。而 Oracle 之所以强调 Exadata 的压缩能力,我想更多是因为 Exadata 目前对于存储能力和价格上的限制吧。

--EOF--

尽管前一段时间有媒体报道 Second Life 已经悄无声息的衰败,不过林登实验室的人也还是很忙,这不,刚把一堆 MySQL 服务器进行了升级,还进行了详尽的经验总结(Refer)。

原有的 MySQL 都是跑在 4.1 版本上(4.1.11),在 2007 年的时候计划升级到 5.0 版本,不过遭遇到了...嗯,失败。当时的 5.0 版本不够快。被迫回滚。之后中心 DB 一直运行 4.1 的版本,而 Slave 和其它 DB 都逐渐升级到了 5.0.51 的版本。

用 Python 和 RabbitMQ 写了一个支持 MySQL 协议的分布式压力测试框架,该工具用于捕捉产品环境中的流量并在测试环境下回放模拟,以便更加接近系统的真实运行情况。此外,使用了 Maatkit 工具包用于验证 SQL 语法以及数据。

4.1.11 与 5.0.51 的对比测试表明,5.0.51 比 4.1.11 要慢不少,经过与 Percona 的沟通后,决定升级到 5.0.84 。从我几天前这份 MySQL 版本的调查看, 5.0.84 也是目前用户采用比较多的版本。初步测试 5.0.84 的性能和 4.1.11 的性能相差无几,随后测试打了 Percona 与 Google 的补丁的版本,未作调整下收益不大。一些关键的参数需要作调整以便得到更好的 I/O 能力(要注意如果是 SSD 环境下 innodb_read_ahead 参数要做一点调整,16K 还是 32K ? 要测试才知道)。此外,将 Binlog 放到单独的块设备上,得到 10% 的提升。值得注意的是,默认的系统 I/O 调度器不是很适合,切换到 Deadline 后得到了 15% 的提升(参考 I/O 调度器与 DB的关系)。

经过一番折腾,峰值并发达到了14-16k QPS,只用了 80% I/O 能力,而 4.1.11 最高是 8200 QPS,5.0.51 最高 11,500 QPS,看到这里,猜测他们费这么大劲升级也就是要得到更好的并发能力?

然后是对代码的验证上,包括 SQL 在不同 DB 版本上的正确性以及 SQL 运行的效率,后者也就是执行计划稳定性。这两个测试主要是用 Maatkit 来做的。对于后者,我个人觉得他们的验证过程还有点黑盒子,或许应该关注到具体的 TOP SQL 才会更稳妥一些。此外,复制数据的一致性检查也有必要加以重视。

这台中心服务器数据量大约 250GB。当前所用的服务器是 8 核 Xeon E5450 CPU,64GB 内存,400GB 的直连磁盘(RAID 10),接下来有计划表明要迁移到 16 核的机器上,并且将启用 SSD

总体来看,对 MySQL 升级的过程其实也不是那么简单的,也要有个方法论与好的方案才会保证最后升级的成功。

--EOF--

延伸参考:Percona 针对 MySQL 5.0.84 的 Patch 说明

针对 MySQL 数据库的版本也做个调查。分析一下大家使用 MySQL 的趋势与习惯。选择大家都选择的,总不会有更大的错误。而如果使用了一个不太合适的版本,或许会后患无穷。

点击访问在线调查 (如果你不能访问这个 URL,需要动动脑子想想为什么)。

现阶段收集到的统计数据:

MySQL_version_chart.png

国内用户用 5.0 的是最多的。如果小版本加起来还是 5.1 的居多。4.1 的版本渐渐推出历史舞台。如果你也在考虑选择 MySQL 的版本,这个数据是否对你有参考性呢?

--EOF--

据我所知,很多第三方公司给客户实施的时候,选择的 Oracle 版本 都是非常随意的。数据库软件的版本选择多少是有点技术含量在里面的,毕竟数据库这东西要升级并非易事。这里小范围调查一下大家都在用 Oracle RDBMS 的哪个版本,然后把分析数据和大家分享一下。或许会对新手 DBA 有一定的参考价值。

点击访问在线调查 (如果你不能访问这个 URL,需要动动脑子想想为什么)。

统计数据:

Oracle_version_chart.png

出乎我的意料,9.2.0.8 这个版本现在用的人并不是特别多了(没有我预期的多),而10.2.0.4 这个版本现在看起来像是不少用户的选择,这其实也侧面说明着很多用户升级到 11g 还需要一段时间。版本的分散意味着 Oracle 升级的难度的确不小。

不少明显质量不够稳定的版本也有用户在用(比如,10gR1),看来第三方实施的弊端的确不小。Oracle 一般发布的Release 1 其实多少都会有一些问题--否则也不会有后续的 PatchSet 发布了,要知道每个 PatchSet 都是包含几百个 Bug Fix 的。一般来说,在线 OLTP 恐怕少有人用 R1 的版本。

现在收集到大约 100 多份样本,相信还是有点参考价值的。

有的 DBA 对于统计所用的 URL 可访问性有疑问,这侧面验证了我另一个想法:Oracle DBA 对 Web 的熟悉整体上不如 MySQL DBA。

--EOF--

关于归档

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

上一类别为 Arch.

Geek 为下一类别.

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