作者 | Claudio Masolo
译者 | 王强
策划 | Tina
在最近的一篇文章中，管理着超过 70 TB 数据的全球旅游技术公司 Expedia Group 披露了其将包含超过 50 个表和数千个连接的 Cassandra 集群迁移到 ScyllaDB 的过程。此次迁移的主要动机是利用 ScyllaDB 内置的变更数据捕获（CDC）功能来提高数据一致性并降低运维复杂性。
这类数据库迁移工作面临着重大挑战，尤其是过程中需要维持应用程序访问能力，还要处理大量数据。具体到这次迁移，其关键目标是零停机、持续的 TLS 连接、数据一致性以及适应延迟敏感的应用程序。
此次迁移工作从名为 Identity 的 Cassandra 集群开始进行，该集群保存了用于用户身份验证和会话的敏感数据。由于数据量巨大，迁移过程需要传输 1 TB 的非压缩数据（加上复制总共 3 TB），并且这些数据非常重要，这意味着任何停机或数据丢失事故都会损坏 Expedia Group 的平台。
原先的架构由 Cassandra 的变更数据捕获（CDC）与 Debezium（第三方变更跟踪库）配对组成，引入了额外的故障点，使系统不够稳定。如果 Debezium 停止处理事件，启用 CDC 的表可能会被阻止，从而导致整个集群陷入不稳定状态。根据需求和原先架构的特点，团队评估了两种迁移工具：SSTable Loader 和 Scylla Migrator。最终，Scylla Migrator 因其检查点功能、并行迁移支持和内置验证器的设计而被选中，它提供了比 SSTable Loader 更可靠的方法。
SStable Loader 架构Scylla Migrator 比 SSTable Loader 更可靠，尤其是考虑到需要暂停和恢复迁移（如果需要）更是如此。Scylla Migrator 还与 Spark 集成，可实现并行数据迁移并进一步提高效率。
Scylla Migrator 的工作机制准备 Spark 集群时需要对 Spark 和 Scylla Migrator 设置进行微调。内存分配和 Spark worker 实例经过调整，以在平衡性能时不会影响 Cassandra 的延迟敏感性。TLS 连接带来了额外的挑战；Cassandra 需要 TLS，但 Scylla Migrator 不支持团队使用的自签名证书。为了解决这个问题，团队在迁移期间暂时禁用了 TLS，后来在 ScyllaDB 中配置了一个新的数据中心，以便在完成后启用 TLS，确保连接安全性的同时不会中断迁移。
空集群键值和较大的表这个领域也体现出了技术复杂性。在迁移过程中，一些表的主键中包含空值，而 ScyllaDB 无法接受这些值。为了解决这个问题，团队在重新运行迁移作业之前识别并清除了有问题的数据。大型表还需要临时扩大 ScyllaDB 集群以处理更高的写入负载，并对拆分计数和工作核心进行额外调整以获得最佳性能。
数据传输完成后，团队通过验证阶段来确认数据准确性，对比的重点是值而不是时间戳。出于延迟考虑，验证作业使用的资源减少了。Scylla 验证器报告确认了数据一致性，在将应用程序切换到 ScyllaDB 之前，双重写入验证了两个集群的完整性。
整个迁移过程提供了几个关键见解。在单独的 CDC 实例上运行 Scylla Migrator 可尽可能减少生产流量的负载。此外，需要原始时间戳的数据类型带来了一些挑战，这是由于 CQL 协议限制，而非 Scylla Migrator 中的限制造成的。最后，迁移到 ScyllaDB 简化了 CDC 流程，需要的节点比 Cassandra 更少，同时保持高可用性，从而降低了 AWS 成本。
其他一些公司也决定迁移到了 ScyllaDB；以下是一些示例：
Cobli：一家巴西物流公司，从 Apache Cassandra 迁移到 ScyllaDB，以提高性能并降低成本。他们的性能提高了 10 倍，基础设施成本降低了 50%。
mParticle：一家客户数据平台，从 Apache Cassandra 迁移到 ScyllaDB，以提高性能并降低延迟。他们的查询性能提高了 10 倍，延迟降低了 50%。
总之，对于 Expedia 来说，迁移到 ScyllaDB 成功提高了效率、稳定性和成本效益，满足了 Expedia Group 对数据可用性和低延迟的严格标准，同时提供了更简单的 CDC 解决方案。
