首页 资讯频道 互联频道 智能频道 网络 数据频道 安全频道 服务器频道 存储频道

关于数据库从RDBMS迁移到NoSQL的困难、过程和好处

2020-04-26 16:29:43 来源 : 读芯术

在大数据时代,数据是信息系统的核心,数据组织和运营的效率是任何公司都关心的问题,业务专长和对现有技术解决方案的理解是非常必要的。因此,公司必须同时继续评估和选择能够满足其未来需求和支持其增长的数据库。

关系数据库已经被用于存储数据几十年了,它们仍是许多用例的可行解决方案。而NoSQL数据库则是针对关系数据库技术的局限性而创建的。

与关系型数据库相比,NoSQL数据库具有更强的可扩展性和更好的性能,它弥补了关系型数据库的一些不足。

NoSQL数据库旨在解决大数据环境中的海量,多源和多格式的数据处理问题。它们提供了一种新的方法来满足容量需求以及新的数据类型。如今,NoSQL数据库的数量变得越来越重要。了解了它们之间的差异是至关重要的,你才能采用正确的技术进行正确的应用。

本文将阐述从RDBMS迁移到NoSQL的困难、过程和好处。

1. 简介

SQL:

SQL是结构化查询语言的缩写。IT工程师在大型关系数据库(DBMS)中快速搜索信息已经有很长一段时间了。

SQL如今被广泛使用,因为它是最结构化、最快的数据库组织和查询设备之一;不同的名字代表不同的改进版本,如Oracle的MySQL和微软的SQL Server。此外,SQL具有预定义的结构和模式,是许多公司最推荐的选择。

NoSQL:

“NoSQL”这个缩略语有两种不同的解释,目前尚不明确:

对有些人来说是“No SQL”,也就是说,使用了另一种不同于SQL的查询语言。

对于其他人,它不仅是“SQL”,也就是说,是SQL与其他信息检索工具的结合使用。

这个术语既与技术特征有关,也与20世纪10年代出现的历史性一代DBMS有关。导致NoSQL发明的主要原因是,它解决了这样一个问题,即一个网站上的同一个数据库可以在全世界范围内被数百万用户同时使用;像亚马逊这样的公司就存在这种典型问题……

笔者试图通过NoSQL来降低查询语言的复杂性,简化数据库的体系结构。这些数据库包括面向列、面向文档、面向图形和面向键/值的数据。NoSQL由各种产品组成,每个产品都有一组独特的功能。

主要差别:

SQL数据库有一个预定义的模式,而NoSQL数据库有一个用于非结构化数据的动态模式。

SQL数据库是可垂直扩展的,而NoSQL数据库是可水平扩展的。SQL数据库是通过增加CPU、RAM或SSD等硬件的能力来扩展的。

NoSQL数据库通过增加数据服务器的数量来减少负载。这就像在同一栋建筑上增加更多的楼层,而不是在邻近地区增加更多的建筑。

SQL数据库使用SQL(结构化查询语言)来定义和操作数据,这是非常强大的。在NoSQL数据库中,查询的重点是文档收集。有时也称为UnQL(非结构化查询语言)。在不同的NoSQL数据库之间,使用UnQL的语法差异很大。

SQL数据库是基于表的数据库,而NoSQL数据库是基于键值对的数据库。这意味着SQL数据库以表的形式表示数据,表由表示数据的一定数量的行组成,而NoSQL数据库是键值对、文档、图形数据库等的集合。

2. 历史因素

(1) 关系型DBMS的历史支配地位

20世纪70年代创建的关系型DBMS已经逐渐成为主流, 20世纪90年代初成为了非常普遍的主流数据库范式。

在20世纪90年代,许多物流公司的销售人员开始使用它来存储业务数据。事实上,他们既没有鼠标,也没有用户界面来搜索存储在服务器上的某些信息,服务器通常由专业线连接并且相距很远,它们用于通过键盘输入SQL命令,并且能够在几秒内检索到特定产品或原材料可用性的相关信息。

出现了其他几种数据库模型,如面向对象的数据库管理系统、层次数据库管理系统、对象关系数据库管理系统,但它们的使用非常有限。

从本世纪初开始,随着谷歌、亚马逊等大型互联网公司的发展,出现了大量的非结构化数据,其增长速度远远超过不再符合RDBMS关系模式的结构化数据。集群计算也得到了发展,关系模型的主导地位由于其在新实践上的限制受到了质疑。

(2) NoSQL模型的先驱

大型web公司必须处理非常大的数据量,这就是为什么它们首先要面对传统关系型DBMS的固有限制。

这些系统严格应用ACID属性(原子性、一致性、隔离性、持久性),通常设计为在单台计算机上运行,很快就出现了可伸缩性问题。为了满足这些限制,一些公司已经开始开发自己的数据库管理系统,这些系统可以在分布式硬件架构上运行,可以处理大量数据:

谷歌(BigTable),

亚马逊(DynamoDB),

LinkedIn(Voldemort ),

Facebook (Cassandra和HBase),

百度(Hypertable)

通过简单增加服务器数量,性能保持良好,这是降低成本的合理解决方案,特别是如果收入随着活动的增长而增长的话。

3. 流行的数据库

为了选择合适的管理系统,了解市场上存在什么是很重要的。看看下面5个流行的SQL和NoSQL数据库,其中有付费的也有免费的。

(1) SQL数据库产品:

MySql:它是免费的,即使是免费的数据库引擎也提供了很多功能。

Postgres:这个数据库管理引擎是可扩展的,可以处理tb级的数据,具有各种预定义的功能。

Oracle:Oracle数据库管理工具集最新的创意和功能于一身,非常强大。

SQL Server:非常快速和稳定,与微软的其他产品配合得很好。

SQLite:SQLite数据库非常灵巧,并且可以快速地设置,它还可以用于在智能手机应用程序(iPhone或Android)的实际数据库中存储数据。

(2) NoSQL数据库产品:

MongoDB:MongoDB是一个灵活/可靠的数据库,它会把读者吸引到NoSQL的世界中来。管理和维护非常简单快捷。

Hbase:它是一个面向列的数据库,有助于提高查询性能和集合。

Cassandra:Cassandra提供的线性可伸缩性,允许通过简单地添加/删除服务器来轻松地扩展/缩小集群。

Redis:使用非常简单和直接。下载Redis,并在接下来的五分钟内开始使用它。

CouchDb:由于CouchDB能够存储序列化(JSON格式)的非结构化数据和Restful HTTP API,因此它非常适合用于Web和移动应用程序。

4. NoSQL数据库设计

NoSQLDBMS的主要特点,在于支持对大量数据的操作和水平可伸缩性。然而,目前大多数公司面临的困难是,如何用最适当的技术解决问题,使应用作出反应。

要解决这个问题,首先要很好地理解不同类型的NoSQL数据库。

有一个普遍的误解,所有的NoSQL数据库都是平等创建的。实际上,这些数据库可以分为四类:面向文档的数据库、键/值数据库、列数据库和面向图形的数据库。它们都有一个共同点:支持比传统关系数据库更灵活和更动态的模型。

事实上,每个类别都有自己的属性和限制。没有数据库可以解决所有问题。必须根据项目的需要选择数据库。

必须考虑将操作什么类型的数据,以及应用程序最终将如何使用这些数据。

(1) 面向文档的数据库:混合结构

面向文档的NoSQL数据库将数据存储和提取为键/值对,但是值部分存储为文档。文档以JSON或XML格式存储。

大数据时代下的新宠:是时候熟悉NoSQL数据库了!

MongoDB, Apache CouchDB, MarkLogic是面向文档的数据库

(2) 键/值数据库:

面向键值的数据库有大量的键和值散列。它代表了NoSQL数据库的最简单形式。将唯一的键与数据中的值相关联,目的是基于相对简单的数据集极大地提高应用程序的性能。

大数据时代下的新宠:是时候熟悉NoSQL数据库了!

Redis, Riak, Memcached 和 Aerospike 就是键值数据库的例子。

(3) 列数据库:

列数据库将数据保存在具有大量列的表中。每个存储块包含来自单个列的数据,并且每个列被单独处理。它们在诸如COUNT、SUM、AVG、MAX等聚合查询上有很高的性能,因为数据很容易从列中取出。

HBase, Cassandra 和 Accumulo 就是列数据库的例子。

(4) 面向图形的数据库:

基于图的数据库是一种网络数据库,它将数据元素存储在“图”结构中,使得在节点之间创建关联成为可能,最终成为推荐引擎或社交网络的基础。

从图形数据库中可以获得很多信息。例如,可以使用图形技术根据不同人的兴趣来确定他们之间的关系。

大数据时代下的新宠:是时候熟悉NoSQL数据库了!

图源:neo4j.

Neo4J, InfiniteGraph 和 FlockDB 就是面向图形数据库的例子。

5. 为应用程序选择适当的数据库类型的5个标准

如何选择哪种类型的数据库最适合一个项目?可以根据以下清单做决定:

要存储的数据类型:SQL数据库不适合分层数据存储。但是,NoSQL数据库更适合分层数据存储,因为它遵循键值对方法或图方法。NoSQL数据库是大型数据集的首选。

可伸缩性:在大多数情况下,SQL数据库是可垂直伸缩的。可以通过增加单个服务器上的处理器、RAM、SSD等来管理增加的负载。另一方面,NoSQL数据库是可水平伸缩的。可以简单地将一些额外的服务器添加到NoSQL数据库基础设施中来处理繁重的数据流。因此,可以根据设备选择适合的数据库类型。

高度事务性应用程序:SQL数据库更稳定并且可以保证原子性和数据完整性,因此更适合密集使用的事务类型的应用程序。虽然可以将NoSQL用于事务性目的,但它仍然不能与SQL相提并论,但可以用于复杂的事务性应用程序。

复杂查询:SQL数据库非常适合需要很多查询的环境,而NoSQL数据库不适合复杂查询。所以NoSQL中的查询不如SQL查询语言强大。

属性:SQL数据库强调ACID属性(原子性、一致性、隔离性、持久性),而NoSQL数据库遵循Brewers CAP定理(一致性、可用性和分区容限)。

6. 从RDBMS转向NoSQL

无论选择哪种NoSQL数据库设计,将数据迁移到其中都会遇到一些严峻的挑战。NoSQL中数据模型的设计具有额外的复杂性,你需要知道数据的最终用途。仅仅知道应用程序将处理账单和客户信息是不够的,还必须知道这些数据将如何展示给最终用户。

因此,NoSQL数据库中的数据建模除了需要对最终用户的使用有深入的了解外,还需要真正的技术专长。

是时候用NoSQL解决方案替换SQL了吗?

在笔者看来,这是一个很难回答的问题。因为在大多数情况下,不是用NoSQL解决方案替换SQL,而是在应用程序和用例显示需要更改时,从一种解决方案转换到另一种解决方案。

通常,在构建现代Web和移动应用程序时,对灵活性和可伸缩性的需求将推动这种转变。

许多公司试图在其web应用程序中支持负载,因此选择简单地将web服务器添加到负载平衡器之后以支持更多用户。

毫无疑问,在日益重要的云计算世界中,扩展能力是一个基本的竞争优势,可以轻松地添加或删除虚拟机实例,以满足变化不定的需求。

关系型数据库(RDBMS)不允许简单的扩展,也不提供灵活的数据模型。管理更多的用户意味着添加更大的服务器,而大型服务器非常复杂和昂贵,不像低成本的硬件、“商品硬件”和云架构。

组织开始看到现有或新应用程序的关系数据库的性能问题。特别是随着用户数量的日益增加,他们意识到对更快速、更灵活的数据库的需求变得非常重要。是时候转移到NoSQL了!

从SQL到NoSQL的转换需要哪些主要步骤?

应用程序/项目可能因每个组织而有很大的差异,因此转换将取决于使用用例。以下是一些关于过渡的通用准则:

(1) 理解应用的核心需求

以下是与NoSQL数据库的需求相对应的一些要求:

可扩展性

快速的应用程序开发:不断变化的市场需求和持续的数据修改

性能稳定:响应时间短,可带来更好的用户体验

运行可靠性:管理错误的高可用性,对应用程序的影响最小,并且集成了监视API以便更好维护

(2) 了解NoSQL提供的不同类型

如前所述,有不同类型的NoSQL数据库管理系统。例如面向文档的NoSQL数据库—Couchbase和MongoDB是两个最著名和最广泛采用的例子。

此外,Cassandra可能也是一个解决方案,可以使用它的柱状模型进行数据分析。Neo4j是一个图形数据库,对于需要存储实体间关系的应用程序来说,它可能是一个完美的数据库。

(3) 建立一个原型

一旦缩小了数据库类型的可能选择范围,就可以尝试开发一个集成了应用程序主要特征的原型。这个原型将帮助评估响应时间、吞吐量方面的性能和易于扩展的能力。

(4) 文档建模与开发

对于面向文档的数据库,请花几天时间从固定的表格图开始对数据建模,以获取灵活的文档模型。

(5) 部署然后生产

操作稳定性是交互式web应用程序的一个非常重要的方面。对部署进行一次又一次的测试,就像对通常使用传统RDBMS系统的应用程序进行测试一样。

(6) 紧跟最新趋势

今天,有大量的高质量培训提供了NoSQL的实践课程,确保NoSQL成功实现的最佳方法是更新最新版本。

不要担心,你会很容易接受某些NoSQL技术,特别是如果熟悉JSON文档格式。广泛使用SQL的开发人员可能需要适应和学习文档建模方法。重新思考如何使用文档在逻辑上构造数据,而不是将数据规范化为固定的数据库模式,这是一个重要的方面。

7. 结论

本文旨在介绍存在的主要差异,以帮助读者做出正确的决策并塑造信息系统(或简单应用程序)的未来。

可以看到,SQL和NoSQL数据库最终做的是几乎相同的事情(存储数据),但方式不同。数据库管理系统(DBMS)的选择对于任何数据项目来说都是一个重要的和结构化的时刻。当然,总是可以选择一个选项,然后切换到另一个选项。但是在项目开始时进行一点概念分析和思考将节省时间和金钱。

今天的市场上到处都是NoSQL数据库——每天都要面对两三个这样的数据库,因为对于开发人员来说,转到NoSQL有很多优势。更灵活的数据模型和摆脱僵化模式是一个很大的优势。还可以看到性能的显著提高和水平伸缩。

但大多数NoSQL产品仍处于产品周期的早期阶段。在复杂连接之类的特性上,开发人员可能更喜欢使用传统的RDBMS。对于某些项目,混合方法可能是最佳选择。最后,根据项目的需求,每个公司都有自己的偏好。

因此,确定需求和数据库,甚至使用混合方法,为项目的开发提供集成支持才是最合适的做法。

最近更新
简述 mysql 的索引选择 2020-04-26 16:28:14