accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-2883) Add API method(s) that support fetching currently assigned locations for tablets
Date Thu, 06 Nov 2014 19:01:34 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14200666#comment-14200666
] 

Christopher Tubbs commented on ACCUMULO-2883:
---------------------------------------------

It should also be mentioned that we already have public API for getting split points. This
feature adds no additional security concerns about data leakage, unless we consider the location
of the data to be additionally sensitive, and I can't imagine why we should, since the whole
point of Accumulo is to manage and reveal that information to a client, so it can efficiently
query from the distributed system. If you don't want to reveal the location of a tablet, Accumulo
(and the whole BigTable model) is not your solution (at least, not without an intermediate:
proxy or web service).

> Add API method(s) that support fetching currently assigned locations for tablets
> --------------------------------------------------------------------------------
>
>                 Key: ACCUMULO-2883
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-2883
>             Project: Accumulo
>          Issue Type: Sub-task
>          Components: client
>            Reporter: Josh Elser
>             Fix For: 1.7.0
>
>
> TabletLocator already exists, but isn't officially a part of the "public API" and is
clunky for users to invoke. In trying to co-locate external processes with the tabletservers
that are hosting some data, it would be nice to have some means that users can invoke that
will return them these assignments.
> Memory concerns are an issue for tables with many splits (e.g. avoiding creating a Set
of 100k tablet locations for a table), but we also want to provide the ability to ask pointed
questions. Likely building something that accepts a Range (or Collection<Range>) would
be best.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message