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