lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Rutherglen (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (LUCENE-1313) Realtime Search
Date Wed, 29 Apr 2009 21:25:30 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704340#action_12704340
] 

Jason Rutherglen edited comment on LUCENE-1313 at 4/29/09 2:24 PM:
-------------------------------------------------------------------

A merge policy may be more optimal for ram segments vs disk
segments. Perhaps the best way to make this clean is to keep the
ram merge policy and real dir merge policies different? That way
we don't merge policy implementations don't need to worry about
ram and non-ram dir cases.

Perhaps an IW.updatePendingRamMerges method should be added that
handles this separately? Does the ram dir ever need to worry
about things like maxNumSegmentsOptimize and optimize?

{quote}Right, this is one of the strong reasons to do the
"internal" approach vs "external" one.{quote}

I think having the ram merge policy should cover the reasons I
had for having a separate ram writer. Although the IW.addWriter
method I implemented would not have blocked, but I don't think
it's necessary now if we have a separate ram merge policy.

      was (Author: jasonrutherglen):
    Regarding the MergePolicy, what a particular merge policy is
more optimal the ram segments vs. the real dir segments? Perhaps
the best way to make this clean is to keep the ram merge policy
and real dir merge policies different? That way we don't merge
policy implementations don't need to worry about ram and non-ram
dir cases.

Perhaps an IW.updatePendingRamMerges method should be added that
handles this separately? Does the ram dir ever need to worry
about things like maxNumSegmentsOptimize and optimize?

{quote}Right, this is one of the strong reasons to do the
"internal" approach vs "external" one.{quote}

I think having the ram merge policy should cover the reasons I
had for having a separate ram writer. Although the IW.addWriter
method I implemented would not have blocked, but I don't think
it's necessary now if we have a separate ram merge policy.
  
> Realtime Search
> ---------------
>
>                 Key: LUCENE-1313
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1313
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: Index
>    Affects Versions: 2.4.1
>            Reporter: Jason Rutherglen
>            Priority: Minor
>             Fix For: 2.9
>
>         Attachments: LUCENE-1313.jar, LUCENE-1313.patch, LUCENE-1313.patch, LUCENE-1313.patch,
LUCENE-1313.patch, lucene-1313.patch, lucene-1313.patch, lucene-1313.patch, lucene-1313.patch
>
>
> Realtime search with transactional semantics.  
> Possible future directions:
>   * Optimistic concurrency
>   * Replication
> Encoding each transaction into a set of bytes by writing to a RAMDirectory enables replication.
 It is difficult to replicate using other methods because while the document may easily be
serialized, the analyzer cannot.
> I think this issue can hold realtime benchmarks which include indexing and searching
concurrently.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message