本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
技术需求评估模板
提供有关数据摄取类型的信息:
数据提取类型 |
是/否 |
描述 |
Frequency |
应用程序访问权限 |
Y |
|
|
API 网关 |
Y |
|
|
数据流 |
否 |
|
|
Batch 处理 |
否 |
|
|
ETL |
否 |
|
|
数据导入 |
否 |
|
|
时间序列 |
否 |
|
|
提供有关数据使用类型的信息:
数据消耗类型 |
是/否 |
描述 |
Frequency |
应用程序访问权限 |
|
|
|
API 网关 |
|
|
|
数据导出 |
|
|
|
数据分析 |
|
|
|
数据聚合 |
|
|
|
报告 |
|
|
|
搜索 |
|
|
|
数据流 |
|
|
|
ETL |
|
|
|
提供数据量估算值:
实体名称 |
估计的记录数 |
记录大小 |
数据量 |
游戏玩家 |
1 毫米 |
< 1 KB |
~ 1 GB (1 毫米 * 1 KB) |
游戏实例 |
6 毫米 (100k/天 * 60 天) |
< 1 KB |
~ 6 GB (6 毫米 * 1 KB) |
游戏用户映射 |
300 MM (6 个 MM 游戏 * 50 个玩家) |
< 1 KB |
大约 300 GB (300 MM * 1 KB) |
注意
数据留存期 60 天。60 天后,必须将数据存储在 Amazon S3 中进行分析,方法是使用 DynamoDB 生存时间 (TTL) 自动将数据从 DynamoDB 移至 Amazon S3。
回答以下有关时间模式的问题:
用户可以在什么时间范围内使用该应用程序(例如,全天候或工作日上午 9 点至下午 5 点)?
白天的使用量是否达到高峰? 多少小时? 应用程序使用百分比是多少?
指定写入吞吐量要求:
实体名称 |
每天写入 |
小时/天 |
写入/秒 |
游戏玩家 |
一万次更新 |
18 |
< 1 |
游戏实例 |
30万 |
18 |
< 5 |
游戏用户映射 |
1800,000,000 |
18 |
~ 27.777 |
注意事项
游戏玩家写入操作:1% 的用户每天更新他们的个人资料,因此我们预计 100 万名用户会有 10,000 次更新。
游戏实例写入操作:100,000 个游戏/天。对于每款游戏,我们至少有 3 个写入操作(在创建、开始和结束时),因此总共有 300,000 个写入操作。
游戏用户映射写入操作:每款游戏每天有 100,000 个,每次有 50 个玩家。平均游戏时长为 30 分钟,玩家位置每 5 秒更新一次。我们估计每位玩家平均有 360 次更新,因此总数为 100,000 * 50 * 360 = 18 亿次写入操作。
指定读取吞吐量要求:
实体名称 |
读数/天 |
小时/天 |
读取/秒 |
游戏玩家 |
20万 |
18 |
~ 3 |
游戏实例 |
5,000,000 |
18 |
~ 77 |
游戏用户映射 |
1800,000,000 |
18 |
~ 27.777 |
注意事项
游戏玩家读取操作:20% 的用户开始游戏,因此 1 MM * 0.2 = 200,000。
游戏实例读取操作:100,000 个游戏/天。对于每款游戏,我们每位玩家至少有 1 次读取操作,每款游戏有 50 名玩家,因此读取操作总数为 500 万次。
游戏用户映射读取操作:每天50 个玩家有 100,000 场游戏。平均游戏时长为 30 分钟,玩家位置每 5 秒更新一次。我们估计每位玩家平均需要 360 次更新,并且每次更新都需要读取操作,因此总数为 100,000 * 50 * 360 = 18 亿次读取操作。
指定数据访问延迟要求:
操作 |
99 个百分位数 |
最大延迟 |
读取 |
30 毫秒 |
100 毫秒 |
写入 |
10 毫秒 |
50 毫秒 |
指定数据可用性要求:
要求 |
是/否 |
指标 |
备注 |
高可用性 |
Y |
99.9% |
|
RTO |
Y |
1 小时 |
恢复时间目标 |
RPO |
Y |
1 小时 |
恢复点目标 |
灾难恢复 |
否 |
|
|
区域内数据复制 |
否 |
|
|
跨区域数据复制 |
否 |
3 秒延迟 |
哪个AWS 区域? |
指定安全要求:
要求 |
是/否 |
备注 |
敏感数据存储 |
否 |
受保护的健康信息 (PHI)、支付卡行业 (PCI) 信息、个人身份信息 (PII)? |
静态加密 |
Y |
|
传输中加密 |
Y |
|
客户端加密 |
否 |
|
任何专有或第三方供应商的加密库 |
否 |
|
数据访问记录 |
否 |
|
数据访问审计 |
否 |
|