SQL vs. NoSQL –你的下一个项目应使用哪个（） _SQL和NoSQL

本文概述

数据库结构
NoSQL
缩放比例
数据库实例

最常见的问题之一–我应该使用哪个数据库…
SQL代表结构化查询语言。它最初是由IBM研究人员小组于1970年代开发的, 另一方面, NoSQL数据库于1998年由Carlo Strozzi首次使用。
这两个数据库(DB)系统之间最常见的区别是SQL是关系型的, 而NoSQL是非关系型的。
让我们深入研究这两个数据库, 以便在下次考虑为项目使用数据库时更好地告知你的决定。
数据库结构让我们谈谈结构化。
SQL
SQL数据库具有确定的架构结构。
模式包含表, 并且每个表包含一定数量的列。这意味着用户不能在表中指定的列数之外更新表。当你需要维护数据完整性并确保保存到数据库中的数据种类时, 这特别有用。
SQL数据库中的每个表都可以关联。即, 你可以在表之间建立关系。这些关系可以是一对多, 多对多或一对一。你实现的关系类型取决于你的要求。
例如, 让我们考虑一下假设情况；我们有一家拥有用户的公司, 用户可以订购产品。然后, 我们可以决定用户可以创建多个订单, 但是每个订单只能由一个用户创建。这将是一对多关系, 即一个用户要执行许多订单。因此, 两个表的表结构将类似于以下内容。
在我们的数据库中, 我们可以有一个用户表, 其结构如下：

users_table----------------------------------------------------id|name|email-----------------------------------------------------1Idris[email protected]

另外, 我们可以有一个订单表

orders_table---------------------------------------------------------------------------------id|user_id|order_number---------------------------------------------------------------------------------1120000001

订单表上的user_id可以轻松地将订单表上的每个订单映射到其所属的用户。在一对一关系的情况下, 如果我们决定通过用户的相关订单ID获取用户, 则可以在users_table上也有order_id。
对于” 多对多” 情况, 通常涉及一个额外的表, 称为” 数据透视表” 。这使多个记录可以相互映射。使用以上实例。我们会有,

users_table-------------------------------------------------------------------------------------id|name|email-------------------------------------------------------------------------------------1Idris[email protected]

订单表将是

orders_table---------------------------------------------------------id|order_number---------------------------------------------------------12000001

然后数据透视表将两个ID都作为外键。

users_orders_table------------------------------------------------------------------------------id|order_id|user_id------------------------------------------------------------------------------111

根据SQL提供的这种结构, 你可以轻松地在表之间编写Joins, 以提供来自一个查询中连接在一起的不同表的数据。
NoSQL NoSQL数据库的构建比SQL DB更加灵活, 还可以包含大量数据。
在NoSQL DB中, 没有预定义的架构或表。有集合, 在每个集合中都有文档。这使你能够以不同的形式保存数据。你可以选择在一个集合中具有多个具有不同字段的不同文档。也可以手动建立集合之间的关系。但是, 它们不适合用于此目的。相反, 你可以将单个查询所需的所有内容保存到同一Collection中。
如果你是一名SQL人员, 则可以将Collections视为表, 将Documents视为具有表的行。但是, 可以在表中添加的数据列没有限制。
回到我们先前定义的具有用户和订单的公司的假设实例。
用户集合可以定义为

{id: 1, name: 'idris', email: '[email protected]'}

订单集合可以定义为

{id: 1, order_number: 2000001, user_id:1}

不过, 在这种情况下, 我们希望避免手动加入两个收藏集(在这种情况下不应该)。我们可以将条目保存到获取最多阅读的集合中。我已决定(对于本示例)将是Orders集合。

{id:1, order_number:200001, user{id:1, name: 'idris', email:'[email protected]'}}

【SQL vs. NoSQL –你的下一个项目应使用哪个（）】在这种情况下, 我们不再需要从Users集合中读取数据, 而仅从Orders集合中读取数据, Orders Collection现在包含了我们需要的所有数据。
在此需要注意的关键事项：如果你要构建的应用程序执行读取操作而不是写入操作, 则NoSQL选项可能更适合你。因为你可以将所有数据保存在同一集合中, 并且可以轻松地从该源中读取数据, 以获取所有必需的数据。
但是, 对于需要如此大规模写入(每秒约10, 000次写入)的应用程序, 在需要将相同数据写入多个位置的NoSQL选项时, 不是一个好主意。在这种情况下, SQL选项可能更适合, 在这种情况下, 你对所有表都具有关系, 并且不必将相同的数据重复写入多个位置, 因此可以通过退出将一个位置的更新数据提供给其他表关系。当然, 这并不意味着每个数据库都无法处理规模。
缩放比例让我们探讨缩放的工作原理。
SQL
SQL DB不能水平扩展, 只能垂直扩展。这到底是什么意思？
水平扩展意味着将数据从一个DB拆分为多个数据库以减轻负载。但是, 由于SQL数据的严格性质, 因此无法在单独的DB上对其进行拆分。扩展SQL DB的适当方法是增加现有DB服务器的CPU, 内存和磁盘空间, 这就是垂直扩展它的意思。

文章图片

文章图片
NoSQL
NoSQL DB可以水平和垂直扩展。这是由于其数据存储的灵活性。因此, 与水平缩放一样, 这允许将其数据拆分到多个数据库中。如果需要, 它也可以垂直缩放。
这里需要注意的关键事项：在扩展方面, SQL和NoSQL数据库都可以有效地扩展。但是, 对于SQL DB, 垂直扩展可能是一个限制。单个数据库服务器将限制其可承载的计算能力。
在此还需要注意, 对于你将要构建的大多数应用程序来说, 可能不会达到服务器最大的计算能力, 但是记住这一点很有帮助。但是, 对于实施SQL的大型企业应用程序, 克服这种限制的一个流行选择是通过分片。
什么是分片？
分片是将大表分成小块的过程, 这些小块称为分片。可以通过对数据库进行水平分区来进行分片。请勿将其与” 水平和垂直缩放” 相混淆。水平分区是指将表的行存储在多个数据库节点中的过程。另一方面, 垂直分区需要将表的列保存在不同的节点上。这允许数据库有效地扩展并提高性能。
数据库实例 SQL

MySQL –一个非常流行的开源数据库。但是, 对于许多PHP开发人员来说, 很容易选择的数据库也可以与Node.js, C＃, C ++, Java, Perl, Ruby和Python一起使用。
MSSQL – Microsoft SQL提供了很多稳定性, 因为它的开发直接来自Microsoft, 它在灾难恢复方面也提供了一些支持。
MariaDB –它是由MySQL的制造商基于MySQL构建的, 旨在使MariaDB永久免费。
PostgresSQL –一个非常流行的开源数据库。以自己为世界上最先进的开源数据库而自豪
Oracle –通常针对Oracle企业解决方案量身定制, 但其免费版本有所限制。

NoSQL

MongoDB –可能是最著名的NoSQL DB, 在使用MERN堆栈(MongoDB, Express, React, Node)或MEAN堆栈(MongoDB, Express, Angular, Node)的应用程序开发人员中常见。
Firebase –于2011年推出, 于2014年被Google收购, 目前正被Web和移动应用程序开发人员广泛使用。
Apache Couch DB –基于文档的NoSQL DB, 将数据存储为JSON。
Redis：这是NoSQL DB, 可能最著名的原因是它用于存储具有可选生存时间的数据。它也以其速度而闻名。

总结
你可以使用SQL或NoSQL数据库创建任何类型的应用程序。这取决于你的要求。如果你正在考虑具有更多读取和更少写入的数据库, 那么NoSQL可能是一个不错的选择。但是, 如果你考虑使用写入次数多于读取次数构建应用程序, 则SQL可能是更好的解决方案。关于可伸缩性, 当你的应用程序扩展到非常大规模时, 你可能最终会同时使用两个数据库。