accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Newton (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-4022) Create a concept of multi-homed tablets
Date Thu, 08 Oct 2015 14:21:26 GMT


Eric Newton commented on ACCUMULO-4022:

Some thoughts:

* multiple servers would be available for *query* since there's still only one writer
* for some applications, inconsistency in recent reads and bulk imports might be perfectly
* some tables are read-only: they don't have updates to worry about
* the write-ahead log is normally *always* flushed. I think you mean in-memory data flushed
to a tablet-specific file.
* one could create a "sync" command, to force read-only tablets to re-load their file list,
and optionally read the mutations from the writable server

> Create a concept of multi-homed tablets
> ---------------------------------------
>                 Key: ACCUMULO-4022
>                 URL:
>             Project: Accumulo
>          Issue Type: Wish
>          Components: client, tserver
>            Reporter: marco polo
>              Labels: newbie, performance
> I'm an accumulo newbie, but I wish to see the concept of multi-homed tablets. This allows
us to have tablets hosted by multiple servers, with only one being writable against it. This
concept would allow n receiver servers for a tablet. An example might be a tablet that has
become a hot spot could be dynamically hosted elsewhere, and clients could pick this up as
a potential. Consistency must be kept between the hosts, as the initial read/write host may
compact or write to that tablet. 
> To me the larger problem may come from live ingest in which the write ahead log has not
been flushed. To avoid having to write to the read only servers in a pipeline, we would likely
need to create a model of enforcing reads only after a flush of that tablet or a thrift interface
to allow reading only the data in memory to ensure consistency is enforced. I haven't given
great thought to solving this yet. 
> Please comment with ideas and pitfalls as I would like to see this wish come to fruition
with actionable tickets after some community thought.

This message was sent by Atlassian JIRA

View raw message