随着互联网web2.0网站的兴起,非关系型的数据库现在成了一个极其热门的新领域, 非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不 从心,暴露了很多难以克服的问题,例如:
1、High performance - 对数据库高并发读写的需求
web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息,所以基本上无法使用动态页面静态化技术,因此数据库并发负载非常高,往往要达到 每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住,但是应付上万次SQL写数据请求,硬盘IO就已经无法承受了。其实对于普通的BBS网 站,往往也存在对高并发写请求的需求,例如像JavaEye网站的实时统计在线用户状态,记录热门帖子的点击次数,投票计数等,因此这是一个相当普遍的需 求。
2、Huge Storage - 对海量数据的高效率存储和访问的需求
类似Facebook,twitter,Friendfeed这样的SNS网站,每天用户产生海量的用户动态,以Friendfeed为例,一个月就达到 了2.5亿条用户动态,对于关系数据库来说,在一张2.5亿条记录的表里面进行SQL查询,效率是极其低下乃至不可忍受的。再例如大型web网站的用户登 录系统,例如腾讯,盛大,动辄数以亿计的帐号,关系数据库也很难应付。
3、High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求
在基于web的架构当中,数据库是最难进行横向扩展的,当一个应用系统的用户量和访问量与日俱增的时候,你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说,对数据库系统进行升级和扩展 是非常痛苦的事情,往往需要停机维护和数据迁移,为什么数据库不能通过不断的添加服务器节点来实现扩展呢?
在上面提到的“三高”需求面前,关系数据库遇到了难以克服的障碍,而对于web2.0网站来说,关系数据库的很多主要特性却往往无用武之地,例如:
1、数据库事务一致性需求
很多web实时系统并不要求严格的数据库事务,对读一致性的要求很低,有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负 担。
2、数据库的写实时性和读实时性需求
对关系数据库来说,插入一条数据之后立刻查询,是肯定可以读出来这条数据的,但是对于很多web应用来说,并不要求这么高的实时性,比方说发一条消息之 后,过几秒乃至十几秒之后,我的订阅者才看到这条动态是完全可以接受的。
3、对复杂的SQL查询,特别是多表关联查询的需求
任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的复杂SQL报表查询,特别是SNS类型的网站,从需求以及产品设计角 度,就避免了这种情况的产生。往往更多的只是单表的主键查询,以及单表的简单条件分页查询,SQL的功能被极大的弱化了。
因此,关系数据库在这些越来越多的应用场景下显得不那么合适了,为了解决这类问题的非关系数据库应运而生,现在这两年,各种各样非关系数据库,特别是键值 数据库(Key-Value Store DB)风起云涌,多得让人眼花缭乱。前不久国外刚刚举办了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编写的,每个都有自己的独到之处,看都看不过来了,这 些NoSQL数据库大致可以分为以下的三类:
一、满足极高读写性能需求的Kye-Value数据库:Redis,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的性能非常出色,每秒可以处理超过 10万次读写操作,是我知道的性能最快的Key-Value DB。
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。
2、Tokyo Cabinet和Tokoy Tyrant
TC和TT的开发者是日本人Mikio Hirabayashi,主要被用在日本最大的SNS网站mixi.jp上,TC发展的时间最早,现在已经是一个非常成熟的项目,也是Kye-Value 数据库领域最大的热点,现在被广泛的应用在很多很多网站上。TC是一个高性能的存储引擎,而TT提供了多线程高并发服务器,性能也非常出色,每秒可以处理 4-5万次读写操作。
TC除了支持Key-Value存储之外,还支持保存Hashtable数据类型,因此很像一个简单的数据库表,并且还支持基于column的条件查询, 分页查询和排序功能,基本上相当于支持单表的基础查询功能了,所以可以简单的替代关系数据库的很多操作,这也是TC受到大家欢迎的主要原因之一,有一个 Ruby的项目miyazakiresistance将TT的hashtable的操作封装成和ActiveRecord一样的操作,用起来非常爽。
TC/TT在mixi的实际应用当中,存储了2000万条以上的数据,同时支撑了上万个并发连接,是一个久经考验的项目。TC在保证了极高的并发读写性能 的同时,具有可靠的数据持久化机制,同时还支持类似关系数据库表结构的hashtable以及简单的条件,分页和排序操作,是一个很棒的NoSQL数据 库。
TC主要的缺点是没有scale的能力,如果单机无法满足要求,只能通过主从复制的方式扩展,另外有人提到TC的性能会随着数据量的增加而下降,当数据量 上亿条以后,性能会有比较明显的下降。
这个是Tim Yang做的一个Memcached,Redis和Tokyo Tyrant的简单的性能评测,仅供参考
3、Flare
TC是日本第一大SNS网站mixi开发的,而Flare是日本第二大SNS网站green.jp开发的,有意思吧。Flare简单的说就是给TC添加了 scale功能。他替换掉了TT部分,自己另外给TC写了网络服务器,Flare的主要特点就是支持scale能力,他在网络服务端之前添加了一个 node server,来管理后端的多个服务器节点,因此可以动态添加数据库服务节点,删除服务器节点,也支持failover。如果你的使用场景必须要让TC可 以scale,那么可以考虑flare。
flare唯一的缺点就是他只支持memcached协议,因此当你使用flare的时候,就不能使用TC的table数据结构了,只能使用TC的 key-value数据结构存储。
二、满足海量存储需求和访问的面向文档的数据库:MongoDB,CouchDB
面向文档的非关系数据库主要解决的问题不是高性能的并发读写,而是保证海量数据存储的同时,具有良好的查询性能。MongoDB是用C++开发的,而 CouchDB则是Erlang开发的:
1、MongoDB
MongoDB是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的。他支持的数据结构非常松散,是类似 json的bjson格式,因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几 乎可以实现类似关系数据库单表查询的绝大部分功能,而且还支持对数据建立索引。
Mongo主要解决的是海量数据的访问效率问题,根据官方的文档,当数据量达到50GB以上的时候,Mongo的数据库访问速度是MySQL的10倍以 上。Mongo的并发读写效率不是特别出色,根据官方提供的性能测试表明,大约每秒可以处理0.5万-1.5次读写请求。
因为Mongo主要是支持海量数据存储的,所以Mongo还自带了一个出色的分布式文件系统GridFS,可以支持海量的数据存储,但我也看到有些评论认 为GridFS性能不佳,这一点还是有待亲自做点测试来验证了。
最后由于Mongo可以支持复杂的数据结构,而且带有强大的数据查询功能,因此非常受到欢迎,很多项目都考虑用MongoDB来替代MySQL来实现不是 特别复杂的Web应用,比方说why we migrated from MySQL to MongoDB就是一个真实的从MySQL迁移到MongoDB的案例,由于数据量实在太大,所以迁移到了Mongo上面,数据查询的速度得到了非常显著 的提升。
MongoDB也有一个ruby的项目MongoMapper,是模仿Merb的DataMapper编写的MongoDB的接口,使用起来非常简单,几 乎和DataMapper一模一样,功能非常强大易用。
2、CouchDB
CouchDB现在是一个非常有名气的项目,似乎不用多介绍了。但是我却对CouchDB没有什么兴趣,主要是因为CouchDB仅仅提供了基于HTTP REST的接口,因此CouchDB单纯从并发读写性能来说,是非常糟糕的,这让我立刻抛弃了对CouchDB的兴趣。
三、满足高可扩展性和可用性的面向分布式计算的数据库:Cassandra,Voldemort
面向scale能力的数据库其实主要解决的问题领域和上述两类数据库还不太一样,它首先必须是一个分布式的数据库系统,由分布在不同节点上面的数据库共同 构成一个数据库服务系统,并且根据这种分布式架构来提供online的,具有弹性的可扩展能力,例如可以不停机的添加更多数据节点,删除数据节点等等。因 此像Cassandra常常被看成是一个开源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java开发的:
1、Cassandra
Cassandra项目是Facebook在2008年开源出来的,随后Facebook自己使用Cassandra的另外一个不开源的分支,而开源出来 的Cassandra主要被Amazon的Dynamite团队来维护,并且Cassandra被认为是Dynamite2.0版本。目前除了 Facebook之外,twitter和digg.com都在使用Cassandra。
Cassandra的主要特点就是它不是一个数据库,而是由一堆数据库节点共同构成的一个分布式网络服务,对Cassandra的一个写操作,会被复制到 其他节点上去,对Cassandra的读操作,也会被路由到某个节点上面去读取。对于一个Cassandra群集来说,扩展性能是比较简单的事情,只管在 群集里面添加节点就可以了。我看到有文章说Facebook的Cassandra群集有超过100台服务器构成的数据库群集。
Cassandra也支持比较丰富的数据结构和功能强大的查询语言,和MongoDB比较类似,查询功能比MongoDB稍弱一些,twitter的平台 架构部门领导Evan Weaver写了一篇文章介绍Cassandra:http://blog.evanweaver.com/articles/2009/07/06 /up-and-running-with-cassandra/,有非常详细的介绍。
Cassandra以单个节点来衡量,其节点的并发读写性能不是特别好,有文章说评测下来Cassandra每秒大约不到1万次读写请求,我也看到一些对 这个问题进行质疑的评论,但是评价Cassandra单个节点的性能是没有意义的,真实的分布式数据库访问系统必然是n多个节点构成的系统,其并发性能取 决于整个系统的节点数量,路由效率,而不仅仅是单节点的并发负载能力。
2、Voldemort
Voldemort是个和Cassandra类似的面向解决scale问题的分布式数据库系统,Cassandra来自于Facebook这个SNS网 站,而Voldemort则来自于Linkedin这个SNS网站。说起来SNS网站为我们贡献了n多的NoSQL数据库,例如 Cassandar,Voldemort,Tokyo Cabinet,Flare等等。Voldemort的资料不是很多,因此我没有特别仔细去钻研,Voldemort官方给出Voldemort的并发读 写性能也很不错,每秒超过了1.5万次读写。
从Facebook开发Cassandra,Linkedin开发Voldemort,我们也可以大致看出国外大型SNS网站对于分布式数据库,特别是对 数据库的scale能力方面的需求是多么殷切。前面提到,web应用的架构当中,web层和app层相对来说都很容易横向扩展,唯有数据库是单点的,极难 scale,现在Facebook和Linkedin在非关系型数据库的分布式方面探索了一条很好的方向,这也是为什么现在Cassandra这么热门的 主要原因。
发表评论
-
四层和七层负载均衡的区别
2015-03-13 13:27 367(一) 简单理解四层和七层负载均衡: ① 所 ... -
Solr搜索服务架构图
2013-02-21 18:33 1363... -
Spring多数据源的配置和使用
2012-09-12 17:27 1078Spring多数据源的配置和使用 最近开 ... -
Java多播通讯框架 JGroups
2012-08-20 12:10 1325Java多播通讯框架 JGroups JGroups ... -
Terrocotta - 基于JVM的Java应用集群解决方案
2012-08-17 11:14 922Terrocotta - 基于JVM的Java ... -
MongoDB基本管理命令
2012-08-16 10:23 861MongoDB基本管理命令 MongoDB是一个NoSQ ... -
hessian demo和hessian与spring整合demo
2012-08-13 11:52 1643hessian demo和hessian与spring ... -
C++著名程序库的比较和学习经验
2012-07-25 10:35 739C++著名程序库的比较和学习经验 内容目录:1、C++各 ... -
Lucene和HBase的集成
2012-07-05 14:19 681Lucene和HBase的集成 ... -
可伸缩性最佳实践:来自eBay的经验
2012-07-05 08:53 712可伸缩性最佳实践: ... -
各种java序列化工具性能对比
2012-07-04 13:16 1756各种java序列化工具性能对比 看到一个很不错的工具ht ... -
深入探讨 Java 类加载器
2012-07-03 17:32 643深入探讨 Java 类加载 ... -
Servlet 工作原理解析
2012-06-27 15:05 717Servlet 工作原理解析 简介: Web 技 ... -
HTTP协议header头域
2012-06-27 10:04 914HTTP(HyperTextTransferPr ... -
深入研究Servlet线程安全性问题
2012-06-21 13:49 0摘 要:介绍了Servlet多 ... -
Java类加载原理解析
2012-06-12 13:33 597Java类加载原理解析 ... -
ffmpeg源码及相关开发资料下载,好文章积攒
2012-06-04 16:12 738FFMpeg0.6版源码下载:来自:http://sour ... -
分布式文件系统FastDFS架构剖析
2012-05-31 11:34 706FastDFS是一款类Google FS的开源分布式文件系 ... -
用nosql轻松打造千万级数据量的微博系统
2012-05-23 11:38 857其实微博是一个结构相对简单,但数据量却是很庞大的一种产品. ...
相关推荐
NoSQL数据库,全称为"Not Only SQL",是在互联网web2.0时代兴起的一种新型数据库解决方案,主要用于处理大规模数据和高并发访问的需求。传统的SQL(结构化查询语言)关系型数据库在面对这类挑战时,往往表现出性能...
本课件将深入探讨分布式数据库的原理以及NoSQL数据库的核心概念,帮助读者理解和掌握这两种技术。 一、分布式数据库基础 1. 分布式数据库定义:分布式数据库是一种物理上分散在不同地理位置,但在逻辑上视为单一...
NoSQL数据库,全称为"Not Only SQL",是近年来在应对互联网大规模、高并发、高可扩展性和高可用性需求背景下发展起来的一种非关系型数据库。相比于传统的SQL关系数据库,NoSQL数据库提供了不同的数据模型和存储机制...
这暗示了我们将会探讨的是NoSQL数据库的基础概念以及常见的NoSQL数据库类型。 【标签】:“MySQL”虽然在本主题中可能不是直接的焦点,但作为关系型数据库的代表,MySQL常常与NoSQL数据库进行对比,因此在这里可能...
《NoSQL数据库技术实战》是腾讯公司前资深后台工程师倾力打造的一本专著,针对大数据时代的开发者,提供了丰富的知识内容。这本书旨在帮助读者全面理解并掌握NoSQL数据库的使用,从基础操作到高级技术,再到核心原理...
“大数据挑战与NoSQL数据库技术”这本书很可能深入探讨了这些问题,包括大数据的挑战、NoSQL数据库的原理、各类NoSQL数据库的特点以及如何在实际项目中选择和使用NoSQL数据库。通过阅读这本书,读者可以更全面地了解...
在“NoSQL数据库入门”中,我们将深入探讨以下几个核心知识点: 1. **NoSQL的概念**:NoSQL并不是指完全不使用SQL,而是指不使用传统的关系模型,它支持灵活的数据结构,如键值对、文档型、列族和图形数据库等。 2...
NoSQL数据库原理主要探讨了非关系型数据库与传统的关系型数据库在设计和操作上的差异。在第二章中,重点讲解了NoSQL数据库的基本原理,包括它如何打破关系模型的常规特征,以及它对完整性约束和事务机制的不同处理...
### NoSQL数据库的应用探讨 #### NoSQL产生的背景 随着互联网技术的飞速发展,特别是社交网络、移动互联网等新兴领域的兴起,传统的关系型数据库面临着前所未有的挑战。这些挑战主要体现在三个方面:一是对数据库...
本章节主要探讨了NoSQL数据库中的三种重要类型:图数据库、文档数据库和列族数据库,并结合北京邮电大学(BUPT)的相关课程作业进行深入学习。 首先,让我们详细了解一下图数据库。图数据库以节点、边和属性三元组...
接下来,我们将深入探讨NoSQL数据库的关键概念、类型、特点以及应用场景。 ### NoSQL数据库的关键概念 NoSQL数据库的核心理念是灵活性和可扩展性,它们通常不采用固定的表结构,而是支持多种数据存储方式,如键值...
本文将深入探讨NoSQL数据库查询处理的挑战,并总结当前流行的解决方案和技术。 ### NoSQL查询处理的挑战 NoSQL数据库的查询能力通常不如传统的RDBMS强大,这主要是由其设计原则决定的。NoSQL系统通常追求高可伸缩...
### NoSQL数据库-MongoDB和Redis #### 一、NoSQL简述 NoSQL数据库的出现是为了应对传统关系型数据库无法解决的一些问题,特别是在大规模数据处理方面。CAP理论(Consistency,Availability,Partition Tolerance)...
《大数据挑战与NoSQL数据库技术》一书,由陆嘉恒编著,深入探讨了在当前数据爆炸的时代,如何应对大数据带来的挑战,并介绍了NoSQL数据库技术作为解决方案的重要角色。本书内容丰富,旨在帮助读者理解大数据的特性、...
本文将深入探讨SQL与NoSQL数据库间的数据查询转换方法,包括数据模式的变化、数据类型的转换、查询语言的差异等方面,并提供实践指南和参考文献,旨在帮助读者快速掌握SQL与NoSQL数据库间的数据查询转换技术。...
本文将深入探讨SQL数据库与NoSQL数据库的区别、优势、以及它们在不同场景下的应用。 SQL数据库和NoSQL数据库各有优势和局限,选择哪种数据库取决于具体的应用需求。理解它们之间的差异有助于开发者做出更合适的技术...
《NoSQL数据库原理与应用》课程是一门针对互联网和物联网技术背景下的新型数据库系统的教学大纲。这门课程旨在深入探讨非关系型数据库(NoSQL)的基本原理、设计方法和技术,以应对大规模数据处理和高并发环境下的...
《NoSQL数据库笔谈》是一本深入探讨非关系型数据库技术的著作,作者颜开在2010年提出了对NoSQL数据库的见解和分析。本文主要围绕思想篇、手段篇、软件篇和应用篇四个部分展开,揭示了NoSQL数据库的核心概念、实现...
《nosql数据库入门 中文版》详细地介绍了nosql数据库(非关系型数据库)的种类、用途以及使用方法,并对memcached、tokyotyrant、redis、mongodb这4种代表性的nosql数据库的特征、适用范围、实现代码进行了深入探讨,...
本篇文章将深入探讨如何根据项目需求选择合适的NoSQL数据库。 首先,理解NoSQL数据库的四大类型至关重要:键值存储、列族、文档型和图形数据库。键值存储(如Redis、Memcached)适用于快速访问和简单的数据结构;列...