Take-away points from Lucene/Solr Revolution 2014

A lot late but finally I could got my hands on the videos from the Solr/LuceneRevolution 2014 conference, and this are my take-away points of the last years edition.

I’ve compiled some key points (from my own perspective of the conference) in a very short and summarized list that I want to share, keep in mind that this are opinions of my own.

  • If search is key to your business/app or Website then you must monitor how your users are using the search capabilities you’re publishing, this is true if you’re using Solr or Elasticsearch or even Lucene, in the conference we see references to this in several presentations (Airbnb, Evernote, etc.). This could be used to improve your search but can also provide very valuable insight on how your search is being used, basically allowing you to acknowledge if your “formula” is working or not.

  • Sometimes its OK to use Lucene and build from the ground up your own custom Search solution, this is not for everybody, but for some cases it will be worth the effort (Twitter, LinkedIn)

  • Solr can be used for the must unexpected use cases, yes we know that when you have text you can use Solr/Elasticsearch/Lucene to search on it, but did you know that you can even search images by color? Also Solr can be used just to deduplicate content, how cool is that? Do you need an engine that you can feed data and then execute quick queries against? then Solr is for you, the use case is limited by your own imagination (or your own needs).

  • If search is a core feature for your use case consider abstracting the inner workings of the search engine of your choice from the rest of your engineering team, meaning provide a library that will allow to other members create amazing apps without wasting time in learning how Solr/Lucene work, or how you scaled your infrastructure, this are complex issues. In previous editions of this same conference we’ve seen good examples of this approach, the case of CareerBuilder comes to my mind.

  • Paired with the previous point you also must provide tools that will allow the other members of your engineering team to debug a query, do A/B testing, bring people who knows the content to tell about the results quality, of course non of this is easy to build or maintain but the effort is well compensated, the idea is to create an ecosystem that democratizes search in your organization.

  • The new Analytics component is a powerful new addition to Solr, coming in the recently released Solr 5.0 and available to previous versions in the form of a patch. This awesome feature was presented by Steve Bower from Bloomberg and is an leap step forward compared to the Stats Components, that old friend that some of us use. I think that this brand new search component combined with AnalyticsQuery and the introducion of the PostFilter interface are leading Solr in a path to become one of the must customizable analytics platform, one item that in my personal opinion Elasticsearch attacked before Solr.

Its always nice to see some more advanced solutions that use Lucene in its core, with its own layers, LinkedIn is a great example of this, although keep in mind that this is not something trivial and you’ll need very talented engineers to create this type of system, and in most cases this is not really required.

Use DocValues there is no other way of saying this, if you want to do analytics, faceting on very large collections you’ll have to use DocValues it improves the memory usage a lot, if you don’t trust me you’ll hear exactly that in several talks on the conference from more advanced folks.

I think that search engines are getting a lot of attraction, not in the traditional Google, Bing, Yahoo! style but actually as a technology that can power very interesting use cases, mostly analytics and because of this, people/companies has been looking for ways to run this products in an even larger scale. Take a look at the talks by Tomás Fernández Löbbe from the Amazon CloudSearch team and Jessica Mallet from Apple and you’ll think entirely different about your own setup, trust me on this.

I’d love to have the opportunity to go to this conference in the near future, its a real joy to share a room with the must talented engineers out there pushing search to the future. So to finish this post I just want to let you an invitation to the next Lucene/Solr Revolution event, which will be in Austin, TX October 13-16. The registration opens this spring, so if you want to stay informed on this event visit the site or follow @LuceneSolrRev or @Lucidworks Twitter accounts for the most updated news.

Adding some safeguard measures to Solr with a SearchComponent

Just to be clear I wont be taking here about adding security to Solr, some documentation about this topic could be found in several places. I’m going to talk about some other kind of problems, those problems that comes when a user of your application requests a great amount of documents from your Solr cluster. Just to clarify perhaps your particular use case requires that your users can fetch a great deal of documents from Solr and in this case you should’ve planed for CPU and RAM requirements accordingly, taking into account your particular schema, cache, analyzers, and even using DocValues to improve query speed. But there are some cases when you just want to put some security measures to prevent your users from fetching a a lot of documents from Solr. Out of the box Solr comes without any options to deal with this case, and sure you could implement this in your app, but if you have several “clients” to your Solr data (this was my case), then you’ve to spread this change into all of those clients and every time you change something in one place it will be needed to change it in all the other pieces of code. Continue reading “Adding some safeguard measures to Solr with a SearchComponent”

MIME Type filtering with Nutch 1.x

As I’ve sayed before Nutch is a great Web crawler, and of course it provides the options for you to configure the process as you want. In this particular case if you only want to crawl some files (i.e HTML pages only and obviate all the images) you could use one several mechanisms available. Nutch basically provides a type of plugin to allow you to filter your crawl based on the URLs, actually Nutch come with a few of this plugins right out of the box for you to use, essentially the urlfilter-* family under the plugins directory.

Continue reading “MIME Type filtering with Nutch 1.x”

Solr: Instant Apache Solr for Indexing Data How-to Book Review

Apache Solr Beginner's GuideI’ve been writing this review for to long, sadly some work related issues forbade me of concluding this sooner. And this is why I want to formally apologize with the author Alfredo Serafini and Punit Shetty, the “guy” form Packt Publishing; wonderful fellows who gives me the opportunity of writing this reviews and provide access to the book, which otherwise I couldn’t afford.

When I start reading a book (any technical book, actually) I like to take a sneak peek through the index before actually reading the book and my first expression about the index of this great book was: This is a BEGINNERS GUIDE? My first impression came from the fact that in the index I saw sections about merging of segments and it’s impact in your indexes, another section about writing Solr plugins; so you don’t need to be a rocket scientist to understand any of those topics; and yet you don’t expect to see those topics covered in a book with the word “beginners” in the title. Nevertheless it’s fare to say that this only increase my interest on reading the book, and as I sayed before this was my first impression BEFORE reading the book, but when we start reading the book you get hit by this sentence in the Acknowledgments: Continue reading “Solr: Instant Apache Solr for Indexing Data How-to Book Review”

Indexing inlinks and outlinks with Nutch 1.x

Nutch its an amazing piece of software, its one of the most versatile Web crawlers out there. I’ve been playing with Nutch for quite some time now, since version 1.3 (If my memory doesn’t play tricks with me). The truth be told Nutch do all the hard lifting of running a crawl over the Internet, Intranet or just on those sites you want to crawl. Also, Nutch gives the user the ability of changing it’s own behavior using configurations.

During the crawl life cycle Nutch needs to pay attention to the outlinks of any given page, this is how Nutch knows where to go next. Of course this outlinks could be affected by a set of configuration options in your nutch-site.xml file, but this configurations are out of the reach of this blog post.

So now we know that Nutch has the capabilities of handling outlinks and inlinks, but how can we index this inlinks and outlinks into Solr? Being able of indexing the inlinks and outlinks could be what you want, depending of your use case. Sadly Nutch doesn’t do this by default, but it’s no problem to add this custom logic trough a plugin.

Nutch provides several extension points which basically corresponds to the kind of plugins you can develop to extend Nutch beyond your wildest dreams. Generalizing our requirement we could say that what we need to do is to index (send to our persistence layer) some data that Nutch already has. So what we need is to implement and IndexingFilter plugin to carry on our task.

Important Note: If you just want to “grab and use” here is the link to the Github repo where I’ve uploaded the full code (with tests included) so you could just build and add the jar into your nutch installation.

If you’re still reading down here then, let’s start with the “technical stuff”. What we need to do is grab the outlinks and inlinks of a Webpage before its send into Solr (or some other backend), as I previously say what we need is an IndexingFilter plugin, basically an IndexingFilter plugin is just a custom class that implements the IndexingFilter interface. This interface has it’s own magic sauce inside it, but it’s way beyond our blog post, so to keep it simple let’s say that this interface force us to implement three methods:

  • filter
  • setConf
  • getConf

Both setConf and getConf are pretty straight forward if you don’t want to provide any kind of configuration options to your plugin; We won’t cover how to handle configuration options for your custom plugins, but it’s enough to say that the Configuration object provided by Hadoop requires a no brainer to use.

So let’s focus on the filter() method which is the one with the greater amount of “condiment”. Basically this method take a few arguments:

public NutchDocument filter(NutchDocument doc, Parse parse, Text url, CrawlDatum datum, Inlinks inlinks) { … }

An instance of a NutchDocument, which is the object that eventually will be passed into an indexer (Solr by default) which will persist the documents. The instance of the Parse class holds all the data that Tika and all the parser plugins has extracted from the web page’s raw content. Of course the url of the webpage being indexed; an instance of the CrawlDatum class, this holds all the crawl related information: status, fetch time, fetch interval, modified time and a lot of other information. And finally but not least an instance of the Inlinks class. Let’s take a moment so we we could realize that we just found the inlinks of any webpage, which solves like the 50% of our problem.

The outlinks could not be so far away, but let’s hold that thought for a moment and see how the filter method suppose to work:

The filter method accepts a NutchDocument as a parameter and returns a NutchDocument, so it basically takes a document add or removes data from this documents (the data of a NutchDocument it’s called a Field, which is an instance of NutchField class.

So, basically the NutchDocument provides a way to store important data, basically information that we would like to persist into our backend, totally agnostic about the persistance layer we want to use: all what an Indexer plugin needs it’s a nutch document that will holds all the data, later on an actual Indexer of your choosing will translate what is stored in a NutchDocument into your persistance layer, which could be: Solr or Elasticseach (both bundled with the default installation of Nutch 1.8 at the time of writing this blog post) or even anything you could think of, even a queue like Kafka or RabbitMQ. The next figure illustrates this process that we just described, summarizing and IndexingFilter plugin it’s only responsible of adding or removing fields from a NutchDocument.

 Nutch Indexing filters life cycle

As we see saw previously the filter method of the IndexingFilter interface receives all the inlinks of the webpage (or URL) being processed at the moment. So what we need to do in our custom plugin is just add a new inlink field into the NutchDocument, so basically something like this:

In this case the add method of the NutchDocument field, handles the case for multivalued fields, so in case of need it “converts” a common field into a multivalued one. Meaning that multivalued fields can save as many values as we want within the same key, in this case a webpage could have several inlinks and several outlinks. Note: You’ll need to add to your Solr configuration the fields required to store the inlinks and outlinks, the main requirement in this case is that the field needs to be multivalued to hold all the inlinks of one document, of course the type of analyzers, tokenizers, etc. that you configure for this field depends on your specific use case. So now we just solved the 50% of our problem, but how to deal with the outlinks? Well as we just say in the beginning of this post, Nutch use outlinks to continue surfing throw the Web, so in some place the outlinks must be stored, this place is in the Parse information, which has a lot of sense if you ask me, basically the outlinks are extracted from the raw content of the Web page, if is an HTML document, you’ll need to search in it’s content and find all those tags that contains an outlink. So to index the outlinks we’ll need to add this snippet of code:

A working plugin, if you just want to grab an use a custom indexing plugin to index your inlinks and outlinks your could clone this GitHub repo. This plugin relies on a few options to let you configure how you want to store your inlinks and outlinks, for instance it allows you to filter over your inlinks and outlinks to store only those links from a different host that the webpage being processed, so you could just keep those “external” links, and forget about all the inlinks of the same host.

If you want to know more about the plugin you should read the README and see how you could configure this plugin. I also encourage you to look into the code, the same technique explained here is used.

So, this all folks, I hope you’ve enjoyed the journey through this very large post. If you have any question, put it in a comment or contact me on Twitter.