Individual Query Construction: Is Terse Just The Worst? To see what I mean, we’ll start with simple cases of individual query construction and move on to more complex formulations. On the other hand, Elasticsearch can feel a bit more like Java’s verbosity mixed with Python’s emphasis on being explicit. What you’ll find is that Solr is a terse, Perl-like experience. Sure, both search engines interpret your queries into the same Lucene “machine code,” but can differ as much as Ruby, Python, or Haskell from each other. Each programming language has specific syntactic and semantic quirks you’ll have to deal with in your work. Think of each search engine’s Query DSL as a search ranking programming language. Rather it’s more useful to see the forest for the trees here. These two search giants quickly catch up to one another at the feature level. At this point in the genre of Elasticsearch vs Solr comparisons, the blow-by-blows quickly get out of date. In this article, I avoid a blow-by-blow feature comparison. More specifically, we’ll see what happens when the two search engine’s Query DSLs duke it out! Next time, we’ll discuss how deeply you can plug each search engine to customize search relevance. This time, we’ll take a look at controlling ranking. Last time we discussed matching, where Elasticsearch was the clear winner.
Ranking – how will the result set be ordered?.Matching – what should be in/out of the set of results?.We discussed how relevance comes down to controlling: Last time on The Young and The RESTful, aka Elasticsearch vs Solr, we took a look at the two search giant’s ability to solve search relevance problems.
0 kommentar(er)
