NoSql的选择比较(redis).ppt
《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
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- NoSql 选择 比较 redis
链接地址:https://www.31ppt.com/p-2967498.html