Discord从Cassandra迁移到ScyllaDB的总结

背景与动机

Discord最初使用MongoDB存储消息，但随着数据量的增长，于2017年迁移到Apache Cassandra。Cassandra在初期表现良好，但随着时间推移，集群规模扩大到177个节点，性能问题逐渐显现，尤其是由于表模式设计导致的“热分区”问题，影响了整个数据库集群的延迟。

热分区问题

热分区问题主要源于Discord基于频道和时间段的分区设计。当一个频道和时间段对的流量过大时，相关节点的延迟会显著增加，进而影响整个集群的性能。由于Cassandra采用仲裁一致性级别，所有针对热分区的查询都会受到延迟影响，导致用户体验下降。

迁移到ScyllaDB

为了解决Cassandra的性能问题，Discord决定迁移到ScyllaDB。ScyllaDB在性能上表现更优，尤其是避免了Cassandra中垃圾回收相关的问题。在迁移过程中，Discord还与ScyllaDB团队合作，优化了反向查询等关键用例。

数据服务层的引入

在迁移过程中，Discord引入了一个新的中间服务层——数据服务层，使用Rust编写并通过gRPC接口进行交互。该层的主要职责包括：

1. 请求合并：避免多个用户请求相同消息时重复调用数据库。
2. 一致性哈希路由：基于路由键（如频道ID）将请求路由到数据服务实例，显著减少了热分区问题。

迁移过程与解决方案

Discord在迁移过程中首先考虑使用ScyllaDB的Apache Spark迁移工具，但最终选择使用Rust实现自定义解决方案，并使用SQLite进行检查点记录。这一策略将迁移时间从3个月缩短至9天。迁移完成后，团队在2022年5月成功切换到ScyllaDB。

迁移后的效果

迁移后，新的ScyllaDB集群表现出色，提供了稳定的性能，并能够处理世界杯期间产生的额外流量。迁移不仅减少了集群规模（从177个Cassandra节点减少到72个ScyllaDB节点），还显著降低了读写操作的尾部延迟，解锁了新的产品用例。

结论

Discord通过从Cassandra迁移到ScyllaDB，解决了长期困扰的性能问题，并显著提升了数据库的稳定性和可扩展性。引入数据服务层和自定义迁移工具是这一成功迁移的关键因素。