¿Es lento Lucene en tiempo real?

A través de este twit de Marc Sturlese, llego a un fenomenal artículo de Mike McCandless, miembro del proyecto Lucene y autor de la segunda edición de Lucene in Action, en el que se hace un exhaustivo análisis de las capacidades de Lucene para realizar búsquedas en tiempo real.

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.

Tutorial sobre Lucene 3.0

Mas o menos a finales del 2009 se lanzó Lucene 3.0. Aún así, mucha gente todavía se quedó en las versiones 2.x porque hubo algunos cambios en la API que forzaban a modificar las aplicaciones.

Este post relámpago es simplemente para comentar que Bob Carpenter, el creador de Lingpipe ha publicado en su blog hace unos días un pequeño tutorial de 20 páginas de introducción a Lucene 3.0 que os puede ser útil.

Podéis descargarlo desde este enlace. Incluye código fuente.

Lucene, Grids, Heaps y otras cosas del montón

En el penúltimo post explicaba la importancia en ciertos escenarios de que los objetos tengan una vida de corta duración. Only the good die young. Uno de esos escenarios es el caso en el que tengamos una Heap enorme, caso en el que la recolección de basura puede llevar mucho tiempo.

¿Y qué tamaño puede tener uno de esos Heaps tan enormes? Recuerdo hace años que tener un Heap de 512Mb ya era la caña. Después, cuando estabamos haciendo aplicaciones de trading hace ya casi cinco años, jugábamos con Heaps de 4gb, que no estaba mal pero ya resultaba bastante pequeño, pero era fruto sobre todo de las limitaciones de los sistemas operativos de 64 bits y en producción si que nos íbamos a 8, pero con la incertidumbre de no saber con exactitud que iba a pasar.

Hadoop toma protagonismo

Parece que uno de los proyectos que han tenido bastante éxito en la OSCON 2007 ha sido Hadoop, un subproyecto de Apache Lucene que implementa el conocido algoritmo de MapReduce utilizando su propio sistema de ficheros distribuido.

Tim O'Reilly ha publicado un extenso artículo sobre esta librería y la importancia de que Yahoo esté detrás de ella. En particular destaca la importancia de que Yahoo escoja el camino de contribuir al Open Source y respaldar proyectos exitosos como Lucene como base para las herramientas que utiliza, en lugar de seguir el camino de hacer desarrollos internos, que es el aparente camino que sigue Google (no quita que haya liberado interesantes frameworks).

Aún así el creador de Lucene y Hadoop, y ahora empleado de Yahoo, Doug Cutting, destaca que Hadoop no está limitado a la búsqueda ni tiene porque ser ese el escenario en el que rinde mejor:


"Where Hadoop really shines, is in data exploration." Many problems, including tuning ad systems, personalization, learning what users need -- and for that matter, corporate or government data mining -- involve finding signal in a lot of noise.

Y el artículo termina con un ejemplo de como utilizar MapReduce para afrontar la explotación de ficheros de log gigantescos.

El caso es que en la Yahoo Developer Network han publicado las charlas, powerpoints, video y audio de la presentación realizada en la OSCON y una entrada antes también hablan sobre la evolución del proyecto.

High Availability ofrecía un análisis hace poco sobre este producto. Y bueno, en casi todas estas fuentes referencian al artículo de Julio sobre como integrar Hadoop con Amazon Web Services.

Desde luego, parece que suena bastante. Por cierto, ¿a alguien le interesa jugar con Hadoop y Amazon? Un proyecto realmente interesante sería integrarlo con Apache Jackrabbit de forma que pudieses almacenar contenido de cualquier repositorio en un sistema de ficheros distribuido, como por ejemplo el de Hadoop, y que a su vez se volcase en un servicio como Amazon S3. Y además sería una contribución espectacular para jLibrary :D