No the employees would end up in arbitrary partitions, and querying them would be inefficient (impossible? - I am levels back on C* so don’t know if ALLOW FILTERING even works for this).
I would be tempted to use organization_id only or organization_Id and maybe a few shard bits (if you are worried about huge orgs) from the employee_Id to make the partition key, but it really depends what other queries you will be making > On Oct 8, 2016, at 11:19 PM, Ali Akhtar <ali.rac...@gmail.com> wrote: > > In the case of PRIMARY KEY((organization_id, employee_id)), could I still do > a query like Select ... where organization_id = x, to get all employees in a > particular organization? > > And, this will put all those employees in the same node, right? > > On Sun, Oct 9, 2016 at 9:17 AM, Graham Sanderson <gra...@vast.com > <mailto:gra...@vast.com>> wrote: > Nomenclature is tricky, but PRIMARY KEY((organization_id, employee_id)) will > make organization_id, employee_id the partition key which equates roughly to > your latter sentence (I’m not sure about the 4 billion limit - that may be > the new actual limit, but probably not a good idea). > >> On Oct 8, 2016, at 8:35 PM, Ali Akhtar <ali.rac...@gmail.com >> <mailto:ali.rac...@gmail.com>> wrote: >> >> the last '4 billion rows' should say '4 billion columns / cells' >> >> On Sun, Oct 9, 2016 at 6:34 AM, Ali Akhtar <ali.rac...@gmail.com >> <mailto:ali.rac...@gmail.com>> wrote: >> Say I have the following primary key: >> PRIMARY KEY((organization_id, employee_id)) >> >> Will this create 1 row whose primary key is the organization id, but it has >> a 4 billion column / cell limit? >> >> Or will this create 1 row for each employee in the same organization, so if >> i have 5 employees, they will each have their own 5 rows, and each of those >> 5 rows will have their own 4 billion rows? >> >> Thank you. >> > >
smime.p7s
Description: S/MIME cryptographic signature
