Cassandra：开箱即用的高度可扩展数据库

Cassandra 是一个分布式、去中心化、可扩展且高度可用的宽列数据库。

根据CAP定理，Cassandra代表AP（可用性和分区容错性）。

这意味着 Cassandra 希望所有客户端即使在并非所有节点都可用的情况下也能找到数据，并且在发生部分网络故障时也能按预期工作。然而，这也意味着数据的一致性可能会为了可用性和分区容错性而受到损害——用户会看到数据，但它可能会过时一段时间。

Cassandra 旨在实现高吞吐量和更快的写入操作。

而正是牺牲一致性才让Cassandra具备了高可用。

Cassandra 是一个 NoSQL 数据库，不支持表连接、外键，也不支持在查询时在 WHERE 子句中添加除主键以外的列。在选择使用 Cassandra 之前应考虑这些限制。

卡桑德拉构建块

• 列：列代表键值对，是数据结构的基本单位。
• Row ：充当主键引用的列的容器。
• Keyspace ：充当跨一个或多个 Cassandra 节点的表的容器。
• Cluster ：Cassandra 中键空间的容器。
• 节点：指运行 Cassandra 实例的计算机系统。节点可以是物理主机、云中的机器实例，甚至是 Docker 容器。

Cassandra 如何存储数据

Cassandra 将数据存储为列族。它充当主键引用的列的容器。

列族的一行包含多个具有键和值的列，行键作为主键：

列族可以为每个行键存储一组不同的列：

Cassandra 中的主键是什么？

主键唯一标识表的每一行。在 Cassandra 中，主键有两部分：

在 Cassandra 中，分区键确定哪个节点存储数据，而集群键确定数据在节点内的存储方式。例如，考虑一个带有

PRIMARY KEY (city_id, event_id) 。该主键由两部分组成，由两列表示：

1. city_id作为分区键，意味着数据将根据city_id字段进行分区，导致具有相同city_id的所有行都存储在同一个节点上。

2. event_id充当聚类键。在每个节点内，数据根据event_id列按排序顺序组织和存储。

分区键=“Paris”的每一行都将存储在同一节点上，并按 event_id 列的值排序。

开箱即用的数据分区

Cassandra 提供基于一致性哈希的数据分区，以减少读/写操作的延迟，并在数据库中存储的数据量变大时提高系统的吞吐量。

Cassandra 中的分区器负责决定数据如何在一致性哈希环上分布。当数据插入 Cassandra 集群时，分区器会对分区键应用哈希算法。这种哈希算法的结果决定了数据落入的范围，并决定了数据将存储在哪个节点上。

协调节点

在 Cassandra 中，每个节点通过gossip 协议了解其他节点的令牌分配，从而允许任何节点处理任何其他节点范围的请求。因此，客户端可以连接到任意节点发起读或写查询。

接收请求的节点称为协调器，可以是集群中的任何节点。如果某个键不属于协调器的范围，则请求将转发到负责该范围的副本。

复制

Cassandra 跨多个节点复制数据以确保高可用性。 Cassandra 中的每个节点都充当特定数据范围的副本。通过将数据的多个副本分布在不同的副本中，Cassandra 使其他副本能够在一个节点不可用的情况下处理对该数据范围的查询。有两个设置会影响复制过程：

复制因子决定有多少节点将存储相同数据的副本。在复制因子为 3 的集群中，每一行将存储在三个不同的节点上。

在 Cassandra 中，第一个副本会根据分区键的哈希值分配给拥有该范围的节点。然后将剩余的副本按顺时针方向放置在连续的节点上。 Cassandra 使用两种复制策略来确定哪些节点将负责副本：

简单的复制策略

在该策略中，第一个副本放置在分区器确定的节点上，后续副本按顺时针方向放置在后续节点上。

网络拓扑策略

为了确保数据完全丢失的恢复能力，同一数据中心内的其他副本通过沿环顺时针移动的方式放置，直到到达不同数据中心的第一个节点。这种安排有助于减轻同一数据中心内通常由于电源、冷却或网络问题而发生的同时故障的影响。

何时使用 Cassandra

Cassandra 擅长处理需要处理大量数据并将数据可用性置于一致性之上的应用程序。它非常适合：

1.物联网 (IoT) 应用：Cassandra 是物联网环境的理想选择，因为它可以处理设备和传感器生成的大量数据。其分布式架构能够管理地理上分散的大规模数据。

2.时间序列数据：处理时间序列数据（例如指标、监控系统和遥测数据）的应用程序受益于 Cassandra 的高效写入操作和水平可扩展性。这些功能对于存储和管理大量带有时间戳的数据至关重要。

3. Web 和移动应用程序：Cassandra 提供高吞吐量和低延迟的数据访问，使其适合具有大量用户群并生成大量数据的 Web 和移动平台。这包括社交媒体平台、游戏应用程序和电子商务网站。

4.实时大数据分析：Cassandra 支持大数据的实时处理，使其成为需要从大型数据集中立即获得洞察的应用程序的宝贵选择。示例包括推荐引擎和欺诈检测系统。

5.分布式数据仓库：拥有大型分布式数据集的企业可以利用 Cassandra 作为数据仓库解决方案。其跨多个数据中心复制数据的能力可确保高可用性和灾难恢复。

6.消息系统：Cassandra 的高写入和读取吞吐量使其非常适合处理大量数据的消息系统，例如事件日志记录、审计跟踪或消息队列。

7.个性化和内容管理系统：需要大规模个性化内容交付的应用程序（例如内容管理系统）受益于 Cassandra 向大量用户同时交付定制内容的速度和可扩展性。

8.地理分布式应用程序：Cassandra 对多个数据中心的支持使其成为需要地理分布式数据的应用程序的绝佳选择。确保跨区域的低延迟数据访问并提供高弹性。

何时不使用 Cassandra

虽然 Apache Cassandra 功能强大且可扩展，但它可能并不适合所有应用程序或用例。不太适合事务密集型应用、复杂查询以及需要强一致性或快速架构更改的场景。在这种情况下，传统的关系数据库管理系统 (RDBMS) 或其他 NoSQL 解决方案可能更合适。以下是 Cassandra 可能不是最佳选择的几种情况：

1. 小型项目：对于小型项目或数据集有限的应用程序来说，Cassandra 的复杂性和资源需求可能会过高。更简单的数据库解决方案可能提供更具成本效益和更易于管理的替代方案。

   
   

2. 需要 ACID 属性的事务系统：Cassandra 不完全支持 ACID（原子性、一致性、隔离性、持久性）属性。如果您的应用程序需要银行或金融系统中常见的复杂交易，那么传统的 RDBMS 可能更适合。

   
   

3. 连接大量查询和聚合：如果您的应用程序严重依赖连接、子查询或复杂聚合，Cassandra 可能不是最合适的选择。它专为快速写入和读取而设计，但不适用于复杂的查询处理。

   
   

4. 具有强一致性要求的数据：Cassandra提供了最终一致性，这可能不适合每次读写操作都需要强一致性的用例。

   
   

5. 单集群中的低延迟读写：虽然 Cassandra 在多节点分布式环境中表现良好，但对于需要低延迟读写的单节点或小型集群部署来说，它可能不是最佳选择。

   
   

6. Blob 存储：Cassandra 并未针对存储大型二进制对象（blob）（例如图像或视频）进行优化。其他存储解决方案更适合高效处理大型 blob。

   
   

7. 需要即席查询的应用程序：与成熟的 SQL 数据库相比，Cassandra 的查询功能有限。它不太适合严重依赖即席查询和报告的应用程序。

   在 Cassandra 中，表的设计与数据的访问方式密切相关，强调查询模式而不是仅仅关注数据实体之间的关系。这与 RDBMS 中的方法不同，其中模式设计基于规范化原则。

   
   

8. 快速架构演变：如果您的应用程序需要频繁更改数据库架构，那么与传统 RDBMS 系统或其他 NoSQL 解决方案相比，Cassandra 的架构管理可能不太灵活。

   
   

9. 涉及复杂查询、联接和历史数据分析的数据仓库应用程序：虽然 Cassandra 非常适合写入密集型工作负载和实时数据访问，但对于需要复杂查询、连接和历史数据分析。

概括

本文概述了 Cassandra，这是一个高度可扩展的分布式宽列数据库。 Cassandra 旨在优先考虑可用性和分区容错性，使其适合一致性不是关键要求的应用程序。它支持高吞吐量和更快的写入操作。

Cassandra 的构建块包括列、行、键空间、集群和节点。列表示键值对，行充当主键引用的列的容器，键空间充当跨越多个节点的表的容器，集群包含键空间，节点指运行 Cassandra 实例的计算机系统。

Cassandra 将数据存储在列族中，列族是主键引用的列的容器。数据分区是通过一致的散列实现的，可以减少延迟并增加吞吐量。分区器在一致性哈希环上分配数据，协调器节点处理读写查询。

Cassandra 提供复制以实现高可用性。数据的副本存储在多个节点上，确保在节点不可用时可以通过副本处理查询。复制因素和策略决定副本的数量以及负责副本的节点。

虽然 Cassandra 提供了可扩展性和高可用性等优势，但它也有局限性。它不支持表连接、外键或在查询期间在 WHERE 子句中添加除主键以外的列的功能。

总体而言，Cassandra 是一个功能强大的数据库解决方案，适用于高度可扩展的应用程序，特别是那些优先考虑可用性和分区容错性而不是强一致性的应用程序。

干杯!