You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by "Michael J. Prichard" <mi...@mac.com> on 2006/05/31 19:40:12 UTC
Document design and analyzer questions?
Hello,
I will try this again....
I am working on a system that will index emails and their attachments.
I have all the pieces working that parse the documents and I am now
working on the actual indexing part. I would like to have synonym
searching as well.
Question is two fold. One, here is the layout I was thinking:
ItemID: Unindexed, Stored
ItemGUID: Unindexed, Stored
ItemType: Indexed, Stored
ItemDate: Indexed, Unstored
ItemKeywords: Indexed, Unstored
ItemName: Indexed, Unstored
ItemContent: Indexed, Unstored
ItemFrom: Indexed, Unstored
ItemTo: Indexed, Unstored
ItemCC: Indexed, Unstored
ItemBCC: Indexed, Unstored
Searches will be combinations of To, From, CC, Date and Content. Does
this look ok?
Also, any recommendations on what analyzer to use? I was thinking the
synonym analyzer based on the one in the Lucene in Action book.
Thanks,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Document design and analyzer questions?
Posted by Chris Hostetter <ho...@fucit.org>.
: I will have millions of entries in my index. Would storing them cause
: any performance issues?
only testing will tell ... but generally speaking i don't think stored
affect query performance very much -- just disk usage.
: >another important thing you should consider is field norms: they don't
: >make sense for most date fields or numeric fields, or fields where the
: >length is fairly irrelevant (ie: email addresses, guids, document types)
: What do you mean?
Check the archives and/or LIA for what a field norm is .. then look at
using Field.setOmitNorm to disable them for fields where you don't
want/need them.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Document design and analyzer questions?
Posted by "Michael J. Prichard" <mi...@mac.com>.
Hey Chris,
Thanks for the response.
Chris Hostetter wrote:
>: Question is two fold. One, here is the layout I was thinking:
>
>my rule of thumb: if a field is going to contain less then a few dozen
>bytes (ie: a date, an email address, etc) you might as well store it ...
>it will make your life easier when looking at your results.
>
>
>
I will have millions of entries in my index. Would storing them cause
any performance issues?
>another important thing you should consider is field norms: they don't
>make sense for most date fields or numeric fields, or fields where the
>length is fairly irrelevant (ie: email addresses, guids, document types)
>
>
>
What do you mean?
>: Also, any recommendations on what analyzer to use? I was thinking the
>: synonym analyzer based on the one in the Lucene in Action book.
>
>you are probably going to want to use PerFieldAnalyzer so you can use a
>differnet analyzer for the fields that store email addresses then the
>analyzer you use for the body text ... if i'm searching for
>emails from "bob@car.com" i dont want it matching on emails from
>"bob@automobile.com"
>
>
>
Sounds good. I guess I could just use a StandardAnalyzer on these fields.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Document design and analyzer questions?
Posted by Chris Hostetter <ho...@fucit.org>.
: Question is two fold. One, here is the layout I was thinking:
my rule of thumb: if a field is going to contain less then a few dozen
bytes (ie: a date, an email address, etc) you might as well store it ...
it will make your life easier when looking at your results.
another important thing you should consider is field norms: they don't
make sense for most date fields or numeric fields, or fields where the
length is fairly irrelevant (ie: email addresses, guids, document types)
: Also, any recommendations on what analyzer to use? I was thinking the
: synonym analyzer based on the one in the Lucene in Action book.
you are probably going to want to use PerFieldAnalyzer so you can use a
differnet analyzer for the fields that store email addresses then the
analyzer you use for the body text ... if i'm searching for
emails from "bob@car.com" i dont want it matching on emails from
"bob@automobile.com"
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org