accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From joshelser <>
Subject [GitHub] accumulo issue #180: Taking a crack at new summarization API
Date Mon, 05 Dec 2016 23:52:43 GMT
Github user joshelser commented on the issue:
    (breaking out discussion to top-level instead of rooted on a code change)
    >I created something called SummaryStore in ab8deb7. It generates ~10 summaries for
input data without knowing how many keys will be added beforhand. Uses the approach I mentioned
above of merging summaries. One additional step I discovered I needed to do was double the
number of key/vals per summary each time I merged.
    > So if I have 10 summaries each covering 1000 keys, when I merge to 5 then each of
those represents 2000 keys. So now I want start adding summaries every 2000 keys. Next time
I merge, I will start adding summaries every 4000 keys... etc.
    The [comment I left here](
has really got my brain thinking about how this should look. First, can we design a good API
without defining what a summary is. Or, reworded, can we restrict what a summary is and come
up with a more elegant/efficient implementation.
    When it comes to `merge(Map, Map)`, I'm specifically wondering if we force all `KeyValueSummaries`
to be commutative, can we manage the merging of summaries better? For example, instead of
delegating to the implementation on how these two `Map`s are merged, we then get to merge
them ourselves (because we know how to combine these maps).
    Should a summary ever not be commutative? Does it make sense for us to allow one to not

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message