【云审计服务】技术科普: Cassandra数据库介绍之入门篇
近几年NoSQL非常火爆,其中Facebook的开源项目Cassandra扮演者重要角色。如果想要一个大容量、高可用、高扩展的海量存储方案,首先应该想到的就是Cassandra。云审计服务需要去实时记录租户的海量操作日志,因此在技术选型时,Cassandra首当其冲。本文主要简单介绍Cassandra数据库的特点以及在运维过程中积累的一些经验,权当抛砖引玉,还希望高手在留言中批评指正
Cassandra简单数据模型
在Cassandra中,每一行数据都是以Key/Value形式存储,其中Row Key(类似于SQL数据库中的主键)是唯一标示。Key/Value中的Value又称为Column(类似于SQL数据库中的列)。整个Key/Value的数据模型称为Column Family(类似于SQL数据库中的表),Cassandra通过Key Space(类似于SQL数据库中的database)去管理多个Column Family。上述为一个标准的Column Family,Cassandra还提供一种更加复杂的数据模型Super Column Family,相当于Value中又包含一个Key/Value的结构,这里就不再赘述。
Cassandra中的Key
在Cassandra中,Primary Key是由Partition Key + [Clustering Key]组成的,当然也会有不同的表现形式。其中PartitionKey决定了数据存储在哪些Partition中,Clustering Key决定了数据在该Partition中的排序。
1. 使用类似于SQL数据库中最基本的形式
这种形式下key作为唯一主键。
2. 使用Partition Key + Clustering Key的形式
这种形式下,Primary Key由key1,key2组成,其中key1作为Partition Key,key2作为Clustering Key。
3. 使用组合形式
这种形式下,Partition Key由key,key2组成,因此他们一起决定了数据存储的Partition,key3作为Clustering Key。
了解Key的组成,将对于我们建立数据模型有很大的帮助。我们需要将数据平均存储到各个Partition中(理想状态下),这样对于数据库的性能及可靠性都有着莫大的帮助,因此选择合理的字段作为Partition Key就至关重要,必要时也需要使用组合形式来保证Partition Key的随机性。而Clustering Key作为Partition内数据排序的依据,因此对数据有顺序存储要求时要充分利用该字段来提高效率,例如在存储时将新数据放在最前面,在查询时指定时间段和Limit可有效避免查询到过量墓碑数据而导致查询超时。
Cassandra中CQL语句及二级索引
上面提到建立适当的数据模型会很有效的提升系统性能,最直接的体现就是在CQL语句中。CQL语法与关系型数据库基本类似,这里不再赘述,主要讲解一些Key以及二级索引对于CQL语句的影响。
首先我们来创建一个Column Family,可以看到语法与SQL基本一致
其中key1为Partition Key,key2为Clustering Key
1. 查询时必须要带Partition Key,不能只根据Clustering Key查询,除非使用Allow Filtering
这个Allow Filtering到底是何方神圣呢?官方给出的解释是Cassandra需要获取到所有数据然后根据key2过滤出真正需要的数据。因此,如果90%的数据都符合key2 < 11111的条件,影响不大,若有很低的命中率,则可能会出现查询超时的情况,所以不要为了一时省心而随意使用Allow Filtering,带来的后果是不可想象的。
2. 更新时必须带上所有的Primary Key且Primary Key不能被更新
3. 不支持多表关联子查询
4. 不支持根据二级索引删除
5. CQL默认显示10万条数据,若想查看更多需增加limit值。但数据量过大时,会导致超时,因此要慎用。
本文只简单的介绍了几个Cassandra相关的基础知识点,后面还会写更多关于Cassandra的文章,例如Cassandra运维相关、Cassandra读写实现原理、Cassandra双DC的构建、Cassandra内存占用分析与调优等,我们不见不散。
- 点赞
- 收藏
- 关注作者
评论(0)