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.


El otro día leyendo un post en el blog de Billy Newport sobre el uso de Lucene en sistemas de Grid me recordó el tema de nuevo. En este caso el problema era el siguiente. Un cliente con un índice de Lucene bastante grande. 25 Gigabytes de nada. Para hacer las búsquedas más rápidas, deciden mover el índice a memoria (ver post de hace tiempo sobre el tema) pero el problema entonces es que la Heap se les iba a los 40Gb, que ¡no está nada mal!. Así que las paradas para recolectar la basura ya os podéis imaginar que eran largas.

La solución que intentaron probar fue el dividir el índice en diferentes máquinas hardware. Por ejemplo 7 máquinas con Heaps de 7Gb cada una. Y después extender las clases de directorio de Apache Lucene de modo que cada vez que se indexase un documento éste fuese a parar a una store que estaba distribuida a través de las 7 máquinas. Para ello utilizaron IBM WebSphere eXtreme Scale que parece que hace que esta tarea que parece tan complicada sea mucho más sencilla.

El problema con esta situación sin embargo es que es fácil que los bloques de un mismo documento se distribuyan por diferentes máquinas, y al final las búsquedas se volvían muy lentas porque significaba el hacer demasiados viajes a través de la red local para obtener los datos. Para solucionarlo construyeron una caché Near pero aún así cuando se producía un fallo en la caché, se notaba el rendimiento. Por lo que al final tenían que aumentar más y más el tamaño de la caché, pero con eso se aumentaba la Heap, y volvíamos al principio.

Según el post, la solución natural a este tipo de problemas es el realizar Sharding y en lugar de distribuir los datos, distribuir las búsquedas. Los documentos se indexan en índices en diferentes máquinas de acuerdo a algún criterio lógico, ej. usuarios del 1 al 1M, del 1M al 2M, del 2M al 3M, etc. y un componente de búsqueda realiza la búsqueda en paralelo en todos los nodos agregando los resultados y devolviéndoselos al cliente.

Y esa es la historia. Me pareció un post tan interesante que debía guardarlo aquí para referencia futura. Espero que también os resulte útil.