Facebook(现为 Meta)工程师 Avinash Lakshman 和 Prashant Malik 创建了 Cassandra,用于支持 Facebook 的收件箱搜索功能。他们需要一个能够在多台服务器上存储和搜索海量数据集,且不会导致速度变慢的系统。
为了构建该系统,该团队从另外两个成熟的数据库模型中汲取了灵感:将 Google 2006 年 Bigtable 论文中介绍的宽列存储模型与 Amazon 的 Dynamo 的分布式环形架构相结合。该项目以特洛伊神话中的女先知卡珊德拉 (Cassandra) 命名,暗合其“预言无人信服”的悲情宿命。
随着该项目的潜力在更广泛的工程社区中逐渐显现,它迅速发展壮大:
凭借其深厚积淀,众多公司信赖 Cassandra 为其系统提供核心支撑。虽然 Cassandra 仍然是高可用性系统的可靠选择,但评估其设计权衡有助于团队决定自行管理旧架构是否符合现代应用的需求。
Cassandra 常用于处理涉及稳定数据流的工作,例如来自智能 (IoT) 传感器、应用日志记录和监控流水线的信息。它还广泛用于事件跟踪和推荐系统,在这些系统中,快速大规模地保存和查询数据至关重要。
无法承受停机时间的系统会使用 Cassandra,因为它的多数据中心复制和异步写入功能允许整个数据中心离线,而不会中断服务或丢失数据。许多全球性公司都依赖此功能来确保其应用在不同区域全天候运行。
Cassandra 采用点对点设计,其中所有节点完全对等。这些节点以去中心化的环形结构设置,并使用称为“一致哈希”的方法来均匀分布数据,防止出现瓶颈,并确保没有单点故障。您还可以选择数据库在检查读写是否成功时的严格程度,从而根据特定应用需求在速度和最新数据之间做出权衡。
该数据库使用一种称为宽列存储区的模型,可帮助您将数据整理到键空间、行和动态列中,类似于常规电子表格,但更加灵活。这样,您就可以设计出易于随着应用发展而更改的数据。
特性 | Apache Cassandra | 传统 RDBMS |
数据模型 | 反规范化 | Normalized |
架构灵活性 | 可在运行时更改 | 需要停机 |
索引结构 | 日志结构合并树 | B 树 |
写入优化 | 主要集群 | 次要 |
CAP 定位(一致性、可用性、分区容错性) | AP(可用性和分区容错性) | CA(一致性和可用性) |
查询功能 | CQL(无 JOIN) | 包含联接的完整 SQL |
数据模型
反规范化
Normalized
架构灵活性
可在运行时更改
需要停机
索引结构
日志结构合并树
B 树
写入优化
主要集群
次要
CAP 定位(一致性、可用性、分区容错性)
AP(可用性和分区容错性)
CA(一致性和可用性)
查询功能
CQL(无 JOIN)
包含联接的完整 SQL
Cassandra 存储引擎依赖日志结构合并 (LSM) 树来处理数据。传入的写入操作会写入提交日志以确保持久性,并通过 Memtable 保存在内存中。当 Memtable 写满时,数据会以不可变的排序字符串表 (SSTable) 形式刷写到磁盘。
这种仅附加设计是 Cassandra 在写密集型吞吐量方面表现出色的原因。通过避免就地更新,系统可以比依赖随机磁盘 I/O 的传统系统更快地处理传入数据。
以下是关于 Cassandra 的一些常见问题的解答。
它是一种分布式数据库,适用于需要始终保持在线并处理大量数据写入(例如流式传输日志或传感器数据)的应用。
Cassandra 是一种 NoSQL 数据库。它使用一种称为 CQL 的语言,该语言外观与 SQL 相似,但并不支持 SQL 的所有功能,例如复杂联接或深度事务安全。
Kafka 用于实时移动数据,而 Cassandra 用于安全地存储数据。它们通常在同一个系统中结合使用。
Cassandra 最适合大规模写入大量数据。MongoDB 是一种文档数据库,如果您需要搜索具有灵活结构的不同类型的数据,它通常是更好的选择。
Cassandra 专为在线事务处理 (OLTP) 而设计,这意味着它擅长处理简单、高速的读写操作。它并非专为复杂的分析任务而构建,例如运行大型报告或一次扫描所有数据。
可伸缩性
您可以添加更多节点来处理更多工作,而且无需关闭系统即可完成。
没有单点故障
由于所有节点都是平等的,因此系统非常稳定。
自动复制数据
系统会自动将您的数据保存到多个位置。
快速写入
存储设计旨在一次处理大量写入操作。
可调优一致性
您可以根据每个查询控制数据的严格程度。选择“所有”节点可获得完美准确度,选择“一个”节点可获得尽可能快的速度。
不受制于特定供应商
由于它在标准硬件上运行,因此您不会受制于特定的云服务提供商。您可以根据需要在本地设置和不同云之间移动数据。
运行自己的 Cassandra 系统需要大量开销。您必须规划所需的空间大小、设置服务器、处理维修、确保有备份,并在系统运行时执行更新。
托管式服务可以为您处理繁重的工作,从而改变这一现状。
通过将这些运营任务转移到托管式平台,您的团队无需再为数据库的底层架构细节操心,从而能够专注于为用户创造价值。
在决定如何运行 Cassandra 工作负载时,您有三种主要途径。
选择合适的路径取决于如何平衡团队的专业知识与特定业务需求。请使用此核对清单来指导您的决策过程:
问题 | 如果是… | 如果不是… |
我们是否有时间修复和调优数据库? | 如果您有专门的工程师负责“数据库管道”,则可以处理自行管理的集群。 | 选择托管式服务,避免将工程时间浪费在基础设施维护上。 |
“保持在线”是否比绝对的一致性更重要? | Cassandra 的 AP 模型非常适合高可用性应用。 | 不妨考虑 Cloud Spanner,它兼具分布式系统的扩缩能力与严格的数据安全保障。 |
随着业务增长,我们是否需要快速扩容? | 使用托管式服务或 Bigtable,它们提供自动扩缩功能来应对流量高峰。 | 静态集群或许可行,但在繁忙时段可能会面临性能瓶颈的风险。 |
托管式服务能否让我们的工作更可靠? | 当然可以;托管式服务可自动执行备份和修补,以防止人为错误。 | 您将承担手动维护带来的更高风险和潜在的配置错误。 |
我们是否以基础设施可移植性为目标? | 自行管理赋予了您最大的自由度,既可以在不同云平台之间迁移,也可以在本地环境中运行。 | 您愿意接受云专属优势,以换取更低的运维投入。 |
问题
如果是…
如果不是…
我们是否有时间修复和调优数据库?
如果您有专门的工程师负责“数据库管道”,则可以处理自行管理的集群。
选择托管式服务,避免将工程时间浪费在基础设施维护上。
“保持在线”是否比绝对的一致性更重要?
Cassandra 的 AP 模型非常适合高可用性应用。
不妨考虑 Cloud Spanner,它兼具分布式系统的扩缩能力与严格的数据安全保障。
随着业务增长,我们是否需要快速扩容?
使用托管式服务或 Bigtable,它们提供自动扩缩功能来应对流量高峰。
静态集群或许可行,但在繁忙时段可能会面临性能瓶颈的风险。
托管式服务能否让我们的工作更可靠?
当然可以;托管式服务可自动执行备份和修补,以防止人为错误。
您将承担手动维护带来的更高风险和潜在的配置错误。
我们是否以基础设施可移植性为目标?
自行管理赋予了您最大的自由度,既可以在不同云平台之间迁移,也可以在本地环境中运行。
您愿意接受云专属优势,以换取更低的运维投入。
如果您不想再自行管理 Cassandra,Google Cloud 提供了两种实用的解决方案:Bigtable 和 Spanner。
如果您已经在使用 Cassandra 的宽列存储和高写入吞吐量,那么 Bigtable 可能非常适合您。如需使用该服务,您可以将现有的 Cassandra 键空间和表映射到 Bigtable 表,然后更新应用代码以使用 Cloud Bigtable 客户端库。由于 Bigtable 是全托管式服务,因此它会自动处理分片和负载均衡,而这些操作以前需要在 Cassandra 中手动微调。
如果您的 Cassandra 工作负载已增长到需要更强一致性的程度,或者您发现自己需要 SQL 的关系型功能,那么 Spanner 也可能是一个不错的选择。如要使用它,您需要使用标准 SQL 定义架构,这可能需要您对一些非规范化的 Cassandra 数据进行规范化。它提供与 Cassandra 相同的横向扩缩能力,但增加了强全局一致性和完整关系型 SQL 支持等优势。