accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Hickey (JIRA)" <>
Subject [jira] [Updated] (ACCUMULO-802) table namespaces
Date Fri, 21 Jun 2013 19:31:20 GMT


Sean Hickey updated ACCUMULO-802:

    Attachment: ACCUMULO-802.v0.patch

Patch for an initial implementation of table namespaces. It's probably not ready for commit,
but I wanted everyone to be able to test it out first. In the README, I documented how it
works and how some of the features will work once implemented. I also went through the TableOperations
interface and described the changes in behavior to the functions if they are given an namespace
(denoted with a ".*") as opposed to a table. I also noted functions that might have a possibility
of being implemented in a namespace-wide manner, but I would like input on how they should

Here's a quick example of how they work.
A table's namespace is denoted as part of it's name (unless it's in the default namespace),
so two tables called "" and "thing.two" would both be in the "thing" namespace. To
perform a namespace-wide operation, use ".\*". For example, you could delete all tables in
a namespace (and the namespace itself) by deleting a table called "thing.*", which from before
would delete "", "thing.two", and it would delete the "thing" namespace.
> table namespaces
> ----------------
>                 Key: ACCUMULO-802
>                 URL:
>             Project: Accumulo
>          Issue Type: New Feature
>            Reporter: Eric Newton
>            Assignee: Sean Hickey
>             Fix For: 1.6.0
>         Attachments: ACCUMULO-802.v0.patch, table-namespaces-README.txt
> A large cluster is a valuable shared resource.  The current permission system and simple
table naming structure does not allow for delegation of authority and safe partitioning within
this shared resource.
> Use cases:
>  # create a namespace (like "test") and delegate the {{grant}} permission to tables created
in that namespace to a user that would manage those tables. Presently, {{grant}} is never
>  # create simple "test" and "production" namespaces that are trivial for users to switch
between.  For example, instead of having tables "test_index" and "test_documents" the client
would support "index" and "documents" with an API to support switching trivially between the
the different environments.
>  # create a set of tables in a namespace called "latest"  This namespace is re-created
periodically with a map-reduce job.  If code changes inadvertently create a corrupt "latest,"
users can switch to the set of tables known as "safest"  In this way, users can experiment,
and provide feedback on incremental improvements, while have a safe fallback.
>  # two applications hosted on the same cluster that can share a table, which has been
"aliased" into their namespace.  Namespace-local permissions are ignored, but a (most likely
read-only) view of the table is available.  This would be helpful for reference tables.
>  # quotas/priorities.  Implement namespace-specific priorities and resource allocations.
 It is reasonable to run namespace-specific queries and ingest on production equipment. Large
cluster resources are always limited, and often the *only* place where near-production quality
software can be run at full scale.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message