查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

风轻扬

活着就是为了追求幸福

 
 
 
 
 
 

NTSE最近的进展及随想

2011-8-10 18:20:54 阅读4827 评论9 102011/08 Aug10

一、NTSE 0.7发布

几天前NTSE 0.7发布了,核心功能有基于字典的记录压缩和在线建索引两个。在线建索引功能能够在不影响事务并发读写时建索引,并且是由基于排序的高性能索引创建算法,对提高数据库的可用性很有帮助。在线建索引比较简单,重点要说的是基于字典的记录压缩。首先来看模拟博客日志模块的blogbench测试结果。

上图是NTSE 0.7和NTSE 0.5及InnoDB的性能对比,纵坐标是TPS,横坐标是内存占数据量的比例。可以看出NTSE 0.7比0.5在小内存配置下又有了近一倍的性能提升。与InnoDB相比小内存时的吞吐率达到15倍以上。第二个数据是压缩后记录占用的存储空间也节约了将近一半。这样,对部分应用无论从任何角度考虑,用NTSE 0.7都可以比用NTSE 0.5时节约一半硬件资源。相比InnoDB,大约可以只用1/4的硬件。这一结果可谓非常理想。看来记录压缩对提升WEB应用的数据库性能还是很有帮助的。

NTSE的记录压缩基于表全局字典来做,不同记录和页面中的记录都共享一个字典,多个属性可以组合压缩成一个单词,一个属性内部也可能被切分成多个单词来压缩,压缩率远高于InnoDB的页面级zip压缩(只能说InnoDB的页面级zip压缩太烂了)。在内存中也是压缩格式因此能够显著的优化缓存效率减少IO。压缩和解压以记录中的属性组为单位(默认记录中所有属性都是一个属性组),压缩和解压都非常快并且粒度非常细,因此启用压缩对性能的影响非常小,纯内存blogbench测试开不开压缩对吞吐率几乎没影响。

二、NTSE又添新应用

作者  | 2011-8-10 18:20:54 | 阅读(4827) |评论(9) | 阅读全文>>

基础系统软件的价值

2011-7-21 14:59:29 阅读7796 评论16 212011/07 July21

盛大推出云计算服务,看起来想做类似于Amazon AWS的IaaS。看了一下,结构化数据管理的功能很弱,只有最简单的Key-Value服务,只有GET/PUT/DEL,没有条件更新没有锁,没有扫描,这让我觉得很不靠谱。结构化数据管理是99.9%的应用都需要的,而基于盛大云这样简单Key-Value来开发应用是很麻烦的事。比如:

1、如果把多个实体属性拼起来,没法索引,效率也不高;如果分开,那经常得用很多个GET;

2、没有索引和扫描,各种数据列表都不容易,比如按时间/阅读次数/评论次数排序的文章列表,你要用一个KV来维护ID列表,这会涉及复杂逻辑(比如按阅读次数排序的列表就不好搞),而且还会数据不一致;

3、刚说到阅读次数,好把,基于盛大云要维护一个会被并发更新的准确的计数是不容易,很不容易,简单到文章阅读次数,评论次数,好友个数等等。因为没有条件更新和并发控制,你把值读出来,+1再存回去,一并发就错了。

总之,这种最简单的Key-Value系统,我一直认为是对系统实现者来说是福音,但对系统使用者来说是绝对坑到祖宗的玩意。如果盛大云就只有这把刷子,没几个开发者愿意用。还好盛大云据说会推出MongoDB服务,这还算有点靠谱。

我越来越觉得这不是正确的做事方式。我觉得做基础系统软件,是希望能够让用户(也就是基于这些基础软件来做应用的人)能够很简单的做出正确、稳定并且高效的应用。很简单的做出应用是指开发效率高;系统不出错并且稳定,这几点是最重要的,高效是在满足前面这几点之后再追求的。系统常出错或不稳定,性能再高也没用,这点可能不用多说。但开发效率的重要性,是工作之后再深刻的体会到的。

作者  | 2011-7-21 14:59:29 | 阅读(7796) |评论(16) | 阅读全文>>

分布式事务性能分析

2011-7-13 17:18:28 阅读6269 评论12 132011/07 July13

这两年来,随着NoSQL系统、CAP理论和Eventual Consistency的大热,关于分布式操作要保证强一致还是弱一致性的讨论络驿不绝。双方各执一词,倾向实现强一致性的一方认为弱一致性满足不了应用开发的需要,倾向实现弱一致性的一方则认为保证强一致性将导致系统性能与可伸缩性难以接受。弱一致性能否满足应用开发的需求这一点由应用特征决定,难以一概而论,但强一致性对系统性能、可伸缩性和可用性的影响则是可以作技术分析的。奇怪的是,找了很久,也没找到对这一问题的深入分析,决定自己来做一个。

对于分布式操作,一般来说有以下两种实现选择:

1、    在每个节点上使用单独的事务,只实现弱一致性。

2、    使用2PC保证强一致性。即分布式事务协调者先要求所有参与节点PREPARE,大家都说PREPARE成功后,再要求所有节点COMMIT。只要有一个节点PREPARE不成功,大家都要回滚。这样参与者要强制写两次日志,协调者在决定要COMMIT时也要强制写一次日志。

首先,假设用户发起分布式操作的速率为TpS(Transactions per Second),每个分布式操作平均会操作K个节点。在每个节点上,平均要操作RpT(Rows per Transaction)条记录,而操作每条记录平均要用时TpR(Time per Row),这样在每个节点上事务操作的执行时间为:

    TExec=RpT×TpR

另外,设定以下参数:

作者  | 2011-7-13 17:18:28 | 阅读(6269) |评论(12) | 阅读全文>>

Facebook Open Compute:如何实现一个高效低成本的数据中心

2011-7-8 9:28:26 阅读5904 评论1 82011/07 July8

Facebook Open Compute(FOC)是一个很无私的项目,据说一个团队辛辛苦苦搞了18个月,最终的结果很无私的公布出来。就这点来说Facebook比Google开放的多了,Google的数据中心技术上很保密。

搞FOC项目的目的是想建一个业界最为高效和低成本的数据中心,所谓高效,指的是能源效率,简单的说关键就是PUE。最终的成果很不错,PUE达到1.07,比目前业界主流先进水平高38%,建设和运营成本降低24%。PUE 1.07确实是很牛了,像国内的机房据说PUE一般只有2,一半的电力都没有供给给IT设备,而FOC只有7%的电力没有供给给IT设备。再优化的余地不多了。当然业界也不是只有FOC一家能做到很低的PUE,根据下图,Google和Yahoo的数据中心的PUE也都是接近的。但业界主流的传统运营商机房的PUE相比确实是差多了。

要建一个极低PUE的数据中心,气候条件很重要。最近Google号称是在搞海里的数据中心,用海水来冷却和发电。FOC没这么夸张,但FOC的数据中心特意的选在一个总体来说天气干冷的地方,这样才适合使用蒸发冷却系统。具体是在Oregon州的Prineville,沙漠地区。这里夏季7月气温最高时平均最高气温约30C,但湿度低干湿球温差很大,冬季最冷的1月份平均最高气温约10C,湿度也不大。蒸发冷却这个专业不懂,但大致说来应该是湿球温度低,干湿球温差大时就比较合适。

此外FOC对机房环境的制定比ASHRAE(美国采暖、制冷和空调工程师协会)的标准要松,ASHRAE标准是干球温度最高80.6F,FOC最高允

作者  | 2011-7-8 9:28:26 | 阅读(5904) |评论(1) | 阅读全文>>

SSD的随机写一定很慢吗?

2011-7-7 22:03:55 阅读8354 评论6 72011/07 July7

对SSD一种常见的认识是随机读、顺序读、顺序写都很快,但随机写很慢。从很多目前公布的产品性能指标数据和测试结果看,确实如此。一般SSD小块随机读性能可以达到几万甚至过十万,但小块随机写性能则一般只有3-5千,相差一个数量级。

我认为这一认识不完全正确。SSD是一个很复杂的硬件,也还在不断改进,各代产品的性能表现往往有很大差异,针对不同的IO操作模式,SSD的性能表现可能有非常大的差异,它的性能表现决不能用“三快一慢”来简单的描述。要用好SSD,需要从原理上对SSD有深刻的理解,这样才能预计各种应用模式下SSD的性能表现,特别是才能预计出未来SSD的性能特征将走向何方。

SSD最基础的硬件是一堆可以并行操作的NAND Flash,之上的控制器提供了读写缓存、LBA到HBA的映射、wear-leveling、garbage collection等众多功能。控制器非常复杂,各个产商的实现也都不同,但基本上可以认为一个设计的还不错的SSD应该能够较好的发挥出底层NAND Flash的性能。如此,了解底层NAND Flash的性能特征非常重要。根据Wikipedia和《Design Tradeoffs for SSD Performance》论文的数据,NAND Flash的基本性能指标大致如下:

   4K Page read latency: 25us

作者  | 2011-7-7 22:03:55 | 阅读(8354) |评论(6) | 阅读全文>>

数据库如何抵抗随机IO:问题、方法与现实

2011-4-21 19:48:51 阅读17511 评论14 212011/04 Apr21

随机IO几乎是令所有DBA谈虎色变的一个问题,这个问题,往往在数据量小的时候不出现,在数据量超过内存大小时,才陡然出现,令没有经验的DBA促不及防,也令有经验的DBA寝食难安。

传统的数据库架构对随机IO几乎没有还手之力。传统数据库的核心通常是页级缓存、B+树、堆或索引组织表,这些机制,对随机IO的抵抗能力,都无一例外的可悲的差。页级缓存有很强的“连坐”效应,就是为了要缓存一条有价值的记录,顺带可能要同时缓存百条无价值的记录。传统上这一点自豪的称之为locality,是用来减少IO的,但往往会导致内存缓存的利用率很差。在记录的级别,应用的访问模式通常符合Zipf分布,其中10%的记录所占的访问概率超过90%。如果我们用记录级的缓存,用相当于数据量10%的内存,就可以消除90%的IO,但用页级缓存,这10%的热点记录,很可能就分布在70%的页面上,这样同样10%的内存,很可能只能消除可悲的30%的IO。B+树的情况也好不了,如果索引大于内存量,每次随机的索引搜索、插入和删除,几乎都将带来一次随机IO(假设索引的非叶节点都在内存中)。

新的SSD硬件可以缓解随机读问题,但对随机写依然是无能为力。SSD的技术比较成熟了,期望它哪一天能魔术般的也搞定随机写,是不现实的。但我们可以从数据库架构上来想办法,谢天谢地,其实有很多办法,虽然未必能马上就用上。

先说记录的随机IO。之前已经说过,用记录级的缓存是很好的,我们

作者  | 2011-4-21 19:48:51 | 阅读(17511) |评论(14) | 阅读全文>>

InnoDB加锁实现机制初步分析

2011-1-7 16:04:40 阅读3033 评论3 72011/01 Jan7

虽然普通的SELECT在InnoDB里是不需要加行锁的,但LOCK IN SHARE MODE、更新操作及高串行化级别中的SELECT都要加锁。InnoDB宣称其行锁实现非常先进,开销只有每行3-4 bit。传统的数据库锁表结构,锁定一条记录时要构建一个包含被锁定对象ID信息、等待者队列、持有者队列链接等一系列东东的复杂数据结构,开销至少在100字节以上。InnoDB竟然可以做到只有3-4 bit,真是牛到不可思议。

于是,去初步了解了一下。基本原理应该是像这篇日志里说的这样还是用的Hash的锁表,只不过不是锁一条记录就创建一个复杂的结构,而是用位图来表示页面中各记录的锁定情况,这样,一个事务锁定页面中的很多行时,只需要把很多个位置设为1就行了,事务锁定大量记录时的平均空间开销就会很小。上述日志里做了个测试,一个事务锁定过百万条记录时,确实锁表占用的空间大概只有每条记录3 bit。

据此推测,如果一个事务只锁定页面中的少量记录,那这个平均开销就大了,上述日志没做过这样的测试。我简单测试了一下,发现确实如此,如果只锁定一个页面中的一条记录的话,也会新建个lock struct,占用空间似乎过百字节。如果一个事务锁定属于同一页面的两条记录,则只有一个lock struct,如果锁定不属于同一页面的两条记录,则就会产生两个lock struct。另外一条记录如果被N个事务同步锁定,锁占用的空间似乎就会达到N倍。

作者  | 2011-1-7 16:04:40 | 阅读(3033) |评论(3) | 阅读全文>>

Dropbox差异同步算法rsync及其改进算法原理

2010-11-12 17:26:32 阅读9921 评论8 122010/11 Nov12

之前用过rsync很多次,只知道可以做差异同步也没研究过原理。所谓差异同步是指只通过传输两文件的差异部分将两文件同步到一致,自己取的称谓,不知道学术术语是什么。差异同步算法中最有名的就是rsync系列了。

近来研究Dropbox,想看看它的同步怎么做的,没找到官方资料,不过据推测应该用的就是rsync,于是,看看鼎鼎大名的rsync是怎么实现的吧。

rsync算法要解决的问题很简单:A和B两个文件在两台服务器中,要将A同步到与B一致,要求尽量减少同步带来的网络传输开销。

rsync基本算法

先说基本的rsync算法,并不复杂,简单的说是三步:

1、按固定大小将A分为多块,每块都计算出一个32位的滚动哈希值和一个128位的MD4(有些也用MD5),发给B一端。

2、B一端从位置0开始按的同样块大小的滚动哈希值,查找看是否命中A给的某个滚动哈希值,若匹配,则表明B文件中的这块内容与对应的A中的那块内容很可能是一致的,但由于32位的哈希值强度不够,因此再计算MD4,若还是匹配,则确认是一致内容,这时B发给A端匹配的段号。对于那些不能匹配的内容,则发给A端原始内容。

3、A端得到B端给的匹配信息,构造一个与B一致的复本,若是匹配的块,则拷贝原A文件中对应的块,若是不匹配内容则追加之。

作者  | 2010-11-12 17:26:32 | 阅读(9921) |评论(8) | 阅读全文>>

无欲无求的生活

2010-11-6 0:54:06 阅读2544 评论12 62010/11 Nov6

听了一天的云计算数据中心的报告,若有所思却又难以理清。百度和Google的分享都相当质朴,虽然了无新意,而其它的所谓云计算的宏伟蓝图大都抽象莫明,即便连演讲者自身都体现出不自信。

年初在国家项目期间曾写下“自信则无忧,尽力即无憾”来勉励自己以求平和的心态,半年多来,这两句话时常想起,似乎真的心态平和许多了。

从小在青山绿水间长大,靠山面水,方圆50里没有工业。从小过着无欲无求的生活,从小学、中学直到大学,像汪峰《春天里》一样没有烦恼。很多人说高中很辛苦,我觉得相当之奇怪,明明高中和本科是最最开心的时光了,只要做了功课什么都不需要想,还有那么多的女孩给我来暗恋,还有些女孩暗恋着我。不知为什么,感觉从研究生到工作开始,会有烦恼,有时会轻度抑郁,二三天不知所衷,要找亲朋好友开心一刻才能好。无欲无求的生活似乎离我越来越远。

可幸的是,这一年以来,这样的生活又离我越来越近了。也许当你看到孩子灿烂的笑脸,你会明白你失去的有多少,父亲的心似乎可以柔化一切。也许因为每天上下班时听的摇滚让我回忆起曾经的单纯。当你有了妻子孩子和可靠的居所,还有多少重要的利一定要去追求呢?虽然名的放下还远。无欲无求但可以有许多梦想,希望能做出更好许多的系统,希望能做好产品,希望有条件再多一个孩子,希望能再拥有一个靠山面水,每天可以去游泳钓鱼的房子,希望能帮助到家人朋友等等,似乎有欲有求,但求的都不是生活所必须的事情,即便个个落空,生活一样可以家庭幸福快乐美满,人生一样可以快快乐乐,如此这些欲求都可以抛弃。只求将来不要得癌症折磨一年半载,只希望可以中风安然西去。

作者  | 2010-11-6 0:54:06 | 阅读(2544) |评论(12) | 阅读全文>>

沪杭高铁

2010-10-29 22:43:20 阅读1588 评论4 292010/10 Oct29

到上海出差,算是第一次座上高铁,之前由于有很多听闻,比如:

1、我们的高铁因为要大干快干赶紧上,都没有经过严格测试就上了;

2、人家老外其实也没大规模用过,拿咱当小白使;

3、我们的高铁非常脆弱,有人抽根烟都会使它怕了高不起来;

因此心里还有些怕怕,尤其是上车之后发现连个安全带都没有,心想这要出事我就乐去了。不过坐了之后,感觉还挺平稳,一点感觉不出是350码。

传说中会显示运行速度的LED没看到,还好有手机GPS显示速度,但有人确实是拍了照片的,奇怪。我想这速度还是不要显示的好,不要挑战某些人的神经。

坐车上先睡了回,然后看车上的杂志,讲上海虹桥火车站的,一下子50多分钟就过去了,似乎没感觉到车子有中途停靠过,所以,泸杭高铁会在嘉兴南站等中途站停吗?都没搞清楚,晕。

还得说一下虹桥火车站,这玩意其实不能称火车站,那是包括航空在内的大大大大的交通枢纽,那个大,大无边了。一下车,看到一列列乳白色的CRH排着,确实是相当之壮观。下高铁坐地铁走不了多少路,挺方便,看来设计者是下了一些工夫,想起北京的某地铁换乘,不知道是哪个艺术家设计的,曲径通幽处,走得那叫一个累。

据说这个是史上最大,世界最大。这玩意肯定有很多人说它劳民伤财的,这么多钱,为啥不补贴给咱老百姓,不过史书上从来不会这么写。我觉得是有必要的,在车上杂志里看到有人说:看了虹桥火车站,明白为什么《2012》里安排中国做避难所了。有理,这么大的工程,只有疯狂的中国人才能干啊,朝鲜应该是更疯狂的,可惜没那体力。最发达的老美

作者  | 2010-10-29 22:43:20 | 阅读(1588) |评论(4) | 阅读全文>>

公司乔迁之喜

2010-7-7 17:23:58 阅读2297 评论4 72010/07 July7

这事值得纪念一下,以前是租的单元房,一下子升级成别墅了。不过,啥时候要是很多员工都能搞上个别墅,那公司才叫是真正成就了啊。

哂两张照片,楼太大站得太近,实在拍不下啊。公司这么多玩单反的,等公司大楼都整好后,搞个摄影大赛吧,以后出去宣传就不用哪个什么效果图了。

作者  | 2010-7-7 17:23:58 | 阅读(2297) |评论(4) | 阅读全文>>

NTSE性能提升,稳定性有待加强及随想

2010-6-22 17:42:41 阅读3571 评论6 222010/06 June22

经过几个月的努力,新发布的NTSE 0.4不但实现了NTSE自主写binlog功能,性能也有很大提高。以下是NTSE与InnoDB的对比测试,在内存是数据量的10-20%时,NTSE开启MMS时的性能有了很大的提升,达到InnoDB的9倍左右,是InnoDB结合Memcached使用时的4倍左右。其实InnoDB的性能比之前也提高不少,原因是这次测试将sync_binlog设成0,之前设为1过于严格,导致InnoDB性能很差。

不过NTSE的稳定性还有待提高,目前还已知两个问题,一是NTSE写的binlog有可能某些时候不对,二是堆和索引有时会不一致,虽然通过重建索引可以解决,但不能确定结果是不是百分百正确的。

NTSE的性能优势已经很明显了,暂时没有太大的必要再优化,目前最重要的工作是提高稳定性。在第一步都没有坚实的跨出去的时候,应该把系统搞得简单点,这是我做NTSE所获得的教训。作为第一步,NTSE最核心的一点应该就只有性能,而对性能来说最核心的只有两点:

1、内置的行级缓存,且UPDATE也可以被缓存,进行检查点时被UPDATE的记录不能强制更新到堆中;

2、大对象压缩

只要有这两点,NTSE相对于InnoDB的性能优势就应该是板上钉钉的事情。考虑到将来改起来不易,最多再加个索引前缀压缩。现在回顾一下,其实目前NTSE实现的很多功能,都不是必需的,比如:

1、高性能UPDATE。这个功能虽然对某类特殊的应用有很大作用,但对普通应用并没有太大价值;

2、定长和变长两种堆。单独为定长记录设计一种堆格式并没有太大价值;

作者  | 2010-6-22 17:42:41 | 阅读(3571) |评论(6) | 阅读全文>>

最近不写博

2010-5-12 21:10:19 阅读1280 评论2 122010/05 May12

最近不写博,有空写点装修日志吧,有兴趣的移步这里http://www.19lou.com/forum-72-thread-28466259-1-1.html

作者  | 2010-5-12 21:10:19 | 阅读(1280) |评论(2) | 阅读全文>>

2009年数据库技术领域回顾(转载)

2010-2-23 10:18:24 阅读2726 评论6 232010/02 Feb23

我用有道阅读看到这篇好文,希望和大家分享。我的看法是:

1. NoSQL运动的核心并不在SQL,也不在Key-Value。现在大部分所谓的Key-Value数据库,都支持根据各属性进行索引扫描的访问方式,并不是纯粹的只能根据Key来访问。从数据模型上说,这些Key-Value数据库已经相当于必须有主键的关系模型。而这些Key-Value数据库的操作语言,也类似于受限的SQL,主要是没有联接与子查询。NoSQL运动的核心,可能是在于BASE/CAP与关系数据库的ACID的区别,然而,BASE/CAP还是ACID,与数据模型并没有强制绑定关系。

2. 基于MySQL的开源产品Drizzle发展的非常好,我在开发存储引擎中遇到的很多问题,Drizzle中都已经解决了,比如:存储引擎和MySQL上层都要维护表定义带来的不一致问题;非标准表定义信息的传递与修改等。我认为Drizzle的未来很好,被Oracle控制的MySQL官方版本的未来是黯淡的。

3. 虽然SSD还没有爆发,但马上就会爆发的。

4. 关于国内BeansDB,还有之前开源的MemcacheDB的开源的两个疑问:一、不清楚为什么决定要开源;二、开源后,更新很少,似乎开源的都是老版本,最新的东东还不愿意拿出来分享,也没什么意思嘛。

以下原文转载自

作者  | 2010-2-23 10:18:24 | 阅读(2726) |评论(6) | 阅读全文>>

苹果低调投资眼动仪公司 Tobii(转载)

2010-1-13 10:52:58 阅读1947 评论0 132010/01 Jan13

我用有道阅读看到这篇好文,希望和大家分享。我的看法是:

我规划了一套将来用眼睛取代鼠标的方法:眼睛盯着,眨一下左眼表示单击左键,眨一下右眼表示单击右键,双眼一眨表示双击。闭着左眼移动视点表示拖动。似乎很酷啊,到时候公司里一眼望过去一堆人挤眉弄眼的。

以下原文转载自apple4us

在收购兼并方面,苹果一向极尽低调之能事,当然,比起它的很多硅谷同侪,比如思科和谷歌,苹果的收购也算得上极少。

我们能粗略数出来的: Casady & Greene、CoverFlow、P.A. SemiEditGridLalaQuattro可能收购 iCall……以及很可能是乔布斯本人投资的 Aviary

我在之前曾经写过:

苹果一向有对小公司、小产品点石成金般的收购能力:2000 年时,苹果买下了一家叫 Casady & Greene 的公司及其产品 SoundJam MP 的所有权,这个仅涉及三名员工的收购在不到十年之后成为年收入 40 亿美元的 iTunes;2001 年,他们招纳了一个怀揣音乐播放器创意的前菲利普员工,这个叫 Tony Fadell 的年轻人搞出了最初的 iPod; 2006 年 7 月,一家名为 Steel Skies 的设计师做了一个名为 CoverFlow 的呈现 iTunes 音乐的专辑封面的小产品,2 个月内就被苹果收购并整合进入 iTunes,甚至将此技术一路应用到其 OS 的文件管理中。

今天我们听到了这方面的最新故事:苹果战略投资了瑞典眼动仪公司

作者  | 2010-1-13 10:52:58 | 阅读(1947) |评论(0) | 阅读全文>>

查看所有日志>>

 
 
 
 
 
 

重要链接

 
 
模块内容加载中...
 
 
 
 
 

精华区

 
 
模块内容加载中...
 
 
 
 
 
 
 

浙江省 杭州市 金牛座

 发消息  写留言

 
关注互联网应用架构、分布式与海量数据处理技术、云计算、数据库技术
 
博客等级加载中...
今日访问加载中...
总访问量加载中...
最后登录加载中...
 
 
 
 
 
 
 
心情随笔列表加载中...
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018

登录  
 加关注