九爷带你了解 带你了解 Nosql Redis ttserver Flare memcache比较

  • 时间:
  • 浏览:1
  • 来源:万人牛牛APP下载_万人牛牛官方

         TC的主要缺点是在数据量达到上亿级别以后 ,并发写数据性能会大幅度下降,NoSQL: If Only It Was That  Easy提到,大伙发现在TC上端插入1.6亿条2-20KB数据的以后 ,写入性能以后 开始了急剧下降。看来是当数据量上亿条的以后 ,TC性能以后 开始了大幅度下降, 从TC作者好多好多 人提供的mixi数据来看,共要上千万条数据量的以后 还这么遇到这么明显的写入性能瓶颈。

         Cassandra项目是Facebook在60 8年开源出来的,以后 Facebook好多好多 人使用Cassandra的另外有有有一个 不开源的分支,而开源出来 的Cassandra主要被Amazon的Dynamite团队来维护,倘若Cassandra被认为是Dynamite2.0版本。目前除了 Facebook之外,twitter和digg.com也有使用Cassandra。

         Cassandra的主要特点要是它也有有有有一个 数据库,要是由一堆数据库节点同时构成的有有有一个 分布式网络服务,对Cassandra的有有有一个 写操作,会被qq克隆好友 到 好多好多 节点上去,对Cassandra的读操作,也会被路由到某个节点上端去读取。对于有有有一个 Cassandra群集来说,扩展性能是比较简单的事情,只管在 群集上端去掉 节点就还可不还可以了。我都看有文章说Facebook的Cassandra群集有超过60 台服务器构成的数据库群集。

         最后导致 分析着Mongo还可不还可以支持复杂的数据形态学 ,倘若所含强大的数据查询功能,倘若非常受到欢迎,好多好多 项目都考虑用MongoDB来替代MySQL来实现也有 有点硬复杂的Web应用,比方说why we migrated from MySQL to MongoDB要是有有有一个 真实的从MySQL迁移到MongoDB的案例,导致 分析着数据量我我觉得太多再 ,好多好多 迁移到了Mongo上端,数据查询的速率单位单位得到了非常显著 的提升。

2、CouchDB

         对关系数据库来说,插入四根数据以后 立刻查询,是肯定还可不还可以读出来这条数据的,倘若对于好多好多 web应用来说,并未必求这么高的实时性,比方说发四根消息以后 ,过几秒乃至十几秒以后 ,我的订阅者才都看这条动态是全部还可不还可以接受的。

         在基于web的架构当中,数据库是最难进行横向扩展的,当有有有一个 应用系统的用户量和访问量与日俱增的以后 ,你的数据库却这么辦法 像web  server和app  server那样简单的通过去掉 更多的硬件和服务节点来扩展性能和负载能力。对于好多好多 时要提供24小时不间断服务的网站来说,对数据库系统进行升级和扩展 是非常痛苦的事情,往往时要停机维护和数据迁移,为哪些数据库只有通过不断的去掉 服务器节点来实现扩展呢?

         MongoDB是有有有一个 介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最富于,最像关系数据库的。他支持的数据形态学 非常松散,是相似 json的bjson格式,倘若还可不还可以存储复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大,其语法有点硬相似于面向对象的查询语言,几乎还可不还可以实现相似关系数据库单表查询的绝大累积功能,倘若还支持对数据建立索引。

         Redis是有有有一个 很新的项目,以后 发布了1.0版本。Redis本质上是有有有一个 Key-Value类型的内存数据库,很像memcached,整个数据库好多好多 加载在内存当中进行操作,定期通过异步操作把数据库数据flush到硬盘上进行保存。导致 分析着是纯内存操作,Redis的性能非常出色,每秒还可不还可以处里超过5万次读写操作,是我知道的性能最快的Key-Value DB。

Redis,Tokyo Cabinet,Cassandra,Voldemort,MongoDB,Dynomite,HBase,CouchDB,Hypertable, Riak,Tin, Flare, Lightcloud, KiokuDB,Scalaris, Kai, ThruDB,  ......

1、Redis

         Redis的出色之处不仅仅是性能,Redis最大的魅力是支持保存List链表和Set集合的数据形态学 ,倘若还支持对List进行各种操作,相似从 List两端push和pop数据,取List区间,排序等等,对Set支持各种集合的并集交集操作,此外单个value的最大限制是1GB,不像 memcached只有保存1MB的数据,倘若Redis还可不还可以用来实现好多好多 有用的功能,比方说用他的List来做FIFO双向链表,实现有有有一个 轻量级的高性 能消息队列服务,用他的Set还可不还可以做高性能的tag系统等等。另外Redis也还可不还可以对存入的Key-Value设置expire时间,倘若也还可不还可以被当作有有有一个 功能加强版的memcached来用。

         Redis的主要缺点是数据库容量受到物理内存的限制,只有用作海量数据的高性能读写,倘若它这么原生的可扩展机制,不具有scale(可扩展)能力,要依赖客户端来实现分布式读写,倘若Redis适合的场景主要局限在较小数据量的高性能操作和运算上。目前使用Redis的网站有github,Engine Yard。

         导致 分析着Mongo主要是支持海量数据存储的,好多好多 Mongo还自带了有有有一个 出色的分布式文件系统GridFS,还可不还可以支持海量的数据存储,但我也都看好多好多 评论认为GridFS性能不佳,好多好多 点还是有待亲自做点测试来验证了。

         flare唯一的缺点要是他只支持memcached协议,倘若当你使用flare的以后 ,就只有使用TC的table数据形态学 了,只有使用TC的key-value数据形态学 存储。

哪些NoSQL数据库,也有用C/C++编写的,也有用Java编写的,还也有用Erlang编写的,每个也有好多好多 人的独到之处,看都看不过来了,我也只有从中选则好多好多 比较有特色,看起来更有前景的产品学习和了解一下。哪些NoSQL数据库大致还可不还可以分为以下的三类:

2、Huge Storage - 对海量数据的高速率单位单位存储和访问的需求

         web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息,好多好多 基本上无法使用动态页面静态化技术,倘若数据库并发负载非常高,往往要达到 每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住,倘若应付上万次SQL写数据请求,硬盘IO就导致 分析着无法承受了。我我觉得对于普通的BBS网 站,往往也趋于稳定对高并发写请求的需求,相似像JavaEye网站的实时统计在线用户情况,记录热门帖子的点击次数,投票计数等,倘若这是有有有一个 相当普遍的需求。

         如今,NoSQL数据库是个令人很兴奋的领域,无缘无故不断有新的技术新的产品无缘无故老出来,改变大伙导致 分析着形成的固有的技术观念,我好多好多 人(robbin)稍微了解了好多好多 ,就感觉好多好多 人深深的沉迷进去了,还可不还可以说NoSQL数据库领域也是博大精深的,我也只有浅尝辄止,希望吸引对好多好多 领域有经验的大伙来讨论和交流。

         TC/TT在mixi的实际应用当中,存储了60 0万条以上的数据,同时支撑了上万个并发连接,是有有有一个 久经考验的项目。TC在保证了极高的并发读写性能 的同时,具有可靠的数据持久化机制,同时还支持相似关系数据库表形态学 的hashtable以及简单的条件,分页和排序操作,是有有有一个 很棒的NoSQL数据 库。

         Cassandra也支持比较富于的数据形态学 和功能强大的查询语言,和MongoDB比较相似,查询功能比MongoDB稍弱好多好多 ,twitter的平台架构部门领导Evan Weaver写了一篇文章介绍Cassandra:http://blog.evanweaver.com/artic ... ing-with-cassandra/,有非常全部的介绍。

3、对复杂的SQL查询,有点硬是多表关联查询的需求

         MongoDB也有有有有一个 ruby的项目MongoMapper,是模仿Merb的DataMapper编写的MongoDB的接口,使用起来非常简单,几乎和DataMapper一模一样,功能非常强大易用。

2、Voldemort

三、满足高可扩展性和可用性的面向分布式计算的数据库:Cassandra,Voldemort

         Mongo主要处里的是海量数据的访问速率单位单位大大问题,根据官方的文档,当数据量达到60 GB以上的以后 ,Mongo的数据库访问速率单位单位是MySQL的10倍以 上。Mongo的并发读写速率单位单位也有有点硬出色,根据官方提供的性能测试表明,共要每秒还可不还可以处里0.5万-1.5次读写请求。对于Mongo的并发读写性能, 我也打算有空的以后 好好测试一下。

         高性能Key-Value数据库的主要特点要是具有极高的并发读写性能,Redis,Tokyo Cabinet, Flare,这六个Key-Value DB也有用C编写的,大伙的性能都相当出色,但出了出色的性能,大伙还有好多好多 人独特的功能:

         倘若,关系数据库在哪些太多再 的应用场景下显得不这么共要了,为了处里相似大大问题的非关系数据库应运而生,现在这两年,各种各样非关系数据库,有点硬是键值 数据库(Key-Value Store DB)风起云涌,多得让人眼花缭乱。前不久国外以后 举办了NoSQL  Conference,各路NoSQL数据库纷纷亮相,去掉 未亮相倘若名声在外的,起码有超过10个开源的NoSQLDB,相似:

2、Tokyo Cabinet和Tokoy Tyrant

二、满足海量存储需求和访问的面向文档的数据库:MongoDB,CouchDB

         TC除了支持Key-Value存储之外,还支持保存Hashtable数据类型,倘若很像有有有一个 简单的数据库表,倘若还支持基于column的条件查询, 分页查询和排序功能,基本上共要支持单表的基础查询功能了,好多好多 还可不还可以简单的替代关系数据库的好多好多 操作,这也是TC受到大伙欢迎的主要导致 分析之一,有有有有一个 Ruby的项目miyazakiresistance将TT的hashtable的操作封装成和ActiveRecord一样的操作,用起来非常爽。

         在上端提到的“三高”需求身旁,关系数据库遇到了难以克服的障碍,而对于web2.0网站来说,关系数据库的好多好多 主要形态学 却往往无用武之地,相似:

2、数据库的写实时性和读实时性需求

         Cassandra以单个节点来衡量,其节点的并发读写性能也有有点硬好,有文章说评测下来Cassandra每秒共要只有1万次读写请求,我也都看好多好多 对 好多好多 大大问题进行质疑的评论,倘若评价Cassandra单个节点的性能是这么意义的,真实的分布式数据库访问系统必然是n多个节点构成的系统,其并发性能取 决于整个系统的节点数量,路由速率单位单位,而不仅仅是单节点的并发负载能力。

1、Cassandra

随着互联网web2.0网站的兴起,非关系型的数据库现在成了有有有一个 极其热门的新领域,非关系数据库产品的发展非常太快了 。而传统的关系数据库在应付 web2.0网站,有点硬是超大规模和高并发的SNS类型的web2.0纯动态网站导致 分析着显得力不从心,暴露了好多好多 难以克服的大大问题,相似:

         相似Facebook,twitter,Friendfeed 要是 的SNS网站,每天用户产生海量的用户动态,以Friendfeed为例,有有有一个 月就达到了2.5亿条用户动态,对于关系数据库来说,在一张2.5亿条 记录的表上端进行SQL查询,速率单位单位是极其低下乃至不可忍受的。再相似大型web网站的用户登录系统,相似腾讯,盛大,动辄数以亿计的帐号,关系数据库也很 难应付。

         Voldemort是个和Cassandra相似的面向处里scale大大问题的分布式数据库系统,Cassandra来自于Facebook好多好多 SNS网 站,而Voldemort则来自于Linkedin好多好多 SNS网站。说起来SNS网站为大伙贡献了n多的NoSQL数据库,相似 Cassandar,Voldemort,Tokyo  Cabinet,Flare等等。Voldemort的资料也有好多好多 ,倘若我这么有点硬仔细去钻研,Voldemort官方给出Voldemort的并发读 写性能也很不错,每秒超过了1.5万次读写。

1、数据库事务一致性需求

         CouchDB现在是有有有一个 非常有名气的项目,似乎太多再多介绍了。倘若我却对CouchDB没哪些兴趣,主要是导致 分析着CouchDB仅仅提供了基于HTTP  REST的接口,倘若CouchDB单纯从并发读写性能来说,是非常糟糕的,这我要 立刻背叛了对CouchDB的兴趣。

3、Flare

1、MongoDB

         从Facebook开发Cassandra,Linkedin开发Voldemort,大伙也还可不还可以大致看出国外大型SNS网站对于分布式数据库,有点硬是对数据库的scale能力方面的需求是多么殷切。前面我提到,web应用的架构当中,web层和app层相对来说都很容易横向扩展,唯有数据库是单点的,极难scale,现在Facebook和Linkedin在非关系型数据库的分布式方面探索了四根很好的方向,这也是为哪些现在Cassandra这么热门的主要导致 分析。

一、满足极高读写性能需求的Kye-Value数据库:Redis,Tokyo Cabinet, Flare

3、High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求

         面向scale能力的数据库我我觉得主要处里的大大问题领域和上述两类数据库还不太一样,它首先时要是有有有一个 分布式的数据库系统,由分布在不同节点上端的数据库同时 构成有有有一个 数据库服务系统,倘若根据好多好多 分布式架构来提供online的,具有弹性的可扩展能力,相似还可不还可以不停机的去掉 更多数据节点,删除数据节点等等。倘若像Cassandra常常被看成是有有有一个 开源版本的Google BigTable的替代品。Cassandra和Voldemort也有用Java开发的:

         好多好多 web实时系统并未必求严格的数据库事务,对读一致性的要求很低,好多好多 场合对写一致性要求要是高。倘若数据库事务管理成了数据库高负载下有有有一个 沉重的负担。

         任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的复杂SQL报表查询,有点硬是SNS类型的网站,从需求以及产品设计淬硬层 ,就处里了好多好多 情况的产生。往往更多的要是单表的主键查询,以及单表的简单条件分页查询,SQL的功能被极大的弱化了。

         面向文档的非关系数据库主要处里的大大问题也有高性能的并发读写,要是保证海量数据存储的同时,具有良好的查询性能。MongoDB是用C++开发的,而CouchDB则是Erlang开发的:

         TC和TT的开发者是日好多好多 人Mikio  Hirabayashi,主要被用在日本最大的SNS网站mixi.jp上,TC发展的时间最早,现在导致 分析着是有有有一个 非常性性性心智心智成熟 图片 的句子的句子 期的项目,也是Kye-Value 数据库领域最大的热点,现在被广泛的应用在好多好多 好多好多 网站上。TC是有有有一个 高性能的存储引擎,而TT提供了多线程 高并发服务器,性能也非常出色,每秒还可不还可以处里 4-5万次读写操作。

         TC是日本第一大SNS网站mixi开发的,而Flare是日本第二大SNS网站green.jp开发的,有意思吧。Flare简单的说要是给TC去掉 了 scale功能。他替换掉了TT累积,好多好多 人另外给TC写了网络服务器,Flare的主要特点要是支持scale能力,他在网络服务端以后 去掉 了有有有一个 node  server,来管理后端的多个服务器节点,倘若还可不还可以动态去掉 数据库服务节点,删除服务器节点,也支持failover。导致 分析着你的使用场景时要要让TC还可不还可以scale,这么还可不还可以考虑flare。

1、High performance - 对数据库高并发读写的需求