I am sure there will be other attributes associated with employee. Reading
and throwing away records on the client is not good.
Better maintain another column family that holds reference to only male
employees. This will make your pagination logic simple on the client side
without wasting resource
There is a aubtle difference between work well amd efficient design.
Say you add this index, that is a huge cost on disk just because cql may
not allow the where clause you want.
Shameless plug but this is why i worked on intravert...server side paging
may be the right answer here. I plan on open
Thanks for that info ondrej, I've never tested out secondary indexes as
I've avoided them because of all the uncertainty around them, and your
statement just adds to the uncertainty. Everything I had read said that
secondary indexes were supposed to work well for columns with low
cardinality, but
Hi,
we had a similar use case. Just do the filtering client-side, the #2
example performs horribly, secondary indexes on something dividing the set
into two roughly the same size subsets just don't work.
Give it a try on localhost with just a couple of records (150.000), you
will see.
regards,
in my #2 example:
select * from people where company_id='xxx' and gender='male'
I already specify the first part of the primary key(row key) in my where
clause, so how does the secondary indexed column gender='male" help
determine which row to return? It is more like filtering a list of column
fro
I would do #2. Take a look at this blog which talks about secondary
indexes, cardinality, and what it means for cassandra. Secondary indexes
in cassandra are a different beast, so often old rules of thumb about
indexes don't apply. http://www.wentnet.com/blog/?p=77
On Tue, Jan 28, 2014 at 1
I have a simple column family like the following
create table people(
company_id text,
employee_id text,
gender text,
primary key(company_id, employee_id)
);
if I want to find out all the "male" employee given a company id, I can do
1/
select * from people where company_id='
and loop through
Generally indexes on binary fields true/false male/female are not terrible
effective.
On Tue, Jan 28, 2014 at 12:40 PM, Jimmy Lin wrote:
> I have a simple column family like the following
>
> create table people(
> company_id text,
> employee_id text,
> gender text,
> primary key(company_id, em
