存档

文章标签 ‘数据库’

12.12日参加了淘宝主办的2010互联网数据库技术论坛,我贡献了一个主题:《数据库性能模型与容量规划》,主要关注硬件性能评测,数据库性能模型和容量规划,并提出了基于响应时间的数据库优化方法。这些内容都来自于实际工作中遇到的一些问题,通过对经验的整理,总结出一些简单的计算模型,属于比较传统和实用的话题,希望对大家有所帮助。
感谢淘宝提供了一个机会,让我们有机会一起交流技术。
–EOF–
PPT:数据库性能模型与容量规划

12 14th, 2010 | Filed under 大话技术

说起Greenplum这个产品,最早是SUN来推他们的数据仓库产品DWA时接触到的,对这个由PgSQL堆叠出来的数据库产品还不是很了解,当时的焦点还在DWA本身的硬件上,当然不可否认,DWA还是有一些特点的。
后来,我们发现普通的PC+SAS磁盘具备非常好的吞吐能力,完全不逊于某些昂贵的存储设备。这样我们就尝试用PC+Greenplum搭建了一个环境,效果完全超出了我们的预期,吞吐量完全超过了我们的大型存储。从那时开始,我们不再迷信那些昂贵的主机和存储,开始尝试一些新的东西,比如用PC+SAS/SATA来堆叠廉价存储,用Greenplum来搭建数据仓库计算环境,搜索的hadoop集群,PC+SSD搭建OLTP数据库,用Intel Nehalem来替代小型机等等。
昨天,去参加了数据仓库部门关于Greenplum的一个技术分享,期间大量列举了一些性能数据的对比,尤其是和当前的一套Oracle RAC的对比。结果不言而喻,在数据仓库的应用上,尤其是大数据量的处理,性能相差悬殊。这时问题就来了,很多人感觉这个产品太神奇了,可以解决数据仓库的一切问题,好像它就是上帝赐予我们的礼物。最后好多人都在问:Oracle太烂了,用这么好的设备,性能还这么差,我们干嘛还要用?呜呼哀哉,Greenplum是好,但并不“神奇”,我们不要被这些”神奇“的数据挡住了视线。
对于Greenplum,我其实也处于一知半解的状态,给大家讲原理未免有些力不从心,这里只简单给大家分析一下Greenplum为什么会快?他用了什么”神奇“的技术?
如何提升数据仓库的处理能力,有以下两个主要因素:第一,吞吐能力,就是所谓的IO;第二,并行计算能力。
我们都知道Oracle RAC是shared everything架构,而Greenplum是shared nothing架构。整个集群由很多个segment host(数据节点)+master host(控制节点)组成,其中每个segment host上运行了很多个PgSQL数据库(segment)。

数据在进入数据库时,首先要做数据分布的工作,即把一个表的数据尽可能均匀的分布到每个segment上,我们需要为每个表指定一个distribute列,然后根据hash来做数据分布。这样做的目的就是要充分利用每个节点的IO能力,我们知道现在PC机的IO能力相当可观,象DWA这种专门设计的数据节点,Sun Fire X4500 Server,在一个box内集成了48块SATA盘,号称“Scan 1 Terabyte of data in 60 seconds”。其实没必要买DWA,国内厂商都有那种磁盘密集型的PC,价格便宜量又足,我们一直用它。

很多人在看到Greenplum架构的时候,第一个问题就是master机器承担了什么功能?它会不会成为系统的瓶颈?这也是Greenplum系统的一个重要特点,master只承担非常少量的控制功能,以及和客户端的交互,完全不承担任何计算。如果存在一个中心节点的话,那意味着这个系统根本没有办法线性扩展,因为master一定会成为系统的瓶颈。而Greenplum不存在这个问题,节点间的数据交互,不需要经过master,而是直接在节点间就完成了。
现在,如果我们要查询某个表的数据,只要把工作分配给每个节点就行了,IO不再是问题,接下来要解决并行计算的问题,核心问题是多表做join。因为表是通过DT列做分布的,所以每个节点通过DT列就知道数据在某个节点上,假设两个表用DT列做join,因为相同的数据都在相同的节点上,所以只需要对应节点计算,然后合并结果就可以了。如果是非DT列做join,因为节点间不知道数据的分布,所以就会做一个数据重分布的过程(redistribute)。我们看下面的例子,三个表都是用id列作为DT列,首先用id做join,因为设计到非DT列的join,这时Greenplum会作redistribute的工作,作用就是重新按照hash做数据分布,这样做的目的就是要让节点知道数据在哪个节点上,以便完成join的动作。我们看到后面的group by也做了redistribute,因为group by的也是非DT列,而hash aggregate动作也需要节点间交互数据,节点间也必须知道数据的分布。如果有redistribute动作,效率会高吗?因为redistribute仅仅只针对需要的数据,而且全部在节点cache中完成,肯定要比DT列做join慢一些,但是效率还是非常高的。
Bride Wars download Somewhere in Time divx
Greenplum真正发挥了并行无处不在的优势,在一个主机上同时启动多个PgSQL数据库,这样硬件上的多核CPU就可以充分发挥优势。有人问我:Greenplum能并行处理多个任务吗?回答是:不可能。因为Greenplun已经将机器的IO和处理能力全部发挥出来了,再没有可能同时处理多个任务。
Greenplum还有一个有意思的特性就是在数据装载时,不是我们一般想象的存在一个中心的数据分发节点,而是所有节点同时读取数据,然后根据hash算法,将属于自己的数据留下,将其他的节点的数据通过网络直接传送给他,所以数据装载的速度非常快。
Greenplum HA架构

现在来看Greenplum并不神奇,其实Oracle RAC也是数据仓库非常好的解决方案,类似的技术Oracle全部都有。我们可以这样来做一个假设,如果针对某个固定的SQL,我可以同样用Oracle RAC来做Greenplum做的事情,根据SQL,我们可以把表做 Hash+Range分区(事实上Greenplum也是hash+range分区,用hash将数据分布到不同的数据库上,然后再用range将每个数据库上的表做分区),再利用RAC的并行处理能力。Oracle也有partition-wise join这种类似功能,但是没有数据redistribute的操作。Oracle最大的问题还是在于shared everything的架构,导致IO的处理能力有限,我们的大型存储吞吐量也就1.4GB/S,而且扩展能力也有限。以前曾经介绍过的Oracle database machine,就是Oracle专门为数据仓库的提供的解决方案。
其实并存在什么神奇的技术,Greenplum之所以神奇是因为我们的场景发挥了他的特点,其实我们也可以设计一个场景来得到Greenplum很烂的结论,所以不要相信厂商的数据,不要相信什么可以解决一切问题的技术,那根本不存在。
”不要迷恋哥,哥只是传说。“
–EOF–

7 24th, 2009 | Filed under 大话技术

关于Greenplum数据库,是sun公司来推销他们的数据仓库产品DWA的时候第一次听说的,当时只是了解了一下DWA产品的硬件特性,对这个数据库并没有给予太多关注,只知道它的原型是postgreSQL。最近,我们对这个数据库进行了测试,我们没有使用SUN的DWA硬件,只是用8台普通的DELL PC Server+内置的SAS硬盘搭建了一个廉价的集群,每台机器之间仅仅是普通的千兆网络,测试的结果令人吃惊,这个山寨版的数据仓库集群,甚至比我们用小型机+存储+ORACLE RAC的性能要好很多,IO throughput可以达到4GB/s,而我们最新购买的IBM DS8300(228块磁盘)存储,最好的IO throughput仅仅为1.4GB,而EMC的DMX也是比这个值稍有提高而已。
为什么一个廉价的山寨集群,在数据仓库类型的应用上,比我们昂贵的小型机+存储的表现还要好呢。究其原因,我想可能和ORACLE share everything的结构有关,由于需要在多节点之间共享存储,这样整个系统的带宽就受限于一台存储的吞吐能力,而这种存储通常都比较昂贵。而Greenplum这种share nothing的结构可以将数据分布在多个独立的节点上,理论上这种结构,IO和处理能力可以随着节点个数增加线性增长。其实除了ORACLE以外的其他数据库,比如DB2,MySQL的集群都是采用这种share nothing的结构。再加上Greenplum设计的初衷就是为了大规模分析计算的,不象其他通用数据库,所以山寨版的greenplum集群比ORACLE的表现好也是正常的。
最近,ORACLE和HP合作推出第一款为数据仓库设计的硬件产品database machine,配合ORACLE 11g RAC,号称可以14GB/s的带宽,仔细看过文档之后发现其实就是一套山寨机。系统包含8个HP Proliant DL360 G5 database servers用来作处理节点,采用高速的infiniband互联,组成了一套8节点的RAC系统。由于ORACLE的share everything的结构,所以必然是共享存储的,系统中包含14个HP Exadata Storage Server(HP ProLiant DL180 G5)组成了一个山寨存储系统,每个节点有12块300GB的SAS硬盘,之间同样采用高速的infiniband互联。至于处理节点和存储之间的连接方式,文档中并没有提及,我猜测可能是IP SAN。然后把这些东西打包到一个BOX里面,就是我们所看到的Database machin.
随着SAS磁盘的使用越来越多,其价格低廉,性能完全不逊于FC,为我们搭建廉价存储系统提供了可能。未来,我们的目标是不依赖IBM的小型机,不依赖EMC,HDS的高端存储,甚至不依赖ORACLE数据库,用廉价的硬件和开源的数据库搭建我们的系统。
–EOF–Simon Says dvd

10 7th, 2008 | Filed under 大话技术
标签:

1.山寨
数据库的服务器将不再采购大型的主机和高端的SAN存储。主机尽可能选用PC server,这几年INTEL的CPU能力越来越强,PC server的处理能力与小型机的差距正在缩短。存储我们也尽可能的选用SAS硬盘的廉价存储,而不是FC硬盘的高端存储,甚至还计划搭建我们自己的“山寨”存储。对于MySQL数据库,则直接采用PC server+本地SAS硬盘的方案。
2.MySQL,分布式
mysql数据库+分布式应用架构将是我们未来发展的方向,这几年随着数据量和访问量的增长,数据库的压力也越来越大,ORACLE+小型机+高端存储这种集中式架构越来越不能满足业务发展的需要。明年已经确定将有几个大型项目使用MySQL数据库和分布式的架构,逐步降低我们对ORACLE和高端设备的依赖性。而且我们已经有非常厉害的MySQL DBA-SKY,未来我们将不仅仅局限在ORACLE方面。
3.数据同步
如果我们要做镜像站点或者分布式应用,数据同步是必须解决的问题。我们目前正在进行ORACLE redo log的解析的研究,并且已经取得了相当的进展(当然不是我做的,是部门的一个大牛去做的)。一定有人问我们为什么不用SharePlex,DSG,或者ORACLE的stream来解决,而是一定要自己来做呢。而且ORACLE的redo对我们是一个黑盒,我们有能力解决这个问题吗?首先,我们不是要做一个商业化产品,我们的仅仅是根据我们实际的环境和需要,能够对日志做有限的解析,达到我们的目的即可。第二,商业化的产品价格昂贵,而且对于我们的某些特别的需求,商业产品都无法解决。这就是我们要自己解析日志的原因。
4.镜像
对于镜像站点的搭建,我觉得技术因素并不是最重要的,从项目管理的角度出发,需要的是沟通和计划的能力,细节决定成败,风险往往在我们最看不到的地方。
5.RAC
我们的数据库架构从pc server上的单数据库到RAC,再到现在的小型机。未来由于PC server的大量引入,我们可能又要重新回到RAC的道路上来,由RAC来提供高可用性和有限的性能扩展能力。
6.Greenplum,Hadoop
这两个东西,其实我都不懂。但是他们都很火,都使用了MapReduce技术。MapReduce是google的一个计算模型,用来进行大规模的并行计算。
Greenplum可以理解为SQL+MapReduce,DBA也可以体会到并行计算的快感了。而且很可能明年会在数据仓库部门使用,从测试的结果上来看,用普通PC server搭建的集群比ORACLE的性能要高出很多。
Hadoop是MapReduce的一个JAVA实现,Hadoop实现了一个分布式文件系统(Hadoop Distributed File System)和MapReduce分布式计算模型。它能够把应用程序分割成许多很小的工作单元,每个单元可以在任何集群节点上执行或重复执行。它有以下的特点:

扩容能力(Scalable):能可靠地(reliably)存储和处理千兆字节(PB)数据。

成本低(Economical):可以通过普通机器组成的服务器群来分发以及处理数据。这些服务器群总计可达数千个节点。

高效率(Efficient):通过分发数据,hadoop可以在数据所在的节点上并行地(parallel)处理它们,这使得处理非常的快速。

可靠性(Reliable):hadoop能自动地维护数据的多份复制,并且在任务失败后能自动地重新部署(redeploy)计算任务。

7.me
最后一个关键词就是“我”。2009年,我要如何发展?继续在某个技术领域深耕细作,还是主动求变向新的方向扩展;继续走技术道路,还是逐步向管理转移,或者有机会走向其他领域(比如演艺界或者专业摄影师);怎么样炒作自己,出书,写博,还是裸奔?
每一年都是这样,来临前给我们很多想象,过去后往往又觉得平淡乏味,我们一起期待吧。
–EOF–

1 13th, 2008 | Filed under 大话技术
标签: ,
1 10th, 2008 | Filed under 大话技术
标签: ,