Hi all,
Thanks for all for the info.
I think Nates suggestion was what I was trying to articulate in my question.
Just to confirm:
So if I add a timeuuid as a row level primary key and reverse the
clustering, so its stored newest first. I can query it by just the partion
key with a limit of 1.
You could turn gc_grace_seconds down to zero and tune compaction options
for this CF to keep the tombstone count down.
But...
This query looks a lot like a ledger. If that is so, treat it as such and
skip the updates by:
- modifying the schema to include a timeuuid as part of a compound key (and
Charlie,
I would be willing to help you out with your issues tomorrow afternoon, feel
free to give me a call after 4m ET. There are lots of people who store *and*
update data with cassandra (at scale).
--
Colin Clark | Solutions Architect
DataStax | www.datastax.com
m | +1-320-221-9531
e
On Sun, May 25, 2014 at 12:01 PM, Charlie Mason wrote:
> I have a table which has one column per user. It revives at lot of updates
> to these columns through out the life time. They are always updates on a
> few specific columns Firstly is Cassandra storing a Tombstone for each of
> these old col
Hi All,
I have a table which has one column per user. It revives at lot of updates
to these columns through out the life time. They are always updates on a
few specific columns Firstly is Cassandra storing a Tombstone for each of
these old column values.
I have run a simple select and seen the fo
