📌 项目地址：apache/cassandra | ⭐ 9,930 颗星 | 🔧 Java | 📜 未标注
为什么需要 Cassandra
传统关系型数据库在单机写入压力过大或数据量超过存储上限时，通常只能垂直扩展（换更大的机器）或手工分库分表，而后者会显著增加运维复杂度和跨分片查询的成本。Cassandra 设计了另一种路线：通过哈希分区（一致性哈希）将数据自动均匀分布到集群中的多个节点，允许你通过增加廉价节点来线性提升吞吐量和存储容量，同时保持对客户端的单一入口。
它的另一个核心特性是去中心化——所有节点地位平等，没有主从选举，也就没有单点故障。任何一台机器宕机，剩下的节点继续提供服务，数据副本会自动补足。这些设计使其在需要高写入吞吐、多数据中心部署的场景下表现突出。
核心设计：数据分布、一致性、容错
- 数据分区：每个表必须定义主键（Primary Key），主键的第一部分决定数据所在的分区（Partition Key）。写入时 Cassandra 对该键做哈希计算，把行映射到具体的节点。
- 一致性级别（Consistency Level）：读写时可指定需要多少副本确认操作才算成功（例如 ONE、QUORUM、ALL）。这让你在可用性和一致性之间做权衡。
- Gossip 协议：节点之间通过反熵协议交换状态信息，任何节点退出或加入都能被集群迅速感知。
- Hinted Handoff 与修复：临时故障的节点恢复后，其他节点会重放积压的写入；定期运行
nodetool repair可以修复长期不一致的副本。
这些细节在官方文档（cassandra.apache.org/doc/latest/）中有完整的架构说明。
真实用法：从安装到第一个查询
官方 README 提供了两种快速启动方式。以下是最常见的本地试验步骤：
-
下载并启动
从 https://cassandra.apache.org/_/download.html 获取二进制包，解压后执行：
bash
bin/cassandra -f
这会以前台方式启动单节点集群。若要后台启动，去掉-f。 -
连接并执行 CQL
Cassandra 使用类 SQL 的查询语言（CQL）。打开另一个终端，运行：
bash
bin/cqlsh
进入交互后，执行以下操作（示例来自官方文档，路径：cassandra/doc/cql/）：
“`sql
CREATE KEYSPACE mykeyspace
WITH replication = {‘class’: ‘SimpleStrategy’, ‘replication_factor’: 1};
USE mykeyspace;
CREATE TABLE users (
user_id UUID PRIMARY KEY,
first_name text,
last_name text,
email text
);
INSERT INTO users (user_id, first_name, last_name, email)
VALUES (uuid(), ‘John’, ‘Doe’, ‘john.doe@example.com’);
SELECT * FROM users WHERE user_id = ?;
“`
注意：真实的 SELECT 中 ? 是位置占位符，但在 cqlsh 中可以使用具体的 UUID。生产环境部署需要设置 NetworkTopologyStrategy 和多副本因子。
- 使用 Docker（官方 README 亦推荐）
bash
docker run --name cassandra -d cassandra:latest
docker exec -it cassandra cqlsh
同样可以执行上述 CQL 语句。
与同类工具的差异
- vs MongoDB：MongoDB 的强项是文档模型的灵活性和内置聚合管道，但写入扩展性受限于主节点（即使分片集群也有协调节点瓶颈）。Cassandra 的写入性能随节点数量线性增长，且每个节点均可接收写入请求。但 Cassandra 不支持文档嵌套、数组、地理空间索引等 MongoDB 的原生功能。
- vs HBase：两者都是宽列存储，但 HBase 强依赖 HDFS 和 ZooKeeper，部署和维护更重。Cassandra 自身完成数据持久化和一致性，集群可直接运行在裸机或云实例上。
- vs ScyllaDB：ScyllaDB 是 C++ 重写的 Cassandra 兼容替代品，API 和协议完全兼容。ScyllaDB 在单核性能上更有优势，但 Cassandra 的生态更成熟（工具链、监控集成）。
必须注意的限制与代价
-
事务和一致性模型
Cassandra 支持轻量级事务（LWT，使用 Paxos 协议实现行级别的原子“检查并设置”），但不支持跨分区的事务。如果业务需要多行、多表之间强一致，Cassandra 不合适。 -
数据建模必须先于查询设计
因为 Cassandra 只能通过主键高效查询（分区键 + 可选的聚簇列），设计表时必须预先想好所有查询模式。临时增加按其他字段过滤的能力会很困难，通常需要建立物化视图（Materialized View）或逆表。 -
运维复杂度
– 扩容/缩容需要手动重新平衡数据（或使用 vnodes 自动分配）。
– 硬盘故障后修复依赖nodetool repair，长时间不修复会导致数据不一致。
– 垃圾回收（压缩）会占用大量 I/O，需要监控合理设置compaction策略。 -
许可证
Apache Cassandra 采用 Apache 2.0 许可证，可自由商用、修改，无后顾之忧。