On 31 Jul 2013, at 12:33, Manik Surtani <msurtani(a)redhat.com> wrote:
On 31 Jul 2013, at 08:22, Radim Vansa <rvansa(a)redhat.com>
wrote:
>>>
>>> I noticed that is neither a log structured nor a b/b+ tree implementation and
it lacks compaction. Maybe it is elsewhere or I simply missed it?
>
> No, the storage does not need any search structure as it keeps all keys
> with entry position in-memory, what is its major drawback.
And also one of its major benefits. Reading an entry off disk is very quick, since the
entry position is in memory. Think of it as a DB index.
LevelDB also has a concept of holding entry positions in an index, only that it keeps the
position index in memory up to a predefined size, after which it persists the position
index to disk. That may mean two disk reads for a single entry, but still proves to be
fairly efficient.
Nice idea. We can add this at a further point, one SFCS prove itself.
Cheers,
--
Mircea Markus
Infinispan lead (
www.infinispan.org)