Akka，事件溯源和分布式数据库迁移
内容提要
本文介绍了基于事件溯源的Akka应用程序的底层数据库迁移案例研究，推荐使用Akka Persistence的r2dbc模式，AlloyDB在大量写入操作方面性能高，CockroachDB在垂直扩展后性能瓶颈，建议迁移到AlloyDB以获得更好的性能和可靠性。
延伸解读
事件溯源场景下的数据库选型要点
事件溯源架构中，数据库需要持续追加事件，写入吞吐量和延迟是关键指标。本文的负载测试表明，AlloyDB在大量写入操作中表现出高性能，而CockroachDB在垂直扩展后仍无法突破每秒2000次写入的瓶颈。因此，对于类似Akka Persistence的事件溯源应用，应优先评估数据库的写入扩展能力，而非仅关注水平扩展特性。
AlloyDB与CockroachDB的架构差异
AlloyDB是谷歌全代管式PostgreSQL兼容数据库，自动处理备份、复制等管理任务，并利用机器学习优化性能。CockroachDB是自托管分布式SQL数据库，强调水平扩展和强一致性。本文测试显示，AlloyDB在写入吞吐量上优于CockroachDB，且无需自运维。对于需要高写入吞吐的事件溯源应用，AlloyDB可能更合适。
垂直扩展的局限性
CockroachDB在垂直扩展后仍无法突破每秒2000次写入的阈值，说明单纯增加硬件资源可能无法解决写入瓶颈。这可能与其分布式架构的协调开销有关。对于写入密集型应用，如果垂直扩展无法满足需求，可能需要考虑更换数据库或调整架构。本文建议迁移到AlloyDB以获得更好的性能。
迁移决策的参考因素
本文建议从CockroachDB迁移到AlloyDB，主要基于写入吞吐量和延迟的测试结果。但迁移决策还需考虑其他因素，如现有技术栈、运维成本、云服务依赖等。AlloyDB作为全代管服务，可能降低运维负担，但需评估供应商锁定风险。读者应结合自身业务需求，权衡性能提升与迁移成本。
Q&A
Akka事件溯源应用在数据库迁移时，为什么推荐从CockroachDB迁移到AlloyDB？
因为AlloyDB在大量写入操作中表现出高性能，而CockroachDB在垂直扩展后仍无法突破每秒2000次写入的性能瓶颈。迁移到AlloyDB可以获得更低的延迟和更高的吞吐量。
AlloyDB是什么？它有哪些主要特点？
AlloyDB是谷歌的全代管式数据库服务，兼容PostgreSQL，具有出色的性能、可用性和扩缩能力。它会自动执行备份、复制、修补和容量管理等任务，并使用自适应算法和机器学习技术进行PostgreSQL真空管理、存储和内存管理、数据分层和分析加速。
CockroachDB在垂直扩展后写入性能如何？
CockroachDB在垂直扩展后仍无法突破每秒2000次写入的性能瓶颈。
针对Akka Persistence插件，推荐使用哪种数据库模式？
推荐使用Akka Persistence的r2dbc模式。
这项研究是如何测试数据库性能的？
研究通过自定义工具进行了负载测试，以验证AlloyDB和CockroachDB在不同硬件配置下对Akka Persistence插件的数据库模式的写入吞吐量和延迟的影响。
CockroachDB是什么？它有哪些特性？
CockroachDB是一个自托管的云原生分布式SQL数据库，旨在构建、扩展和管理现代数据密集型应用程序。它基于事务性和强一致性键值存储构建，支持水平缩放，能够在磁盘、机器、机架甚至数据中心发生故障时以最小的延迟中断且无需人工干预，支持强一致性ACID事务，并提供熟悉的SQL API。
