You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by lu...@sohu.com on 2010/03/14 13:34:11 UTC
答复: about lucene in action 2
Thanks very much for your patience!
Nor are the files "sync"'d.?It means something like reading disk file to RAM,so reader can see it?
And why flushing(reopen) is much faster than commit? flushing means writing stuff to disk, commit means writing stuff to disk and then reading the new created disk file("sync ").
I guess commit only cost twice time than flush?
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p> </o:p>
-----邮件原件-----
发件人: Michael McCandless [mailto:lucene@mikemccandless.com]
发送时间: 2010年3月14日 18:14
收件人: java-user@lucene.apache.org
主题: Re: about lucene in action 2
<o:p> </o:p>
Flushing means stuff (added docs, deletions) buffered in RAM are moved to disk, ie, written as new segment files.
<o:p> </o:p>
But the new segments_N file, referencing these new segments, is not written.
<o:p> </o:p>
Nor are the files "sync"'d.
<o:p> </o:p>
This means a newly opened or reopened reader will not see the changes.
<o:p> </o:p>
In order to make the changes "visible" you have to call IndexWriter.commit.
<o:p> </o:p>
Mike
<o:p> </o:p>
On Sun, Mar 14, 2010 at 2:36 AM, luocanrao <luocan19826164@sohu.com> wrote:
> I am reading lucene in action 2,there is some question about it.
><o:p> </o:p>
> When a flush occurs, the writer creates new segment and deletion files
> in the Directory. However, these files are neither visible nor usable
> to a newly opened IndexReader until the writer commits the changes.
> It's important to understand this difference. Flushing is done to free
> up memory consumed by buffered changes to the index, whereas
> committing is done to make all flushed changes persistent and visible
> in the index.
><o:p> </o:p>
> Why Flushing does not make all flushed changes persistent even if it
> had created new segment?
> Flushing does not mean flush any change to disk?
><o:p> </o:p>
><o:p> </o:p>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
><o:p> </o:p>
><o:p> </o:p>
<o:p> </o:p>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: 答复: about lucene in action 2
Posted by Michael McCandless <lu...@mikemccandless.com>.
sync (fsync to the OS) tells the OS to make sure everything associated
with that file is moved to stable storage in the IO system. (It
doesn't read anything back).
On flush we write the files to disk, which is usually very fast since
it writes into the OS's RAM write cache, but we do not sync.
sync (fsync) is in general a costly operation as it forces the OS & IO
subsystem to flush their write caches, journals, etc.
So, only on commit do we sync.
You should measure the cost in practice to see what it works out to be
for your context... it's very OS/filesytem dependent, and also depends
on how many segments your index has when you commit, whether you're
using CFS, etc.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org