Q26 — AWS SAA-C03 第15章
第 26/100 题 | ← 返回第15章
Q1126. 一家公司正在推出一款新的游戏应用程序。该公司将使用 Amazon EC2 Auto Scaling 组来部署该应用程序。该应用程序将用户数据存储在关系数据库中。该公司在世界各地设有办事处,需要对数据库中的用户数据进行分析。该公司需要一种经济高效的数据库解决方案,该解决方案可在 AWS 区域之间提供跨区域灾难恢复和低延迟读取性能。哪种解决方案可以满足这些要求?
- A. 在应用程序部署的区域中创建 Amazon ElastiCache(Redis OSS)集群。在公司办公室所在的区域创建只读副本。确保公司办公室从只读副本实例读取数据。
- B. 创建 Amazon DynamoDB 全局表。将这些表部署到公司办公室所在的区域以及应用程序部署的区域。确保每个公司办公室都从与其位于同一区域的表读取数据。
- C. 创建 Amazon Aurora 全局数据库。将主集群配置为应用程序部署的区域。将辅助 Aurora 副本配置为公司办公室所在的区域。确保公司办公室能够从 Aurora 副本读取数据。 ✓
- D. 在应用程序部署的区域创建 Amazon RDS 多可用区数据库集群部署。确保公司办公室从只读副本实例读取数据。
正确答案: C. 创建 Amazon Aurora 全局数据库。将主集群配置为应用程序部署的区域。将辅助 Aurora 副本配置为公司办公室所在的区域。确保公司办公室能够从 Aurora 副本读取数据。
解析
满足经济高效的数据库解决方案要求的最佳解决方案是提供跨区域灾难恢复以及跨 AWS 区域的低延迟读取性能:C. 创建 Amazon Aurora 全局数据库。将主集群配置为应用程序部署的区域。将辅助 Aurora 副本配置为公司办公室所在的区域。确保公司办公室能够从 Aurora 副本读取数据。解释:Amazon Aurora 全球数据库:此解决方案支持从多个区域进行低延迟读取,并提供跨区域灾难恢复功能。它会自动将数据以最低延迟复制到辅助区域,确保办公室能够快速可靠地访问数据。经济高效:Aurora 专为高可用性和高性能而设计,非常适合具有全球覆盖范围的应用程序。为什么其他选择不适合:A.虽然 ElastiCache 可以提供快速的内存数据访问,但它并非为用户数据的持久存储而设计,也不提供关系数据库的跨区域灾难恢复。B:Amazon DynamoDB 全局表适用于非关系数据,可能不符合关系数据库解决方案的要求。D:RDS 多可用区部署在单区域内提供高可用性,但不支持跨区域复制或灾难恢复,而这恰恰是关键需求。因此,选项 C 是最适合该公司需求的解决方案。为了满足经济高效的数据库解决方案的要求,该解决方案提供跨区域灾难恢复 (DR) 以及跨 AWS 区域的低延迟读取性能以进行分析,该解决方案必须:支持多区域复制(用于灾难恢复和低延迟读取)。在多个区域提供只读副本(用于靠近办公地点的分析)。经济高效(避免不必要的过度配置或昂贵的 NoSQL 解决方案)。支持关系数据(因为应用程序将用户数据存储在关系数据库中)。关键要求:关系数据库:该解决方案必须兼容关系数据库(而非 DynamoDB 等 NoSQL 数据库)。跨区域灾难恢复:数据库必须跨区域复制数据以实现故障转移。低延迟读取分析:全球各地的办事处应从其所在区域的副本读取数据。经济高效:除非必要,否则避免使用诸如全局 DynamoDB 表之类的昂贵解决方案。期权分析:选项A:在应用程序部署的区域创建 Amazon ElastiCache (Redis OSS) 集群。在公司办公室所在的区域创建只读副本。确保公司办公室能够从只读副本实例读取数据。失败原因:ElastiCache (Redis) 是一个缓存层,而非主数据库。它不存储持久化关系数据(仅缓存数据)。不适用于用户数据分析(需要直接访问数据库)。选项 B:创建 Amazon DynamoDB 全局表。将表部署到公司办公室所在的区域以及应用程序部署的区域。确保每个公司办公室都从与其位于同一区域的表读取数据。失败原因:DynamoDB 是 NoSQL 数据库,而非关系型数据库(这违反了关系型数据库的要求)。虽然 DynamoDB 全局表支持多区域复制,但如果应用程序已经使用关系型数据库,则它并不合适。对于关系工作负载来说不具成本效益:DynamoDB 需要完全重写应用程序。选项C:创建 Amazon Aurora 全局数据库。将主集群配置为应用程序部署的区域。将辅助 Aurora 副本配置为公司办公室所在的区域。确保公司办公室能够从 Aurora 副本读取数据。为什么有效:Amazon Aurora 全球数据库:关系数据库:Aurora 是一款兼容 MySQL/PostgreSQL 的托管数据库。跨区域灾难恢复:支持一个主区域和最多五个辅助区域(用于故障转移)。低延迟读取:办公室可以从本地 Aurora 副本读取数据(复制延迟小于 1 秒)。经济高效:对于关系型工作负载,比 DynamoDB 全局表更经济。最佳匹配:满足所有需求(关系型、多区域灾难恢复、低延迟读取)。选项D:在应用程序部署区域创建 Amazon RDS 多可用区数据库集群部署。确保公司办公室从只读副本实例读取数据。失败原因:RDS 多可用区:在单区域内提供高可用性(不支持跨区域灾难恢复)。不支持多区域只读副本:RDS 只读副本可以部署在同一区域,但不能跨区域部署(除非使用 Aurora 全球数据库)。不满足跨区域要求:无法在其他区域提供低延迟读取。最佳选择:选项CAmazon Aurora 全球数据库提供:关系数据库支持(兼容 MySQL/PostgreSQL)。跨区域灾难恢复(主数据库位于一个区域,辅助数据库位于其他区域)。低延迟读取(办公室从本地副本读取)。经济高效(与关系工作负载的 DynamoDB 全局表相比)。最终答案:C. 创建 Amazon Aurora 全局数据库。将主集群配置为应用程序部署的区域。将辅助 Aurora 副本配置为公司办公室所在的区域。确保公司办公室能够从 Aurora 副本读取数据。补充说明:Aurora 全局数据库非常适合需要灾难恢复和低延迟读取的多区域关系型工作负载。DynamoDB 全局表仅适用于已使用 NoSQL 的应用程序。RDS 多可用区适用于同区域高可用性,而非跨区域灾难恢复。ElastiCache 用于缓存,而不是持久数据存储。