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:
- El contenido de los distintos tipos de ficheros (cada uno con
su extractor, que son las piezas encargadas de extraer la
información de los docuementos ya que lucene solo indexa texto) - Path dentro del svn del fichero
- Metadatos de autor del cambio
- Comentario del commit del cambio
- Tipo de fichero
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:
- Texto/Contenido con los operadores de lucene (http://lucene.apache.org/core/2_9_4/queryparsersyntax.html)
- Path del fichero para su descarga/visualización, y para acotar
la búsqueda a un path concreto - Meta datos del autor del cambio en el svn (para la
visualización de los resultados de búsqueda)
y las ordenaciones del resultado pueden ser
(ascendentes o descendentes) según los siguientes criterios
- Fecha de modificación
- Relevancia
- Tipo de fichero
- Autor
- Comentario
Además se puede acotar la búsqueda por:
- Path
- Por fecha de modificación (buscar solo en los últimos 2 meses,
tres días etc..)
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/actualidad/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
