sure, SSD or RAM disks fix these problems with IO. Anyhow, I can really see no alternative for some in memory index for slaves, especially for low latency master-slave apps (high commit rate is a problem).
having possibility to run slaves in memory that are slurping updates from Master seams to me like a preffered method (you need no twiddling with OS, just CPU and RAM is what you need for your slaves, run slave and point it to master ). I assume that update propagation times could be better by having some sexy ReadOnlySlaveRAMDirectorySlurpingUpdatesFromTheMaster that does reload() directly from the Master (maybe even uncommitted, somehow NRT-likish). Point being, lower latency update than current 1-5 Minutes (wiki recommended values) is not going to be possible with current master-slave solution, due to the nature of it (commit to disk on master, copy delta to slave disk, reload...) This is a lot of ping pong... ES and solandra are by nature better suited if you need update propagation in seconds range. It is just thinking aloud, and slightly off-topic... solr/lucene as it is today, rocks anyhow. On Wed, Jun 29, 2011 at 10:55 AM, Toke Eskildsen <t...@statsbiblioteket.dk> wrote: > On Wed, 2011-06-29 at 09:35 +0200, eks dev wrote: >> In MMAP, you need to have really smart warm up (MMAP) to beat IO >> quirks, for RAMDir you need to tune gc(), choose your poison :) > > Other alternatives are operating system RAM disks (avoids the GC > problem) and using SSDs (nearly the same performance as RAM). > >
