[Koha-bugs] [Bug 12478] Elasticsearch support for Koha

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12478

--- Comment #72 from Robin Sheat <robin at catalyst.net.nz> ---
(In reply to Katrin Fischer from comment #71)
> We currently do it alphabetically - which is kind of ok, but as we pick the
> facets quite randomly out of 20 records... 

Oh, this should be presenting the facets with the most results across the full
set of search results.

> I understand about not changing behaviour significantly for now, but I think
> there are a lot of weirdnesses that we shouldn't translate to Elastic Search
> if we can help it. And our facets are quite weird right now.

Well, they're probably a bit more sane in ES anyway. 

> Sorry, I don't understand, what do you mean by "(roughly, but I think mostly
> accurate for the scale of results in a Koha system.)"? 

Oh, just that when you get to many results over a clustered system, after a
point it starts estimating the counts. Like google's "Results 1-10 of about
1,200,000", it's an estimate, not an exact count. But for smaller result counts
it's going to be pretty exact.

> The demo database seems to be quite small and from here it's not very fast,
> so wondering about how performance looks for you. Have you done testing with
> a bigger database by chance? (100.000+?). We are running into a lot of
> never-noticed problems right now with the bigger databases and searching.

http://elasticsearch.koha.catalystdemo.net.nz/files/es-search/

Most of the time is spent in Koha::Database. This is something that has to be
fixed in general for Koha to use it (alternately, using a persistent
environment like Plack where the init only has to happen once.) There is a bit
of extra time spent in Catmandu that could be reduced if necessary, we're using
it as a fairly thin wrapper over search (as opposed to indexing where it's
critical) and it'd be OK to use the elasticsearch libraries directly. However
that's a bridge to burn when we get to it.

The database I'm using has 8,679 biblios and 14,841 items. So not very large at
all. At some stage I might have a look at putting a bigger one in, but that
does impact my reindexing time :)

> About the number - I think limiting to 10 could be problematic for things
> like itemtypes, locations and branches. It could be good to have that
> configurable at some point or an option to just show 'all' for some of the
> facets.

Sure, but is that a search thing or a Koha thing? I mean, putting hooks in to
make this possible is certainly a search thing (they don't exist yet), but the
decision on how it should be done is out of scope. I have enough problems to
worry about as it is :)

-- 
You are receiving this mail because:
You are watching all bug changes.