卡桑德拉 - 一個大桌子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很多桌子

回答

相關問題