[
https://issues.apache.org/jira/browse/ACCUMULO-4500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15590341#comment-15590341
]
Christopher Tubbs commented on ACCUMULO-4500:
---------------------------------------------
That was just a quick mock-up, not the actual suggested implementation. That
mock-up wouldn't work anyway, because it's actually a list of Longs to map to a
Long. But, then there's also the question... should this function be able to
change behavior based on the counter name? Should it be able to emit new
counters (like a many-to-many transformation) or just reduce?
I don't know if we could do serialized lambdas or if we'd have to pass the
class name, but you're right: The aggregation function will need to be
available on both the client and the server side, because some aggregation
might occur within the tserver, and some between tservers in the client. Maybe
those should be two separate aggregation opportunities? Should our API only
reflect in-cluster aggregation, and client code has to do its own cross-tserver
aggregation because we'll just provide a stream?
I don't know. I just know it'd be nice to put some serious thought into what
any new API is going to look like... and based on a solid understanding of what
features we're trying to provide at the most basic level.
> Implement visibility histograms as a table feature
> --------------------------------------------------
>
> Key: ACCUMULO-4500
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4500
> Project: Accumulo
> Issue Type: New Feature
> Components: client, tserver
> Reporter: Josh Elser
>
> Add support to quickly extract a histogram of all of the visibilities stored
> in an Accumulo table.
> DISCUSS:
> https://lists.apache.org/thread.html/df5e764362a95277344fd2731a432e9fafc60595e7d30015d9a56b9c@%3Cdev.accumulo.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
