Re: Representation of dynamically added columns in table (column family) schema using cqlsh
See http://www.datastax.com/dev/blog/thrift-to-cql3 for more information.
On Sat, Jul 13, 2013 at 1:19 AM, Eric Stevens wrote:
> If you're creating dynamic columns via Thrift interface, they will not be
> reflected in the CQL3 schema. I would recommend not mixing paradigms like
> that, either stick with CQL3 or Thrift / cassandra-cli. With compact
> storage creates column families which can be interacted with meaningfully
> via Thrift, but you'll be lacking any metadata on those columns to interact
> with them via cql.
>
>
> On Fri, Jul 12, 2013 at 11:13 AM, Shahab Yunus wrote:
>
>> A basic question and it seems that I have a gap in my understanding.
>>
>> I have a simple table in Cassandra with multiple column families. I add
>> new columns to each of these column families on the fly. When I view (using
>> the 'DESCRIBE table' command) the schema of a particular column family, I
>> see only one entry for column (bolded below). What is the reason for that?
>> The column that I am adding have string names and byte values, written
>> using Hector 1.1-3 (
>> HFactory.createColumn(...) method).
>>
>> CREATE TABLE mytable (
>> key text,
>> *column1* ascii,
>> value blob,
>> PRIMARY KEY (key, column1)
>> ) WITH COMPACT STORAGE AND
>> bloom_filter_fp_chance=0.01 AND
>> caching='KEYS_ONLY' AND
>> comment='' AND
>> dclocal_read_repair_chance=0.00 AND
>> gc_grace_seconds=864000 AND
>> read_repair_chance=1.00 AND
>> replicate_on_write='true' AND
>> populate_io_cache_on_flush='false' AND
>> compaction={'class': 'SizeTieredCompactionStrategy'} AND
>> compression={'sstable_compression': 'SnappyCompressor'};
>>
>> cqlsh 3.0.2
>> Cassandra 1.2.5
>> CQL spec 3.0.0
>> Thrift protocol 19.36.0
>>
>>
>> Given this, I can also only query on this one column1 or value using the
>> 'SELECT' statement.
>>
>> The OpsCenter on the other hand, displays multiple columns as
>> expected. Basically the demarcation of multiple columns i clearer.
>>
>> Thanks a lot.
>>
>> Regards,
>> Shahab
>>
>
>
--
mithrandi, i Ainil en-Balandor, a faer Ambar
Re: IllegalArgumentException on query with AbstractCompositeType
On Fri, Jul 12, 2013 at 10:38 AM, aaron morton wrote: > CREATE INDEX ON conv_msgdata_by_participant_cql(msgReadFlag); > > On general this is a bad idea in Cassandra (also in a relational DB IMHO). > You will get poor performance from it. > Could you elaborate on why this is a bad idea? -- mithrandi, i Ainil en-Balandor, a faer Ambar
Re: IllegalArgumentException on query with AbstractCompositeType
Aaron Morton can confirm but I think one problem could be that to create an index on a field with small number of possible values is not good. Regards, Shahab On Sat, Jul 13, 2013 at 9:14 AM, Tristan Seligmann wrote: > On Fri, Jul 12, 2013 at 10:38 AM, aaron morton wrote: > >> CREATE INDEX ON conv_msgdata_by_participant_cql(msgReadFlag); >> >> On general this is a bad idea in Cassandra (also in a relational DB >> IMHO). You will get poor performance from it. >> > > Could you elaborate on why this is a bad idea? > -- > mithrandi, i Ainil en-Balandor, a faer Ambar >
Re: Node tokens / data move
Pretty sure you can put the list in the yaml file too. -Jeremiah On Jul 12, 2013, at 3:09 AM, aaron morton wrote: >> Can he not specify all 256 tokens in the YAML of the new >> cluster and then copy sstables? >> I know it is a bit ugly but should work. > You can pass a comma separated list of tokens to the > -Dcassandra.replace_token JVM param. > > AFAIK it's not possible to provide the list in the yaml file. > > Cheers > A > > - > Aaron Morton > Cassandra Consultant > New Zealand > > @aaronmorton > http://www.thelastpickle.com > > On 11/07/2013, at 5:07 AM, Baskar Duraikannu > wrote: > >> >> I copied the sstables and then ran a repair. It worked. Looks like export >> and import may have been much faster given that we had very little data. >> >> Thanks everyone. >> >> >> >> >> On Tue, Jul 9, 2013 at 1:34 PM, sankalp kohli wrote: >> Hi Aaron, >> Can he not specify all 256 tokens in the YAML of the new >> cluster and then copy sstables? >> I know it is a bit ugly but should work. >> >> Sankalp >> >> >> On Tue, Jul 9, 2013 at 3:19 AM, Baskar Duraikannu >> wrote: >> Thanks Aaron >> >> On 7/9/13, aaron morton wrote: >> >> Can I just copy data files for the required keyspaces, create schema >> >> manually and run repair? >> > If you have something like RF 3 and 3 nodes then yes, you can copy the data >> > from one node in the source cluster to all nodes in the dest cluster and >> > use >> > cleanup to remove the unneeded data. Because each node in the source >> > cluster >> > has a full copy of the data. >> > >> > If that's not the case you cannot copy the data files, even if they have >> > the >> > same number of nodes, because the nodes in the dest cluster will have >> > different tokens. AFAIK you need to export the full data set from the >> > source >> > DC and then import it into the dest system. >> > >> > The Bulk Load utility may be of help >> > http://www.datastax.com/docs/1.2/references/bulkloader . You could copy the >> > SSTables from every node in the source system and bulk load them into the >> > dest system. That process will ensure rows are sent to nodes that are >> > replicas. >> > >> > Cheers >> > >> > - >> > Aaron Morton >> > Freelance Cassandra Consultant >> > New Zealand >> > >> > @aaronmorton >> > http://www.thelastpickle.com >> > >> > On 9/07/2013, at 12:45 PM, Baskar Duraikannu >> > wrote: >> > >> >> We have two clusters used by two different groups with vnodes enabled. Now >> >> there is a need to move some of the keyspaces from cluster 1 to cluster 2. >> >> >> >> >> >> Can I just copy data files for the required keyspaces, create schema >> >> manually and run repair? >> >> >> >> Anything else required? Please help. >> >> -- >> >> Thanks, >> >> Baskar Duraikannu >> > >> > >> >> >
