在 Amazon Keyspaces 上运行的 Apache Cassandra 兼容数据库 - 以无服务器起步的广域分布式数据库
以无服务器方式运行与 Apache Cassandra 兼容的宽列数据库。本文介绍按需与预置容量的选择以及分区键的设计。
Keyspaces 的特点及与 Cassandra 的区别
Keyspaces 是与 Apache Cassandra 兼容的托管数据库服务。使用 CQL 创建表并读写数据，可以利用现有的 Cassandra 驱动程序（DataStax Java Driver 等）。但是，连接时必须启用 TLS，使用 IAM 认证时还需要对 SigV4 认证插件进行额外配置。运维 Cassandra 集群所需的节点管理、补丁应用、修复处理和压缩调整都不再需要。但是，并非 Cassandra 的所有功能都受支持，用户定义函数（UDF）、物化视图、SUM 和 AVG 等聚合函数等均不受支持。另一方面，基于 Lightweight Transactions（LWT）的条件写入完全受支持。迁移前需要确认兼容性矩阵，并验证应用程序使用的 CQL 功能是否受支持。
容量模式与分区设计
按需模式根据请求量自动扩展，无需事先进行容量规划。它适用于流量模式难以预测的情况以及开发 / 测试环境。预置模式可以事先指定读取/写入容量单位，并通过 Auto Scaling 自动调整。在流量稳定的生产环境中，预置模式的成本效率更高。分区键的设计与 Cassandra 同样重要，选择基数高、能使访问均匀分布的键。热分区会导致限流，因此对于时间序列数据，需要采取不仅使用时间戳、还组合桶 ID 等措施。
安全与备份
Keyspaces 默认启用静态加密，可以选择 AWS 托管密钥或客户托管密钥（KMS）。传输中的数据通过 TLS 加密。访问控制通过 IAM 策略管理，可以进行表级别的精细权限设置。启用时间点恢复（PITR）后，可以将表恢复到过去 35 天内的任意一秒。这对于从误删数据或应用程序缺陷导致的数据损坏中恢复是有效的。PITR 会产生额外费用，但强烈建议在生产环境中启用。
Keyspaces 的费用
以下是截至 2026 年 8 月、东京区域的单价。按需模式下，读取每 100 万个请求单位 0.1425 美元，写入每 100 万个请求单位 0.715 美元，仅对实际读写的量计费。预置模式按预留容量的小时数计费。每个读取容量单位（RCU）0.0001484 美元/小时，每个写入容量单位（WCU）0.000742 美元/小时（按 730 小时换算，每个 RCU 约 0.11 美元/月，每个 WCU 约 0.54 美元/月）。写入的单价是读取的 5 倍，这一点是容量设计中容易忽视的因素。存储为每 GB 每月 0.285 美元，启用 PITR 后，用于恢复的数据还会额外产生每 GB 每月 0.228 美元的费用。通过 TTL 自动删除也另行计费，每 100 万次删除 0.315 美元。与 DynamoDB 相比，计费体系的思路相近；由于 Keyspaces 通过 CQL 访问，其优势在于现有 Cassandra 工作负载的迁移成本（应用程序修改）低。另外，最初 3 个月内，每月读取 / 写入各 3,000 万个请求单位和 1 GB 存储属于免费套餐的范围。
数据建模与查询设计
在 Keyspaces 这样的宽列数据库中，设计思路与关系型数据库不同。基本做法是“查询驱动”，即先确定查询模式，再据此设计表。根据预期的检索来设计决定数据如何分布的分区键，以及决定分区内排列顺序的聚类列。与规范化相比，将所需数据集中保存的非规范化常常更合适。由于它不擅长事后按任意条件检索，因此最初梳理访问模式并进行建模，是发挥性能的前提。
一致性与性能的平衡
Keyspaces 可以选择读取的一致性级别。希望始终可靠地读取最新值时选择强一致性，希望容忍一定延迟并优先考虑性能和可用性时选择宽松的一致性。一致性越强，在响应和负载方面的成本就越高，因此根据数据的性质分别使用。多个处理同时更新同一数据时的冲突，可以通过基于 LWT 的条件写入来防止。在 Cassandra 中，由于 LWT 会因共识处理而变慢，避免使用 LWT 的设计是常见做法；但在 Keyspaces 中，LWT 没有性能上的损失，可以像普通写入一样使用。在设计时兼顾所需的一致性与延迟、吞吐量之间的平衡，是有效利用宽列数据库的关键。
迁移与应用程序集成
Keyspaces 与 Cassandra 兼容，可以使用面向 Cassandra 的查询语言（CQL）和现有的驱动程序。需要改写的是连接部分：在启用 TLS 的基础上，要么在使用 IAM 认证时添加 SigV4 认证插件，要么签发并配置服务专用凭证。除了这项连接设置之外，有可能在不对代码进行大幅修改的情况下迁移现有的 Cassandra 应用程序。但是，由于部分功能和行为存在差异，迁移前确认应用程序所依赖的功能是否受支持是重要的。由于以无服务器方式运行，省去了自行构建 / 运维 Cassandra 集群的工作，这是一大优势。在利用兼容性的同时事先验证支持范围的差异，可以实现顺畅的迁移和运维负担的减轻。
运维与监控
Keyspaces 是无服务器的，因此无需添加节点、应用补丁等集群管理工作。容量可以选择按需自动调整，或者根据预期负载进行预置。在运维中，监控读写吞吐量和限流的发生情况，并确认对分区的访问是否存在偏斜。访问集中到特定分区时，性能会达到上限，因此通过键设计来分散访问。借助持续备份，可以恢复到过去的任意时间点，为误操作和故障做好准备。由于管理工作量少，可以专注于设计和监控。
总结
Keyspaces 是可以通过 Cassandra 兼容的 CQL 访问的无服务器数据库。它消除了集群管理的负担，使用按需容量时按实际使用量计费。在将现有 Cassandra 工作负载迁移到 AWS 以及新建适合 Cassandra 数据模型的工作负载时，它是有效的。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。