分类归档: 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

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

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

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 化,尤其避免表连接,并且通过一些变通的办法提供 RDBMS 的 ACID 功能(如果需要的话)。

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-

稿件来源

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