我创建了一个TABLE和索引如下
CREATE TABLE refresh_token (
user_id bigint,
refresh_token text,
access_token text,
device_desc text,
device_type text,
expire_time timestamp,
org_id bigint,
PRIMARY KEY (user_id, refresh_token)
) WITH CLUSTERING ORDER BY (refresh_token ASC)
CREATE INDEX i_access_token ON demodb.refresh_token (access_token);
我插入或删除数百万次后的数据 . 我发现当我用户后跟查询无法返回任何数据 . 实际上,数据中有这一行 .
当我通过PRIMARY KEY查询时
select * from refresh_token where user_id=405198 and refresh_token='E82B57D9D64BECDBD6B5602A72816BD19016323504F803116F66A32598E04298';
它返回数据:
select * from refresh_token where user_id=405198 and refresh_token='E82B57D9D64BECDBD6B5602A72816BD19016323504F803116F66A32598E04298';
user_id | refresh_token | access_token | device_desc | device_type | expire_time | org_id
---------+------------------------------------------------------------------+------------------------------------------------------------------+-------------+-------------+--------------------------+--------------
405198 | E82B57D9D64BECDBD6B5602A72816BD19016323504F803116F66A32598E04298 | E82B57D9D64BECDB16D4F3F9F81AC0EF7AF2C4B460CB0F33C9CEFA5846BA7BE1 | null | null | 2016-06-07 14:09:52+0800 | 481036337156
但是当我通过二级索引查询时,它返回null .
select * from refresh_token where access_token ='E82B57D9D64BECDB16D4F3F9F81AC0EF7AF2C4B460CB0F33C9CEFA5846BA7BE1';
user_id | refresh_token | access_token | device_desc | device_type | expire_time | org_id
---------+---------------+--------------+-------------+-------------+-------------+--------
谢谢
1 回答
仅为具有低基数的字段建议二级索引 . 您的access_token字段看起来具有非常高的基数(甚至可能对于所有百万行都是唯一的) . 这是Cassandra中已知的反模式 .
高基数字段适用于分区键之类的东西,因为它们将散列到已知位置 . 但是二级索引不是散列的,而是通过每个节点上的本地数据结构找到的 . 当有许多不同的值被索引时,这些本地数据结构变得麻烦且低效 . 我怀疑你在具有匹配的access_token的节点在大海捞针中找到针之前,正在进行内部超时 .
如果你需要通过access_token查找数据,我建议创建第二个表,其中access_token是分区键,并使用它来查找相应的user_id和refresh_token . 这样,您将使用access_token作为哈希,并将获得可靠和快速的查找 .