把数据库做得能扩展：Aurora DSQL 的故事
我们在 AWS re:Invent 上发布了 Aurora DSQL，这是一个全新方式构建关系型数据库的尝试。它不是单纯的技术升级，而是一段从零开始、反复试错、不断学习的工程旅程。
我们为什么做 Aurora DSQL？
AWS 从最早的 RDS 到 DynamoDB、Redshift、Aurora，一直在为客户打造专用型数据库。这些服务解决了客户遇到的实际问题，比如：如何处理超大规模的数据、如何加快查询速度、怎样减轻数据库维护负担等。
但我们还缺了一个拼图：一个真正 可自动扩展、无需人工维护 的 SQL 数据库。Aurora 和 Aurora Serverless 已经向这个目标迈出了一步，但我们想做得更多、更彻底。
DSQL 是什么？
DSQL 把数据库拆成多个模块，每个模块只做一件事，但配合起来可以完成完整数据库功能，比如事务、查询、一致性、并发等。
最难的是如何扩展写操作。传统方法很复杂，容易出错。我们决定换一种思路，把一次写入的全部数据打包写入一个地方，这样简单、可靠。但这样做导致读取数据变复杂，因为要到处找更新数据。
为了解决这个问题，我们设计了 Crossbar
Crossbar 是一个关键组件，能高效管理读写扩展。它允许存储节点只接收相关的数据，而不是所有数据都广播一遍。不过这个系统很难实现，还带来了一堆新问题，比如网络压力、延迟、垃圾回收等。
我们模拟测试后发现问题很严重：只要有一台机器慢，整个系统就变慢了。我们需要根本的改变。
于是，我们选择了 Rust
最初我们的代码是用 Java 的 JVM 平台写的。但 JVM 的垃圾回收机制让我们在高负载下很难保证低延迟。C/C++ 太容易出内存问题。Rust 则给了我们意想不到的答案：
- 没有垃圾回收，性能稳定
- 内存安全，避免很多 bug
- 写出来的代码非常快（比我们优化多年的 Java 版本快 10 倍）
我们决定用 Rust 重写整个数据库核心。控制层最开始还保留在 Kotlin，但最终也迁移到了 Rust，因为：
- Rust 写的逻辑更一致，便于测试和调试
- 不同语言导致重复代码、不同表现
- 开发人员反而更喜欢 Rust，学得快、写得顺
遇到的挑战和收获
- Rust 学起来不容易，但一旦学会，效率很高
- Postgres 虽然是用 C 写的，但我们用 Rust 写扩展，反而更安全
- 决策时最重要的是看团队需求、项目特点，而不是语言流行度
最后的总结
DSQL 的开发不是一蹴而就的，而是靠一步步尝试和不断调整得来的。Rust 最终帮我们打造了一个更稳定、更快速、更可扩展的数据库。它未必适合每个项目，但对我们来说，是个对的选择。
我们最大的收获不是代码写得多快，而是团队一起面对挑战、不断进步的过程。