Thanks for the info Sean and Russell!
On Fri, Nov 14, 2014 at 2:42 PM, Russell Brown wrote:
> Hi,
> Sorry to say that Maps are just riak objects underneath, so the same size
> limit applies. Anything over 1mb and you'll start to feel the pain.
>
> Cheers
>
> Russell
>
> On 14 Nov 2014, at 19:34,
Hi Mark,
Currently maps are contained in a single key. The same warnings we give for
value sizes in regular KV apply; however, the map has additional contained
metadata that will give an approximately linear overhead (per-embedded
type) to the object.
If you can constrain the various domains of y
Hi,
Sorry to say that Maps are just riak objects underneath, so the same size limit
applies. Anything over 1mb and you'll start to feel the pain.
Cheers
Russell
On 14 Nov 2014, at 19:34, Mark Rechler wrote:
> Hi Everyone,
>
> I'm curious if anyone has had experience using maps as containers
Hi Everyone,
I'm curious if anyone has had experience using maps as containers for
a large amount of data.
Are there any inherent size limits for maps? Could you put sets
equivalent to several gigabytes of data into one map? I'd also be
curious as to the performance impact of deleting said map. W
Small correction, thanks to Steve Vinoski: term_to_binary is reduction-counted
and interruptible since R16, and so shouldn't cause scheduler issues anymore.
Sean Cribbs
> On Feb 21, 2014, at 5:05 PM, Sean Cribbs wrote:
>
> Hi Alex,
>
> We're not yet certain of all the performance characterist
Hi Alex,
We're not yet certain of all the performance characteristics of our
datatypes to give general recommendations. In order to head some of this
off at the pass we have added a bunch of metrics around them[1], including
actor-count and merge time. Of course, the general recommendations about
Hey Gang,
I'm pretty excited about the new CRDT support coming in the next release.
Although counters are already out, I haven't seen much in the way of
performance guidelines. Where counters are a fold/merge/sum type of deal with
some kind of reasonably bounded size based on update frequency,
