NoSql的选择比较(redis).ppt

上传人:laozhun 文档编号:2967498 上传时间:2023-03-06 格式:PPT 页数:42 大小:1.28MB
返回 下载 相关 举报
NoSql的选择比较(redis).ppt_第1页
第1页 / 共42页
NoSql的选择比较(redis).ppt_第2页
第2页 / 共42页
NoSql的选择比较(redis).ppt_第3页
第3页 / 共42页
NoSql的选择比较(redis).ppt_第4页
第4页 / 共42页
NoSql的选择比较(redis).ppt_第5页
第5页 / 共42页
点击查看更多>>
资源描述

《NoSql的选择比较(redis).ppt》由会员分享,可在线阅读,更多相关《NoSql的选择比较(redis).ppt(42页珍藏版)》请在三一办公上搜索。

1、NoSql数据库的选择比较徐高省2012年3月19日,NoSql数据库的选择比较,现实应用中遇到的问题:,随着新华网的一些应用对web2.0技术运用越来越多,传统的关系数据库在应付 这些应用,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多如下难以克服的问题。,NoSql数据库的选择比较,1、对数据库高并发读写的需求web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息,所以基本上无法使用动态页面静态化技术,因此数据库并发负载非常高,往往要达到 每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住,但是应付上万次SQL写数据请求,硬

2、盘IO就已经无法承受了。像网站的实时统计在线用户状态,记录热门帖子的点击次数,投票计数,积分等,因此这是一个相当普遍的需求。,现实应用中遇到的问题:,NoSql数据库的选择比较,2、对海量数据的高效率存储和访问的需求类似新华网的一些应用,每天用户产生海量的用户动态,以总理访谈用新华微博为例,一个月可能达到了亿条用户信息,对于关系数据库来说,在一张亿条 记录的表里面进行SQL查询,效率是极其低下乃至不可忍受的。再例如新华网的用户登录系统,所有的应用都是同一的登录系统,当用户账户达到一定程度。关系数据库也很难应付。,现实应用中遇到的问题:,NoSql数据库的选择比较,3、对数据库的高可扩展性和高可

3、用性的需求在基于web的架构当中,数据库是最难进行横向扩展的,当一个应用系统的用户量和访问量与日俱增的时候,你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说,对数据库系统进行升级和扩展 是非常痛苦的事情,往往需要停机维护和数据迁移,为什么数据库不能通过不断的添加服务器节点来实现扩展呢?,现实应用中遇到的问题:,NoSql数据库的选择比较,在上面提到的“三高”需求面前,关系数据库遇到了难以克服的障碍,而对于web2.0应用来说,关系数据库的很多主要特性却往往无用武之地,Web2

4、.0应用的现状:,NoSql数据库的选择比较,1、数据库事务一致性需求 很多web实时系统并不要求严格的数据库事务,对读一致性的要求很低,有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。,Web2.0应用的现状:,NoSql数据库的选择比较,2、数据库的写实时性和读实时性需求对关系数据库来说,插入一条数据之后立刻查询,是肯定可以读出来这条数据的,但是对于很多web应用来说,并不要求这么高的实时性,比方说新华微博发一条消息之后,要经过审核,审核通过后才能上线。当用户看到这个消息时,已经是几十秒之后了。,Web2.0应用的现状:,NoSql数据库的选择比较,3、对

5、复杂的SQL查询,特别是多表关联查询的需求任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的复杂SQL报表查询,特别是SNS类型的网站,从需求以及产品设计角度,就避免了这种情况的产生。往往更多的只是单表的主键查询,以及单表的简单条件分页查询,SQL的功能被极大的弱化了。,Web2.0应用的现状:,NoSql数据库的选择比较,因此,关系数据库在这些越来越多的应用场景下显得不那么合适了,为了解决这类问题的非关系数据库应运而生,现在这两年,各种各样非关系数据库,特别是键值 数据库(Key-Value Store DB)风起云涌,多得让人眼花缭乱。大约有10多个开源的No

6、SQLDB,例如:Redis,Tokyo Cabinet,Cassandra,Voldemort,MongoDB,HBase,CouchDB,Flare,memcachdb,NoSQLDB:,NoSql数据库的选择比较,1、Redis Redis是一个很新的项目,刚刚发布了2.4.8版本。Redis本质上是一个Key-Value类型的内存数据库,很像memcached,整个数据库统统加载在内存当中进行操作,定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作,Redis的性能非常出色,每秒可以处理超过10万次读写操作,是我知道的性能最快的Key-Value DB。,主要的N

7、oSql简介-redis:,NoSql数据库的选择比较,Redis的出色之处不仅仅是性能,Redis最大的魅力是支持保存List链表和Set集合的数据结构,而且还支持对List进行各种操作,例如从 List两端push和pop数据,取List区间,排序等等,对Set支持各种集合的并集交集操作,此外单个value的最大限制是1GB。Redis可以用来实现很多有用的功能,比方说用他的List来做FIFO双向链表,实现一个轻量级的高性 能消息队列服务,用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间,因此也可以被当作一个功能加强版的memc

8、ached来用。,主要的NoSql简介-redis:,NoSql数据库的选择比较,主要的NoSql简介-MemCached:,2、MemCached Memcached是(运营LiveJournal的技术团队)开发的一套分布式内存对象缓存系统,用于在动态系统中减少数据库负载,提升性能。特点 协议简单 基于libevent的事件处理 内置内存存储方式 memcached不互相通信的分布式,NoSql数据库的选择比较,主要的NoSql 简介-MemCached:,特点:协议简单 基于libevent的事件处理 内置内存存储方式 memcached不互相通信的分布式,NoSql数据库的选择比较,主要

9、的NoSql简介-MemCacheDB:,3、MemCacheDB 它是新浪互动社区事业部为在Memcached基础上,增加Berkeley DB存储层而开发一款支持高并发的分布式持久存储系统,对任何原有Memcached客户端来讲,它仍旧是个Memcached,但是,它的数据是可以持久存储的。,NoSql数据库的选择比较,主要的NoSql简介-TC/TT:,4、Tokyo Cabinet和Tokoy Tyrant TC和TT的开发者是日本人Mikio Hirabayashi,主要被用在日本最大的SNS网站mixi.jp上,TC发展的时间最早,现在已经是一个非常成熟的项目,也是Kye-Valu

10、e 数据库领域最大的热点,现在被广泛的应用在很多很多网站上。TC是一个高性能的存储引擎,而TT提供了多线程高并发服务器,性能也非常出色,每秒可以处理 4-5万次读写操作。,NoSql数据库的选择比较,主要的NoSql简介-TC/TT:,TC除了支持Key-Value存储之外,还支持保存Hashtable数据类型,因此很像一个简单的数据库表,并且还支持基于column的条件查询,分页查询和排序功能,基本上相当于支持单表的基础查询功能了,所以可以简单的替代关系数据库的很多操作,这也是TC受到大家欢迎的主要原因之一,有一个 Ruby的项目miyazakiresistance将TT的hashtable

11、的操作封装成和ActiveRecord一样的操作,用起来非常爽。,NoSql数据库的选择比较,主要的NoSql简介-TC/TT:,TC/TT在mixi的实际应用当中,存储了2000万条以上的数据,同时支撑了上万个并发连接,是一个久经考验的项目。TC在保证了极高的并发读写性能 的同时,具有可靠的数据持久化机制,同时还支持类似关系数据库表结构的hashtable以及简单的条件,分页和排序操作,是一个很棒的NoSQL数据 库。,NoSql数据库的选择比较,主要的NoSql简介-Cassandra:,5、Cassandra Cassandra项目是Facebook在2008年开源出来的,随后Faceb

12、ook自己使用Cassandra的另外一个不开源的分支。目前除了 Facebook之外,twitter和都在使用Cassandra。Cassandra的主要特点就是它不是一个数据库,而是由一堆数据库节点共同构成的一个分布式网络服务,对Cassandra的一个写操作,会被复制到 其他节点上去,对Cassandra的读操作,也会被路由到某个节点上面去读取。对于一个Cassandra群集来说,扩展性能是比较简单的事情,只管在 群集里面添加节点就可以了.,NoSql数据库的选择比较,主要的NoSql简介-Cassandra:,Cassandra也支持比较丰富的数据结构和功能强大的查询语言,和Mongo

13、DB比较类似,查询功能比MongoDB稍弱一些。Cassandra以单个节点来衡量,其节点的并发读写性能不是特别好,Cassandra每秒大约不到1万次读写请求。,NoSql数据库的选择比较,主要的NoSql简介-Voldemort:,6、Voldemort Voldemort是个和Cassandra类似的面向解决scale问题的分布式数据库系统,Voldemort来自于Linkedin这个SNS网站。Voldemort的资料不是很多,研究学习不是太方便。Voldemort官方给出Voldemort的并发读写性能也很不错,每秒超过了1.5万次读写。,NoSql数据库的选择比较,主要的NoSql

14、简介-MongoDB:,7、MongoDB MongoDB是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的。他支持的数据结构非常松散,是类似 json的bson格式,因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几 乎可以实现类似关系数据库单表查询的绝大部分功能,而且还支持对数据建立索引。,NoSql数据库的选择比较,主要的NoSql简介-MongoDB:,Mongo主要解决的是海量数据的访问效率问题,根据官方的文档,当数据量达到50GB以上的时候,Mongo的数据库访问速度是My

15、SQL的10倍以 上。Mongo的并发读写效率不是特别出色,根据官方提供的性能测试表明,大约每秒可以处理0.5万1.5次读写请求。由于Mongo可以支持复杂的数据结构,而且带有强大的数据查询功能,因此非常受到欢迎,很多项目都考虑用MongoDB来替代MySQL来实现不是 特别复杂的Web应用。,NoSql数据库的选择比较,MongoDB vs Cassandra简单比较:,1.数据结构 MongoDB使用文档型存储,其数据结构为与JSON类似的BSON结构,而Cassandra支持的是keyvalue式存储,而每个keyvalue还会保存一个时间戳,这个时间戳实际上起到了版本控制的作用。2.索

16、引结构MongoDB的索引几乎与关系型数据库完全一样,其普通索引、联合索引、唯一索引的意义和实现上都可以参考对MySQL索引的理解。而 Cassandra由于其是一个keyvalue结构的存储,如果你要对value进行条件查找,那么就必须建立反向索引,重新建立一个 valuekey的键值对。,NoSql数据库的选择比较,MongoDB vs Cassandra简单比较:,3.部署 MongoDB提供了Replica Sets的高可用部署方式,配置好RS的节点后,整个集群会自动选举出Primary机器供写入操作,并自动复制数据到其它节点。它还具有故障后自动选举新的主机的机制。而Cassandra

17、提供的策略更为灵活,它通过一种对网络结构可感知的机制,它让你可以配置数据是备份在本地网络中的其它节点还是备份到远端的数据中心。,NoSql数据库的选择比较,新华网目前用于满足海量存储需求和访问的NoSql数据库是mongoDB。由于现在新华网的应用很多是为了满足高并发的需求,满足极高读写性能需求。满足这样需求的产品必须具有分布式缓存的功能。因而根据需求选择了的Key-Value数据库:Redis,Tokyo Cabinet,memcached,memcachdb进行比较。,适合新华网应用的NoSql产品:,NoSql数据库的选择比较,产品的性能测试:,以下是新浪做的一个Memcached,Re

18、dis和Tokyo Tyrant的简单的性能评测。1.1硬件环境和操作系统 2 Linux boxes in a LAN,1 server and 1 test clientLinux Centos 5.2 64bitIntel(R)Xeon(R)CPU E5410 2.33GHz(L2 cache:6M),Quad-Core*28G memorySCSI disk(standalone disk,no other access),NoSql数据库的选择比较,产品的性能测试:,小的value值测试,1-5,000,000 as key,100 bytes string value,读写/s。测

19、试结果如下:,NoSql数据库的选择比较,产品的性能测试:,大的value值测试,1-5,000,000 as key,20k string value,读写/s。测试结果如下:,NoSql数据库的选择比较,产品功能比较:,NoSql数据库的选择比较,通过上面的比较,redis是个新出现的产品,也表现出明显的优越性。在主从模式,多数据结构,单个value大小,排序等方面都明显的优于memcachedb/memcached,在性能测试方面,在小的value值时,表现出较高的读写性能。在大的value时,也表现出比tc/tt更优越的稳定性。同时,公司的应用需要多种数据结构,公司员工对redis的熟

20、悉多于tc/tt。因而选择redis.,总结:,Redis介绍,Redis功能简介:,1、Redis的Sharding:目前,redis server没有提供类似mongodb那样的shard功能,只能在client端,通过一致性hash算法实现,当前Redis不支持故障冗余,在集群中不能在线增加或删除Redis 2、Redis的master/slave复制:1.一个master支持多个slave 2.Slave可以接受其他slave的连接来替代他连接master 3.复制在master、在slave都是非阻塞的。4.复制被利用来提供可扩展性,在slave端只提供查询功能及数据的冗余,Redi

21、s介绍,3、Redis的附加档案(AOF)功能:Redis通过配置的策略将数据集保存到aof中,当Redis挂掉后能够通过aof恢复到挂掉前的状态 4、提供批量写入功能 5、事务:允许让一组命令进入队列一次性执行,在执行的过程中不穿插其它命令(Redis的单线程保证)。6、管道:一次性提交多个命令(如果只是进行一些设置,命令之间不需要依赖前置命令结果的话,可以提高不少效率)。,Redis功能简介:,Redis介绍,Redis架构示意图:,Redis介绍,Redis架构示意图,Redis介绍,Redis架构示意图,Redis介绍,Redis架构示意图,Redis介绍,Redis架构示意图,Red

22、is介绍,Redis的缺点:,1、数据库容量受到物理内存的限制,不能用作海量数据的高性能读写。2、它没有原生的可扩展机制,不具有自身可扩展能力,要依赖客户端来实现分布式读写。3、Redis使用最佳方式是全部数据in-memory。虽然Redis也提供持久化功能,但实际更多的是一个disk-backed功能,跟传统意义上的持久化有比较大的差别。4、现在的Redis只适合的场景主要局限在较小数据量的高性能操作和运算上。,Redis介绍,Redis前景展望:,对于Redis 3.0,据说会支持Redis集群:1)节点之间可以互相通讯,和服务端口不同的端口通讯。2)所有数据的key被分成几千份(哈希槽),分布在现有的节点中。3)在增加了一个节点后,会把相应的数据转移过去。4)新的key的操作会转移到新节点,老的key的操作每一次都会询问老节点是否已转移。5)转移完成之后所有之后的请求会直接请求新的节点。,Redis介绍,Redis相关网站:,Redis资料汇总专题:http:/Redis google code:http:/,Q&A,谢谢大家!,

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 建筑/施工/环境 > 项目建议


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号