Cassandra——分布式KV数据库

更新: 4/21/2025 字数: 0 字 时长: 0 分钟

简介

Cassandra是Apache基金会维护的一个分布式KV数据库，其优点在于可以高效的写入读出

那么我们为什么要使用它呢？

总所周知，MySQL在长文本的存储方面存在一定的性能瓶颈，在InnoDB中，数据以行的形式存储，一行，而行又存储在页中，一页16kb，当文本很长时，InnoDB会将内容存储在溢出页中，然后留下一个指针指向溢出页，这样就导致了更多的I/O操作

那么16kb有多大呢？

我的博客里面有篇4800+字符的文章，是14kb 寄

因此如果你的软件有大量的长文本需求（博客/论坛/IM的聊天记录），那么将文本存储在MySQL中就不是一个很好的选择了

其他方案

1. Redis Redis的高效是有目共睹的，但是Redis运行时存储的内容在内存上，这不大适合我们去持久化所有的长文本数据
2. MongoDB 不评价，不使用 听我说，谢谢你，因为有你......(尬黑了，不过个人认为MogoDB不是很适合作为后端数据库)
3. Cassandra Cassandra的天生分布式，高性能读写的功能正是我们需要，且其CQL语句与SQL语句较为相像，学习成本较低

Cassandra

数据模型

Cassandra的整体存储结构与关系型数据库相似（虽然只是长得像），这就很方便我们理解

键空间： 类似MySQL中的一个数据库，一个键空间内可以有多个表

表： 类似MySQL的表

列： Cassandra的基本数据单元，与MySQL的列类似

对于列还有一个静态列的特殊情况，这个我们先按下不表

主键： 列的唯一标识，可以由一个或多个列组成，一个主键由分区键和集群列（主键中除了分区键以外的部分，当主键全是分区键时不存在）

分区键： 由于Cassandra的天生分布式设计，因此必须要考虑数据如何分布在不同的节点上，一般会使用分区键的Hash值来决定，分区键是主键的第一部分

PRIMARY KEY((key_part_one,key_part_two), key_clust_one, key_clust_two, key_clust_three)

上面代码中的(key_part_one,key_part_two)就是分区键（没有小括号则认为是主键的第一个列为分区键）

静态列： 一种固定的列，认为一个分区键下的数据的静态列全部为同一个值，比如存在一个键空间中含有商品名和种类两个列，那么名字和种类是唯一且确定的，那么商品名就可以做分区键，种类就可以作为静态列（有点类似MySQL里的联合唯一索引）

索引： 用于查询的数据结构，（键是特殊的索引）

查询

由于分布式情景的性能问题，Cassandra的更加希望我们使用索引（甚至是只用分区键）去查询数据，因此我们在定义表结构的时候应该先考虑好查询的情景

要求：

• 分区键只支持 = 或 in 来查询
• 集群列支持范围与比较查询，但where若对集群列进行查询需要加上ALLOW FILTERING（提示你性能会受损）
• 索引列只支持 = 查询
• 其他情况查询须加上ALLOW FILTERING

支持的操作：

• order by : 要使用分区键查询后才可以使用（因为数据存在一个分区上），order by 只能针对集群列进行排序
• like : 新型索引支持like的模糊查询
• group by : 支持针对主键的group by
• limit : 支持分页查询

Java 操作 Cassandra

SpringBoot为我们提供了Spring Data For Apache Cassandra包，让我们可以使用SpringData的形式去在Java中操作Cassandra