关系型资料库和非关系型资料库有什么区别？
先说说关系型资料库和非关系型资料库有什么区别
这里的关系型和非关系型，主要是数据存储格式的区别，我们常见的关系型资料库有Mysql、Oracle、DB2、SQL Server等，都是通过关系模型来组织数据，也就是二维表格模型。
而非关系型资料库，就不是按照这个二维表格来存储数据了，例如Redis是使用键值对（key-value）来组织数据，MongoDB是采用BSON的格式（可以想像成JSON）；并且不局限于固定的结构。
关系型资料库和非关系型资料库之间的关系，也不是有你没有，二者选其一，通常都是配合起来使用的。
各自的优缺点
关系型资料库，容易理解，使用方便（通过SQL语言操作），易于维护；但是因为数据在磁碟上存储，I/O会成为一个很大的瓶颈，如果在高并发的场景下，性能降低的很快；另外，对于关系型资料库，当单表数据量增加到一定程度的时候，表的操作效率也会很低；表结构固定，当数据量比较大的时候，对表结构的扩展会是灾难性的。
非惯性资料库因为数据结构的「随性」，用户可以根据需要增加栏位，关系型数据习惯设计成多张表，然后通过表关联查询，而非关系型资料库（文档性）会把所有栏位放到一个集合中，避免多表的关联。不过缺点也非常明显，「随性」也就意味著没有标准，单集合有好处也有坏处，没有完整性约束，对于复杂的业务场景支持比较差。
Redis的数据存储格式是key-value，支持持久化、 支持事务，经常用于缓存、高并发下的读写（计数器、最新列表、秒杀），因为单线程的机制也会用于分散式锁。
MongoDB的数据存储格式为BSON（类似于JSON），支持快速读写，特别是大吞吐量的写操作；如果表结构不明确，未来可能会发生很大的变化，非常适合使用MongoDB。
架构中可以同时包含关系型资料库、Redis和MongoDB，各司其职。
相信不少人在工作中都遇到过以下对话：
程序员A：又要到流量高峰期了，感觉资料库要崩。
程序员B：嗯嗯，赶紧扩容吧。
虽然资料库很耳熟，但是它究竟是何方神圣呢？今天就给大家科普一下。
资料库，其实就是互联网业务存储、查询数据的仓库。通过几十年的发展历史让资料库衍生出了各种不同的类型。
1、关系型资料库关系型资料库，是指采用了关系模型来组织数据的资料库。例如，某个学生的信息——姓名：张三，性别：男，学号：12345，班级：二年级一班，每一个信息之间是有联系的，而数据也是以表格形式存储的。
这就是最早的资料库形态，1970年IBM的研究员E.F.Codd博士首先提出关系模型，在之后的几十年中，关系模型的概念得到了充分的发展并逐渐成为主流资料库结构的主流模型。Oracle、DB2、Microsoft SQL Server、MySQL等都属于这一范畴。
但是，这类资料库的特点是一致性强，缺点是读写性能差。
2、非关系型资料库（NoSQL）顾名思义，非关系型资料库是相对关系型资料库的一个概念，起初指的是「没有SQL」的资料库，但现在已经公认为「no relational」（非关系型）。非关系型资料库是根据特定的应用场景设计出来的，没有明确的分类标准，但根据应用场景大致可分为几类：1、文档资料库，没研究过定义，通常mongodb 就是文档资料库，特点就是数据定义比较灵活。2、Kv资料库，提供的是kv的数据表示模式。单机的rocksdb，分散式的tikv之类。3、图资料库。数据可以用图来定义。4、列式资料库。hbase之类，这里可能有争议，很多人把hbase 定义为列存。
之前提到的资料库都属于传统资料库和开源资料库，但到了云计算时代，无论是云服务提供商还是用户，都需要一个完全为云打造的资料库，于是诞生了全新的产品形态——云原生资料库。
作为云计算领域的先行者，亚马逊在2014年11月召开的AWS re:Invent 年度大会上，发布了云原生资料库Aurora, 让资料库行业发生了翻天覆地的变化。
在亚马逊之后，许多云厂商也纷纷投入云原生资料库研究。比如2017年9月，阿里云在国内率先发布自研的云原生资料库POLARDB，它采用了自主研发分散式存储引擎，计算伺服器和存储数据分离的架构。
如今，国际社会公认，与传统商业资料库相比，云原生资料库拥有以下几个大优势，是未来的大势所趋。
1）价格更低
传统商业资料库按年、按CPU这样的方式进行售卖，对大体量的企业而言，每年需要数百万甚至千万的费用。
云原生资料库按使用量付费，让用户可以以非常低的价格就享受到企业级资料库的服务。用户可以根据自己的业务实际发展情况，按需的购买，可以大大降低企业在早期发展过程的成本。
此外，云原生资料库天然是规模化的，规模化会带来成本的下降。这也大大降低单个用户的成本。例如，阿里云PolarDB价格仅为商业资料库的1/10。
2）更强的性能
用户使用传统的资料库需要单独购买硬体，然而传统的资料库厂商则更倾向于去适配通用的硬体，对于一些特定的、前沿的硬体，不会去专门适配，所以传统资料库用户无法享受新硬体的红利。
而云原生资料库的架构可以重复享受硬体变革带来的红利，从而实现更强的性能。
3）更快速的迭代，让资料库更安全稳定
云原生资料库可以做到以周，甚至以天为单位来迭代资料库，这是传统的资料库不可能做到的。当系统出现问题时，云原生资料库可以快速进行升级，而传统资料库升级的周期通常是年，级别是出现了非常严重的漏洞，升级的周期也是以月为单位来计算的。
4）无需关注部署、运维等，全力专注业务开发
现在是一个快速创新的时代，每家企业都希望将重要的资源聚焦在自己的核心业务开发上。使用云原生资料库，让企业不再需要关注资料库的部署与运维，开箱即用，全力专注在自己的业务开发和用户价值上。
对于关系型资料库和非关系型资料库的区别就先介绍这么多，如果还有更多想知道的，欢迎留言提问。觉得云原生资料库不错的，也可以试用一下，也许你会爱上它。
相信大家在二级资料库考试的时候都做过这么一道题，关系型资料库中的关系是什么意思？答案是:数据模型符合满足一定条件的二维表格式，即是这张二维表中的行都是一个个元素，而列是一个个的属性，这种结构化的数据通过结构化的查询语言(SQL)可以以不同的方式进行存取！
所以说，SQL的定义和执行就代表著关系型资料库结构的数据存取，从where，groupby，order等命令，sum，count等函数就能一目了然的知道，关系型资料库可以通过栏位方便的筛选，分组，统计和运算，并且性能十分高效！
总结来说，关系型资料库不仅维护著一张二维表中行和列的关系，还维护著多张表中一对多，多对多的关系，并能通过SQL处理这种关系进行存取，还提供事务支持！
而非关系型资料库是以key-value形式存储数据，可认为是只有一个主键(key)，加一个属性(value)构成的二维表，其value中的属性之间的关系无法体现，很难通过其中的某个属性进行统计，分组等关系型资料库中的常规操作！
非关系型资料库更容易维护与扩展，关系型资料库却因为分表分库等有一定难度！非关系型资料库不支持事务，只能使用别的方式支持数据一致性！
mongodb和redis比较的话，redis更适合用做缓存，消息队列等，而mongodb适用于文档结构(json等)等的大容量数据存取！
关系型资料库和非关系型资料库在不同的场景都大有所为，可根据实际情况择优使用！
非关系型资料库和关系型资料库的区别就说到这，本人持续更新更多的技术分享，敬请关注！
关系型资料库在关系代数为基础建立起来的一种应用，经过严密的完备性证明。也就是说理论上关系型资料库可用于所有场景。当然这仅仅是理论上的说法，实际上，很多文档和图形数据很难采用统一的结构，而且这些数据通常都是海量的。为了提高这些数据的处理效率，人们针对不同的场景设计了不同的演算法，这就是非关系型资料库。值得注意的是非关系型资料库中保留了关系型资料库的特征，是对关系型资料库应用的一种扩展。NoSQL=Not Only SQL，不仅仅是SQL。
关系型资料库概要只要是每行的列都相同的表格都是关系型数据表。这叫第一范型。每行数据都是唯一的关系表叫第二范型。每行数据唯一且能由特定栏位确定的关系表叫第三范式，这些特定的栏位被称为主键。通常所说的资料库都满足第三范型，也就是可用主键进行查询。关系型资料库有基本的四则运算可以增减列或增减行:选择，投影，并，交。SQL就是根据这些规则设计出来的。
非关系型资料库非关系型资料库是根据特定的应用场景设计出来的，没有明确的分类标准，但根据应用场景大致可分为:键值存储，列存储，文档型和图型等几类。题主所说的Redis是键值存储型的，它不关心文档的内容，用哈希表存储了文档的特征属性，方便快速查找文档，多用于文件管理。MongoDb是文档型资料库，管理结构化或者半结构化的格式文档，可对文档内容进行高速地全文检索，也可以建立复杂的文档分类结构，是键值存储的升级版。至于如何选择，主要看需求，不需要检索内容时可使用Redis，轻便易安装。反之，用MongoDb功能强大。
关系型资料库是一种基本的资料库，非关系型资料库是关系型资料库的扩展应用。我个人很讨厌非关系型资料库这个叫法，它容易让人产生误解，以为NoSQL=No SQL。实际上，还有很多使用其他原理的资料库，比如，在人工智慧领域用一定应用的逻辑型资料库。这类资料库比较小众鲜为人知，称它们为非关系型资料库比较贴切。
欢迎关注我，一个程序员老司机，和你分享编程、运营、需求等等经验和趣事。
作为一个多年的程序员，两种资料库都使用过现在将自己的一些感受和你分享一下。
最大的区别
两种资料库的最大区别在于存储方式，关系资料库是将关系存储到资料库里面，什么关系呢？就是一对一、一对多和多对多关系，这样存储进去之后就能够通过sql命令查询到符合客观需求的数据，但是将关系存储进行查询时，有时需要关联很多个数据表才能够得到需要的数据，于是就诞生的分关系资料库，也就是nosql资料库。
两种常见的非关系资料库
一种是redis资料库，这种资料库主要做为缓存使用，它一般配合关系资料库一起用，也就是先从关系资料库获取或者计算数据，然后保存到redis资料库里面，而mongodb资料库除了具备redis的特点，也具备关系资料库的特点，所以一般业务数据还是用它来保存。
那为什么不用mongodb来代替redis因为redis非常小巧和专业,已经将缓存做到了极致。
我们首先来说一下关系型和非关系型资料库的区别，然后再说mongodb和redis。
关系型资料库，顾名思义就是说里边存储的数据都是关系，就是数学里说的元组。每个元素都有对应的另一个元素存在。在这种资料库的中，数据是用二维表来表示的，而表之间是可以有关系的，比如员工表和部门表，每个员工都属于某一部门，这种关系在关系型资料库是用外键来表示的，员工表中存了部门的ID，那么在查询的时候就可以通过这种关系，把员工和部门的信息一同查出来，可以使用SQL的join子句。代表性的资料库有MySQL, Oracle和PostgreSQL。
非关系型资料库中数据的表示并不是关系的，有这么几种类型，Document类型，以MongoDB为代表，一种是Key-Value类型的，以Redis为代表，还有一种是BigTable类型的，以cassandra为代表。每种都有不同的优势和功能特性，不过总体上非关系型资料库的出现是为了更好的适应分散式系统架构和提升性能。关系型资料库的Join是非常耗时的一个操作，在大量数据的前提下，性能牺牲的比较多。而非关系型资料库的设计是denormalized，即通过定义重复的数据来消除join，例如员工和部门，员工数据中会包括部门的相关数据，比如名称，负责人等。这样做的代价就是每当部门数据有更新，员工数据也需要做同步的修改，可能会引起数据不一致。所以这两种资料库需要根据业务场景来做选择，是需要高并发，高性能，还是要方便数据的存储，数据是不是最适合用表的形式来存储等等。
再来说MongoDB和Redis。
这两种都是非关系型的资料库，MongoDB是document类型的，它的存储格式是bson，是带有数据类型的json，非常适合给web前端提供数据。MongoDB的数据是存储在硬碟上，所以会受到硬碟速度的制约。而redis是key-value形式存储的，体积小，且数据是存在内存中，极大的提高了性能，所以非常适合做缓存和一些临时数据的存储，如用于验证的token。
题主要先明白两种类型，
关系型就常见的oracle，MySQL，等等
非关系缓存中用的多，而且有点像精简版的关系型！
键值对形式或者文档形式存储！
非关系不支持SQL，不支持事务，不过速度快啊，性能好！
至于选择的Redis跟mongdb，要看场景进行选择了！
因为mongdb以文档形式存，最好在开发评论系统的时候使用，存json格式数据最为关键！
若有帮助，右上角，纯手打！个人经验总结！
关系型资料库遵循acid（原子性，一致性，隔离性，持久性），非关系型资料库只要遵循cap（一致性，可用性和分区容忍性），那么这些属性的差异也就决定了性能的快慢和建表的数据结构的类型，其中mongodb和redis都属于nosql，不过mongodb属于文档型资料库，redis属于内存资料库
推荐阅读：
