Question

我有这种结构，我希望用户看到其他用户的Feed。一种方法是向所有感兴趣的各方提供动作。

这将导致查询，例如选择来自其中userid =

的供稿

否则我可以避免写这么多数据，因为我已经做了我可以做的阅读：

从用户ID IN（朋友列表）中选择。

第二个慢吗？我还没有使用大量数据/集群来测试这个应用程序。由于应用程序是大型编写代码来测试单个节点是不值得的，所以我要求你的知识。

Answer 1

如果您的标题正确，并且userid是辅助索引，那么甚至无法运行SELECT/WHERE/IN。 WHERE/IN子句仅适用于主键值。当您在具有二级索引的列上使用它时，您将看到如下内容：

Bad Request: IN predicates on non-primary-key columns (columnName) is not yet supported

此外，DataStax CQL3 documentation for SELECT有一节值得阅读有关使用IN的内容：

何时不使用IN

关于何时不使用索引的建议适用于使用IN   在WHERE子句中。在大多数情况下，在WHERE中使用IN   不推荐使用条款。使用IN会降低性能，因为   通常必须查询许多节点。例如，在单个，本地   数据中心集群有30个节点，复制因子为3，a   LOCAL_QUORUM的一致性级别，单个密钥查询为2   节点，但如果查询使用IN条件，则节点数   被查询的可能性甚至更高，最多20个节点取决于   密钥落在令牌范围内。

至于您的第一个查询，如果不知道Feed表中userid的基数，就很难推测性能。如果userid是唯一的或具有非常多的可能值，则该查询将无法正常运行。另一方面，如果每个userid可以有多个“提要”，那么它可能会正常。

请记住，Cassandra数据建模是关于为预期查询构建数据结构。有时，如果对同一数据有3个不同的查询，最好的计划可能是将相同的冗余数据存储在3个不同的表中。那没关系。

我会通过编写一个面向该特定查询的表来解决这个问题。根据你提到的内容，我会像这样构建它：

CREATE TABLE feedsByUserId
    userid UUID,
    feedid UUID,
    action text,
    PRIMARY KEY (userid, feedid));

如果使用userid作为partitioning key组成的复合主键，您就可以运行上面提到的SELECT/WHERE/IN查询，并获得预期的结果。当然，我假设添加feedid将使整个密钥唯一。如果不是这种情况，那么您可能需要向PRIMARY KEY添加其他字段。我的示例还假设userid和feedid是版本4 UUID。如果不是这种情况，请相应调整其类型。

读取的一个辅助索引比读取多个cassandra的读取速度快吗？

1 个答案: