【大数据存储与管理】NoSQL数据库:02 NoSQL兴起的原因

【作者主页】Francek Chen

【专栏介绍】⌈ ⌈ ⌈大数据技术原理与应用 ⌋ ⌋ ⌋专栏系统介绍大数据的相关知识,分为大数据基础篇、大数据存储与管理篇、大数据处理与分析篇、大数据应用篇。内容包含大数据概述、大数据处理架构Hadoop、分布式文件系统HDFS、分布式数据库HBase、NoSQL数据库、云数据库、MapReduce、Hadoop再探讨、数据仓库Hive、Spark、流计算、Flink、图计算、数据可视化,以及大数据在互联网领域、生物医学领域的应用和大数据的其他应用。

【GitCode】专栏资源保存在我的GitCode仓库:https://gitcode.com/Morse_Chen/BigData_principle_application

文章目录


关系数据库是指采用关系数据模型的数据库,最早由图灵奖得主、有"关系数据库之父"之称的埃德加·弗兰克·科德于 1970 年提出。由于具有规范的行和列结构,因此存储在关系数据库中的数据通常也被称为"结构化数据",用来查询和操作关系数据库的语言被称为"结构化查询语言"。由于关系数据库具有完备的数学理论基础、完善的事务管理机制和高效的查询处理引擎,因此在社会生产和生活中得到了广泛的应用,并从 20 世纪 70 年代到 21 世纪前 10 年,一直占据商业数据库应用的主流的位置。目前主流的关系数据库有 Oracle、DB2、SQL Server、Sybase、MySQL 等。

尽管数据库的事务和查询机制较好地满足了银行、电信等各类商业公司的业务数据管理需求,但是随着 Web 2.0 的兴起和大数据时代的到来,关系数据库已经显得越来越力不从心,暴露出越来越多难以克服的缺陷。于是 NoSQL 数据库应运而生,它很好地满足了 Web 2.0 的需求,得到了市场的青睐。

一、关系数据库无法满足 Web 2.0 的需求

关系数据库已经无法满足 Web 2.0 的需求,主要表现在以下 3 个方面。

(一)无法满足海量数据的管理需求

在 Web 2.0 时代,每个用户都是信息的发布者,用户的购物、社交、搜索等网络行为都会产生大量数据。新浪微博、淘宝、百度等网站,每天生成的数据量十分可观。对于上述网站而言,很快就可以产生超过 10 亿条的记录数据。对于关系数据库来说,在一张有 10 亿条记录数据的表里进行 SQL 查询,效率极其低下,甚至是不可忍受的。

(二)无法满足数据高并发的需求

在 Web 1.0 时代,通常采用动态页面静态化技术,事先访问数据库生成静态页面供浏览者访问,从而保证大规模用户访问时,也能够获得较好的实时响应性能。但是,在 Web 2.0 时代,各种用户信息都在不断地发生变化,购物记录、搜索记录、微博粉丝数等信息都需要实时更新,动态页面静态化技术基本没有用武之地,所有信息都需要动态实时生成,这就会导致高并发的数据库访问,可能产生每秒上万次的读写请求。对于很多关系数据库而言,这都是"难以承受之重"。

(三)无法满足高可扩展性和高可用性的需求

在 Web 2.0 时代,不知名的网站可能一夜爆红,用户迅速增加,已经广为人知的网站也可能因为发布了某些吸引眼球的信息,引来大量用户在短时间内围绕该信息产生大量交流、互动。这些都会导致对数据库读写负荷的急剧增加,需要数据库能够在短时间内迅速提升性能应对突发需求。但遗憾的是,关系数据库通常是难以横向扩展的,没有办法像网页服务器和应用服务器那样简单地通过添加更多的硬件和服务节点来扩展性能和负载能力。

二、关系数据库的关键特性在 Web 2.0 时代成为"鸡肋"

关系数据库的关键特性包括完善的事务机制和高效的查询机制。关系数据库的事务机制是由 1998 年图灵奖获得者、被誉为"数据库事务处理专家"的詹姆斯·格雷提出的。一个事务具有原子性、一致性、隔离性、持续性等"ACID"四性。有了事务机制,数据库中的各种操作可以保证数据的一致性修改。关系数据库还拥有非常高效的查询处理引擎,可以对查询语句进行语法分析和性能优化,保证查询的高效执行。

但是,关系数据库引以为傲的两个关键特性到了 Web 2.0 时代却成了"鸡肋",主要表现在以下 3 个方面。

(一)Web 2.0 网站系统通常不要求严格的数据库事务

对于许多 Web 2.0 网站而言,数据库事务已经不再那么重要。比如对于微博网站而言,如果一个用户发布微博过程出现错误,可以直接丢弃该信息,而不必像关系数据库那样执行复杂的回滚操作,这样并不会给用户造成什么损失。而且,数据库事务通常有一套复杂的实现机制来保证数据库一致性,这需要大量系统开销。对于包含大量频繁实时读写请求的 Web 2.0 网站而言,实现事务的代价是难以承受的。

(二)Web 2.0 并不要求严格的读写实时性

对于关系数据库而言,一旦有一条数据记录成功插入数据库中,就可以立即被查询。这对于银行等金融机构而言,是非常重要的。银行用户肯定不希望自己刚刚存入一笔钱,却无法在系统中立即查询到这笔存款记录。但是,对于 Web 2.0 而言,却没有这种实时读写需求,比如用户的微博粉丝数量增加了 10 个,在几分钟后显示更新的粉丝数量,用户可能也不会察觉。

(三)Web 2.0 通常不包含大量复杂的 SQL 查询

复杂的 SQL 查询通常包含多表连接操作。在数据库中,多表连接操作代价高昂,因此各类 SQL 查询处理引擎都设计了十分巧妙的优化机制---通过调整选择、投影、连接等操作的顺序,达到尽早减少参与连接操作的元组数目的目的,从而降低连接代价,提高连接效率。但是,Web 2.0 网站在设计时就已经尽量减少甚至避免这类操作,通常只采用单表的主键查询,因此关系数据库的查询优化机制在 Web 2.0 中难以有所作为。

综上所述,关系数据库凭借自身的独特优势,很好地满足了传统企业的数据管理需求,在数据库这个"江湖"独领风骚 40 余年。但是随着 Web 2.0 时代的到来,各类网站的数据管理需求已经与传统企业大不相同。在这种新的应用背景下,纵使关系数据库使尽浑身解数,也难以满足新时期的要求。于是 NoSQL 数据应运而生,它的出现可以说是 IT 发展的必然。

小结

Web 2.0 时代,关系数据库逐渐力不从心。它无法满足海量数据管理、高并发及高可扩展性和高可用性的需求。同时,关系数据库的关键特性,如完善的事务机制和高效的查询机制,在 Web 2.0 时代也显得不再重要。Web 2.0 网站不要求严格的数据库事务和读写实时性,且通常不包含大量复杂的 SQL 查询。因此,NoSQL 数据库应运而生,满足了 Web 2.0 的新需求。

欢迎 点赞👍 | 收藏⭐ | 评论✍ | 关注🤗

相关推荐
做萤石二次开发的哈哈2 小时前
智能AI云存储|萤石蓝海大模型加持,解锁视频数据新价值
大数据·人工智能
斌味代码2 小时前
RAG API 接入:从注册到生产级应用的10分钟上手指南
数据库·oracle
送秋三十五2 小时前
Spring 源码---------Spring Core
java·数据库·spring
用户4815930195912 小时前
四大厂商突然集体站队 Iceberg v3,我花一周搞清楚了为什么
大数据
止语Lab2 小时前
从一行超时配置到分布式可观测性——Go HTTP服务的渐进式演进实战
分布式·http·golang
Cat_Rocky2 小时前
redis数据库基础学习
数据库·redis·学习
正在走向自律2 小时前
多源异构数据融合技术实践:GIS、时序、文档与缓存数据整合方案
数据库
武子康3 小时前
大数据-267 实时数仓-架构演进:Lambda与Kappa架构实战指南
大数据·后端
一个骇客3 小时前
分布式 ID 生成器:给事件排序有多难
分布式·架构