一文读懂NoSQL数据库

摘要:SQL数据库对数据类型和一致性有要求,NoSQL为了速度、灵活性和规模而放弃了这些要求。

在开发应用程序时,最基本的选择之一就是是否使用SQL或NoSQL数据库来存储数据。传统的SQL(即关系)数据库是几十年技术演进、良好实践和实际压力测试的产物。它们是为可靠的事务和特殊查询而设计的,是业务应用程序主要采用的方式。但他们也承受了一些限制,比如死板的计划,使他们不适合其他种类的应用。

NoSQL数据库是为了突破这些限制而产生的,NoSQL系统存储和管理数据的方式,使开发人员具有较高的操作速度和极大的灵活性。像谷歌、亚马逊、雅虎和Facebook这些公司的开发者,他们寻求更好的方法来存储内容或处理大型网站的数据。与SQL数据库不同,许多NoSQL数据库可以在数百或数千台服务器的水平上进行伸缩。

NoSQL vs. SQL

SQL和NoSQL之间的根本区别并不是那么复杂,对于如何存储和检索数据,都有不同的哲学。

对于SQL数据库,所有数据都有一个固有的结构。像Microsoft SQL Server、MySQL或Oracle数据库这样的传统数据库使用了schema,即明确的定义,如何将数据插入到数据库中。例如,表中给定的列只能限于整数,因此,此栏所记录的数据将具有高度的标准化。一个SQL数据库的刚性模式也使得对数据进行聚合变得相对容易,例如通过连接方式。

使用NoSQL,数据可以以无模式或自由格式存储,任何数据都可以存储在任何记录中。在NoSQL数据库中,你将找到四个用于存储数据的常用模型,这将导致4种常见的NoSQL系统:

文档数据库(如CouchDB,MongoDB),插入的数据以自由格式的JSON结构或“文档”形式存储,其中数据可以是任何从整数到字符串到自由格式文本的内容。没有必要指定文档将包含哪些字段。

键值存储(例如Redis,Riak),从简单的整数或字符串到复杂的JSON文档,在数据库中以键的方式访问自由格式的值。

列存储(如HBase,Cassandra),数据存储在列中,而不是传统的SQL系统中的行。可以根据需要对任意数量的列(以及不同类型的数据)进行分组或聚合,以进行查询或数据视图。

图数据库(例如Neo4j),数据以网络或实体的图形和它们的关系表示,图中的每个节点都是一个自由的数据块。

无模式数据存储在以下场景中是有用的:

希望快速访问数据,更关心访问速度和简单性,而不是可靠的事务或一致性。

正在存储大量的数据,并且不想将自己锁在一个模式中,因为稍后更改模式可能会比较缓慢和痛苦。

正在接收来自一个或多个源的非结构化数据,希望将数据保存在原始表单中,以获得最大的灵活性。

希望将数据存储在分层结构中,但希望这些层次结构由数据本身描述,而不是外部模式。NoSQL允许数据以随意的方式进行自我引用,这对于SQL数据库来说更加复杂。

查询NoSQL数据库

传统数据库使用的结构化查询语言提供了在存储和检索数据时与服务器通信的统一方法。SQL语法是高度标准化的,因此,虽然单个数据库可以以不同的方式处理某些操作(例如,window functions),但基础仍然是相同的。

相比之下,每个NoSQL数据库都有自己的查询和管理数据的语法。例如,CouchDB使用JSON形式的请求,通过HTTP发送,从其数据库创建或检索文档。MongoDB通过命令行接口或语言库向二进制协议发送JSON对象。

一些NoSQL产品可以使用类似sql的语法来处理数据,但仅限于有限的范围。例如,Apache Cassandra,一个列存储数据库,有它自己的类似sql的语言,Cassandra查询语言或CQL。一些CQL语法直接来自于SQL脚本,比如SELECT或INSERT关键字。但是无法在Cassandra中执行联接或子查询,因此CQL中不存在相关的关键字。

无共享架构

NoSQL系统常见的设计选择是“无共享”架构,在无共享的设计中,集群中的每个服务器节点都独立于其他节点运行。系统不必从每一个节点获得一致性,将一个数据返回给客户端。查询速度快,因为它们可以从最接近或最方便的节点返回。

无共享架构的另一个好处是,弹性和扩展。扩展集群就像在集群中添加新节点并等待它们与其他节点同步一样容易。如果NoSQL节点宕机,集群中的其他服务器将继续运行,所有的数据仍然可用,即使提供服务请求的节点更少。

注意,无共享架构并不专属于NoSQL数据库,许多传统的SQL系统也可以以一种没有共享的方式设置,尽管这通常需要牺牲集群的一致性以获得性能。

NoSQL的局限性

如果NoSQL提供了如此多的自由和灵活性,为什么不完全抛弃SQL呢?答案很简单:许多应用程序仍然需要SQL数据库提供的约束、一致性和安全保障。在这些情况下,NoSQL的一些“优势”可能会变成劣势,其他限制源自NoSQL系统相对较新的事实。

无模式

即使使用的是自由格式的数据,几乎总是需要对其施加约束以使其有用。对于NoSQL,强制约束包括将责任从数据库转移到应用程序开发人员。例如,开发人员可以通过对象关系映射系统(ORM)来实施结构。但是,如果你希望模式与数据本身共存,NoSQL通常不会这样做。

一些NoSQL解决方案为数据提供可选的数据类型和验证机制。例如,Apache Cassandra拥有大量的本地数据类型,这让人想起了在常规SQL中发现的那些数据类型。

最终一致性

NoSQL系统对更好的可用性和性能进行了强烈或即时的一致性。传统的数据库确保了操作是原子的(事务的所有部分都成功了,或者没有成功),一致的(所有用户都有相同的数据视图),孤立的(事务不竞争),并且持久(一旦完成,它们将在服务器故障中幸存)。

这四个属性,统称为ACID,在大多数NoSQL系统中处理方式不同。由于需要将更新复制到集群中的其他节点,因此在整个集群中没有立即的一致性,但有最终的一致性。插入到集群中的数据最终在任何地方都可以使用,但不能保证何时。

在SQL系统中,事务语义保证事务中的所有步骤(例如执行销售和减少库存)要么完成了,要么回滚,这通常在NoSQL中是没有的。对于任何需要“真实的单一来源”的系统,例如银行,NoSQL方法都不能很好地工作。你不希望你的银行余额与ATM机上的不同,你希望它在任何地方都一致。

一些NoSQL数据库有部分机制来解决这个问题。例如,MongoDB对单个操作有一致性保证,但对整个数据库没有一致性保证。微软Azure CosmosDB允许选择每个请求的一致性级别,因此可以选择适合的用例的行为。但对于NoSQL,最终一致性是默认行为。

NoSQL锁定

大多数NoSQL系统在概念上是相似的,但是它们的实现非常不同。每个都有自己的规则和机制,以了解数据如何被查询和管理。

其中的一个副作用是应用程序逻辑和数据库之间可能存在高度耦合。如果你选择了一个NoSQL系统并坚持使用它,这并没有那么糟糕,但如果你在半路上改变系统,它就会成为绊脚石。

如果你从MongoDB迁移到CouchDB(反之亦然),那么你必须做的不仅仅是迁移数据。你还必须了解数据访问和编程语法的差异,换句话说,你必须重写访问数据库的那部分应用程序。

NoSQL技能

NoSQL的另一个缺点是缺乏专业人士,传统的SQL人才市场上仍然相当多,NoSQL技能的人才市场还处于萌芽阶段。

据Indeed.com网站报道,截至2017年

底,传统的SQL数据库,mysql、微软SQL Server、Oracle数据库等,职位数量在过去三年里比MongoDB、Couchbase和Cassandra的工作数量还要高。对NoSQL专业技术的需求正在增长,但它仍然是传统SQL市场的一小部分。

合并SQL和NoSQL

我们可以预期SQL和NoSQL系统之间的一些差异会随着时间的推移而消失。现在已有许多SQL数据库接受JSON文档作为本地数据类型,并可以对该数据执行查询。有些甚至有本地方法来对JSON数据施加约束,这样就可以处理与常规行和列数据相同的严格性。

另一方面,NoSQL数据库不仅增加了类似SQL的查询语言,还增加了传统SQL数据库的其他功能。例如,至少有两个文档数据库,MarkLogic和RavenDB,承诺是ACID兼容的。

有迹象表明,未来几代数据库将跨出范例并提供NoSQL和SQL功能。例如,微软的Azure Cosmos DB,数据库引擎可以交替地复制这两种系统的行为。谷歌云Spanner是一个与NoSQL系统的水平可扩展性相结合的SQL数据库。

不过,纯SQL和纯NoSQL系统将在未来的许多年都有一席之地,以实现快速、高度可伸缩的自由格式数据访问。这带来了一些成本,比如对SQL数据库常见的读取和其他保护措施。但对于许多应用程序来说,使用NoSQL,这些安全措施很可能值得牺牲。

https://www.infoworld.com/article/3240644/nosql/what-is-nosql-nosql-databases-explained.html

本文来自企鹅号 - 云技术实践媒体

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏开源优测

大数据测试学习笔记之hadoop家族

前言 在进行大数据测试之前,我们必须了解下大数据处理的的相关技术体系,今天主要学习和了解了hadoop家族,这里记录下来分享给大家。 hadoop家族产品 ha...

2646
来自专栏杨建荣的学习笔记

运维平台中的集群管理功能设计

我在一次沙龙上说过,做一件事情和做一件具体的事情差别很大。 和很多人交流的时候,其实我是希望他做一件事情,把这件事情负责起来,但是从他们惯有的思维来看,他们希...

3419
来自专栏IT笔记

关于架构优化和设计,架构师必须知道的事情

近几年来随着互联网的飞速发展,新的架构实践方式不断涌现,但是有一件事情是永恒不变的,那就是-“架构之道”;关于如何设计出灵活、高可用性以及能够快速适应变化的系统...

3417
来自专栏吴逸翔的专栏

海量服务实践:手 Q 游戏春节红包项目设计与总结(下篇)

本篇文章接上篇,主要讲解了手 Q 游戏春节红包项目系统保障、演戏验证和总结三个部分。团队从系统容灾/过载保护/柔性可用/立体监控方面做的一些工作,为了保障项目顺...

5580
来自专栏架构之路

高并发请求的缓存设计策略

前几天,我司出了个篓子。当时正值某喜闻乐见的关键比赛结束,一堆人打开我司app准备看点东西,结果从来没有感受到过这么多关注量的该功能瞬间幸福到眩晕,触发了熔断,...

802
来自专栏IT技术精选文摘

基于事件驱动的微服务模式

本文我们将讨论一些经常用在微服务应用中可扩展的设计模式: 事件流 事件溯源 通晓多语言的持久性 内存镜像 命令查询职责分离 起因 Uber, Gilt和其它的公...

22610
来自专栏JAVA高级架构

Java程序员该如何突破瓶颈,成长为优秀的架构师

762
来自专栏架构师之路

12306系统架构优化

12306系统架构优化 coolshell陈皓优化方案 原文:http://coolshell.cn/articles/6470.html 一、业务复杂度比对 ...

3744
来自专栏织云平台团队的专栏

看腾讯运维应对“18岁照片全民怀旧”事件的方案,你一定不后悔!

空间相册面对突发四倍流量,七成访问落在后端冷存储的极端压力下,相册运维、开发团队如何凭借平时基础功底,从告警、容量、扩容、柔性、调度等全方面运维能力,扛过“18...

42511
来自专栏积累沉淀

storm概述

1.Storm是什么,应用场景有哪些?        2.Storm有什么特点?        3.spout发出的消息后续可能会触发产生成...

1899

扫码关注云+社区