Cinco soluciones basadas en Lucene para Real Time Search

Hace unos días trascendió que Twitter había terminado su proyecto de migración para su backend de búsqueda en tiempo real (search.twitter.com). El proyecto había comenzado en la primavera del 2010 y terminó en Abril del 2011 así que tenemos, tal y como señala Javier Murillo en su análisis, un año para un proyecto desarrollado por un equipo de quince ingenieros.

Twitter tenía dos problemas para querer cambiar la arquitectura de su sistema de búsqueda y que hasta el momento estaba basado en el modelo clásico de base de datos relacional. Uno era el que describen en el post de este mes, y es la escalabilidad. Con Rails estaban atados a un thread por búsqueda y eso hacía que desperdicien CPU y recursos mientras se está realizando la búsqueda. Algo realmente importante cuando tienes 12.000 búsquedas por segundo y mil millones de búsquedas diarias. Para eso decidieron migrar a una arquitectura asíncrona basada en Netty tal y como explica el artículo.

El segundo problema, que explicaban hace unos meses, tiene que ver con las limitaciones de las bases de datos tradicionales a la hora de indexar y realizar búsquedas en tiempo real sobre grandes volúmenes de datos. De hecho de un poco a esta parte se ha creado una tendencia en lo que es la búsqueda en tiempo real a migrar de bases de datos relacionales a sistemas de índices invertidos. Twitter compró allá por el 2008 una empresa llamada Summize que tenía un motor de búsqueda construido sobre MySQL. Adecuado para ese momento pero que sucumbió ante la magnitud del volumen de datos de Twitter.

Probablemente la implementación de índice invertido más popular sea Apache Lucene. Así que, si somos tan afortunados de disponer de millones de datos que queremos indexar, y si además necesitamos que estos datos sean accesibles en tiempo real, entonces nos podemos llegar a preguntar: ¿Qué opciones tengo para realizar búsquedas en tiempo real con Lucene? Bueno, en realidad esta pregunta nos la podemos plantear de cualquier modo, aunque sólo sea por curiosidad. Aquí están las opciones que yo he podido encontrar:

1. Lucene

Sí, el propio Lucene se puede utilizar directamente como motor de búsqueda en tiempo real. Y en la mayor parte de los casos es más que suficiente. La mayoría de proyectos no tratan con millones de datos diariamente ni miles de consultas por segundo, por lo que el sharding, la escalabilidad, la tolerancia a fallos, o la escalabilidad, quedan relegados a un segundo lugar.

Lucene implementa desde la versión 2.9 lo que ellos llaman Near Realtime Search que hace que los datos actualizados estén disponibles para consultas pocos milisegundos después de haber sido insertados. Existe también una rama de desarrollo para búsqueda en tiempo real.

Si nuestro proyecto no entra dentro de ese pequeño porcentajq que necesita realmente tomarse muy en serio la escalabilidad, entonces simplemente configurar Lucene es una alternativa.

2. Elastic Search

Elastic Search es un motor de búsqueda en tiempo real y distribuido que se diferencia de los demás por hacer pública la gestión y consulta de estos índices mediante un API REST, lo que hace realmente sencillo el comenzar a trabajar con el motor sin siquiera tener conocimientos de ningún lenguaje de programación.

Además del API REST, existen APIs en Java y Groovy. Soporta Sharding y Multi-Tenancy (un mismo índice dividido en partes automáticamente vs. generación de divisiones lógicas sobre un mismo índice). Está liberado bajo licencia Apache, y su simplicidad realmente impresiona. El creador es Shay Banon, ex-director de tecnología de GigaSpaces y fundador del proyecto Compass. En su blog Shay Banon describe a Elastic Search como todo lo que él quiso que fuera Compass 3.0 y nunca pudo ser.

3. Katta

Katta es una librería, no demasiado conocida, basada en Hadoop y Lucene. Básicamente realiza sharding sobre los índices de Lucene sirviendo de este modo un único índice repartido entre múltiples servidores. Tiene licencia Apache y ofrece acceso en tiempo real a los índices además de encargarse automáticamente del sharding y la tolerancia a fallos.

Apartándonos ya de los temas técnicos, parece que la mayor actividad en las listas de correo se registró en 2009 decayendo un poco en los últimos años. Seguramente el haber ganado en estabilidad y el hecho de que no sea una librería no demasiado conocida haya contribuido a esto. Podéis ver más sobre Katta, aquí.

4. Solandra

Solandra es un motor de búsqueda en tiempo real basado en Solr y Cassandra. Cassandra es una base de datos distribuida desarrollada por Facebook y que sigue el paradigma NoSQL. Su arquitectura, tal y como comentan en su wiki, se basa en el modelo de datos de BigTable (Google) y la arquitectura y modelo distribuido de Dynamo (Amazon). Cassandra es utilizado por numerosas empresas conocidas como Digg, Facebook, Twitter, Cisco o RackSpace.

El concepto de Solandra es muy simple. Utilizar Solr para las búsquedas y Cassandra para la replicación de datos, sharding y caché. O en resumidas cuentas, un cluster de instancias de Solr gestionadas por Cassandra. Todo ello corriendo en la misma máquina virtual. El proyecto también tiene licencia Apache y está disponible en Github.

5. Zoie

Zoie es el sistema de indexado y búsqueda en tiempo real de Linkedin. Linkedin lo donó como proyecto Open Source en 2008 y su sitio web sigue utilizando, gestionando millones de búsquedas diariamente. Se trata de una modificación de Lucene adaptándola a los requisitos de Linkedin sin incluir funcionalidades como sharding, tolerancia a fallos, etc. que sería necesario añadir.