Cassandra 时间序列:允许过滤、桶或其他

Cassandra Time-Series: Allow Filtering, Buckets, or Other

我知道这里有很多时间序列问题,但我的问题似乎不太适合给定的解决方案。我也是 Cassandra 的新手,所以我可能会以错误的心态来处理这个问题。忍耐一下。

我收到以下格式的搜索数据:

datetime_searched, term_used, product_found

以及我想进行的查询:

Given a start-date and an end-date, return all term-product pairs that fall in that time window. Initially, the window will be a month long. This may (read: will) change.

例如,给定以下数据:

2013-11-20 00:00:00, "christmas", "decorated tree"
2014-12-01 20:00:00, "christmas", "wrapping paper"
2014-12-23 15:00:00, "christmas", "decorated tree" (duplicate term-product)

和时间范围 2014-12-01 到 2015-01-01 的查询,我希望能够检索:

"christmas", "wrapping paper"
"christmas", "decorated tree"

我最初的方法看起来像大多数时间序列数据的例子:

CREATE TABLE search_terms (
  datetime_searched timestamp,
  term_used text,
  product_found text,
  PRIMARY KEY (term_used, date_searched)
);

SELECT term_used, product_found
FROM search_terms 
WHERE datetime_searched > [start] 
AND datetime_searched < [end];

但这需要我有二级索引 and/or 允许过滤,如果我只捕获一小部分被过滤的数据,这似乎是我应该避免的事情。

我的第二个想法是创建时间段,但这个解决方案似乎只有在我将查询限制在时间段内时才有效。它似乎也产生了热点——在我最初的例子中,一个长达一个月的热点。例如,对于每日存储桶:

CREATE TABLE search_terms_by_day (
  datetime_searched timestamp,
  day_searched timestamp,
  term_used text,
  product_found text,
  PRIMARY KEY (day_searched)
);

SELECT term_used, product_found
FROM search_terms_by_day
WHERE day_searched=[my limited query's bucket];

那么我有什么选择呢?我是否将我的请求限制在桶大小,可能会创建许多具有不同桶大小的 CF,同时创建热点?我是否被迫使用二级索引?或者还有其他我不知道的选项吗?

提前致谢。

写这个问题帮助我解决了一些问题。我想出了一个替代解决方案,我或多或少对此感到满意,但需要进行一些微调。

有可能计算我们需要访问的所有时间桶,使用过滤器对每个时间桶进行查询以获取我们需要的条目。

CREATE TABLE search_terms_by_day_of_year (
  day_searched int, // 1 - 366
  datetime_searched timestamp,
  term_used text,
  product_found text,
  PRIMARY KEY (day_searched, datetime_searched, term_used, product_found)
);

// Make N of these, with a different day_searched
SELECT term_used, product_found
FROM search_terms_by_week
WHERE day_searched = 51
AND datetime_searched > [start]
AND datetime_searched < [end]

正面:

  • 避免扫描所有搜索数据
  • 允许更小的时间段,从而减少我们的热点

否定:

  • 需要逻辑来确定所需的分区键
  • 在bucket的周期内(在上面的例子中,一天)会有一个写入热点
  • 与查询范围相关的存储桶大小选择不当将需要查看所有存储桶,从而抵消任何收益。
  • 对数据库的多次查询。桶越小,调用次数越多。

请告诉我是否有更好的解决方案