All,
Sorry for long email. I have two questions on indexing. My data consists of
an id, short headline and story text. Story text has some html tags. Here is
an example.
In early 2005, it seemed that Shamita Shetty had finally arrived after a
high profile debut in Mohabbatein [2000]. With 3
:
http://www.nabble.com/Multiple-index-performance-tp19043404p19043404.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Hi,
Just wondering if my repository has 1TB of index file, when I perform
searching, does it takes up or allocate a lot of memory usage to read and
retrieve the results?
Thanks
regards,
Wooi Meng
--
View this message in context:
http://www.nabble.com/Search-index-performance
Otis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ - Tag - Search - Share
- Original Message
From: Tony Qian <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Thursday, April 12, 2007 11:23:36 AM
Subject: Index performance
All,
Sorry for lo
Another question is if I can delete document based on storyIndentity field
(
using IndexReader.deleteDocuments(term)). Since storyIdentity field is not
indexed, is there any performance issue or I should index it too (and
store
it)?
As to your very last question, No, there'll be no performance
Eric,
Thanks for the information. The id is generated by database and it is
unique. So I only need to index it and don't need to store it, right
Tony
From: "Erick Erickson" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Index perf
Otis,
I timed just for indexing.
thanks,
Tony
From: Otis Gospodnetic <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Index performance
Date: Thu, 12 Apr 2007 09:31:49 -0700 (PDT)
Hi Tony,
Your code looks fine to me. I'm not sure what you timed
> I tried to index it. It took from 7-10 seconds to index about 90
documents.
That would be around 10 documents per second - way too slow. A Lucene's
perf test adding 12,000 docs sized similar to your sample doc (1400
characters) on a not so strong machine shows much faster pace - 146 docs
per sec
could that be where the time is
spent?
Erick
On 4/12/07, Tony Qian <[EMAIL PROTECTED]> wrote:
Otis,
I timed just for indexing.
thanks,
Tony
>From: Otis Gospodnetic <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: Re: Index performance
>D
To cover all possible non-indexing overhead, better measure with something
like this:
static long indexContents(IndexWriter writer, List storyContentList)
throws IOException {
long res = 0;
if (storyContentList != null && storyContentList.size() != 0) {
try {
Erick,
Sorry for late reply. I was stuck with other project. content object is
plain Java object. It has all fields set.
Thanks,
Tony
From: "Erick Erickson" <[EMAIL PROTECTED]>
Reply-To: java-user@lucene.apache.org
To: java-user@lucene.apache.org
Subject: Re: Index perfo
Doron,
I'll try that and let you know the result.
thanks for suggestions.
Tony
From: Doron Cohen <[EMAIL PROTECTED]>
Reply-To: java-user@lucene.apache.org
To: java-user@lucene.apache.org
Subject: Re: Index performance
Date: Thu, 12 Apr 2007 13:40:07 -0700
To cover all possible n
Doron and Erick,
I found the problem which slowed down indexing. It is our NFS file system.
Thanks for help.
Tony
From: "Tony Qian" <[EMAIL PROTECTED]>
Reply-To: java-user@lucene.apache.org
To: java-user@lucene.apache.org
Subject: Re: Index performance
Date: Mon, 16 Apr 200
"Tony Qian" <[EMAIL PROTECTED]> wrote:
> I found the problem which slowed down indexing. It is our NFS file
> system.
NFS performance is generally slower than local filesystem, though
there may be ways to tune it (I'm not sure). I have heard but not
personally verified that mounting NFS read-onl
"Tony Qian" wrote on 19/04/2007:
> I found the problem which slowed down indexing. It is our NFS file
system.
If only the index is maintained on NFS (say input is on local disk or DB or
such) it may help to index to local disk and only occasionally (once a
day?) copy/update to an index maintained
Hi,
I would like to know how's the performance during indexing and searching of
results on a large index files would be like.
And is it possible to create multiple index files and search across multiple
index files? If possible, may I know how could it be done?
Thanks a lot.
---
Cyndy wrote:
I want to keep user text files indexed separately, I will have about 10,000
users and each user may have about 20,000 short files, and I need to keep
privacy. So the idea is to have one folder with the text files and index
for each user, so when search will be done, it will be poin
[EMAIL PROTECTED] wrote:
Thanks Anthony for your response, I did not know about that field.
You make your own fields in Lucene, it is not something Lucene gives you.
But still I have a problem and it is about privacy. The users are concerned
about privacy and so, we thought we could have all
tion? Any recommendation?
>
> Thanks in advance.
>
>
> --
> View this message in context:
> http://www.nabble.com/Multiple-index-performance-tp19043404p19043404.html
> Sent from the Lucene - Java Users mailing list archive at Nabble.com.
>
>
> -
gt; Antony
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://
:Just wondering if my repository has 1TB of index file, when I perform
: searching, does it takes up or allocate a lot of memory usage to read and
: retrieve the results?
try a mailing list search for "memory usage" ... i think you'll find some
previous discussions that may help.
-Hoss
-
Lee Li Bin wrote:
Hi,
I would like to know how's the performance during indexing and searching of
results on a large index files would be like.
Fast.
And is it possible to create multiple index files and search across multiple
index files?
Yes.
If possible, may I know how could it be d
Searching on multiple index files is incredible fast. We have 10 different
index folders with different sizes. All folders together have a size of 7
GB. Results come back usual within less than 50 ms. Getting results out of
the index i.e. reading documents is expensive and you will have to spe
: Monday, June 18, 2007 4:00 AM
To: java-user@lucene.apache.org
Subject: Re: Lucene index performance
Searching on multiple index files is incredible fast. We have 10
different
index folders with different sizes. All folders together have a size of
7
GB. Results come back usual within less than 50 ms
- Original Message
From: Lee Li Bin <[EMAIL PROTECTED]>
I would like to know how's the performance during indexing and searching of
results on a large index files would be like.
OG: It depends ;)
- on your hardware (fast disk? lots of RAM? multi-CPU? multi-core?)
- on the size of data
its aggregates as a single Lucene document which made the
reading faster.
Andreas
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 19, 2007 8:05 PM
To: java-user@lucene.apache.org
Subject: RE: Lucene index performance
Hi Andreas,
I am very
Hi,
I've been wondering if anyone has tried to compare the performance of
any 'native' Java DB as index storage mechanism vs Lucene custom
implementation? I'm assuming that DB products should provide some
functionality for 'free' right out of the box (correct, if I'm wrong):
- easily managable
Hi.
I've been wondering if anyone has tried to compare the performance of
any 'native' Java DB as index storage mechanism vs Lucene custom
implementation? I'm assuming that DB products should provide some
functionality for 'free' right out of the box (correct, if I'm wrong):
- easily managabl
28 matches
Mail list logo
