cassandra cql解析

摘要

CQL相比较于SQL有很多的限制,原因在于cassandra是为大数据存储设计的,而它的部署模式又都是基于分区方式的,不像mongo还有复制集这个小规模的数据库集群设计,当数据量大的时候再进行分片。为了提供检索效率,所以在CQL语法上做了限制,避免低效的查询语句。cassandra的数据是根据partition key做hash计算后分布到各个节点的,扫描各个节点的效率是很低的。所以cassandra query检索的一个基本原则就是尽可能的查找少的节点。

CQ L

概览

关系型数据库是行的集合,Cassandra是分区的集合,如果没有clustering key的话,每个分区就是单行,一个分区包含多行的话就叫做宽行(wide-row)。cassandra 根据partition key的hash value来决定数据存储在哪个节点,这个相当于是hash索引,所以不能进行范围查询。然后在每个分区根据clustering key来排序,
这个不是基于hash的,所以可以根据范围来查询。以下表为例,node为partition key,(date,number)是clustering key.

CREATE KEYSPACE test WITH REPLICATION = {
    'class': 'SimpleStrategy',
    'replication_factor': 1
};

CREATE TABLE log(
    node text,
    date text,
    name text,
    number int,
    Primary Key(node,date,number)
);

在关系型数据库中数据是这么存储的

node date number name
n1 feb 1 name1
n1 feb 2 name2
n2 feb 1 name3
n2 feb 2 name4

而在cassandra则是

partition1

{
    n1:feb {1:name:name1}} 
             {2:name:name2}}
}

partition2

{
    n2:feb {1:name:name3}} 
             {1:name:name4}}
}

其中1:name:name3这种结构
key为1:name,name3为value

cassandra 的列不固定,所以列名也要存。

范围查询

  • IN操作

    cassandra 2.2 以前IN只能用于partition key的最后一列,2.2之后改进了可以用于partition key的任意一列了。但是要注意IN操作的效率比较低,在摘要中已经说过了要尽可能的减少查询的节点,in操作会查询多个节点,如果设置了replicat factor为3的话,查询的节点数又会三倍增加。这样coordinate 节点的查询压力就会增加,需要保存各个节点的查询结果,就有可能会导致GC暂停,堆内存增加。

    cassandra 3.0之后的IN支持在clustering key的列,不过如果是单列,必须要指定之前clustering key的值。(=或者IN)

  • 范围查询>,<

    partition key

    Cassandra是基于partition key的hash分步数据的,所以不支持范围查询。
    允许在partition key的字段上面利用token函数来进行范围查询。

    SELECT * FROM log WHERE token(node) > token('1') 
    

    注:分区器ByteOrderedPartitioner是有序分布数据的,所以理论上应该可以支持范围查询,但是使用这种分区器容易导致数据分布的不平衡,所以一搬不推荐使用

    clustering key

    单列的话,范围查询只能用于最后一列。前面的列必须要给定

    SELECT *FROM log WHERE node = '1' AND date >='date1'
    
    SELECT *FROM log WHERE node = '1' AND date = 'date' AND number >=1
    

    无效的就是这种

    SELECT *FROM log where node = '1' AND number >= 1
    

总结

  1. partition key是基于hash,不支持大于,小于这种范围查询,IN操作的是支持的。

  2. clustering key是排序的,支持IN,大于小于查询。它相当于一个联合索引,所以要想让联合索引生效,得保证前面字段都有。

  3. 当没有给定partition key,而给定clustering key,需要扫描所有节点,然后进行过滤。所以执行效率可能比较低。所以Cassandra 要求使用ALLOW FILTERING。当过滤到的数据占查询的数据比例比较高的时候,还比较有效。

问题

  • 问题1:where 语法中支不支持or

    不支持,or 在SQL中一般是用来减少发到DB的请求。其中每个条件都构成了单个查询。Cassandra要求尽可能的减少请求节点,要求在每次查询时指定partition key,显然对于or这样多字段的条件,很难分析语境。

  • 问题2:cassandra支不支持模糊查询

    不支持LIKE操作,cassandra3.4以后可以使用,但是有很多限制。可以看下这篇文章介绍http://www.tsoft.se/wp/2016/08/12/sql-like-operation-in-cassandra-is-possible-in-v3-4/

  • 问题3: 一张表支持上千个字段吗

    支持,对字段的数目没有限制,只有对paritition的数目有20亿的限制。所以列越多的话,相应的能够存储的行数就少了。

参考

https://lostechies.com/ryansvihla/2014/09/22/cassandra-query-patterns-not-using-the-in-query-for-multiple-partitions/

https://wiki.apache.org/cassandra/CassandraLimitations

http://www.tsoft.se/wp/2016/08/12/sql-like-operation-in-cassandra-is-possible-in-v3-4/

https://github.com/xedin/sasi

http://opensourceconnections.com/blog/2013/07/24/understanding-how-cql3-maps-to-cassandras-internal-data-structure/

发布了164 篇原创文章 · 获赞 319 · 访问量 49万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: Age of Ai 设计师: meimeiellie

分享到微信朋友圈

×

扫一扫,手机浏览