【云驻共创】数据库入门就看这一篇!详解
随着技术的快速发展,数据库的应用已经深入到人们生活和工作的方方面面,数据库也越来越受到重视。下面就来对数据库进行介绍,主要包括数据库技术概述、数据库技术发展史、关系型数据库架构演进以及关系型数据库主流应用场景。
一、数据库技术概述
1.1 数据库技术
数据库技术是数据库管理的有效技术,研究如何对数据进行科学管理,从而为人们提供可共享的、安全的、可靠的数据。
图1 数据库技术
如上所示,数据库技术包括:数据、数据库、数据库管理系统以及数据库系统等概念。
1.2 数据
早期的计算机系统主要用于科学计算,处理的数据是数值型数据:
- 整数:1,2,3,4,5……
- 浮点数:14,100.34,-25.36……
现代计算机系统的数据概念是广义的:表示数字、文字、图形、图像、音频、视频等。描述事物的符号记录称为数据。
现代计算机系统的数据是需要在具体语境下理解的,例如:数字 88 ,可能代表一个部门的人数,也可能代表一门课的考试成绩。
数据除了表现形式之外,还有语义,数据的含义称为数据的语义。记录是在计算机中表示和存储数据的一种格式或一种方法,下面来看一条记录。
图2 记录的存储
在上图中,李明的信息被存入2020级学生信息库,以李明存储数据的格式,还可以存入张三、李四等同学的信息。
1.3 数据库
数据库是存放数据的仓库,是大量数据的集合。存放在数据库中的数据的有如下特点:
- 永久存储
永久存储:在掉电、关机后,再开机后,再访问存储的数据,还可以正常访问,这是数据库存储最基本特点。
- 有组织
有组织:将杂乱无章的数据通过一种模式或模型,去掉一些冗余的数据,形成一个有组织的存放。
- 可共享
可共享:在现实生活中,通常要求对存储的一定的数据能够实现共享。比如在学生数据库里面存储的数据,学生可以去访问,老师可以去访问,家长可以去访问,实现数据的共享,如下图所示:
图3 数据的共享
1.4 数据库管理系统
数据库管理系统是一个能够科学地组织存储数据,高效地获取和维护数据的系统软件,是位于用于与操作系统之间的数据管理软件,其主要功能包括:
- 数据定义功能
- 数据组织、存储和管理功能
- 数据操纵功能
- 数据库的事物管理和运行管理功能
- 数据库的建立和维护功能
- 与其他软件系统的通信功能等
1.5 数据库系统(Database System,DBS)
数据库系统是由数据库、数据库管理系统(及其应用开发工具)、应用程序和数据库管理员组成的存储、管理、处理和维护数据的系统,如下图所示:
图4 数据库系统的组成
在计算机系统层次中的结构如下所示:
图5 计算机系统层次结构图
二、数据库技术发展史
2.1 数据库技术产生与发展
数据库技术应数据管理任务的需要而产生。数据管理的发展,包括:应用需求推动,软硬件的飞速发展为基础,三个阶段:人工管理、文件系统、数据库系统。
数据库技术的发展经历了人工管理阶段、文件系统阶段以及数据库系统阶段,其中数据库系统阶段包括:层次数据库、网状数据库、关系型数据库、面向对象数据库、NoSQL以及NewSQL等。如下所示:
图6 数据库技术阶段
2.2 数据库管理三个阶段比较
下面通过表格来直观的对比一下数据库管理三个阶段,如下表所示。
表1 数据库管理三个阶段
角度 |
层面/阶段 |
人工管理阶段 |
文件系统阶段 |
数据库系统阶段 |
背景 |
应用背景 |
科学计算 |
科学计算、数据管理 |
大规模数据管理 |
硬件背景 |
无直接存取存储设备 |
磁盘,磁鼓 |
大容量磁盘,磁盘阵列 |
|
软件背景 |
无操作系统 |
联机实时处理,批处理 |
有数据库管理系统 |
|
处理方式 |
批处理 |
文件系统 |
联机实时处理,分布处理,批处理 |
|
特点 |
数据管理者 |
用户(程序员) |
|
|
数据面向的对象 |
某一应用程序 |
应用程序 |
现实世界(个人,部门,企业等) |
|
数据的共享程度 |
无共享,冗余度极大 |
共享性差,冗余度大 |
共享性高,冗余度小 |
|
数据的独立性 |
不独立,完全依赖于程序 |
独立性差 |
具有高度的物理独立性和一定的逻辑独立性 |
|
数据的结构化 |
无结构 |
记录内有结构,整体无结构 |
整体结构化,用数据模型描述 |
|
数据控制能力 |
应用程序控制 |
应用程序控制 |
有数据库管理系统提供数据安全性、完整性、并发控制和恢复能力 |
如上表所示,开始经历了人工管理阶段和文件系统阶段,但是,发展到文件系统阶段具有共享性差,冗余度大,独立性差等,最后,发展到数据库系统阶段。
2.3 数据库系统优势
数据库系统的优势主要体现在一下几个方面:
(1)数据库整体数据的结构化
数据面向整个系统而不是单个应用,被多个应用共享。
(2)数据的共享性高,冗余度低且易扩充
(3)数据独立性高
物理物理性:应用程序与数据库中数据的物理存储是相互独立的;逻辑独立性:应用程序与数据库的逻辑结构是相互独立的。
(4)统一管理和控制
数据的安全性保护、数据的完整性检查、并发控制、数据库恢复。
图7 数据库系统
2.4 数据库系统发展特点
数据库系统已经成为计算机信息系统和智能应用系统的核心技术之一和重要基础。
数据库系统的发展的特点主要包括以下几点:
- 数据库的发展集中表现在数据模型的发展上;
- 与其它计算机技术交叉结合;
- 面向应用领域发展数据库新技术;
在应用领域方面经历了联机事物处理、联机分析处理、实时处理、数据挖掘、地理信息系统等。在数据模型维度,经历了层次、网状模型、关系模型、面向对象模型、XML、RDF模型、NoSQL、NewSQL等模型。在计算机技术维度,经历了分布式处理、并行处理、人工智能、多媒体、移动技术、Cloud技术等。
2.5 层次、网状、关系模型
首先说一下层次模型,层次模型有且只有一个节点没有双亲,该节点被称为根节点(root)。根节点意外的其他节点有且只有一个双亲节点。
图8 层次模型
接下来是网状模型,网状模型允许一个以上的节点无双亲。一个节点可以有多于一个的双亲。
图9 网状模型
最后是关系模型,关系模型建立在严格的数据概念基础上,关系必须是规范化的,关系的分量必须是一个不可分的数据项。
表2 关系模型
学号 |
姓名 |
年龄 |
性别 |
2019004 |
王四 |
19 |
男 |
2019005 |
李五 |
20 |
女 |
2019006 |
陈六 |
18 |
男 |
2019007 |
赵七 |
19 |
女 |
2019010 |
宋十 |
17 |
男 |
………… |
………… |
………… |
………… |
2.6 结构化查询语言
SQL语言是一种高级的非过程化编程语言,允许用户在高层数据结构上工作;
不要求用户指定数据存放方法。它不需要用户了解具体数据存放方式。底层结构完全不同的各种关系型数据库系统可以使用相同的SQL语言作为数据操作和管理的接口。
图10 SQL语言发展
2.7 其他数据模型
其他数据模型主要有以下几种。
(1)面向对象数据模型(Object Oriented Data Model, OO模型)
将语义数据模型和面向对象程序设计方法结合起来,用一系列面向对象核心概念构成模型基础。由于面向对象数据库操作语言过于复杂,没有得到开发人员认可。
(2)XML数据模型
可扩展标记语言(extensible markup language,简称XML),是W3C在1998年制定的一项标准,被作为互联网信息交换的标准。XML模型是由若干带有标签的节点组成的有向树,是一种分层自描述模型,具有良好的语义和可扩展性,可以灵活地表示和组织数据,并提供高效的查询方法,例如:XPath、XQuery、关键字查询、子树匹配等。
(3)RDF数据模型
互联网的信息没有同意表达方式,W3C提出资源描述框架(Resource Description Framework,RDF)来描述和注解互联网资源。RDF是描述互联网资源的标记语言,结构为(主语,谓语,宾语)。主要用于语义网、知识库的基础数据模型,是当前知识图谱技术的基石。
2.8 数据管理技术的新挑战
数据管理技术的新挑战包括高度可扩展性和可伸缩性、数据类型多样和异构处理能力、数据处理时效性要求、大数据时代来临,下面分别来讲解下:
(1)高度可扩展性和可伸缩性
随着数据获取手段的自动化,多样化和智能化,导致数据量急剧增大。
(2)数据类型多样和异构处理能力
结构化数据到半结构化/非结构化数据,文本到图形图像,音频视频等多媒体数据,流数据、队列数据。
(3)数据处理时效性要求
传感、网络和通信技术发展对于数据快速流入和处理,实时性方面提出了更高的要求。
(4)大数据时代来临
传统关系型数据库面对海量异构、形式繁杂、高速增长、价值密度低的数据问题遇到全面挑战。NoSQL和NewSQL技术顺应大数据发展的需要,蓬勃发展。
图11 5V特性
2.9 NoSQL技术特点和类型
NoSQL(Not Only SQL)是一种非关系型的、分布式的、不保证满足ACID特性的一类数据管理系统。
NoSQL具有如下特点。
- 对数据进行分区(partitioning),利用大量节点并行处理获得高性能,同时能够采用横向扩展方式(scale out);
- 降低ACID一致性约束,允许暂时不一致,结构最终一致性。遵循CAP理论和BASE原则;
- 各数据分区提供备份(一般是三份),应对节点故障,提高系统可用性。
常见NoSQL数据库技术有键值数据库、图数据库、列式数据库、文档式数据库。
2.10 主要NoSQL数据库简介
下面通过一个表格来直观的对比下,如下表所示。
表3 主要NoSQL数据库简介
分类 |
代表产品 |
典型应用场景 |
数据模型 |
优点 |
限制性 |
键值数据库 |
Redis MemCahed |
缓存用户信息,会话信息,配置文件,购物车等 |
Key指向Value,通常基于Hash table实现 |
查找速度快 |
数据无结构化,字符串或二进制数据 |
列式数据库 |
HBase Cassandra |
日志 博客平台 |
列族式存储 |
查找速度快,很容易分布式扩展 |
不适合随机更新,不适合做有删除和更新的实时操作 |
文档型数据库 |
DouchDB MongoDB |
日志,可以存储不同模式的日志信息。基于弱模式的数据分析 |
和K-V类似,Value的数据结构要求不严格,无需预先定义表结构 |
表结构可变,扩展性好,适合非结构化对象 |
有些产品不支持事务操作 |
图数据库 |
Neo4j Infinite Graph |
推荐引擎 关系图谱 |
图结构 |
借助图论算法处理特定领域问题 |
非图领域的应用受限 |
NoSQL并不是为了取代RDBMS,优势显著,缺点也较为明显,与RDBMS一起构建完整的数据库生态系统。
2.11 NewSQL浅谈
NewSQL指追求NoSQL的可扩展性同时能够支持关系模型(包括ACID特性)的关系型数据库系统,主要面向OLTP场景,能够支持SQL作为主要的使用语言。
NewSQL具有如下分类。
- 采用了新架构重新构建产品。
Shared-Nothing,多节点并发控制,分布式处理,利用复制实现容错,流失控制,Google Spanner,H-Store,VoltDB等。
- 采用Transparent Sharding中间件技术。
数据分片(sharding)的过程对于用户来说是透明的(transparent),用户的应用程序不需要作出变化。Oracle MySQL Proxy,MariaDB MaxSacle等。
- DAAS(Database-as-a-Service,数据库即服务)
云服务商提供的数据库产品,云服务商提供具备NewSQL特性的数据库产品。
Amazon Aurora,阿里云的Oceanbase,腾讯云的CynosDB。
2.12 传统数据库VS云数据库
Gartner的最新报告(2019年)指出,云将主导数据库市场的未来,到2022年,75%的数据库将被部署或迁移至云平台,只有5%的数据库会考虑部署在本地。
传统数据库具有建设和运维成本高、扩展不灵活、性能冗余、资源隔离差、集成性能差的特点。
云数据库具有易、稳、快、弹、密的特点。即:易使用易管理,业务敏捷上线;高可靠,业务零终端,跨地域容灾备份;数据读写时延迟低,快速响应业务需求;扩展性好,快速自动弹性伸缩;数据安全性好,全同态加密;
下面通过一个表格来直观的对比下,如下表所示。
表4 数据库对比
性能项目 |
自购服务器搭建数据库服务 |
云数据库 |
服务可用性 |
需要购买额外设备,自建自从,自建RAID。 |
根据业务需求和策略,自动调整资源,高效匹配业务要求。 |
数据库可靠性 |
需要购买额外设备,自建自从,自建RAID。 |
能够保证任何一个副本故障时快速进行数据迁移恢复。 |
系统安全性 |
需要购买昂贵的硬件设备和软件服务,需要自行检测和修复安全漏洞等。 |
防DDoS攻击,流量清洗;及时修复各种数据库安全漏洞。 |
数据库备份 |
需要购买设备,并自行搭建设置和后期维护。 |
支持自动备份,手动备份,自定义备份存储周期。 |
软硬件投入 |
数据库服务器成本相对较高,对于SQL Server需支付许可证费用。 |
无需投入软硬件成本,按需购买,弹性伸缩。 |
系统托管 |
需要自购服务器设备,如需实现主从,购买两台服务器,并进行自建。 |
无需托管。 |
维护成本 |
需要投入大量人力成本,招聘专业的DBA进行维护。 |
无需运维。 |
部署扩容 |
需采购和原设备匹配的硬件,需托管机房的配合,需部署设备,整体周期较长。 |
弹性扩容,快速升级,按需开通。 |
资源利用率 |
考虑峰值,资源利用率低。 |
按实际结算,100%利用率 |
三、关系型数据库架构演进
3.1 数据库架构发展
随着业务规模增大,数据库存储的数据量和承载的业务压力也不断增加,数据库的架构需要随之变化,为上层应用提供稳定和高效的数据服务。
图12 数据库架构
数据库架构主要分为主机架构和多级架构,单机架构又分为单主机和独立主机,多级架构又分为分组和分片。
3.2 单机架构
为了避免应用服务和数据库服务对资源的竞争,单机架构也从早期的单主机模式发展到数据库独立主机模式,把应用和数据服务分开。应用服务可以增加服务器数量,进行负载均衡,增大系统并发能力。
单机架构部署集中,运维方便。但是,在可扩展性方面,数据库单机架构扩展性只有纵向扩展(Scale-up)。通过增加硬件配置来提升性能,但单台主机的硬件可配置的资源会遇到上限。而且存在单点故障,扩容的时候往往需要停机扩容,服务停止。硬件故障导致整个服务不可用,甚至数据丢失,单机会遇到性能瓶颈。
图13 单机架构
3.3 分组架构-主备
主备机架构数据库部署在两台服务器,其中承担数据读写服务的服务器称为“主机”。另外一台服务器利用数据同步机制把主机的数据服务过来,称为“备机”。同一时刻,只有一台服务器对外提供数据服务。
主备架构具有应用不需要针对数据库故障来增加开发量,相对单机架构提升了数据容错性的优点。
主备架构的缺点包括:资源浪费,备机和主机同等配置,但长期范围内基本上资源限制,无法利用。性能压力还是集中在单机上,无法解决性能瓶颈问题。当出现故障时候,主备机切换需要一定的人工干预或者监控。
图14 主备架构
3.4 分组架构-主从
主从式架构部署模式和主备机模式相似,备机(Backup)上升为从机(Slave),对外提供一定的数据服务。它通过读写分离方式分散压力:写入、修改、删除操作,在写库(主机)上完成。把查询请求,分配到读库(从机)。
主从式架构具有提升资源利用率,适合读多写少的应用场景。在大并发读的使用场景,可以使用负载均衡在多个从机间进行平衡,从机的扩展性比较灵活,扩容操作不会影响到业务进行的优点。
但是,主从式架构特点也很明显,首先,延迟问题,数据同步到从机数据库时会有延迟,所以应用必须能够容忍短暂的不一致性。而且,对于一致性要求非常高的场景是不适合的。写操作的性能压力还是集中在主机上。当主机出现故障,需要实现主从切换,人工干预需要响应时间,自动切换复杂度较高。
图15 主从架构
3.5 分组架构-多主
多主架构数据库服务器互为主从,同时对外提供完整的数据服务。多主机架构资源利用率较高的同时降低了单点故障的风险。但是,双主机都接受写数据,要实现数据双向同步。双向复制同样会带来延迟问题,极端情况下有可能数据丢失。数据库数量增加会导致数据同步问题变得极为复杂,实际应用中多见双机模式。
图16 多主架构
3.6 共享存储多活架构
共享存储的多活架构(Shared-Disk)是一种特殊的多主架构数据库服务器共享数据存储,而多个服务器实现均衡负载。具有多个计算服务器提供高可用服务,提供高级别的可用性。可伸缩性,避免了服务器集群的单点故障问题。比较方便的横向扩展能够增加整体系统并行处理能力等特点。
但是,共享存储多活架构实现技术难度大。当存储器接口贷款达到饱和的时候,增加节点并不能获得更高的性能,存储IO容易成为整个系统的性能瓶颈。
图17 共享存储多活架构
3.7 分片(Sharding)架构
分片架构主要表现形式就是水平数据分片架构,它把数据分散在多个节点上的分片方案,每一个分片包括数据库的一部分,成为一个shard。多个节点都拥有相同的数据库结构,但不同分片的数据之间没有交集,所有分区数据的并集构成数据总体。
分片架构常见的分片算法有:根据列表值,范围取值和Hash值进行数据分片。具有数据分散在集群内的各个节点上,所有节点可以独立性工作的优点。
3.8 无共享(Shared-Nothing)架构
无共享架构是集群中每一个节点(处理单元)都完全拥有自己独立的CPU/内存/存储,不存在共享资源的架构。各节点(处理单元)处理自己本地的数据,处理结果可以向上层汇总或者通过通信协议在节点间流转。节点是相互独立的,扩展能力强。整个集群拥有强大的并行处理能力。
3.9 MPP架构(Massively Parallel Processing)
大规模并行处理(Massively Parallel Processing)是将任务并行的分散到多个服务器和节点上,在每个节点上计算完成后,将各自部分的结果汇总在一起得到最终的结果。具有任务并行执行,分布式计算的特点。
常见的MPP产品,无共享Master: Vertica, Teradata以及共享Master: Greenplum, Netezza。
3.10 数据库架构特点对比
下面通过一个表格来直观的对比下,如下表所示。
表5 数据库架构特点对比
特点 |
单机 |
主备 |
主从 |
多主 |
分片 |
高可用性 |
差 |
一般 |
较好 |
好 |
好 |
读写性能 |
依赖于单主机的硬件性能瓶颈 |
依赖于单主机的硬件性能瓶颈 |
利用读写分离,写性能受主机限制,读性能可以通过增加从机数量来提升并发能力。 |
多个主机能够同时提供读写服务,具备较好的读写能力。 |
Shared-Nothing架构提供了出色的分布式计算能力,具备强大的并行处理能力。 |
数据一致性 |
不存在数据一致性问题 |
利用数据同步机制在主备机之间进行同步,存在数据延迟问题和数据丢失风险。 |
同主备模式,而且随着从机数量的增加,数据延迟问题和数据丢失风险更为突出。 |
多主机之间需要进行数据双向同步,所以容易产生数据不一致问题。但对于Shared-Disk架构不存在数据一致性问题。 |
基于sharding技术,数据分散在各节点上,节点之间不需要数据同步,所以不存在数据一致性问题。 |
可扩展性 |
只能纵向扩展,会遇到单机硬件性能瓶颈 |
只能纵向扩展,同样遇到单机硬件性能瓶颈。 |
从机可以通过横行扩展来提升并发读能力。 |
扩展性好,但是主机数量增加,会导致数据同步的复杂性急剧升高。 |
理论上可以实现线性扩展,扩展性最好。 |
四、关系型数据库主流应用场景
4.1 联机事物处理(OnLine Transaction Processing)
OLTP是传统关系数据库的主要应用,面向基本的,日常的事物处理,例如:银行储蓄业务的存取交易,转账交易等。它的特点包括:
- 大吞吐量:大量的短在线事物(插入、更新、删除),非常快速的查询处理。
- 高并发:(准)实时响应。
下面来看一下典型的OLTP场景,包括:零售系统、金融交易系统、火车票销售系统、秒杀活动。
4.2 联机分析处理(OnLine Analytical Processing)
联机分析处理的概念最早是E.F.Codd于1993年相对于OLTP系统而提出的。它是指对数据的查询和分析操作,通常对大量的历史数据查询和分析。涉及到的历史周期比较长,数据量大,在不同层级上的汇总,聚合操作使得事务处理操作比较复杂。
联机分析处理有如下特点:
- 主要面向侧重于复杂查询,回答一些“战略性”的问题。
- 数据处理方面聚焦于数据的聚合,汇总,分组计算,窗口计算等“分析型”数据加工和操作。
- 从多维度去使用和分析数据。
联机分析处理的典型的OLAP场景包括:报表系统,CRM系统、金融风险预测预警系统、反洗钱系统、数据集市,数据仓库。
4.3 OLTP和OLAP对比分析
下面通过一个表格来直观的看一下OLTP和OLAP的对比分析,如下表所示。
表6 OLTP和OLAP对比分析
分类 |
OLTP |
OLAP |
分析粒度 |
细节的 |
细节的,综合的或提炼的 |
时效性 |
在存取瞬间是准确的 |
代表过去的数据 |
数据更新需求 |
可更新 |
一般情况,无需更新 |
操作可预知性 |
操作需求事先可知道 |
操作需求事先可能不知道 |
实时性 |
对性能要求高,响应毫秒级、秒级 |
对性能要求相对宽松,响应分钟级、小时级 |
数据量 |
一个时刻操作一条或几条记录,数据量小 |
一个时刻操作一集合,数据量大 |
驱动方式 |
事务驱动 |
分析驱动 |
应用类型 |
面向应用 |
面向分析 |
应用场景 |
支持日常运营 |
支持管理需求 |
典型应用 |
银行核心系统、信用卡系统 |
ACRM、风险管理 |
4.4 数据库性能衡量指标
TPC(Transaction Processing Performance Council,事务处理性能委员会)的职责是制定商务应用基准测试标准(Benchmark)的规范、性能和价格度量,并管理测试结果的发布。制定的是标准规范而不是代码,任何厂家依据规范最优地构造自己系统进行评测。还推出了很多基准测试标准,其中针对OLTP和OLAP分别有两个规范。
(1)TPC-C规范
TPC-C规范面向OLTP系统,主要包括两个指标,流量指标:tpmC(tpm-transactionsper minuete,即每分钟测试系统处理的事务数量)。性价比指标:Price(测试系统价格)/tpmC。
(2)TPC-H规范
TPC-H规范面向OLAP类系统。流量指标:qphH-Query per hour,即每小时处理的复杂查询数量。需要考虑测试数据集合大小,分为不同的测试数据集,指定了22个查询语句,可以根据产品微调。测试场景:数据加载,Power能力测试和Throuanut测试。
五、总结
本篇文章主要介绍了数据库、数据库系统和数据管理系统的基本概念,对数据库几十年的发展历史进行了回顾,详细介绍了数据库从早期的网状模型,层次模型发展到关系型模型的历程,并对近年来新兴的NoSQL和NewSQL概念进行了介绍。对关系型数据库的主要架构进行了对比分析和介绍,对于不同场景下各种架构的优缺点进行了简单说明。最后对关系型数据的主流应用场景OLTP和OLAP进行了介绍和对比说明。
本文整理自华为云社区【内容共创系列】活动。
查看活动详情:https://bbs.huaweicloud.com/blogs/314887
相关任务详情:数据库介绍
- 点赞
- 收藏
- 关注作者
评论(0)