incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Kallen <spidaman.l...@gmail.com>
Subject Re: pagination through slices with deleted keys
Date Thu, 06 May 2010 22:27:26 GMT
Cool, is this a patch you've applied on the server side? Are you running
0.6.x? I'm wondering if this kind of thing can make it into future versions
of Cassandra.
-Ian

On Thu, May 6, 2010 at 2:56 PM, Mike Malone <mike@simplegeo.com> wrote:

> Our solution at SimpleGeo has been to hack Cassandra to (optionally, at
> least) be sensible and drop Rows that don't have any Columns. The claim from
> the FAQ that "Cassandra would have to check if there are any other columns
> in the row" is inaccurate. The common case for us at least is that we're
> only interested in Rows that have Columns matching our predicate. So if
> there aren't any, we just don't return that row. No need to check if the
> entire row is deleted.
>
> Mike
>
>
> On Thu, May 6, 2010 at 9:17 AM, Ian Kallen <spidaman.list@gmail.com>wrote:
>
>> I read the DistributedDeletes and the range_ghosts FAQ entry on the wiki
>> which do a good job describing how difficult deletion is in an eventually
>> consistent system. But practical application strategies for dealing with it
>> aren't there (that I saw). I'm wondering how folks implement pagination in
>> their applications; if you want to render N results in an application, is
>> the only solution to over-fetch and filter out the tombstones? Or is there
>> something simpler that I overlooked? I'd like to be able to count (even if
>> the counts are approximate) and fetch rows with the deleted ones filtered
>> out (without waiting for the GCGraceSeconds interval + compaction) but from
>> what I see so far, the burden is on the app to deal with the tombstones.
>>  -Ian
>>
>
>

Mime
View raw message