卡桑德拉 - 一个大桌子vs很多桌子

我目前正在尝试Cassandra数据库。我正在使用DataStax开发人员中心和DataStax C＃驱动程序。卡桑德拉 - 一个大桌子vs很多桌子

我目前的模型非常简单，只包括：

参数标识（INT） - 将作为表的ID。
值（BIGINT）
MeasureTime（时间戳）

我将具有1000（不多也不少）参数，从1 - 1000而将越来越每个参数的条目一次PR 。第二，并将运行多年。

我的问题是关于是否有更好的做法是创建一个表：

CREATE TABLE keyspace.measurement (
    parameterId int, 
    value bigint, 
    measureTime timestamp, 
    PRIMARY KEY(parameterId, measureTime) 
) WITH CLUSTERING ORDER BY (measureTime DESC)

或者它会更好地创建1000个表格只包含的价值和measureTime，如果是这样我就可以在我的MeasureTime范围查询？

来源

2016-09-29 Larzix

你打算用这个打很宽的行。我会建议你的表格格式，我会去的东西，让你控制行的宽度。

根据您的查询要求，我给您写下来更合适的架构（恕我直言）：

CREATE TABLE keyspace.measurement (
    parameterId int, 
    granularity timestamp, 
    value bigint, 
    measureTime timestamp, 
    PRIMARY KEY((parameterId, granularity), measureTime) 
) WITH CLUSTERING ORDER BY (measureTime DESC)

这是你的差不多，但它有一个很大的优势：你可以配置wideness你的行，你没有任何热点。这个想法很简单：parameterId和granularity字段使分区键，所以他们告诉你的数据将去哪里，而measureTime将保持您的数据排序。假设你想每天查询，你可以在granularity中存储measureTime的值yyyy-mm-dd，将同一天的所有度量值组合在一起。

这允许您检索位于同一分区上的所有值（因此每个给定的parameterId和granularity字段对）使用有效范围查询。在日常配置中，每个分区最终会有86400条记录。这个数字可能仍然很高（建议的限制是10k IIRC），您可以通过逐个小时分组，使用yyyy-mm-dd HH:00值来降低该值。

该方法的缺点是，如果您需要来自多个分区的数据（例如，您正在逐日进行分组，但您需要连续两天的数据，例如1月19日的最后6个小时，以及1月20日的前6个小时），那么您需要执行多个查询。

来源

2016-09-29 13:22:58 xmas79

谢谢！这是一种魅力。我的阅读表现现在通过屋顶！额外的查询很容易以编程方式处理。 – Larzix

我们在这里有两种方法，每种都有自己的优点和缺点。

方法1：创建每个参数1个表（1000个表格只包含值和measureTime）

这种做法将是一件好事，如果我们只参数的数量有限，在不久的将来，如果我们需要容纳更多参数，那么为每个参数创建一个表将变得麻烦。通过将表放在不同的分片中可以使性能更好。

方法2：创建一个大表

的NoSql DB的是专为更高数量的记录更好的性能。即使有十亿条记录也会带来良好的表现。

考虑到这一点"will be getting an entry for each parameter once pr. second and will be running for years."，我觉得方法1最适合您的情况，前提是将来不会增加参数的数量。

来源

2016-09-29 12:59:46

虽然你的答案对于一般nosql dbs来说是一个很好的答案，但问题是cassandra特有的。 1000个表不利于cassandra（每个表的内存开销），你应该尽量保持在“数百”而不是“数千”。你不需要/没有cassandra分片。 –

@ChrisLohfink - 谢谢Chris –

卡桑德拉 - 一个大桌子vs很多桌子

回答

相关问题