Faceted Search Part II: Enter RavenDB
April 17, 2014
Finding the right approach to a problem is dependent on many factors, including what tools are readily available. Sometimes there are already systems in place which may make sense to try to incorporate into the solution. Sometimes there are systems in place which would be more trouble than they’re worth to integrate with, and other times there’s nothing in the ecosystem and you need to introduce something new.
In the recent past, I was involved in implementing faceted search on two very different websites. One of these was based on the Sitecore content management system and already had extensive Lucene indexes over the content in question. Lucene has many powerful tools that help implement faceted search, but unfortunately, this site used a rather dated version of Lucene which was lacking most of these tools. Despite this, I still felt that finding some way to use the existing indexes would offer a significant savings. I was able to come up with a very efficient way to implement faceted search, which I previously discussed here.
The second site was a custom ASP.NET E-Commerce system backed by SQL Server 2005 with no other data storage or indexing technologies in place. The site already had faceted search implemented utilizing stored procedures and views, but the approach was scaling poorly as the site continued to grow in popularity. Although the faceted search feature wasn’t scaling well, the solution was well architected. After an analysis of the code, I was able to determine that there was a single interface which could be replaced to swap out the entire implementation.
We considered many different ways of fixing this – we could simply throw more hardware at the problem, try to make the existing implementation more efficient or introduce another tool altogether.
From past experience, I knew Solr would easily be able to solve this problem and the price was right. However, the client needed a solution ASAP and didn’t want to take the risk rushing a dependency on Java to their existing production servers or wait to install new hardware unless absolutely necessary.
During the process of evaluating options, I remembered that RavenDB had support for faceted search, was very reasonably priced, and would fit well within the customer’s ecosystem. It seemed like a great solution on the surface but I had reservations that mapping and synchronizing the client’s heavily normalized relational data into a document database would prove problematic.
Despite my misgivings, RavenDB felt like a strong contender. I discussed it with the customer and we collectively felt it was worth the investment of building a quick and dirty prototype/proof of concept. One afternoon’s worth of hacking later, I had a development version of the website running on a single test server that was handling an order of magnitude more traffic than the entire load balanced production environment. Two days later, a build was in production and has been running smoothly ever since then, handling more traffic faster and more efficiently than ever.
I may dedicate some future posts to exploring the exact process by which this transition was accomplished if there’s any interest.
Photo Credit: qthomasbower on Flickr Creative Commons
Stay up to date with our email updates!