NoSQL 在腾讯应用实践

标签: nosql 腾讯 应用 | 发表时间:2014-06-15 03:39 | 作者:杨粼波
出处:http://www.cppblog.com/tx7do/
转载自: http://djt.qq.com/article/view/234

  吴悦, http://t.qq.com/iwuyue  腾讯大讲堂特约讲师,腾讯T4技术专家。先后参与腾讯分布式文件系统(TFS),K-V存储,SQL集群,接入网关(TGW)的设计与研发。见证了腾讯Nosql 从07年诞生,08、09批量应用,10年至今应用于腾讯开放平台让更多的第三方开发者使用;关注于构建具有低成本、高性能、高可用,可扩展,易运营特点的互联网海量后台服务。目前任腾讯架构平台部平台开发中心技术总监。

 

  此文已发表在《程序员》杂志。


一、前言
  NoSQL的历史很长,最早可以追朔到Berkeley DB等嵌入式数据库的年代。互联网行业的高速发展对大数据的需求,为NoSQL的发展起到了推波助澜的作用。互联网时代的NoSQL,源起于Google为解决大数据的存储与计算而提出的GFS + Bigtable + Map Reduce。随后Hadoop  (Hdfs+Hbase+MapReduce)、 Hypertable、Memcached,Tokyo cabinet,Redis, Dynamo,Cassandra等等NoSQL 产品雨后春笋般的推出,使得Nosql技术广泛应用于互联网各个领域。
  在腾讯过去的几年中,互联网社交平台取得令人瞩目的发展。包括平台用户基数、在线、应用数都取得突飞猛进的增长;另外随着开放的加剧,还有越来越多的第三方选择社交平台开发应用。这些外部条件的变化对技术平台的而言,也带来了新挑战:除需要为用户提供更强的海量服务外,同时还需要提供开放的软件基础架构来帮助第三方开发海量服务。
  在解决这些问题的实践中,总结了很多经验。其中关键一点则是通过NoSQL技术来构建海量服务的数据层,并通过分析和总结出不同的业务场景和技术特点,为各种场景提供更合适的数据层解决方案。具体而言:
 相册、日志等UGC类应用,主要是自我产生数据,他人以浏览为主,其技术特点是读取量巨大,修改量低于读取量一个量级,数据量从几百T至P级不等。提供SAS、SATA级的TDB、TFS解决方案。
 农牧场等Social Game类应用,核心数据是用户背包数据,互动性很强,其技术特点是巨大读取量与修改量,数据量在百G级别。提供MEM级的TMEM解决方案。
 信息中心的Feeds类应用,其技术特点是巨大的修改量与读取量,数据量也在几十T到几百T不等。提供SSD级的TSSD解决方案。


二、【2006~2008】因QQ相册而研发TFS、TDB
  回顾NoSQL在腾讯的发展历程,需要从2006年腾讯分布式文件系统TFS      的研发开始谈起,TFS目的是在公司内部构建统一的存储平台,为各个BU提供文件系统服务。第一期的重点是要能够支持到QQ相册的快速发展。当时QQ相册使用传统企业级存储硬件+标准linux文件系统的老架构,在数百亿的图片数,每天近10亿长尾下载的规模下已难以为继。通过分析,老架构主要有下面三个问题:
 采用FC-SAN等高端企业级存储硬件,这些硬件主要是针对电信、银行等高ARPU值的行业客户而生,价格通常比较贵,对盛行免费的互联网企业来说,成本压力大。
 使用通用的linux文件系统,对相册海量小文件的场景,空间利用和IO性能都不能很好的满足要求。
 元数据与对象数据耦合,扩展性和可维护性较差,单机故障以及扩容都是异常繁琐的运维操作。
  TFS采用廉价的存储设备,在软件层面使用类似软raid的技术来满足系统基于不可靠硬件的可靠性要求。将对象数据与元数据分离:对象数据存储采用自研的CHUNK文件系统,inode节点更小,空间分配采用了基于append + delete更为紧凑的管理方式,使得单机最大可以支持数10亿的图片文件;元数据使用MYSQL存储。系统架构如下:


  上面的架构很好的满足了数百亿级别规模下的QQ相册业务发展。大致在07的时候,QQ相册采用TFS的新架构趋于稳定,同时业务发展需要,对用户上传也放开了限制,用户上传浏览的活跃度上升的一个新的量级,用户目录、文件索引等元数据规模突破千亿。在使用MYSQL应对如此大规模的元数据的场景下,暴露出一些问题:
 索引低效:在QQ相册的场景,上千亿的记录,使用MYSQL的B树索引索引的存储量消耗都在数TB到数十TB。 海量索引在无法全内存的情况会带来IO的多次访问,一方面增加了单次访问的时延,另一方面降低了磁盘的IO利用率。
 数据搬迁:每天数亿的图片上传导致系统扩容,IDC分布策略,导致数据搬迁是常态。使用MYSQL,使用select逐条记录方式搬迁,不同的记录分散在不同的磁盘偏移,一方面搬迁速度较慢,另一方面由迁移导致的磁盘随机IO与业务正常访问相互交织在一起,从而影响到在线业务访问。
 系统控制:MYSQL更多针对是各种数据通用场景所做的设计与开发,实现较复杂。在使用中遇到性能问题,异常故障时难以定位原因,对业务系统来说,已经是无法打破的天花板。
针对上面的问题结合业务需求,07年底研发出TDB用以替代MYSQL,TDB是一个典型的K-V存储系统。其特点是:接口简单,性能高效,具备优秀的扩展能力。


  数据层面,索引设计使用HASH,通过KEY可直接定位磁盘物理偏移,避免B树设计导致的二次定位磁盘性能开销,解决索引低效的问题。同时采用16MB大磁盘块的设计,使得TDB的数据迁移速度可达网卡性能上限,解决迁移性能问题。另外系统可控性更强,一方面因为是专用场景,所以可以简化设计,方便定位问题与优化更新;另一方面打通了存储系统到磁盘IO的控制路径,避免MYSQL的系统天花板。
  接入层面,为业务提供透明的访问代理,从而实现无缝的水平扩展。由于接口简单,并且是PAAS,业务使用非常方便,从07年底开始,在Qzone、朋友、群空间等社区应用中逐步取得了广泛应用。
三、【2009】Social Game催生的TMEM
  09年有一款叫农场的游戏大家应该不会陌生,农场的火爆带动了一批Social Game应用的兴起。其典型特点(1)好友间互动性很强,用户背包数据会被频繁的修改与读取;(2)交叉访问,无明显热点数据;举个例子来说,对于传统的应用来说,用户间交互相对较弱,活跃用户数据就是热点数据;而对于Social Game而言,用户交互性强,通过交叉访问,活跃用户也会频繁访问与修改非活跃用户数据。(3)放大效果明显;比如用户每次登陆,通常会遍历好友的农场,会遍历菜地偷菜,捉虫,一次偷菜、捉虫会导致多个用户的多个背包数据修改。这些行为一方面导致整个系统中无明显热点数据,用户传统的读缓存+写落地的方式则难以很好的满足这些业务的需求;另一方面庞大的用户基数之上的火爆应用,往往单款应用就会有数百万次每秒的访问量,这种海量访问不光对存储层面,同时对网络通讯层面提出更高的性能要求。
  针对以上新兴面临的问题,很明显TDB并不能很好的解决,所以09年围绕着网络通信,内存持久化两个方面,做了大量的设计与论证。09年底左右推出新的服务TMEM。


核心有两点:
 提供内核级KCCD网络通讯组件,提升网络通信性能,在网络包量吞吐方面相对于应用层提升了接近1倍的性能。
 通过将操作流水加数据镜像落地TFS,解决了内存持久化的问题。
  TMEM的出现很好的满足了业务海量访问的需求。不过毕竟内存介质的成本比较高,所以TMEM在小数据量的场景下,性价比比较高。但针对于中大数据规模的海量访问的场景,使用TMEM的成本偏高,而使用SAS介质的TDB,则IO性能又不能很好的满足。比如社区中各类应用产生的Feeds,数据量数十TB至数百TB,每天访问量数十亿至数百亿,应对该场景传统的做法必须得是前端内存缓存加上后端落地存储。分级存储导致的内存数据保护,各级间数据一致性,另外最为关键的一点,与Social Game类似,Feeds也是典型交叉访问,热点不是非常明显,等等这些都是数据层亟需解决的难题。
四、【2010】顺SSD之势的TSSD
  在10年的时候,引入了SSD存储介质,开始构建TSSD K-V存储系统。SSD的特点:有着很好的随机读取性能,往往单盘可达数万IOPS,远高于SAS、SATA的数百随机IOPS。容量方面也接近SAS盘的容量,可达数百GB。但SSD也有弊端:(1)寿命有限,随机写入的寿命相对于顺序写入为1/10左右;(2)随机写入场景,性能易受干扰,毛刺率较高;具体而言:受限于物理机制,SSD的存储单元只能先擦除才能写入,并且擦除次数有限,针对NAND芯片,在3000~5000次左右。其中擦除单元是512KB,写入单元是4KB。随机写入的场景,会带来写入放大。
  因此应用SSD存储介质,必须优化随机写入性能。TSSD通过构建地址映射,增加随机写入内存缓冲区,实现随机转顺序的写入;通过定期的垃圾回收机制,回收垃圾数据。


  TSSD系统中,单机可以支持容量数TB,性能随机数万次IOPS。这样基于TSSD使用简单的架构,更少的机器便可支持到容量数十至数百TB,性能数十万IOPS的Feeds类应用。
五、NoSQL小结
  至此,业已构建出基于内存、SSD、SAS、SATA的各类存储介质的存储系统,在上面也已提到各类存储系统所对应的使用场景。实际应用中,各种业务场景千变万化,有没有统一的方法来判别和选择合适的存储系统呢?大致在 1987 年,Jim Gray发表了这个"五分钟法则"的观点,简而言之,如果一条记录频繁被访问,就应该放到内存里,否则的话就应该待在硬盘上按需要再访问。这个临界点就是五分钟。这个看似经验公式,隐含的是硬件性能和成本两个方面的因素。大约在97的时候,Jim Gray再次回顾了该法则,并引入了SSD,验证了该法则依然正确。这里不在赘述该法则。
  很多情况下需要一种直接根据业务的访问模型,因此使用IO访问密度,即每GB的存储的IO访问次数,会更为直观。那看看目前常用的几种存储介质:


SATA:希捷2TB/7200转/SATA(ST32000644NS)
SAS:希捷300GB/15000转/SAS(ST3300657SS)
SSD :Intel 160GB X25-M G2 34nm
DRAM:三星8GB DDR3 1333 REG ECC
(中关村在线报价,人民币美元汇率:6.3157,2012/4/16)
  根据业务IO访问密度,选择合适的存储介质,就是根据存储介质的IO访问密度特性与价格来选择性价比最高的存储介质,即找到每种存储介质之间IO访问密度的临界点。
  临界点G(X,Y).IO per sec per GB = X.IO per sec per GB * Y.price per GB / X. price per GB,X与Y分别表示对比的两种存储介质,且Y.IO per sec per GB 大于 X.IO per sec per GB。根据上面的公式,可以得到表格如下:


  怎么理解上面的公式呢?举计算SATA与SAS之间的临界点为例,G(SATA,SAS).IO per sec per GB = SATA.IO per sec per GB* SAS.price per GB/SATA.price per GB = 1/20 * 0.71/0.23 = 0.15 per sec per GB。假设现在有1GB的数据,访问密度是X,X小于2/3,那么使用SAS介质则需要0.71$,如果选择SATA介质,则需要X/(1/20) * 0.23 $。当X为0.15时,选择SATA与SAS的成本是一样的,当大于0.15时,则使用SATA的成本相对于SAS则高;否则则低。SAS比SSD,SSD比DRAM也是类似。
  实际上对于一款存储介质而言,IO访问特性与单位每GB的成本是决定了其存在与生命力的关键因素。通常来讲,其IO访问特性一般来讲不会有革命性的变化,而单位每GB的成本却是可以控制的,所以厂商总是会围绕容量来不断的深入优化。
六、开放的挑战
  10年底开始,随着开放的加剧,越来越多的第三方选择社交平台开发应用。这些外部条件的变化对技术平台的而言,也带来了新挑战:除需要为用户提供更强的海量服务外,同时还需要提供开放的软件基础架构来帮助第三方开发海量服务。现有已成熟的NoSQL的架构能否被外部第三方接受,其关键的一点是接口的友好性和兼容性。采用的标准化的接口,会大大降低外部开发者的使用门槛。因此,在11年推出了CMEM 的NoSQL云存储服务,开发者可直接使用memcached接口,并即将支持redis接口。同时也提供了SQL云存储服务,开发者可用MYSQL客户端直接访问。后续推出CFS文件系统云存储服务,开发者可使用posix接口访问到TFS。


  回顾TFS、TDB、TMEM、TSSD、CMEM、CDB、CFS等一系列存储系统过去近6个年头的演进发展。有两点经验可供分享:
  1、 建议NoSQL开发者尽量选择构建PAAS服务。一方面对业务开发者而言,不需关心日常运维,使用更为方便,易于接受;另一方面更容易形成用户需求提出、实现与发布的闭环,从而方便小步快跑,快速迭代出完善的服务。
  2、 建议中小业务开发者尽量使用云服务。通常一个NoSQL服务所面临的挑战有两个方面:一方面是大家所直观感受的产品本身;另一方面是服务背后的运营体系。类似与铁路系统、消防系统,用户所直观感受到的火车、铁路,消防栓、消防车只是整个服务其中一个部分,是冰山海平面之上的部分;用户所感受不到的铁路规划、调度系统、消防规划、消防演练,报警系统等后台运营体系通常是冰山海平面以下的部分,往往需要有大量的人力和财力投入,可能是中小公司难以投入的。而在没有稳固的后台运营体系支撑下,类似动车事故、火灾等生产系统故障难以避免,并最终为业务带来不可估量的损失。
  从过去几年来看,硬件在变,存储介质的性能与容量在不断提升,并不断会有新存储介质的产生;业务在变,不断有新兴的产品和新的业务体验,并对后台系统提出新的挑战和需求;唯一不变的就是需要拥抱变化,为业务提供更贴切与更优化的存储服务。想了解更多关于腾讯TFS、TDB、TMEM、TSSD、CMEM、CDB、CFS等一系列存储系统过去近6个年头的演进发展,大家可以到腾讯大讲堂网站(djt.qq.com)翻阅架构平台部的分享文章,谢谢。



杨粼波 2014-06-15 11:39 发表评论

相关 [nosql 腾讯 应用] 推荐:

NoSQL 在腾讯应用实践

- - C++博客-牵着老婆满街逛
http://t.qq.com/iwuyue  腾讯大讲堂特约讲师,腾讯T4技术专家. 先后参与腾讯分布式文件系统(TFS),K-V存储,SQL集群,接入网关(TGW)的设计与研发. 见证了腾讯Nosql 从07年诞生,08、09批量应用,10年至今应用于腾讯开放平台让更多的第三方开发者使用;关注于构建具有低成本、高性能、高可用,可扩展,易运营特点的互联网海量后台服务.

MySQL在Web应用领域面临NoSQL的挑战

- - 博客 - 伯乐在线
仅仅几年前,MySQL 还是开源数据库领域公认的王者,但是随着 NoSQL 以 82% 的年复合增长率狂飙,MySQL 在 web 应用市场正面临被 NoSQL 淘汰的危险. 向 NoSQL 的迁移不但成为 IT 业发展趋势的一个注脚,还让人们领略了开源驱动的产业创新正如疾风骤雨般来临. 这一切与 Oracle 对 MySQL 的管理无关,实际上,Oracle 对 MySQL 可谓尽心尽力,投入大量资源改进技术,培养社区.

NoSQL数据库的35个应用场景-转载

- - 人月神话的BLOG
中午原文: http://news.cnblogs.com/n/172096/. 英文原文:35+ Use Cases For Choosing Your Next NoSQL Database,编译:Juliashine.   现在我们站在各个用例的角度上来考虑哪种系统适合于这些用例. 源起:受 Lotus Notes 启发.

如何让NoSQL内存数据库适合企业级应用

- - CSDN博客数据库推荐文章
如何让NoSQL内存数据库适合企业级应用. 作者:chszs,转载需注明. 博客主页: http://blog.csdn.net/chszs. 英文原文: How to Make Your In-memory NoSQL Datastores Enterprise-Ready. 对于每一个关注用户体验的Web应用或移动应用而言,NoSQL内存数据库(例如开源的 Redis和Memcached)正逐步成为事实上的标准.

Oracle MySQL Or NoSQL续

- - Sky.Jian 朝阳的天空
接前面一篇,这里再将之前在“中国系统架构师大会”5周年的时候发布的纪念册“IT架构实录”上的一篇文章发出来,也算是前面博文中PPT的一个文字版解读吧. Oracle,MySQL 还是 NoSQL. 随着阿里系的“去IOE”运动在社区的宣传声越来越大,国内正在掀起一股“去xxx”的技术潮. 不仅仅是互联网企业,包括运营商以及金融机构都已经开始加入到这个潮流之中.

NoSQL开篇——为什么要使用NoSQL

- Foxiang - 博客园新闻频道
  NoSQL在2010年风生水起,大大小小的Web站点在追求高性能高可靠性方面,不由自主都选择了NoSQL技术作为优先考虑的方面. 今年伊始,InfoQ中文站有幸邀请到凤凰网的孙立先生,为大家分享他之于NoSQL方面的经验和体会.   非常荣幸能受邀在InfoQ开辟这样一个关于NoSQL的专栏,InfoQ是我非常尊重的一家技术媒体,同时我也希望借助InfoQ,在国内推动NoSQL的发展,希望跟我一样有兴趣的朋友加入进来.

8种nosql对比

- - 谁主沉浮
虽然SQL数据库是非常有用的工具,但经历了15年的一支独秀之后垄断即将被打破. 这只是时间问题:被迫使用关系数据库,但最终发现不能适应需求的情况不胜枚举. 但是 NoSQL数据库之间的不同,远超过两 SQL数据库之间的差别. 这意味着软件架构师更应该在项目开始时就选择好一个适合的 NoSQL数据库.

腾讯旗下iPhone应用盘点

- JoyLee - 月光博客
  腾讯和苹果是现今IT业界炙手可热的两家公司. 不知不觉中QQ已经改变了我们的生活,而iPhone手机已成为时下年轻人的宠儿. 当腾讯遇到苹果,这二者会碰撞出怎样的火花呢. 笔者把App Store中腾讯的几十个应用中适用于iPhone的应用程序做了一个小的盘点. 相比百度的手机应用来说,腾讯的手机应用数量更多,每个应用更新也很频繁,体验都很不错,希望大家喜欢.

腾讯TDW:大型Hadoop集群应用

- - 服务器运维与网站架构|Linux运维|X研究
PS:TDW是腾讯最大的离线数据处理平台. 本文主要从需求、挑战、方案和未来计划等方面,介绍了TDW在建设单个大规模集群中采取的JobTracker分散化和NameNode高可用两个优化方案. TDW(Tencent distributed Data Warehouse,腾讯分布式数据仓库)基于开源软件Hadoop和Hive进行构建,打破了传统数据仓库不能线性扩展、可控性差的局限,并且根据腾讯数据量大、计算复杂等特定情况进行了大量优化和改造.

HTC携手腾讯推QQ手机:内置腾讯多项服务应用

- fz - GeekPark 捕风捉影
前不久HTC曾为Facebook量身定制一款手机chacha,为了迎合国人的习惯,HTC将这款手机经了改动,并携手腾讯推出了chacha的行货版. chacha的行货版与海外版本的差异在于手机全键盘下方的Facebook专属键改成了我们熟悉的“小企鹅”. 该机采用直板全键盘造型,并配备了一块2.6英寸HVGA分辨率触控屏,运行Android 2.3.3系统与HTC Sense 2.1 Messenger界面,同时搭载主频800MHz处理器,内置512MB RAM内存和512MB ROM容量空间,并提供500万像素摄像头.