存档

2010年2月 的存档

提起NoSQL这个话题,仿佛不应该是DBA要关注的事,而是架构师应该关心的。但是作为一名DBA,在使用传统的关系型思想建模时,应该有必要了解NoSQL的建模方法。
各种NoSQL数据库有很多,我最关注的还是BigTable类型,因为它是一个高可用可扩展的分布式计算平台,用来处理海量的结构化数据,而数据库同样也是处理结构化数据,所以除了没有SQL,在数据模型方面有相似之处。Cassandra是facebook开源出来的一个版本,可以认为是BigTable的一个开源版本,目前twitter和digg.com在使用。我们尝试从DBA的角度出发去理解Cassandra的数据模型。
NoSQL并不能简单的理解为No SQL,其本质应该是No Relational,也就是说它不是基于关系型的理论基础,而我们所有传统的数据库都是基于这套理论而发展起来的,所以SQL并不是问题的关键所在,比如有些NoSQL数据库可以提供SQL类型的接口,允许你通过类SQL的语法去访问数据。而Friendfeed则是反其道而行之,利用关系型数据库MySQL,采用了去关系化的设计方法,去实现自己的KeyValue存储。所以NoSQL的本质是No Relational.
Cassandra特点:
1.灵活的schema,不需要象数据库一样预先设计schema,增加或者删除字段非常方便(on the fly)。
2.支持range查询:可以对Key进行范围查询。
3.高可用,可扩展:单点故障不影响集群服务,可线性扩展。
Keyspace
Cassandra中的最大组织单元,里面包含了一系列Column family,Keyspace一般是应用程序的名称。你可以把它理解为Oracle里面的一个schema,包含了一系列的对象。
Column family(CF)
CF是某个特定Key的数据集合,每个CF物理上被存放在单独的文件中。从概念上看,CF有点象数据库中的Table.
Key
数据必须通过Key来访问,Cassandra允许范围查询,例如:start => ‘10050′, :finish => ‘10070′

Column
在Cassandra中字段是最小的数据单元,column和value构成一个对,比如:name:“jacky”,column是name,value是jacky,每个column:value后都有一个时间戳:timestamp。
和数据库不同的是,Cassandra的一行中可以有任意多个column,而且每行的column可以是不同的。从数据库设计的角度,你可以理解为表上有两个字段,第一个是Key,第二个是长文本类型,用来存放很多的column。这也是为什么说Cassandra具备非常灵活schema的原因。
Super column

Super column是一种特殊的column,里面可以存放任意多个普通的column。而且一个CF中同样可以有任意多个Super column,一个CF只能定义使用Column或者Super column,不能混用。下面是Super column的一个例子,homeAddress这个Super column有三个字段:分别是street,city和zip:
homeAddress: {street: “binjiang road”,city: “hangzhou”,zip: “310052″,}
Sorting
不同于数据库可以通过Order by定义排序规则,Cassandra取出的数据顺序是总是一定的,数据保存时已经按照定义的规则存放,所以取出来的顺序已经确定了,这是一个巨大的性能优势。有意思的是,Cassandra按照column name而不是column value来进行排序,它定义了以下几种选项:BytesType, UTF8Type, LexicalUUIDType, TimeUUIDType, AsciiType,  和LongType,用来定义如何按照column name来排序。实际上,就是把column name识别成为不同的类型,以此来达到灵活排序的目的。UTF8Type是把column name转换为UTF8编码来进行排序,LongType转换成为64位long型,TimeUUIDType是按照基于时间的UUID来排序。例如:
Column name按照LongType排序:
{name: 3, value: “jacky”},
{name: 123, value: “hellodba”},
{name: 976, value: “Cassandra”},
{name: 832416, value: “bigtable”}
Column name按照UTF8Type排序:
{name: 123, value: “hellodba”},
{name: 3, value: “jacky”},
{name: [...]

2 10th, 2010 | Filed under 大话技术
标签: ,

自从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 [...]

2 1st, 2010 | Filed under 大话技术
标签: ,