你这样会引起很大的轰动。我建议不要使用表格格式，我会使用允许您控制行宽度的格式。
根据您的查询需求，我将为您写下一个更合适的模式（恕我直言）：

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

这和你的很相似，但它有一个很大的优势：你可以配置你的行的宽度，你没有任何热点。这个想法非常简单：parameterId和granularity字段都是 * 分区键 *，因此它们告诉您的数据将去往何处，而measureTime将使您的数据保持有序。假设您希望按天查询，您可以将measureTime的值yyyy-mm-dd存储到granularity中，将同一天的所有度量值组合在一起。
这允许您使用高效的范围查询来检索位于同一分区上的所有值（因此对于给定的parameterId和granularity字段对）。在一天一天的配置中，每个分区最终将有86400条记录。这个数字可能仍然很高（建议的限制是10k IIRC），您可以通过使用yyyy-mm-dd HH:00值逐小时分组来降低这个值。
这种方法的缺点是，如果您需要来自多个分区的数据（例如，您正在按天分组，但您需要连续两天的数据，例如1月19日的最后6小时和1月20日的前6小时），那么您需要执行多个查询。

我们这里有两种方法，每种方法都有自己的优点和缺点。
方法1：为每个参数创建1个表（1000个表仅由一个值和measureTime组成）
如果我们只有有限数量的参数，这种方法将是很好的，在不久的将来，如果我们需要容纳更多的参数，那么为每个参数创建一个表将变得很麻烦。通过将表放在不同的分片上可以提高性能。
方法2：创建一个大表
NoSql数据库的设计是为了更好的性能，更高的记录数。即使有十亿条记录也会给予很好的性能。
考虑到这一点"will be getting an entry for each parameter once pr. second and will be running for years."，我觉得方法1最适合您的场景，前提是将来参数的数量不会增加。