Update nexus: fix conflicts and sync local changes
This commit is contained in:
Shen Wei
@@ -1,64 +1,64 @@
|
||||
---
|
||||
title: "CTP Topic 51 Architecting with AWS Purpose-Built Databases"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- Purpose-Built
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-51-architecting-with-aws-purpose-built-databases]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AWS 专用数据库（Purpose-Built Databases）选型与架构设计原则
|
||||
- 问题域：现代应用的数据层设计——如何在多种数据类型和访问模式下选择最优数据库
|
||||
- 方法/机制：从用例出发 → 选择最佳工具 → 避免一刀切思维；AWS 提供关系型/NoSQL/内存/图/时序/账本/宽列等全品类专用数据库；DBA 角色从平台管理转向应用创新
|
||||
- 结论/价值：正确的数据库选型是应用性能的基础；数据库类型与访问模式的匹配度比"最新最贵"更重要；Duolingo/Netflix/Peloton 等真实案例验证了多数据库混合架构的价值
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- AWS 数据库专家 Femi George 认为：现代应用需要"为正确的应用选择正确的专用数据库"，避免用单一关系型数据库解决所有问题
|
||||
- 专用数据库选型应考虑：应用规模、用户数量、访问模式、流量峰值、性能需求（延迟、可用性）
|
||||
- Duolingo 的多数据库架构：DynamoDB 存储个性化数据 + ElastiCache 缓存高频词/短语 + Aurora 处理事务数据
|
||||
- Netflix 使用 DynamoDB 实现高弹性和低延迟 JSON 文档访问
|
||||
- Peloton 使用 ElastiCache Redis 为客户提供即时反馈
|
||||
- 云时代 DBA 的职能转变：从底层平台管理（备份、补丁）转向应用层创新和查询优化
|
||||
|
||||
## Key Quotes
|
||||
> "We need to start thinking of the right purpose-built database for the right application." — Femi George, AWS Database Sales Specialist
|
||||
> "Amazon Aurora has two flavors, MySQL and PostgreSQL." — Femi George, 强调 Aurora 的双引擎特性
|
||||
> "The role of the DBA is evolving in the cloud." — 云时代 DBA 从平台管理转向应用创新
|
||||
|
||||
## Key Concepts
|
||||
- [[Purpose-Built-Databases]]：AWS 全品类专用数据库体系——关系型/NoSQL/键值/文档/内存/图/时序/账本/宽列，覆盖所有数据模型
|
||||
- [[DBA-Role-Evolution]]：云时代数据库管理员职能转变——从平台管理（备份/补丁）转向应用创新（查询优化/架构设计）
|
||||
- [[Multi-Database-Architecture]]：多数据库混合架构——根据数据类型选择最优数据库（如 Duolingo：DynamoDB + ElastiCache + Aurora）
|
||||
|
||||
## Key Entities
|
||||
- [[Amazon-DynamoDB]]：AWS 全托管键值和文档数据库，单位数毫秒性能，日处理万亿级请求
|
||||
- [[Amazon-Aurora]]：云原生关系型数据库，支持 MySQL 和 PostgreSQL，存储与计算分离架构
|
||||
- [[Amazon-RDS]]：AWS 全托管关系型数据库服务，支持多引擎（MySQL/PostgreSQL/MariaDB/Oracle/SQL Server）
|
||||
- [[Amazon-ElastiCache]]：AWS 全托管内存缓存服务，支持 Redis 和 Memcached
|
||||
- [[Amazon-Neptune]]：AWS 图数据库，用于欺诈检测、社交网络、推荐系统
|
||||
- [[Amazon-Timestream]]：AWS 时序数据库，专为 IoT 和运维监控场景优化
|
||||
- [[Amazon-Keyspaces]]：AWS 托管 Apache Cassandra 兼容数据库，提供无服务器选项
|
||||
- [[Amazon-DocumentDB]]：AWS MongoDB 兼容文档数据库，支持灵活 schema
|
||||
- [[Duolingo]]：多数据库架构实战案例——DynamoDB + ElastiCache + Aurora
|
||||
- [[Netflix]]：DynamoDB 生产级用户——高弹性、低延迟 JSON 文档访问
|
||||
- [[Peloton]]：ElastiCache Redis 生产级用户——即时客户反馈
|
||||
|
||||
## Connections
|
||||
- [[Amazon-Aurora]] ← extends ← [[Amazon-RDS]]：Aurora 是 RDS 的云原生演进版本
|
||||
- [[Amazon-DynamoDB]] ← alternative_to ← [[Amazon-RDS]]：NoSQL 键值 vs 传统关系型的选型对比
|
||||
- [[Amazon-ElastiCache]] ← complements ← [[Amazon-RDS]]：缓存层补充数据库层，提升读取性能
|
||||
- [[Amazon-Neptune]] ← specialized_for ← Graph-Use-Cases：图数据库用于关系复杂的场景
|
||||
- [[Amazon-Timestream]] ← specialized_for ← Time-Series-Data：时序数据库用于 IoT/监控场景
|
||||
- [[ctp-topic-66-rds-vs-aurora]] ← related_to ← [[ctp-topic-51-purpose-built-databases]]：RDS vs Aurora 是关系型数据库内部的选型，本文档覆盖全品类数据库选型
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ctp-topic-66-rds-vs-aurora]] 的视角互补而非冲突：
|
||||
- 冲突点：无实质性冲突，两者是不同维度的对比
|
||||
- 当前观点（本文档）：Aurora 是 RDS 的云原生演进，提供存储计算分离和更高 IO 性能
|
||||
- 对方观点（CTP 66）：从 PostgreSQL 迁移视角对比，RDS 更适合小规模低成本场景，Aurora 更适合大规模高性能场景
|
||||
---
|
||||
title: "CTP Topic 51 Architecting with AWS Purpose-Built Databases"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- Purpose-Built
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-51-architecting-with-aws-purpose-built-databases]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AWS 专用数据库（Purpose-Built Databases）选型与架构设计原则
|
||||
- 问题域：现代应用的数据层设计——如何在多种数据类型和访问模式下选择最优数据库
|
||||
- 方法/机制：从用例出发 → 选择最佳工具 → 避免一刀切思维；AWS 提供关系型/NoSQL/内存/图/时序/账本/宽列等全品类专用数据库；DBA 角色从平台管理转向应用创新
|
||||
- 结论/价值：正确的数据库选型是应用性能的基础；数据库类型与访问模式的匹配度比"最新最贵"更重要；Duolingo/Netflix/Peloton 等真实案例验证了多数据库混合架构的价值
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- AWS 数据库专家 Femi George 认为：现代应用需要"为正确的应用选择正确的专用数据库"，避免用单一关系型数据库解决所有问题
|
||||
- 专用数据库选型应考虑：应用规模、用户数量、访问模式、流量峰值、性能需求（延迟、可用性）
|
||||
- Duolingo 的多数据库架构：DynamoDB 存储个性化数据 + ElastiCache 缓存高频词/短语 + Aurora 处理事务数据
|
||||
- Netflix 使用 DynamoDB 实现高弹性和低延迟 JSON 文档访问
|
||||
- Peloton 使用 ElastiCache Redis 为客户提供即时反馈
|
||||
- 云时代 DBA 的职能转变：从底层平台管理（备份、补丁）转向应用层创新和查询优化
|
||||
|
||||
## Key Quotes
|
||||
> "We need to start thinking of the right purpose-built database for the right application." — Femi George, AWS Database Sales Specialist
|
||||
> "Amazon Aurora has two flavors, MySQL and PostgreSQL." — Femi George, 强调 Aurora 的双引擎特性
|
||||
> "The role of the DBA is evolving in the cloud." — 云时代 DBA 从平台管理转向应用创新
|
||||
|
||||
## Key Concepts
|
||||
- [[Purpose-Built-Databases]]：AWS 全品类专用数据库体系——关系型/NoSQL/键值/文档/内存/图/时序/账本/宽列，覆盖所有数据模型
|
||||
- [[DBA-Role-Evolution]]：云时代数据库管理员职能转变——从平台管理（备份/补丁）转向应用创新（查询优化/架构设计）
|
||||
- [[Multi-Database-Architecture]]：多数据库混合架构——根据数据类型选择最优数据库（如 Duolingo：DynamoDB + ElastiCache + Aurora）
|
||||
|
||||
## Key Entities
|
||||
- [[Amazon-DynamoDB]]：AWS 全托管键值和文档数据库，单位数毫秒性能，日处理万亿级请求
|
||||
- [[Amazon-Aurora]]：云原生关系型数据库，支持 MySQL 和 PostgreSQL，存储与计算分离架构
|
||||
- [[Amazon-RDS]]：AWS 全托管关系型数据库服务，支持多引擎（MySQL/PostgreSQL/MariaDB/Oracle/SQL Server）
|
||||
- [[Amazon-ElastiCache]]：AWS 全托管内存缓存服务，支持 Redis 和 Memcached
|
||||
- [[Amazon-Neptune]]：AWS 图数据库，用于欺诈检测、社交网络、推荐系统
|
||||
- [[Amazon-Timestream]]：AWS 时序数据库，专为 IoT 和运维监控场景优化
|
||||
- [[Amazon-Keyspaces]]：AWS 托管 Apache Cassandra 兼容数据库，提供无服务器选项
|
||||
- [[Amazon-DocumentDB]]：AWS MongoDB 兼容文档数据库，支持灵活 schema
|
||||
- [[Duolingo]]：多数据库架构实战案例——DynamoDB + ElastiCache + Aurora
|
||||
- [[Netflix]]：DynamoDB 生产级用户——高弹性、低延迟 JSON 文档访问
|
||||
- [[Peloton]]：ElastiCache Redis 生产级用户——即时客户反馈
|
||||
|
||||
## Connections
|
||||
- [[Amazon-Aurora]] ← extends ← [[Amazon-RDS]]：Aurora 是 RDS 的云原生演进版本
|
||||
- [[Amazon-DynamoDB]] ← alternative_to ← [[Amazon-RDS]]：NoSQL 键值 vs 传统关系型的选型对比
|
||||
- [[Amazon-ElastiCache]] ← complements ← [[Amazon-RDS]]：缓存层补充数据库层，提升读取性能
|
||||
- [[Amazon-Neptune]] ← specialized_for ← Graph-Use-Cases：图数据库用于关系复杂的场景
|
||||
- [[Amazon-Timestream]] ← specialized_for ← Time-Series-Data：时序数据库用于 IoT/监控场景
|
||||
- [[ctp-topic-66-rds-vs-aurora]] ← related_to ← [[ctp-topic-51-purpose-built-databases]]：RDS vs Aurora 是关系型数据库内部的选型，本文档覆盖全品类数据库选型
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ctp-topic-66-rds-vs-aurora]] 的视角互补而非冲突：
|
||||
- 冲突点：无实质性冲突，两者是不同维度的对比
|
||||
- 当前观点（本文档）：Aurora 是 RDS 的云原生演进，提供存储计算分离和更高 IO 性能
|
||||
- 对方观点（CTP 66）：从 PostgreSQL 迁移视角对比，RDS 更适合小规模低成本场景，Aurora 更适合大规模高性能场景
|
||||
|
||||
Reference in New Issue
Block a user