“AI 技术+人才”如何成为企业增长新引擎?戳此了解>>> 了解详情
写点什么

关系数据库还是 NoSQL 数据库

  • 2011-01-22
  • 本文字数:3076 字

    阅读完需:约 10 分钟

上一篇简单的说明了为什么要使用NoSQL。接下来我们看下如何把NoSQL 引入到我们的项目中,我们到底要不要把NoSQL 引入到项目中。

在过去,我们只需要学习和使用一种数据库技术,就能做几乎所有的数据库应用开发。因为成熟稳定的关系数据库产品并不是很多,而供你选择的免费版本就更加少了,所以互联网领域基本上都选择了免费的MySQL 数据库。在高速发展的WEB2.0 时代,我们发现关系数据库在性能、扩展性、数据的快速备份和恢复、满足需求的易用性上并不总是能很好的满足我们的需要,我们越来越趋向于根据业务场景选择合适的数据库,以及进行多种数据库的融合运用。几年前的一篇文章《 One Size Fits All - An Idea Whose Time Has Come and Gone 》就已经阐述了这个观点。

当我们在讨论是否要使用 NoSQL 的时候,你还需要理解 NoSQL 也是分很多种类的,在 NoSQL 百花齐放的今天,NoSQL 的正确选择比选择关系数据库还具有挑战性。虽然 NoSQL 的使用很简单,但是选择却是个麻烦事,这也正是很多人在观望的一个原因。

NoSQL 的分类

NoSQL 仅仅是一个概念,NoSQL 数据库根据数据的存储模型和特点分为很多种类。

类型

部分代表

特点

列存储

Hbase

Cassandra

Hypertable

顾名思义,是按列存储数据的。最大的特点是方便存储结构化和半结构化数据,方便做数据压缩,对针对某一列或者某几列的查询有非常大的 IO 优势。

文档存储

MongoDB

CouchDB

文档存储一般用类似 json 的格式存储,存储的内容是文档型的。这样也就有有机会对某些字段建立索引,实现关系数据库的某些功能。

key-value 存储

Tokyo Cabinet / Tyrant

Berkeley DB

MemcacheDB

Redis

可以通过 key 快速查询到其 value。一般来说,存储不管 value 的格式,照单全收。(Redis 包含了其他功能)

图存储

Neo4J

FlockDB

图形关系的最佳存储。使用传统关系数据库来解决的话性能低下,而且设计使用不方便。

对象存储

db4o

Versant

通过类似面向对象语言的语法操作数据库,通过对象的方式存取数据。

xml 数据库

Berkeley DB XML

BaseX

高效的存储 XML 数据,并支持 XML 的内部查询语法,比如 XQuery,Xpath。

以上 NoSQL 数据库类型的划分并不是绝对,只是从存储模型上来进行的大体划分。它们之间没有绝对的分界,也有交差的情况,比如 Tokyo Cabinet / Tyrant 的 Table 类型存储,就可以理解为是文档型存储,Berkeley DB XML 数据库是基于 Berkeley DB 之上开发的。

NoSQL 还是关系数据库

虽然 09 年出现了比较激进的文章《关系数据库已死》,但是我们心里都清楚,关系数据库其实还活得好好的,你还不能不用关系数据库。但是也说明了一个事实,关系数据库在处理 WEB2.0 数据的时候,的确已经出现了瓶颈。

那么我们到底是用 NoSQL 还是关系数据库呢?我想我们没有必要来进行一个绝对的回答。我们需要根据我们的应用场景来决定我们到底用什么。

如果关系数据库在你的应用场景中,完全能够很好的工作,而你又是非常善于使用和维护关系数据库的,那么我觉得你完全没有必要迁移到 NoSQL 上面,除非你是个喜欢折腾的人。如果你是在金融,电信等以数据为王的关键领域,目前使用的是 Oracle 数据库来提供高可靠性的,除非遇到特别大的瓶颈,不然也别贸然尝试 NoSQL。

然而,在 WEB2.0 的网站中,关系数据库大部分都出现了瓶颈。在磁盘 IO、数据库可扩展上都花费了开发人员相当多的精力来优化,比如做分表分库(database sharding)、主从复制、异构复制等等,然而,这些工作需要的技术能力越来越高,也越来越具有挑战性。如果你正在经历这些场合,那么我觉得你应该尝试一下 NoSQL 了。

选择合适的 NoSQL

如此多类型的 NoSQL,而每种类型的 NoSQL 又有很多,到底选择什么类型的 NoSQL 来作为我们的存储呢?这并不是一个很好回答的问题,影响我们选择的因素有很多,而选择也可能有多种,随着业务场景,需求的变更可能选择又会变化。我们常常需要根据如下情况考虑:

  1. 数据结构特点。包括结构化、半结构化、字段是否可能变更、是否有大文本字段、数据字段是否可能变化。
  2. 写入特点。包括 insert 比例、update 比例、是否经常更新数据的某一个小字段、原子更新需求。
  3. 查询特点。包括查询的条件、查询热点的范围。比如用户信息的查询,可能就是随机的,而新闻的查询就是按照时间,越新的越频繁。

NoSQL 和关系数据库结合

其实 NoSQL 数据库仅仅是关系数据库在某些方面(性能,扩展)的一个弥补,单从功能上讲,NoSQL 的几乎所有的功能,在关系数据库上都能够满足,所以选择 NoSQL 的原因并不在功能上。

所以,我们一般会把 NoSQL 和关系数据库进行结合使用,各取所长,需要使用关系特性的时候我们使用关系数据库,需要使用 NoSQL 特性的时候我们使用 NoSQL 数据库,各得其所。

举个简单的例子吧,比如用户评论的存储,评论大概有主键 id、评论的对象 aid、评论内容 content、用户 uid 等字段。我们能确定的是评论内容 content 肯定不会在数据库中用 where content=’’查询,评论内容也是一个大文本字段。那么我们可以把 主键 id、评论对象 aid、用户 id 存储在数据库,评论内容存储在 NoSQL,这样数据库就节省了存储 content 占用的磁盘空间,从而节省大量 IO,对 content 也更容易做 Cache。

复制代码
// 从 MySQL 中查询出评论主键 id 列表
commentIds=DB.query("SELECT id FROM comments where aid='评论对象 id' LIMIT 0,20");
// 根据主键 id 列表,从 NoSQL 取回评论实体数据
CommentsList=NoSQL.get(commentIds);

NoSQL 代替 MySQL

在某些应用场合,比如一些配置的关系键值映射存储、用户名和密码的存储、Session 会话存储等等,用 NoSQL 完全可以替代 MySQL 存储。不但具有更高的性能,而且开发也更加方便。

NoSQL 作为缓存服务器

MySQL+Memcached 的架构中,我们处处都要精心设计我们的缓存,包括过期时间的设计、缓存的实时性设计、缓存内存大小评估、缓存命中率等等。

NoSQL 数据库一般都具有非常高的性能,在大多数场景下面,你不必再考虑在代码层为 NoSQL 构建一层 Memcached 缓存。NoSQL 数据本身在 Cache 上已经做了相当多的优化工作。

Memcached 这类内存缓存服务器缓存的数据大小受限于内存大小,如果用 NoSQL 来代替 Memcached 来缓存数据库的话,就可以不再受限于内存大小。虽然可能有少量的磁盘 IO 读写,可能比 Memcached 慢一点,但是完全可以用来缓存数据库的查询操作。

规避风险

由于 NoSQL 是一个比较新的东西,特别是我们选择的 NoSQL 数据库还不是非常成熟的产品,所以我们可能会遇到未知的风险。为了得到 NoSQL 的好处,又要考虑规避风险,鱼与熊掌如何兼得?

现在业内很多公司的做法就是数据的备份。在往 NoSQL 里面存储数据的时候还会往 MySQL 里面存储一份。NoSQL 数据库本身也需要进行备份(冷备和热备)。或者可以考虑使用两种 NoSQL 数据库,出现问题后可以进行切换(避免出现 digg 使用 Cassandra 的悲剧)。

总结

本文只是简单的从 MySQL 和 NoSQL 的角度分析如何选择,以及进行融合使用。其实在选择 NoSQL 的时候,你可能还会碰到关于 CAP 原则,最终一致性,BASE 思想的考虑。因为使用 MySQL 架构的时候,你也会碰到上面的问题,所以这里没有阐述。

关于作者

孙立,目前在凤凰网负责底层组的研发工作。曾就职于搜狐和 ku6。多年互联网从业经验和程序开发,对分布式搜索引擎的开发,高并发,大数据量网站系统架构优化,高可用性,可伸缩性,分布式系统缓存, 数据库分表分库(sharding)等有丰富的经验,并且对运维监控和自动化运维控制有经验。开源项目 phplock,phpbuffer 的作者。近期开发了一个 NOSQL 数据库存储 INetDB, 是 NoSQL 数据库爱好者。他的新浪微博是: http://t.sina.com.cn/sunli1223


感谢张凯峰对本文的策划及审校。

公众号推荐:

2024 年 1 月,InfoQ 研究中心重磅发布《大语言模型综合能力测评报告 2024》,揭示了 10 个大模型在语义理解、文学创作、知识问答等领域的卓越表现。ChatGPT-4、文心一言等领先模型在编程、逻辑推理等方面展现出惊人的进步,预示着大模型将在 2024 年迎来更广泛的应用和创新。关注公众号「AI 前线」,回复「大模型报告」免费获取电子版研究报告。

AI 前线公众号
2011-01-22 22:0128901

评论 1 条评论

发布
用户头像
居然搜到了大辉老师
2022-03-30 00:32
回复
没有更多了
发现更多内容

PON网络应用场景

小齐写代码

一站式指南:使用Motoko打造高性能后端服务

TinTinLand

区块链

我们不可能永远都在救火 ——Scrum中技术债务“偿还”指南

敏捷开发

项目管理 Scrum 敏捷开发 自动化测试 技术债务

记三次升级 TiDB 集群到 v6.1.5 遇到的案例分析过程&升级收益

TiDB 社区干货传送门

版本升级 管理与运维 6.x 实践

网站遇到DDOS攻击该怎么解决?

德迅云安全杨德俊

安全 DDoS 网站优化 #web

软件测试/测试开发|如何解决pip下载速度慢的问题

霍格沃兹测试开发学社

软件测试/测试开发丨常用测试策略与测试手段

测试人

软件测试 测试开发

TiDB v7.5.0 vs Oceanbase v4.2.1.1 : online ddl 吐血验证测试

TiDB 社区干货传送门

【新手升级必看】从 TiDB v6.5升级到 v7.5 的实践步骤

TiDB 社区干货传送门

版本升级

Git:Rebase和Merge之间的区别

百度搜索:蓝易云

Linux Rebase 云服务器 NFS merge

探索JavaScript:使用JavaScript创造引人入胜的前端体验

TinTinLand

区块链

软件测试/测试开发丨Bug概念,定义,判定标准,严重程度,优先级

测试人

软件测试 测试开发

软件测试/测试开发丨Bug生命周期

测试人

软件测试 测试开发

基于Flink SQL 和 Paimon 构建流式湖仓新方案

Apache Flink

大数据 flink 实时计算

软件测试/测试开发|如何使用场景法设计测试用例?

霍格沃兹测试开发学社

QCN9024|Wallys DR9074-TRIBAND Now Supported by ATH11K for Enhanced Linux Compatibility!

wallyslilly

QCN9074 QCN9024

技术写作与内容研究:主题得分、关键词搜索量、社区和论坛策略

小万哥

程序人生 后端开发 技术写作 关键词搜索 社区和论坛

macos冒险游戏推荐:索尼克梦之队Sonic Dream Team激活最新

胖墩儿不胖y

好玩的游戏推荐 Mac游戏分享

SecGPT:全球首个网络安全开源大模型

云起无垠

软件测试/测试开发|如何使用因果图法设计测试用例?

霍格沃兹测试开发学社

数字时代B2B订货平台,助力渠道业绩持续增长

赛博威科技

赛博威 经销商管理 订货平台

【终极教程】Cocos2dx服务端重构(优化cocos2dx服务端)

杭州悦数成立「悦数图技术陆家嘴数据智能研究院」入驻上海「双城辉映」平台

悦数图数据库

图数据库

Flink CDC 3.0 正式发布,详细解读新一代实时数据集成框架

Apache Flink

大数据 flink 实时计算

【资源汇总】TiDB-TiCDC 源码解读系列最全资源!!!

TiDB 社区干货传送门

TiDB在银行业核心系统POC测试应用压测参考手册

TiDB 社区干货传送门

性能调优 性能测评 数据库架构设计 应用适配 OLTP 场景实践

Ubuntu 22.04上安装NFS服务教程。

百度搜索:蓝易云

云计算 Linux ubuntu 运维 NFS

条件编译 | AI工程化部署

AIWeker

c AI AI工程化部署

AI数字人互动大屏赋能哪些行业?

青否数字人

数字人

半岛铁盒推出22.5W超级快充充电宝:双线快充,超能补量

科技热闻

【教程】使用ipagurd打包与混淆Cocos2d-x的Lua脚本

雪奈椰子

关系数据库还是NoSQL数据库_Java_孙立_InfoQ精选文章