文章探讨了为SSD优化的关系型数据库设计问题。传统数据库基于磁盘存储设计，而现代NVMe SSD在吞吐量和延迟上有千倍提升，加上云计算、多数据中心、高性能网络等基础设施的进步，以及全球化、24/7业务需求的变化，需要重新思考数据库架构，如预写日志、页面大小等设计决策是否仍适用。核心是如何为现代事务型数据库进行定量优化。

为SSD设计的数据库应该是什么样子？

背景与核心问题

传统关系型数据库（如PostgreSQL、MySQL、SQLite）诞生于机械硬盘（HDD）时代，其设计围绕HDD的慢速I/O和顺序读写优势展开（例如预写日志、大页尺寸、批量缓冲表写入）。而现代NVMe SSD的吞吐量和延迟性能提升了约1000倍，加上云计算、多数据中心部署、多核大内存服务器等基础设施的革新，以及全球化、高可用的业务需求，促使我们重新思考：如果2025年从头设计一个面向SSD的数据库，哪些该保留，哪些该改变？

四大设计思路

1. 缓存策略：30秒规则

   • 理论依据：沿用Jim Gray的“五分钟规则”（1986年提出：若页面5分钟内可能被重复访问，则缓存于内存），结合现代硬件参数调整。
   • 数据测算：以AWS i8g.48xlarge实例为例，32kB页面的读取成本约1美元/10亿次，内存缓存的经济性平衡点约为30秒（接近历史结论）。
   • 结论：数据库应缓存未来30秒内可能访问的热数据，兼顾成本与延迟优化。

2. I/O尺寸：32kB的吞吐/IOPS平衡点

   • SSD特性：现代SSD在吞吐量和IOPS上均远胜HDD，但对工作负载模式（如读写比例、磁盘占满率）仍敏感。
   • 经验法则：传输尺寸小于32kB时受IOPS限制，大于32kB时受吞吐限制。过大的传输会降低缓存效率（如伪共享问题）。
   • 结论：平均I/O尺寸应接近32kB，避免吞吐浪费。

3. 持久性与复制：跨可用区（AZ）同步

   • 挑战：本地SSD写入仅单机持久，需通过跨AZ同步复制保障数据安全。
   • 网络限制：实例的100Gb/s带宽制约单主数据库写入吞吐，跨AZ延迟（数百微秒至毫秒级）影响提交延迟。
   • 优化方向：仅在提交时触发跨AZ同步（如Aurora DSQL策略），减少写入阶段的协调开销。
   • 扩展收益：利用高精度硬件时钟（如AWS的NTP服务）实现强一致性读扩展。

4. 日志与恢复：分布式日志取代单机WAL

   • 传统设计：预写日志（WAL）针对单机磁盘持久性优化。
   • 现代需求：依赖多机多AZ的分布式日志（如Aurora的存储层），单机磁盘提交既非必要（冗余存储已保障持久性）也不充分（需容忍单机故障）。
   • 结论：事务提交至分布式日志，恢复时通过日志重放任意副本。

其他关键考量

• 数据结构：B树、LSM树等选择需权衡访问模式，无绝对优劣。
• 隔离级别：默认推荐SNAPSHOT隔离，平衡性能与一致性。
• 安全与多租户：强化客户端间隔离、静态/传输中数据加密。
• 新场景适配：向量计算、可验证复制日志、热分区处理等。

总结：变与不变

• 保留：关系模型、原子性、SQL、交互式事务等核心特性。
• 革新：
  • 将持久性、读写扩展、高可用性转为分布式实现。
  • 摒弃单机持久性优化（如ARIES算法），拥抱分布式优势。
  • 缓存工作集优化为30秒至5分钟，I/O尺寸针对SSD（32kB）和网络（8kB）调优。

未来数据库需深度融合现代硬件能力（SSD、云网络、时钟同步），同时应对全球化、安全合规等新需求，而这一切的起点是摆脱单机时代的惯性思维。

以下是评论内容的总结：

1. 传统数据库设计在SSD时代仍然有效

• 观点：虽然SSD改变了存储性能特征，但顺序与随机访问仍有显著差异，传统设计如预写日志(WAL)和缓冲仍适用。
  • "sequential and random access with SSDs still has massive difference" (mrkeen)
  • "still benefit from write ahead log to batch changes" (londons_explore)

2. 数据库需要针对SSD优化

• 观点：当前数据库仍沿用为机械硬盘设计的B树/LSM树，SSD的特性（如块写入、FTL层）未被充分利用。
  • "DB still use BTree/LSM tree optimized for spinning disc" (sreekanth850)
  • "SSDs are black boxes with vendor-specific FTL" (ritcgab)

3. 分布式与云原生设计的争议

• 支持：分布式存储可提高可用性，单机持久化非必需。
  • "Commit-to-disk on single system is unnecessary with replication" (PunchyHamster引用原文)
• 反对：过度依赖云服务可能导致厂商锁定和复杂性。
  • "Cloud locks you in with money and complexity" (cornholio)

4. 新型数据库案例

• 现有方案：Aerospike、MyRocks等已针对SSD优化。
  • "Aerospike is designed for SSDs with low overhead" (ghqqwwee)
  • "Check MyRocks on ZenFS for SSD-optimized DB" (zokier)
• 创新尝试：DuckDB的单文件列式存储、dbzero的内存模型等。
  • "DuckDB's columnar design with compression is efficient" (ljosifov)
  • "dbzero replaces DB with DISTIC model for SSDs" (dbzero)

5. 未来方向

• 硬件适配：应利用NVMe特性（如细粒度操作、直接数据传输）。
  • "NVMe can naturally handle metadata/indexes" (toolslive)
• 数据模型革新：关系模型可能不适用于LLM等新场景。
  • "Relational model is poor fit for LLM world models" (adsharma)

其他技术观点

• 页面大小调整：Postgres默认8KB页或可改为32KB以适应SSD。
  • "32K page size might be better for Postgres" (hyperman1)
• 性能权衡：需平衡吞吐量、延迟和写入放大。
  • "DBs still optimize throughput over latency variance" (firesteelrain)

行业观察

• 历史背景：数据库最初为解决机械硬盘问题而生（如磁头寻道）。
  • "Early databases solved disk access challenges" (wpietri)
• 企业选择：Optane虽停产但在小查询性能上仍领先。
  • "Enterprise could stick to Optane for Q1 performance" (Havoc)

（注：所有评论均无评分信息，总结时未体现认可度差异）