非关系型数据库的资料.docx

《非关系型数据库的资料.docx》由会员分享，可在线阅读，更多相关《非关系型数据库的资料.docx（4页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、keven的路一些技术上小的琐碎心得；讨论轻巧灵敏的IT工程管理模式，以适应中国国情；对职业教育产业运作方式 的思索；人力资源管理理念，人才开发，劳动法规；我的小家；路还在连续随着互联网web2.0网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品 的进展特别快速。而传统的关系数据库在应付web2.0网站,特殊是超大规模和高并发的SNS类型的web2.0 纯动态网站已经显得力不从心，暴露了许多难以克服的问题，例如：1、High performance -对数据库高并发读写的需求web2.0网站要依据用户共性化信息来实时生成动态页面和供应动态信息，所以基本上无法使用动态页

2、面静 态化技术，因此数据库并发负载特别高，往往要到达每秒上万次读写恳求。关系数据库应付上万次SQL查 询还牵强顶得住，但是应付上万次SQL写数据恳求，硬盘I0就已经无法承受了。其实对于一般的BBS网 站，往往也存在对高并发写恳求的需求，例如像JavaEye网站的实时统计在线用户状态，纪录热门帖子的 点击次数，投票计数等，因此这是一个相当普遍的需求。2、Huge Storage-对海量数据的高效率存储和访问的需求类似Facebook, twitter, Friendfeed这样的 SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就到达了 2.5亿条用户动态，对于 关系数

3、据库来说，在一张2.5亿条纪录的表里面进行SQL查询，效率是极其低下乃至不行忍受的。再例如 大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。3、High Scalability & High Availability-对数据库的高可扩展性和高可用性的需求在基于web的架构当中，数 据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有方法 像web server和app server那样简洁的通过添加更多的硬件和服务节点来扩展性能和负载力量。对于许多 需要供应24小时不间断服务的网站来说，对数据库系统进行升级和扩展是特别

4、苦痛的事情，往往需要停机 维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库 的许多主要特性却往往无用武之地，例如：1、数据库事务全都性需求许多web实时系统并不要求严格的数据库事务，对读全都性的要求很低，有些 场合对写全都性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。2、数据库的写实时性和读实时性需求对关系数据库来说，插入一条数据之后立即查询，是确定可以读出来 这条数据的，但是对于许多web应用来说，并不要求这么高的实时性，比方说发一条消息之后，过几秒乃

5、 至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。3、对简单的SQL查询，特殊是多表关联查询的需求任何大数据量的web系统，都特别忌讳多个大表的关 联查询，以及简单的数据分析类型的简单SQL报表查询，特殊是SNS类型的网站，从需求以及产品设计 角度，就避开了这种状况的产生。往往更多的只是单表的主键查询，以及单表的简洁条件分页查询，SQL 的功能被极大的弱化了。因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应 运而生，现在这两年，各种各样非关系数据库，特殊是键值数据库(Key-ValueStoreDB)风起云涌，多得让 人眼花缭乱。前不久国外刚

6、刚举办了 NoSQL Conference,各路NoSQL数据库纷纷亮相，加上未亮相但 是名声在外的，起码有超过10个开源的NoSQLDB,例如：Redis, Tokyo Cabinet, Cassandra, Voldemort, MongoDB, Dynomite, HBase, CouchDB, Hypertable, Riak, Tin, Flare, Lightcloud, KiokuDB, Scalaris Kai, ThruDB, 这些NoSQL数据库，有的是用C/C+编写的，有的是用Java编写的，还有的是用Erlang编写的，每个 都有自己的独到之处，看都看不过来了，这些No

7、SQL数据库大致可以分为以下的三类： 一、满意极高读写性能需求的Kye-Value数据库：Redis, Tokyo Cabinet, Flare高性能KeyValue数据库的主要特点就是具有极高的并发读写性能，Redis, Tokyo Cabinet, Flare,这 3个Key-Value DB都是用C编写的，他们的性能都相当精彩，但出了精彩的性能，他们还有自己独特的 功能：1、RedisRedis是一个很新的工程，刚刚发布了 1.0版本。Redis本质上是一个Key-Value类型的内存数 据库，很像memcached,整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据fl

8、ush 到硬盘上进行保存。由于是纯内存操作，Redis的性能特别精彩，每秒可以处理超过10万次读写操作， 是我知道的性能最快的Key-Value DB。Redis的精彩之处不仅仅是性能，Redis最大的魅力是支持保存List链表和Set集合的数据结构，而且还 支持对List进行各种操作，例如从List两端push和pop数据，取List区间，排序等等，对Set支持各种 集合的并集交集操作，此外单个value的最大限制是1GB,不像memcached只能保存1MB的数据，因 此Redis可以用来实现许多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性 能消息队列服务，用

9、他的Set可以做高性能的tag系统等等。此外Redis也可以对存入的Key-Value设置 expire时间，因此也可以被当作一个功能加强版的memcached来用。Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，并且它没有原生 的可扩展机制，不具有scale （可扩展）力量，要依靠客户端来实现分布式读写，因此Redis适合的场景主 要局限在较小数据量的高性能操作和运算上。目前使用Redis的网站有github, Engine Yardo2、Tokyo Cabinet 和 Tokoy TyrantTC和TT的开发者是日本人MikioHirabayashi,主要

10、被用在日本最大的SNS网站mixi.jp上，TC进展的时 间最早，现在已经是一个特别成熟的工程，也是Kye-Value数据库领域最大的热点，现在被广泛的应用在 许多许多网站上。TC是一个高性能的存储引擎，而TT供应了多线程高并发服务器，性能也特别精彩，每 秒可以处理45万次读写操作。TC除了支持Key-Value存储之外，还支持保存Hashtable数据类型，因此很像一个简洁的数据库表，并 且还支持基于column的条件查询，分页查询和排序功能，基本上相当于支持单表的基础查询功能了，所 以可以简洁的替代关系数据库的许多操作，这也是TC受到大家欢迎的主要缘由之一，有一个Ruby的项 目miyaz

11、akiresistance将TT的hashtable的操作封装成和ActiveRecord 一样的操作，用起来特别爽。TC/TT在mixi的实际应用当中，存储了 2000万条以上的数据，同时支撑了上万个并发连接，是一个久经 考验的工程。TC在保证了极高的并发读写性能的同时具有牢靠的数据长久化机制，同时还支持类似关系 数据库表结构的hashtable以及简洁的条件，分页和排序操作，是一个很棒的NoSQL数据库。TC主要的缺点是没有scale的力量，假如单机无法满意要求，只能通过主从复制的方式扩展，此外有人提 到TC的性能会随着数据量的增加而下降，当数据量上亿条以后，性能会有比拟明显的下降。这个是

12、Tim Yang做的一个Memcached, Redis和Tokyo Tyrant的简洁的性能评测，3、FlareTC是日本第一大SNS网站mixi开发的，而Flare是日本其次大SNS网站green.jp开发的，有意思吧。 Flare简洁的说就是给TC添加了 scale功能。他替换掉了 TT局部，自己此外给TC写了网络服务器，Flare 的主要特点就是支持scale力量，他在网络服务端之前添加了一个node server,来管理后端的多个服务器 节点，因此可以动态添加数据库服务节点，删除服务器节点，也支持failover。假如你的使用场景必需要让 TC可以scale,那么可以考虑flare。

13、flare唯一的缺点就是他只支持memcached合同，因此当你使用flare的时候，就不能使用TC的table数 据结构了，只能使用TC的key-value数据结构存储。二、满意海量存储需求和访问的面对文档的数据库：MongoDB, CouchDB面对文档的非关系数据库主要解决的问题不是高性能的并发读写，而是保证海量数据存储的同时，具有良 好的查询性能。MongoDB是用C+开发的，而CouchDB那么是Erlang开发的：1、MongoDBMongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最 丰富，最像关系数据库的。他支持的数据结构特别松散，是类似json的

14、bjson格式，因此可以存储比拟简 单的数据类型。Mongo最大的特点是他支持的查询语言特别强大，其语法有点类似于面对对象的查询语言, 几乎可以实现类似关系数据库单表查询的绝大局部功能，而且还支持对数据建立索引。Mongo主要解决的是海量数据的访问效率问题，依据官方的文档，当数据量到达50GB以上的时候，Mongo 的数据库访问速度是MySQL的10倍以上。Mongo的并发读写效率不是特殊精彩，依据官方供应的性能 测试说明，大约每秒可以处理0.5万一1.5次读写恳求。由于Mong。主要是支持海量数据存储的，所以Mongo还自带了一个精彩的分布式文件系统GridFS,可以 支持海量的数据存储，但

15、我也看到有些评论认为GridFS性能不佳，这一点还是有待亲自做点测试来验证 了。最终由于Mongo可以支持简单的数据结构，而且带有强大的数据查询功能，因此特别受到欢迎，许多工程 都考虑用MongoDB来替代MySQL来实现不是特殊简单的Web应用，比方说why we migrated from MySQL to MongoDB就是一个真实的从MySQL迁移到MongoDB的案例，由于数据量实在太大，所以迁 移到了 Mongo上面，数据查询的速度得到了特别显著的提升。MongoDB 也有一个 ruby 的工程 MongoMapper,是仿照 Merb 的 DataMapper 编写的 Mongo

16、DB 的接口， 使用起来特别简洁，几乎和DataMapper一模一样，功能特别强大易用。2、CouchDBCouchDB现在是一个特别知名气的工程，好像不用多介绍了。但是我去口对CouchDB没有什 么爱好，主要是由于CouchDB仅仅供应了基于HTTP REST的接口，因此CouchDB单纯从并发读写性能 来说，是特别糟糕的，这让我立即抛弃了对CouchDB的爱好。三、满意高可扩展性和可用性的面对分布式计算的数据库：Cassandra, Voldemort面对scale力量的数据库其实主要解决的问题领域和上述两类数据库还不太一样，它首先必需是一个分布 式的数据库系统，由分布在不同节点上面的数

17、据库共同构成一个数据库服务系统，并且依据这种分布式架 构来供应。nline的，具有弹性的可扩展力量，例如可以不停机的添加更多数据节点，删除数据节点等等。 因此像Cassandra经常被看成是一个开源版本的Google BigTable的替代品。Cassandra和Voldemort 都是用Java开发的：Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务， 对Cassandra的一个写操作，会被复制到其他节点上去，对Cassandra的读操作，也会被路由到某个节 点上面去读取。对于一个Cassandra群集来说，扩展性能是比拟简洁的事情，只管在群

18、集里面添加节点就 可以了。我看到有文章说Facebook的Cassandra群集有超过100台服务器构成的数据库群集。Cassandra也支持比拟丰富的数据结构和功能强大的查询语言，和MongoDB比拟类似，查询功能比 MongoDB稍弱一些,twitter的平台架构部门领导Evan Weaver写了一篇文章介绍Cassandra： cassandra/, 有特别具体的介绍。Cassandra以单个节点来衡量，其节点的并发读写性能不是特殊好，有文章说评测下来Cassandra每秒大 约不到1万次读写恳求，我也看到一些对这个问题进行质疑的评论，但是评价Cassandra单个节点的性能 是没有意义

19、的，真实的分布式数据库访问系统必定是n多个节点构成的系统，其并发性能取决于整个系统 的节点数量，路由效率，而不仅仅是单节点的并发负载力量。2、VoldemortVoldemort是个和Cassandra类似的面对解决scale问题的分布式数据库系统，Cassandra 来自于Facebook这个SNS网站，而Voldemort那么来自于Linkedin这个SNS网站。说起来SNS网站为 我们贡献了 n 多的 NoSQL 数据库，例如 Cassandar, Voldemort, Tokyo Cabinet, Flare 等等。Voldemort 的资料不是许多，因此我没有特殊认真去钻研，Vold

20、emort官方给出Voldemort的并发读写性能也很不错， 每秒超过了 15万次读写。从Facebook开发Cassandra, Linkedin开发Voldemort,我们也可以大致看出国外大型SNS网站对于分 布式数据库，特殊是对数据库的scale力量方面的需求是多么殷切。前面提到，web应用的架构当中，web 层和app层相对来说都很简洁横向扩展，唯有数据库是单点的，极难scale,现在Facebook和Unkedin 在非关系型数据库的分布式方面探究了一条很好的方向，这也是为什么现在Cassandra这么热门的主要缘 由。引文来源常见非关系型数据库(NoSQL)推举介绍(Redis,Tokyo Cabinet, Cassandra, Voldemort, MongoDB, Dyromite, HBase, CouchDB, Hypertable, Riak, Tin, Flare, Lightcloud, KiokuDB, Scalaris, Kai, ThruDB ) - keven 的路