Question

我正在研究将日志存储到Cassandra 日志的架构就是这样的。

编辑：我已经改变了架构以便做出一些澄清。

CREATE TABLE log_date (
  userid bigint,
  time timeuuid,
  reason text,
  item text,
  price int,
  count int,
  PRIMARY KEY ((userid), time) - #1
  PRIMARY KEY ((userid), time, reason, item, price, count) - #2
);

每天都会创建一个新表格。因此，一个表只包含一天的日志。

我的查询条件如下查询特定用户在特定日期（日期而非时间）的所有日志因此，原因，项目，价格，计数将不会被用作查询的提示或条件。

我的问题是哪种PRIMARY KEY设计更适合。
编辑：这里的关键是我想以原理图的方式存储日志。

如果我选择＃1，那么每个日志会创建很多列。并且每个日志具有更多值的可能性非常高。上面的架构只是一个例子。日志可以包含subreason，friendid等值。

如果我选择＃2，每个日志将创建一个（非常）复合列，到目前为止，我无法找到有关复合列开销的任何有价值的信息。

我应该选择哪一个？请帮忙。

Answer 1

我的建议是，你的两个选项似乎都不适合你的时间序列，你每天创建一个表格的事实，似乎也不是最优的。

相反，我建议按用户ID和日期创建一个表和分区，并使用时间uuids作为事件的聚集列，这样的示例如下所示：

CREATE TABLE log_per_day (
   userid bigint,
   date text, 
   time timeuuid, 
   value text,
      PRIMARY KEY ((userid, date), time)
)

这将允许您将一天中的所有事件放在一行中，并允许您按用户每天进行查询。

通过声明time群集列允许有一个宽行，您可以在一天内根据需要插入许多事件。

因此，行键是用户ID的composite key，加上文本中的日期，例如

insert into log_per_day (userid, date, time, value) values (1000,'2015-05-06',aTimeUUID1,'my value')

insert into log_per_day (userid, date, time, value) values (1000,'2015-05-06',aTimeUUID2,'my value2')

上面的两个插页将位于同一行，因此您可以在一个查询中阅读。

此外，如果您想了解有关时间序列的更多信息，我强烈建议您查看Getting Started with Time Series Data Modeling

希望它有所帮助，

JoséLuis

使用Cassandra获取时间序列数据

1 个答案: