文章归档

Some use cases of Cassadra

source : http://n2.nabble.com/Cassandra-users-survey-td4040068.html
survey By Jonathan Ellis of Rackspace

user
site
application
others evaluated

Jonathan
Ellis-3
Rackspace 
stats collection (testing,
almost production),Mail & Apps
division (early testing)
HBase, Hypertable, dynomite,and
Voldemort

Ryan King
Twitter
storage for all tweets
a custom mysql impl, voldemort,
hbase,mongodb, memcachdb, hypertable, and others

Edmond Lau
Ooyala
store and serve our near
real-time video analytics data
HBase, Cassandra, Voldemort, [...]

为什么Oracle不使用我的索引?!

本文翻译自Jonathan Lewis发表在DBAZine上的文章:Why Isn’t Oracle Using My Index?!,可以从此处下载本文的Word版本.

为什么Oracle不使用我的索引?!
by Jonathan Lewis
标题的这个问题可能是在Metalink论坛与Usenet新闻组出现的最频繁的问题了.这篇文章使用一个测试用例(可以在你自己的系统来重现的)来演示基于成本的优化器的基本工作原理.在看完这篇文章之后,当再次遇到这个令人讨厌的问题时,你应该就可以自信的解答了.
由于在安装Oracle的时候存在大量的选项,因此当某人执行一条你口授的脚本时,通常很难精确的预测即将出现什么结果. 当时我想要尝试一下,希望你的数据库选择了一个相对普通的安装选项,并且最常用的关键的参数是取得默认值. 这个例子是在Oracle 8.1.7下创建并测试的,参数db_block_size被设置成最常用的值(8k),参数db_file_multiblock_read_count也设置了一个很常用的值(8).在Oracle 9.2下跑图-1中的这个脚本(创建了一组表,在表上添加索引并分些表与索引),结果可能出现部分差异.

create table t1 as
select trunc((rownum-1)/15) n1, trunc((rownum-1)/15) n2, rpad(‘x’, 215) v1
from all_objects
where rownum

如何提高SQL 查询技能

Robert Vollman 今天发表了一篇由其个人经历总结出来的如何写好Oracle SQL查询的Blog, 本文是对其主要观点的摘录, 这也是Oracle初学者在写SQL是经常遇到的困难.
Improving your SQL Queries By Robert Vollman

记录详细的需求文档

在写SQL之前必须弄清楚需求, 具体要取什么数据, 有些什么具体的约束条件, 在数据仓库环境中还可以考虑补上这个需求具体对应哪些报表, 对应的基础表如何. 到开发环境的话, 可以考虑加上这条SQL服务于哪些业务(页面),调用频率如何.

不要重新制造轮子

对于一些已经比较成熟的解决方案,有比较现成的例子的SQL,要善于利用已有SQL,已有模板.

降低语句的复杂度

有些同学可能比较喜欢使用比较炫的技术,比较炫的SQL来解决问题. 但是要切记一点, 使用过于复杂过于新的技术, 如果不能在性能(以及其他方面)带来好处的话, 只会使得这条SQL难于维护, 使得其他相关人员难于理解.

小心处理NULL

NULL在Oracle数据库中是一个非常特别的值, 它不等于任何值, 所以如果你的SQL返回的值数量偏少,或者根本不对很可能就是使用NULL出现了问题..
常见的情况是:
1. 查询的时候直接使用条件 colx = xxx,而这个colx里面是有NULL值的, 这种情况下查询的返回结果是不会包含NULL值对应的记录的, 如果要查询出NULL对应的记录, 需要使用 colx is null (is not null).
2. var 为null的时候, 在plsql中给var赋值, var := var + xxx;这种情况下var的值会一直是null的, 这一点需要特别注意, 我自己也犯过好几次这个错误.

自己核对数据类型

在where条件里面要仔细地核对数据类型, 由于隐形转换的问题, 在数据类型错误的时候, Oracle无法正确使用索引, 可能会导致SQL运行非常慢.

小心处理重复数据

在需求明确的情况下, 如果你不在乎是否出现重复记录, [...]

闪存表空间 VS 数据库Flash Cache

本文翻译自Guy Harrison的blog: Flash tablespace vs. DB Flash Cache, 这是他写的关于Flash Cache系列文章的最后一篇,另外还会翻译两篇Kevin Closson写的关于Flash Cache的相关文章.
之前两篇关于Flash Cache的文章如下:

数据库Flash Cache(II)
使用Oracle 11GR2 数据库Flash Cache

闪存表空间 VS 数据库Flash Cache

在这篇文章中,我将根据我最近针对使用SSD作为数据文件的存储以及使用Oracle 11GR2数据库Flash Cache所做的测试,给出一份两者的性能对比.
有时,我的整个职业生涯看上去都是在等待旋转磁盘的终结.这项技术是如此古老,能力限制如此明确,如此机械.因此,SSD作为一种数据库存储介质越来越可行(Oracle 11GR2已经直接支持这一点),这个事实令人振奋.
使用SSD作为数据库存储的一部分确实会产生很大的问题,但是,理解闪存SSD的性能特征却是非常重要的,它可以帮助我们确保不会不当地使用它.
SSD有以下两个特征:

基于闪存的SSD使用与常见的USB盘相似的闪存技术,这种USB盘已经在小容量移动数据存储领域替代软盘.闪存RAM比较便宜,提供不需要电池备份的持久存储,因此其耗电量也很低.
基于DDR RAM的SSD使用本质上与服务器核心内存差别不大的内存模块.这种RAM需要有持久存储(如磁盘或闪存RAM)和内部电池来支撑.在发生电力故障的时候,电池可以提供足够的电力来保证可以将RAM内存中的内容写到持久存储.

DDR SSD非常昂贵(以及$$/GB这个级别),以致于目前无法作为专业的数据库设备使用.但是,基于闪存的SSD磁盘越来越称为机械磁盘的一个可行的替代选项.

读,写以及擦写操作

闪存盘存储是按照页(一般为4K)以及块(一般为256K)来组织的.对于读操作来讲,闪存盘可以从单个页(page)快速返回结果.往一个页中写数据要慢很多(可能要慢10倍).然而,只有在块中刚好有一个空闲的页的往页写才能达到这个速度.如果我们需要往整个块写数据,必须先清除块内的内容才可以.维基百科关于SSD的条目给出了下面这个关于查找/写以及擦写的时间:

当一个闪存SSD盘渐渐填满数据时,需要清除操作的块级别的写操作的比例逐渐增加,闪存SSD的写性能也相应下降.

TRIM API函数

高端的闪存SSD支持一种叫做TRIM的API,这个功能使得OS可以主动提前清除整个块,从而写操作可以在只有一个页级别的IO内完成.大部分高端的SSD盘还支持一种防磨损算法,这种算法可以在设备上移动热点页以避免块级别出现故障的风险.闪存盘在块变得不可靠之前只支持一定次数的擦写操作,加入磁盘可以自动将热点页在物理存储上移动时,这个缺陷就可以得到缓解.

MLC vs SLC

廉价的闪存盘一般都使用MLC(Multi-Level-Cell)技术,它可以实现在一个单元中存储两位的数据,而使用SLC时一个单元中只能保存一位数据.MLC的效果是以牺牲性能的代价来提高数据密度,特别是写性能.从数据丢失的角度讲,MLC也是更加不可靠的.如果你关心写性能,那么或许你应该避免使用基于MLC的SSD.
通常,如果你想要一个高性能的闪存SSD的话(如果它不是高性能的,干嘛还要它呢?),你就应该选择基于SLC的闪存SSD,并且是支持TRIM API以及有着好的防磨损能力的SSD.在我的测试中,我使用一个Intel X-25 E 32GB的SSD盘.它大概需要600澳元(大概534美元).

读写速度差异的问题

假设大部分数据库都是读比写多,我们还需要担心闪存SSD在查找时间与写时间方面的差异吗?毫无疑问答案是YES.对于一个Oracle数据库来讲,当通过Buffer Cache处理事务活动时,一个设备的读能力与往这个设备的写能力之间有很大的不匹配会非常有害.
这个问题与Buffer Cache中的数据的缓存有关.如果往Buffer Cache中放入数据块比从里面写出简单很多,那么Buffer Cache就很可能会被脏块填满,从而出现free buffer waits等待.下图展示了free buffer waits是如何出现的:

如果使用的是廉价的闪存盘,那么写速度就会比读速度慢更多,最终free buffer waits等待将成为事务活动高峰时期的限制因素.

Oracle数据库Flash Cache

Oracle的数据库Flash Cache提供了另外一种利用闪存SSD的途径. 它不是将整个数据文件放到闪存上,而是将闪存作为二级缓存使用.Flash Cache可以非常大从而加快经常被访问的数据块的读速度.但是,如果闪存盘非常繁忙的话,Oracle就只是尽量少写缓存.这样,我们就可以得到闪存来优化读操作的好处,而不用承担多少写操作带来的损失.
我在前一篇文章中总结了Flash Cache的处理算法,下面是我在那篇文章中使用的图表,它概括了当数据库使用Flash Cache时一个数据块的生命周期.

这个架构的关键点是,只有在DBWR没有超负荷时,它才会往Flash Cache中写入数据块.当DBWR逐渐变得繁忙时,往Flash Cache中的写操作将被忽略(这将会降低Flash Cache的效率),它可以防止Buffer Cache被脏块填满,从而导致free buffer waits等待事件的出现.

闪存盘的读性能

让我们来看在实际操作中它是如何表现的.下面来看当我们针对如下情况执行500,000次随机索引读取时的性能对比:

1. 一个在机械磁盘上的表,不使用Flash [...]

推荐几篇不错的解释Oracle基础概念的文章

一组关于lgwr处理过程相关的文章, 主要是强调log file sync等待的主要原因不是lgwr io而是lgwr processing.

Tuning ‘log file sync’ wait events By Riyaj Shamsudeen

LGWR I/O is Simple, But Not LGWR Processing By Kevin Closson

Don’t Forget ARCH When Pondering Redo By Kevin Closson

The “log file sync” wait event is not always spent waiting for an I/O By Christian Bilien

一篇Jonathan Lewis写的关于Undo设计的文章.
Why undo By Jonathan Lewis