Un problema típico cuando estás desarrollando es contestar a la pregunta .... ¿esto lo hice en algún otro proyecto hace un año pero no recuerdo como se hacía?. Hay que decir que para contestar a esta pregunta google suele ser la mejor opción, pero cuando estás desarrollando código hay veces que ese código está en un subversion interno de la empresa y entonces google no sabe la respuesta. Para estos casos, que no son la mayoría, hemos añadido un servicio a la lista de servicios de zylk.net que consiste en dos partes, un indexador y un buscador:
Para la realización de este mini-proyecto nos hemos apoyado en el siguiente proyecto (http://svn-search.sourceforge.net/) que aunque parece discontinuado lo hemos podido montar y modificar para que se adaptara a nuestras necesidades.
La idea es indexar el contenido del gestor de versiones (en este caso subversion) en un conjunto de índices para permitir su posterior búsqueda,usando un buscador sobre los índices. En este caso el indexador y el buscador están basados en Lucene (http://lucene.apache.org/). Como datos básicos lo que indexamos es:
Ejemplo de un item de resultado con nombre de autor, fecha del último commit, path al fichero, nombre del fichero, mime-type y snippet de código con resaltado de las palabras claves buscadas.
En base a estos campos pueden hacer búsquedas por:
y las ordenaciones del resultado pueden ser (ascendentes o descendentes) según los siguientes criterios
Además se puede acotar la búsqueda por:
El por qué este nuevo servicio y por qué basado en lucene... se ha explicado someramente al inicio de este post pero lo más interesante es que lucene permite indexar GB de información de manera óptima y permite realizar las búsquedas de manera muy ágil además de disponer de un lenguaje de query mucho más orientado a la búsqueda de texto que lo que lo está por ejemplo SQL. En números por ejemplo nuestro repositorio contiene unos 20GB de código y documentos (más de 50000 documentos java, 100000 imágenes, 10000 documentos ofimáticos etc..) y los índices generados ocupan 3,5 GB.
Con estos números una búsqueda típica tarda entre 0.1 y 2 segundos dependiendo de la ordenación que se quiera etc. Hacer algo similar con una base de datos usando los módulos que no son SQL estandar da un rendimiento mucho peor (un por diez aproximadamente) además de los típicos problemas de crecimiento de las tablas con los blobs etc....
Estadísticas de las búsquedas de todos los ficheros .doc (0.04 sg en buscar y 0.7 en renderizar y comprobar permisos)
Estadísticas de las búsquedas de todos los ficheros .java que contienen la palabra zylk (0.06 sg en buscar y 2.1 en renderizar y comprobar permisos)
Realmente esta es la misma orientación que siguien gestores documentales como Alfresco o la parte de gestión documental de Liferay Portal. Es decir separar de la base de datos relacional los índices de búsqueda para no penalizar el rendimiento. Algo similar a lo que se hace con BigData y elastic-search tal como se explicó en este otro post (http://www.zylk.net/es/web/guest/web-2-0/blog/-/blogs/big-data-explorando-los-nuevos-paradigmas-del-desarrollo).
Esta misma orientación/arquitectura, se podría usar para hacer buscadores de casi cualquier origen de datos ya sean documentos (catalogos de empresa en PDF, boletines en xml o en PDF etc..) ya sean campos de una base de datos relacional al uso. Lo único que cambiaría en este caso es el modelo de meta-datos sobre los que se trabaja.
La idea es añadir ahora una capa de facets usando la librería bobo para mejorar la experiencia de uso del buscador y para mejorar si cabe más el rendimiento. En el siguiente enlace se puede ver una comparativa entre una base de datos relacional como mysql y bobo + lucene