Hey Daniel,
I wanted to know a little bit more about using withoutFetch() option when
> used with levelDB.
> I'm trying to write to a single key as fast as I can with n=3.
> I deliberately create siblings by writing with stale vclock.
> ...
> During the test I see activity on the on disk via iostat and it's between
> 20-30 MB/s on each node.
> Even taking into account multiple copies and overhead of Riak (vclocks etc)
> this seems to be pretty high rate.
> I don't see any read activity which suggest withoutFetch() works as
> expected.
> After 2 mins of tests leveldb on each node is 250MB is size, before test
> (11MB)
> Am I using it incorrectly?
Is writing in this way to a single key a good idea or will I be bitten by
> something?
> How to explain high number of MB written to disks?
We call this problem a "hot key".
When you write with a stale vclock, it will generate a new sibling every
time.
For example the first time you store your object it's just "{v1}", the next
time it will get a sibling: "{v1, v2}", eventually it's "{v1,...v1000}"
since the siblings are never resolved. That data is read, updated, old
version tombstoned, and the new data written with every PUT. Based on your
info I would see about 250MB raw data there if LevelDB hasn't compacted the
tombstones away.
RiakObject.withoutFetch() tells your java client to store data without
fetching the most current value first. During that fetch, it would resolve
siblings before writing the value back. You may get better throughput by
resolving your siblings (less writes overall), or by rethinking your data
model so you're not always writing to the same key repeatedly. Is this
just a benchmark or are you modeling something in your application?
Thanks,
Alex
On Wed, May 13, 2015 at 11:03 AM, Daniel Iwan <iwan.dan...@gmail.com> wrote:
> We are using Java client 1.1.4.
> We haven't moved to newer version of Riak as as for the moment we don't
> need
> any new features.
> Also roll out of the new version may be complicated since we have multiple
> clusters.
>
> As with regards to object size its ~250-300 bytes per write. We store
> simple
> JSON structures.
>
> Is there anything in new versions that would limit size of data going to
> the
> disk?
> And more importantly is there a way of determining why levelDB grows so
> big?
>
> I'm using ring size 128 which is probably too high at the moment, but after
> switching to 64 not much has changed.
> I also disabled 2i indexes that I thought may matter (four 16 bytes fields)
> and that did not made any difference, still 25-38MB/s write to level db per
> node.
>
> D.
>
>
>
> --
> View this message in context:
> http://riak-users.197444.n3.nabble.com/Clarifying-withoutFetch-with-LevelDB-and-tp4033051p4033053.html
> Sent from the Riak Users mailing list archive at Nabble.com.
>
> _______________________________________________
> 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
