时间: 2020-10-02 文章来源: 洋蜜蜂Online Tutor
留学,辅导,补习,Online Tutor,SQL ,SQL 辅导,SQL tutor
洋蜜蜂Online Tutor
关于SQL的问题
SQL一直是学生关注的问题之一，我们应该先了解SQL才能更好的掌握它，本文洋蜜蜂将告诉你一些关于SQL的知识，让你更全面的了解SQL！
关系数据库系统（RDBMS）非常重视数据的一致性和对正式数据库架构的遵从性。除非新数据或现有数据的修改满足该模式在数据类型，引用完整性等方面表示的约束，否则不接受这些数据。RDBMS协调其事务的方式可确保整个数据库始终保持一致，已知的ACID属性：原子性，一致性，隔离性和耐久性。一致性通常是理想的属性；通常，既不希望错误的数据进入系统，也不希望中途中止汇款，而只更新两个帐户之一。
但是，有时对一致性的关注可能会成为负担，因为它会引起（有时是不必要的）开销，并妨碍可伸缩性和灵活性。当对中小型数据集执行密集的读/写操作或执行较大的批处理过程时，RDBMS处于最佳状态，但同时事务的数量有限。随着数据量或并行事务数量的增加，可以通过垂直扩展（也称为扩展）（即通过扩展数据库服务器的存储容量和/或CPU功能）来增加容量。但是，很明显，存在硬件引起的垂直缩放限制。
因此，需要通过水平扩展（也称为向外扩展）来实现进一步的容量增加，并且将多个DBMS服务器布置在一个群集中。群集中的各个节点可以彼此平衡工作量，并且可以通过将节点添加到群集中而不是扩展单个节点的容量来实现扩展。这样的集群体系结构是应付诸如 大数据 （分析）， 云计算 和各种响应式Web应用程序等最新发展的巨大需求的必要先决条件。它提供了必要的性能，这是单个服务器无法实现的，但也保证了可用性，数据可以在多个节点上复制，如果一个节点发生故障，其他节点可以接管邻居的工作量。
但是，RDBMS不能很好地进行水平扩展。随着节点数量的增加，他们的事务管理方法以及始终保持数据一致性的要求引起了巨大的协调开销。此外，丰富的查询功能在许多 大数据 设置中可能是过大的，在这些设置中，应用程序仅需要高容量来“放入”和“获取”数据项，而不需要复杂的数据相互关系或选择标准。同样， 大数据 设置通常集中于半结构化数据或结构非常不稳定的数据（例如，有关传感器数据，图像，音频数据等），在这些数据中，RDBMS的刚性数据库架构会导致灵活性不足。
这些都不意味着关系数据库将很快过时。但是，“一刀切”的时代似乎已经结束了，在几乎所有数据和处理环境中都使用了RDBMS。在存储中型高度结构化数据量时，RDBMS仍然是必经之路，重点是一致性和广泛的查询功能。在海量数据，灵活的数据结构，可伸缩性和可用性更为重要的地方，可能需要使用其他系统。这种需求导致No sql数据库 的出现。
No SQL 运动的兴起
在过去的十年中，“ No SQL ”一词已经变得越来越繁琐，因此这个名字现在涉及许多含义和系统。现代的No SQL 运动描述了以表格关系以外的其他格式存储和处理数据的数据库，即非关系数据库。该运动应该更恰当地称为NoREL，尤其是因为其中一些非关系数据库实际上提供了接近 SQL 的查询语言功能。由于这些原因，人们已经将No SQL 运动的本义更改为“不仅是 SQL ”或“不是关系”而不是“不是 SQL ”的代表。
是什么使No sql数据库 与早在1970年代就已经存在的其他旧式非关系型系统不同？对非关系数据库系统的重新关注源于2000年代初的Web 2.0公司。在此期间，新兴的网络公司，例如Facebook，Google和Amazon，正越来越多地面临大量要处理的数据，通常在时间敏感的约束下。例如，考虑一下即时Google搜索查询，或者成千上万的用户同时访问Amazon产品页面或Facebook个人资料。
通常根植于开源社区，为满足这些要求而开发的系统的特性非常多样化。但是，它们的共同点是它们试图至少在某种程度上避免RDBMS在这方面的缺点。许多目标旨在实现近乎线性的水平可伸缩性，这是通过出于性能（并行性和负载平衡）和可用性（复制和故障转移管理）的目的在数据库节点群集上分布数据来实现的。作为回报，通常会牺牲一定程度的数据一致性。在这方面经常使用的术语是最终的一致性 ; 每次交易后，该数据以及同一数据项的各个副本将在时间上保持一致，但不能保证连续的一致性。
关系数据模型用于其他建模范例，这些范例通常不那么僵化，并且能够更好地应对快速发展的数据结构。通常，API（应用程序编程接口）和/或查询机制比关系设置要简单得多。比较框提供了No sql数据库 与关系系统的典型 特征 的更详细比较。请注意，存在不同类别的No sql数据库 ，甚至单个类别的成员也可能非常不同。没有一个No SQL 系统会显示所有这些属性。
比较盒
关系数据库
No sql数据库
数据范式
关系表
基于键值（元组），基于
文档，基于列，基于图的
XML，基于对象的
其他： 时间序列 ，概率等。
分配
单节点和分布式
主要分布
可扩展性
垂直缩放，难以水平缩放
易于水平扩展，易于数据复制
开放性
封闭和开源
主要是开源
模式角色
模式驱动
主要是无模式或灵活模式
查询语言
SQL 作为查询语言
没有或简单的查询工具，或专用语言
交易机制
酸：原子性，一致性，隔离性，耐久性
BASE：基本可用，软状态，最终一致
功能集
许多功能（触发，视图，存储过程等）
简单的API
数据量
能够处理正常大小的数据集
能够处理大量数据和/或很高频率的读/写请求
No sql数据库 与关系数据库的 特征 。
但是，我们注意到，No SQL 数据存储层的爆炸性增长应该考虑到它们的局限性。大多数No SQL 实现尚未在该领域证明其真正价值（大多数还处于开发阶段）。大多数实现都牺牲了ACID的关注点，以求最终保持一致，而缺乏关系支持使得表达某些查询或聚合特别困难，因为可能提供map-reduce接口，但更难以学习和使用。
结合RDBMS确实提供了对事务性，持久性和可管理性的强大支持这一事实，相当多的No SQL 早期采用者面临一些惨痛的教训。例如，参见FreeBSD维护者，他们反对MongoDB缺乏磁盘上的一致性支持[1]，Digg从 MySQL 切换到No SQL Cassandra数据库后也陷入困境[2]，而Twitter也面临类似的问题（最终也坚持了一个 MySQL 集群持续了一段时间[3]，或者是HealthCare.gov的惨败，IT团队在那里还使用了不合适的No sql数据库 [4]。。将RDBMS和No sql数据库 之间的选择减少到一方面是在一致性和完整性之间，另一方面是在可伸缩性和灵活性之间进行选择，将过于简化。No SQL 系统的市场太多样化了。不过，在决定采用No SQL 路由时，这种权衡通常会发挥作用。我们看到许多No SQL 供应商再次将重点放在鲁棒性和持久性上。我们还观察到传统RDBMS供应商实现的功能，这些功能使您可以在传统RDBMS内构建无模式，可扩展的数据存储，能够存储嵌套的半结构化文档，因为这似乎仍然是大多数No sql数据库 （尤其是那些No sql数据库 ）的真正卖点。在文档存储类别中。
预计未来的趋势将继续朝着采用这种“混合系统”的方向发展，除了需要特殊的利基数据库管理系统的用例之外。在这些情况下，No SQL 运动正确地告诉用户，一种尺寸适合关系系统的所有思维方式不再适用，应通过找到适合该工作的工具来代替。例如，图数据库是作为“超关系”数据库出现的，它使关系成为头等公民，而他们自己旁边是记录自己，而不是完全放弃它们。图形数据库以一种简单明了的方式表达复杂的查询，特别是在其中一个对象必须处理对象之间的许多嵌套或层次关系的情况下。下表总结了传统RDBMS，No SQL DBMS和New SQL DBMS之间的区别，从而总结了本文。
传统 SQL RDBMS
No sql数据库
混合系统“ New SQL ”
关系型
是
没有
是
的 SQL
是
否，虽然可以使用自己的查询语言
是
列存储
没有
是
是
可扩展性
有限
是
是
一致性模型
强大
最终保持一致，尽管为加强一致性做出了一些努力
在大多数情况下非常一致
BASE（基本可用，软状态并最终一致）
没有
是
没有
处理大（大）数据量
没有
是
是
无模式
没有
是
否，虽然可以存储和查询自由结构的 字段
海外留学学不会？洋蜜蜂在线来帮你。专业在线辅导：数学Mathematics、物理physics、化学chemistry、生物biological sciences、地球科学earth scaiences、计算机科学computer sciences、医学medicine、工程学Engineering、会计Accounting、统计学statistics、精算科学Actuarial Science等涵盖大学90%以上科目均有专业SQLTutor给您在线辅导。
