You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Aurélien MAZOYER <au...@francelabs.com> on 2014/07/24 19:04:21 UTC
Multipart documents with different update cycles
Hello,
I have to index a dataset containing multipart documents. The "main"
part and the "user metadata" part have different update cycles : we want
to update the "user metadata part" frequently without having to refetch
the main part from the datasource nor storing every fields in order to
use atomic update. As there is no true field level update in Solr yet, I
am afraid that I have to build an index for both parts and to perform a
query time join, with all the well-known performance limitation. I have
also heard of side car index. Is it a solution that can meet my
requirements? Is it stable enough to be usable in production? Does the
community plan to make it part of the trunk code?
Thanks,
Aurelien
Re: Multipart documents with different update cycles
Posted by Alexandre Rafalovitch <ar...@gmail.com>.
Do you search the frequently changing user-metadata? If not, maybe the
external file field is helpful.
https://cwiki.apache.org/confluence/display/solr/Working+with+External+Files+and+Processes
Regards,
Alex.
Personal: http://www.outerthoughts.com/ and @arafalov
Solr resources and newsletter: http://www.solr-start.com/ and @solrstart
Solr popularizers community: https://www.linkedin.com/groups?gid=6713853
On Fri, Jul 25, 2014 at 12:04 AM, Aurélien MAZOYER
<au...@francelabs.com> wrote:
> Hello,
>
> I have to index a dataset containing multipart documents. The "main" part
> and the "user metadata" part have different update cycles : we want to
> update the "user metadata part" frequently without having to refetch the
> main part from the datasource nor storing every fields in order to use
> atomic update. As there is no true field level update in Solr yet, I am
> afraid that I have to build an index for both parts and to perform a query
> time join, with all the well-known performance limitation. I have also heard
> of side car index. Is it a solution that can meet my requirements? Is it
> stable enough to be usable in production? Does the community plan to make it
> part of the trunk code?
>
> Thanks,
>
> Aurelien
>