Per https://issues.apache.org/jira/browse/LUCENE-1349, we have made an
exception to Lucene's backward compatibility rules and marked
Fieldable as changeable, namely meaning we will allow, on a case-by-
case basis, changes to the interface, meaning anyone who implements
there own Fieldable
I just made a program using the java api of Lucene. Its is working fine for
my actually index size. But i am worried about performance with an biger
index and simultaneous users access.
1) I am worried with the fact of having to make the program in java. I
searched for alternative like the C
Before we go solving a problem that isn't necessarily there, can you
share a bit about what sizes you are at currently? Num docs, index
size, query rate?
Have you looked at http://wiki.apache.org/lucene-java/BasicsOfPerformance
?
-Grant
On Aug 5, 2008, at 10:21 AM, ezer wrote:
I
Yes i saw that.. it talks about performance, but not about the variants i
mentioned before.
Actually i tested indexing a database of about 200.000 registers. As i
mentioned it works fine with response of less than a second. But this
database can grow to millions of registers, and not sure if i am
Grant, wich other information can i provide in order to clarify my questions?
ezer wrote:
Yes i saw that.. it talks about performance, but not about the variants i
mentioned before.
Actually i tested indexing a database of about 200.000 registers. As i
mentioned it works fine with
An alternative is always to distribute the index to a set of servers.
If you need to scale I guess this is the only long term perspective.
You can do your own home grown lucene distribution or look into
existing one.
I'm currently working on katta (http://katta.wiki.sourceforge.net/) -
there
My point is more that you don't necessarily need to go looking for
variants. I've seen Lucene Java scale to millions no problem. I
talked w/ a guy using Solr this past week who had ~80 million records
in a single 80 gb index on one machine.
If I had a PHP front end, I would most likely
