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

风轻扬

活着就是为了追求幸福

 
 
 

日志

 
 
关于我

关注互联网应用架构、分布式与海量数据处理技术、云计算、数据库技术

网易考拉推荐

NTSE 0.3性能白皮书  

2009-12-03 22:04:59|  分类: NTSE/TNT |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
经历1年半时间开发的NTSE存储引擎今天达到了一个令人振奋的里程碑。今天不久将要发布的NTSE 0.3版本与InnoDB的性能对比测试结果已经出来了,见下图:
NTSE 0.3性能白皮书 - 风轻扬 - 风轻扬
图中横坐标是内存与表大小的比例,由于相同的数据量时使用NTSE和InnoDB时的表大小不同,这一比例是相对于InnoDB的表大小的。纵坐标是tps,即每秒处理的事务数。

从图中可以看出:
1、NTSE性能始终显著优于InnoDB,尤其在内存<=数据量的30%时,NTSE性能大约为InnoDB+Memcached的3倍,为纯InnoDB的4倍以上。也就是说,有些时候用NTSE后,Memcached就可以扔掉了;
2、小内存时NTSE开启MMS对性能有较大帮助,内存10%时与无MMS相比提高75%,内存较大时也基本没有负面影响;
3、小内存时配置Memcached对InnoDB的性能也有较大帮助,在10%内存时提高67%,但大InnoDB内存已经很大时反而有很大的负面影响;
4、NTSE在10%内存时的性能相当于InnoDB+Memcached 40%内存时的性能,20%相当于InnoDB 75%,30%相当于InnoDB 90%,因此在提供同等吞吐率时,NTSE只需要InnoDB 1/3的内存;

另外还有一点,在图中没有给出的是,使用NTSE时的表大小只有InnoDB的54%。

测试使用的是我们模拟博客日志应用开发的blogbench测试程序。这一测试程序操作以下的Blog表:
CREATE TABLE Blog (
    ID BIGINT NOT NULL PRIMARY KEY,  -- 递增生成
    UserID BIGINT,  -- 按zipf分布生成,5%的用户拥有95%的日志
    Title VARCHAR(255), -- 长度10-30字节,平均20
    Abstract VARCHAR(2000), -- 长度10-500字节,平均255
    Content MEDIUMTEXT, -- 长度20-20000,二项分布,平均2.1k,内容取自从博客中随机挑选的100篇日志
    AllowView SMALLINT, -- 91%为-100,1%为100,8%为10000,与博客真实数据一致
    PublishTime BIGINT, -- 发表时的系统当前时间
    AccessCount INT, -- 初始为0
    CommentCount INT, -- 初始为0
    KEY IDX_BLOG_UID_PUBTIME(UserID, PublishTime, AllowView)
);

blogbench会模拟以下七类博客应用中的典型操作:
1. list-blogs: 按发表时间倒数排序显示某个用户最近的10篇日志的信息;
2. show-blog: 显示某篇日志内容;
3. update-access: 更新某篇日志的访问计数;
4. update-comment: 更新某篇日志的评论计数;
5. show-siblings: 显示某篇日志前一篇后一篇日志的标题等信息;
6. publish-blog: 发表一篇日志;
7. update-blog: 修改一篇日志;

表的数据的统计特征、事务的概率组合、事务中参数的统计特征、事务的实现方式都基本与线上数据库一致,因此blogbench能够将真实的模拟当前博客日志模板的行为。当InnoDB与Memcached组合使用时,我们也是完全参照前台的DAO框架实现的,比如使用一个单独的计数Memcached来存储频繁更新的AccessCount,更新AccessCount时不是立即更新数据库,而是放到一个队列里,每隔10秒处理这个队列,去掉重复的更新后再更新数据库和普通Memcached.

可以说,这一性能结果还是非常不错的。当然我们还有一些已知的优化没有实施,比如如果NTSE改为自己写binlog,对AccessCount的更新不是每次都写binlog的话,初步实验发现在10%内存时性能还能再提高30%。但目前的性能已经很不错,短期内不会再实施优化了,我们将全力投入稳定性工作。由于在NTSE 0.2发布时在稳定性上已经有良好基础,我预计NTSE 0.3的稳定性工作也不需要太长时间,应该不出一个月就可以release啦!

在此要非常感谢领导的支持和(曾经)参与NTSE项目的全体成员:余利华、邵峰、苏斌、谢可、张潇、聂明军、潘宁和李伟钊,感谢DDB组同事的大力配合。NTSE是一个非常困难的项目,目前已有C++实现代码9万行左右,测试代码也有8万多行,完成任务600多个,并且对性能和可靠性的要求都极高。没有大家的付出,不可能走到今天。虽然现在NTSE离实用还有不小的距离,但到今天应该说已经有了不错的基础,只要再接再励一定可以早日投入使用。

但NTSE只是起点,不是终点。比如某些应用要求更高,需要事务;某些应用要求更低,你可以连日志、行锁都不要,崩溃了我就重建不需要你恢复,只要给我性能;某些应用希望用key-value模型,不想白白消耗SQL解析、查询优化的开销。这些需求能不能在NTSE基础之上实现,我相信是能的,比如最复杂的事务支持,我想我已经找到了一条可行之路,就是多版本,NTSE底层已经提供了单条记录更新原子性,崩溃可恢复这些保证,我只要在上层给每条记录加上版本号信息并实现可见性判断就OK了,我相信再增加不到1万行代码就可以实现。NTSE如果支持了事务,那就不能叫NT(Non-Transactional)SE了,我想叫TNT(Transactional and Non-Transactional)吧,听起来挺酷的,大家觉得怎么样?NTSE 0.3性能白皮书 - 风轻扬 - 风轻扬
  评论这张
 
阅读(1770)| 评论(22)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

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