Apache Cassandra 与 MongoDB 对比

Apache Cassandra 和 MongoDB 是广泛采用的 NoSQL 数据库，旨在存储和管理大量数据。

这两个数据库系统之所以受欢迎，部分原因是它们具有出色的可扩展性和可用性。两者也都已经使用了十多年：Cassandra 在 2008 年作为开源／开放源代码项目发布；次年发布 MongoDB。

尽管 Apache Cassandra 和 MongoDB 有相似之处，但其数据模型、架构和其他组件方面却存在显著差异。这些基础差异会影响它们在关键特征上的表现，并决定其最适合的数据管理用例。

在比较 Apache Cassandra 和 MongoDB 之前，了解 NoSQL 数据库会很有帮助。

NoSQL 数据库，也称为“Not Only SQL”（不仅是SQL）或“非SQL”数据库，属于分布式数据库。这意味着其中的信息会被复制到不同的节点（存储数据的单个服务器）。这种分布式架构支持高可用性和耐用性；如果一个或多个节点离线，数据库的其他部分可以继续运行。

然而，最值得注意的是，NoSQL 数据库旨在存储和查询关系数据库管理系统（RDBMS）中传统结构之外的数据。非关系型数据库的设计不必遵循传统关系数据库固有的严格表格结构，也不需要固定的模式。这允许可扩展性来管理大型数据集，包括结构化、半结构化和 非结构化数据集。

（值得注意的是，包括 MongoDB 在内的 NoSQL 数据库所推崇的可扩展性是水平可扩展性或“横向扩展”。在水平可扩展性中，工作量可以在服务器之间分配，这与 SQL 数据库相关的垂直可扩展性或“扩展”相反，后者需要在现有硬件上添加内存。）

由于其性能、可扩展性和灵活性，NoSQL 数据库已成为支持大数据应用程序和实时工作负载的首选。除了 Apache Cassandra 和 MongoDB 之外，其他流行的 NoSQL 数据库还包括 DynamoDB（由 AWS 提供）、Redis 和 CouchDB。

尽管 Apache Cassandra 和 MongoDB 都起源于世纪之交几年后，但它们有着不同的历史。

Apache Cassandra 的历史可以追溯到 2007 年左右的 Facebook，当时工程师们正在寻找一种能够为公司不断发展的消息平台存储数据的系统。通过结合已建立的 NoSQL 数据库模型，他们创建了一个具有高效数据结构和最终一致性的系统——其中更新会传播，最终所有副本会在一段时间后达到一致。工程师们于 2008 年将 Cassandra 作为开源／开放源代码项目发布。一年后，Apache 软件基金会接管了管理工作。

MongoDB 始于 2007 年，作为 10Gen 公司平台即服务项目的一部分。该公司转而专注于 MongoDB（其名称巧妙取自 “humongous”（巨大）一词），并将其打造为一款运行快速、易于使用的文档型数据库。¹

10Gen 最终更名为 MongoDB Inc.，于 2009 年将 MongoDB 作为开源／开放源代码项目发布。但是，最新版本的 MongoDB 是根据服务器端公共许可证 v1 发布的。

Apache Cassandra 和 MongoDB 之间的根本区别影响了它们的性能和理想用例。关键要素包括：

• 数据模型
• 架构和存储
• 查询和其他语言

NoSQL 数据库依赖于四种数据模型之一：

• 文档模型：数据存储为结构化文档，通常为JSON（JavaScript 对象表示法）或 BSON（二进制 JSON）。
• 宽列模型：数据存储在具有稀疏列的表中，这意味着表中的每一行可以有不同的列数。
• 键值模型：数据存储为键值对（标识符或标签与特定值配对）。
• 图形模型：数据存储为节点和边缘，表示实体和关系。

Cassandra的数据模型是宽列模型，也称为宽列存储。Cassandra 表中的每一行都有一组列和一个用于在节点和数据中心之间分配数据的唯一分区键。行由主键标识，主键可以由分区键和可选的簇键（可以唯一标识分区或相关组内的行的列）组成。

这种方法比关系数据库更灵活，关系数据库将空间分配给一定数量的列。通过 Cassandra 的数据模型，仅在必要时使用列可以实现更高效的存储空间和更快的查询。²

相比之下，MongoDB 使用文档模型。数据主要存储为 BSON，这是 MongoDB 开发的 JSON 的二进制表示形式。

BSON 有助于解决标准 JSON 给数据库带来的障碍：支持有限的数据类型、对象缺乏固定长度（这会减慢遍历速度）以及缺乏元数据（这会减慢文档检索）。BSON 旨在通过对格式和长度信息进行编码来优化速度和效率。它还支持一些非原生 JSON 数据类型，例如日期和二进制数据。³

作为 NoSQL 数据库，Apache Cassandra 和 MongoDB 都支持分布式系统，并将数据存储在多个计算资源中以减少停机时间。但是，就像他们的数据模型一样，这个分布的底层架构有着根本的不同。

Apache Cassandra 依赖于点对点架构。Cassandra 簇中的每个节点都是平等的，不依赖于主节点。当数据放入簇时，哈希函数将应用于行的分区键，并使用输出将数据分配给特定节点。数据也被复制到其他节点。

Cassandra 数据存储的复制因子描述了数据库中存储的数据副本数。Cassandra 的存储空间引擎使用由提交日志、内存表（memtable）和排序字符串表（SSTable）文件组成的逐步流程（或写入路径）。

与 Cassandra 相比，MongoDB 使用主/从模型的分布式架构。在 MongoDB 中，副本集（一组实例）由主节点和辅助节点组成，主节点负责处理所有写入操作（数据添加或修改），辅助节点则复制主节点中的数据。

MongoDB 中的大型数据集也可以通过称为分片的过程分发到多台机器。信息被分成分片簇—多个副本集和一个将应用程序的查询传输到副本集的路由器—以提高系统处理数据请求的能力。

数据库也采用不同的索引方法。在 Apache Cassandra 中，主索引是分区键，尽管 Cassandra 文档提到存储附加索引（具有非分区列的索引）适用于大多数用例。⁴ Cassandra 还具有二级索引，这些是本地索引，存储在与包含被索引列的数据表相分离的表中。MongoDB 支持针对不同用例的几种不同的索引类型，包括地理空间索引、多键索引和文本索引。

根据定义，NoSQL 数据库不使用结构化查询语言 (SQL)，即关系数据库的标准化编程语言。但是，Apache Cassandra 和 MongoDB 都有自己的查询语言。

Cassandra 使用名为 Cassandra 查询语言 (CQL) 的定制 SQL 版本。虽然 CQL 在很大程度上类似于 SQL，但两者之间也存在关键区别。例如，SQL 适用于规范化表，而 CQL 专为与分区键对齐的非规范化 Cassandra 数据而设计。此外，SQL 针对事务进行了优化，而 CQL 专为实时查询和大容量写入操作而设计。

MongoDB 使用 MongoDB 查询语言 (MQL)。MQL 专为查询文档模型而设计，其语法与文档相同，与 SQL 相比更偏离 Cassandra 查询语言。MQL 因其强大的查询与数据操作能力而备受推崇，涵盖复杂查询、聚合管道，以及对地理空间数据的检索⁵

除了各自的查询语言外，数据库在编程支持方面也有所不同。MongoDB 提供 Java、Python、Ruby 和 Node.js 等十几种编程语言的官方驱动程序。这些语言和其他语言也与 Cassandra 兼容，但驱动程序主要由第三方提供商提供。

Apache Cassandra 和 MongoDB 之间的根本区别导致了它们在性能相关特征上的一些差异。这些变化也可以用 CAP 定理来解释。

CAP 是缩写，表示分布式系统的三个所需特征：一致性（所有客户端在同一时间看到相同的数据）、可用性（发出数据请求的任何客户端都会收到响应，即使一个或多个节点发生故障）和分区容错性（即使两个或多个节点之间的通信发生故障，集群节点也能继续运行）。

CAP 定理规定分布式系统只能提供三个所需特性中的两个。Apache Cassandra 通常归类为“AP”数据库，主要依靠可用性和分区容错来提供高性能。

同时，MongoDB 被称为“CP”数据库，在分区容错和一致性方面表现出色。但对于这两个数据库，也有措施来提高据称受损特性的性能，即 Cassandra 的一致性和 MongoDB 的可用性。

让我们仔细看看这三个理想的特征。

Cassandra支持高可用性，因为作为一个将数据复制到多个节点的去中心化系统，它具有高容错能力且没有单点故障。如果一个节点发生停机时间，其他拥有相同数据副本的节点可以满足数据请求。此外，将数据复制到世界各地的数据中心，可为本地用户提供低延迟。

由于 MongoDB 的架构基于主/从模型，因此当主节点发生故障时可能会发生单点故障。然而，MongoDB 的故障转移被认为是强大的：在所谓的副本集选举期间，属于副本集的节点会选择一个新的主节点来替换不可用的主节点。此过程还使 MongoDB 还能够提供高可用性，尽管会有短暂的延迟 — 只有在选择新的主节点后性能才会恢复。

MongoDB 本质上提供了高一致性，因为所有客户端都写入单一可信信息源 — 每个副本集只能有一个接收所有写入操作的主节点。相比之下，Apache Cassandra 提供最终一致性：客户端可以随时向任何节点写入数据，然后尽快解决不一致问题。

Cassandra 还允许用户通过所谓的可调一致性来优化一致性（同时降低可用性）。用户可以选择一个一致性级别，以设置在向客户端应用程序确认读取或写入之前必须确认多少副本。更高级别的一致性需要更多副本以确认的方式做出响应，但这也会增加延迟并降低可用性。

Apache Cassandra 和 MongoDB 都提供分区容错性，因为即使在系统的某一部分发生通信故障时，各自的设计也能继续运行。

在 Apache Cassandra 中，出现通信问题时，节点仍然可用，但在分区解决之前，某些节点可能无法提供最新版本的数据（以响应数据请求）。在 MongoDB 中，可用性受到限制，以确保在处理分区时的数据一致性。

通常建议将 Apache Cassandra 用于可用性和可扩展性至关重要的高吞吐量、全球分布式写入密集型工作负载（例如流媒体和娱乐）。例如，Netflix 等流媒体服务使用 Cassandra 来处理全球用户活动。

MongoDB 非常适合以文档为中心、模式灵活的用例，这些用例受益于开发人员的敏捷性和强大的一致性。公司通常依靠 MongoDB 来支持其内容管理系统，因为 MongoDB 存储并提供一系列内容资产。

尽管这两种数据库存在差异，但 Apache Cassandra 的用例和 MongoDB 的用例可能会重叠。每个数据库的成功案例都证明了其在物联网 (IoT) 应用、电子商务等方面的有效性。