Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-user@lucene.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4FF2A732.30109@codemium.com>
References: <4FF2A732.30109@codemium.com>
From: Michael McCandless <lucene@mikemccandless.com>
Date: Tue, 3 Jul 2012 08:40:14 -0400
Message-ID: 
 <CAL8PwkYyNbdm8xf925CN2z5JWJDj8Wyy7u-=9dLvWtm-aQ6UBA@mail.gmail.com>
Subject: Re: Near Real Time Indexing and Searching with solr 3.6
To: solr-user@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Hi,

You might want to take a look at Solr's trunk (very soon to be 4.0.0
alpha release), which already has a near-real-time solution (using
Lucene's near-real-time APIs).

Lucene has NRTCachingDirectory (to use RAM for small / recently
flushed segments), but I don't think Solr uses it yet.

Mike McCandless

http://blog.mikemccandless.com

On Tue, Jul 3, 2012 at 4:02 AM, thomas <thomas@codemium.com> wrote:
> Hi,
>
> As part of my bachelor thesis I'm trying to archive NRT with Solr 3.6. I've
> came up with a basic concept and would be trilled if I could get some
> feedback.
>
> The main idea is to use two different Indexes. One persistent on disc and
> one in RAM. The plan is to route every added and modified document to the
> RAMIndex (http://imgur.com/kLfUN). After a certain period of time, this
> index would get cleared and the documents get added to the persistent Index.
>
> Some major problems I still have with this idea is:
> - deletions of documents from documents in the persistent index
> - having the same unique IDs in both the RAM index and persitent Index, as a
> result of an updated document
>   - Merging search results to filter out old versions of updated documents
>
> Would such an idea be viable to persuit?
>
> Thanks for you time
>