AWS全球数据库解决方案三剑客

250,000
800,000
200,000
700,000 600,000
150,000 100,000
500,000 400,000 300,000
50,000
200,000 100,000
0
0
MySQL 5.6 Aurora 5.6
MySQL 5.7 Aurora 5.7
MySQL 8.0
MySQL 5.6 MySQL 5.7 MySQL 8.0 Aurora 5.6 Aurora 5.7
ZHY Region
Availability Zone A
Availability Zone B
Availability Zone C
Availability Zone
Datacenter
Datacenter
Datacenter
Common data categories and use cases
▪ 将远程的readers 提升为master ▪ 快速的跨region灾难恢复 ▪ 更方便的跨region迁移数据方法
▪ 让客户的数据分布到不同region，更 贴近用户
▪ 次秒级跨region数据复制
全局物理复制
• Primary region
AZ 3
Replica instance
AZ 2
Replica instance
➢ 将Log机制推送至存储层 ➢ 4/6写入仲裁与本地跟踪 ✓ 写入性能 ✓ 读取横向扩展 ✓ 可用区+1容错机制 ✓ 即时数据库重做恢复
不再需要妥协！
主
SQL 事务 缓存
AZ1
副
副
SQL
SQL
事务
事务
缓存
缓存
共享存储卷
AZ2
AZ3
“可用区+1”容错机制
AZ 1
AZ 2
AZ 3
2/3读取 2/3 写入
可用区 故障时的 仲裁中断
为什么？
➢ 在大规模集群体系中，故障总会出现 ➢ 可用区故障是一种“命中注定”
AZ 1
AZ 2
AZ 3
3/6读取 4/6写入
可用区故障 时仲裁仍可 继续起效
如何实现？
➢ 6份副本，每可用区2份 ➢ 2/3仲裁无法满足需求
写入与读取吞吐量
Aurora MySQL的速度可达MySQL的5倍
AWS全球数据库解决方案“三剑客”
技术创新，变革未来
目录
CONTENTS
1
全球数据库挑战
2
Aurora global database
3
DynamoDB global tables
4
ElastiCache global datastore
5 客户案例
全球数据库的原因与挑战
• 为什么我们需要全球部署数据库？ • 为了灾备，需要将数据库跨region部署 • 为了性能，需要将数据库在多个region分布，贴近我们的用户 • 全球部署数据库的挑战？ • 搭建多个region内数据库之间复制环境带来的技术挑战 • 维护多个数据库环境带来的运维压力 • 未来的扩展压力 • 尽量降低secondary region与primary region数据库之间的复制延迟
DocumentDB
with MongDB Compatibility
ElastiCache
Neptune Timestream
QLDB
目录
CONTENTS
1
全球数据库挑战
2
Aurora global database
3
DynamoDB global tables
4
ElastiCache global datastore
AWS全球基础设施
222边缘节点
24 区 域 77可用区
区域与可用区
Availability Zone 可用区
_ 每个region区域至少有两个可用区 _ 每个可用区都由多个数据中心组成 _ 可用区之间地理与网络都是独立设计与运营 _ 可用区专为实现物理冗余而设计，具有弹性，即使 在出现断电、互联网停机、洪水和其他自然灾害的情 况下也能实现不间断的性能。
Relational Key-value Wide Column Document In-memory
Graph
Time-series
Ledger
RDS
DynamoDB
Aurora Community Commercial
Biblioteka Baidu
Managed Cassandra
Service
with Cassandra Compatibility
500
600
时间以秒为单位
SysBench OLTP（只写）工作负载与250份表，每表20万行，采用R4.16XL实例
Aurora region内高可用与只读副本的实现
MYSQL 读取扩展
AMAZON AURORA 读取扩展
MySQL 主节点 70% 写入 30% 读取
数据卷
单线程二进制日志
MySQL副节点 70% 写入 30% 读取
数据卷
Aurora 主节点 70% 写入 30% 读取
页面缓存更新
共享多可用区存储
Aurora副节点 100% 新读取
• 使用完整的变更逻辑 • 相同的写入工作负载 • 独立存储
以物理方式使用delta变更 不向副节点写入 共享存储
Amazon Aurora MySQL region内逻辑与物理复制延迟
AZ 1
1
Primary
1
instance
1
ASYNC 4/6 quorum
Continuous backup
Storage fleet
AuroBrian逻lo辑g 复Re制pl延ic迟a L（ag秒(）sec.)
Aurora物理复制延迟（毫秒）
“在MySQL当中，我们看到复制延迟达到近12分钟。从实际应用的角度来 看，这显然是种近乎荒谬的情况。利用Aurora，4个副本的最大读取延迟从 未超过20毫秒。”
更快的灾难恢复和数据贴近用户
5 客户案例
Amazon Aurora
Amazon Aurora…
以开源级成本交付的企业级数据库
媲美高端商业数据库的速度与可用性 媲美开源数据库的简单性与成本效益 与MySQL及PostgreSQL全面 兼容 按使用量计费的简单定价模式
以托管服务形式交付
Amazon Aurora: 横向扩展、分布式架构
写入吞吐量
读取吞吐量
在R4.16XL实例上运行Sysbench处理250份表，每份表包含20万行
12 10 8 6 4 2 0
0
负载条件下的性能变化
Amazon Aurora >一致性提升200倍
写入响应时间（秒）
Amazon Aurora MySQL 5.6 on EBS
100
200
300
400