国内最专业的IT技术学习网

Mysql数据库

当前位置:主页 > Mysql数据库 >

到底选择SQL还是NoSQL?看这里!

发布时间:2019/08/15标签:   CPU      NoSQL      SQL    点击量:

原标题:到底选择SQL还是NoSQL?看这里!

你是否在为系统的数据库来一波大流量就几乎打满 CPU,日常 CPU 居高不下烦恼?你是否在各种 NoSQL 间纠结不定,到底该选用哪种最好?今天的你就是昨天的我,这也是我写这篇文章的初衷。

图片来自 Pexels

作为互联网从业人员,我们要知道关系型数据库(MySQL、Oracle)无法满足我们对存储的所有要求,因此对底层存储的选型,对每种存储引擎的理解非常重要。

同时也由于过去一段时间的工作经历,对这块有了一些更多的思考,想通过自己的总结把这块写出来分享给大家。

结构化数据、非结构化数据与半结构化数据

文章的开始,聊一下结构化数据、非结构化数据与半结构化数据,因为数据特点的不同,将在技术上直接影响存储引擎的选型。

首先是结构化数据,根据定义结构化数据指的是由二维表结构来逻辑表达和实现的数据,严格遵循数据格式与长度规范,也称作为行数据,特点为:数据以行为单位,一行数据表示一个实体的信息,每一行数据的属性是相同的。

例如:

因此关系型数据库很好契合结构化数据的特点,关系型数据库也是关系型数据最主要的存储与管理引擎。

非结构化数据,指的是数据结构不规则或不完整,没有任何预定义的数据模型,不方便用二维逻辑表来表现的数据,例如办公文档(Word)、文本、图片、HTML、各类报表、视频音频等。

介于结构化与非结构化数据之间的数据就是半结构化数据了,它是结构化数据的一种形式,虽然不符合二维逻辑这种数据模型结构,但是包含相关标记,用来分割语义元素以及对记录和字段进行分层。

常见的半结构化数据有 XML 和 JSON,例如:

<person> 

    <name>张三</name

    <age>18</age> 

    <phone>12345</phone> 

</person> 

这种结构也被成为自描述的结构。

以关系型数据库的方式做存储的架构演进

首先,我们看一下使用关系型数据库的方式,seo工资高吗,企业一个系统发展的几个阶段的架构演进(由于本文写的是 SQL 与 NoSQL,因此只以存储方式作为切入点,不会涉及类似 MQ、ZK 这些中间件内容):

阶段一

企业刚发展的阶段,最简单,一个应用服务器配一个关系型数据库,每次读写数据库。

阶段二

无论是使用 MySQL 还是 Oracle 还是别的关系型数据库,数据库通常不会先成为性能瓶颈,通常随着企业规模的扩大,一台应用服务器扛不住上游过来的流量且一台应用服务器会产生单点故障的问题。

因此加应用服务器并且在流量入口使用 Nginx 做一层负载均衡,保证把流量均匀打到应用服务器上。

阶段三

随着企业规模的继续扩大,此时由于读写都在同一个数据库上,数据库性能出现一定的瓶颈。

此时简单地做一层读写分离,每次写主库,读备库,主备库之间通过 Binlog 同步数据,就能很大程度上解决这个阶段的数据库性能问题。

阶段四

企业发展越来越好了,业务越来越大了,做了读写分离数据库压力还是越来越大,这时候怎么办呢?

一台数据库扛不住,那我们就分几台吧,做分库分表,对表做垂直拆分,对库做水平拆分。

以扩数据库为例,扩出两台数据库,以一定的单号(例如交易单号),以一定的规则(例如取模)。

交易单号对 2 取模为 0 的丢到数据库 1 去,交易单号对 2 取模为 1 的丢到数据库 2 去,通过这样的方式将写数据库的流量均分到两台数据库上。

一般分库分表会使用 Shard 的方式,通过一个中间件,便于连接管理、数据监控且客户端无需感知数据库 IP。

关系型数据库的优点

上面的方式,看似可以解决问题(实际上确实也能解决很多问题),正常对关系型数据库做一下读写分离+分库分表,支撑个 1W+ 的读写 QPS 还是问题不大的。

版权信息Copyright © IT技术教程 版权所有    ICP备案编号:鲁ICP备09013610号