On 31 Jul 2013, at 12:33, Manik Surtani <msurt...@redhat.com> wrote:

> On 31 Jul 2013, at 08:22, Radim Vansa <rva...@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)





_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Reply via email to