that sounds very interesting but how do you handle queries like
select * from MY_TABLE where MY_NUMERIC_FIELD 80
as far as I know you have only the range query so you will have to say
my_numeric_filed:[80 TO ??]
but this would not work in the a/m example or am I missing something?
regards
PROTECTED]
Sent: Tuesday, December 14, 2004 10:23 AM
Subject: Re: Opinions: Using Lucene as a thin database
that sounds very interesting but how do you handle queries like
select * from MY_TABLE where MY_NUMERIC_FIELD 80
as far as I know you have only the range query so you will have to say
On Dec 14, 2004, at 15:40, Kevin L. Cobb wrote:
Was wondering if anyone out there was doing the same of it
there are any dissenting opinions on using Lucene for this purpose.
ZOE [1] [2] takes the same approach and uses Lucene as a relational
engine of sort.
However, for both practical and
My concern is that this just shifts the scaling issue to
Lucene, and I haven't found much info on how to scale Lucene
vertically.
By vertically, of course, I meant horizontally. Basically scaling
it across servers as one might do with a relational database.
: select * from MY_TABLE where MY_NUMERIC_FIELD 80
:
: as far as I know you have only the range query so you will have to say
:
: my_numeric_filed:[80 TO ??]
: but this would not work in the a/m example or am I missing something?
RangeQuery allows you to an open ended range -- you can tell the
Well, one could always partition an index, distribute pieces of it
horizontally across multiple 'search servers' and use the built-in
RMI-based and Parallel search feature. Nutch uses something similar
for search scaling.
Otis
--- Monsur Hossain [EMAIL PROTECTED] wrote:
My concern is that
Even we use lucene for similar purpose except that we index and store quite
a few fields. Infact I also update partial documents as people suggested. I
store all the indexed fields so I don't have to build the whole document
again while updating partial document. The reason we do this is due to
How big do you expect it to get and how often do you expect to update
it, we've been using Lucene for about 1 M records (19 fields each) with
incremental updates every 10 minutes, the performance during updates
wasn't wonderful, so it took some seriously intense code to sort that
out, as you
You can see Flickr-like tag (lookup) system at my Simpy site (
http://www.simpy.com ). It uses Lucene as the backend for lookups, but
still uses a RDBMS as the primary storage.
I find it that keeping the RDBMS and Lucene indices is a bit of a pain
and error prone, so _thin_ storage layer with
On Tuesday 14 December 2004 20:13, Monsur Hossain wrote:
My concern is that this just shifts the scaling issue to Lucene, and I
haven't found much info on how to scale Lucene vertically.
You can easily use MultiSearcher to search over several indices. If you
want the distribution to be more
:[EMAIL PROTECTED]
Sent: Tuesday, December 14, 2004 10:24 AM
To: Lucene Users List
Subject: Re: Opinions: Using Lucene as a thin database
that sounds very interesting but how do you handle queries like
select * from MY_TABLE where MY_NUMERIC_FIELD 80
as far as I know you have only the range query so
On Dec 14, 2004, at 9:40 AM, Kevin L. Cobb wrote:
I use Lucene as a legitimate search engine which is cool. But, I am
also
using it as a simple database too. I build an index with a couple of
keyword fields that allows me to retrieve values based on exact matches
in those fields. This is all I
12 matches
Mail list logo
