关于 NoSQL 数据库你需要知道的一切
指数
什么是 NoSQL?
优点和缺点
NoSQL 数据库的类型
你好,DEV!好久不见了,我终于找到了一篇经过大量研究的文章,因为我觉得这里的答案对我来说还不够。
我建议您首先查看我撰写的有关关系数据库的这篇文章,以便更容易理解这篇文章。
指数
什么是 NoSQL?
定义
关系数据库是在瀑布模型非常流行的时候创建的,但它们的设计目的并不是应对现代应用程序的规模和灵活性,也不是利用当今可用的商品存储和处理能力。
NoSQL 是 90 年代末为解决这些问题而创建的一种数据库类型,之所以这样称呼是因为它们不使用 SQL(但如今,由于一些管理系统实现了查询语言,它们被称为“非关系型数据库”)。NoSQL 数据库主要解决了以下几个方面:非关系型、分布式、开源和水平可扩展。
值得一提的是,如今关系型数据库已经得到了显著的改进,解决了它们在处理当今技术时遇到的大多数问题。NoSQL 数据库是另一种存储数据的方式,但并不一定比关系型数据库更好。两者都旨在解决不同类型的需求。
特征
- 分布式计算系统。
- 更高的可扩展性。
- 降低成本。
- 灵活的模式设计。
- 处理非结构化和半结构化数据。
- 没有复杂的关系。
- 开源。
术语
- 节点:提供某种服务、本地存储以及对更大的分布式系统或文件存储的访问的联网计算机。
- 集群:节点的集合。
- 分片(或水平分区):根据某些字段的值对数据库进行分区。
- 复制:部分数据将写入多个节点,以防其中一个节点发生故障(确保可用性)。
- ACID:原子性、一致性、隔离性、持久性。是数据库事务的一组属性,旨在即使在发生错误、电源故障等情况下也能保证有效性。
- BASE:基本上可用(不是 24/7 可用性)、软状态(数据库可能不一致)和最终一致(最终将保持一致)。
优点和缺点
优势
- 弹性可扩展性:这些数据库设计用于低成本商品硬件。
- 大数据应用:NoSQL 数据库可以轻松处理海量数据。
- 经济实惠:关系型数据库需要安装昂贵的存储系统和专有服务器,而随着交易量和数据量的增加,NoSQL 数据库可以轻松安装在廉价的商用硬件集群中。这意味着您可以以更低的成本处理和存储更多数据。
- 动态模式:NoSQL 数据库无需模式即可开始处理数据。在关系数据库中,您必须先定义模式,这使得操作更加困难,因为每次需求发生变化时都必须更改模式。注意:这意味着所有数据质量控制都必须在应用程序上进行。注意 2:没有模式并非每个 NoSQL 数据库都具备的特性,如果我们没有正确组织数据,这也可能是一个缺点。
- 自动分片:关系型数据库可以垂直扩展,这意味着由于磁盘空间的限制,许多数据库通常分布在多台服务器上。NoSQL 数据库通常支持自动分片,这意味着它们可以原生地自动将数据分布到任意数量的服务器上,而无需应用程序了解服务器池的组成情况。
- 复制:大多数 NoSQL 数据库还支持自动数据库复制,以便在发生中断或计划维护事件时保持可用性。更复杂的 NoSQL 数据库具有完全的自我修复功能,提供自动故障转移和恢复功能,以及将数据库分布到多个地理区域的能力,以抵御区域性故障并实现数据本地化。
- 集成缓存:许多 NoSQL 技术都具有出色的集成缓存功能,尽可能将常用数据保存在系统内存中,无需单独的缓存层。
缺点
- NoSQL 数据库不具备关系数据库所具有的可靠性功能(基本上不支持 ACID)。
- 这也意味着 NoSQL 数据库在性能和可扩展性方面具有一致性。
- 为了支持 ACID,开发人员必须实现自己的代码,这使得他们的系统更加复杂。
- 这可能会减少提交交易的安全应用程序的数量,例如银行系统。
- NoSQL 与 SQL 完全不兼容。
- 注意:一些 NoSQL 管理系统确实使用结构化查询语言。
- 这意味着您将需要手动查询语言,这会使事情变得更慢、更复杂。
- 与关系数据库相比,NoSQL 非常新,这意味着它的稳定性要差得多,功能也可能少得多。
NoSQL 数据库的类型
键值
键值存储是最简单的 NoSQL 数据库。数据库中的每个项目都以属性名称(或“键”)及其值的形式存储,类似于字典。
特征
- 可扩展性:大量数据和用户。
- 速度:大量查询。
- 数据模型:键值对。
- 一致性。
- 交易。
- 查询能力。
- 可扩展性。
运营
- get(key):获取给定键的值。
- put(key, value):根据键创建/更新值。
- delete(key):根据键删除一个值。
- 执行(键):对某个值调用操作。
限制
- 多数据之间没有关系。
- 多操作事务:如果您存储了多个密钥,并且保存其中一个密钥失败,则无法回滚其余操作。
- 通过“值”查询数据:根据键值对的“值”部分中找到的一些信息搜索“键”。
- 按组操作:由于操作仅限于一次一个键,因此无法同时运行多个键。
现实生活中的例子
Key-Value 最适合存储用户资料:
- 用户 ID,用户名。
- 附加属性/偏好:
- 语言
- 国家
- 时区
- 用户收藏
- 等等
键值数据库
文档
文档存储将每个键与一个称为文档的复杂数据结构配对,该结构可以包含许多不同的键值对、键数组对,甚至嵌套文档。文档被视为完整文档,避免将文档拆分成其组成元素的键/值对。
特征
- 可扩展性:适用于更复杂的对象。
- 数据模型:文档集合。
- 类似于 JSON 和 XML。
- 实现ACID事务并适应RDBMS特性。
- 允许根据文档的主要标识符和属性对文档进行索引。
- 支持查询事务(在一定程度上)。
- 设计模式允许在单个操作中检索信息。
- 避免在应用程序内执行连接。
运营
- 搜索依据:
- 场地
- 范围
- 正则表达式
- 查询:可以包含 Javascript 函数。
- 索引:可以在任何字段上进行。
- XML文档形成了第一个文档数据库。
- XML 有多种标准和工具来协助创作、验证、搜索和转换 XML 文档。
- XPath:从 XML 文档中检索特定元素的语法。
- XQuery:用于查询XML文档的查询语言,又被称为“XML的SQL”。
- XML 模式:文档模板,解释在指定类别的 XML 文档中可能存在哪些所有元素,以验证文档的正确性。
- XSLT:将 XML 文档转换为其他格式(如非 XML 格式,如 HTML)的语言。
- 著名的 XML 数据库:eXist(开源)和 MarkLogic(商业)。
- JSON文档数据库要求数据以JSON格式存储。
- 类似于 RDBMS 中的行。
- 包含一个或多个键值对、嵌套文档和数组。数组可能包含复杂的层次结构。
- 集合(数据存储桶)是一组具有某些共同目标的文档(类似于 RDBMS 中的表)。
- 尽管是首选,但集合中的文档不必是同一类型。
- JSON 数据库:
- MongoDB
- CouchDB
- OrientDB
- 文档数据库。
- 与 RDBMS 相比,确定性较差。
- 由要执行的查询的性质驱动,而在 RDBMS 中,它由要存储的数据类型驱动。
限制
- 多个文档中的基本信息重复
- 使设计复杂化并导致不一致。
- 解决方案:使用文档标识符链接多个文档(类似于 RDBMS 中的外键)
现实生活中的例子
这里列出了一些现实生活中的案例。
文档数据库
图形
图谱存储是一种富有表现力的结构,由节点及其相互连接的关系组成,用于存储有关数据网络的信息,例如社交关系。它基于图的数学理论。
图表的组成部分
- 节点——实体的表示。
- 属性——有关节点的信息。
- 可以索引。
- 边——节点之间的关系。
- 可以索引。
- 单向或双向,不受边的限制。
根据图论,图的主要组成部分包括:
- 代表不同对象的顶点或节点。
- 建立这些对象之间连接性的边、关系或弧。
- 节点和关系都具有一些属性。
- 节点的属性与关系表/JSON文档的属性类似。
- 关系属性考虑关系的类型、强度或历史。
图论为
- 从图中添加/删除节点或关系
- 执行操作来追踪相邻节点。
核心规则- “无断开链接”:关系应始终具有起始节点和终止节点。删除节点时,必须同时删除其关联的关系。
类型
从高层次上讲,图形存储可分为两类:
1)图形数据库-(实时)
- 实时执行事务在线图形持久化。
- 类似于 RDBMS 领域的在线事务处理 (OLTP) 数据库。
2)图形计算引擎-(批处理模式)
- 按一系列步骤批量执行离线图形分析。
- 类似于联机分析处理(OLAP),用于批量分析数据,例如数据挖掘。
特征
- 适应数据的复杂性。
- 注重互联互通。
- 许多查询语言。
操作
将取决于其查询语言。例如,Neoj4 使用Cypher 查询语言。
限制
- 缺乏高性能并发性:在许多情况下,图形数据库提供多个读取器和单个写入器类型的事务,这会阻碍它们的并发性和性能,从而在一定程度上限制线程并行性。
- 缺乏标准语言:缺乏完善且标准的声明式语言是当今的一个问题。Neo4j 正在提议使用 Cypher,而 Oracle 也正在开发一种语言。
- 缺乏并行性:一个重要的问题是图的分区存在问题。因此,大多数系统不提供针对非常大的图的无共享并行查询。因此,实现并行性本质上是一个问题。
现实生活中的例子
Graph Store 用于模拟各种不同的场景,例如:
- 建造太空火箭。
- 交通系统(公路和火车)。
- 供应链和物流。
- 病史。
- 欺诈检测。
- 网络和 IT 运营。
图形数据库
柱状
宽列/列式/列存储针对基于列族存储的大型数据集的查询进行了优化。列存储数据库使用称为键空间的概念。键空间有点像关系模型中的模式。键空间包含所有列族,列族包含行,行包含列。
列式数据库与关系数据库在本质上有很大不同:表不是由一组行或元组组成,每个行或元组都有值,而是由一组列组成,每个列可能包含或不包含特定行键的值。
特征
- 压缩:列存储在数据压缩和/或分区方面非常有效。
- 聚合查询:由于其结构,列式数据库在聚合查询(例如 SUM、COUNT、AVG 等)中表现特别好。
- 可扩展性:列式数据库具有极高的可扩展性。它们非常适合大规模并行处理,这种处理需要将数据分布在大型机器集群(通常是数千台机器)上。
- 加载和查询速度快:列式存储的加载速度极快。十亿行的表可以在几秒钟内加载完成。
这些只是使列式数据库成为处理大数据的组织的热门选择的一些优势。
操作
操作和某些功能根据您使用的管理系统而有很大差异。
限制
- 增量数据加载:写入数据所需的时间比读取数据所需的时间更多。联机事务处理 (OLTP) 使用情况。
- 仅针对几行的查询:读取特定数据所花费的时间比预期的多。
现实生活中的例子
- 超市蔬菜的列族。
- 为客户打造的列族。
- 为用户提供的列族。
列式数据库
CAP定理
理解 NoSQL 数据库的局限性非常重要。NoSQL 无法同时提供一致性和高可用性。这一点 Eric Brewer 在 CAP 定理中首次提出。
CAP 定理或 Eric Brewers 定理指出,我们只能实现数据库三个保证中的最多两个:一致性、可用性和分区容错性。
- 一致性:每次读取都会收到最近的写入或错误。
- 可用性:每个请求都会收到一个(非错误)响应 - 但不能保证它包含最新的写入。
- 分区容错:即使数据中心发生网络中断,某些计算机无法访问,系统仍会继续运行。
没有系统能够提供超过 2 个保证。对于分布式系统来说,网络分区是必须的,因此需要在一致性和可用性之间进行权衡。
如果您想了解有关 CAP 的更多信息,请查看此链接和此链接。
NoSQL 与关系数据库的比较
需要注意的是,此比较是在数据库层面进行的,并不包含任何同时实现这两种方法的管理系统。数据库管理系统拥有自己的技术来解决此类问题,并提高性能和可靠性。
- 关系数据库:垂直扩展。
- 架构设计在单机上运行良好。
- 要处理更大量的操作,就需要用更快的处理器或更多的内存来升级机器。
- 由于您需要更多计算机来处理更多数据,因此规模/扩展级别存在限制。
- NoSQL 数据库:水平扩展。
- NoSQL 数据库旨在在相对低规格的服务器集群上运行。
- 为了处理更多数据,请向集群添加更多服务器。
- 即使使用低成本硬件,也可以校准为全速运行。
- 相对便宜的方法来处理增加的操作数量和数据的大小。
- 关系数据库:维护高端 RDBMS 系统成本高昂,并且需要训练有素的数据库管理人员。
- NoSQL 数据库:只需极少的管理,并且支持许多功能,从而减少了管理和调优的需求。这包括自动修复、更便捷的数据分发和更简单的数据模型。
- 关系数据库:刚性数据模型。
- RDBMS 需要按照定义的数据模型采用结构化格式的数据。
- 由于变更管理在 SQL 中是一个大问题,并且严重依赖主键/外键,因此临时数据插入变得更加困难。
注:值得一提的是,关系数据库在处理非结构化或半结构化数据方面已经取得了长足的进步,其中 PostgreSQL 的可索引二进制 JSONB 数据类型尤为出色。如果您有混合数据,那么将非结构化数据适配到关系上下文中比尝试将关系数据适配到 NoSQL 上下文中要容易得多,也更安全。
- NoSQL 数据库:没有模式/数据模型。
- NoSQL 数据库没有模式,因此即使没有任何预定义的模式,也可以轻松地将数据插入数据库。
- 格式或数据模型可以随时更改,而不会中断应用程序。
- 关系数据库:典型的 RDBMS 数据库中的缓存需要单独的基础设施。
- NoSQL数据库:NoSQL数据库支持在系统内存中缓存,因此可以提高数据输出性能。
选择特定的数据库
现在我们已经了解了不同类型的 NoSQL,您现在应该知道 NoSQL 数据库并不相似,并且不是用来解决相同的问题的。
了解哪种数据库适合于特定场景非常重要。选择 NoSQL 数据库时需要考虑的参数包括:
- 数据库功能
- 表现
- 基于上下文的标准
对它们进行分组的最佳方法是比较它们的特征,以便为我们面临的问题选择正确的方法。
功能比较
可扩展性
- 并非所有 NoSQL 数据库都承诺同等程度的水平可扩展性。
- HBase 和 Hypertable 具有优势,而 Redis、MongoDB 和 Couchbase Server 则落后。
- 当数据大小超过几 PB 时,差异会变得更加明显。
事务完整性和一致性
- 事务完整性仅在数据被修改、更新、创建和删除时适用。
- 与纯数据仓库和挖掘环境无关,因为数据只写入一次,读取多次。
- 例如网络流量日志、社交网络状态更新、股票市场数据和游戏比分。
- 如果更新很常见并且操作范围需要更新的完整性,那么 RDBMS 最适合。
- 如果单个项目级别的原子性足够的话,列系列数据库(HBase 和 Hypertable)和文档数据库(MongoDB)非常适合。
数据建模
关系数据库管理系统 (RBDMS) 提供了一种一致且有组织的数据建模方式,并采用标准化的实现。NoSQL 世界不提供标准化和定义明确的数据模型,因为它们不一定解决相同的问题或具有相同的架构。
MongoDB 逐渐采用了一些 RDBMS 概念,例如:
- 类似 SQL 的查询。
- 基本的关系引用。
- 数据库对象(受标准表和基于列的模型启发)。
查询支持:
轻松高效地从任何数据库查询数据被认为是一个有待解决的有趣难题。凭借标准化的语法和语义,关系数据库管理系统 (RDBMS) 依靠 SQL 支持轻松访问数据。
在 NoSQL 中:
- MongoDB 和 CouchDB(文档数据库)具有与 RDBMS 同样强大的查询功能。
- Redis(键值数据库)本身带有查询其存储的数据结构。
- 在列式数据库下,HBase 具有一点点查询能力。
访问和接口可用性
- MongoDB 凭借其用于接口和交互的主流库驱动程序在该领域占据主导地位。
- CouchDB 还提供一些可用的驱动程序以及 RESTful HTTP 接口。
- 大多数主流语言的语言绑定可用于 Redis、Membase、Riak、HBase、Hypertable、Cassandra 和 Voldemort 等少数语言。
NoSQL 优于关系型数据库
如果出现以下情况,则应该选择 NoSQL 数据库而不是关系数据库:
- 您拥有非结构化或半结构化数据,或非结构化和关系数据的混合。
- 您需要在同时加载大量数据的同时支持多个查询。
- 您需要将部分数据重复用于多个项目。
- 您拥有快速变化的模式或需要获取新的信息源,而不需要六个月(或更长)的开发周期。
- 您需要整合多种不同的数据类型和来源,而不必被迫建模数据或创建模式。
多语言持久化
通晓多种语言:了解或使用多种语言。
多语言编程使我们能够为相应的任务选择合适的语言。单一数据库并不适合所有规模,因此,采用多个数据库是明智之举。对多种数据库产品和方法的了解和使用现在被广泛称为多语言持久化。
基准数据库
基准测试使我们能够深入了解不同 NoSQL 产品的性能。
- Yahoo! 云服务基准测试是用于比较 NoSQL 产品的著名基准测试基础设施之一
- 东京内阁基准
- Redis 的速度有多快
如何设计NoSQL数据库
NoSQL 数据库的设计取决于数据库的类型。
-
这是用于建模文档数据库的Microsoft 官方 Youtube 帐户视频。
-
这是亚马逊键值数据库DynamoDB的官方文档。
- 我听说,如果将“分区键”替换为“分片键”,将“排序键”替换为“索引”,这对 Cassandra 也很有用。它们也能转换为 MongoDB 格式。
-
您还可以查看这个有趣的帖子。
重要链接
- NoSQL-database:一个有点过时的网站,包含大量有关 NoSQL 数据库的信息。
- MongoDB 官方文档:开始使用最著名的文档数据库。
- 本文讲解了如何借助 Mongoose 在 Node 中轻松使用 MongoDB:
- Freecodecamp:它有一个名为“Apis and Microservices”的证书,其中他们教你如何在 Node 中使用 MongoDB 和 Mongoose。
- 关于 NoSQL 的免费 Udemy 课程。
- 许多 NoSQL 数据库的比较。
- 而且,我发现了一篇关于 MongoDB 的有争议的博客文章,我想你可能会感兴趣。
来源
- 我工作中的一次培训。
- http://nosql-database.org
- MongoDB:NoSQL 解释。
- https://blog.pandorafms.org/es/bases-de-datos-nosql/
- https://blogs.oracle.com/spain/qu-es-una-base-de-datos-nosql
- https://www.hadoop360.datasciencecentral.com/blog/advantages-and-disadvantages-of-nosql-databases-what-you-should-k
- https://mapr.com/blog/data-modeling-guidelines-nosql-json-document-databases/
- NoSQL 的局限性。
- 中等:SQL 和 NoSQL 之间的差异。
- 维基百科:ACID。
- 维基百科:CAP 定理。
- 维基百科:多语言持久性。
- https://howtodoinjava.com/hadoop/brewers-cap-theorem-in-simple-words/
- https://cloudxlab.com/assessment/slide/11/nosql/345/nosql-cap-theorem
- https://database.guide/what-is-a-column-store-database/
- https://www.flydata.com/blog/whats-unique-about-a-columnar-database/
- https://mapr.com/blog/data-modeling-guidelines-nosql-json-document-databases/
- https://neo4j.com/blog/why-graph-databases-are-the-future/
- https://www.quora.com/What-is-a-limitation-of-graph-database-Is-there-any-situation-when-the-performance-of-the-graph-database-degrades
- https://www.slideshare.net/blimpyacht/polyglot-persistence-52711581
- 傻瓜版 NoSQL。
- 企业 NoSQL 傻瓜指南,MarkLogic 特别版:输入链接即可免费获取此电子书!
最后的话
我希望您觉得这篇文章有用,如果您发现一些错误并希望我纠正它,请随时在评论中告诉我!
感谢 Dian Fay 和 Slavius 在评论中做出的更正!
感谢您的阅读。别忘了在 dev.to 和 Twitter 上关注我!
文章来源:https://dev.to/lmolivera/everything-you-need-to-know-about-nosql-databases-3o3h