存储全量SHA1值哈希集的数据库检索时长及AWS数据库选型咨询

1. 2^160量级哈希集存储在AWS后的单条检索耗时 #

核心前提说明：2^160 约等于 1.46×10^48 条记录，即使单条记录仅存储20字节的SHA1原始值，总存储需求约为2.9×10^{49字节（约2.6×10}37 EB），这一规模远超当前全球所有存储设备的总容量之和，不可能实现全量物理存储。
如果是存储碰撞研究产生的可落地的子集数据，AWS不同数据库的单条主键检索耗时参考如下：

• 键值类数据库（如DynamoDB）：P95延迟稳定在10ms以内，流量平稳的场景下P99延迟可控制在20ms以内
• 关系型数据库（如RDS托管的MySQL/MSSQL）：命中内存缓存的热数据主键检索耗时约1_{10ms，需要读取磁盘的冷数据检索耗时约10}50ms，受实例配置、缓存命中率影响波动较大

2. MySQL/MSSQL官方是否明确定义单条检索耗时标准 #

没有明确定义统一的单条记录检索耗时标准。
单条检索耗时完全依赖数据规模、索引设计、实例硬件配置、缓存命中率、磁盘IO性能、网络延迟等多个变量，不存在通用的固定标准。官方仅会发布特定测试环境下的基准性能参考：比如MySQL官方会提供SysBench基准测试的参考结果，MSSQL官方会提供TPC-C、TPC-E等基准测试的参考数值，均为特定场景下的参考值，不代表所有场景下的性能表现。

3. 超大规模哈希存储检索场景适配的AWS数据库 #

全量2^160的数据集不存在可落地的存储方案，针对SHA1碰撞研究这类需要超大规模键值检索的场景，优先推荐两类AWS数据库：

• Amazon DynamoDB：无服务器托管的键值数据库，天生适配单键点查场景，可无缝水平扩展到PB级数据容量，支持每秒百万级查询请求，检索延迟稳定，无需手动运维分片和扩容，是这类场景的首选。如果有冷数据归档需求，还可以搭配S3做低频数据存储，降低成本。
• Amazon MemoryDB for Redis：兼容Redis协议的内存数据库，热数据全量存储在内存中，单条检索延迟可低至亚毫秒级，适合对检索性能要求极高的热点数据查询场景，缺点是存储成本高于DynamoDB。

内容的提问来源于stack exchange，提问作者김소정_1310