《2022年非关系型数据库 .pdf》由会员分享，可在线阅读，更多相关《2022年非关系型数据库 .pdf（4页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、JavaEye 创始人范凯（网名：robbin ）曾发表一篇博文，指出Web 2.0 网站的兴起对数据库提出了“ 三高 ” 需求，而传统的关系型数据库对此无法满足，于是非关系型数据库便成了众多 Web2.0 开发者追捧的对象，众多非关系数据库产品也应运而生。全文请见下：随着互联网 web2.0 网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0 网站，特别是超大规模和高并发的SNS 类型的 web2.0 纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：1、High performance 对数据库高并发读写
2、的需求Web2.0 网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL 查询还勉强顶得住，但是应付上万次SQL 写数据请求，硬盘IO 就已经无法承受了。其实对于普通的BBS 网站，往往也存在对高并发写请求的需求，例如像JavaEye 网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求。2、Huge Storage 对海量数据的高效率存储和访问的需求类似 Facebook ，twitter ，Friendfeed这样的 SNS 网
3、站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到了2.5 亿条用户动态，对于关系数据库来说，在一张 2.5 亿条记录的表里面进行SQL 查询，效率是极其低下乃至不可忍受的。再例如大型web 网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。3、High Scalability & High Availability 对数据库的高可扩展性和高可用性的需求在基于 web 的架构当中， 数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server 和 app server 那样简单的通过添加更
4、多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24 小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？在上面提到的 “ 三高” 需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0 网站来说，关系数据库的很多主要特性却往往无用武之地，例如：1. 数据库事务一致性需求很多 web 实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。2. 数据库的写实时性和读实时性需求对关系数据库来说，插入一条
5、数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web 应用来说，并不要求这么高的实时性，比方说我（JavaEye 的 robbin ）发一条消息之后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。3、对复杂的SQL 查询，特别是多表关联查询的需求任何大数据量的web 系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL 报表查询，特别是SNS 类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL 的功能被极大的弱化了。因此，关系数据库在这些越来越多的应用场景下显得不那么合适了
6、，为了解决这类问题的非关系数据库应运而生，现在这两年，各种各样非关系数据库，特别是键值数据库(Key-Value Store DB)风起云涌，多得让人眼花缭乱。前不久国外刚刚举办了NoSQL Conference，各路 NoSQL 数据库纷纷亮相，加上未亮相但是名声在外的，起码有超过10 个开源的 NoSQLDB ，例如：Redis ，Tokyo Cabinet ，Cassandra ，Voldemort ，MongoDB ，Dynomite ，HBase ，CouchDB ，Hypertable ， Riak，Tin ， Flare ， Lightcloud ， KiokuDB ，Scala
7、ris ， Kai，ThruDB ， . 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 4 页 - - - - - - - - - 这些 NoSQL 数据库，有的是用C/C+ 编写的，有的是用Java 编写的，还有的是用Erlang 编写的，每个都有自己的独到之处，看都看不过来了，我(robbin) 也只能从中挑选一些比较有特色，看起来更有前景的产品学习和了解一下。这些NoSQL 数据库大致可以分为以下的三类：一、满足极高读写性能需求的Kye-Value数据库： Red
8、is ，Tokyo Cabinet， Flare 高性能 Key-Value数据库的主要特点就是具有极高的并发读写性能，Redis ，Tokyo Cabinet ， Flare ，这 3 个 Key-Value DB都是用 C编写的，他们的性能都相当出色，但出了出色的性能，他们还有自己独特的功能：1、Redis Redis 是一个很新的项目，刚刚发布了1.0 版本。Redis 本质上是一个Key-Value类型的内存数据库，很像memcached ，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush 到硬盘上进行保存。 因为是纯内存操作， Redis 的性能非常出色，
9、 每秒可以处理超过10 万次读写操作， 是我知道的性能最快的Key-Value DB 。Redis 的出色之处不仅仅是性能，Redis 最大的魅力是支持保存List 链表和 Set 集合的数据结构， 而且还支持对List 进行各种操作， 例如从 List 两端 push 和 pop 数据，取 List区间，排序等等，对Set 支持各种集合的并集交集操作，此外单个value 的最大限制是1GB，不像 memcached只能保存 1MB 的数据，因此Redis 可以用来实现很多有用的功能，比方说用他的List 来做 FIFO 双向链表，实现一个轻量级的高性能消息队列服务，用他的Set 可以做高性能
10、的tag 系统等等。另外Redis 也可以对存入的Key-Value设置 expire 时间，因此也可以被当作一个功能加强版的memcached来用。Redis 的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，并且它没有原生的可扩展机制，不具有scale（可扩展）能力，要依赖客户端来实现分布式读写，因此Redis 适合的场景主要局限在较小数据量的高性能操作和运算上。目前使用Redis 的网站有 github ，Engine Yard 。2、Tokyo Cabinet和 Tokoy Tyrant TC 和 TT 的开发者是日本人Mikio Hirabayashi ，主要被
11、用在日本最大的SNS 网站 mixi.jp 上，TC 发展的时间最早，现在已经是一个非常成熟的项目，也是Kye-Value 数据库领域最大的热点，现在被广泛的应用在很多很多网站上。TC 是一个高性能的存储引擎，而TT 提供了多线程高并发服务器，性能也非常出色，每秒可以处理4-5 万次读写操作。TC 除了支持 Key-Value 存储之外，还支持保存Hashtable 数据类型，因此很像一个简单的数据库表，并且还支持基于column 的条件查询，分页查询和排序功能，基本上相当于支持单表的基础查询功能了，所以可以简单的替代关系数据库的很多操作，这也是TC 受到大家欢迎的主要原因之一，有一个Ruby
12、 的项目 miyazakiresistance将 TT 的hashtable 的操作封装成和ActiveRecord一样的操作，用起来非常爽。TC/TT 在 mixi 的实际应用当中，存储了2000 万条以上的数据，同时支撑了上万个并发连接，是一个久经考验的项目。TC 在保证了极高的并发读写性能的同时，具有可靠的数据持久化机制，同时还支持类似关系数据库表结构的hashtable 以及简单的条件，分页和排序操作，是一个很棒的NoSQL 数据库。TC 的主要缺点是在数据量达到上亿级别以后，并发写数据性能会大幅度下降，NoSQL: If Only It Was That Easy提到，他们发现在TC
13、 里面插入1.6 亿条 2-20KB 数据的时候，写入性能开始急剧下降。看来是当数据量上亿条的时候，TC 性能开始大幅度下降，从TC 作者自己提供的mixi 数据来看，至少上千万条数据量的时候还没有遇到这么明显的写入性能瓶颈。这个是 Tim Yang做的一个 Memcached ，Redis 和 Tokyo Tyrant的简单的性能评测，仅供参考3. Flare TC 是日本第一大SNS 网站 mixi 开发的，而Flare 是日本第二大SNS 网站 green.jp 开发的，有意思吧。Flare 简单的说就是给TC 添加了 scale 功能。他替换掉了TT 部分，自己另外给 TC 写了网络服
14、务器，Flare 的主要特点就是支持scale 能力，他在网络服务端之前添加了一个node server ，来管理后端的多个服务器节点，因此可以动态添加数据库服务节点，删除服务器节点，也支持failover 。如果你的使用场景必须要让TC 可以 scale ，那么可以考虑flare。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 4 页 - - - - - - - - - flare 唯一的缺点就是他只支持memcached协议，因此当你使用flare 的时候，就不能使用
15、TC 的 table 数据结构了，只能使用TC 的 key-value 数据结构存储。二、满足海量存储需求和访问的面向文档的数据库：MongoDB，CouchDB 面向文档的非关系数据库主要解决的问题不是高性能的并发读写，而是保证海量数据存储的同时，具有良好的查询性能。 MongoDB 是用 C+开发的，而 CouchDB 则是 Erlang开发的：1. MongoDB MongoDB 是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。 他支持的数据结构非常松散，是类似 json 的 bjson 格式，因此可以存储比较复杂的数据类型。Mongo最大的
16、特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。Mongo 主要解决的是海量数据的访问效率问题，根据官方的文档，当数据量达到50GB 以上的时候， Mongo 的数据库访问速度是MySQL 的 10 倍以上。 Mongo 的并发读写效率不是特别出色， 根据官方提供的性能测试表明，大约每秒可以处理0.5 万 1.5 次读写请求。 对于 Mongo 的并发读写性能， 我（ robbin）也打算有空的时候好好测试一下。因为 Mongo 主要是支持海量数据存储的，所以 Mongo 还自带了一个出色的分布式文
17、件系统GridFS ，可以支持海量的数据存储，但我也看到有些评论认为GridFS 性能不佳，这一点还是有待亲自做点测试来验证了。最后由于 Mongo 可以支持复杂的数据结构，而且带有强大的数据查询功能，因此非常受到欢迎，很多项目都考虑用MongoDB 来替代 MySQL 来实现不是特别复杂的Web 应用，比方说 why we migrated from MySQL to MongoDB就是一个真实的从MySQL 迁移到 MongoDB 的案例，由于数据量实在太大，所以迁移到了Mongo 上面，数据查询的速度得到了非常显著的提升。MongoDB 也有一个ruby 的项目 MongoMapper，
18、是模仿 Merb 的 DataMapper编写的 MongoDB的接口，使用起来非常简单，几乎和DataMapper 一模一样，功能非常强大易用。2. CouchDBCouchDB 现在是一个非常有名气的项目，似乎不用多介绍了。 但是我却对CouchDB 没有什么兴趣， 主要是因为 CouchDB 仅仅提供了基于HTTP REST的接口，因此 CouchDB单纯从并发读写性能来说，是非常糟糕的，这让我立刻抛弃了对CouchDB 的兴趣。三、满足高可扩展性和可用性的面向分布式计算的数据库：Cassandra ，Voldemort 面向 scale 能力的数据库其实主要解决的问题领域和上述两类数据
19、库还不太一样，它首先必须是一个分布式的数据库系统，由分布在不同节点上面的数据库共同构成一个数据库服务系统，并且根据这种分布式架构来提供online 的，具有弹性的可扩展能力，例如可以不停机的添加更多数据节点，删除数据节点等等。因此像Cassandra常常被看成是一个开源版本的Google BigTable的替代品。 Cassandra 和 Voldemort都是用 Java 开发的：1. Cassandra Cassandra 项目是 Facebook在 2008 年开源出来的， 随后 Facebook 自己使用 Cassandra 的另外一个不开源的分支，而开源出来的Cassandra 主要
20、被 Amazon 的 Dynamite团队来维护，并且Cassandra 被认为是 Dynamite2.0 版本。目前除了Facebook 之外， twitter 和 都在使用 Cassandra 。Cassandra 的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对 Cassandra 的一个写操作， 会被复制到其他节点上去， 对 Cassandra的读操作，也会被路由到某个节点上面去读取。对于一个Cassandra群集来说，扩展性能是比较简单的事情，只管在群集里面添加节点就可以了。我看到有文章说Facebook的 Cassandra 群集有超过 100
21、台服务器构成的数据库群集。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 4 页 - - - - - - - - - Cassandra 也支持比较丰富的数据结构和功能强大的查询语言，和MongoDB 比较类似，查询功能比MongoDB稍弱一些， twitter 的平台架构部门领导Evan Weaver写了一篇文章介绍 Cassandra ：http:/ 以单个节点来衡量， 其节点的并发读写性能不是特别好，有文章说评测下来Cassandra 每秒大约不到1 万次读写请求，
22、 我也看到一些对这个问题进行质疑的评论，但是评价 Cassandra 单个节点的性能是没有意义的，真实的分布式数据库访问系统必然是n 多个节点构成的系统，其并发性能取决于整个系统的节点数量，路由效率，而不仅仅是单节点的并发负载能力。2. Voldemort Voldemort 是个和 Cassandra 类似的面向解决scale 问题的分布式数据库系统，Cassandra 来自于 Facebook 这个 SNS 网站，而 Voldemort则来自于 Linkedin 这个 SNS 网站。说起来 SNS 网站为我们贡献了n多的 NoSQL 数据库，例如 Cassandar ，Voldemort
23、，Tokyo Cabinet ，Flare 等等。 Voldemort的资料不是很多，因此我没有特别仔细去钻研， Voldemort官方给出 Voldemort 的并发读写性能也很不错，每秒超过了1.5 万次读写。从 Facebook 开发 Cassandra ，Linkedin 开发 Voldemort ，我们也可以大致看出国外大型SNS 网站对于分布式数据库，特别是对数据库的scale 能力方面的需求是多么殷切。前面我（ robbin ）提到， web 应用的架构当中， web 层和 app 层相对来说都很容易横向扩展，唯有数据库是单点的，极难scale ，现在 Facebook 和 Li
24、nkedin 在非关系型数据库的分布式方面探索了一条很好的方向，这也是为什么现在Cassandra 这么热门的主要原因。如今， NoSQL数据库是个令人很兴奋的领域，总是不断有新的技术新的产品冒出来，改变我们已经形成的固有的技术观念，我自己（robbin ）稍微了解了一些，就感觉自己深深的沉迷进去了，可以说NoSQL 数据库领域也是博大精深的，我（robbin ）也只能浅尝辄止，我（robbin ）写这篇文章既是自己一点点钻研心得，也是抛砖引玉，希望吸引对这个领域有经验的朋友来讨论和交流。从我（ robbin ）个人的兴趣来说，分布式数据库系统不是我能实际用到的技术，因此不打算花时间深入，而其他两个数据领域（高性能NoSQLDB和海量存储 NoSQLDB ）都是我很感兴趣的，特别是Redis ，TT/TC 和 MongoDB这 3 个 NoSQL 数据库，因此我接下来将写三篇文章分别详细介绍这3个数据库。原文链接： http:/ - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 4 页 - - - - - - - - -