存档

文章标签 ‘mysql’

最近一段时间,我们整理了一些关于Percona,Linux,Flashcache,硬件设备的优化经验,分享给大家:
硬件
1.开启BBWC
RAID卡都有写cache(Battery Backed Write Cache),写cache对IO性能的提升非常明显,因为掉电会丢失数据,所以必须由电池提供支持。电池会定期充放电,一般为90天左右,当发现电量低于某个阀值时,会将写cache策略从writeback置为writethrough,相当于写cache会失效,这时如果系统有大量的IO操作,可能会明显感觉到IO响应速度变慢。目前,新的RAID卡内置了flash存储,掉电后会将写cache的数据写入flash中,这样就可以保证数据永不丢失,但依然需要电池的支持。
解决方案有两种:1.人工触发充放电,可以选择在业务低谷时做,降低对应用的影响;2.设置写cache策略为force write back,即使电池失效,也保持写cache策略为writeback,这样存在掉电后丢失数据的风险。
目前,有一些硬件厂家提供了电容供电的RAID卡,没有电池充放电的问题,可以联系自己的硬件厂商。
2.RAID卡配置
关闭读cache:RAID卡上的cache容量有限,我们选择direct方式读取数据,从而忽略读cache。
关闭预读:RAID卡的预读功能对于随机IO几乎没有任何提升,所以将预读功能关闭。
关闭磁盘cache:一般情况下,如果使用RAID,系统会默认关闭磁盘的cache,也可以用命令强制关闭。
以上设置都可以通过RAID卡的命令行来完成,比如LSI芯片的RAID卡使用megacli命令。
3.开启Fastpath功能
Fastpath是LSI的新特性,在RAID控制器为SSD做了了优化,使用fastpath特性可以最大程度发挥出SSD的能力。如果使用SSD做RAID的方式,可以开启fastpath功能。关于fastpath特性,可以从LSI官网下载资料,并咨询自己的硬件提供商。
4.Fusionio参数调整
基本上,Fusionio无需做任何调整,下列三个参数可能会提升性能:
options iomemory-vsl use_workqueue=0
对于fusionio设备,忽略Linux IO调度,相当于使用NOOP。
options iomemory-vsl disable-msi=0
开启MSI中断,如果设备支持,则打开。
options iomemory-vsl use_large_pcie_rx_buffer=1
打开Large PCIE buffer,可能会提升性能。
操作系统
1.IO调度算法
Linux有四种IO调度算法:CFQ,Deadline,Anticipatory和NOOP,CFQ是默认的IO调度算法。完全随机的访问环境下,CFQ与Deadline,NOOP性能差异很小,但是一旦有大的连续IO,CFQ可能会造成小IO的响应延时增加,所以数据库环境建议修改为deadline算法,表现更稳定。我们的环境统一使用deadline算法。
IO调度算法都是基于磁盘设计,所以减少磁头移动是最重要的考虑因素之一,但是使用Flash存储设备之后,不再需要考虑磁头移动的问题,可以使用NOOP算法。NOOP的含义就是NonOperation,意味着不会做任何的IO优化,完全按照请求来FIFO的方式来处理IO。
减少预读:/sys/block/sdb/queue/read_ahead_kb,默认128,调整为16
增大队列:/sys/block/sdb/queue/nr_requests,默认128,调整为512
2.NUMA设置
单机单实例,建议关闭NUMA,关闭的方法有三种:1.硬件层,在BIOS中设置关闭;2.OS内核,启动时设置numa=off;3.可以用numactl命令将内存分配策略修改为interleave(交叉),有些硬件可以在BIOS中设置。
单机多实例,请参考:http://www.hellodb.net/2011/06/mysql_multi_instance.html
3.文件系统设置
我们使用XFS文件系统,XFS有两个设置:su(stripe size)和sw(stirpe width),要根据硬件层RAID来设置这两个参数,比如10块盘做RAID10,条带大小为64K,XFS设置为su=64K,sw=10。
xfs mount参数:defaults,rw,noatime,nodiratime,noikeep,nobarrier,allocsize=8M,attr2,largeio,inode64,swalloc
数据库
1.Flashcache参数
创建flashcache:flashcache_create -b 4k cachedev /dev/sdc /dev/sdb
指定flashcache的block大小与Percona的page大小相同。
Flashcache参数设置:
flashcache.fast_remove = 1:打开fast remove特性,关闭机器时,无需将cache中的脏块写入磁盘。
flashcache.reclaim_policy = 1:脏块刷出策略,0:FIFO,1:LRU。
flashcache.dirty_thresh_pct = 90:flashcache上每个hash set上的脏块阀值。
flashcache.cache_all = 1:cache所有内容,可以用黑名单过滤。
flashecache.write_merge = 1:打开写入合并,提升写磁盘的性能。
2.Percona参数
innodb_page_size:如果使用fusionio,4K的性能最好;使用SAS磁盘,设置为8K。如果全表扫描很多,可以设置为16K。比较小的page size,可以提升cache的命中率。
innodb_adaptive_checkpoint:如果使用fusionio,设置为3,提高刷新频率到0.1秒;使用SAS磁盘,设置为2,采用estimate方式刷新脏页。
innodb_io_capacity:根据IOPS能力设置,使用fuionio可以设置10000以上。
innodb_flush_neighbor_pages = 0:针对fusionio或者SSD,因为随机IO足够好,所以关闭此功能。
innodb_flush_method=ALL_O_DIRECT:公版的MySQL只能将数据库文件读写设置为DirectIO,对于Percona可以将log和数据文件设置为direct方式读写。但是我不确定这个参数对于innodb_flush_log_at_trx_commit的影响,
innodb_read_io_threads = 1:设置预读线程设置为1,因为线性预读的效果并不明显,所以无需设置更大。
innodb_write_io_threads = 16:设置写线程数量为16,提升写的能力。
innodb_fast_checksum = 1:开启Fast checksum特性。
监控
1.fusionio监控:fio-status命令
Media status: Healthy; Reserves: 100.00%, warn at 10.00%
Thresholds: write-reduced: 96.00%, read-only: 94.00%
Lifetime [...]

7 5th, 2011 | Filed under 大话技术

MySQL单机多实例方案,是指在一台物理的PC服务器上运行多个MySQL数据库实例,为什么要这样做?这样做的好处是什么?
1.存储技术飞速发展,IO不再是瓶颈
普通PC服务器的CPU与IO资源不均衡,因为磁盘的IO能力非常有限,为了满足应用的需要,往往需要配置大量的服务器,这样就造成CPU资源的大量浪费。但是,Flash存储技术的出现改变了这一切,单机的IO能力不再是瓶颈,可以在单机运行多个MySQL实例提升CPU利用率。
2.MySQL对多核CPU利用率低
MySQL对多核CPU的利用率不高,一直是个问题,5.1版本以前的MySQL,当CPU超过4个核时,性能无法线性扩展。虽然MySQL后续版本一直在改进这个问题,包括Innodb plugin和Percona XtraDB都对多核CPU的利用率改进了很多,但是依然无法实现性能随着CPU core的增加而提升。我们现在常用的双路至强服务器,单颗CPU有4-8个core,在操作系统上可以看到16-32 CPU(每个core有两个线程),四路服务器可以达到64 core甚至更多,所以提升MySQL对于多核CPU的利用率是提升性能的重要手段。下图是Percona的一份测试数据:

3.NUMA对MySQL性能的影响
我们现在使用的PC服务器都是NUMA架构的,下图是Intel 5600 CPU的架构:

NUMA的内存分配策略有四种:
1.缺省(default):总是在本地节点分配(分配在当前进程运行的节点上);
2.绑定(bind):强制分配到指定节点上;
3.交叉(interleave):在所有节点或者指定的节点上交织分配;
4.优先(preferred):在指定节点上分配,失败则在其他节点上分配。
因为NUMA默认的内存分配策略是优先在进程所在CPU的本地内存中分配,会导致CPU节点之间内存分配不均衡,当某个CPU节点的内存不足时,会导致swap产生,而不是从远程节点分配内存。这就是所谓的swap insanity现象。
MySQL采用了线程模式,对于NUMA特性的支持并不好,如果单机只运行一个MySQL实例,我们可以选择关闭NUMA,关闭的方法有三种:1.硬件层,在BIOS中设置关闭;2.OS内核,启动时设置numa=off;3.可以用numactl命令将内存分配策略修改为interleave(交叉),有些硬件可以在BIOS中设置。
如果单机运行多个MySQL实例,我们可以将MySQL绑定在不同的CPU节点上,并且采用绑定的内存分配策略,强制在本节点内分配内存,这样既可以充分利用硬件的NUMA特性,又避免了单实例MySQL对多核CPU利用率不高的问题。

资源隔离方案
1.CPU,Memory
numactl –cpubind=0 –localalloc,此命令将MySQL绑定在不同的CPU节点上,cpubind是指NUMA概念中的CPU节点,可以用numactl –hardware查看,localalloc参数指定内存为本地分配策略。
2.IO
我们在机器中内置了fusionio卡(320G),配合flashcache技术,单机的IO不再成为瓶颈,所以IO我们采用了多实例共享的方式,并没有对IO做资源限制。多个MySQL实例使用相同的物理设备,不同的目录的来进行区分。
3.Network
因为单机运行多个实例,必须对网络进行优化,我们通过多个的IP的方式,将多个MySQL实例绑定在不同的网卡上,从而提高整体的网络能力。还有一种更高级的做法是,将不同网卡的中断与CPU绑定,这样可以大幅度提升网卡的效率。
4.为什么不采用虚拟机
虚拟机会耗费额外的资源,而且MySQL属于IO类型的应用,采用虚拟机会大幅度降低IO的性能,而且虚拟机的管理成本比较高。所以,我们的数据库都不采用虚拟机的方式。
5.性能
下图是Percona的测试数据,可以看到运行两个实例的提升非常明显。

高可用方案
因为单机运行了多个MySQL实例,所以不能采用主机层面的HA策略,比如heartbeat。因为当一个MySQL实例出现问题时,无法将整个机器切换。所以必须改为MySQL实例级别的HA策略,我们采用了自己开发的MySQL访问层来解决HA的问题,当某个实例出问题时,只切换一个实例,对于应用来说,这一层是透明的。
MySQL单机多实例方案的优点
1.节省成本,虽然采用Flash存储的成本比较高,但是如果可以缩减机器的数量,考虑到节省电力和机房使用的成本,还是比单机单实例的方案更便宜。
2.提升利用率,利用NUMA特性,将MySQL实例绑定在不同的CPU节点,不仅提高了CPU利用率,同时解决了MySQL对多核CPU的利用率问题。
3.提升用户体验,采用Flash存储技术,大幅度降低IO响应时间,有助于提升用户的体验。
–EOF–
关于NUMA可以参考这篇文章:NUMA与Intel新一代Xeon处理器

6 28th, 2011 | Filed under 大话技术
标签: , ,

近日参加了IT168组织的2011数据库技术大会,并且分享了一个数据库与SSD实践方面的主题。很遗憾,因为涉及的内容比较多,现场时间有限,所以很多问题都没有解答。
PPT中有我的联系方式,大家可以发邮件给我,我会尽我所能回答大家的疑问。
PPT:数据库与SSD的实践与探索
–EOF–

4 18th, 2011 | Filed under 大话技术

这个主题是周末参加博文视点组织的open party上的演讲,准备不足,所以ppt中的内容不多,大部分内容都是现场即兴发挥。
根据这个ppt,我想整理两篇文章,一篇是如何取得SSD的磨损数据,以及SSD的可靠性分析;另一篇是通过实际案例讲述数据分布对于数据库性能的影响,以及flashcache的解决方案。
关于SSD与database的结合,flashcache的应用,这也是我今年的技术重点。
PPT:Database和SSD的实践与探索
–EOF–

3 20th, 2011 | Filed under 大话技术
标签: , ,

关于SSD
去年,我们曾经使用了一批SSD的PC,用来做数据库的服务器,用来提高数据库服务器的IO能力。但是从目前的使用情况来看,如果将SSD作为主存储,存在一些问题:
首先,SSD的稳定性还不够好,我们碰到了一些SSD盘损坏和SSD与机器不兼容的情况发生。
第二,SSD的容量盘都比较小,考虑到稳定性的问题,如果做RAID会进一步损失容量,性价比不高。
第三,SSD属于NAND类型的flash,写操作不仅会产生“磨损”,而且随着碎片的不断增加,写操作的性能会不断下降。
目前看来,SSD并不太适合作为数据库的主存储,写操作并不是SSD的特长,而且作为主存储的代价过高,SSD更加适合作为内存和磁盘之间的一层cache,降低读操作的延迟时间,我们将其称为flash cache。Oracle 11g R2中就提供了这样的功能,Oracle exadata V2配置了flash卡用来做flash cache,可以提供非常高的IOPS。对于MySQL数据库,Google和Facebook都提出了基于MySQL数据库的解决方案。
将SSD和Flash卡配置在PC服务器上,与普通SAS或者SATA磁盘混插,采用数据库flash cache技术,可以达到一个非常理想的性能,代价又不是特别高,我们也在考虑采用MySQL的flash cache架构。但是,如果你采用大型的存储设备,比如EMC和HDS,存储的cache实际上已经起到了一个二级缓存的作用,就没有太多必要使用SSD或者Flash卡了。
使用SSD还可以解决写操作的响应延迟,比如Oracle数据库的redo,因为每次commit都必须物理写入到磁盘上,所以将redo放在SSD上,可以提高写的响应延迟,但是不必将数据文件放在SSD上,因为他们并不是必须被写入的。这里要注意的是,SSD可能出现随着大量的写操作性能下降的情况。在我们的测试中,SLC的写能力比较稳定,而MLC的写能力会出现下降的情况。
SSD一定有光明的未来,取代磁盘只是个时间问题,只是我们还需要等待技术更加成熟,价格更加便宜。
关于可扩展的数据库架构
数据库分片(Sharding)是最简单实用的方案之一,将一个集中式的数据库拆分为很多小的数据库,从而获取数据库横向扩展的能力。但是,Sharding也带来一些问题:第一,应用可能需要进行大幅度的修改,以适应数据库拆分的变化。我们通过数据库代理软件来解决应用透明访问的问题,比如Amoeba,让数据库对应用透明,从而降低应用修改的复杂程度。第二,Sharding带来了一些应用上的限制,比如join,复杂查询和事务,要想解决这个问题比较困难,但是我们可以选择在适当的应用场景来使用,比如:在我们实际的应用场景中,绝大部分压力来自于商品,订单,交易等这类应用,其特点是:访问简单,数据量大,查询压力大。这类应用往往占到系统85%以上的压力,他们是非常适合做数据库拆分的。还有些应用是不适合做拆分的,比如一些查询复杂,事务要求高的应用,采用集中式数据库是比较合适的。我们通过应用场景的不同,选择不同的方案,既可以降低数据库压力,又可以降低应用的复杂程度。
还有一种常见的解决方案,在数据库前端增加一层cache,比如内存数据库,搜索引擎,KV cache等等,属于读写分离架构的一种,通过cache层有效缓解数据库的读压力,提高整个系统的处理能力。在这种架构中,由cache层承载了大量的数据访问,而数据库则退化为一个单纯的数据存储。在我们的系统架构中,就大量使用了memcache作为数据库的外部cache,淘宝也开发了自己的分布式KV  cache(Tair)。
作为DBA来说,我们也常常使用数据本身的功能去解决问题,比如Partition功能,但是它依然受限于单个database的处理能力,如果我们预期到单一数据库可能产生性能瓶颈时,就需要考虑借助一些应用架构去解决问题,而不是总是局限在数据库本身的功能上。
事实上,解决方案都不是孤立存在的,这几种方案经常混合在一起使用,比如Facebook的架构中,就是利用MySQL数据库和memcache,通过Sharding和读写分离等架构,从而使整个网站具备非常高的性能和扩展能力。我们在实际解决问题时,也是如此,从数据库本身的优化,数据库内做分区,数据库拆分,利用memcache作读写分离,多数据库中心架构等等。

关于Oracle和MySQL
Oracle更适合集中式数据库架构,而MySQL数据库更适合分布式架构,在两种架构并存的环境下,我们用MySQL完全去替换Oracle是不现实的。
从公司战略的角度出发,逐步降低对Oracle的依赖,这是一个大的方向和目标,但并不意味着我们需要把所有的应用都迁移到MySQL数据库上,从纯技术的角度分析,这并不合理。
我对MySQL和Oracle的想法是:分布式架构采用MySQL数据库,集中式架构采用Oracle数据库,前者通过数据拆分(Sharding)等手段,解决海量数据处理和弹性扩展的问题,集中式Oracle数据库则用于保存核心数据,提供简单可靠的数据存储和访问服务。合理的使用Oracle和MySQL数据库,集中式架构和分布式架构共存,不仅可以控制Oracle数据库的压力和规模,而且可以降低整体开发成本和维护成本。
关于小型机和存储
虽然说近些年来PC服务器的性能得到了很大的提高,甚至已经超过了小型机,但是小型机也不是一无是处,在稳定性,管理性和维护性等方面,小型机都要比PC服务器高出不止一个档次。其缺点就是价格昂贵,容易对硬件厂商产生依赖。
长远来看,我们要控制小型机使用的规模,但并不意味着要替换掉所有的小型机,对于核心应用的Oracle数据库,我认为小型机还是有价值的,起码在可用性方面有保证。对于MySQL数据库,我们大量采用PC服务器,配合数据库拆分和高可用架构,可以充分利用单台PC服务器的处理能力,又保证整个MySQL数据库集群的可用性。
Oracle和MySQL数据库对于机器的选型也有差异,Oracle选择小型机或者比较高端的PC服务器,比如四路Intel 7500系列,最高可以配置四路六核或八核CPU,在性能上已经超过了我们使用的IBM小型机。MySQL则选择处理能力与IO能力均衡的服务器,通常会配置比较多的本地磁盘,比如双路Intel 5500或者5600系列,本地配置12-16块磁盘,甚至配置SSD或者flash卡。
对数据库而言,存储设备非常重要,通常情况下,Oracle数据库会选择中高端的存储设备,而MySQL只配置PC服务器上本地磁盘或者低端的磁盘扩展柜。因为Oracle的高可用策略通常都要基于共享的存储设备实现(比如RAC,Veritas VCS等),所以SAN存储几乎是必须的选择,而MySQL的高可用策略是基于复制的,并不需要共享的存储设备。(当然,Oracle也有data guard的方式,但是DG的切换过程复杂,需要人工干预,作为高可用策略并不适合,更多是作为一种容灾和备份的机制)。
总的来说,硬件的选择与数据库本身的特性和应用架构有密切关系。从对主机的资源利用率上看,Oracle可以充分利用机器的计算能力,而MySQL对SMP架构的支持比Oracle差很多,单台MySQL数据库可能无法完全利用主机的处理能力,所以MySQL主机配置过多的CPU也是一种资源浪费。
关于“去I/O/E”的策略(分别代表IBM,Oracle,EMC),我个人的观点是“合理使用”,而不是为了去而去。不管是数据库的选择还是硬件的选择,我们的目标应该是不依赖于某个厂商,掌握主动权和话语权,这才是最重要的。
关于NoSQL和Database
NoSQL现在非常火,我也写了一些鸡毛蒜皮的文章介绍NoSQL,NoSQL的出现并不是为了替代database,而是在某些特定的领域内解决问题,所以每个NoSQL产品都有其鲜明的特点,相比之下,Database经过这么多年的发展,已经发展成为非常成熟的商业产品,而NoSQL现在大部分还处于成长的阶段。
NoSQL产品的优势在于:扩展性,灵活的数据模型(非关系型),大规模数据处理等方面,Database的优势在于:通用解决方案,成熟度,运维成本,使用成本等方面。我始终认为他们之间不是替代的关系,而是互补的关系,未来在Alibaba的使用场景中,Database应该还是首选的数据库处理和存储方案,但是在大规模的数据处理和数据仓库计算方面,NoSQL应该可以找到大量的应用场景。
现在我们做技术方案时,往往面临很多选择,但是选择太多未必是件好事,我们在选择的过程中往往会加入个人的喜好,比如对某个技术的喜好和掌握程度,甚至为了证明某些能力,而选择一些并不熟悉的技术,虽然它非常先进,但可能并不适用。每种技术都有其存在的合理性,但是引入过多技术必然增加成本和风险,比如facebook,他们利用MySQL和memcache就解决了绝大部分的问题,而很火的cassandra,在facebook只是很小的一个应用而已。相比较而言,我们使用的技术要多得多,我建议在选择NoSQL和Database产品时,选择简单和成熟的技术方案,后期开发和运维成本都是需要考虑的。
关于DBA
DBA不应该仅仅局限于某个数据库产品,而应该更全面的了解开发架构方面的知识,甚至需要具备开发能力,比如针对MySQL数据库进行修改和优化,这也将大大提高DBA解决问题的能力。
DBA的价值不仅仅在于维护数据库本身,而应该在数据存储方案的选择上做出最专业的判断,这是DBA最大的价值所在。
关于技术发展趋势
我在公司五年多了,最初的数据库就是采用PC服务器,然后我们统一把他们整合到小型机上的集中式数据库,把MySQL换成Oracle,而现在我们又要把小型机换成PC服务器,把集中式Oracle数据库拆分成MySQL数据库集群,这不是简单的轮回,而是技术发展的结果。
虽然现在的发展趋势是分布式架构,但是说不定过几年又会出现超级计算机,从而又走向集中式的道路。我们要做的是能够看到3年内技术发展的一个方向,适应技术发展的潮流,并不断调整目标,在解决问题的过程中不断优化。问题和技术都是不断发展的,试图设计一个完美的解决方案是不现实的,在一个问题被解决后,一定会有新的问题冒出来。
选择简单但是不完美的技术解决问题,先做!然后再不断优化。如果不去尝试,我们永远也不知道下一步要做什么,总是停留在对技术方案本身优劣的讨论上,是没有意义的。
人总是在不断反思,不断否定自我的过程中进步的,技术发展也是一样。
–EOF–
本文仅代表我个人对技术一些看法,欢迎大家拍砖。

9 12th, 2010 | Filed under 大话技术
标签: , ,

最近整理了一些关于数据库架构方面的技术专题,并整理成为PPT,准备拿出来和大家一起分享。
为什么要这么做,并不是要为了证明我自己,更不是为了其他什么目的。因为最近一直有一种强烈的执着,想要做成一些事情,在这之前,必须找到很多志同道合的人一起来努力,所以需要先布道。我并不是为了分享而分享,而是希望这些东西能够改变大家对现在一些架构的理解,真正了解我们现在面对的问题和未来的挑战。
蔡学镛说:大多數的工程師並不是「做了五年的系統開發」,而是「做了一年的系統開發,然後重複五次」。我不希望我和周围的同事们都是如此,所以我分享,帮助别人,也帮助我自己。
PPT:数据库高可用架构

5 27th, 2010 | Filed under 大话技术

根据CAP理论,一致性(C),可用性(A),分区容错性(P),三者不可兼得,必须有所取舍。而传统数据库保 证了强一致性(ACID模型)和高可用性,所以要想实现一个分布式数据库集群非常困难,这也解释了为什么数据库的扩展能力十分有限。而近年来不断发展壮大 的NoSQL运动,就是通过牺牲强一致性,采用BASE模型,用最终一致性的思想来设计分布式系统,从而使得系统可以达到很高的可用性和扩展性。
但是,对于CAP理论也有一些不同的声音,数据库大师Michael Stonebraker就撰文《Errors in Database Systems, Eventual Consistency, and the CAP Theorem》,表示为了P而牺牲C是不可取的。事实上,数据库系统最大的优势就对一致性的保证,如果我们放弃了一致性,也许NoSQL比数据库更有优势。那么,有没有可能实现一套分布式数据库集群,即保证可用性和一致性,又可以提供很好的扩展能力呢?回答是:有的。
目前,有很多分布式 数据库的产品,但是绝大部分是面向DSS类型的应用,因为相比较OLTP应用,DSS应用更容易做到分布式扩展。Michael Stonebraker提到了一种新型的数据库VoltDB,它的定义是Next-Generation SQL Database for Fast-Scaling OLTP Applications。虽然产品还没有问世,但是从技术资料上来看,它有几个特点:
1.采用Share nothing架构,将物理服务器划分为以CPU core为单位的Virtual node,采用Sharding技术,将数据自动分布到不同的Virtual node,最大限度的利用机器的计算资源;
2.采用内存数据访问技术,类似于内存数据库(In-memory database),区别于传统的数据库(Disk-based database),消除了传统数据库内存管理的开销,而且响应速度非常快;
3.每个Virtual node上的操作是自治的,利用队列技术将并发访问变为串行访问,消除了传统数据库串行控制的开销(比如Latch和Lock);
4.数据同步写多个副本,不存在单点故障,而且消除了传统数据库需要记录redo log的开销。

VoltDB与传统数据库的对比,可以看到VoltDB即支持传统数据库的ACID模型,又提供了类似NoSQL产品很高的扩展能力。

这个产品,让我想到了MySQL cluster,同样是shared-nothing架构,NDB存储引擎也要求将数据存放在内存中,数据根据PK被分布到多个不同的节点上,同一份数据可以保存多个副本,防止单点故障。

MySQL cluster目前的主要问题是性能不佳,但是我认为MySQL cluster的架构是分布式数据库未来的趋势,Oracle收购MySQL后,很多人对MySQL的前途表示担忧,而我作为一个用户,除了可能会收费这件事以外,我一点也不担心MySQL的前景,反而有所期待,因为在数据库领域没有任何一个公司比Oracle更懂数据库,而Oracle也正在大力发展MySQL cluster,MySQL cluster一定会成为分布式数据库领域内最好的解决方案之一。
–EOF–

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

本篇文章不得以任何形式转载或发表。

这不是一篇关于Oracle和MySQL技术比较的文章,而是我对Oracle和MySQL甚至 NoSQL产品选择上的一些想法。
我们过去和现在使用了大量的Oracle数据库,几乎我们所有的数据都存放在Oracle数据库里面,我们有高端的小型机,大型存储和全国最牛的DBA团队。这些都让我们引以为傲。
随着业务不断增长,数据量和计算量越来越庞大,我们发现小型机都无法满足我们的需求,除了Oracle我们别无选择,我们被“绑架”了,被IBM,EMC,Oracle绑架了,我们辛辛苦苦赚的血汗钱都交给他们了。
2009年开始,我们引入了MySQL数据库,采用sharding技术,利用PC服务器搭建高可用的数据库集群,极大的降低了我们的成本,并提供了充足的扩展能力,让业务有更大的发展空间。
最近,我们遇到了一些困惑:应用如何选择Oracle还是MySQL?从Oracle迁移到MySQL的意义是什么?Oracle收购SUN之后,MySQL何去何从?
我们的目标不是要用MySQL数据库替代所有的Oracle,事实上,这不现实也不是我们的目标,目前很多应用都依赖于Oracle数据库的特性,相当长的一段时间内,Oracle依然是我们的首选。但是,这并不意味着Oracle是我们唯一的选择,我们选择MySQL和PC服务器来搭建大规模数据库集群,最终的目标是要证明我们具备更换数据库的能力,具备用廉价设备替换小型机的能力,能够用我们自己的软件搭建高可用可扩展的架构。所以说,MySQL只是一个数据库而已,如果某天Oracle将MySQL收费,我们可以换成其他的数据库(比如 PostgreSQL)。我们正在做的事,其中的价值并不能简单的用节省 Oracle license的费用来评估。
阿里巴巴正在研发云计算系统,同样要证明阿里巴巴具备这种能力,这是每一个伟大的公司都要具备的能力。我相信,未来的数据存储肯定不仅仅局限于数据库,数据库和其他NoSQL产品一定会百花齐放。
我们做了大量的努力和尝试,包括Sharding和功能分区,SSD的尝试,MySQL高可用架构,数据同步工具等等,都是为了一个目标:证明的是我们能够设计出一种架构,可以做到用PC server和开源数据库(不仅仅局限于MySQL)来替换高端设备和Oracle,不被设备厂家和Oracle所绑架,将主动权掌握在自己手中。所以,我们不要过分纠结于Oracle和MySQL 在具体性能上的差异,作为一个数据库产品,MySQL无法和Oracle相比,单个PC server的可用性更是无法同小型机相比,但是我们用架构去弥补,整体上达到更高的可用性。
所以,我们不应该单纯用MySQL和Oracle本身的优劣,来评估技术方案,更不能用pc server的可用性和小型机去相比。关键是我们的技术架构能否用廉价的东西搭建出高可用可扩展的系统,这才是我们真正引以为傲的地方。
–EOF–

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

【内容简介】
本书以 MySQL 数据库的基础及维护为切入点,重点介绍了 MySQL 数据库应用系统的性能调优,以及高可用可扩展的架构设计。
全 书共分3篇,基础篇介绍了MySQL软件的基础知识、架构组成、存储引擎、安全管理及基本的备份恢复知识。性能优化篇从影响 MySQL 数据库应用系统性能的因素开始,针对性地对各个影响因素进行调优分析。如 MySQL Schema 设计的技巧,Query 语句的性能优化方式方法及MySQL Server中SQL层和存储引擎层的优化思路。同时还分析了 MySQL 数据库中主要存储引擎的锁定机制。架构设计篇则主要以设计一个高可用可扩展的分布式企业级数据库集群环境为目标,分析介绍了通过 MySQL 实现这一目标的多种架构方式。主要包括可扩展和高可用两部分内容,可扩展部分包括设计原则、Replication 的利用、数据切分、如何使用 Cache 和 Search,以及 NDB Cluster等内容。高可用则主要包括 Dual Master、DRBD、NDB Cluster,以及系统监控等方面。
【作者介绍】
简朝阳,毕业于南京工业大学管理科学与工程学院,管理学学士。擅长MySQL & Oracle数据库应用系统的性能调优与高可用可扩展架构设计,有一定的对Java 和C语言基础。目前就职于阿里巴巴(中国)网络技术有限公司,曾参与过公司多个核心数据库应用系统的设计与实施,目前主要负责 MySQL 数据库应用系统的架构设计与相关维护工作。活跃于 iMySQLer 数据库论坛(http://imysqler.com) 和 MySQL 邮件组(mysqler@googlegroups.com, http://groups.google.com/group/mysqler)。
–EOF–
本书的作者是我的同事,2006年大学毕业后来到Alibaba DBA team,还记得当时DBA没有招聘应届毕业生的计划,但是在校园招聘中,他被评估为“潜力无限”的增值股,所以被破格录用。而我(一个刚刚上路的菜鸟DBA)是他的导师。事实证明,当时的招聘人员的眼光是犀利的,正如他的名字朝阳一样,他成长的速度超过了我们所有人的期望。从最初的Oracle DBA转型到MySQL方向后,迅速成为MySQL领域内的专家。
在这本书之前,中文版的MySQL图书要不是译作,要不就是官方文档的简单翻译,几乎没有自己的思想。而这本书则完全不同,首先它不是一本MySQL的入门书,也不是用命令堆砌的参考书,而是一本深入介绍MySQL原理的故事书。作者通过大量实际的案例,讲述了MySQL数据库优化原理,以及架构设计方面的内容,这些内容都是在实际工作中不断积累的宝贵财富,在其他任何文档中都找不到。
作者从一个应届毕业生到数据库大师,只花了三年时间,在这个过程中,我见证了他的成长,也从他的导师变成了学生(我也开始学MySQL啦)。在他的成长轨迹中,我看到了信念,坚持,行动和态度。对于每一个想成为DBA的年轻人来说,现在就像朝阳那样开始吧。
我们,依然在路上……

6 11th, 2009 | Filed under 一地鸡毛

SUN被收购的传闻一直没断过,昨天终于尘埃落定,Oracle以74亿美金收购SUN。
我们来看看Oracle得到了什么?Sun的硬件产品,Java,Solaris和MySQL数据库。前三个产品对Oracle来说应该是非常有价值的,只有MySQL前景不明。因为Oracle的CEO Larry Ellison有句名言,与对手最好的竞争方式就是收购它。
对MySQL唯一的利好消息是,InnoDB也在Oracle手中,不用再担心存储引擎的问题了。关键是Oracle对MySQL的态度如何?作为一个竞争产品打入冷宫,继续发展走商业化路线,还是保持现在的开源身份,让我们拭目以待吧。
–EOF–The Negotiator release

4 21st, 2009 | Filed under IT江湖
标签: ,