How to define secondary key while table creation? - cassandra

I was trying to create a secondary index in cassandra using cql3. I know I can do it using CREATE INDEX.. syntax.
But is there any way I can designate a column as Secondary key when using CREATE TABLE.. syntax i.e., while defining a table?
I have searched on internet but getting results regarding CREATE INDEX. I'm not sure how to frame it.

Nope. You have to do two queries. You can do them one after the other.

Related

can we create datasync between two tables without indexes in azure data sync

can we sync two tables of two different databases in azure without indexes. As, we all know ,if two databases has to be in sync hub database and member data base should have same schema. But is there chance of avoiding indexes.
please help me with this
Each table needs to have a primary key and you cannot avoid that. Please read the following excerpt from Microsoft documentation:
Each table must have a primary key. Don't change the value of the
primary key in any row. If you have to change a primary key value,
delete the row and recreate it with the new primary key value.
Source here.

Link two tables in spotfire

I have two tables which I want to connect through a common key, when that is done I would be able to select something in on of the table which would make the other table respond with the data associated to that common key...
But I am not sure how see that, I can see they are connected, but I can't get the 'selection' to work
After you join the tables (not a prerequisite by the way), set up a relationship between the two tables on the common key(s) by going to Edit > Data Table Properties > Relations.
Relationships allow markings and filters to propagate through tables that may not even be joined. For example, with a proper relationship, if I mark one table on a key that is also in another table, that other table will be marked. This can drive visualizations and detailed drill downs. You can read more from spotfire at the below link.
https://docs.tibco.com/pub/sfire-analyst/7.5.0/doc/html/WebHelp/data/data_details_on_manage_relations.htm

Duplicate entry '??' for key 'emp_name_unique2'

When I design my table, there comes a error:
Duplicate entry '??' for key 'emp_name_unique2'
My design table:
When I save it, comes the error.
Where is the problem?
EDIT
My data in t_employee:
That is, you see the emp_name, if you want to set it to unique, you should make sure the value is unique first.
You have many same ?? in the emp_name.
In general, Design table should before add data.

Kibana Dashboard from Multiple Indices

I have a Couch DB server that stores a number of sets of logs. Each of these is pulled into elastic search via a river. This works fine. Each of the indices has a timestamp field (the same field name in each index). I am trying to create a kibana dashboard which shows all a number of charts, one for each index. The problem I'm having is that there doesn't seem to be a way to distinguish which index each chart is built from. Is this possible or do I have to have a dashboard per index?
You can create custom dashboards depending upon the index. Create a new dashboard and visualize upon custom fields and add it to dashboard.
Likewise create new dashboard and you can add visualizations of another index.
Now you can monitor with different dashboards.
You may be able to use an alias that points to multiple indexes. Then create multiple queries.
Alias with multiple indices

CQL Select on column value

I am creating account data in Cassandra. Accounts are most commonly queried based on an account id. However, often the account is queried by a login name. I have created a user table with primary keys (account_id and login_name). Because of this, I have to "ALLOW FILTERING" on the table to query by the login_name.
Is there a better way to create the table that does not have the impact of a filterable table?
A possible approach is to define a new table that has the exact same elements in the primary key but in the reverse order: (login_name, account_id). You can still keep the table you present as the reference table, which stores all the relevant account data, but this new table would allow you more optimized queries based on login_name. I am not sure how much you would win compared with the query "allowing filtering"... But this kind of "data duplication" for query optimization is a normal procedure in NoSQL DBs.
HTH.

Resources