Lucene.Net 4.8 Directory question

[Monica Black <ml...@hotmail.com>]

Hi Lucene Devs.
I am using Lucene again after many years for data caching in an application where we didn't want a lot of components to install.  It's really quite perfect for this.
The question I have is how best to approach the use of directories, indices, and searchers.
My cache is structured with a Lucene cache per subdirectory (lowest leaves only) like so:-Address Type 1----AK----AL----AR.....
-Address Type 2----AK----AL----AR.....
and so on for each US State.
The bad thing about this type of cache breakdown is that I need one FSDirectory for each of two address types per US State--that's a lot of FSDirectories.  I notice the FSDirectory is very slow to open.  
This will be a library called from another application, so I have no way to know how many queries the application would need per cache.  What do you suggest to avoid this slow opening of FSDirectory over and over?
Thanks,Monica 		 	   		  

Re: Lucene.Net 4.8 Directory question

[Itamar Syn-Hershko <it...@code972.com>]

Monica, this doesn't sound like the right usage for Lucene. Why won't you
create one index (one FSDirectory) and just separate documents by a
directory field?

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Lucene.NET committer and PMC member

On Mon, Oct 24, 2016 at 8:34 PM, Monica Black <ml...@hotmail.com> wrote:

> Hi Lucene Devs.
> I am using Lucene again after many years for data caching in an
> application where we didn't want a lot of components to install.  It's
> really quite perfect for this.
> The question I have is how best to approach the use of directories,
> indices, and searchers.
> My cache is structured with a Lucene cache per subdirectory (lowest leaves
> only) like so:-Address Type 1----AK----AL----AR.....
> -Address Type 2----AK----AL----AR.....
> and so on for each US State.
> The bad thing about this type of cache breakdown is that I need one
> FSDirectory for each of two address types per US State--that's a lot of
> FSDirectories.  I notice the FSDirectory is very slow to open.
> This will be a library called from another application, so I have no way
> to know how many queries the application would need per cache.  What do you
> suggest to avoid this slow opening of FSDirectory over and over?
> Thanks,Monica

Re: Lucene.Net 4.8 Directory question

["Koga, Diego" <di...@gmail.com>]

Hi Monica,

I don't have much experience using Lucene but as far as I can see, I would
create a singleton to manage it.

As soon as you create the instance, open the directory and keep it open for
a while. You can create a mechanism to dispose it after its been idle for X
minutes/hours.

Also if you need to update while it is being used, you can create new
index, halt the requests on the old one, change the directory to point to
the new one and release the requests. So, there is no downtime, only a leg
instead.


Hope it helps.




Att.,
------------------
Koga, Diego

On Mon, Oct 24, 2016 at 1:34 PM, Monica Black <ml...@hotmail.com> wrote:

> Hi Lucene Devs.
> I am using Lucene again after many years for data caching in an
> application where we didn't want a lot of components to install.  It's
> really quite perfect for this.
> The question I have is how best to approach the use of directories,
> indices, and searchers.
> My cache is structured with a Lucene cache per subdirectory (lowest leaves
> only) like so:-Address Type 1----AK----AL----AR.....
> -Address Type 2----AK----AL----AR.....
> and so on for each US State.
> The bad thing about this type of cache breakdown is that I need one
> FSDirectory for each of two address types per US State--that's a lot of
> FSDirectories.  I notice the FSDirectory is very slow to open.
> This will be a library called from another application, so I have no way
> to know how many queries the application would need per cache.  What do you
> suggest to avoid this slow opening of FSDirectory over and over?
> Thanks,Monica