存档

2010年7月 的存档

周末随老婆公司自驾游,东极岛,顾名思义,是中国有人居住的最东端的岛屿,从舟山沈家门出海,大约40多公里,坐船大约需要三个小时。
当天风浪很大,我晕船,吐得一塌糊涂,在岛上住在渔民家里,顿顿都是海鲜,不是鱼就是贝壳。岛上蚊子巨多,我们戏称是来献血的。岛上没什么象样的海滩,找了个能游泳的地方,水还算清澈,就是有些冷。回去的路上,继续吐了一路,下船后只想吃顿KFC,比海鲜好吃多了,我想我还是比较适应在陆地上生活。
只带了一个30mm的定焦头,也没怎么拍,凑合着看吧。

–EOF–

7 28th, 2010 | Filed under 一地鸡毛, 边走边拍

本文发表在《程序员》杂志2010年第6期
引 言
数据库的可用性和扩展性一直是数据库厂商和用户最关注的问题。过去我们采用高端的设备,比如使用小型机和大型存储来保证数据库的可用 性。而扩展性主要采用向上扩展(Scale up)的方式,通过增加CPU,内存,磁盘等方式提高处理能力。这种集中式数据库的架构,使得数据库成为了整个系统的瓶颈,已经越来越不适应海量数据对计 算能力的巨大需求。近些年来,分布式系统成为了一种趋势,我们希望用廉价的设备堆叠出具备高可用性和高扩展性的计算集群,从而摆脱对大型设备的依赖。数据 库作为系统架构中的重要组成部分,如何做到即提供高可用性,又具备向外扩展(Scale out)的能力,数据库厂商和用户都做了很多的探索。
Oracle RAC
几乎每个数据库产品都有集群解决方案,Oracle RAC是业界最流行的产品。其架构的最大特点是共享存储架构(Shared-disk),整个RAC集群是建立在一个共享的存储设备之上的,节点之间采用 高速网络互连。Oracle RAC提供了非常好的高可用特性,比如负载均衡和应用透明切换(TAF),其最大优势在于对应用完全透明,应用无需修改便可以切换到RAC集群。但 是,RAC的扩展能力有限,首先因为整个集群都依赖于底层的共享存储,所以共享存储的IO能力和可用性决定了整个集群的可以提供的能力,其依然无法摆脱对 大型存储设备的依赖。Oracle显然也意识到了这个问题,在Oracle的MAA(Maximum Availability Architecture)架构中,采用ASM来整合多个存储设备的能力,使得RAC底层的共享存储也具备线性扩展的能力,整个集群不再依赖于大型存储的 处理能力和可用性。
RAC的另外一个问题是,随着节点数的不断增加,节点间通信的成本也会随之增加,当到达某个限度时,增加节点可能不会 再带来性能上的提高,甚至可能造成性能下降。这个问题的主要原因是Oracle RAC对应用透明,应用可以连接集群中的任意节点进行处理,当不同节点上的应用争用资源时,RAC节点间的通信开销会严重影响集群的处理能力。所以使用 Oracle RAC有两个建议:1.节点间通信使用高速互联网络;2.尽可能将不同的应用分布在不同的节点上。基于这个原因,Oracle RAC通常在DSS环境中可以做到很好的扩展性,因为DSS环境很容易将不同的任务分布在不同的计算节点上,而对于OLTP应用,Oracle RAC更多情况下是用来提高可用性,而不是为了提高扩展性。
MySQL Cluster
MySQL cluster和Oracle RAC完全不同,它采用Shared-nothing架构。整个集群由管理节点(ndb_mgmd),处理节点(mysqld)和存储节点(ndbd)组 成,不存在一个共享的存储设备。MySQL cluster主要利用了NDB存储引擎来实现,NDB存储引擎是一个内存式存储引擎,要求数据必须全部加载到内存之中。数据被自动分布在集群中的不同存 储节点上,每个存储节点只保存完整数据的一个分片(fragment)。同时,用户可以设置同一份数据保存在多个不同的存储节点上,以保证单点故障不会造 成数据丢失。
MySQL cluster的优点在于其是一个分布式的数据库集群,处理节点和存储节点都可以线性增加,整个集群没有单点故障,可用性和扩展性都可以做到很高,更适合 OLTP应用。但是它的问题在于:1.NDB存储引擎必须要求数据全部加载到内存之中,限制比较大,但是目前NDB新版本对此做了改进,允许只在内存中加 载索引数据,数据可以保存在磁盘上。2.目前的MySQL cluster的性能还不理想,因为数据是按照主键hash分布到不同的存储节点上,如果应用不是通过主键去获取数据的话,必须在所有的存储节点上扫描, 返回结果到处理节点上去处理。而且,写操作需要同时写多份数据到不同的存储节点上,对节点间的网络要求很高。
虽然MySQL cluster目前性能还不理想,但是share nothing的架构一定是未来的趋势,Oracle接手MySQL之后,也在大力发展MySQL cluster,我对MySQL cluster的前景抱有很大的期待。
分布式数据库架构
目前,除了数据库厂商的 集群产品以外,解决数据库扩展能力的方法主要有两个:数据分片和读写分离。数据分片(Sharding)的原理就是将数据做水平切分,类似于hash分区 的原理,通过应用架构解决访问路由和数据合并的问题。Sharding架构的优势在于,集群扩展能力很强,几乎可以做到线性扩展,而且整个集群的可用性也 [...]

7 15th, 2010 | Filed under 大话技术

Library cache是Shared pool的一部分,它几乎是Oracle内存结构中最复杂的一部分,主要存放shared curosr(SQL)和PLSQL对象(function,procedure,trigger)的信息,以及这些对象所依赖的table,index,view等对象的信息。
Library cache需要解决三个问题:
1.快速定位的问题:Library cache中对象众多,Oracle如何管理这些对象,以便服务进程可以迅速找到他们需要的信息。比如某个服务进程需要迅速定位某个SQL是否存在于Library cache中。
2.关系依赖的问题:Library cache中的对象存在复杂的依赖关系,当某个objec失效时,可以迅速将依赖其的对象也置为失效状态。比如某个表发生了结构变化,依赖其的SQL语句需要重新解析。
3.并发控制的问题:Library cache中必须有一个并发控制的机构,比如锁机制,来管理大量共享对象的并发访问和修改的问题,比如某个SQL在重新编译的同时,其所依赖的对象不能被修改。
Library cache结构:

Oracle利用hash table结构来解决library cache中快速定位的问题,hash table就是很多hash bucket组成的数组:

原理与buffer cache中定位block的方式相同,将对象信息(比如SQL)hash定位到某个hash bucket中,然后顺序扫描bucket中的 List,实现快速定位对象的目的。
Library cache handle是对象的一个指针,其中的namespace属性表示其指向的对象的类型:比如CRSR(Cursor),TABL(Table),INDX(Index) ,PROD(Procedure),TRIG(Trigger)等等。
LCO(Library cache object)是handel指向的对象,包含了以下几个部分的内容:
1.dependency table:
指向本对象所依赖的对象,比如:select * from emp这个cursor的对象,依赖emp这个表,这里指向了emp这个表的handle。
2.child table:
指向本对象的子对象,比如某个游标的子游标。子游标是指SQL文本相同,但是SQL的实际含义不同的情况,比如执行的用户不同,执行计划不同,执行的环境不同等等,我们一般称之为SQL的不同版本。一个SQL至少包含一个父游标和一个子游标。
3.authorization table:
对象的授权信息。
4.type
Library cache object的type,包括:shared cursor,index,table,cluster,view,synonym,sequence,procedure,function,package,table body,package body,trigger等等。
5.data blocks
data block是一个指针,指向了data heap,即存放真实数据的地方,主要包括:diana tree, p-code, source code, shared cursor context area等等,如下图:

Library cache对象依赖关系:
对象依赖关系是利用LCO中的dependency table来完成的,我们设想以下的情况,用来说明对象间的依赖关系:
两个共享游标:
SQL1: select * from emp;
SQL2: select * from emp和select a.name [...]

7 4th, 2010 | Filed under 大话技术
标签: , , , ,