I was going through the documentation of CQLv3.0
Should we specify composite keys across updates and selects like 'a:b:1' incase my comparator or key_validation is ascii, ascii, int?
There is no mention on <select expression> in select or way to specify composite columns and rows in update too <primary/composite key name>
Expecting some help over it
CQL 3 takes care of managing the actual composite types and values for you. CQL 3 rows are not necessarily the same as the underlying Cassandra rows ("storage engine rows"). The composite values are abstracted into separate columns.
The example at http://www.datastax.com/dev/blog/schema-in-cassandra-1-1 may help in understanding the transformation.
Related
while designing the datamodel in cassandra. I am stuck while designing the below scenario.
Like One API/Webservice can have multiple parameters(input/output). I don't know the parameters count and its column name as well.
How to design its cassandra datamodel. I am aware that supercolumns are not good to use and alternative good solution is using composite keys. But for my scenario I don't have fixed columns names and count that I can specify as composite keys.
Please see the pic below which I want to model
Secondly how to write its create table statement so that I can specify parameter name as column name.
Please let me know if anything is unclear.
Thanks,
Why not use a map?
http://www.datastax.com/documentation/cql/3.1/cql/cql_using/use_map_t.html
create table foo(
name text,
owner text,
version text,
params map<text, text>,
primary key (name, owner, version)
);
If you're one 2.1, you can create secondary indexes on the map keys / values, which caters to more flexibility if needed.
Using CQL3, is it possible to define multiple formats of composite columns within a table/column family? With the syntax:
PRIMARY KEY(A, B, C)
it looks like A becomes the row key, a composite column of B:C is created, and additional composite columns are created for each additional column with B:C prepended.
What if I wanted to have in that same column family, another composite column X:Y - can that be accomplished?
I am not sure if that is possible using CLI. But we are using PlayOrm for Cassandra and there it is very much possible. Basically, you can have millions of composite columns. Read this for more details. The example is given for a OneToMany relation where you can have multiple column with name like activities.act1, activities.act2. Similarly you can have more entities with *ToMany relationship and can save them in composite column. If you do not want to use *ToMany relationship, then you may try its #NoSqlEmbedded pattern which also stores the data in composite columns.
Primary key identifies the single row of the table (all listed components). The A is a partition key that defines the placement of this partition on particular server.
In CQL3 you have only one primary key per table/column family. If you need to access it differently, you may (with some limitations) use the materialized views, or duplicate data into separate table.
So far, this is what I understand of the current Cassandra architecture:
Super columns are not desirable any more due to performance issues.
Composite columns (actually keys) are a good choice for indexing hierarchical keys.
Composite columns store nested components in sorted order. There is no actual index.
I have some questions:
Is everything I stated correct?
Can composite columns efficiently process range queries per component (assuming logical usage)?
Are composite columns suited to extremely large numbers of rows while still yielding rapid query results (considering they are not an index per se)?
Can secondary indexes be created against composite columns. If yes, can range queries be efficiently performed?
Thanks in advance.
Yes
Yes
Yes, because they are sorted on write just like any other column
Yes, secondaries can be created against composites as of 1.2. See this JIRA ticket
So I've defined a column family that uses composite ids for the row keys. So say the composite key is CompositeType(LongType,LongType). So I've tested storing items with this type and that works fine and SELECT works as expected too when I know the full key. But lets say I want all keys that have 0 as the first element and anything as the second. So far the only way that I can see to perform this query is as follows:
if I was all keys that are 0:* then I would do a CQL query for key >= 0:0 AND key < 1:0 which works as long as there is an order preserving partitioner.
My questions are:
1) is this odd syntax only because I'm using a CQL driver (only option for nodejs aside from thrift)
2) is there any inefficiency with this type of query? essentially i'm using a composite key instead of super columns since those aren't supported in CQL. I have no problem dealing with this logic in the code as long as there is no limitations to using it like this.
I would suggest you change your data model. Use RandomPartitioner and just have the first component as the row key. Push the second component into the column names, that is make your column names composites instead.
Since column names are always sorted, you can do easy slicing operations. For example,
a) When you know both the components, do a get slice on the row key(first component) and first component of the composite.
b) When you know just the first component, fetch the complete row for the row key(first component)
This is the approach CQL3 takes when you ask it to create a table with multiple primary keys.
Your best option is to use CQL 3. This will let you use composites underneath to optimize your lookups while still allowing you to use the parts of the composite values as though they were separate columns. You're currently using composites in your row keys, and CQL 3 only supports composites in column names (so far), but that's probably ok. In many cases like this, shifting the compositing from the row key to the column name won't have an adverse effect on your performance or data distribution, but if your row keys aren't sufficiently selective, then it might.
Either way, though, you should be looking at CQL 3. CQL 2 is deprecated. I could tell you more about how to adapt your model for CQL 3 if I knew more about your situation.
I've to test different datamodels for Cassandra. I'm thinking about to use a composite key made by key1:key2 for the row key.
With this configuration on Cassandra, for example, I can query to have all the rows having a specific key1 value and any key2 value but It's impossible otherwise (obtain all the rows having a specific key2's value and any key1).
Is it right?
thanks in advance
Cesare
If you use Order Preserving Partitioning (OPP), then yes, the keys will be stored sorted, and then you can get slices over a range of keys e.g. A:A to A:Z -- but not necessarily any:A to any:Z.
But, OPP is not guaranteed to evenly distribute the keys across the nodes and you could end up with "hot spots" of too many or too few keys. You probably want to use Random Partitioning (RP) which distributes the keys by storing by hash across all nodes.
However, since Columns are stored sorted, using Composite values can be pretty powerful for accessing ranges of data.
See this question for details on querying Composite columns using Hector .
If necessary, the column names could then be used as keys to do Multiget queries for additional lookups.
I hope these articles help you :)
http://pkghosh.wordpress.com/2011/03/02/cassandra-secondary-index-patterns/
http://www.datastax.com/docs/0.7/data_model/cfs_as_indexes
http://www.anuff.com/2011/02/indexing-in-cassandra.html
Also checkout this question
Storing a list of values in Cassandra