Initial tests run comparing throughput when first populating and then
loading data into levelled and eleveledb.
The tests were run in series, populating first and then loading. The
population tests were run again in-between to try and add a roughly
even underlying volume into the stores.
The initial tests were run on on a quad core iMac with 8GB of RAM and a
fusion drive. Due to the limited footprint of the hardware, the number
of concurrent database instances was reduced to 12, rather than the 32
in the off0the-shelf leveldb test.
The penciller attempt to close the L0 file if pending was unpredictable
in behaviour. If a L0 file is still pending it will be lost - but this
is at least a predictable event.
This allows for deleted journals to be retained for a period (the
waste_retnetion_period). The idea being that a backup strategy can
ensure that all journals are backed up, even ones created and removed
from within a backup period - so that any restore pont is possible.
This is also a pre-cursor to removing some of the PromptDelete
complexity from the Inker Clerk - all compactions can prompt deletion as
deletion is now deferred.
Add nonsense tests for nonsense coverage on standard methods.
Look at CDB search_hash_table - looks like it doubled-up on break-outs
so that one would never get hit
Leveled will now signal the need for a pause due to back-pressure, but
not actually pause itself. The hope is that in a riak implementation
this pause can be managed by the put_fsm, and so not lock the store.
Clena the API of Riak specific methods, and also resolve timing issue in
simple_server unit test. Previously this would end up with missing data
(and a lower sequence number after start) because of the penciller_clerk
timeout being relatively large in the context of this test. Now the
timeout has bene reduced the L0 slot is cleared by the time of the
close. To make sure an extra sleep has been added as a precaution to
avoid any intermittent issues.
