Cassandra

卡桑德拉改變

  • June 1, 2017

我將 cassandra 表定義為:

CREATE TABLE db.table (
   value text,
   time timestamp,
   sid text,
   PRIMARY KEY (sid, time)
) WITH CLUSTERING ORDER BY (time ASC)
   AND bloom_filter_fp_chance = 0.01
   AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
   AND comment = ''
   AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
   AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
   AND dclocal_read_repair_chance = 0.1
   AND default_time_to_live = 0
   AND gc_grace_seconds = 864000
   AND max_index_interval = 2048
   AND memtable_flush_period_in_ms = 0
   AND min_index_interval = 128
   AND read_repair_chance = 0.0
   AND speculative_retry = '99.0PERCENTILE';

表很大,這裡是數據文件:

root@server:/home# ls -l /var/lib/cassandra/data/db/table/*-Data.db -h
-rw-r--r-- 1 cassandra cassandra 8.7G Aug 16 00:14 /var/lib/cassandra/data/db/table/db-table-ka-200785-Data.db
-rw-r--r-- 1 cassandra cassandra 2.2G Nov  5 21:28 /var/lib/cassandra/data/db/table/db-table-ka-208079-Data.db
-rw-r--r-- 1 cassandra cassandra  20G Nov 20 20:55 /var/lib/cassandra/data/db/table/db-table-ka-208702-Data.db
-rw-r--r-- 1 cassandra cassandra  18G Dec 17 17:31 /var/lib/cassandra/data/db/table/db-table-ka-210089-Data.db
-rw-r--r-- 1 cassandra cassandra 455M Dec 18 14:15 /var/lib/cassandra/data/db/table/db-table-ka-210153-Data.db
-rw-r--r-- 1 cassandra cassandra 4.4G Dec 27 09:27 /var/lib/cassandra/data/db/table/db-table-ka-210477-Data.db
-rw-r--r-- 1 cassandra cassandra 3.9G Jan  7 14:50 /var/lib/cassandra/data/db/table/db-table-ka-210834-Data.db
-rw-r--r-- 1 cassandra cassandra 4.1G Jan 16 04:47 /var/lib/cassandra/data/db/table/db-table-ka-211203-Data.db
-rw-r--r-- 1 cassandra cassandra 997M Jan 19 08:56 /var/lib/cassandra/data/db/table/db-table-ka-211292-Data.db
-rw-r--r-- 1 cassandra cassandra 1.1G Jan 20 23:24 /var/lib/cassandra/data/db/table/db-table-ka-211389-Data.db
-rw-r--r-- 1 cassandra cassandra 1.1G Jan 22 00:03 /var/lib/cassandra/data/db/table/db-table-ka-211479-Data.db
-rw-r--r-- 1 cassandra cassandra 285M Jan 22 11:33 /var/lib/cassandra/data/db/table/db-table-ka-211495-Data.db
-rw-r--r-- 1 cassandra cassandra  51M Jan 22 12:16 /var/lib/cassandra/data/db/table/db-table-ka-211500-Data.db
-rw-r--r-- 1 cassandra cassandra  16M Jan 22 12:31 /var/lib/cassandra/data/db/table/db-table-ka-211501-Data.db
-rw-r--r-- 1 cassandra cassandra  16M Jan 22 12:46 /var/lib/cassandra/data/db/table/db-table-ka-211502-Data.db

表是使用者將一些指標儲存為時間序列。插入的每一行都設置為一個月的 TTL。

  1. 我在這裡註意到的第一件事是存在比 TTL 更早的 sstable,可能是因為時間序列數據的壓縮策略不是最優的。現在更改表並將壓縮策略更改為 DTCS 是否安全?對於 1 個月的 TTL,哪些壓縮子屬性應該是最好的?
  2. 由於所有數據都使用相同的 TTL 插入,我想最好在 table 上設置預設 TTL。根據 Datastax:

表上的預設 TTL 是另一種自然適合時間序列數據的方式。它允許您避免僅出於刪除墓碑和/或 TTLed 單元的目的而執行的代價高昂的壓縮。實際上,它允許壓縮邏輯更加高效,只需在最新的單元格時間戳足夠舊以指示所有 sstable 都已超過其保質期時刪除 sstable。這些數據在寫入時保存在表元數據中,便於檢查。當預設 TTL 與時間序列工作負載結合使用時,您可以進一步減少與數據密度相關的壓縮負載。當與 DTCS 結合使用時,您幾乎可以消除與系統壓實側的高密度相關的幾何載荷。

現在這樣做安全嗎? 3. 分群順序的方向不是獲得最後一個值的最佳選擇。

select * from table where sid='XXX' limit 1

給出第一個條目,而不是最後一個。此時是否可以將分群順序更改為 DESC?

您不能,因為這需要以不同的順序重寫磁碟上的所有數據,同時在執行時訴諸直到重寫完成,這將對性能造成不可接受的影響。您需要創建一個新表並將其批量載入。

引用自:https://dba.stackexchange.com/questions/161881