.The combination was performing better was querying for 500 rows at a time
with 1000 columns while different combinations, such as 125 rows for 4000
columns or 1000 rows for 500 columns, were about the 15% slower.
I would rarely go above 100 rows, specially if you are asking for 1000
Thank you Aaron, your advice about a newer client it is really
interesting. We will take in account it!
Here, some numbers about our tests: we found that more or less that with
more than 500k elements (multiplying rows and columns requested) there was
the inflection point, and so asking for more
Hi Rob,
of course, we could issue multiple requests, but then we should consider
which is the optimal way to split the query in smaller ones. Moreover, we
should choose how many of sub-query run in parallel.
In ours tests, we found there's a significant performance difference
between various
In ours tests, we found there's a significant performance difference
between various configurations and we are studying a policy to optimize it.
The doubt is that, if the needing of issuing multiple requests is caused only
by a fixable implementation detail, would make pointless do this
Hi everybody,
We are working on porting some life science applications to Cassandra, but
we have to deal with its limits managing huge queries. Our queries are
usually multiget_slice ones: many rows with many columns each.
We have seen system start to slower until the entry point node crashes
On Tue, Jul 16, 2013 at 4:46 AM, cesare cugnasco
cesare.cugna...@gmail.comwrote:
We are working on porting some life science applications to Cassandra,
but we have to deal with its limits managing huge queries. Our queries are
usually multiget_slice ones: many rows with many columns each.
