Hi Rahul,
the table TTL is 24 months. Oldest data is 22 months, so no
expirations yet. Compacted partition maximum bytes: 17 GB - yeah, I
know that's not good, but we'll have to wait for the TTL to make it go
away. More recent partitions are kept under 100 MB by bucketing.
The data model:
CREATE TABLE keyspace.table (
group int,
status int,
bucket timestamp,
ts timeuuid,
source int,
...
PRIMARY KEY ((group, status, bucket), ts, source)
) WITH CLUSTERING ORDER BY (ts DESC, monitor ASC)
There are no INSERT statements with the same 'ts' and 'source'
clustering columns.
Regards,
Martin
On Thu, Jul 26, 2018 at 12:16 PM Rahul Singh
<rahul.xavier.si...@gmail.com> wrote:
>
> Few questions
>
>
> What is your maximumcompactedbytes across the cluster for this table ?
> What’s your TTL ?
> What does your data model look like as in what’s your PK?
>
> Rahul
> On Jul 25, 2018, 1:07 PM -0400, James Shaw <jxys...@gmail.com>, wrote:
>
> nodetool compactionstats --- see compacting which table
> nodetool cfstats keyspace_name.table_name --- check partition side,
> tombstones
>
> go the data file directories: look the data file size, timestamp, ---
> compaction will write to new temp file with _tmplink...,
>
> use sstablemetadata ... ---- look the largest or oldest one first
>
> of course, other factors may be, like disk space, etc
> also what are compaction_throughput_mb_per_sec in cassandra.yaml
>
> Hope it is helpful.
>
> Thanks,
>
> James
>
>
>
>
> On Wed, Jul 25, 2018 at 4:18 AM, Martin Mačura <m.mac...@gmail.com> wrote:
>>
>> Hi,
>> we have a table which is being compacted all the time, with no change in
>> size:
>>
>> Compaction History:
>> compacted_at bytes_in bytes_out rows_merged
>> 2018-07-25T05:26:48.101 57248063878 57248063878 {1:11655}
>>
>> 2018-07-25T01:09:47.346 57248063878 57248063878
>> {1:11655}
>> 2018-07-24T20:52:48.652
>> 57248063878 57248063878 {1:11655}
>>
>> 2018-07-24T16:36:01.828 57248063878 57248063878 {1:11655}
>>
>> 2018-07-24T12:11:00.026 57248063878 57248063878
>> {1:11655}
>> 2018-07-24T07:28:04.686
>> 57248063878 57248063878 {1:11655}
>>
>> 2018-07-24T02:47:15.290 57248063878 57248063878 {1:11655}
>>
>> 2018-07-23T22:06:17.410 57248137921 57248063878
>> {1:11655}
>>
>> We tried setting unchecked_tombstone_compaction to false, had no effect.
>>
>> The data is a time series, there will be only a handful of cell
>> tombstones present. The table has a TTL, but it'll be least a month
>> before it takes effect.
>>
>> Table properties:
>> AND compaction = {'class':
>> 'org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy',
>> 'compaction_window_size': '1', 'compaction_window_unit': 'DAYS',
>> 'max_threshold': '32', 'min_threshold': '4',
>> 'unchecked_tombstone_compaction': 'false'}
>> AND compression = {'chunk_length_in_kb': '64', 'class':
>> 'org.apache.cassandra.io.compress.LZ4Compressor'}
>> AND crc_check_chance = 1.0
>> AND dclocal_read_repair_chance = 0.0
>> AND default_time_to_live = 63072000
>> AND gc_grace_seconds = 10800
>> 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 = 'NONE';
>>
>> Thanks for any help
>>
>>
>> Martin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: user-h...@cassandra.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
For additional commands, e-mail: user-h...@cassandra.apache.org
