Hi: If you model your table with 'status' as the partitiion key you are limiting your cluster. If status only has 5 posible values, every insert will be assigned only to 5 nodes. So, you will not use your cluster resources correctly.
create table ks1.sta1(status int,id1 bigint,id2 binint,resp text,primary key(*(*status,id1*)*)); Use status and id1 as a compounded partition key. Regards Eduardo Alonso Vía de las dos Castillas, 33, Ática 4, 3ª Planta 28224 Pozuelo de Alarcón, Madrid Tel: +34 91 828 6473 // www.stratio.com // *@stratiobd <https://twitter.com/StratioBD>* 2017-06-20 9:38 GMT+02:00 @Nandan@ <nandanpriyadarshi...@gmail.com>: > Hi , > Better you can go with denormalized the data based on status. > create table ks1.sta1(status int,id1 bigint,id2 binint,resp text,primary > key(status,id1)); > This will allow you to do as you want.. > select * from ks1.sta1 where status = 0 and id1 = 123; > > Please make sure, that (status and id1) gives uniqueness to your data. > > On Tue, Jun 20, 2017 at 3:29 PM, techpyaasa . <techpya...@gmail.com> > wrote: > >> Hi ZAIDI, >> >> Thanks for reply. >> Sorry I didn't get your line >> "You can get away the potential situation by leveraging composite key, if >> that is possible for you?" >> >> How can I get through it?? >> >> Like I have a table as below >> CREATE TABLE ks1.cf1 (id1 bigint, id2 bigint, resp text, status int, >> PRIMARY KEY (id1, id2) >> ) WITH CLUSTERING ORDER BY (id2 ASC) >> >> 'status' will have values of 0/1/2/3/4 (4 possible values) , insertions >> to table(partition) will happen based on id2 i.e values(id1,id2,resp,status) >> >> I want to have a filtering/criteria applied on 'status' column too like >> select * from ks1.cf1 where id1=123 and status=0; >> >> How can I achieve this w/o secondary index (on 'status' column )?? >> >> >> On Tue, Jun 20, 2017 at 12:09 AM, ZAIDI, ASAD A <az1...@att.com> wrote: >> >>> If you’re only creating index so that your query work, think again! >>> You’ll be storing secondary index on each node , queries involving index >>> could create issues (slowness!!) down the road the when index on multiple >>> node Is involved and not maintained! Tables involving a lot of >>> inserts/delete could easily ruin index performance. >>> >>> >>> >>> You can get away the potential situation by leveraging composite key, if >>> that is possible for you? >>> >>> >>> >>> >>> >>> *From:* techpyaasa . [mailto:techpya...@gmail.com] >>> *Sent:* Monday, June 19, 2017 1:01 PM >>> *To:* user@cassandra.apache.org >>> *Subject:* Secondary Index >>> >>> >>> >>> Hi, >>> >>> I want to create Index on already existing table which has more than 3 >>> GB/node. >>> We are using c*-2.1.17 with 2 DCs , each DC with 3 groups and each group >>> has 7 nodes.(Total 42 nodes in cluster) >>> >>> So is it ok to create Index on this table now or will it have any >>> problem? >>> If its ok , how much time it would take for this process? >>> >>> >>> Thanks in advance, >>> TechPyaasa >>> >> >> >
