For many applications, search engine and database are
competitive solutions. One has to consider in depth to
choose either search engine or database, and in some
cases, the border is blurred.
There are several issues to consider when selecting
database or Lucene or both as the solution to a
speci
1. The conventional database uses B+tree as the
indexing mechanism, while search engine uses
inverted-index.
When user needs to update the data frequently, then
B+tree is a better choice. However, for search engine,
the data and index doesn't change too often.
Inverted indexes are tables
Thanks, Yonik.
TermInfosReader is exactly the class I am looking for.
Kan
--- Yonik Seeley <[EMAIL PROTECTED]> wrote:
> On 1/12/06, Kan Deng <[EMAIL PROTECTED]> wrote:
> > Many thanks, Doug.
> >
> > A quick question, which class implements the
> following
Many thanks, Doug.
A quick question, which class implements the following
logic?
org.apache.lucene.search.IndexSearcher?
> For access, Lucene is equivalent to a B-Tree
> with all but the leaves cached in memory, so
> that accesses require only a single disk access.
thanks,
Kan
--- Dou
icks to improve the hopping algorithm. However, my
doubt is that the search performance may not so
competitive as B+tree.
Is my understanding correct?
Kan
--- Kan Deng <[EMAIL PROTECTED]> wrote:
>
> I have similar problem about the internal indexing
> data structure
>
> Acc
ricks to improve the system performance, before
rushing into the implementation of cache.
thanks again,
Kan
--- John Haxby <[EMAIL PROTECTED]> wrote:
> Kan Deng wrote:
>
> >1. Performance.
> >
> > Since all the cached disk data resides outside
> JVM
>
I have similar problem about the internal indexing
data structure
According to Paolo Ferragina of Univ Pisa, B+tree with
cluster is best for sorting. However, referring to the
implementation of
org.apache.lucene.search.IndexSearch, it looks like
the impl doesn't take B+tree, never mention cluster
d for you by the file system. Yes, the JVM
> would blow up with a OOM error if the index is too
> big to fit in RAM.
>
> Otis
>
> - Original Message
> From: Kan Deng <[EMAIL PROTECTED]>
> To: java-user@lucene.apache.org
> Cc: Kan Deng <[EMAIL PROTECTED]&
Hi, there,
In "Lucene in action", it mentions in Section 3.2.3
"reading indexes into memory" that,
"...RAMDirectory's constructor can be used to read a
file system-based index into memory, allowing the
application that accesses it to benefit from the
superior speed of the RAM:
RAMDirectory