Thanks for the response, Eric.
We have seen that size of the index has a direct impact on the search
speed, especially when the index size is in GBs, so trying all
possible ways to keep the index size as low as we can.
We thought solr.ExternalFileField type would help to keep the index
size low by storing a text field out side of the index.
Here's what we were planning: initially, all the fields except the
solr.ExternalFileField type field will be queried and will be
displayed to the end user. . There will be subsequent calls from the
UI to pull the solr.ExternalFileField field that will be loaded in a
lazy manner.
However, realized that solr.ExternalFileField only supports float
type, however, the data that we're planning to keep as an external
field is a string type.
Thanks,
-Jibo
On Jul 22, 2009, at 1:46 PM, Erick Erickson wrote:
Hoping the experts chime in if I'm wrong, but....
As far as I know, while storing a field increases the size of an
index,
it doesn't have much impact on the search speed. Which you could
pretty easily test by creating the index both ways and firing off some
timing queries and comparing..... Although it would be time
consuming...
I believe there's some info on the Lucene Wiki about this, but my
memory
isn't what it used to be.
Erick
On Tue, Jul 21, 2009 at 2:42 PM, Jibo John <jiboj...@mac.com> wrote:
We're in the process of building a log searcher application.
In order to reduce the index size to improve the query performance,
we're
exploring the possibility of having:
1. One field for each log line with 'indexed=true & stored=false'
that
will be used for searching
2. Another field for each log line of type solr.ExternalFileField
that
will be used only for display purpose.
We realized that currently solr.ExternalFileField supports only
float type.
Is there a way we can override this to support string type? Any
issues with
this approach?
Any ideas are welcome.
Thanks,
-Jibo
