I understood it as a run trigger when column gets deleted due to TTL,
so - as you said - it doesn't sound like something that can be done.
Gareth, TTL'd columns in Cassandra are not really removed after TTL -
they are just ignored from that time (so they're not returned by
queries), but they
Edward, Michal,
Thanks very much for the answers. I hadn't really thought before about how
Cassandra would implement the TTL feature. I had foolishly assumed that it
would be like a delete (which I would eventually be able to trigger on to
execute another action) but it makes sense how it is
Dne 13.6.2013 8:19, Michal Michalski napsal(a):
It could be doable to do something when they get converted to
tombstone, but I don't think it's the use case you're looking for.
actually, this would be good enough for me
Hi Cassandra community,
we are currently experimenting with different Cassandra scaling
strategies. We observed that Cassandra performance decreases
drastically when we insert more data into the cluster (say, going from
60GB to 600GB in a 3-node cluster). So we want to find out how to deal
with
We want to precalculate counts for some common metrics for usage. We have
events, locations, products, etc. The problem is we have millions
events/day, thousands of locations and millions of products.
Were trying to precalculate counts for some common queries like 'how many
times was product X
After a few months of development and many preview releases cql-rb, the
pure Ruby CQL3 driver has finally reached v1.0.
You can find the code and examples on GitHub:
https://github.com/iconara/cql-rb
T#
Hi!
We have a similar situation of millions of events on millions of items - turns
out that this isn't really a problem, because there tends to be a very strong
power -distribution: very few of the items get a lot of hits, some get some,
and the majority gets no hits (though most of them do
On Thu, Jun 13, 2013 at 10:47 AM, Markus Klems markuskl...@gmail.com wrote:
One scaling strategy seems interesting but we don't
fully understand what is going on, yet. The strategy works like this:
add new nodes to a Cassandra cluster with auto_bootstrap = false to
avoid streaming to the new
Robert,
thank you for your explanation. I think you are right. YCSB probably
does not correctly interpret the missing record response. We will
look into it and report our results here in the next days.
Thanks,
Markus
On Thu, Jun 13, 2013 at 9:47 PM, Robert Coli rc...@eventbrite.com wrote:
On
For the ones that need access by public IP we have not found a way to automate
it. Would be curious to know if anyone else has been able to that.
In the case of access by private IP we just specify security group as the
source.
From: Alain RODRIGUEZ [mailto:arodr...@gmail.com]
Sent: Wednesday,
CL.ONE requests for rows which do not exist are very fast.
http://adrianotto.com/2010/08/dev-null-unlimited-scale/
On Thu, Jun 13, 2013 at 3:47 PM, Robert Coli rc...@eventbrite.com wrote:
On Thu, Jun 13, 2013 at 10:47 AM, Markus Klems markuskl...@gmail.com
wrote:
One scaling strategy
On Thu, Jun 13, 2013 at 11:20 PM, Edward Capriolo edlinuxg...@gmail.com wrote:
CL.ONE requests for rows which do not exist are very fast.
http://adrianotto.com/2010/08/dev-null-unlimited-scale/
Yep, /dev/null is a might force ;-)
I took a look at the YCSB source code and spotted the line of
12 matches
Mail list logo
