Yes we have an open JIRA for this. Some of the ideas we should look into are, as you say, Lucene or Cassandra-like fast append-only with compacting.
https://issues.jboss.org/browse/ISPN-517 Please add any thoughts to this JIRA - I was actually going to propose a quick IRC session next week to discuss ideas around this. On 26 Mar 2012, at 18:47, Sanne Grinovero wrote: > I definitely agree we should do that, our current performance on the > FS CacheLoader is not very interesting.. ok it has never been a > priority, still it shouldn't be hard writing one following these basic > principles. > > As I suggested in London a while ago, we could learn from Lucene as > well: uso NIO or MMAP, and the basic rule is to never "change" > existing segments but rewrite optimal ones in a new file, then swap > them atomically and delete the old one. > > As antirez states too, that allows you to take good performance even > from rotating-platter disks. Actually I'm told that rotating disks can > still be faster than SSDs on continual writes/reads, as long as you > don't have it change the head position.. for Infinispan that means > that ideally it should not perform Cache *load* operations from the > same drive. > > > On 26 March 2012 18:36, Emmanuel Bernard <[email protected]> wrote: >> http://antirez.com/post/redis-persistence-demystified.html >> >> Anyone interested in writing a cachestore following these rules? >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani [email protected] twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
