<div dir="ltr">I suspect with the test environment having only 4GB of RAM and a single slow disk per node - both Leveldb and Leveled are going to struggle in terms of the write throughput.  As n=1 in this test, some of the advantages of Leveled will be lost also (e.g. the n HEADs advantage).<div><br></div><div>I thought the paper was really interesting though.  It highlights an area of riak performance - merge effectiveness - that is not often discussed.  I've ignored merge effectiveness as a measure between leveldb and leveled, but it is an area where leveldb is currently notably better (and may well be better than Bitcask).  </div><div><br></div><div>As DeadZen mentioned having awareness of file system space is interesting.  The "fisherman's algorithm" approach mentioned in the paper is a neat, I've not thought about having a "Target Usage Level" - and I think this is potentially a better way of tuning a backend merge process.  I will try and put some effort in writing up the approach to tuning merge effectiveness that is implemented in leveled sometime soon for comparison.  </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 3 October 2017 at 17:32, DeadZen <span dir="ltr"><<a href="mailto:deadzen@deadzen.com" target="_blank">deadzen@deadzen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This looks cool, and might give some indication that back pressure<br>
should be aware of available file system space..<br>
Any plans on LevelDB testing? A newer option Leveled might be cool to<br>
compare with as well.<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Oct 3, 2017 at 6:58 AM, Grigory Fateyev <<a href="mailto:gfborn@gmail.com">gfborn@gmail.com</a>> wrote:<br>
> Yury, thank you for sharing your investigations. It is very useful to read!<br>
><br>
> 2017-10-03 8:32 GMT+03:00 Yury Shevchuk <<a href="mailto:sizif@botik.ru">sizif@botik.ru</a>>:<br>
>><br>
>> Greetings!<br>
>><br>
>> We have published a paper on the subject.  It may be of interest for<br>
>> Riak developers and users who put Riak under heavy write load.<br>
>><br>
>>   English: <a href="http://psta.psiras.ru/read/psta2017_3_61-85.pdf" rel="noreferrer" target="_blank">http://psta.psiras.ru/read/<wbr>psta2017_3_61-85.pdf</a><br>
>>   Russian (native): <a href="http://psta.psiras.ru/read/psta2017_3_31-60.pdf" rel="noreferrer" target="_blank">http://psta.psiras.ru/read/<wbr>psta2017_3_31-60.pdf</a><br>
>><br>
>> Best,<br>
>><br>
>><br>
>> -- Yury<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> riak-users mailing list<br>
>> <a href="mailto:riak-users@lists.basho.com">riak-users@lists.basho.com</a><br>
>> <a href="http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com" rel="noreferrer" target="_blank">http://lists.basho.com/<wbr>mailman/listinfo/riak-users_<wbr>lists.basho.com</a><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> riak-users mailing list<br>
> <a href="mailto:riak-users@lists.basho.com">riak-users@lists.basho.com</a><br>
> <a href="http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com" rel="noreferrer" target="_blank">http://lists.basho.com/<wbr>mailman/listinfo/riak-users_<wbr>lists.basho.com</a><br>
><br>
<br>
______________________________<wbr>_________________<br>
riak-users mailing list<br>
<a href="mailto:riak-users@lists.basho.com">riak-users@lists.basho.com</a><br>
<a href="http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com" rel="noreferrer" target="_blank">http://lists.basho.com/<wbr>mailman/listinfo/riak-users_<wbr>lists.basho.com</a><br>
</div></div></blockquote></div><br></div>

<br>
<div><font face="Arial" size="1">***** Email confidentiality notice *****</font></div><div><font face="Arial" size="1">This message is private and confidential.  If you have received this message in error, please let us know and remove it from your system.</font></div>