12:36 p.m.
http://antirez.com/post/redis-persistence-demystified.html
Anyone interested in writing a cachestore following these rules?
12:47 p.m.
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 <emmanuel(a)hibernate.org> wrote:
http://antirez.com/post/redis-persistence-demystified.html
Anyone interested in writing a cachestore following these rules?
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
4:07 a.m.
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 <emmanuel(a)hibernate.org> wrote:
> http://antirez.com/post/redis-persistence-demystified.html
>
> Anyone interested in writing a cachestore following these rules?
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
4939
days inactive
4940
days old
infinispan-dev@lists.jboss.org
2 comments
3 participants
participants (3)
-
Emmanuel Bernard -
Manik Surtani -
Sanne Grinovero