Github user joshelser commented on the issue:
https://github.com/apache/accumulo/pull/180
(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](https://github.com/apache/accumulo/commit/ab8deb76ef96602d27072ce913ee90434bb9c246#commitcomment-20080483)
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 be?
---
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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
