Think of an object with thousands of siblings. That's an object that has 1 copy of the data for each sibling. That object could be on the order of 100s of megabytes. Everytime an object is read off disk and returned to the client 100mb is being transferred. Furthermore leveldb must rewrite the entire 100mb to disk everytime a new sibling is added. And it just got larger with that write. If a merge occurs, the amount of data is a single copy of the data at that key instead of what ammounts to approximately 10000 copies of the same sized data, when all you care about is one of those 10,000.
-Andrew On Fri, Dec 20, 2013 at 5:41 PM, Jason Campbell <xia...@xiaclo.net> wrote: > > ------------------------------ > *From: *"Sean Cribbs" <s...@basho.com> > *To: *"Jason Campbell" <xia...@xiaclo.net> > *Sent: *Saturday, 21 December, 2013 3:17:57 AM > > *Subject: *Re: May allow_mult cause DoS? > > > No, the behavior in LevelDB is no different than the behavior of any of > our other backends, namely, all siblings occupy the same key. Every write > involves a fetch from the backend so that the existing value can be > superseded by or merged with the incoming write. > > I'm confused then, why is reading hundreds or thousands of siblings a > problem if they are stored in the same object anyway? What is the > difference between reading a large number of siblings and a merged object? > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > >
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
