常见数据库分类、架构及其使用场景等概述

0    60    5

Tags:

👉 本文共约16066个字,系统预计阅读时间或需61分钟。

数据库分类

常见数据库分类、架构及其使用场景等概述

常见数据库分类、架构及其使用场景等概述

常见数据库分类、架构及其使用场景等概述

常见数据库分类、架构及其使用场景等概述

常见数据库分类、架构及其使用场景等概述

image-20220418152801189

数据库架构分类

常见数据库分类、架构及其使用场景等概述

数据库的划分经过多年的演进,大概有三种架构。

第一种是单体数据库(Shared-Everything),所谓单体数据库就像之前我们经常提到的Oracle、PostgreSQL、MySQL这种单机的数据库,单个实例能够提供独立的服务,主备机通过流复制来做HA,这是传统的架构。

第二种是共享存储架构(Shared-Storage),多个数据库实例同时访问一份存储,数据是存储在专门的存储设备中,这里的存储设备一般是指磁盘阵列或者类似于这样专用的存储设备,现在我们能看得到的包括Oracle RAC、SybaseIQ都是这样的架构。

第三种是无共享(Shared-Nothing),也就是我们常说的MPP。每个DN节点存储一个数据分片,在DN节点之上会有另外一层节点,这层节点在不同的数据库中有不同的名字,但是它的作用其实是一样的,都是接收业务请求,然后分发,同时对业务请求进行返回。TeraData、GreenPlum、TBase、TDSQL、TiDB、Hadoop都是属于这种架构。

常见数据库分类、架构及其使用场景等概述

常见数据库分类、架构及其使用场景等概述

随着云业务形态的诞生,这两年在传统的数据库架构基础上,产生一种比较流行的新架构--云原生架构,日志即数据库。

img

它会把数据库的业务逻辑沉到底层的存储节点里面去,存储节点和上面的计算节点是进行逻辑上的分离,其实也就是物理上的分离,另外一种叫法是计算与存储分离。在下层的存储集群之间,通过一致性协议来保证多个副本之间的一致性,统一对上层的数据节点提供一个可靠的存储服务。这里补充说明下:数据库节点就是把数据库的业务逻辑,包括SQL解析及SQL的执行都做到上层去。类似的产品现在也比较多,基本上几个大的云厂商都有自己的产品。主要有两个技术优点,1、可以做到存储计算分离,存储和计算可以做到单独扩容,2、它可以实现存储的超卖,这在云上这是一个比较有价值的能力。

分布式架构

https://cloud.tencent.com/developer/article/1847790

分布式数据库有两大流派,NEWSQL和POSTGRESQL-XC ,NEWSQL 的分布式主流的理论来源自 GOOGLE 的分布式数据库spanner,以及相关理论的白皮书,而另一派的分布式数据库来自于POSTGRESQL-XC, 今天我们看看到底POSTGRESQL-XC 这个流派的方式是什么,有什么特点,当下那些分布式数据库采用了POSTGRESQL-XC。

POSTGRESQL-XC 的研究自2002年开始,主要是日本的NTT公司进行相关的研究,踏实基于水平可伸缩的数据库系统share nothing无架构的方式. 最早POSTGRESQL-XC 最早的名字叫RiTaDB, 后来改名为POSTGRESQL-XC, 支持全局事务,表分区,复制以及查询计划在各个节点并行执行的shared nothing 架构.

在数据库架构中有一种独特的结构被称为星型结构,在很多的数据库仓库和OLTP的数据库结构中都可以发现其中的身影,星型的结构一般存在较少的大表和一些普通的表,或者数据量较少的表. 例如,产品目录表可能是普通表,而销售的订单表是BIG TABLE.

POSTGRES -XC 的结构主要解决的是大表的问题,将大表通过关键主键的方式来将一张大表分布在不同的数据存储节点, 主要对于写压力的释放还是通过将数据分散在不同的sharding 分片中来进行的.

常见数据库分类、架构及其使用场景等概述

NewSQL 特性

常见数据库分类、架构及其使用场景等概述

NewSQL⼀词最早由451 Group的分析师Matthew Aslett在研究论⽂中提出。NewSQL是一类现代关系型的DBMS,旨在为NoSQL的OLTP读写负载提供相同的可扩展性能,同时仍然提供事务的ACID保证。简单来讲,NewSQL就是在传统关系型数据库上集成了NoSQL强大的可扩展性。传统的SQL架构设计基因中是没有分布式的,而NewSQL生于云时代,天生就是分布式架构。NewSQL的优点在于兼具NoSQL对海量数据的存储管理能力和传统关系数据库的ACID、SQL等特性,但其也有局限性,即不具有SQL系统的通用性,对传统SQL系统的丰富工具仅仅提供部分访问。⽬前较为知名的NewSQL数据库有Google Spanner、Amazon Aurora、CockroachDB。

  • NoSQL 数据库不支持 ACID 特性, 在很多场合下,ACID 特性使系统在中断的情况下也能够保证在线事务的准确执行;
  • 大多数 NoSQL 数据库提供的功能比较简单,这就需要用户在应用层添加更多的功能;
  • NoSQL 数据库没有统一的查询语言,不支持 SQL 查询,这也在一定程度上增加了开发者的负担。

为了解决上述难题,NewSQL 数据库应运而生。NewSQL 数据库不仅具有 NoSQL 数据库对海量数据的存储管理能力,同时还保留了传统数据库支持的 ACID 和 SQL 特性。

NewSQL 是一类新的关系型数据库, 是各种新的可扩展和高性能的数据库的简称。

https://zhuanlan.zhihu.com/p/95650799

newSQL 提供了与 noSQL 相同的可扩展性,而且仍基于关系模型,还保留了极其成熟的 SQL 作为查询语言,保证了ACID事务特性。

简单来讲,newSQL 就是在传统关系型数据库上集成了 noSQL 强大的可扩展性。

传统的SQL架构设计基因中是没有分布式的,而 newSQL 生于云时代,天生就是分布式架构。

noSQL 的主要特性:

  • SQL 支持,支持复杂查询和大数据分析。
  • 支持 ACID 事务,支持隔离级别。
  • 弹性伸缩,扩容缩容对于业务层完全透明。
  • 高可用,自动容灾。

img

MPP架构

什么是MPP?

MPP (Massively Parallel Processing),即大规模并行处理或海量并行处理。简单来说,MPP是将任务并行的分散到多个服务器和节点上,在每个节点上计算完成后,将各自部分的结果汇总在一起得到最终的结果(与Hadoop相似)。

MPP架构特征

  • 任务并行执行;
  • 数据分布式存储(本地化);
  • 分布式计算;
  • 私有资源;
  • 横向扩展;
  • Shared Nothing架构。

什么是MPP数据库?

MPP数据库是一款 Shared Nothing架构的分布式并行结构化数据库集群,具备高性能、高可用、高扩展特性,可以为超大规模数据管理提供高性价比的通用计算平台,并广泛地用于支撑各类数据仓库系统、BI 系统和决策支持系统

MPP数据库的使用场景?

MPP数据库有对SQL的完整兼容和一些事务的处理能力,对于用户来说,在实际的使用场景中,如果数据扩展需求不是特别大,需要的处理节点不多,数据都是结构化的数据,习惯使用传统的RDBMS的很多特性的场景,可以考虑MPP,例如Greenplum/Gbase等。

主流 MPP 架构数据库介绍

常见数据库分类、架构及其使用场景等概述

系统架构之SMP、NUMA和MPP

主流的系统架构主要有三类:对称多处理结构(SMP),非一致存储访问结构(NUMA)和海量并行处理架构(MPP)。其对应的特点与不足分别如下:

  • SMP:

较为典型的包括Oracle、MySQL等

特点:

存储,包括CPU、内存和IO都是共享的。在一台机器就能支撑起整个网站的Web时代,SMP架构是非常流行的,足以支撑前端业务。

不足:

扩展能力有限。随着业务的扩大,数据量的增长,在业务场景上就有了很大的限制。

  • NUMA

特点:

拥有多个CPU模块,每个模块由多个CPU组成,有独立的本地内存;节点之间通过互联模块进行连接和信息交互,较好解决SMP系统的扩展问题。

不足:

互联模块访问效率和本地内存访问不在一个效率层级,系统性能无法随着CPU数线性增加。

  • MPP

这个是我们今天要讲解的重点,也是Greenplum的架构。

特点:

MPP是采用SMP组成的多个服务器,多个服务器共同完成任务。在硬件使用上可以发挥SMP架构的优势,多节点并行处理时,内存、CPU、网络、IO、磁盘均不共享,即Share-Nothing架构,每个节点只访问本地内存和存储,节点信息交互和节点本身是并行处理的。所有数据节点角色一样,可以提升并行计算能力。

不足:

MPP架构也存在一些不足,如果多台服务器在进行并行处理时,如果有一台服务器出现部分性能下降,会影响到整个MPP集群的性能,即木桶的短板效应。MPP架构集群规模不能过大,不能像Hadoop那样,几千个集群同时运行某个查询逻辑。此外,并发度不能过高。MPP架构正常情况下都是进行两阶段事务提交的,需要有一个事务汇总和底层事务查询的过程,如果并发过高,资源损耗会过大,会影响到整体系统的响应。

不同的系统架构有其擅长的应用场景,很难说某个架构更好,在其擅长的应用场景下,都可以发挥其优势。

多模数据库

多模数据库(Multi-Model Database)是指同一个数据库支持多个存储引擎,可以同时满足应用程序对于结构化、半结构化、非结构化数据的统一管理需求。通常来说,结构化数据特指表单类型的数据存储结构,典型应用包括银行核心交易等传统业务;而半结构化数据则在用户画像、物联网设备日志采集、应用点击流分析等场景中得到大规模使用;非结构化数据对应着海量的图片、视频、和文档处理等业务,在金融科技的发展下增长迅速。多模式数据管理能力,使得数据库能够进行跨部门、跨业务的数据统一存储与管理,实现多业务数据融合,支撑多样化的应用服务。在架构上,多模 Multi-model也是针对云数据库需求的,使得数据库使用一套数据管理体系可以支撑多种数据类型,因此支持多种业务模式,大大降低使用和运维的成本。

常见数据库分类、架构及其使用场景等概述

国产数据库

https://mp.weixin.qq.com/s/0fsEBzMbLxEd14e26TzjXA

图片

常见数据库分类、架构及其使用场景等概述

常见数据库分类、架构及其使用场景等概述

OLAP、OLTP、HTAP

https://www.xmmup.com/oltpolaphehtapdequbie.html

行存储和列存储

将表放入存储系统中的方法有两种:行存储(Row Storage)和列存储(Column Storage),绝大部分数据库是采用行存储的。行存储法是将各行放入连续的物理位置,这很像传统的记录和文件系统,然后由数据库引擎根据每个查询提取需要的列。列存储法是将数据按照列存储到数据库中,与行存储类似。列存储是相对于传统关系型数据库的行存储来说的,简单来说两者的区别就是如何组织表,列存储将所有记录中相同字段的数据聚合存储,而行存储将每条记录的所有字段的数据聚合存储。Sybase在2004年左右就推出了列存储的Sybase IQ数据库系统,主要用于在线分析、数据挖掘等查询密集型应用。

列存储不同于传统的关系型数据库,其数据在表中是按行存储的,列方式所带来的重要好处之一就是,由于查询中的选择规则是通过列来定义的,因此整个数据库是自动索引化的。按列存储每个字段的数据聚集存储,在查询时,只需要少数几个字段的时候,能大大减少读取的数据量,一个字段的数据聚集存储,那就更容易为这种聚集存储设计更好的压缩或解压算法。

列存储(Column-based)是相对于行存储(Row-based)来说的。传统的数据库设计都是基于行存储,如 Oracle、DB2、MySQL、SQL Server 等,在基于行存储的数据库中,数据是以行数据为基础逻辑存储单元存储的,同一行的数据在存储介质中以连续存储的形式存在。

在实际应用中我们会发现,行式数据库在读取数据时存在一个固有的缺陷,比如,选择查询的目标虽然只涉及少数几个字段,但这些目标数据埋藏在各行数据单元中,而行单元往往又特别大,应用程序必须读取每一条完整的行记录,这使得读取效率大大降低。对此,行式数据库给出的优化方案是增加索引,在 OLTP 类型的应用中,通过索引机制或给表分区等手段简化查询操作步骤,提升查询效率。

针对海量数据背景的 OLAP 应用(例如分布式数据库、数据仓库等),行存储的数据库就有些力不从心了,因为行式数据库建立索引和物化视图需要花费大量时间和资源,所以还是不划算的,无法从根本上解决查询性能和维护成本的问题,也不适用于数据仓库等应用场景,因此后来出现了基于列存储的数据库。

对于数据仓库和分布式数据库来说,大部分情况下会先从各个数据源汇总数据,然后进行分析和反馈,大多数操作是围绕同一个字段(属性)进行的,而当查询某属性的数据记录时,列式数据库只需返回与列属性相关的值。在大数据量查询场景中,列式数据库可在内存中高效组装各列的值,最终形成关系记录集,可以显著减少 I/O 消耗并降低查询响应时间,非常适合数据仓库和分布式应用。

本人提供Oracle、MySQL、PG等数据库的培训和考证业务,私聊QQ646634621或微信db_bao,谢谢!

新兴的 HBase、HP Vertica、SAP HANA、Pivotal Greenplum○一、TiDB 等分布式数据库均支持列存储。其中 SAP HANA、Pivotal Greenplum、TiDB 是同时支持行存储和列存储的数据库。在基于列存储的数据库中,数据是以列为基础逻辑存储单元存储的,同一列的数据在存储介质中以连续存储形式存在。行存储和列存储的差异如图 1-2 所示。

常见数据库分类、架构及其使用场景等概述

行存储和列存储各有各的优点,有不同的应用场景。因为列存储是新兴的数据库存储方式,所以支持的数据库还不是很多,行存储的适用场景如下。
1)需要随机地增、删、改、查操作。
2)需要在行中选取所有属性的查询操作。
3)需要频繁插入或更新的操作,其操作与索引和行的大小更为相关。

列存储的适用场景如下。
1)查询过程中,可针对各列的运算并发执行,在内存中聚合完整的记录集,降低查询响应时间。
2)在数据中高效查找数据,无须维护索引(任何列都能作为索引),查询过程中能够尽量减少无关 I/O,避免全表扫描。
3)因为各列独立存储,且数据类型已知,所以可以针对该列的数据类型、数据量大小等因素动态选择压缩算法,以提高物理存储利用率。如果某一列没有数据,在列存储时,就可以不存储该列的值,这比行存储更节省空间。

应用行存储的数据库系统称为行式数据库,同理,应用列存储的数据库系统称为列式数据库。随着列式数据库的发展,传统的行式数据库加入了列式存储的支持,形成具有两种存储方式的数据库系统。

传统的关系型数据库,如Oracle、DB2、MySQL、SQL Server等采用行式存储法,当然传统的关系型数据库也在不断发展中。随着Oracle 12c推出了In Memory组件,使得Oracle数据库具有了双模式数据存放方式,从而能够实现对混合类型应用的支持:传统的以行形式保存的数据满足OLTP应用;列形式保存的数据满足以查询为主的OLAP应用。新兴的Hbase、HP Vertica、EMC Greenplum等分布式数据库采用列存储,当然这些数据库也有对行式存储的支持比如HP Vertica。随着传统关系型数据库与新兴的分布式数据库不断的发展,列式存储与行式存储会不断融合,数据库系统会呈现双模式数据存放方式,这也是商业竞争的需要。

行存储和列存储的区别如下表所示:

表 2-4 列存储和行存储的区别

项目列存储(Column Storage)行存储(Row Storage)
存储模型DSM(Decomposition Storage Model)NSM(N-ary Storage Model)
存储数据的方式按列存储,一行数据包含一个列或者多个列,每个列一单独一个cell来存储数据。按行存储,把一行数据作为一个整体来存储。
索引数据即索引没有索引的查询使用大量I/O
使用场合适用于OLAP、数据仓库、数据挖掘等查询密集型应用,不适合用在OLTP,或者更新操作,尤其是插入、删除操作频繁的场合。适用于OLTP系统,插入更新等频繁的系统。
优点(1)每个字段的数据聚集存储,在查询只需要少数几个字段的时候,能大大减少读取的数据量,大幅降低系统的I/O,尤其是在海量数据查询时,I/O向来是系统的主要瓶颈之一,据C-Store、MonetDB的作者调查和分析,查询密集型应用的特点之一就是查询一般只关心少数几个字段,而相对应的,NSM中每次必须读取整条记录;
(2)既然是一个字段的数据聚集存储,那就更容易为这种聚集存储设计更好的压缩/解压算法,换句话说,列式存储天生就是适合压缩,因为同一列里面的数据类型是相同。
从查询来说,行存储比较适合随机查询,并且RDBMS大多提供二级索引,在整行数据的读取上,要优于列式存储。

由于设计上的不同,列式数据库在并行查询处理和压缩上更有优势。而且数据是以列为单元存储,完全不用考虑数据建模或者说建模更简单了。要查询计算哪些列上的数据,直接读取列就行。没有万能的数据库,列式数据库也并非万能,只不过给DBA提供了更多的选择,DBA需根据自己的应用场景自行选择。

数据库对比及使用场景

一、数据库类型

数据库类型国别是否开源
Oracle关系型数据库美国
mysql关系型数据库美国
PostgreSQL对象-关系型数据库美国
达梦DM关系型数据库中国
南大通用Gbase关系型数据库中国

ps:关系型数据库大家应该都知道,关于对象-关系型数据库是指数据库管理系统既具备关系数据库的功能,同时又支持面向对象的特征:抽象数据类型(ADT),对象之间的继承(概括)关系、包含(聚集)关系,对象的封装,对象(包括方法和成员变量)在数据库中的可持久性,对象的消息驱动特性,对象的多态性等

二、授权方式

数据库授权方式
Oracle两种方式:按CPU(Process)数和按⽤户数(Named User Plus)。前⼀种⽅式⼀般⽤于⽤户数不确定或者⽤户数量很⼤的情况,典型的如互联⽹环境,⽽后⼀种则通常被⽤于⽤户数确定或者较少的情况
mysql1、 MySQL社区版,开源免费
2、MySQL企业版,需付费,可以试用30天。
PostgreSQLPostgreSQL提供了单个完整功能的版本,而不像MySQL那样提供了多个不同的社区版、商业版与企业版。
PostgreSQL基于自由的BSD/MIT许可,组织可以使用、复制、修改和重新分发代码,只需要提供一个版权声明即可。
达梦DM购买永久授权,费用依据具体项目和配置,可提供测试版
南大通用Gbase购买永久授权,费用依据具体项目和配置

三、适用系统

数据库适用系统
OracleLinux和windows等
mysqlLinux和windows等
PostgreSQLPostgreSQL操作系统支持WINDOWS、Linux、UNIX、MAC OS X、BSD。
达梦DM达梦DM支持以下CPU平台:x86(比如centos,readhat,win32,win64等)、飞腾、龙芯、鲲鹏、海光、兆芯。
南大通用Gbase南大通用Gbase支持标准Linux 内核:Cent OS,Redhat, Suse等支持基于x86-64和ARM的标准PC服务器

四、最低硬件配置

数据库硬件配置
Oracleoracle软件非常大,对硬件要求很高。
CPU:最低主频550MHZ以上
内存:1GB以上
磁盘空间:基本安装需4.55G,高级安装需4.92G
mysqlmysql对硬件配置要求较低
PostgreSQLPostgreSQL对硬件配置要求较低
达梦DMDM8最低配置要求 CPU: Intel Pentium4(建议Pentium 41.6G以上)处理器 内存:256M(建议512MI以 上) 硬盘:5G以上可用空间 网卡:10M以 上支持TCP/IP协议的网卡 操作系统:Windows(简体中文服务 器版sp2以上)/Linux(glibc2.3以上,内核2.6, 安装KDE/GNOME桌面环境,建议预先安装UnixODBC组件) 更具体参考:https://eco.dameng.com/docs/zh-cn/pm/installation-introduction.html
南大通用GbaseGBase 8s V8.8最低配置要求(未找到GBase 8a的):处理器:最低:1×2 核 2.0GHz 推荐: 4×4 核 3.0GHz 内存: 最低:4GB 推荐:64GB 或更多 硬盘: 最低:100GB 推荐:1TB 光驱: 最低:CD-ROM 推荐:CD-ROM GBase 8s 产品需要部署于 UOS V20 操作系统,鲲鹏920芯片上,建议以 Software Development Workstation 模式安装

五、适用场景

数据库适用场景
OracleOracle适用场景如下:大型数据库软件,收费,支撑体系完善,强大,安全性高(适用于服务器比较强大的单节点或者集群环境)。
大都集中于一些大型企业,一些传统行业的数据化业务中,比如:银行、金融、证券这一类,对于可用性,安全性,健壮性,实时性要求极高的业务。
MySQLMySQL适用场景如下:轻量级数据库,大都集中于互联网方向,主要集中在以下几类:web网站系统(企业官网),日志记录系统,嵌入式系统
PostgreSQLPostgreSQL数据库的主要有以下应用场景:
(1)企业数据库,如ERP
(2)含 LBS 的应用,如大型游戏、O2O 等应用需要支持世界地图、附近的商家,两个点的距离等能力
(3)数据仓库和大数据
(4)建站或 App
(5)广泛用于读写速度高和数据一致性高的大型系统
(6)PostgreSQL性能最适用于需要执行复杂查询的系统
SQL Server传统制造业(微电子、半导体)、药企、车企(比亚迪)
tidb1、对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景
2、对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景
3、Real-time HTAP 场景
4、数据汇聚、二次加工处理的场景
更多请参考:https://docs.pingcap.com/zh/tidb/stable/overview
OceanBase
达梦DM达梦DM8适用场景如下:
(1)DM8全面支持 ANSI SQL 标准和主流编程语言接口/开发框架。行列融合存储技术,在兼顾 OLAP 和 OLTP 的同时,满足 HTAP 混合应用场景。核心场景包括:
a)高性能交易处理需求场景
b)高可用需求场景
c)大规模数据分析需求场景
d)高强度混合型负载需求场景
e)数据库平滑迁移 f)数据库的统一云化管理和智能运维需求场景
(2)更多产品适用场景可参考:https://www.dameng.com/list_17.html
南大通用Gbase(1)GBase 8a是面向大数据分析类应用领域的一款高性能国产新型数据库产品,用于满足数据密集型行业日益增大的数据查询、数据统计、数据分析、数据挖掘和数据备份等需求,可用做数据仓库系统、BI系统和决策支持系统的承载数据库。
(2)GBase 8s适用于OLTP 应用场景,包括金融、电信行业的关键核心业务系统,安全、党政、国防等行业对信息安全性有较高要求的信息系统,以及大型企业的经营类、管理类信息系统,能够提供7*24小时不间断运行处理能力,在80%以上场景中可以替代国际主流数据库。
更多产品适用场景请参考:http://www.gbase.cn/pro/361.html

从行业来说,通讯、金融、交通、互联网、物联网、药企、车企、传统制造业 等等都是数据库应用场景

  • Oracle:银行、证券
    优势:高性能、高可靠性。Oracle数据库作为元老级的产品,的确拥有其过人之处,直到现在去IOE大当其道的今天,仍然在众多的核心应用系统中存在。
    缺点:费用昂贵,需要比较专业的DBA。对主机硬件配置要求较高。

  • MySQL:互联网、企业官网
    优势:免费,基于主从复制,高可用架构比较灵活。对硬件配置要求较低。
    缺点:表数据量大时需要做分库分表,否则对性能影响较大。

  • PG:gis系统
    免费,开源,插件多,主从为物理复制,高可用架构比较灵活,可以有分布式数据库PGXL、GP等。对硬件配置要求较低。

  • SQL Server:传统制造业(微电子、半导体)、药企、车企(比亚迪)、
    优势:
    缺点:2017版本之前只能用于Windows主机。

  • TiDB:
    优势:
    缺点:
    https://docs.pingcap.com/zh/tidb/stable/overview

  • OB:
    优势:
    缺点:
    案例:中国石化建设新一代分布式智慧加油系统

  • MongoDB:互联网、物联网、游戏
    在物联网、游戏等场景大量使用MongoDB数据库。例如,四川省某石油客户使用该数据库存储采油站的大量数据,因其JSON松散式的数据格式,利于数据的任意保存、快速分析、分片存储,得到大量公司的应用。
    其优势:高性能、低成本、易使用。MongoDB通过索引加速检索的性能,利于X86服务器进行分片的存储,JSON数据格式不需要预先定义。

六、总结

最后总结下国外主流数据库和国内数据库的对比详情表格,希望国产数据库能早日能完全替代国外数据库!
常见数据库分类、架构及其使用场景等概述

数据库架构选型的思考

常见数据库分类、架构及其使用场景等概述

对于⼀个线上⾼并发的服务来说,要考虑以下⼏点:
● 稳定。对于任何⼀个线上服务来说,可以容忍交易稍微慢⼀点,但⼀定不可能容忍频繁宕机。稳定是第⼀要务,脱离了稳定,效率没有任何意义;
● 效率。在系统⾮常稳定的情况下,速度越快,意味着⽤⼾体验越好。⽐如外卖下单,秒接单的⽤⼾感受⼀定很好。如果 30 分之后才接单,⽤⼾会想到底是系统出了问题还是外卖⼩哥偷懒;

● 成本。当稳定有了,效率也有了,就要思考花的成本值不值?因为成本降下来才能赚到收益;
● 安全。安全是⼀个⼤家都绕不开的问题。但凡做交易,⼤家都担⼼⾃⼰的数据被泄露。
所以在数据库上⾯,我们最关注的就是保稳定、提效率、降成本、保安全。除了这四项之外,还有就是开源。在做技术选型时,我希望这个数据库是开源的,因为当我遇到⼀些问题,是有社区⽀持的。另外当我想为产品做⼀些贡献时,是可以和社区⼀起迭代的。

1、保稳定
在稳定⽅⾯,我们会考虑这⼏⽅⾯:
● 这个数据库能不能做多活,能否有⼀些附加诊断以及⾼可⽤能⼒?
● 运维时,做监控告警是否容易?
● 是不是平滑滚动的升级?对业务有没有影响?
● 做数据迁移的时候,有没有问题?
● 数据校验好不好做?
● 运维上弹性扩缩容的效率如何?
2、提效率
性能⽅⾯,我们最关注四点:
● 第⼀,低延迟;
● 第⼆,事务模型是不是我们平常使⽤的。⼤家都知道 MySQL 是⼀个悲观事务模型,我希望的是迁移到新型的数据库上,还能保持原来的使⽤习惯;

● 第三,⾼ QPS。就是说这个数据库能否⽀持⾼的访问量。⽐如做⼀个活动,今晚流量涨了三倍,这种情况数据库能不能抗得住?抗不住会有什么样的场景?是完全挂掉还是服务端有⾃动的性能保护机制;
● 第四,能⽀撑海量数据。如果不能⽀撑海量数据,意味着需要提前跟业务沟通基础设计,确定能否先分库分表以及相应的分⽚数量。
3、降成本
成本⽅⾯,主要考虑三个⽅⾯:
● 第⼀,应⽤接⼊成本,指接⼊数据库容易不容易,是否需要提前沟通跟培训;
● 第⼆,硬件成本,就是 CPU + 内存 + 磁盘。像有⼀款分布式数据库,它是⼀个 Scaleup 类型的数据库,它要求的内存是 384 G,但并不是所有的互联⽹公司都能负担这种⾼配机型的成本。众所周知,在⼀般的机型上⼤概要花费四万多成本,像互联⽹⾏业常⽤的机器,⼤概 128G 内存,30 核 CPU 或 40 核 CPU,带⼀张 3.2T 的 PCIE 卡。但如果采⽤⾼密度机型,其价格会呈指数级上涨。所以在这种场景下,所选型的数据库会导致⾮常⾼的硬件成本;
● 第三,⽹络带宽。
4、保安全
安全⽅⾯,有三点需要考虑:
● 第⼀,数据库是否有审计功能。拿⾦融⾏业数据库举例,⽤⼾肯定希望能审计出来谁访问了这些数据,以及对这些数据做了什么操作;
● 第⼆,数据是可恢复的,不管⽤⼾做了什么异常操作,最后的数据都可以通过备份找回;
● 第三,数据库的权限。我们要考虑的是权限的粒度会有多细,因为⼀些特殊场景下我们希望数据库的呈现精细到表级别,甚⾄字段级别。⽐如个⼈信息⾥的⾝份证信息、⼿机号,还有密码帐号,这些涉及个⼈隐私的信息是不希望展⽰给 DBA 或其他 RD的。

数据库架构技术选型

常见数据库分类、架构及其使用场景等概述

技术选型:场景区分

当用户面对数据库选型时,首先是做场景的大致区分。这里我们将业务场景分为三种类型:

❖ 通用场景

第一类为通用场景,是具有较为普遍的意义,绝大多数业务场景都是适用的。这里面包含了企业常规的业务系统,也包括像互联网应用、实时交互分析等场景。

❖ 分析场景

第二类为分析场景,这类场景比较明确,是对企业内包含线上活跃和历史在内的全量数据进行实时或批量的分析。这类场景主要强调对数据的加工处理能力,并将结果在数据可视化平台进行输出。

❖ 特定场景

第三类较为特殊,此部分场景属于相对较窄的范围,属于特定方向的数据应用。如比较常见的图、时序等。这类应用有别于传统的业务应用。

技术选型:通用场景

针对通用场景,可进一步安装数据模型、标准SQL访问及ACID能力做进一步区分。大的方面可分为两类:

❖ 非关系模型+无SQL+无ACID

此类产品提供较为多元的数据访问需求。随着互联网兴起,针对非关系模型的数据受到更多的重视。这类数据通常提供专有访问接口且对ACID能力没有需求,更多强调是对异构数据的存储和扩展能力。其根据存储数据模型,又可进一步细分为KV、文档型、宽列型等。这类产品与后面谈到的特有场景数据库产品不同,其往往是作为生产业务系统中的一部分,但两者有时是有交叉的。

❖ 关系模型+SQL+ACID

绝大多数数据库产品都是在此分类,它们提供结构化数据的存储,提供SQL访问接口,支持ACID能力,强调事务等能力。这类产品种类众多、架构各异,因此后续按扩展能力、可用性水平等做进一步划分。

1).按扩展性/可用性划分

从这个维度进一步细分通用数据库场景产品,可按照其架构分为单机、共享、集群、分布式等多种架构。

  • 单机架构

    单机数据库是大家最为熟悉的,提供基础数据库功能。从扩展性来说,一般只具有Scale UP的能力,通过升级硬件来进行扩展其性能。从可用性角度来看,单机的可用性有限,一般作为非核心系统或者作为研发、测试用途。

  • 共享架构

    共享架构数据库,是针对单机库的升级,通过共享存储资源,将上层计算资源实现水平扩展,可以提供更好的性能及可用性表现。从扩展性来说,其能提供计算能力的有限扩展,存储能力扩展则取决于底层存储。从可用性来看,可以解决实例级、主机级故障,提供整体可用性。

  • 集群架构

    集群架构数据库,是提供了在单机/共享模式之上的数据库架构。通过复制技术,可实现数据库主从的工作模式。从扩展性上看,这种方式可提供提供一定范围内计算资源的水平扩展,这里强调是一定范围是指计算能力不能“完整扩展”,如仅能提供只读的扩展能力。对可用性来说,通过集群可实现主出现问题时,切换到从的能力,进而提升整体可用性。

  • 分布式架构

    分布式架构数据库,近些年来很火热,其突破单机、共享、集群架构下的数据库局限。通过存算分离技术,可实现上层计算资源、底层存储资源的水平扩展,进而满足更高性能、更大容量的承载。从扩展性来看,其扩展能力要远远优于前几种架构。从可用性来看,分布式架构因其多副本技术等,原生提供了更高的可用性。但这部分的具体实现技术上有着不同的方式,下面针对这部分加以说明。

2).按规模/一致性/侵入性/负载特征

  • 原生分布式架构

    原生分布式架构,通过存算分离技术,可实现计算与存储的独立扩展。但受到其管理能力限制,一般扩展能力较后者稍差。技术上按分布式重构了整个架构,可提供全局的MVCC、标准ACID、数据强一致等能力。对于用户来说,可类似普通数据库一样去使用,无应用浸入性。在性能上,可提供很大的吞吐量,但受限于架构在响应时间上有一定劣势。此外,还有些产品通过构造第二引擎及MPP的引入,也可提供一定的在线分析能力,满足类似HTAP的要求。

  • 分布式计算+单机引擎

    这种架构利用成熟的单机引擎与上层分布式计算层的结合,可实现存算分离。其扩展能力,较前者有更大的扩展能力。技术上此类产品仅重构了部分数据库架构,可通过上层与底层的部分改造,实现全局MVCC、ACID和强一致能力。但从实现上看,并不是十分优雅。此外,这种架构是需要用户明确数据分片方法,带有一定的侵入性,但也因这点其带来较好的延时表现。在性能上,可提供很大的吞吐量。

  • 单机计算+分布式存储

    这种架构是以分布式存储为基础,在其上构建单机的计算层。通过底层存储和上层无状态计算节点的扩展能力,实现一定程度的存算分离和弹性扩展。但从整体扩展能力来看,相较于前两者,有着明显的劣势。且受限于底座能力的约束,必须满足一定的部署条件。从产品能力上看,其是非分布式数据库最为接近的,用户几乎无感。

技术选型:分析场景

针对分析场景,可以做进一步的功能细分。这里可从支持事务情况、在线性、数据模型及实时性要求来做区分。

  • MPP架构

    第一类产品是MPP类型的数据仓库,是一种大规模并行计算数据库。此类产品属于数据库定位,提供数据库特有的ACID能力,对用户非常友好。提供标准的SQL能力及企业级能力(例如权限、资源)等。此类产品曾经是数据分析的唯一选择,后来面对更大规模、多模异构等场景不太适用,才出现后续基于大数据及其他方案。但随着近些年产品的发展,此类产品突破之前集群规模的限制,已经可以支持PB级及以上的规模。在使用体验上更加接近于数据库的能力。因此更为受到企业级用户的欢迎。后续此类产品在向细粒度控制、资源弹性、异构计算等方向发展。

  • 大数据架构

    第二类产品是大数据架构的产品,其本质是一种并行计算及存储系统。从早期出现的Hadoop及Hive、Spark到后期一系列产品,对应产品非常多样。此类产品提供多种计算方式,且通常为了降低使用成本也提供了类SQL的访问方式。但在如数据一致性、事务等方面较前者有明显的差异。通常适用于某类特定场景的数据分析,其扩展能力较前者更有优势。

  • 分布式存储架构

    第三类产品是来自于分布式存储产品,其原始诉求是提供各类数据的存储。这里包括结构化、半结构乃至非结构化数据。随着这些数据被保存,计算类的需求也被提出来。但通常这些计算往往是探索性的、无规律的。同时为了方便存储的各类不同数据,还需提供统一的元数据,建立整体数据视角。

技术选型:特定场景

对于特定场景部分,其根据数据专项应用领域,通常是比较好选择的。例如针对图数据库领域,Neo4j等是常规的选择;针对时序数据库InfluxDB等是常规的选择。此类产品选择,往往可选择的产品范围不同,只需关注被选产品的核心能力即可。

传统数据库、Hadoop 和 MPP 数据库的对比

常见数据库分类、架构及其使用场景等概述

参考

https://www.panziye.com/java/4745.html

tidb社区《数据库架构选型指南》

https://mp.weixin.qq.com/s/y3mvlPeD1Tlqrz_2FFrTrw 韩峰频道

《高效使用Greenplum 入门 进阶 与数据中台》

标签:

头像

小麦苗

学习或考证,均可联系麦老师,请加微信db_bao或QQ646634621

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

2 × 1 =

 

嘿,我是小麦,需要帮助随时找我哦
  • 18509239930
  • 个人微信

  • 麦老师QQ聊天
  • 个人邮箱
  • 点击加入QQ群
  • 个人微店

  • 回到顶部
返回顶部