nosql和关系型数据库对比

Nosql介绍

Nosql(not only sql)指的是非关系型数据库,而我们常用的都是关系型数据库,这些数据库一般用来存储重要信息,应对普通的业务是没有问题的,但是,随着互联网的告诉发展,传统道德关系型数据库在应对超大规模,超大流量以及高并发的时候力不从心。

四大类型

键值数据库

相关产品:redis、riak、simpledb、chordless、scalaris、memcached
应用:内容缓存
优点:扩展性号、灵活性好、大量写操作时性能高
缺点:无法存储结构化信息、条件查询效率较低

列组数据库

相关产品:BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS
应用:分布式数据存储与管理
优点:查找速度快、可扩展性强、容易进行分布式扩展、复杂性低

文档数据库

相关产品:MongoDB、CouchDB、ThruDB、CloudKit、Perservere、Jackrabbit
应用:存储、索引并管理面向文档的数据或者类似的半结构化数据
优点:性能好、灵活性高、复杂性低、数据结构灵活
缺点:缺乏统一的查询语言

图形数据库

相关产品:Neo4J、OrientDB、InfoGrid、GraphDB
应用:大量复杂、互连接、低结构化的图结构场合,如社交网络、推荐系统等
优点:灵活性高、支持复杂的图形算法、可用于构建复杂的关系图谱
缺点:复杂性高、只能支持一定的数据规模

Nosql和关系型数据库的区别

存储方式

关系型数据库是表格式的,因此存储在表的列和行中,他们之间很容易关联协作存储,提取数据很方便。而nosql数据库则与其相反,它是大块的组合在一起。通常存储在数据集中,就像文档、键值对或者图结构。

存储结构

关系型数据库对应的是结构化数据,数据表都预先定义了结构(列的定义),结构描述了数据的形式和内容。这一点对数据建模至关重要,虽然预定义结构带来了可靠性和稳定性,但是修改这些数据比较困难。而nosql数据库基于动态结构,使用与非结构化数据。因为nosql数据库是动态结构,可以很容易适应数据类型和结构的变化。

存储规范

关系型数据库的数据存储为了更高的规范性,把数据分割为最小的关系表以避免重复,获得精简的空间利用。虽然管理起来很清晰,但是单个操作设计到多张表的时候,数据管理就显得有点儿麻烦。而nosql数据存储在平面数据集中,数据经常可能会重复。单个数据库很少被分隔开,而是存储成了一个整体,这样整块数据更加便于读写

存储扩展(最大区别)

关系型数据库是纵向扩展,(提高处理能力,要使用速度更快的计算机)。数据存储在关系表中,因为数据存储在关系表中,操作的性能可能涉及到多个表,需要通过提升计算机性能来克服。虽然有很大的扩展空间,但是最终会达到纵向扩展的上限。而nosql数据库库是横向扩展的,它是存储方式就是分布式的,可以通过给资源池添加更多的普通数据库服务器来分担负担。

查询方式

关系型数据库通过结构化查询语言来操作数据库(就是我们通常说的SQL语句)。SQL支持数据库CURD操作的功能非常强大,是业界的标准用法。而nosql查询以块为单位操作数据,使用的是非结构化查询语言(UnQl),它是没有标准的。关系型数据库表中主键的概念对应nosql中存储文档的ID。关系型数据库使用预定义优化方式(比如索引)来加快查询操作,而nosql更简单更精确的数据访问模式。

事务

关系型数据库遵循ACID规则(原子性(Atomicity)、一致性(consistency)、隔离性(Isolation)、持久性(Durability)),而nosql数据库遵循BASE原则(基本可用(Basically Availble)、软/柔性事务(soft-state)、最终一致性(Eventual Consistency))。由于关系型数据库的输几局强一致性,所以对事务的支持很好。关系型数据库支持对事务原子性细粒度控制,并且易于回滚事务。而nosql数据库是CAP(一致性(consistency)、可用性(Availability)、分区容忍度(Partition tolerance))中任选两项,因为基于节点的分布式系统中,很难全部满足,所以对事务的支持不是很好,虽然也可以使用事务,但是并不是nosql的闪光点。

性能

关系型数据库为了维护数据的一致性付出了巨大的代价,读写性能比较差。在面对高并发读写性能非常差,面对海量数据的时候效率非常低。而nosql存储的格式都是key-value类型的,并且存储在内存中,废话从哪个容易存储,而且对于数据一致性弱要求。nosql无需sql的解析,提高了读写性能。

授权方式

关系型数据库通常有SQL Server,Mysql,Oracle。主流的Nosql数据库有redis,memcache,MongoDb。大多数的关系型数据库都是付费的并且价格昂贵,成本较大,而Nosql数据库通常都是开源的。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 215,294评论 6 497
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,780评论 3 391
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 161,001评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,593评论 1 289
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,687评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,679评论 1 294
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,667评论 3 415
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,426评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,872评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,180评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,346评论 1 345
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,019评论 5 340
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,658评论 3 323
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,268评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,495评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,275评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,207评论 2 352

推荐阅读更多精彩内容