lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <otis_gospodne...@yahoo.com>
Subject Re: Simple Faceted Searching out of the box
Date Sat, 23 Sep 2006 19:47:40 GMT
Nah, he didn't write any DB -> JDBC -> Lucene examples in Lucene in Action, and neither
did Erik.  Lazy guys, I tell you!
Btw. your situation/problem is very common.  Just treat your DB as "the truth", and your Solr/Lucene
instance as a mechanism to quickly find bits of that truth.  Design your system so that in
case you lose your Solr/Lucene instance, you can revive from "the truth", even if you have
to do it from scratch.
RDBMS - transactional and relational beast that holds data
Solr/Lucene - quick text lookup

Otis

----- Original Message ----
From: Tim Archambault <tarchambault@bangordailynews.net>
To: solr-user@lucene.apache.org
Sent: Friday, September 22, 2006 4:15:42 PM
Subject: Re: Simple Faceted Searching out of the box

Okay. We are all on the same page. I just don't express myself as well in
"programming speak" yet.

I'm going to read up on Otis' "Lucene in Action" tonight. I'd swear he had
an example of how to inject records into a lucene index using java and sql.
Maybe I'm wrong though.



On 9/22/06, Walter Underwood <wunderwood@netflix.com> wrote:
>
> Sorry, I was not being exact with "store". Lucene has separate
> control over whether the value of a field is stored and whether
> it is indexed. The term "nurse" might be searchable, but the
> only value that is stored in the index for retrieval is the
> database key for each matching job.
>
> It seems like text search should be easy to add to a transactional
> database, but lots of smart people have tried to make that work
> and failed. Maybe it is possible, but neither Oracle nor Microsoft
> nor the open source community have been able to make it happen.
> The text search in RDBMSs seems to always be slow and lame.
>
> There is one product that does transactional query and text
> search: MarkLogic. It does a good job of both, but it is very
> XML-centric. It might be a good match, if you are into commercial
> software. It is a rather different style of programming than
> SQL or Lucene. You write XQuery to define the result XML with
> the contents fetched from the database.
>
> wunder (not affiliated with MarkLogic)
>
> On 9/22/06 12:42 PM, "Tim Archambault" <tarchambault@bangordailynews.net>
> wrote:
>
> > I'm really confused. I don't mean "store" the data figuratively as in a
> > lucene/solr command. Storing an ID number in a solr index isn't going to
> > help a user find "nurse". I think part of this is that some people feel
> that
> > databases like MSSQL, MYSQL should be able to provide quality search
> > experience, but they just flat out don't. It's a separate utility.
> >
> > Thanks Walter.
> >
> > On 9/22/06, Walter Underwood <wunderwood@netflix.com> wrote:
> >>
> >> On 9/22/06 12:25 PM, "Tim Archambault" <
> tarchambault@bangordailynews.net>
> >> wrote:
> >>
> >>> A recruitment (jobs) customer goes onto our website and posts an
> online
> >> job
> >>> posting to our newspaper website. Upon insert into the database, I
> need
> >> to
> >>> generate an xml file to be sent to SOLR to ADD as  a record to the
> >> search
> >>> engine. Same  goes for an edit, my database updates the record and
> then
> >> I
> >>> have to send an ADD statement to Solr again to commit my change. 2x
> the
> >>> work.
> >>>
> >>> I've been talking with other papers about Solr and I think what
> bothers
> >> many
> >>> is that there a is a deposit of information in a structured database
> >> here
> >>> [named A], then we have another set of basically the same data over
> here
> >>> [named B] and they don't understand why they have to manage to
> different
> >>> sets of data [A & B] that are virtually the same thing.
> >>
> >> The work isn't duplicated. Two servers are building two kinds of index,
> >> a transactional record index and a text index. That is two kinds of
> >> work, not a duplication.
> >>
> >> Storing the data is the small part of a database or a search engine.
> >> The indexes are the real benefit.
> >>
> >> In fact, the data does not have to be stored in Solr. You can return a
> >> database key as the only field, then get the details from the database.
> >> That is  how our current search works -- the search result is a list
> >> of keys in relevance order. Period.
> >>
> >> wunder
> >> --
> >> Walter Underwood
> >> Search Guru, Netflix
> >>
> >>
>
>




Mime
View raw message