Well,
I think that if some is searching the 'whole of the dataset' to find the
'individual data' then an SQL database outside of Solr makes as much sense.
There's plenty of data in the world or most applications that needs to stay
normalized or at least has benefits to being that way.
Dennis Gearon
Signature Warning
----------------
It is always a good idea to learn from your own mistakes. It is usually a
better idea to learn from others’ mistakes, so you do not have to make them
yourself. from 'http://blogs.techrepublic.com.com/security/?p=4501&tag=nl.e036'
EARTH has a Right To Life,
otherwise we all die.
--- On Mon, 10/11/10, Peter Keegan <peterlkee...@gmail.com> wrote:
> From: Peter Keegan <peterlkee...@gmail.com>
> Subject: LuceneRevolution - NoSQL: A comparison
> To: solr-user@lucene.apache.org
> Date: Monday, October 11, 2010, 5:32 PM
> I listened with great interest to
> Grant's presentation of the NoSQL
> comparisons/alternatives to Solr/Lucene. It sounds like the
> jury is still
> out on much of this. Here's a use case that might favor
> using a NoSQL
> alternative for storing 'stored fields' outside of Lucene.
>
> When Solr does a distributed search across shards, it does
> this in 2 phases
> (correct me if I'm wrong):
>
> 1. 1st query to get the docIds and facet counts
> 2. 2nd query to retrieve the stored fields of the top hits
>
> The problem here is that the index could change between (1)
> and (2), so it's
> not an atomic transaction. If the stored fields were kept
> outside of Lucene,
> only the first query would be necessary. However, this
> would mean that the
> external NoSQL data store would have to be synchronized
> with the Lucene
> index, which might present its own problems. (I'm just
> throwing this out for
> discussion)
>
> Peter
>
