compression did a lot of good, but there is one set of use cases where we have
significant speed loss when using defaults.
There is lovely concept of Document Values that is perfect for smallish single
fields, there are also stored fields that are prefect for clunky texts, but
there is a ga
thanks Jack,
yes, i should evaluate lucene by query performance.
On Mon, Jul 8, 2013 at 12:45 AM, Jack Krupansky wrote:
> To be clear, Lucene and Solr are "search" engines, NOT "storage" engines.
> Has someone claimed otherwise to you?
>
> What is your query performance in in 4.x vs. 3.x? That's
To be clear, Lucene and Solr are "search" engines, NOT "storage" engines.
Has someone claimed otherwise to you?
What is your query performance in in 4.x vs. 3.x? That's the true, proper
measure of Lucene and Solr performance.
-- Jack Krupansky
-Original Message-
From: Chris Zhang
S
thianks Adrien,
In my project, almost all hit docs are supposed to be fetched for every
query, what's why I am upset by the poor reading performance. Maybe I
should store field values which are expected to be stored in high
performance storage engine.
In the above test case, time consuming of readi
Indeed, Lucene 4.1+ may be a bit slower for indices that comptelely
fit in your file-system cache. On the other hand, you should see
better performance with indices which are larger than the amount of
physical memory of your machine. Your reading benchmark only measures
IndexReader.get(int) which s
hi ,
Sorry to interrupt you, but I am really confused by the bad performance
of lucene 4.2.1. Recently I migrated project from lucene 3.0 to 4.2.1 .
After simply tests I found that both indexing and reading performance of
lucene 4 can not match the older version.
Indexing code snippets are as
