[Building Sakai] Elastic Search (SRCH-111)

[Adrian Fish]

> This is not different of maintaining the support of different
> databases (which is already what is done in sakai).
>

Agreed


> Regarding the googling, I must say that this is a really bold
> statement and would really like to see some sources explaining that.


Just Google for 'SOLR elasticsearch'. Like I said, not scientfic. There's
probably loads of regurgitation and dogma in the hits, but there is a
general theme of elasticsearch being easier to configure and scale. I'm not
even approaching expertise here, as a matter of fact, I don't even know why
I'm typing this ...


> And even if it was the case (I still don't think it is) reindexing
> isn't the problem as it's not the case (or rarely) in Sakai, almost
> nothing is reindex actually. Most of the time, documents are indexed
> only once, and a reindexation should only occur when the index is
> corrupted in a way or an other. So I disagree with you saying that
> it's the obvious scenario in Sakai.


I should have been clearer. I meant new documents being added to the index,
not full reindexing. New documents are added very frequently in Sakai I'd
say, and this is one of the areas where my (unscientific) googling proposes
that ES has the upper hand.


> On the other hand, when it comes to scaling, it suffers from being too
> tied to Sakai, and the index requires a new instance of Sakai to
> scale.


If that's the case, then I agree entirely. It seems mad to be forced to
cluster your sakai app servers just to scale your search thing. I'm not
sure that's what he is saying though. Surely the integration is using the
REST api, not the internal Java one? I think the embedded/external argument
is moot. Anybody serious about search will need an external search thing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130125/29bdd9cb/attachment.html