lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Walter Underwood <wunderw...@netflix.com>
Subject Re: Simple Faceted Searching out of the box
Date Fri, 22 Sep 2006 20:03:03 GMT
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