In the future you may find SASI indexes useful for indexing Cassandra data.
Shameless blog post plug:
http://rustyrazorblade.com/2016/02/cassandra-secondary-index-preview-1/
Deep technical dive: http://www.doanduyhai.com/blog/?p=2058
On Thu, Aug 4, 2016 at 11:45 AM Kevin Burton
BTW. we think we tracked this down to using large partitions to implement
inverted indexes. C* just doesn't do a reasonable job at all with large
partitions so we're going to migrate this use case to using Elasticsearch
On Wed, Aug 3, 2016 at 1:54 PM, Ben Slater
Yep, that was what I was referring to.
On Thu, 4 Aug 2016 2:24 am Reynald Bourtembourg <
reynald.bourtembo...@esrf.fr> wrote:
> Hi,
>
> Maybe Ben was referring to this issue which has been mentioned recently on
> this mailing list:
> https://issues.apache.org/jira/browse/CASSANDRA-11887
>
>
Have you tried using the G1 garbage collector instead of CMS?
We had the same issues that things were normally fine, but as soon as
something extraordinary happened, a node could go into GC hell and never
recover, and that could then spread to other nodes as they took up the
slack, trapping them
We usually use 100 per every 5 minutes.. but you're right. We might
actually move this use case over to using Elasticsearch in the next couple
of weeks.
On Wed, Aug 3, 2016 at 11:09 AM, Jonathan Haddad wrote:
> Kevin,
>
> "Our scheme uses large buckets of content where we
Kevin,
"Our scheme uses large buckets of content where we write to a
bucket/partition for 5 minutes, then move to a new one."
Are you writing to a single partition and only that partition for 5
minutes? If so, you should really rethink your data model. This method
does not scale as you add
Hi,
Maybe Ben was referring to this issue which has been mentioned recently
on this mailing list:
https://issues.apache.org/jira/browse/CASSANDRA-11887
Cheers,
Reynald
On 03/08/2016 18:09, Romain Hardouin wrote:
>Curious why the 2.2 to 3.x upgrade path is risky at best.
I guess that upgrade