multiple temporary indexes

[graham <gr...@theseamans.net>]

Hi,

I'm a complete newbie and currently at the stage of wondering whether
Solr might be suitable for what I want.

I need to take search results collected by another system in response to
user requests and allow each user to view their set of results in
different ways: sorting into different order, filtering by facets, etc.

I am wondering whether it would be practical to do this by creating a
Solr index for each result set on the fly. Two particular questions are:

1. Is it even practical to do this in real time? Assuming that each set
of results contains low hundreds of elements (each a bibliographic
record), and that the users' patience is not unlimited.

2. What would be the best way to manage a separate index for each query,
given that the main constraint is time, and that the number of indexes
needed simultaneously is not known in advance? Create a separate core
for each query, or use a single index with a query id as one of the
keys, or..?

Thanks for any advice (or pointers to existing systems which work like
this)

Graham

Re: multiple temporary indexes

[graham <gr...@theseamans.net>]

Could be, but I had been assuming I would need to delete each result set
at the end of the users' sessions to stop the index growing and indexing
time growing with it, which would probably rule out complete statistics.

Graham

On 12/20/11 11:58, Chantal Ackermann wrote:
> 
> You could also create a single index and use a field "user" to filter
> results for only a single user. This would also allow for statistics
> over the complete base.
> 
> Chantal
> 
> 
> 
> On Tue, 2011-12-20 at 12:43 +0100, graham wrote:
>> Hi,
>>
>> I'm a complete newbie and currently at the stage of wondering whether
>> Solr might be suitable for what I want.
>>
>> I need to take search results collected by another system in response to
>> user requests and allow each user to view their set of results in
>> different ways: sorting into different order, filtering by facets, etc.
>>
>> I am wondering whether it would be practical to do this by creating a
>> Solr index for each result set on the fly. Two particular questions are:
>>
>> 1. Is it even practical to do this in real time? Assuming that each set
>> of results contains low hundreds of elements (each a bibliographic
>> record), and that the users' patience is not unlimited.
>>
>> 2. What would be the best way to manage a separate index for each query,
>> given that the main constraint is time, and that the number of indexes
>> needed simultaneously is not known in advance? Create a separate core
>> for each query, or use a single index with a query id as one of the
>> keys, or..?
>>
>> Thanks for any advice (or pointers to existing systems which work like
>> this)
>>
>> Graham
> 

Re: multiple temporary indexes

[Chantal Ackermann <ch...@btelligent.de>]

You could also create a single index and use a field "user" to filter
results for only a single user. This would also allow for statistics
over the complete base.

Chantal



On Tue, 2011-12-20 at 12:43 +0100, graham wrote:
> Hi,
> 
> I'm a complete newbie and currently at the stage of wondering whether
> Solr might be suitable for what I want.
> 
> I need to take search results collected by another system in response to
> user requests and allow each user to view their set of results in
> different ways: sorting into different order, filtering by facets, etc.
> 
> I am wondering whether it would be practical to do this by creating a
> Solr index for each result set on the fly. Two particular questions are:
> 
> 1. Is it even practical to do this in real time? Assuming that each set
> of results contains low hundreds of elements (each a bibliographic
> record), and that the users' patience is not unlimited.
> 
> 2. What would be the best way to manage a separate index for each query,
> given that the main constraint is time, and that the number of indexes
> needed simultaneously is not known in advance? Create a separate core
> for each query, or use a single index with a query id as one of the
> keys, or..?
> 
> Thanks for any advice (or pointers to existing systems which work like
> this)
> 
> Graham