I see, thanks Jason!
Can a dev confirm it is safe to apply those changes on live data? Also, if
I understood correctly, those parameters still obey the gc_grace_seconds,
that is, no compaction to evict tombstones will take place before
gc_grace_seconds elapsed, correct?
Cheers,
Stefano
On Tue, May 26, 2015 at 5:17 AM, Jason Wee <peich...@gmail.com> wrote:
> Hi Stefano,
>
> I did a quick test, it looks almost instant if you do alter but remember,
> in my test machine, there are no loaded data yet and switching from stcs to
> lcs.
>
> cqlsh:jw_schema1> CREATE TABLE DogTypes ( block_id uuid, species text,
> alias text, population varint, PRIMARY KEY (block_id) ) WITH caching =
> 'keys_only' and COMPACTION = {'class': 'SizeTieredCompactionStrategy'};
> cqlsh:jw_schema1> desc table dogtypes;
>
> CREATE TABLE jw_schema1.dogtypes (
> block_id uuid PRIMARY KEY,
> alias text,
> population varint,
> species text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'min_threshold': '4', 'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32'}
> 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';
>
> cqlsh:jw_schema1> ALTER TABLE dogtypes WITH COMPACTION = {'class':
> 'LeveledCompactionStrategy', 'tombstone_threshold': '0.3',
> 'unchecked_tombstone_compaction': 'true'} ;
> cqlsh:jw_schema1>
>
>
>
>
> ---------------------------------
>
>
> INFO [MigrationStage:1] 2015-05-26 12:12:25,867
> ColumnFamilyStore.java:882 - Enqueuing flush of schema_keyspaces: 436 (0%)
> on-heap, 0 (0%) off-heap
> INFO [MemtableFlushWriter:146] 2015-05-26 12:12:25,869 Memtable.java:339
> - Writing Memtable-schema_keyspaces@6829883(138 serialized bytes, 3 ops,
> 0%/0% of on/off-heap limit)
> INFO [MemtableFlushWriter:146] 2015-05-26 12:12:26,173 Memtable.java:378
> - Completed flushing
> /var/lib/cassandra/data/system/schema_keyspaces-b0f2235744583cdb9631c43e59ce3676/system-schema_keyspaces-ka-8-Data.db
> (163 bytes) for commitlog position ReplayPosition(segmentId=1432265013436,
> position=423408)
> INFO [CompactionExecutor:191] 2015-05-26 12:12:26,174
> CompactionTask.java:140 - Compacting
> [SSTableReader(path='/var/lib/cassandra/data/system/schema_keyspaces-b0f2235744583cdb9631c43e59ce3676/system-schema_keyspaces-ka-6-Data.db'),
> SSTableReader(path='/var/lib/cassandra/data/system/schema_keyspaces-b0f2235744583cdb9631c43e59ce3676/system-schema_keyspaces-ka-5-Data.db'),
> SSTableReader(path='/var/lib/cassandra/data/system/schema_keyspaces-b0f2235744583cdb9631c43e59ce3676/system-schema_keyspaces-ka-8-Data.db'),
> SSTableReader(path='/var/lib/cassandra/data/system/schema_keyspaces-b0f2235744583cdb9631c43e59ce3676/system-schema_keyspaces-ka-7-Data.db')]
> INFO [MigrationStage:1] 2015-05-26 12:12:26,176
> ColumnFamilyStore.java:882 - Enqueuing flush of schema_columnfamilies: 5307
> (0%) on-heap, 0 (0%) off-heap
> INFO [MemtableFlushWriter:147] 2015-05-26 12:12:26,178 Memtable.java:339
> - Writing Memtable-schema_columnfamilies@32790230(1380 serialized bytes,
> 27 ops, 0%/0% of on/off-heap limit)
> INFO [MemtableFlushWriter:147] 2015-05-26 12:12:26,550 Memtable.java:378
> - Completed flushing
> /var/lib/cassandra/data/system/schema_columnfamilies-45f5b36024bc3f83a3631034ea4fa697/system-schema_columnfamilies-ka-7-Data.db
> (922 bytes) for commitlog position ReplayPosition(segmentId=1432265013436,
> position=423408)
> INFO [MigrationStage:1] 2015-05-26 12:12:26,598
> ColumnFamilyStore.java:882 - Enqueuing flush of dogtypes: 0 (0%) on-heap, 0
> (0%) off-heap
> INFO [CompactionExecutor:191] 2015-05-26 12:12:26,668
> CompactionTask.java:270 - Compacted 4 sstables to
> [/var/lib/cassandra/data/system/schema_keyspaces-b0f2235744583cdb9631c43e59ce3676/system-schema_keyspaces-ka-9,].
> 751 bytes to 262 (~34% of original) in 492ms = 0.000508MB/s. 6 total
> partitions merged to 3. Partition merge counts were {1:2, 4:1, }
>
>
> hth
>
> jason
>
> On Tue, May 26, 2015 at 6:24 AM, Stefano Ortolani <ostef...@gmail.com>
> wrote:
>
>> Ok, I am reading a bit more about compaction subproperties here (
>> http://docs.datastax.com/en/cql/3.1/cql/cql_reference/compactSubprop.html)
>> and it seems that tombstone_threshold and unchecked_tombstone_compaction
>> might come handy.
>>
>> Does anybody know if changing any of these values (via ALTER) is possible
>> without downtime, and how fast those values are picked up?
>>
>> Cheers,
>> Stefano
>>
>>
>> On Mon, May 25, 2015 at 1:32 PM, Stefano Ortolani <ostef...@gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> Thanks for your answers! Yes, I agree that a delete intensive workload
>>> is not something Cassandra is designed for.
>>>
>>> Unfortunately this is to cope with some unexpected data transformations
>>> that I hope are a temporary thing.
>>>
>>> We chose LCS strategy because of really wide rows which were spanning
>>> several SStables with other compaction strategies (and hence leading to
>>> high latency read queries).
>>>
>>> I was honestly thinking of scraping and rebuilding the SStable from
>>> scratch if this workload is confirmed to be temporary. Knowing the answer
>>> to my question above would help second guess my a decision a bit less :)
>>>
>>> Cheers,
>>> Stefano
>>>
>>> On Mon, May 25, 2015 at 9:52 AM, Jason Wee <peich...@gmail.com> wrote:
>>>
>>>> ...., due to a really intensive delete workloads, the SSTable is
>>>> promoted to t......
>>>>
>>>> Is cassandra design for *delete* workloads? doubt so. Perhaps looking
>>>> at some other alternative like ttl?
>>>>
>>>> jason
>>>>
>>>> On Mon, May 25, 2015 at 10:12 AM, Manoj Khangaonkar <
>>>> khangaon...@gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> For a delete intensive workload ( translate to write intensive), is
>>>>> there any reason to use leveled compaction ? The recommendation seems to
>>>>> be
>>>>> that leveled compaction is suited for read intensive workloads.
>>>>>
>>>>> Depending on your use case, you might better of with data tiered or
>>>>> size tiered strategy.
>>>>>
>>>>> regards
>>>>>
>>>>> regards
>>>>>
>>>>> On Sun, May 24, 2015 at 10:50 AM, Stefano Ortolani <ostef...@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I have a question re leveled compaction strategy that has been
>>>>>> bugging me quite a lot lately. Based on what I understood, a compaction
>>>>>> takes place when the SSTable gets to a specific size (10 times the size
>>>>>> of
>>>>>> its previous generation). My question is about an edge case where, due
>>>>>> to a
>>>>>> really intensive delete workloads, the SSTable is promoted to the next
>>>>>> level (say L1) and its size, because of the many evicted tombstones, fall
>>>>>> back to 1/10 of its size (hence to a size compatible to the previous
>>>>>> generation, L0).
>>>>>>
>>>>>> What happens in this case? If the next major compaction is set to
>>>>>> happen when the SSTable is promoted to L2, well, that might take too long
>>>>>> and too many tobmstones could then appear in the meanwhile (and queries
>>>>>> might subsequently fail). Wouldn't be more correct to flag the SStable's
>>>>>> generation to its previous value (namely, not changing it even if a major
>>>>>> compaction took place)?
>>>>>>
>>>>>> Regards,
>>>>>> Stefano Ortolani
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://khangaonkar.blogspot.com/
>>>>>
>>>>
>>>>
>>>
>>
>
