The “law of unintended consequences” applies to using the block join query parser in Solr, just as it does to many other things in life (and software). Leave out certain query strings in Solr, and It seems to make no difference. But this action can actually have positive effects, especially when working with Solr in a Near Real Time (NRT) environment. There are a number of other steps you can take to make Solr more NRT-capable, too.
Faster responses make customers happy. Lower hardware requirements make budget people happy. Block Join can help accomplish both these goals, which is why we strongly suggest using it for nested document searches in Solr. But that’s enough about why we advocate using Block Join for nested and faceted searches in Solr. Now we’ll talk about how to do it.
In a previous post, we talked about business motivations behind the support of structured documents in a Solr/Lucene index and the unique requirements for a faceting engine which is created by this approach to modeling data. We have introduced SOLR-5743. Now it is time to take a deep dive into the implementation details of Block Join Faceting in Solr search.
Join support is a highly-requested Solr feature, especially in e-commerce. So I repeated Erick Erickson’s benchmark test with block join support for Solr, and I want to share my observations on how BlockJoinQuery can maximize Solr/Lucene performance.
A straightforward look at how Block Join Faceting works, how it can save your customers from frustrating search experiences, and why Grid Dynamics created SOLR-5743 to bring Block Join Faceting to Solr
Solr/Lucene has emerged over the last few years as a leading open source search platform for large-scale e-commerce search engines. Systems based on Solr power major sites including Macy’s, Kohl’s, Walmart, Etsy, and many others. An increasing number of tier-1 digital retailers are building their next-generation search and catalog navigation platforms using the Solr technology stack, often replacing commercial engines such as Oracle Endeca, FAST or Mercado.
The main reason website and application performance testing is not already continuous in many companies is clear: it’s hard to implement. Why? Let’s look at a few CPT implementation issues:
Nobody wants situations where e-commerce performance issues lead to lost revenue. Nothing upsets engineering teams more than frantic application troubleshooting and patching in the middle of the night. And absolutely nothing upsets business people and destroys careers more than watching customers switch to your competition during the year’s heaviest sales days because their website or mobile application is visibly faster. Continuous Performance Testing can help prevent these problems by catching them during the development process instead of after an application is in production.
Here are four studies that show how software performance problems can affect busy e-commerce properties: