Can you put that in a ticket ? https://issues.apache.org/jira/browse/CASSANDRA
Cheers ----------------- Aaron Morton Cassandra Consultant New Zealand @aaronmorton http://www.thelastpickle.com On 30/07/2013, at 12:52 AM, Keith Wright <kwri...@nanigans.com> wrote: > Version 1.2.4. > > Original alter that does nothing: alter table shard_user_lookup with > compaction_strategy_options = {'sstable_size_in_mb':256}; > > Correct alter: alter table cookie_user_lookup with > compaction={'sstable_size_in_mb': '256', 'class': > 'LeveledCompactionStrategy'}; > > Thanks > > From: aaron morton <aa...@thelastpickle.com> > Reply-To: "user@cassandra.apache.org" <user@cassandra.apache.org> > Date: Monday, July 29, 2013 4:02 AM > To: "user@cassandra.apache.org" <user@cassandra.apache.org> > Subject: Re: sstable size change > >> I still would have expected my original alter command to at least have >> thrown an error. I assume I should open a bug for this? > Sounds like a good idea. > > Please describe the version and query you first used. > > Thanks for taking the time to update the thread. > > Cheers > > > ----------------- > Aaron Morton > Cassandra Consultant > New Zealand > > @aaronmorton > http://www.thelastpickle.com > > On 27/07/2013, at 12:57 AM, Keith Wright <kwri...@nanigans.com> wrote: > >> FYI. It appears that the proper command in CQL3 is the following: >> >> alter table cookie_user_lookup with compaction={'sstable_size_in_mb': '256', >> 'class': 'LeveledCompactionStrategy'}; >> >> I still would have expected my original alter command to at least have >> thrown an error. I assume I should open a bug for this? >> >> alter table shard_user_lookup with compaction_strategy_options = >> {'sstable_size_in_mb':256}; >> >> >> From: Keith Wright <kwri...@nanigans.com> >> Reply-To: "user@cassandra.apache.org" <user@cassandra.apache.org> >> Date: Thursday, July 25, 2013 9:14 AM >> To: "user@cassandra.apache.org" <user@cassandra.apache.org>, Wei Zhu >> <wz1...@yahoo.com> >> Subject: Re: sstable size change >> >> Unfortunately the table in question is a CQL3 table so cassandra-cli will >> not output its describe: >> >> WARNING: CQL3 tables are intentionally omitted from 'describe' output. >> See https://issues.apache.org/jira/browse/CASSANDRA-4377 for details. >> >> However, I did figure out that apparently I was not setting the change >> properly. I was using the following alter via CQL3: >> >> alter table shard_user_lookup with compaction_strategy_options = >> {'sstable_size_in_mb':256}; >> >> But when I did a describe, I did not see the change. >> >> CREATE TABLE shard_user_lookup ( >> shard_user_id int, >> shard text, >> creation_time timestamp, >> status int, >> user_id timeuuid, >> PRIMARY KEY (shard_user_id, shard) >> ) WITH >> bloom_filter_fp_chance=0.100000 AND >> caching='KEYS_ONLY' AND >> comment='' AND >> dclocal_read_repair_chance=0.000000 AND >> gc_grace_seconds=86400 AND >> read_repair_chance=0.100000 AND >> replicate_on_write='true' AND >> populate_io_cache_on_flush='false' AND >> compaction={'class': 'LeveledCompactionStrategy'} AND >> compression={'chunk_length_kb': '8', 'crc_check_chance': '0.1', >> 'sstable_compression': 'LZ4Compressor'}; >> >> If I then execute the following via CQL2, I do see the property. Seems odd >> to me? >> >> alter table shard_user_lookup with >> compaction_strategy_options:sstable_size_in_mb=256; >> >> CREATE TABLE shard_user_lookup ( >> shard_user_id int, >> shard text, >> creation_time timestamp, >> status int, >> user_id timeuuid, >> PRIMARY KEY (shard_user_id, shard) >> ) WITH >> bloom_filter_fp_chance=0.100000 AND >> caching='KEYS_ONLY' AND >> comment='' AND >> dclocal_read_repair_chance=0.000000 AND >> gc_grace_seconds=86400 AND >> read_repair_chance=0.100000 AND >> replicate_on_write='true' AND >> populate_io_cache_on_flush='false' AND >> compaction={'sstable_size_in_mb': '256', 'class': >> 'LeveledCompactionStrategy'} AND >> compression={'chunk_length_kb': '8', 'crc_check_chance': '0.1', >> 'sstable_compression': 'LZ4Compressor'}; >> >> >> From: Wei Zhu <wz1...@yahoo.com> >> Reply-To: "user@cassandra.apache.org" <user@cassandra.apache.org>, Wei Zhu >> <wz1...@yahoo.com> >> Date: Wednesday, July 24, 2013 8:49 PM >> To: "user@cassandra.apache.org" <user@cassandra.apache.org> >> Subject: Re: sstable size change >> >> what is output of show keyspaces from cassandra-cli, did you see the new >> value? >> >> Compaction Strategy: >> org.apache.cassandra.db.compaction.LeveledCompactionStrategy >> Compaction Strategy Options: >> sstable_size_in_mb: XXX >> >> From: Keith Wright <kwri...@nanigans.com> >> To: "user@cassandra.apache.org" <user@cassandra.apache.org> >> Sent: Wednesday, July 24, 2013 3:44 PM >> Subject: Re: sstable size change >> >> Hi all, >> >> This morning I increased the SSTable size for one of my LCS via an alter >> command and saw at least one compaction run (I did not trigger a compaction >> via nodetool nor upgrades stables nor removing the .json file). But so far >> my data sizes appear the same at the default 5 MB (see below for output of >> ls –Sal as well as relevant portion of cfstats). Is this expected? I was >> hoping to see at least one file at the new 256 MB size I set. >> >> Thanks >> >> SSTable count: 4965 >> SSTables in each level: [0, 10, 112/100, 1027/1000, 3816, 0, 0, 0] >> Space used (live): 29062393142 >> Space used (total): 29140547702 >> Number of Keys (estimate): 195103104 >> Memtable Columns Count: 441483 >> Memtable Data Size: 205486218 >> Memtable Switch Count: 243 >> Read Count: 154226729 >> >> -rw-rw-r-- 1 cassandra cassandra 5247564 Jul 18 01:33 >> users-shard_user_lookup-ib-97153-Data.db >> -rw-rw-r-- 1 cassandra cassandra 5247454 Jul 23 02:59 >> users-shard_user_lookup-ib-109063-Data.db >> -rw-rw-r-- 1 cassandra cassandra 5247421 Jul 20 14:58 >> users-shard_user_lookup-ib-103127-Data.db >> -rw-rw-r-- 1 cassandra cassandra 5247415 Jul 17 13:56 >> users-shard_user_lookup-ib-95761-Data.db >> -rw-rw-r-- 1 cassandra cassandra 5247379 Jul 21 02:44 >> users-shard_user_lookup-ib-104718-Data.db >> -rw-rw-r-- 1 cassandra cassandra 5247346 Jul 21 21:54 >> users-shard_user_lookup-ib-106280-Data.db >> -rw-rw-r-- 1 cassandra cassandra 5247242 Jul 3 19:41 >> users-shard_user_lookup-ib-66049-Data.db >> -rw-rw-r-- 1 cassandra cassandra 5247235 Jul 21 02:44 >> users-shard_user_lookup-ib-104737-Data.db >> -rw-rw-r-- 1 cassandra cassandra 5247233 Jul 20 14:58 >> users-shard_user_lookup-ib-103169-Data.db >> >> >> From: sankalp kohli <kohlisank...@gmail.com> >> Reply-To: "user@cassandra.apache.org" <user@cassandra.apache.org> >> Date: Tuesday, July 23, 2013 3:04 PM >> To: "user@cassandra.apache.org" <user@cassandra.apache.org> >> Subject: Re: sstable size change >> >> "Will Cassandra force any newly compacted files to my new setting as >> compactions are naturally triggered" >> Yes. Let it compact and increase in size. >> >> >> On Tue, Jul 23, 2013 at 9:38 AM, Robert Coli <rc...@eventbrite.com> wrote: >>> On Tue, Jul 23, 2013 at 6:48 AM, Keith Wright <kwri...@nanigans.com> wrote: >>>> Can you elaborate on what you mean by "let it take its own course >>>> organically"? Will Cassandra force any newly compacted files to my new >>>> setting as compactions are naturally triggered? >>> >>> You see, when two (or more!) SSTables love each other very much, they >>> sometimes decide they want to compact together.. >>> >>> But seriously, "yes." If you force all existing SSTables to level 0, it is >>> as if you just flushed them all. Level compaction then does a whole lot of >>> compaction, using the active table size. >>> >>> =Rob >> >> >> >
