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的周期内(在上面的例子中,一天)会有一个写入热点
- 与查询范围相关的存储桶大小选择不当将需要查看所有存储桶,从而抵消任何收益。
- 对数据库的多次查询。桶越小,调用次数越多。
请告诉我是否有更好的解决方案
我知道这里有很多时间序列问题,但我的问题似乎不太适合给定的解决方案。我也是 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的周期内(在上面的例子中,一天)会有一个写入热点
- 与查询范围相关的存储桶大小选择不当将需要查看所有存储桶,从而抵消任何收益。
- 对数据库的多次查询。桶越小,调用次数越多。
请告诉我是否有更好的解决方案