SQL 和 NoSQL 的区别
一、概念
SQL (Structured Query Language) 数据库&＃xff0c;指关系型数据库。主要代表&＃xff1a;SQL Server&＃xff0c;Oracle&＃xff0c;MySQL(开源)&＃xff0c;PostgreSQL(开源)。
NoSQL&＃xff08;Not Only SQL&＃xff09;泛指非关系型数据库。主要代表&＃xff1a;MongoDB&＃xff0c;Redis&＃xff0c;CouchDB。
二、区别
1、存储方式
SQL数据存在特定结构的表中&＃xff1b;而NoSQL则更加灵活和可扩展&＃xff0c;存储方式可以省是JSON文档、哈希表或者其他方式。SQL通常以数据库表形式存储数据。举个栗子&＃xff0c;存个学生借书数据&＃xff1a;
而NoSQL存储方式比较灵活&＃xff0c;比如使用类JSON文件存储上表中熊大的借阅数据&＃xff1a;
2、表/数据集合的数据的关系
在SQL中&＃xff0c;必须定义好表和字段结构后才能添加数据&＃xff0c;例如定义表的主键(primary key)&＃xff0c;索引(index),触发器(trigger),存储过程(stored procedure)等。
表结构可以在被定义之后更新&＃xff0c;但是如果有比较大的结构变更的话就会变得比较复杂。在NoSQL中&＃xff0c;数据可以在任何时候任何地方添加&＃xff0c;不需要先定义表。例如下面这段代码会自动创建一个新的"借阅表"数据集合&＃xff1a;
NoSQL也可以在数据集中建立索引。以MongoDB为例&＃xff0c;会自动在数据集合创建后创建唯一值_id字段&＃xff0c;这样的话就可以在数据集创建后增加索引。
从这点来看&＃xff0c;NoSQL可能更加适合初始化数据还不明确或者未定的项目中。
3、外部数据存储
SQL中如何需要增加外部关联数据的话&＃xff0c;规范化做法是在原表中增加一个外键&＃xff0c;关联外部数据表。例如需要在借阅表中增加审核人信息&＃xff0c;先建立一个审核人表&＃xff1a;
再在原来的借阅人表中增加审核人外键&＃xff1a;
这样如果我们需要更新审核人个人信息的时候只需要更新审核人表而不需要对借阅人表做更新。而
在NoSQL中除了这种规范化的外部数据表做法以外&＃xff0c;我们还能用如下的非规范化方式把外部数据直接放到原数据集中&＃xff0c;以提高查询效率。缺点也比较明显&＃xff0c;更新审核人数据的时候将会比较麻烦。
4、SQL中的JOIN查询
SQL中可以使用JOIN表链接方式将多个关系数据表中的数据用一条简单的查询语句查询出来。NoSQL暂未提供类似JOIN的查询方式对多个数据集中的数据做查询。所以大部分NoSQL使用非规范化的数据存储方式存储数据。
5、数据耦合性
SQL中不允许删除已经被使用的外部数据&＃xff0c;例如审核人表中的"熊三"已经被分配给了借阅人熊大&＃xff0c;那么在审核人表中将不允许删除熊三这条数据&＃xff0c;
以保证数据完整性。而NoSQL中则没有这种强耦合的概念&＃xff0c;可以随时删除任何数据。
6、事务
SQL中如果多张表数据需要同批次被更新&＃xff0c;即如果其中一张表更新失败的话其他表也不能更新成功。这种场景可以通过事务来控制&＃xff0c;可以在所有命令完成后再统一提交事务。
而NoSQL中没有事务这个概念&＃xff0c;每一个数据集的操作都是原子级的。
7、增删改查语法
8、查询性能
在相同水平的系统设计的前提下&＃xff0c;因为NoSQL中省略了JOIN查询的消耗&＃xff0c;故理论上性能上是优于SQL的。
三、补充
目前许多大型互联网项目都会选用MySQL&＃xff08;或任何关系型数据库&＃xff09; &＃43; NoSQL的组合方案。
关系型数据库适合存储结构化数据&＃xff0c;如用户的帐号、地址&＃xff1a;
1&＃xff09;这些数据通常需要做结构化查询&＃xff08;嗯&＃xff0c;好像是废话&＃xff09;&＃xff0c;比如join&＃xff0c;这时候&＃xff0c;关系型数据库就要胜出一筹
2&＃xff09;这些数据的规模、增长的速度通常是可以预期的
3&＃xff09;事务性、一致性
NoSQL适合存储非结构化数据&＃xff0c;如文章、评论&＃xff1a;
1&＃xff09;这些数据通常用于模糊处理&＃xff0c;如全文搜索、机器学习
2&＃xff09;这些数据是海量的&＃xff0c;而且增长的速度是难以预期的&＃xff0c;
3&＃xff09;根据数据的特点&＃xff0c;NoSQL数据库通常具有无限&＃xff08;至少接近&＃xff09;伸缩性
4&＃xff09;按key获取数据效率很高&＃xff0c;但是对join或其他结构化查询的支持就比较差
基于它们的适用范围不同&＃xff0c;目前主流架构才会采用组合方案&＃xff0c;一个也不能少。目前为止&＃xff0c;还没有出现一个能够通吃各种场景的数据库&＃xff0c;而且根据
CAP理论&＃xff0c;这样的数据库是不存在的。
京公网安备 11010802041100号