apache/cassandra

Apache Cassandra 是一个开源分布式数据库：应用通过 CQL（一种与 SQL 相近的查询语言）访问数据，而数据会被分区并分散到多台机器上，应用无需自行路由行。它适合这样的团队：数据集较宽、写入压力较大，需要跨普通硬件或云主机横向扩展，并且可以接受行存储模型而不是完整的关系型查询能力。

它做什么、怎么工作

数据按表组织，每张表必须有主键。分区（Partitioning）把行分布到多台机器上，这一过程对应用透明；集群在增加或移除机器时会自动重新分区 Partitioning。存储模型是行存储，按行和列组织数据；查询语言 CQL 与 SQL 关系密切 Data model。

CQL 的文档化范围有意比 SQL 窄：README 把它概括为“SQL 减去 join 和子查询，加上集合类型” README。这是规划时最有用的一条事实：表结构和查询设计必须围绕分区与访问模式来做，而不能依赖随意的 join。

一个基本流程

官方快速上手路径是一个单节点本地集群：解压发行包，用前台模式启动服务端（日志输出到标准输出），再打开交互式 CQL 客户端 bin/cqlsh。在其中创建带复制策略与复制因子的 keyspace，定义带主键的表，插入一行并查询回来。当提示符显示已连接到集群、且查询返回了刚插入的那一行，就说明该节点已可用 README。超出本地单机的部分见项目的 Getting Started Guide，完整语言参考见 CQL 文档。

要求与实际限制

• Java：运行服务端需要 Java；支持的 Java 版本写在 build.xml 的 java.supported 属性中，应对照该属性检查自己的 JDK，而不是假设 README 固定了某个版本 README。
• Python：cqlsh 需要 Python，具体支持范围定义在 bin/cqlsh 内部 README。也就是说服务端和命令行客户端有各自独立的版本检查。
• 许可：Apache-2.0，按其条款允许使用和修改 LICENSE。
• README 没有记录集群规模、故障恢复流程、升级与回滚等运维限制；这些内容属于项目文档和问题跟踪器 项目主页、Jira。

适合的场景

如果负载可以按分区键来设计和查询，横向扩展与在普通机器或云基础设施上容错是重要目标，并且团队愿意围绕 CQL 收窄的查询能力来设计，那么 Cassandra 是合理的选择。如果应用依赖 join、子查询或单机关系型引擎，这属于不匹配，而不是配置问题。

HotRepo 点评

可用的趋势信号很少且有明确日期范围：仓库在 2026-07-27 和 2026-07-28 两次出现在日榜（最后记录为 10,025 stars），并在 2026-10-26 的 Java 周榜上位列第 13 仓库。这样的样本不足以描述趋势，只能当作孤立观察。