Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # user >> 'Redundant' mutations


Copy link to this message
-
Re: 'Redundant' mutations
On Thu, Feb 9, 2012 at 9:47 AM, Aaron Cordova <[EMAIL PROTECTED]> wrote:
> You get "a"
>
> By default tables are configured with a "versioning iterator" that filters out all but the latest "version" of a key, meaning the key with the latest timestamp, which provides the cleaning out of redundant keys that differ only in timestamp behavior you describe

I understood that the default was only to see the latest, but does
disk space remain consumed with older ones until something happens, or
does it clean out itself?
.
>
>
> On Feb 9, 2012, at 9:43 AM, Benson Margulies wrote:
>
>> At time 0, I make a Mutation with put("a", "b", "c");
>>
>> At time 1, I do it again.
>>
>> Do I get:
>>
>> a) two copies of the same data with different timestamps?
>>
>> b) an error?
>>
>> c) something else?
>>
>> If the idea I'm looking for is to end up with one item without doing a
>> scan each time to see if it's out there, is there a 'garbage
>> collection' cliche for cleaning out redundant items that differ only
>> in timestamp?
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB