如何根据不同场景选择合适的云数据库|学习笔记

本文涉及的产品
云数据库 RDS SQL Server,独享型 2核4GB
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云服务器 ECS,每月免费额度200元 3个月
简介: 快速学习如何根据不同场景选择合适的云数据库

开发者学堂课程【数据库上云实战:如何根据不同场景选择合适的云数据库】学习笔记,与课程紧密联系,让用户快速学习知识

课程地址:https://developer.aliyun.com/learning/course/70/detail/1173


如何根据不同场景选择合适的云数据库

 

内容介绍:

一、前言

二、MySQL 数据库应用场景及选型

三、SQL server 数据库应用场景及选型

四、POLARDB 应用场景及选型

五、Hybrid 应用场景及选型

六、Redis 应用场景及选型

七、MongoDB 应用场景及选型

八、HBase 应用场景

九、HBase 产品选型

 

一、前言

第二部分介绍了阿里云数据库有的一个产品以及各个产品的一个特性,简单描述了一下个人数据库产品的适用的一些场景,那到底在具体的某一些业务场景下应该选择什么样的产品形态的什么样的数据库,是第三部分要重点讨论的一个内容。第三部分主要会针对于各类主流的一些数据库产品,去分析一下各种的一些产品形态到底是在哪些应用场景下能够得到更好的使用的。

 

二、MySQL 数据库应用场景及选型

1.业务场景

适合场景:OLTP 场景、绝大部分行业使用,如︰网站、日志系统、嵌入式系统等。

业务场景

架构选型

备注

开发测试环境

单机版 MySQL

可用性不保证

生产环境

高可用版

一主一备,可以添加只读实例来实现读写分离

数据一致性极高

MySQL 金融版

数据复制的强一致性,主要针对金融、证券、保险等行业的核心数据库

image.png

首先来介绍一下 mySQL 数据库的应用场景以及选型方面的一些内容,首先肯定都非常熟悉 MySQL 数据库,因为它是绝大部分业务都能够使用的一个 OLTP 场景下的一个关系性数据库,例如像网站、日志系统、嵌入式系统这些耳熟能详的应用系统,很多都使用了 mySQL 数据库,在阿里云 mySQL 数据库之上目前支持的架构有单机版 mySQL、高可用版的 mySQL 以及金融版的 mySQL,由于单机版的 mySQL 在可用性上是不一定能得到一个很好的满足的,所以建议在开发测试环境下使用单机版的 mySQL

对于数据可用性、数据安全性要求非常高的一些生产环境的产品,都建议客户在阿里云上直接使用高可用版的 mySQL,它的架构是一主一倍,可以部署在不同的机房做一个机房层面的一个容灾,也可以通过一些只读实例添加只读实例的方式来实现一个读写分离的功能。而对于金融行业核心的数据一次性要求极高的应用,其实可以考虑用金融版的一个 mySQL,它真正做到了数据复制的一次性,在任何故障场景下都能够保证数据不发生丢失。

2.架构选情

场景

架构造型

备注

价格敏感

性能稳定性要求低

通用型

CPU 和存储有一定的复用

完全独占一台物理机的所有资源

独享型

完全独享的 CPU、内存、存储和I/0资源

数据库性能容量要求高,监管要求

独占型

完全独占一台物理机的所有资源

image.png

在架构选型方面,目前 MySQL 数据库有三种类型,成本比较低廉的是通用型,它这种适合是价格比较敏感、性能稳定性要求又不是那么高的一些业务,因为它的CPU 跟存储是有一定的复用的,也就是说在极端情况下,可能别的数据库实例把系统资源消耗的比较多的时候,可能会影响到自己的一些数据库实例的一些性能的稳定性。

如果为了更好的去保证一个业务性能稳定性,建议采用的是独享型的 MySQL 数据库,它是完全独享一份 CPU 内存和存储资源,不会和其它实例之间发生资源的争抢。而对于那些性能容量要求特别高,性能稳定性要求特别大,或者有一定的监管要求的一些应用场景,也可以选择独占物理机的独占型的 MySQL 数据库。

 

三、SQL server 数据库应用场景及选型

1.单机基础型

可用性要求不高场景

◆单 ECS 运行.数据在云盘存三份拷贝

◆故障漂移至另一 ECS ,约需30分钟。

image.png

2.双机高可用版

可用性要求非常高,

需要故障快速恢复

◆主备实例容灾,数据云盘:E份拷贝( 2008r2未放云盘)

◆故障90s 切换。

◆原生官方 Mirror 技术,用户、权限同时同步(阿里独有)

image.png

3.共享型实例

价格敏感、性能稳定性要求不高.

CPU 共享,内存独占

2008r22012企业单机版

◆价格便宜

image.png

4.独享型实例

性能稳定性要求较高

CPU 独占,内存独占

2012及以上版本(2012企业单机版)

image.png

SQL server 数据库刚才前面也提到了,目前 SQL server 数据库支持的产品清单有外部版、标准版、企业版,从一个架构层面上来说,主要是分成单机基础版跟双机高合用版。

单机基础版目前是运行在单个的 ecs 之上的,在数据保护层面是有三份的拷贝,如果发生 ecs 层面的一些故障,数据库的实例是会漂移到另外一台 ecs 上进行提供的。总体故障恢复的时间会需要30分钟左右,所以对于单机版的 SQL server,是建议在可用性要求不是那么高的场景下进行使用。而对于那些可用性要求非常高的就需要故障能够快速恢复、业务连续性有一个很好的保证的一些业务场景,建议采用的还是双机高可用版的数据库,它除了做了主位实例的容灾,它的数据云盘也是做三份的拷贝。发生任何故障,一般都能够在90秒以内完成切换,它在实例方面是选择共享性实力还是独享性实力,这个其实跟 MySQL 实例是类似的,取决于对价格跟性能稳定性的一个需求。如果对价格比较敏感,性能稳定性要求不是那么高,也可以选择共享性的实例。目前云上的20082012企业单机版是共享性的一个实力的架构。而对于那种性能稳定性要求非常高的,还是建议使用2012基础上的版本,因为它使用的是独占性的实例,CPU 和内存以及存储资源是能够做到很好的一个隔离,从而去保证业务的稳定。

 

四、POLARDB 应用场景及选型

➢适用 MySQL 体系的所有业务场景

➢高并发、高性能

➢存储容量需求较大

➢业务弹性要求非常灵活

image.png

前面提到了 POLARDB 是阿里云自研的一个高度兼容 MySQL 数据库,它能够适合于以下业务场景。第一个就是它适用于前期使用 MySQL 体系的所有业务场景,它能够解决掉高并发、高性能的一些问题,首先它存储容量是会比传统的 MySQL 更大,它最大能支持数据10T的存储容量,而且由于它是一个全新的数据库架构,它能够做到更好的弹性,而且能够支持更高的一个并发提供更好的性能,从初步的测试数据来看,POLARDB 的整体性能比传统的 MySQL 5~6倍左右,性能提高如此之快的原因是:首先从上图上的架构就能看出来,它所有的计算实例,都是通过高速达 DMA 协议访问底层的分布式存储,所以它的 IO 吞吐能力会非常强,而且在所机制跟数据同步的一些方面,阿里的团队是在内核方面做了一个深度的优化以及一些特性的一些添加,使得整个 POLARDB 的处理能力会有一个明显的提升。也就是说如果前期用 MySQL 数据库,由于性能容量出现一些瓶颈,是可以很平滑的切换到 POLARDB 上进行使用的。

 

五、Hybrid 应用场景及选型

HybridDB for MySQL

RDS MySQL 存在容量和性能瓶颈

沿用 MySQL 生态的 OLAP 场景

物联网历史归档场景

历史数据报表生产的场景

高并发高吞吐的交换库的场景

image.png

HybridDB for PG

非事务类场景

企业级数据仓库场景

地理信息场景

线下使用 Greenplum 的场景

image.png

HybridDB for MySQL 这类的数据库适用的业务场景有以下几点,首先第一个是当MySQL里面可能某一张表特别大以后,在单个的 MySQL 实例里面处理起来已经有了一些明显的一些性能问题,以及一些大量的数据要做归档或者做一些历史报表的分析的时候,其实是可以考虑用 HybridDB for MySQL 数据库的,它是会基于一个分区间将数据打散在不同的节点里面,然后通过扩展节点去提升整个集群的数据存储的能力和处理能力。HybridDB for MySQL 这个其实是就是用开源版的Greenplum 研发出来的一个支持非事务类场景,比较适合企业级数据仓库场景以及地理信息成立的一个数据库。

 

六、Redis 应用场景及选型

image.png

在第二部分的时候,也提到了 Redis 各种丰富的一些产品形态,不同的产品形态适合业务场景以及它支撑的 qps 信息从上面的表中是能看出来的。首先第一个就是如果可用性要求不是特别高, qps 的要求在几千到几万,Redis 的协议兼容性要求也非常高的情况下,其实是可以考虑用一个标准版的单副本的 Redis 支撑业务。

对于一些就数据可能性要求比较高,但 QPS 以及协议的兼容性也有一定的要求的场景下,是可以采用标准版的双副本的架构。另外可能有一些业务场景的数据量非常大,可能标准版的不管是单副本还是双副本都是会有一些瓶颈的时候,是可以考虑用一个集群版的 Redis 去提升整个数据库的处理能力和存储的能力。比如说像一些数据量特别大、存款之类的一些业务对协议又不是非常敏感的数据库,是可以用集群版的 Redis 去支撑业务,它能够达到的 qps 都是10万以及更高级别的。

还有一些业务场景,其实可能有一些比如热点 key 的一些问题,还有读写都非常频繁的一些业务场景,也是可以使用读写分离版的 redis 集群去做架构的选型,它前端会有一个 proceed 服务器来自动的做一个数据库的读写的分离。

 

七、MongoDB 应用场景及选型

业务类型

场景需求

架构选型

游戏

移动应用

物联网应用

内容管理

......

非核心业务场景

数据可用性要求不高

单节点

核心业务场景

高可用需求

存储容量需求不大

多节点

核心业务

数据量较大

可扩展性要求较高

集群版

MongoDB 类型的数据库,目前比较适合的业务类型就是包括比如说像游戏行业、物联网行业、内容管理的行业。目前在阿里云上 MongoDB 这类的数据库有三个产品形态,一个就是单节点的,一个是多节点,一个是集群版。这三类不同的架构的区别就是首先单节点,就是数据可用性的保证是相对来说是会比较低的,一些非核心的业务场景是可以选择用单节点的 MongoDB 去做。

对于一些核心业务场景高可用的需求特别强烈,但是总体存储容量需求不是特别大的时候,是直接可以选择一个多节点也就是一个三节点的 MongoDB 去支撑业务,而对于整体数据量非常大,并发要求特别高、性能要求也非常高的一些场景,阿里云上目前也有集群版的 MongoDB 可以去做选择。

 

八、HBase 应用场景

image.png

HBase 作为现在业界非常准确的分布式的数据库,它的应用场景其实非常的广泛,也就是说在那种数据量比较大、并发比较高、性能要求比较高、查询也不是很复杂的场景,其实都可以使用HBase的数据库,比如像报表类、时序类、日志类、风控类以及物联网车联网等所有的领域目前都有非常多的 HBase 的一些使用案例。HBase 和这些场景都能够利用掉HBase的海量的存储能力以及高并发、高吞吐的能力。

 

九、HBase 产品选型

image.png

HBase 目前在阿里云上有三种产品形态

1.单节点

它也是建议在开发测试玩家使用。目前建议的是数据量小于等于100G 的时候考虑用单节点

2.集群版

目前是使用特别多的产品形态,它适合的就是对高肯定要求非常高的一些核心的业务。总体存储容量小于10P 左右,它的延迟非常低

3.双活集群版

双活集群版本是对容灾的一个需求是可以选用双活集群版。

上面的是介绍了一些相关内容,比如说现在各个产品 HBase 支持的示范类型有哪些,适合的业务场景哪些以及它目前可以选择一些规格的列表有哪些。

目前在阿里云上客户更多的还是选择集群版的 base,此版本的 HBade 目前注册的时候磁盘类型有三种,第一个是高效云盘/SSD 云盘/沙盘磁盘,这三种磁盘主要是从性能跟成本上是有一定的区别的,像高效磁盘,它整体容量会比较大,综合成本来说会比较低,但是它的性能方面会比高效云盘还有一定的差距;SSD的云盘是性能最好的磁盘介质,它的总体支撑的容量相对来说会稍微小一些,但是它的 qps 的能力能够最高达到百万以上,对于实施硬要求非常高的一些在线业务是可以考虑使用这种版本。双活版本是比如客户在跨可用区的一些高容灾的一些需求,双活版本也是可以去实现的。

相关实践学习
一小时快速掌握 SQL 语法
本实验带您学习SQL的基础语法,快速入门SQL。
7天玩转云服务器
云服务器ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,可降低 IT 成本,提升运维效率。本课程手把手带你了解ECS、掌握基本操作、动手实操快照管理、镜像管理等。了解产品详情: https://www.aliyun.com/product/ecs
相关文章
|
2月前
|
存储 机器学习/深度学习 关系型数据库
向量数据库的崛起与多元化场景创新
向量数据库的崛起与多元化场景创新
76 0
|
3月前
|
存储 关系型数据库 MySQL
Linux C/C++ 开发(学习笔记八):Mysql数据库图片存储
Linux C/C++ 开发(学习笔记八):Mysql数据库图片存储
50 0
|
3月前
|
关系型数据库 MySQL 数据库
Linux C/C++ 开发(学习笔记七):Mysql数据库C/C++编程实现 插入/读取/删除
Linux C/C++ 开发(学习笔记七):Mysql数据库C/C++编程实现 插入/读取/删除
49 0
|
1月前
|
存储 SQL 数据管理
阿里云数据库 SelectDB 内核 Apache Doris 如何基于自增列满足高效字典编码等典型场景需求|Deep Dive 系列
自增列的实现,使得 Apache Doris 可以在处理大规模时展示出更高的稳定性和可靠性。通过自增列,用户能够高效进行字典编码,显著提升了字符串精确去重以及查询的性能。使用自增列作为主键来存储明细数据,可以完美的解决明细数据更新的问题。同时,基于自增列,用户可以实现高效的分页机制,轻松应对深分页场景,有效过滤掉大量非必需数据,从而减轻数据库的负载压力,为用户带来了更加流畅和高效的数据处理体验。
|
2月前
|
缓存 NoSQL 关系型数据库
数据库缓存一致性学习笔记(一)
数据库缓存一致性学习笔记(一)
|
2月前
|
开发框架 安全 .NET
某教程学习笔记(一):07、数据库漏洞(access注入)
某教程学习笔记(一):07、数据库漏洞(access注入)
19 0
|
2月前
|
XML SQL 安全
某教程学习笔记(一):08、MSSQL数据库漏洞
某教程学习笔记(一):08、MSSQL数据库漏洞
17 0
|
2月前
|
安全 关系型数据库 MySQL
某教程学习笔记(一):09、MYSQL数据库漏洞
某教程学习笔记(一):09、MYSQL数据库漏洞
19 0
|
2月前
|
Oracle 关系型数据库 数据处理
某教程学习笔记(一):10、oracle数据库注入
某教程学习笔记(一):10、oracle数据库注入
17 0
|
3月前
|
存储 人工智能 自然语言处理
向量数据库:大模型场景下知识管理新方式
向量数据库在构建基于大语言模型的行业智能应用中扮演着重要角色。

热门文章

最新文章