Hey folks, samj1912 here again o/
As you might know, we recently did a massive upgrade of our search infrastructure. If you have not been following our Solr updates, definitely check out our other blog detailing our search server journey and the improvements and changes that come with the new search.
We have had a beta run with Solr this last week and fixed most of the show-stopping bugs. As such, we have been stress testing our Solr search by replaying our production logs on it, live.
Solr search seems to solvr almost all our qualms with search and as such, we have made the decision to use Solr for our production search servers.
The purpose of this blog post, as nicely worded by our BDFL Rob is –
Speak now or forever hold your pickle. In a week, the ole search servers gets it.
And it’s basically that, if you haven’t experimented with Solr search, please read our earlier blog to know what’s what. If you find any bugs, please report them on our ticket tracker. In case there are no new show-stoppers reported, that must absolutely be fixed before we switch to Solr on the main website, we will be killing the old search servers and replacing them with our brand new Solr ones in a week.
Apart from that, we have made a discourse thread to report any minor improvements in the search results.
Another thing, I’d like to remind everyone is that, with our switch to this new Solr infrastructure, the version 1 web service (ws/1)will soon be discontinued. As announced earlier, we will keep it alive till 31st July 2018 but it will get the axe on 1st August 2018, 12 pm GMT.
6 thoughts on “Releasing our new Solr search infrastructure”
It’s great to read the progress, and I’m looking forward to seeing Solr in action!
I’d like to ask something out of curiosity rather than a suggestion. Has ElasticSearch also been considered for search infrastructure? If yes, what advantages does Solr have over ElasticSearch?
Cheers to all the MB people,
Yes, we did indeed consider ES, however given that Solr is entirely open source and has an amazing community, which ES (with Elastic behind it) lacks upon.
Something else that solr does well is the documentation. ES though easier to setup and use at the beginning gets tiresome to use if you want to do something complex like writing a custom response writer which is compatible with our existing API. Our bookbrainz website infact tried using ES but our experience wasn’t that great.
Solr has been nothing but a blessing for us so far.
Another great pro for solr was the fact that our search API mostly involved textual queries rather than analytical ones which ES is supposed to excel at.
Given our use case and the maintenance of such a project, we ended up choosing Solr.
Great that there is a new search infrastructure.
But the previous search infrastructure led to better search results. In most cases, the name of the artist is displayed in the result list under title, although it is correctly entered in the search mask.
Maybe you could check and optimize this routine again.
Hi! Can you give an example of what you mean? https://musicbrainz.org/search?query=artist%3Anine&type=release&limit=25&method=advanced seems to show artists in the right place, so I’m not sure where exactly you mean – please paste a search example 🙂 Thanks!
So far this has been real positive from what I’ve seen. One of the biggest pains for me was adding multiple versions of a new album at the same time. Now if I wait a minute, I don’t have to copy and paste from the first entry and can just use search. I really appreciate the work.