Cassandra 兼容数据库 - 使用 Amazon Keyspaces 实现无服务器分布式数据库
介绍使用 Amazon Keyspaces（for Apache Cassandra）和 DynamoDB 的分布式数据库设计与运维方法。
Apache Cassandra 与 Amazon Keyspaces 的定位
Apache Cassandra 是以高写入吞吐量、线性可扩展性和多区域复制为特征的大规模分布式 NoSQL 数据库。在时序数据、事件日志、消息历史等写入密集型用途中，它被广泛用作大规模服务的基础，但本地运维需要高度专业知识。节点增删时的数据再平衡、压缩策略优化、墓碑管理、JVM 调优等运维任务涉及面广。Amazon Keyspaces 是 Apache Cassandra 兼容的全托管数据库服务，可直接使用 CQL（Cassandra Query Language）。现有 Cassandra 应用的驱动程序和工具几乎无需修改即可使用，在大幅降低运维负担的同时保持 Cassandra 的数据模型和查询模式。采用无服务器架构，创建表后即可立即读写数据，无需预先配置容量。
Amazon Keyspaces 的特性与架构
Amazon Keyspaces 以无服务器方式运行，表的吞吐量根据流量自动扩展。按需模式对读写请求按量计费，最大限度降低低流量时段的成本。预置模式可为可预测的工作负载提供高性价比的定价。存储自动扩展，数据以复制因子 3 复制到区域内的 3 个可用区。可用性 SLA 按配置分为两个级别，根据官方 SLA（2023 年 5 月 24 日更新版）的 Service Commitment，适用于单区域配置的 Standard SLA 规定月度正常运行时间为 99.99%，配置多区域复制时适用的 Multi-Region Replication SLA 为 99.999%。请注意，向 3 个可用区的复制是支撑单一区域内持久性的机制，其本身并不构成 99.999% 的依据。静态和传输中的加密默认启用，也可使用 AWS KMS 的客户托管密钥。Keyspaces 支持 CQL 3.11 API（向后兼容 2.x），表定义、数据类型、查询语法与 Cassandra 兼容。基于轻量级事务（LWT）的条件写入（如 IF NOT EXISTS）和 counter 类型均受支持，使用 LWT 不收取额外费用。但条件判定为 FALSE 的写入仍会按行大小消耗写入单位，因此需通过 CloudWatch 的 ConditionalCheckFailed 指标监控失败次数。官方兼容性列表（截至 2026 年 8 月）中列为不支持的功能包括二级索引（CREATE INDEX / DROP INDEX）、物化视图、触发器、用户定义函数（UDF）和聚合函数、ALTER TYPE、TRUNCATE 等。静态列、TTL、LOGGED / UNLOGGED BATCH、用户定义类型（UDT）可以使用。通过 Point-in-Time Recovery（PITR），可将表恢复到过去 35 天内的任意时间点，便于从误操作或数据损坏中恢复。以下是在 Keyspaces 中创建表的 CQL 示例。 CREATE TABLE my_keyspace.orders ( customer_id text, order_id timeuuid, product_name text, quantity int, total_amount decimal, PRIMARY KEY (customer_id, order_id) ) WITH CLUSTERING ORDER BY (order_id DESC) AND CUSTOM_PROPERTIES = {'capacity_mode': {'throughput_mode': 'PAY_PER_REQUEST'}};
从 Cassandra 迁移到 Keyspaces 的策略
从现有 Cassandra 集群迁移到 Keyspaces 推荐采用分阶段方法。首先使用 cqlsh 或 DataStax 驱动程序验证与 Keyspaces 的连接，确认 schema 兼容性。数据迁移有两种方法：使用 AWS Glue 的批量迁移和双写（同时写入两个数据库）的渐进式迁移。使用 Glue 时，配置从 Cassandra 读取数据并写入 Keyspaces 的 ETL 作业。大规模数据集迁移时，在 Keyspaces 的预置模式下确保足够的写入容量，迁移完成后切换到按需模式较为高效。应用端的修改最小化，主要变更为连接端点的更改和 TLS 连接设置（Keyspaces 要求 TLS）。迁移时的性能测试中，基于 Keyspaces 对一致性级别的处理方式进行验证非常重要。写入为保证持久性始终以 LOCAL_QUORUM 执行，读取则从 ONE / LOCAL_ONE / LOCAL_QUORUM 三个级别中选择（默认值由驱动程序端的设置决定，因此显式指定更安全）。每次 4 KB 读取的消耗为 ONE / LOCAL_ONE 0.5 个单位、LOCAL_QUORUM 1 个单位，存在差异，因此应在迁移前确认一致性要求与延迟、成本之间的权衡。
Keyspaces 与 DynamoDB 的选择
在 AWS 上选择分布式数据库时，Keyspaces 和 DynamoDB 都是候选。Keyspaces 最适合作为现有 Cassandra 应用的迁移目标，可直接利用 CQL 知识和技能。可保持复合分区键和聚簇列的灵活数据建模、TTL（Time to Live）的数据自动过期、静态列的分区级共享数据等 Cassandra 特有的数据建模模式。Keyspaces 也支持多区域复制，在主动-主动配置中各区域独立处理读写，冲突通过 last writer wins 自动解决。区域间的复制延迟通常不到 1 秒，区域故障时的 RPO 为数秒级，故障转移只需通过 Route 53 切换路由即可（无需提升或故障转移操作）。不过，官方文档（截至 2026 年 8 月）中记载的限制包括：TTL 必须在创建多区域表时设置，之后无法启用、禁用或更改其值；静态加密仅支持 AWS 拥有的密钥，不能使用客户托管密钥；不支持同步复制和 QUORUM 一致性；AWS GovCloud (US) 和中国区域不在支持范围内。另一方面，DynamoDB 作为 AWS 原生服务，提供与 Lambda、AppSync、API Gateway 等的无缝集成。DynamoDB Streams 的事件驱动架构、全局表、DAX（DynamoDB Accelerator）的微秒级缓存等，与 AWS 生态系统的集成是其优势。对于没有 Cassandra 经验的团队进行新开发推荐 DynamoDB，现有 Cassandra 工作负载的迁移推荐 Keyspaces。两个服务都支持 IAM 认证、VPC 端点和加密，满足企业级安全需求。
Keyspaces 的费用
以下为基于截至 2026 年 8 月 AWS 官方价格表的单价，并列弗吉尼亚北部（us-east-1）和东京（ap-northeast-1）。按需模式读取每百万请求单位 0.125 USD（弗吉尼亚北部）/ 0.1425 USD（东京），写入每百万请求单位 0.625 USD（弗吉尼亚北部）/ 0.715 USD（东京）。预置模式不是按月而是按小时单价计费，每个读取容量单位（RCU）0.00013 USD/小时（弗吉尼亚北部）/ 0.0001484 USD/小时（东京），每个写入容量单位（WCU）0.00065 USD/小时（弗吉尼亚北部）/ 0.000742 USD/小时（东京）。写入单价约为读取的 5 倍，按每月 730 小时换算，弗吉尼亚北部每个 RCU 约 0.095 USD、每个 WCU 约 0.475 USD。存储每 GB 每月 0.25 USD（弗吉尼亚北部）/ 0.285 USD（东京），PITR 用备份存储每 GB 每月 0.20 USD（弗吉尼亚北部）/ 0.228 USD（东京），基于 TTL 的自动删除每百万条 0.275 USD（弗吉尼亚北部）/ 0.315 USD（东京），从备份恢复每 GB 0.15 USD（弗吉尼亚北部）/ 0.171 USD（东京）。东京比弗吉尼亚北部高出约一到两成，因此如果延迟要求允许，区域的选择本身就会带来成本差异。与 DynamoDB 的定价体系基本相同，但可通过 CQL 访问，因此现有 Cassandra 工作负载的迁移成本较低是其优势。
总结 - Cassandra 兼容数据库的最佳选择
根据工作负载特性和现有资产，选择作为 Cassandra 迁移目标的 Keyspaces 或 AWS 原生的 DynamoDB，可构建最优的分布式数据库策略。需要 CQL 兼容时选择 Keyspaces，重视无服务器灵活性时选择 DynamoDB。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。