You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Andrew Lenards (JIRA)" <ji...@apache.org> on 2014/09/19 02:06:33 UTC
[jira] [Updated] (CASSANDRA-7976) Changes to index_interval table
properties revert after subsequent modifications
[ https://issues.apache.org/jira/browse/CASSANDRA-7976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Lenards updated CASSANDRA-7976:
--------------------------------------
Description:
It appears that if you want to increase the sampling in *-Summary.db files, you would change the default for {{index_interval}} table property from the {{128}} default value to {{256}} on a given CQL {{TABLE}}.
However, if you {{ALTER TABLE}} after setting the value, {{index_interval}} returns to the default, {{128}}. This is unexpected behavior. I would expect the value for {{index_interval}} to not be affected by subsequent {{ALTER TABLE}} statements.
As noted in Environment, this was seen with a 2.0.9-SNAPSHOT built w/ `ccm`.
If I just use a table from one of DataStax documentation tutorials (musicdb as mdb):
{noformat}
cqlsh:mdb> DESC TABLE songs;
CREATE TABLE songs (
id uuid,
album text,
artist text,
data blob,
reviews list<text>,
tags set<text>,
title text,
venue map<timestamp, text>,
PRIMARY KEY ((id))
) WITH
bloom_filter_fp_chance=0.010000 AND
caching='KEYS_ONLY' AND
comment='' AND
dclocal_read_repair_chance=0.100000 AND
gc_grace_seconds=864000 AND
index_interval=128 AND
read_repair_chance=0.000000 AND
replicate_on_write='true' AND
populate_io_cache_on_flush='false' AND
default_time_to_live=0 AND
speculative_retry='99.0PERCENTILE' AND
memtable_flush_period_in_ms=0 AND
compaction={'class': 'SizeTieredCompactionStrategy'} AND
compression={'sstable_compression': 'LZ4Compressor'};
{noformat}
We've got {{128}} as expected.
We alter it:
{noformat}
cqlsh:mdb> ALTER TABLE songs WITH index_interval = 256;
{noformat}
And the change appears:
{noformat}
cqlsh:mdb> DESC TABLE songs;
CREATE TABLE songs (
id uuid,
album text,
artist text,
data blob,
reviews list<text>,
tags set<text>,
title text,
venue map<timestamp, text>,
PRIMARY KEY ((id))
) WITH
bloom_filter_fp_chance=0.010000 AND
caching='KEYS_ONLY' AND
comment='' AND
dclocal_read_repair_chance=0.100000 AND
gc_grace_seconds=864000 AND
index_interval=256 AND
read_repair_chance=0.000000 AND
replicate_on_write='true' AND
populate_io_cache_on_flush='false' AND
default_time_to_live=0 AND
speculative_retry='99.0PERCENTILE' AND
memtable_flush_period_in_ms=0 AND
compaction={'class': 'SizeTieredCompactionStrategy'} AND
compression={'sstable_compression': 'LZ4Compressor'};
{noformat}
But if do another {{ALTER TABLE}}, say, change the caching or comment, the {{index_interval}} will revert back to {{128}}.
{noformat}
cqlsh:mdb> ALTER TABLE songs WITH caching = 'none';
cqlsh:mdb> DESC TABLE songs;
CREATE TABLE songs (
id uuid,
album text,
artist text,
data blob,
reviews list<text>,
tags set<text>,
title text,
venue map<timestamp, text>,
PRIMARY KEY ((id))
) WITH
bloom_filter_fp_chance=0.010000 AND
caching='NONE' AND
comment='' AND
dclocal_read_repair_chance=0.100000 AND
gc_grace_seconds=864000 AND
index_interval=128 AND
read_repair_chance=0.000000 AND
replicate_on_write='true' AND
populate_io_cache_on_flush='false' AND
default_time_to_live=0 AND
speculative_retry='99.0PERCENTILE' AND
memtable_flush_period_in_ms=0 AND
compaction={'class': 'SizeTieredCompactionStrategy'} AND
compression={'sstable_compression': 'LZ4Compressor'};
{noformat}
It should be {{index_interval=256}}.
I know that 2.1 will replace {{index_interval}}.
I have not confirmed any behavior with {{min_index_interval}} nor {{max_index_interval}} (which is described in resolved #6379).
was:
It appears that if you want to increase the sampling in *-Summary.db files, you would change the default for {{index_interval}} table property from the {{128}} default value to {{256}} on a given CQL {{TABLE}}.
However, if you {{ALTER TABLE}} after setting the value, {{index_interval}} returns to the default, {{128}}. This is unexpected behavior. I would expect the value for {{index_interval}} to not be affected by subsequent {{ALTER TABLE}} statements.
As noted in Environment, this was seen with a 2.0.9-SNAPSHOT built w/ `ccm`.
If I just use a table from one of DataStax documentation tutorials (musicdb as mdb):
{noformat}
cqlsh:mdb> DESC TABLE songs;
CREATE TABLE songs (
id uuid,
album text,
artist text,
data blob,
reviews list<text>,
tags set<text>,
title text,
venue map<timestamp, text>,
PRIMARY KEY ((id))
) WITH
bloom_filter_fp_chance=0.010000 AND
caching='KEYS_ONLY' AND
comment='' AND
dclocal_read_repair_chance=0.100000 AND
gc_grace_seconds=864000 AND
index_interval=128 AND
read_repair_chance=0.000000 AND
replicate_on_write='true' AND
populate_io_cache_on_flush='false' AND
default_time_to_live=0 AND
speculative_retry='99.0PERCENTILE' AND
memtable_flush_period_in_ms=0 AND
compaction={'class': 'SizeTieredCompactionStrategy'} AND
compression={'sstable_compression': 'LZ4Compressor'};
{noformat}
We've got {{128}} as expected.
We alter it:
{noformat}
cqlsh:mdb> ALTER TABLE songs WITH index_interval = 256;
{noformat}
And the change appears:
{noformat}
cqlsh:mdb> DESC TABLE songs;
CREATE TABLE songs (
id uuid,
album text,
artist text,
data blob,
reviews list<text>,
tags set<text>,
title text,
venue map<timestamp, text>,
PRIMARY KEY ((id))
) WITH
bloom_filter_fp_chance=0.010000 AND
caching='KEYS_ONLY' AND
comment='' AND
dclocal_read_repair_chance=0.100000 AND
gc_grace_seconds=864000 AND
index_interval=256 AND
read_repair_chance=0.000000 AND
replicate_on_write='true' AND
populate_io_cache_on_flush='false' AND
default_time_to_live=0 AND
speculative_retry='99.0PERCENTILE' AND
memtable_flush_period_in_ms=0 AND
compaction={'class': 'SizeTieredCompactionStrategy'} AND
compression={'sstable_compression': 'LZ4Compressor'};
{noformat}
But if do another {{ALTER TABLE}}, say, change the caching or comment, the {{index_interval}} will revert back to {{128}}.
{noformat}
cqlsh:mdb> ALTER TABLE songs WITH caching = 'none';
cqlsh:mdb> DESC TABLE songs;
CREATE TABLE songs (
id uuid,
album text,
artist text,
data blob,
reviews list<text>,
tags set<text>,
title text,
venue map<timestamp, text>,
PRIMARY KEY ((id))
) WITH
bloom_filter_fp_chance=0.010000 AND
caching='NONE' AND
comment='' AND
dclocal_read_repair_chance=0.100000 AND
gc_grace_seconds=864000 AND
index_interval=128 AND
read_repair_chance=0.000000 AND
replicate_on_write='true' AND
populate_io_cache_on_flush='false' AND
default_time_to_live=0 AND
speculative_retry='99.0PERCENTILE' AND
memtable_flush_period_in_ms=0 AND
compaction={'class': 'SizeTieredCompactionStrategy'} AND
compression={'sstable_compression': 'LZ4Compressor'};
{noformat}
It should be index_interval=256.
I know that 2.1 will replace {{index_interval}}.
I have not confirmed any behavior with {{min_index_interval}} nor {{max_index_interval}} (which is described in resolved #6379).
> Changes to index_interval table properties revert after subsequent modifications
> --------------------------------------------------------------------------------
>
> Key: CASSANDRA-7976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7976
> Project: Cassandra
> Issue Type: Bug
> Components: Config
> Environment: cqlsh 4.1.1, Cassandra 2.0.9-SNAPSHOT (built w/ `ccm` on Mac OS X 10.9.4 with Java 1.7.0_67 - more detail below)
> $ java -version
> java version "1.7.0_67"
> Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
> $ mvn --version
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T13:58:10-07:00)
> Maven home: /usr/local/Cellar/maven/3.2.3/libexec
> Java version: 1.7.0_67, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.9.4", arch: "x86_64", family: "mac"
> Reporter: Andrew Lenards
> Labels: cql3, metadata
>
> It appears that if you want to increase the sampling in *-Summary.db files, you would change the default for {{index_interval}} table property from the {{128}} default value to {{256}} on a given CQL {{TABLE}}.
> However, if you {{ALTER TABLE}} after setting the value, {{index_interval}} returns to the default, {{128}}. This is unexpected behavior. I would expect the value for {{index_interval}} to not be affected by subsequent {{ALTER TABLE}} statements.
> As noted in Environment, this was seen with a 2.0.9-SNAPSHOT built w/ `ccm`.
> If I just use a table from one of DataStax documentation tutorials (musicdb as mdb):
> {noformat}
> cqlsh:mdb> DESC TABLE songs;
> CREATE TABLE songs (
> id uuid,
> album text,
> artist text,
> data blob,
> reviews list<text>,
> tags set<text>,
> title text,
> venue map<timestamp, text>,
> PRIMARY KEY ((id))
> ) WITH
> bloom_filter_fp_chance=0.010000 AND
> caching='KEYS_ONLY' AND
> comment='' AND
> dclocal_read_repair_chance=0.100000 AND
> gc_grace_seconds=864000 AND
> index_interval=128 AND
> read_repair_chance=0.000000 AND
> replicate_on_write='true' AND
> populate_io_cache_on_flush='false' AND
> default_time_to_live=0 AND
> speculative_retry='99.0PERCENTILE' AND
> memtable_flush_period_in_ms=0 AND
> compaction={'class': 'SizeTieredCompactionStrategy'} AND
> compression={'sstable_compression': 'LZ4Compressor'};
> {noformat}
> We've got {{128}} as expected.
> We alter it:
> {noformat}
> cqlsh:mdb> ALTER TABLE songs WITH index_interval = 256;
> {noformat}
> And the change appears:
> {noformat}
> cqlsh:mdb> DESC TABLE songs;
> CREATE TABLE songs (
> id uuid,
> album text,
> artist text,
> data blob,
> reviews list<text>,
> tags set<text>,
> title text,
> venue map<timestamp, text>,
> PRIMARY KEY ((id))
> ) WITH
> bloom_filter_fp_chance=0.010000 AND
> caching='KEYS_ONLY' AND
> comment='' AND
> dclocal_read_repair_chance=0.100000 AND
> gc_grace_seconds=864000 AND
> index_interval=256 AND
> read_repair_chance=0.000000 AND
> replicate_on_write='true' AND
> populate_io_cache_on_flush='false' AND
> default_time_to_live=0 AND
> speculative_retry='99.0PERCENTILE' AND
> memtable_flush_period_in_ms=0 AND
> compaction={'class': 'SizeTieredCompactionStrategy'} AND
> compression={'sstable_compression': 'LZ4Compressor'};
> {noformat}
> But if do another {{ALTER TABLE}}, say, change the caching or comment, the {{index_interval}} will revert back to {{128}}.
> {noformat}
> cqlsh:mdb> ALTER TABLE songs WITH caching = 'none';
> cqlsh:mdb> DESC TABLE songs;
> CREATE TABLE songs (
> id uuid,
> album text,
> artist text,
> data blob,
> reviews list<text>,
> tags set<text>,
> title text,
> venue map<timestamp, text>,
> PRIMARY KEY ((id))
> ) WITH
> bloom_filter_fp_chance=0.010000 AND
> caching='NONE' AND
> comment='' AND
> dclocal_read_repair_chance=0.100000 AND
> gc_grace_seconds=864000 AND
> index_interval=128 AND
> read_repair_chance=0.000000 AND
> replicate_on_write='true' AND
> populate_io_cache_on_flush='false' AND
> default_time_to_live=0 AND
> speculative_retry='99.0PERCENTILE' AND
> memtable_flush_period_in_ms=0 AND
> compaction={'class': 'SizeTieredCompactionStrategy'} AND
> compression={'sstable_compression': 'LZ4Compressor'};
> {noformat}
> It should be {{index_interval=256}}.
> I know that 2.1 will replace {{index_interval}}.
> I have not confirmed any behavior with {{min_index_interval}} nor {{max_index_interval}} (which is described in resolved #6379).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)