一、关系型数据库介绍
关系数据库管理系统
利用关系数据库管理系统，也就是 RDBMS，您可以创建、更新和管理关系数据库。RDBMS 的一些常见示例包括：
- MySQL
- PostgreSQL
- Oracle
- Microsoft SQL Server
- Amazon Aurora
您需要通过使用结构化查询语言 (SQL) 查询与 RDBMS 进行通信，类似于以下示例：
SELECT * FROM table_name。
这个查询从特定表中选择所有数据。不过，SQL 查询的强大之处在于可创建更复杂的查询，从多个表中提取数据来揭示模式和业务问题的答案。例如，同时查询销售表和图书表，可以了解与某个作者的图书相关的销售情况。可以使用“join”同时查询多个表，更好地了解这些表之间的关系。
二、关系数据库使用案例
大多数应用程序都在关系数据库上运行。事实上，关系数据库是许多任务关键型应用程序的核心，其中一些应用程序可能会在日常生活中用到。
要了解关系数据库的一些常见使用案例，请分别展开查看以下两个类别中的每个类别。
具有固定架构的应用程序
应用程序具有固定架构，并且不会经常发生更改。例如直接迁移的应用程序，也就是将应用程序从本地直接迁移到云，只需进行少量修改，甚至无需修改。
需要持久性存储的应用程序
应用程序需要持久性存储，并遵循 ACID 原则，例如：
- 企业资源规划 (ERP) 应用程序
- 客户关系管理 (CRM) 应用程序
- 商业和金融应用程序
三、托管和非托管数据库
选择非托管式数据库还是托管式数据库
如果您想将本地部署数据库换成 AWS 上的关系数据库，首先需要选择您想要的运行方式：托管式还是非托管式。托管式服务与非托管式服务的处理方式类似于责任共担模式。责任共担模式划分了 AWS 的安全责任和客户的安全责任。同样，也可以将托管式与非托管式之间的比较理解为便利性与控制权之间的权衡。
非托管式数据库
如果您在本地运维关系数据库，则需要负责运维的所有方面。这包括数据中心安全和电力、主机管理、数据库管理、查询优化和客户数据管理。您需要全权负责所有事情，这意味着您对一切拥有绝对的控制权。
现在，假设您想通过在 Amazon Elastic Compute Cloud (Amazon EC2) 上运行关系数据库，将一些工作转移给 AWS。如果您在 Amazon EC2 上托管数据库，AWS 将实施和维护物理基础设施和硬件，以及安装 EC2 实例操作系统 (OS)。但是，您仍需负责管理 EC2 实例、管理主机上的数据库、优化查询以及管理客户数据。
这就是非托管式数据库选项。如果使用这个选项，AWS 负责并控制硬件和底层基础设施。您负责并控制主机和数据库的管理。
对于在本地部署的数据库，您负责数据的方方面面。对于在 Amazon EC2 中托管的数据库，AWS 承担更多责任。
托管式数据库
要将更多工作转移给 AWS，您可以使用托管式数据库服务。此类服务同时提供 EC2 实例和数据库设置，还提供相应的系统，以便实现高可用性、可扩展性、补丁和备份。不过在此模式下，您仍然需要负责数据库优化、查询优化，还要确保客户数据安全。与前两个选项相比，这个选项提供了极大的便利性，但控制权最少。
四、AWS数据库服务及责任划分总结
| 数据库服务 | 类型 | AWS负责部分 | 客户负责部分 | 适用场景 |
|---|---|---|---|---|
| Amazon RDS | 关系型数据库（托管式） | - 硬件、网络、操作系统维护 - 数据库引擎补丁更新 - 自动备份与恢复 - 多可用区部署 | - 数据库参数组调优（如内存分配） - 索引设计、慢查询优化 - 连接池配置 - 数据加密（需主动启用KMS） | 传统OLTP场景（如MySQL/PostgreSQL） |
| Amazon Aurora | 关系型数据库（云原生） | - 分布式存储自动扩展 - 6副本跨AZ存储容灾 - 计算节点自动故障转移（Failover） | - 读写分离策略优化 - 只读副本负载均衡配置 - 全局数据库同步延迟监控 - DNS切换期间的连接重试逻辑 | 高并发、高可用企业级应用 |
| Amazon DynamoDB | NoSQL（Key-Value） | - 自动分区与容量扩展 - 跨区域复制 - 底层SSD存储维护 | - 分区键设计（避免热分区） - 二级索引规划 - 读写容量模式选择（标准/自适应） - TTL策略配置 | 电商购物车、游戏玩家状态等 |
| Amazon Redshift | 数据仓库 | - 列式存储优化 - 自动压缩编码 - 并发查询队列管理 | - 分布键（DISTKEY）设计 - 排序键（SORTKEY）选择 - 物化视图维护 - 工作负载管理（WLM）规则 | 大数据分析、BI报表 |
| Amazon ElastiCache | 内存数据库 | - 节点自动替换 - 多可用区副本同步 - Redis/Memcached引擎维护 | - 缓存淘汰策略（LRU/LFU） - 穿透/雪崩防护机制 - 数据预热脚本设计 - 连接超时参数调整 | 会话缓存、实时排行榜 |
责任模型说明
根据AWS共享责任模型：
• AWS责任始终包括：
✅ 物理数据中心安全
✅ 硬件/网络基础设施
✅ 虚拟化层管理
✅ 托管服务的自动扩展与灾备
• 客户责任根据服务类型变化：
| 服务层级 | 客户需关注重点 |
|---|---|
| 完全托管服务 | 数据模型设计、访问控制、查询优化（如DynamoDB/Aurora） |
| 半托管服务 | 参数配置、连接池管理、备份策略（如RDS/Redshift） |
| 基础设施服务 | 操作系统补丁、安全组规则、全链路监控（如EC2自建数据库） |
性能优化要点示例
对于"读取性能优化"这一客户核心责任，不同服务的优化方向差异显著：
• RDS/Aurora：
🔧 索引覆盖查询避免全表扫描
🔧 批量读取时启用并行查询
🔧 长连接复用减少握手开销
• DynamoDB：
🔧 合理设置全局/本地二级索引
🔧 使用DAX缓存高频查询结果
🔧 避免单个分区键的请求倾斜
• ElastiCache：
🔧 采用Pipeline减少网络往返
🔧 热点数据预加载到内存
🔧 监控缓存命中率并扩容
通过表格和分层说明，可清晰看出AWS数据库服务的责任边界，客户需要根据具体服务类型针对性优化，而非仅关注"读取性能"单一维度。
五、Amazon RDS
Amazon RDS 上的存储
Amazon RDS 数据库实例的存储部分使用 Amazon Elastic Block Store (Amazon EBS) 卷存储数据库和日志，包括 MySQL、MariaDB、PostgreSQL、Oracle 和 SQL Server。
在使用 Aurora 时，数据存储在集群卷中，集群卷是一个使用固态硬盘 (SSD) 的虚拟卷。集群卷由跨一个 AWS 区域中的三个可用区的数据副本组成。对于非持久性的临时文件，Aurora 使用本地存储。
Amazon RDS 提供三种存储类型：通用型 SSD（也称为 gp2 和 gp3）、预置 IOPS SSD（也称为 io1）以及磁性介质（也称为标准）。它们的性能特征和价格各不相同，这意味着您可以根据数据库工作负载的需求定制存储性能和成本。
Amazon Virtual Private Cloud 中的 Amazon RDS
创建数据库实例时，您需要选择数据库所在的 Amazon Virtual Private Cloud (Amazon VPC)。然后，选择要指定给数据库的子网。这称为数据库子网组，并在子网组的区域中至少有两个可用区。数据库子网组中的子网应是私有的，因此它们没有指向互联网网关的路由。这可以确保数据库实例及其中的数据只能由应用程序后端访问。
通过使用网络访问控制列表（网络 ACL）和安全组，可以进一步限制对数据库实例的访问。利用这些防火墙，您可以精细地控制可访问数据库的流量类型。
通过使用这些控件，可以为基础设施提供安全层。这强化了只有后端实例才能访问数据库的概念。
RDS备份
您不想丢失数据。要定期备份 Amazon RDS 实例，您可以使用自动备份或手动快照。
自动备份
手动快照
选择备份选项
最好同时部署这两个备份选项。自动备份有助于时间点恢复。利用手动快照，您可以将备份保留超过 35 天。
使用 Amazon RDS 多可用区实现冗余
六、Amazon DynamoDB
DynamoDB 使用案例
DynamoDB 是一项完全托管式服务，用于处理操作工作。您可以将操作和扩展分布式数据库方面的管理任务转移给 AWS。
在以下情况中，您可能需要考虑使用 DynamoDB：
- •
您在使用其他传统数据库系统时遇到了可扩展性问题。
- •
您正在积极参与应用程序或服务的开发工作。
- •
您正在处理 OLTP 工作负载。
- •
您需要部署一个任务关键型应用程序，该应用程序必须始终高度可用，无需人工干预。
- •
无论采用何种备份和恢复策略，您都需要高级别的数据持久性。
DynamoDB 因其简单易用而被广泛应用于各种工作负载，从小规模运营到超大规模运营，就像 Amazon.com 这样的规模要求也不在话下。
开发软件应用程序
构建支持用户内容元数据和缓存的互联网级应用程序，这些应用程序需要很高的并发性和连接数，以便满足数百万用户和每秒数百万次请求的需求。
创建媒体元数据存储
扩展吞吐量和并发性，满足分析媒体和娱乐工作负载的要求，例如实时视频流和交互式内容。通过跨区域的多区域复制降低延迟。
扩展游戏平台
专注于推动创新，无运维开销。利用玩家数据、会话历史记录和数百万同时在线用户的排行榜，构建您的游戏平台。
提供无缝的零售体验
使用设计模式来部署购物车、工作流引擎、库存跟踪和客户资料。DynamoDB 支持高流量、强扩展的事件，每秒可处理数百万次查询。
七、AWS多种数据库对比
| AWS 服务 | 数据库类型 | 使用案例 |
| Amazon RDS、Aurora、Amazon Redshift | 关系 | 传统应用程序、ERP、CRM、电子商务 |
| DynamoDB | 键值数据库 | 高流量 Web 应用程序、电子商务系统、游戏应用程序 |
| Amazon ElastiCache for Memcached、Amazon ElastiCache for Redis | 内存数据库 | 缓存、会话管理、游戏排行榜、地理空间应用程序 |
| Amazon DocumentDB | 文档 | 内容管理、目录、用户配置文件 |
| Amazon Keyspaces | 宽列数据库 | 用于设备维护、实例集管理、路线优化的大规模工业应用程序 |
| Neptune | 图形数据库 | 欺诈侦测、社交网络、推荐引擎 |
| Timestream | 时间序列 | IoT 应用程序、开发运维 (DevOps)、工业遥测 |
| Amazon QLDB | 分类账数据库 | 用于记录、供应链、注册、银行事务的系统 |
以下是主要数据库服务的对比表格，涵盖核心功能、适用场景及成本差异：
| 数据库服务 | 数据模型 | 主要用途 | 性能特点 | 扩展性 | 成本结构 | 高可用性 | 兼容性/协议 |
| Amazon RDS | 关系型（SQL） | OLTP、传统企业应用 | 基于EC2实例，性能依赖存储类型（gp2/io1） | 垂直扩展（单实例升级） | 按实例规格、存储、I/O操作计费（例：t3.medium约$35/月） | 多可用区部署（SLA 99.95%） | MySQL、PostgreSQL、Oracle等 |
| Amazon Aurora | 关系型（云原生SQL） | 高性能OLTP、全球分布式应用 | 吞吐量是RDS的3-5倍，支持15个读副本，存储计算分离架构 | 自动水平扩展（Aurora Serverless v2） | 存储成本约$0.18-0.23/GB/月 + 计算实例费用（IO优化版降低I/O费用） | 多可用区+全球数据库（SLA 99.99%） | MySQL、PostgreSQL兼容 |
| DynamoDB | 键值（NoSQL） | 高并发、低延迟场景（电商、游戏） | 单表每秒百万级请求，延迟<10ms，自动分区扩展 | 无限水平扩展 | 按读写请求量（RCU/WCU）+ 存储计费（例：50读/20写请求约$250/月） | 多区域复制（强一致性或最终一致性） | 专有API（支持AWS SDK） |
| Redshift | 列式（数据仓库） | 大数据分析、BI报表 | 大规模并行处理（MPP），支持PB级数据压缩查询 | 集群节点扩展 | 按计算节点类型（例：ra3.xlplus $0.85/小时） + 存储费用 | 跨可用区备份 | PostgreSQL兼容（部分语法差异） |
| DocumentDB | 文档（NoSQL） | 半结构化数据存储（JSON文档） | 兼容MongoDB 4.0协议，读写吞吐量比自建MongoDB高2倍 | 自动分片扩展 | 按实例规格（例：db.r5.large $0.40/小时） + 存储（gp3 $0.12/GB/月） | 多可用区副本集 | MongoDB 4.0协议兼容 |
| Neptune | 图数据库 | 社交网络、推荐系统、欺诈检测 | 支持Gremlin和SPARQL查询，复杂关系查询延迟<100ms | 存储自动扩展至64TB | 按实例规格（例：db.r5.large $0.52/小时） + 存储 | 多副本跨可用区 | Gremlin、RDF/SPARQL |
| Timestream | 时序数据库 | IoT设备日志、运维监控数据 | 自动时间分区，写入速度>100万数据点/秒，查询性能比传统方案快1000倍 | 存储无限扩展 | 按写入数据量（$0.005/百万事件） + 查询扫描量（$0.01/GB） | 多副本存储 | 专有API（支持SQL扩展） |
| ElastiCache | 内存数据库 | 实时缓存、会话存储 | 亚毫秒级延迟（Redis/Memcached），支持集群模式 | 分片扩展 | 按节点类型（例：cache.r6g.xlarge $0.30/小时） | 多可用区副本 + 自动故障转移 | Redis、Memcached协议 |
关键差异总结
-
性能与扩展性• **OLTP场景**：Aurora在吞吐量和故障恢复速度上显著优于RDS，但DynamoDB在超大规模并发下更具成本优势。• **分析场景**：Redshift的列式存储适合复杂聚合查询，而Timestream专为时间序列数据优化。
-
成本优化策略• **按需 vs 预留**：RDS/Aurora适合预留实例（长期稳定负载），DynamoDB按请求计费更适合流量波动场景。• **存储分层**：S3 Glacier与Timestream结合可降低冷数据存储成本达90%。
-
架构兼容性• 迁移友好型：DocumentDB（MongoDB兼容）和RDS（多引擎支持）适合从传统数据库迁移。• 云原生设计：Aurora和DynamoDB深度集成AWS服务（如Lambda、S3），适合无服务器架构。
-
运维复杂度• **全托管服务**：Aurora/DynamoDB自动处理备份、打补丁和扩展，运维成本低于自建方案。• **自定义需求**：ElastiCache和RDS允许更细粒度的配置调整（如Redis参数组）。
选型建议
• **电商秒杀**：DynamoDB（高并发写入）+ ElastiCache（缓存热点数据）。
• **全球分布式应用**：Aurora Global Database（跨区域低延迟读取）。
• **IoT数据分析**：Timestream（自动时间分区）+ Redshift（聚合报表）。
如需具体配置案例或成本测算，可参考AWS官方文档或结合业务流量模型进一步分析。
-
AWS 网站：AWS 云数据库(opens in a new tab)
-
AWS Blog：AWS 数据库博客(opens in a new tab)
-
AWS 网站：数据库自由
AWS提供了多种数据库服务，涵盖关系型、NoSQL、内存、文档、图形、时间序列等多种类型，适用于不同的业务场景。以下是AWS主要数据库种类及其特点的详细介绍：
1. 关系型数据库（RDS & Aurora）
• **Amazon RDS**：支持MySQL、PostgreSQL、MariaDB、Oracle、SQL Server等引擎，适用于需要强一致性和事务处理的场景（如金融、ERP系统）。
• **Amazon Aurora**：AWS自研的高性能云原生数据库，兼容MySQL和PostgreSQL，吞吐量是标准MySQL的5倍，支持自动扩展和多可用区高可用（99.99% SLA）。
MySQL和PostgreSQL是两大主流开源关系型数据库，它们在架构设计、功能特性和适用场景上有显著差异。以下是核心区别总结：
1. 架构与核心特性
| 维度 | MySQL | PostgreSQL |
| 存储引擎 | 插件式（InnoDB/MyISAM等） | 统一存储引擎，支持扩展（如PostGIS） |
| 并发模型 | 线程级（高并发短查询优化） | 进程级（复杂事务处理更稳定） |
| 复制机制 | 基于binlog的逻辑复制 | 基于WAL的物理复制（延迟更低） |
| 事务隔离 | 默认REPEATABLE-READ（存在幻读） | 默认SSI（可串行化快照隔离） |
2. 功能对比
• 数据类型支持 • PostgreSQL原生支持 **JSONB、数组、范围类型、GIS数据**，适合复杂数据结构。 • MySQL的JSON处理需调用函数（如JSON_EXTRACT），性能较弱。
• 扩展能力 • PostgreSQL支持 **120+扩展**（如TimescaleDB时序数据库），MySQL生态依赖存储引擎。
• 高级功能 • PostgreSQL提供 **窗口函数、CTE递归查询、FDW联邦查询**，MySQL需8.0+版本支持部分功能。
3. 性能与适用场景
| 场景 | MySQL优势 | PostgreSQL优势 |
| 高并发读写 | 简单查询速度快（如电商交易） | 复杂查询（如分析报表）性能更优 |
| 数据一致性 | 需手动处理幻读 | 强ACID支持，适合金融系统 |
| 水平扩展 | 依赖中间件（如ShardingSphere） | 原生支持分片（如Citus扩展） |
4. 运维与生态
• 开源协议 • PostgreSQL采用 **BSD协议**，允许闭源商用；MySQL受Oracle控制，存在商业版限制。
• 高可用 • PostgreSQL的 PITR（时间点恢复） 和逻辑复制更灵活，MySQL依赖GTID和MGR。
选型建议
1. SQL数据库
• **选MySQL**：需要快速读写、简单架构或与LAMP栈集成（如Web应用）。
• **选PostgreSQL**：处理复杂查询、GIS数据或需要严格ACID（如ERP系统）。
性能测试显示：PostgreSQL在1000并发下吞吐量比MySQL高22%，且延迟更低。
2. NoSQL数据库
• **DynamoDB**：全托管键值对数据库，适用于高吞吐、低延迟场景（如电商、游戏），支持自动扩展和全球表功能。
• **DocumentDB**：兼容MongoDB的文档数据库，适合半结构化数据（如内容管理系统）。
• **Keyspaces**：宽列数据库，兼容Apache Cassandra，适用于物联网和车联网等大规模数据集场景。
3. 内存数据库（ElastiCache）
• 支持Redis和Memcached，用于缓存和实时数据处理（如会话管理、实时推荐系统）。
4. 图形数据库（Neptune）
• 适用于复杂关系分析（如社交网络推荐、欺诈检测），支持属性图和RDF图模型。
5. 时间序列数据库（Timestream）
• 专为时序数据优化（如IoT设备监控、工业遥测），支持高效写入和查询。
6. 分类账数据库（QLDB）
• 不可变账本，适用于审计跟踪和区块链场景（如银行交易记录）。
7. 数据仓库（Redshift）
• PB级数据分析服务，支持高性能查询和机器学习集成。
8. RDS 与 Aurora 对比及选择建议
以下从核心维度对比 Amazon RDS 和 Aurora，并结合实际场景给出选择建议：
| 对比维度 | Amazon RDS | Amazon Aurora | 关键差异总结 |
|---|---|---|---|
| 支持的数据库引擎 | 支持 MySQL、PostgreSQL、Oracle、SQL Server、MariaDB、Db2 等 | 仅兼容 MySQL 和 PostgreSQL 协议 | RDS 兼容性更广，适合需多引擎支持的传统企业；Aurora 专注主流开源数据库优化。 |
| 架构设计 | 传统集中式存储（基于 EBS），计算与存储耦合 | 云原生架构，计算与存储分离（存储基于 S3），仅传输日志减少 I/O 压力 | Aurora 的日志驱动存储和分布式设计显著提升性能与扩展性，适合高并发场景。 |
| 性能表现 | 常规 OLTP 性能，依赖 EBS 存储类型（gp2/io1） | 写入性能是 RDS 的 5-60 倍（MySQL），读副本延迟更低，支持 15 个读副本 | Aurora 在写入密集型和复杂查询场景优势明显，尤其适合电商、游戏等高吞吐需求。 |
| 高可用性 | 多可用区部署（Multi-AZ），SLA 99.95%，故障转移时间约 2-5 分钟 | 跨 3 个可用区存储 6 副本，SLA 99.99%，故障转移时间 <30 秒 | Aurora 故障恢复更快，支持全球数据库（跨区域复制），容灾能力更强。 |
| 扩展性 | 手动扩展存储和计算节点，最大 5 个读副本 | 存储自动扩展（10GB~128TB），Serverless v2 按需弹性伸缩，支持 15 个读副本 | Aurora 在突发流量和长期扩展场景更灵活，Serverless 版适合负载波动大的业务。 |
| 成本模型 | 实例费用较低（如 t3.micro 免费层），存储和 IOPS 需预配置 | 实例费用约为 RDS 的 1.2 倍，但存储按实际用量计费，I/O 优化版减少隐性成本 | 小规模场景 RDS 更经济；高并发下 Aurora 性能提升可降低总成本（如减少节点数）。 |
| 适用场景 | - 传统 OLTP 系统 - 多数据库引擎需求 - 预算有限的中小企业 | - 高性能 OLTP/HTAP - 全球化部署（低延迟读） - 云原生应用 | RDS 适合兼容性优先的稳定业务；Aurora 适合追求极致性能与弹性的创新业务。 |
选择建议
优先选择 RDS 的场景：
- 多数据库引擎需求：需使用 Oracle、SQL Server 等非开源引擎。
- 简单工作负载：低并发、固定规模的业务（如内部管理系统）。
- 严格成本控制：免费层（t3.micro）或预留实例可显著降低成本。
优先选择 Aurora 的场景：
- 高性能写入/查询：如实时交易、游戏会话等高频写入场景。
- 全球化业务：需跨区域低延迟读取（Aurora Global Database）。
- 弹性扩展需求：Serverless v2 自动适配流量波动（如促销活动）。
优化技巧
• 成本敏感型 Aurora：启用 I/O 优化版降低存储费用，调整 innodb_flush_log_at_trx_commit=2 减少 I/O 操作（需评估数据丢失风险）。
• RDS 性能瓶颈：升级存储类型（如 io1 预配置 IOPS），增加读副本分担负载。
• 迁移验证：使用 Aurora 读副本逐步迁移，并通过 CloudWatch 监控复制延迟。
通过对比可见，Aurora 在性能与扩展性上全面领先，但需权衡成本与兼容性；RDS 则以灵活性和低成本见长。实际决策需结合业务峰值负载、全球化部署需求及长期运维成本综合评估。
官方文档参考
扫一扫
259
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
