`
robbin
  • 浏览: 4796759 次
  • 性别: Icon_minigender_1
  • 来自: 上海
博客专栏
377a9ecd-1ea1-34ac-9530-9daa53bb2a7b
robbin谈管理
浏览量:135567
社区版块
存档分类
最新评论

NoSQL数据库探讨之一 - 为什么要用非关系数据库?

阅读更多
随着互联网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应用来说,并不要求这么高的实时性,比方说我(JavaEye的robbin)发一条消息之后,过几秒乃至十几秒之后,我的订阅者才看到这条动态是完全可以接受的。

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编写的,每个都有自己的独到之处,看都看不过来了,我(robbin)也只能从中挑选一些比较有特色,看起来更有前景的产品学习和了解一下。这些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的主要缺点是在数据量达到上亿级别以后,并发写数据性能会大幅度下降,NoSQL: If Only It Was That Easy提到,他们发现在TC里面插入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写了网络服务器,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的并发读写性能,我(robbin)也打算有空的时候好好测试一下。

因为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能力方面的需求是多么殷切。前面我(robbin)提到,web应用的架构当中,web层和app层相对来说都很容易横向扩展,唯有数据库是单点的,极难scale,现在Facebook和Linkedin在非关系型数据库的分布式方面探索了一条很好的方向,这也是为什么现在Cassandra这么热门的主要原因。

如今,NoSQL数据库是个令人很兴奋的领域,总是不断有新的技术新的产品冒出来,改变我们已经形成的固有的技术观念,我自己(robbin)稍微了解了一些,就感觉自己深深的沉迷进去了,可以说NoSQL数据库领域也是博大精深的,我(robbin)也只能浅尝辄止,我(robbin)写这篇文章既是自己一点点钻研心得,也是抛砖引玉,希望吸引对这个领域有经验的朋友来讨论和交流。

从我(robbin)个人的兴趣来说,分布式数据库系统不是我能实际用到的技术,因此不打算花时间深入,而其他两个数据领域(高性能NoSQLDB和海量存储NoSQLDB)都是我很感兴趣的,特别是Redis,TT/TC和MongoDB这3个NoSQL数据库,因此我接下来将写三篇文章分别详细介绍这3个数据库。
分享到:
评论
95 楼 youjianbo_han_87 2013-06-11  
很期待后面3个NOSQL数据库的的详细介绍,文章在哪搭呢?
94 楼 1monh 2013-04-27  
"CouchDB现在是一个非常有名气的项目,似乎不用多介绍了。但是我却对CouchDB没有什么兴趣,主要是因为CouchDB仅仅提供了基于HTTP REST的接口,因此CouchDB单纯从并发读写性能来说,是非常糟糕的,这让我立刻抛弃了对CouchDB的兴趣。 "



你懂个球!
93 楼 coldrush 2012-12-21  
感谢robbin贡献这么好的文章。
92 楼 atii 2012-08-28  
学习了,有点感觉了。

意思是说:变化的核心需求在于数据库需要关注的业务模型发生了极大的变化?

关系型数据库时代:服务的主要业务类型是事务。

在现在互联网应用场景下:大数据,强读写能力为主要特征的业务需求。业务需求的简化带来查询简化,相应的,改变了对数据库的要求,出现NoSQL。

91 楼 larry1314mvp 2012-07-16  
弱弱的问一句下面两句话 “1.对数据库高并发读写的需求 2.对海量数据的高效率存储和访问的需求” 为什么非关系系数据库就好 而关系型数据库不好 求解答
90 楼 zyy5411 2012-07-07  
“我接下来将写三篇文章分别详细介绍这3个数据库”为什么没有哇
89 楼 elmar 2012-04-14  
荒村听雨 写道

非关系型还有个缺点就是表之间的关联。Join操作不能用了,于是得取出一个表里所有符合的列,再对另一个表进行多次的查询(虽然BigTable也支持IN操作,但限制数目最多20,而且内部实现是多个并发的=操作)。如果涉及到3个以上的表的话,这种操作的效率和代码量更是不可接受的。


有join的需求就不要用nosql,nosql就是假定没有join的。
88 楼 荒村听雨 2012-04-01  

非关系型还有个缺点就是表之间的关联。Join操作不能用了,于是得取出一个表里所有符合的列,再对另一个表进行多次的查询(虽然BigTable也支持IN操作,但限制数目最多20,而且内部实现是多个并发的=操作)。如果涉及到3个以上的表的话,这种操作的效率和代码量更是不可接受的。

淘金盈 博彩通  澳门博彩  博彩网e世博]时尚资讯
87 楼 WhyNever 2012-03-22  
受教了,学习一下。
86 楼 suoth 2012-02-29  
学习了。。。。。。
85 楼 zhaolei-best 2012-02-03  
分析的很详细也很直白,非常有帮助。不知道后续的三篇文章何时出来
84 楼 xiaokang1582830 2012-01-29  
说得非常到位!nosql应该说是发展的一个必然趋势
83 楼 xufun 2011-12-30  
elmar 写道
土问CAP什么意思?



CAP,BASE和最终一致性是NoSQL数据库存在的三大基石。CAP的意思是:
  C: Consistency 一致性
   A: Availability 可用性(指的是快速获取数据)
  P: Tolerance of network Partition 分区容忍性(分布式)
BASE是
  Basically Availble --基本可用
  Soft-state --软状态/柔性事务。"Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的
  Eventual Consistency --最终一致性。最终一致性, 也是是 ACID 的最终目的。

BASE模型反ACID模型,完全不同ACID模型,牺牲高一致性。
82 楼 xufun 2011-12-30  
好文拜读了,谢谢!
81 楼 56553655 2011-11-02  
受教了,能够看到这样的文章,就是我们开发者的福音
80 楼 oujunfeng 2010-10-17  
分析的很好,正有这方面探讨的打算,十分受教了!
79 楼 C_J 2010-08-27  
scgywx 写道
为什么Redis和MongoDB的读写操作差距好大哦,如果两个之间进行互补一下,是不是完美了??


从robbin大哥文中介绍和自己了解的情况来说,redis数据在内存处理,主要解决高读写问题,MongoDB采用BSON松散结构和自己的文件系统,主要解决海量数据存储问题。

可想两者应该有差距了。
78 楼 gh_aiyz 2010-08-25  
gyro 写道
AreYouOK? 写道
我在工作中也遇到很多问题,关系数据库确实有些力不从心了,但是不使用关系数据库,面对复杂的查询,没有好的解决方案。
从这篇文章的介绍看,我对MongoDB最感兴趣,期待后续。

我的需求和这里列出的Web2.0的网站需求还不太一样。我的场景是:
  • 数据量非常巨大,写操作特别多。数据量可以说是无限的,就看系统能处理多少,如果能处理更多就要接入更多的数据(一般来说我们只接入了部分数据)。
  • 读操作非常少,可以用每天多少次来衡量(就那么几个使用人员,他用的时候才有查询操作),但是一旦有查询操作,往往都是重量级的。
  • 查询操作可以稍微慢点,能在5秒内出来就不错了,如果进行复杂的查询,30秒出来也算不错了。10分钟甚至1个小时才查出结果,是非常不好的,但是能出来总比不能要好。
  • 写操作允许丢失少量数据,但是整个数据库的完整性要有保证
  • 数据最好能够压缩存储


在某个项目里面,数据量大的时候大约每天40、50G,使用postgresql,居然也支撑了下来,但是查询非常慢。接下来的一些项目数据量会更大,可能会有这个量的100倍以上,目前没有好的办法,只能从数据源头先做过滤。

我在1年前,开始尝试进行一些探索,根据产品需求特点,使用自定义的数据格式存储。目前能够解决的问题有:
  • 对数据进行简单的解析和压缩存储
  • 能够对压缩的数据进行简单的查询(指定数据源、时间范围、关键字),查询较慢,但是比SQL有一个好处,就是能看见当前查询到哪个时间点了,而不是像SQL一样,等运行完了才能给用户看到
  • 高性能的写入。目前在我的笔记本上进行简单的测试,每秒2万条的UDP包,丢包率是0.5%,在复杂的环境下性能是会下降的,但服务器的性能会更好

不幸的是,我只有很少的时间能投入到这上面,有时候几个星期都没空去弄,所以到现在还有很多要完善的地方,没有在项目里面实用。有时候我都怀疑这条路是不是走错了。

目前没有解决的问题是高性能的、对数据的复杂查询。数据可以分为2部分,原始数据和格式化后的数据,目前我这里只解决了原始数据的问题,对于格式化数据的复杂查询,还是需要类似关系数据库的功能才行。这也是我对MongoDB比较感兴趣的原因。




感觉上,你这就是一个日志统计系统,解决模型可以看现在大部分的日志统计程序
只保留必要的数据,并且汇总必要的数据,根据你可以开放的查询功能,设计你的数据结构。

就是,原始数据直接缓冲后写入文件,再以专门的分析程序进行分析,分析结果形成报表,解释查询的就是各种报表罢了。
77 楼 toppi 2010-07-31  
不错的文章,不错的讨论
76 楼 slimsymphony 2010-07-20  
pandonix 写道
onlytiancai 写道
比如一个SNS系统,有1亿注册用户,我们可以按用户ID平均分成100组DB。
客户端通过用户ID和一个映射规则去获取它所属的DB组,然后再使用。

因为每组DB只有100w,所以能满足高性能并发读写的需求,慢的话再细分;

对于写缓存,读缓存等是应用的事,可以写应用来实现缓存。
同理,对海量数据高效率存储也可以通过优化mysql或者更细的划分DB组来达到;
每组DB都做热备以达到高可用性;

当用户又增长了100万时,增加一组DB,修改下映射规则就可以满足扩展性。
什么时候该用 nosql db呀



分库会带来太多的维护问题和辐射效应

相关推荐

    NoSQL数据库探讨之一-为什么要用非关系数据库?.pdf

    NoSQL数据库探讨之一-为什么要用非关系数据库?.pdf

    NoSQL数据库探讨.ppt

    随着互联网web2.0网站的兴起,非关系型的数据库现在成了一个极其热门的新领域,非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得...

    nosql数据库的应用探讨

    nosql数据库的发展和应用研究

    NoSQL数据库入门(当今最炙手可热的NoSQL新型数据库技术)

    《nosql数据库入门 中文版》详细地介绍了nosql数据库(非关系型数据库)的种类、用途以及使用方法,并对memcached、tokyotyrant、redis、mongodb这4种代表性的nosql数据库的特征、适用范围、实现代码进行了深入探讨,...

    NoSQL 精粹 高清

    《NoSQL 精粹》为考虑是否可以使用和如何使用 NoSQL 数据库的企业提供了可靠的决策依据。它由世界级软件开发大师和软件开发 “教父”Martin Fowler 与 Jolt 生产效率大奖图书作者 Pramod J. Sadalage 共同撰写。书中...

    2013年中国数据库大会-11-NoSQL一致性实践:我对CAP的一点认识

    一直以来,数据库架构实践、数据库优化应用等,是备受大家关注的传统话题,本届大会仍将继续邀请一批国内顶尖的技术专家来进行分享,包括Oracle应用实践、MySQL应用实践、SQL Server应用实践等。

    2013年中国数据库大会-09-主流开源NoSQL及分布式存储的应用与思考

    一直以来,数据库架构实践、数据库优化应用等,是备受大家关注的传统话题,本届大会仍将继续邀请一批国内顶尖的技术专家来进行分享,包括Oracle应用实践、MySQL应用实践、SQL Server应用实践等。

    使用NoSQL数据库提供云级别数据可伸缩性

    在提及数据库扩展性时,人们就会想到相对低成本...NoSQL数据库(包括NoSQL系统HBase、MongoDB和SimpleDB)的特性和功能概述,还将介绍云和 NoSQL数据库的设计基础。就创建、交流、访问内容、共享信息和购买产品而论,快

    NoSQL精粹爱飞翔

    《NoSQL精粹》为考虑是否可以使用和如何使用NoSQL数据库的企业提供了可靠的决策依据。它由世界级软件开发大师和软件开发“教父”Martin Fowler与Jolt生产效率大奖图书作者Pramod J. Sadalage共同撰写。书中全方位...

    计算机课程(数据库)-关系型数据库 vs. 非关系型数据库

    本文将介绍关系型数据库和非关系型数据库的概念、主流数据库管理系统,并深入探讨它们的优缺点以及适用场景。同时,我们还将从数据模型、数据结构、数据操作和数据存储方式等方面对比这两种数据库类型的差别。

    dsc-nosql-databases-section-recap-nyc-ds-071519

    NoSQL数据库-概述NoSQL与SQL 我们通过将Relational Databases / SQL与各种NoSQL数据库选项进行比较和对比来开始本课程,并概述了何时使用它们的示例。 NoSQL数据库有4种不同的类型: 文件存储关键值商店列存储图形...

    基于NoSQL内存数据库的Linux性能优化

    我们不仅要选择适合自己口味的NoSQL数据库,比如基于内存的Memcache或Redis,更适合企业级架构的Cassandra或HBase,同时,针对Linux服务器的优化也必不可少。另外,还有一个问题需要探讨。我们在尝试NoSQL数据库的...

    厦门大学林子雨老师主讲大数据教程.rar

    Chapter5--大数据技术原理与应用-第5讲-NoSQL数据库.pdf Chapter6--大数据技术原理与应用-第6讲-云数据库.pdf Chapter7--大数据技术原理与应用-第7讲-MapReduce.pdf Chapter8--大数据技术原理与应用-第8讲-基于...

    基于NoSQL的PDM产品结构数据组织 (2013年)

    SQL的优势,以及PDM中产品结构树的创建理念,结合产品结构树中的结构关系和非关系型数据库MongoDB的特点,探讨PDM中的数据在MongoDB中数据存储结构,打破以往关系型数据库表结构的传统模式,建立一种基于NoSQL的PDM数据...

    一文看懂数据库原理

    一提到关系型数据库,我禁不住想:有些东西被忽视了。关系型数据库无处不在,而且种类繁多,从小巧实用的SQLite到强大的Teradata。但很少有文章讲解数据库是如何工作的。...而且,数据库已经使用了40年之久,一定

    Designing Data Intensive Applications

    数据存储和处理:如何处理和存储大数据量,包括关系型数据库、NoSQL数据库、消息队列、搜索引擎和流处理。 数据流和数据流处理:如何处理实时数据流,以及如何使用流处理系统进行流数据处理和分析。 可靠性和可维护...

Global site tag (gtag.js) - Google Analytics