I was thinking of a CF with many many rows with id, type, latitude and longitude (indexed), and do geolocation queries: type=all and lat < 43 and lat >42.9 and lon < 7.3 and lon > 7.2
where all rows have type=all (at least try how Cassandra deals with that) So it seems it's not a good idea, to use Cassandra like that? There's also the possibly to do in parallel, other CF, with latitude in rows, that will be sorted, so an indexed query can give us the right latidue range, and then just query with logitude < and > What do you think of that thanks 2012/5/11 Dave Brosius <dbros...@mebigfatguy.com> > Inequalities on secondary indices are always done in memory, so without at > least one EQ on another secondary index you will be loading every row in > the database, which with a massive database isn't a good idea. So by > requiring at least one EQ on an index, you hopefully limit the set of rows > that need to be read into memory to a manageable size. Although obviously > you can still get into trouble with that as well. > > > > > On 05/11/2012 09:39 AM, cyril auburtin wrote: > >> Sorry for askign that >> but Why is it necessary to always have at least one EQ comparison >> >> [default@Keyspace1] get test where birth_year>1985; >> No indexed columns present in index clause with operator EQ >> >> It oblige to have one dummy indexed column, to do this query >> >> [default@Keyspace1] get test where tag=sea and birth_year>1985; >> ------------------- >> RowKey: sam >> => (column=birth_year, value=1988, timestamp=1336742346059000) >> >> >> >
