作者 | 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，确保连接安全性的同时不会中断迁移。

数据传输完成后，团队通过验证阶段来确认数据准确性，对比的重点是值而不是时间戳。出于延迟考虑，验证作业使用的资源减少了。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 解决方