View a markdown version of this page

PERF04-BP04 根据访问模式选择数据存储 - AWS Well-Architected Framework
实施指导资源

PERF04-BP04 根据访问模式选择数据存储

根据工作负载的访问模式和应用程序的要求来决定要使用的最佳数据服务和技术。

期望结果：根据已识别和记录的数据访问模式选择数据存储。这可包括最常见的读取、写入和删除查询，对必要计算和聚合的需求，数据的复杂性，数据的相互依赖关系，以及所要求的一致性需求。

常见反模式：

  • 仅选择一个数据库引擎来简化运营管理。

  • 假设数据访问模式始终保持不变。

  • 在应用程序中实施复杂的事务、回滚和一致性逻辑。

  • 数据库配置为支持可能出现的高流量突增，从而导致数据库资源大部分时间保持空闲状态。

  • 使用共享数据库进行事务处理和分析。

建立此最佳实践的好处：根据访问模式选择和优化数据存储将有助于降低开发复杂性并优化性能。了解何时使用只读副本、全局表、数据分区和缓存将有助于减少运营开销，并可以根据工作负载需求进行扩展。

在未建立这种最佳实践的情况下暴露的风险等级：中等

实施指导

识别和评估数据访问模式，以选择正确的存储配置。每个数据库解决方案都有配置和优化存储解决方案的选项。使用收集的指标和日志，并尝试使用各种选项以找到最佳配置。使用下表查看每个数据库服务的存储选项。

AWS Services Amazon RDS Amazon Aurora Amazon DynamoDB Amazon DocumentDB Amazon ElastiCache Amazon Neptune Amazon Timestream Amazon Keyspaces Amazon QLDB
Scaling Storage Storage can be scaled up manually or configured to scale automatically to a maximum of 64 TiB based on engine types. Provisioned storage cannot be decreased. Storage scales automatically up to maximum of 128 TiB and decreases when data is removed. Maximum storage size also depends upon specific Aurora MySQL or Aurora Postgres engine versions. Storage automatically scales. Tables are unconstrained in terms of size. Storage scales automatically up to maximum of 64 TiB. Starting Amazon DocumentDB 4.0 storage can decrease by comparable amounts for data removal through dropping a collection or index. With Amazon DocumentDB 3.6 allocated space remains same and free space is reused when data volume increases. Storage is in-memory, tied to instance type or count. Storage scales automatically can grow up to 128 TiB (or 64 TiB in few Regions). Upon data removal from, total allocated space remains same and is reused in the future. Organizes your time series data to optimize query processing and reduce storage costs. Retention period can be configured through in-memory and magnetic tiers. Scales table storage up and down automatically as your application writes, updates, and deletes data. Storage automatically scales. Tables are unconstrained in terms of size.

实施步骤：

  1. 了解事务以及原子性、一致性、隔离和持久性（ACID） 合规性和一致性读取的要求。并非每个数据库都支持这些要求，大多数 NoSQL 数据库提供最终一致性模型。

  2. 考虑全球分布式应用程序需要的流量模式、延迟和访问要求，以便确定最佳存储解决方案。

  3. 分析查询模式、随机访问模式和一次性查询。还必须考虑针对文本和自然语言处理、时间序列和图形的高度专业化查询功能。

  4. 确定并记录数据和流量的预期增长。

    1. Amazon RDS 和 Aurora 支持存储自动扩展到规定的限制。除此之外，可以考虑将旧数据转移到 Amazon S3 进行归档，聚合历史数据进行分析，或通过分片进行横向扩展。

    2. DynamoDB 和 Amazon S3 将自动扩展到接近无限的存储量。

    3. 在 EC2 上运行的 Amazon RDS 实例和数据库的大小可以手动调整，并且 EC2 实例可以在以后添加新的 EBS 卷以增加存储空间。 

    4. 实例类型可以根据活动的变化而改变。例如，您可以在测试时从较小的实例开始，然后在服务开始接收生产流量时扩展实例。Aurora Serverless V2 会自动扩缩以响应负载的变化。 

  5. 有关正常和峰值性能（每秒事务数 TPS 和每秒查询数 QPS）及一致性（ACID 和最终一致性）的基准要求。

  6. 记录解决方案部署方面和数据库访问要求（如全局复制、多可用区、读取复制和多个写入节点）。

实施计划的工作量级别：低。如果您未记录数据管理解决方案的日志或指标，那么您需要在识别和记录数据访问模式之前完成这项工作。一旦了解了数据访问模式，选择和配置数据存储的工作量就会比较低。

资源

相关文档：

相关视频：

相关示例：