【问题标题】:cassandra search a row by secondary index returns nullcassandra 按二级索引搜索一行返回 null
【发布时间】:2015-08-31 22:33:54
【问题描述】:

我已经创建了一个TABLE和索引如下

创建表 refresh_token ( user_id bigint, refresh_token 文本, access_token 文本, device_desc 文本, device_type 文本, expire_time 时间戳, org_id bigint, 主键 (user_id, refresh_token) ) 具有聚类顺序 (refresh_token ASC) 在 demodb.refresh_token (access_token) 上创建索引 i_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'; 用户 ID |刷新令牌 |访问令牌 | device_desc |设备类型 |过期时间 | org_id ---------+---------------------------------------- --------------------------+------------------------ --------------------------------------------+------ --------+--------------+--------------+- ------------- 405198 | E82B57D9D64BECDBD6B5602A72816BD19016323504F803116F66A32598E04298 | E82B57D9D64BECDB16D4F3F9F81AC0EF7AF2C4B460CB0F33C9CEFA5846BA7BE1 |空 |空 | 2016-06-07 14:09:52+0800 | 481036337156

但是当我通过二级索引查询时,它返回null。

 select * from refresh_token where access_token ='E82B57D9D64BECDB16D4F3F9F81AC0EF7AF2C4B460CB0F33C9CEFA5846BA7BE1';

 用户 ID |刷新令牌 |访问令牌 | device_desc |设备类型 |过期时间 | org_id
---------+---------------+--------------+--------- ----+-------------+-------------+--------

谢谢

【问题讨论】:

  • 当我重新插入它时。它是按次要搜索的。
  • 您使用 CL=QUORUM 还是 CL=ONE 进行查询?
  • 尝试重建您的索引:nodetool rebuild_index demodb refresh_token i_access_token.
  • @BryceAtNetwork23,是的,我已经重建了索引并修复了表,但它不起作用。
  • @shutty 是的,我使用 CL=QUORUM 或 CL=ONE 进行查询。

标签: cassandra secondary-indexes


【解决方案1】:

仅建议对基数较低的字段使用辅助索引。您的 access_token 字段看起来具有非常高的基数(甚至可能对所有百万行都是唯一的)。这是 Cassandra 中已知的反模式。

高基数字段适用于分区键之类的内容,因为它们会散列到已知位置。但是二级索引不是散列的,而是通过每个节点上的本地数据结构找到的。当索引很多不同的值时,这些本地数据结构变得繁琐且效率低下。我怀疑您在具有匹配 access_token 的节点在大海捞针之前遇到了内部超时。

如果您需要通过access_token查找数据,我建议创建第二个表,其中access_token是分区键,并使用它来查找相应的user_id和refresh_token。这样,您将使用 access_token 作为散列,并获得可靠且快速的查找。

【讨论】:

    猜你喜欢
    • 2014-11-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-10-01
    • 2013-07-25
    • 2016-06-29
    相关资源
    最近更新 更多