我需要在Cassandra中存储明智的客户数据。每次客户进行任何活动时,都会在表格中插入新行。这就是我使用SizeTieredCompactionStrategy
的原因。因此,与水平压缩策略相比,我拥有的SSTtable数量更少
现在,一旦我插入一些测试行并运行以下命令'bin/nodetool compact'
,以便数据从memtable写入SSTable。之后我做10-15读取请求。因为我启用了密钥缓存。它应该从缓存返回数据,第一个请求除外。但正如我在日志中看到的,我不知道是否从缓存中获取数据?谁能帮我这个?
此外,在删除键空间和列家庭之后。为什么我的data / saved_cache / commitlog文件夹的大小保持不变。它不应该减少吗?
Keyspace and ColumnFamily(Table) Definition :
CREATE KEYSPACE cw WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3 };
CREATE TABLE cw.usertracking (
Col1 text PRIMARY KEY,
Col2 timestamp,
Col3 text,
Col4 bigint,
Col5 timestamp,
Col6 bigint,
Col7 bigint,
Col8 bigint,
Col9 bigint
) WITH bloom_filter_fp_chance = 0.01
AND caching = '{"keys":"ALL", "rows_per_partition":"10"}'
AND comment = ''
AND compaction = {'min_threshold': '4', 'cold_reads_to_omit': '0.05', 'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32'}
AND compression = {'chunk_length_kb': '64', 'sstable_compression': 'org.apache.cassandra.io.compress.DeflateCompressor'}
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';
跟踪日志:
activity | timestamp | source | source_elapsed
--------------------------------------------------------------------------------------------------------+----------------------------+---------------+----------------
Execute CQL3 query | 2015-04-10 13:05:15.655000 | 192.168.1.200 | 0
Message received from /192.168.1.200 [Thread-7] | 2015-04-10 13:05:15.653000 | 192.168.1.202 | 23
Executing single-partition query on usertimespentpage [SharedPool-Worker-2] | 2015-04-10 13:05:15.653000 | 192.168.1.202 | 220
Acquiring sstable references [SharedPool-Worker-2] | 2015-04-10 13:05:15.653000 | 192.168.1.202 | 235
Merging memtable tombstones [SharedPool-Worker-2] | 2015-04-10 13:05:15.653000 | 192.168.1.202 | 259
Skipped 0/0 non-slice-intersecting sstables, included 0 due to tombstones [SharedPool-Worker-2] | 2015-04-10 13:05:15.654000 | 192.168.1.202 | 318
Merging data from memtables and 0 sstables [SharedPool-Worker-2] | 2015-04-10 13:05:15.654000 | 192.168.1.202 | 344
Read 1 live and 0 tombstoned cells [SharedPool-Worker-2] | 2015-04-10 13:05:15.654000 | 192.168.1.202 | 378
Enqueuing response to /192.168.1.200 [SharedPool-Worker-2] | 2015-04-10 13:05:15.654000 | 192.168.1.202 | 452
Sending message to /192.168.1.200 [WRITE-/192.168.1.200] | 2015-04-10 13:05:15.654000 | 192.168.1.202 | 575
Message received from /192.168.1.200 [Thread-7] | 2015-04-10 13:05:15.655000 | 192.168.1.201 | 11
Executing single-partition query on usertimespentpage [SharedPool-Worker-2] | 2015-04-10 13:05:15.655000 | 192.168.1.201 | 198
Parsing select * from userTimeSpentPage where cwc ='321KqwLrW2OY8IMT9aHJD3Bj27'; [SharedPool-Worker-1] | 2015-04-10 13:05:15.655000 | 192.168.1.200 | 45
Acquiring sstable references [SharedPool-Worker-2] | 2015-04-10 13:05:15.655000 | 192.168.1.201 | 207
Preparing statement [SharedPool-Worker-1] | 2015-04-10 13:05:15.655000 | 192.168.1.200 | 147
Merging memtable tombstones [SharedPool-Worker-2] | 2015-04-10 13:05:15.655000 | 192.168.1.201 | 227
Sending message to /192.168.1.201 [WRITE-/192.168.1.201] | 2015-04-10 13:05:15.655000 | 192.168.1.200 | 455
Skipped 0/0 non-slice-intersecting sstables, included 0 due to tombstones [SharedPool-Worker-2] | 2015-04-10 13:05:15.655000 | 192.168.1.201 | 280
Merging data from memtables and 0 sstables [SharedPool-Worker-2] | 2015-04-10 13:05:15.655000 | 192.168.1.201 | 285
Read 1 live and 0 tombstoned cells [SharedPool-Worker-2] | 2015-04-10 13:05:15.655001 | 192.168.1.201 | 322
Enqueuing response to /192.168.1.200 [SharedPool-Worker-2] | 2015-04-10 13:05:15.655001 | 192.168.1.201 | 423
Sending message to /192.168.1.200 [WRITE-/192.168.1.200] | 2015-04-10 13:05:15.655001 | 192.168.1.201 | 527
Sending message to /192.168.1.202 [WRITE-/192.168.1.202] | 2015-04-10 13:05:15.656000 | 192.168.1.200 | 1221
Message received from /192.168.1.201 [Thread-4] | 2015-04-10 13:05:15.657000 | 192.168.1.200 | 2094
Processing response from /192.168.1.201 [SharedPool-Worker-2] | 2015-04-10 13:05:15.657000 | 192.168.1.200 | 2134
Message received from /192.168.1.202 [Thread-5] | 2015-04-10 13:05:15.657000 | 192.168.1.200 | --
Processing response from /192.168.1.202 [SharedPool-Worker-1] | 2015-04-10 13:05:15.657000 | 192.168.1.200 | --
Request complete | 2015-04-10 13:05:15.657232 | 192.168.1.200 | 2232
答案 0 :(得分:2)
1)你对Cassandra的理解似乎相当轻松。试图确保所有数据总是以单个sstable结束是不合理的。压缩是会发生的事情,你应该理解它为什么会发生,但不要依赖它来整合你的数据以便更容易缓存 - 密钥缓存将缓存相关的密钥,这对于大多数用例来说已经足够了。如果您需要更低的延迟,请考虑在cassandra前面使用另一个缓存层,例如memcached。
2)你在没有真正触及sstable的情况下从memtable中提供请求 - 它在memtable中找到了一个单元格,并且它与任何sstable都没有调和细胞:
Skipped 0/0 non-slice-intersecting sstables, included 0 due to tombstones [SharedPool-Worker-2] | 2015-04-10 13:05:15.655000 | 192.168.1.201 | 280 Merging data from memtables and 0 sstables [SharedPool-Worker-2] | 2015-04-10 13:05:15.655000 | 192.168.1.201 | 285 Read 1 live and 0 tombstoned cells [SharedPool-Worker-2] | 2015-04-10 13:05:15.655001 | 192.168.1.201 | 322
3)commitlog不会缩小 - 它是在启动时重播的所有活动的日志。所有写入都存在,直到它被清除。
答案 1 :(得分:0)
我不知道您使用的是什么版本的Cassandra,但在2.1中您可以使用JMX,查看" Caches"的MBean。 " KeyCacheHits"的值和" KeyCacheSize"应告诉您有多少读取命中密钥缓存以及密钥缓存当前有多大。