riak search - creating many indexes for one inserted object

kamiseq kamiseq at gmail.com
Tue Oct 23 13:43:28 EDT 2012


thanks for replying,
and yes i meant something like multiple cores in solr. right now we
are indexing each core manually. I know we could try different
approach.

the example is my pure imagination to demonstrate more or less the
logic we have.

pozdrawiam
Paweł Kamiński

kamiseq at gmail.com
pkaminski.prv at gmail.com
______________________


On 19 October 2012 18:21, Ryan Zezeski <rzezeski at basho.com> wrote:
> Pawel,
>
> On Tue, Oct 9, 2012 at 5:21 PM, kamiseq <kamiseq at gmail.com> wrote:
>>
>> hi all,
>>
>> right now we are using solr as search index and we are inserting data
>> manually. so there is nothing to stop us from creating many indexes
>> (sort of views) on same entity, aggregate data and so on.
>> can something like that be achieved with riak search??
>
>
> Just to be sure I understand you.  When you say "many indexes" do you mean
> something like writing to multiple Solr cores?  If so, no, Riak Search
> cannot do that.  It writes to an index named after the bucket you have the
> hook on.
>
>>
>> I think that commit hooks are good point to start with but as I read
>> search index is kept in different format than bucket data and I would
>> love to still use solr-like api to search the index.
>
>
> Yes, Riak Search stores index data in a backend called Merged Index.  Riak
> Search has a Solr _like_ interface but it lacks many features, and doesn't
> have the same semantics or performance characteristics.
>
> There is a new project underway called Yokozuna which tightly integrates
> Riak and Solr.  If you like Solr then keep an eye on this.  I'm looking for
> people who want to prototype on it so if that interests you please email me
> directly.
>
> https://github.com/rzezeski/yokozuna
>
>>
>> example
>>
>> I have two entities cars and parking_lots, each car references parking
>> lot it belongs to.
>> when I create/update/delete car object I would like to not only update
>> car index (so I can search by car type, name, number plates, etc) but
>> also update parking index to easily check how many cars given lot has
>> (plus search lots by cars, or search cars with given property).
>
>
> Why have a separate index at all?  Is it not good enough to have just the
> car index.  Each doc would have a 'parking_lot_s' field.
>
> "How many cars a given lot has" -- would be numFound on q=parking_lot_s:foo.
>
> "Search lots by cars" -- I'm guessing you mean something like "tell me what
> lots have cars like this", sounds like a facet on 'parking_lot_s', right?
>
> "Search cars with a given property" -- like the last query but no facet.
>
>>
>> probably all this can be achieved in many other ways. I can imagine
>> storing array of direct references in parking object and update this
>> object when car object also changed. but this way I need to issue two
>> asynchronous write request with no guaranties that both will be
>> persisted.
>
>
> Yes.  This is a problem with two Solr cores as well.  I'm not sure if this
> is a toy example but I don't see the need for 2 indexes.  I potentially see
> 2 buckets: 'cars' and 'lots'.  But that doesn't mean it has to be two
> indexes.  Does that make sense?
>
> -Z
>




More information about the riak-users mailing list