lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rajan chandi <chandi.ra...@gmail.com>
Subject Re: A very complex search problem.
Date Wed, 02 Sep 2009 17:42:16 GMT
Great Thanks Aakash for your inputs!
We'll try to do some research and possibly bench-marks before we move
forward.

Regards
Rajan

On Wed, Sep 2, 2009 at 1:27 PM, Aakash Dharmadhikari <aakashd@gmail.com>wrote:

> hi Rajan,
>
>  More knowledgeable people might be able to  provide better insight into
> the performance issues, but I have a doubt around this ORing business.
>
>  The best option I see is storing all my friends IDs in my documents as
> multi valued field. This in contrast to OR queries would make querying
> super
> fast as the number of Terms are reduced to one per document. In case of
> ORing if I have 150 friends, there would be 150 terms to be matched against
> per document in case its not my friends document.
>
> It would certainly increase the size of your index a bit, but comparing the
> query time efforts in ORing this might be extremely efficient.
>
> regards,
> aakash
>
>
>
> 2009/9/2 rajan chandi <chandi.rajan@gmail.com>
>
> > Thank you Birger for the pointer to HBase.
> >
> > HBase sounds interesting. We will consider this for -  "people you may
> > know".
> >
> > We are trying to address a different problem of searching from a well
> > defined list of contacts.
> > A huge ORed query sounds good at this point as a solution.
> >
> > Thanks and regards
> > Rajan Chandi
> >
> >
> > On Wed, Sep 2, 2009 at 4:22 PM, Lie, Birger <Birger.Lie@expert.no>
> wrote:
> >
> > > HI,
> > > I might be unclear in what I mean.
> > >
> > >
> > > Usually people have friends in common, so if you
> > > 1) create and store a relationship between user x and y, and give that
> > > an id.
> > > 2) x knows z than there is a probability that y might know z as well.
> > >
> > > If that is the case than add z to the relation and you don't need
> update
> > > documents.
> > >
> > >
> > > The important thing is to create some sort of relationship concept so
> > > you don't end up with N users and N relations...
> > > In this is the case when you search than you only have 1 And clause
> > > instead of 3.
> > >
> > >
> > > I think Hadoop running HBase is ideal for this application. Facebook is
> > > using HBase (I think) CouchDB is also excellent...
> > >
> > >
> > > -Birger
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: gwk [mailto:gijs@eyefi.nl]
> > > Sent: 2. september 2009 12:34
> > > To: solr-user@lucene.apache.org
> > > Subject: Re: A very complex search problem.
> > >
> > > Hello Rajan,
> > >
> > > I might be mistaken, but isn't CouchDB or a similar map/reduce database
> > > ideal for situations like this?
> > >
> > > Regards,
> > >
> > > gwk
> > >
> > > rajan chandi wrote:
> > > > Hi All,
> > > >
> > > > We are dealing with a very complex problem of person specific search.
> > > >
> > > > We're building a social network where people will post stuff and
> other
> > > users
> > > > should be able to see the content only from their contacts.
> > > >
> > > > e.g. There are 10,000 users in the system and there are only 150
> users
> > > in my
> > > > network.
> > > > I should be search across only 150 users' content.
> > > >
> > > > Is there an easy way to approach this problem?
> > > >
> > > > We've come-up with different approaches:-
> > > >
> > > >
> > > >    - Storing the relationship in each document.
> > > >    - A huge ORed query with all the IDs of the people that needs to
> be
> > > >    searched.
> > > >    - Creating a query and filtering the results based on the list of
> > > >    contacts.
> > > >
> > > > None of these approach sounds to be plausible.
> > > >
> > > > We already have gone through recently released book on Solr 1.4
> > > Enterprise
> > > > Search. The book also doesn't seem to have any pointers.
> > > >
> > > > Any good approach/pointers will help.
> > > >
> > > > Thanks and regards
> > > > Rajan Chandi
> > > >
> > > >
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message