ii - materias.fi.uba.armaterias.fi.uba.ar/7500/klas-tesisingenieriainformatica.pdfllamamos el...

ii

Abstract

In recent years, advances in the �eld of Information Retrieval has accelerated the provision of intelligent toolsthat help us to access information in an unstructured way using natural language. These tools are capable ofsearching for web pages, map locations, jobs, products, images and many other elements.

In parallel to advances in information retrieval, the �eld of software engineering shows a widespread adoption ofobject oriented programming, modeling business process and entities into domain models. This fact has beenstrengthened in the context of enterprise applications, which support organization's business and processes.

This thesis is about the construction of a search engine over domain models, a problem called the �DomainModel Search� problem.

This thesis makes a survey of the state of the art in information retrieval, domain models and their persistence.Additionally, we make case studies of tools that solve similar problems.

As part of experimentation, there has been built a complete and extensible search engine for indexing andretrieving information over domain models, validating this framework on di�erent domains and achieving astate of the art performance.

Keywords: information retrieval, search engines, indexing, software engineering, domain models,

enteprise applications

Resumen

Desde hace algunos años, los avances en el campo de Recuperación de Información han acelerado la pro-visión de herramientas inteligentes que nos ayudan a acceder a la información de manera desestructuradautilizando el lenguaje natural. Estas herramientas que son capaces de buscar páginas web, ubicacionesen el mapa, empleos, productos, imágenes y muchos otros elementos.

En paralelo a los avances en materia de recuperación de la información, el campo de la ingeniería desoftware muestra una amplia adopción de la programación orientada a objetos, modelando procesos yentidades de negocio en modelos del dominio. Este hecho se ha visto potenciado en el contexto de lasaplicaciones empresariales, las cuales soportan el negocio y/o los procesos de las organizaciones.

Esta tesis trata la construcción de un motor de búsqueda sobre objetos de un modelo de dominio, lo cualllamamos el problema de �Recuperación de Información sobre Modelos de Dominio�.

En este trabajo se realiza un relevamiento del estado del arte en materia de recuperación de la información,modelos de dominio y su persistencia, tomando casos de estudio de herramientas que resuelven problemassimilares.

Como parte de la experimentación se ha construido un framework completo y extensible para la indexacióny recuperación de información sobre objetos, validándolo en distintos dominios y logrando rendimientospropios del estado del arte.

Palabras Clave: recuperación de información, motor de búsqueda, indexación, ingeniería de software,modelos de dominio, aplicaciones empresariales

Índice general

1. Introducción 1

1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1. Information Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.2. Modelos de Dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.3. El problema del Domain Model Search . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.4. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2. Contribución de la Tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3. Plan de Tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4. Algunas convenciones adoptadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Estado del Arte 7

2.1. Information Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1. Clasi�cación de los Sistemas de IR . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.2. De�niciones Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.3. Métricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.4. Modelos de Information Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.5. Técnicas de Matching y Acceso a Datos . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1.6. Técnicas de Puntaje y Relevancia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.2. Modelos de Dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.2.1. De�niciones Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.2.2. Independencia del Modelo de Dominio . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.2.3. Inversión del Control e Inyección de Dependencias . . . . . . . . . . . . . . . . . . 51

2.3. Persistencia de Modelos de Dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

2.3.1. Persistencia y Ciclos de Vida en Aplicaciones Enterprise . . . . . . . . . . . . . . . 55

2.3.2. Persistencia Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.3.3. Persistencia Administrada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

2.3.4. Binaria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

2.3.5. Ad-Hoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

2.3.6. XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

2.3.7. Object Relational Mapper (ORM) . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

2.3.8. Bases de Datos Orientadas a Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . 65

iii

iv ÍNDICE GENERAL

2.4. Casos de Estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

2.4.1. Apache Lucene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

2.4.2. Hibernate Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

2.4.3. Compass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

2.4.4. Análisis de Hibernate Search y Compass . . . . . . . . . . . . . . . . . . . . . . . . 78

3. Desarrollo de la Propuesta de Solución 85

3.1. Análisis General del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3.1.1. Modelos de IR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85


3.1.3. Procesos de Indexación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93


3.2. Mapeo de Clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

3.2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

3.2.2. Con�guración y Mapeo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

3.2.3. Mapeos Avanzados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

3.3. Diseño del Framework de IR sobre objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

3.3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

3.3.2. Arquitectura del Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108


3.3.4. Procesos de Indexación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118


4. Experimentación 129

4.1. Tipo de Pruebas Efectuadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

4.2. Pruebas con Aplicaciones de Referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

4.2.1. PetClinic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

4.2.2. Klink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

4.2.3. KStore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

4.3. Pruebas de Calidad y Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

4.3.1. Pruebas de Calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

4.3.2. Pruebas de Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

4.3.3. Análisis Comparativo Cualitativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

5. Conclusiones 167

5.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

5.2. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Bibliografía 171

A. Instalación del Software y el Código Fuente 175

A.1. Instalación del Software de Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

A.2. Código Fuente y Sitio Web del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Capítulo 1

Introducción

En este capítulo comenzaremos a de�nir el problema que vamos resolver en esta tesis. Las siguientessecciones tratarán la motivación, contribución, el plan de tesis y las convenciones que emplearemos a lolargo de este trabajo.

1.1. Motivación

Para explicar la motivación de esta tesis, es necesario repasar algunos conceptos básicos de Recuperaciónde Información (en adelante también Information Retrieval o simplemente IR) y Modelos de Dominio(en adelante también Domain Model).

Las próximas subsecciones repasan brevemente de�niciones generales y conceptos necesarios para de�nirel problema a resolver (motivación), el cual llamaremos �el problema del Domain Model Search�.

1.1.1. Information Retrieval

Como primer paso creemos conveniente de�nir qué es Information Retrieval. Dependiendo del autor quetomemos, existen diferentes de�niciones de IR. Veamos algunas de éstas:

�IR trata acerca de la representación, almacenamiento, organización y acceso a items de información�(Baeza-Yates et al., 1999).

�Information retrieval (IR) consiste en encontrar material (usualmente documentos) de naturalezades estructurada (usualmente texto) que satisfaga una necesidad de información sobre grandescolecciones de documentos (usualmente almacenada en computadoras)� (Manning et al., 2008).

El objetivo de un sistema de IR es encontrar información que pueda ser relevante para la consultarealizada por el usuario (Baeza-Yates et al., 1999). Estas consultas son una representación de la necesidadde información del usuario e ingresan al sistema mediante texto libre (eventualmente pueden existiroperadores lógicos y otros complementos, pero normalmente se trata de texto libre).

Ejemplos de sistemas de IR:

Library Book Search: www.nypl.org (New York Public Library)

Web Search: www.google.com (Google Search), www.yahoo.com (Yahoo! Search)

Online Store Product Search: www.ebay.com (eBay) , www.shopping.com (Shopping.com)

Social Network Search: www.linkedin.com (Linked-In Contact Network), www.facebook.com (Face-book Social Network)

1

http://www.nypl.org

http://www.google.com

http://www.yahoo.com

http://www.ebay.com

http://www.shopping.com

http://www.linkedin.com

http://www.facebook.com

2 CAPÍTULO 1. INTRODUCCIÓN

1.1.2. Modelos de Dominio

De la misma forma que hicimos con IR, vamos a comenzar dando una de�nición de modelo de dominio odomain model :

Domain Model �es un modelo de objetos que incorpora comportamiento y datos� (Fowler, 2002).

Esta de�nición, además de ser algo escueta, es perfectible. Por esto vamos a replantearla pensando a losmodelos de dominio de la siguiente forma:

Domain Model un diseño de objetos que representa un dominio de problema de la realidad.

Este nuevo enfoque nos permite ver a los objetos no sólo como �datos y comportamiento� sino comoverdaderos modelos de entes de un dominio de problema. Para terminar de comprender esto hay queexplicar a qué nos referimos con realidad y dominio de problema:

La realidad comprende cualquier tipo de idea que podamos concebir, por ejemplo: un objeto concreto, lanada, las relaciones de amistad y enemistad, etc. Un dominio de problema es una porción de la realidaden la cual sus entes están relacionados entre si. Ejemplos de dominios de problema podrían ser las cuentasbancarias, un �lesystem o la sincronización entre procesos.

Los domain models no son un concepto nuevo en el diseño de software orientado a objetos, sino queimplementan premisas básicas de este paradigma: dentro de un dominio particular se efectúa un análisissegún el cual se modelan entes de negocio junto a sus responsabilidades, protocolo y colaboraciones. Enun domain model encontraremos objetos como productos, personas, pagos, páginas web, etc.

Volviendo a la perspectiva de Fowler, éste propone al domain model como un patrón de arquitectura(ver subsección 2.2.1), el cual, dependiendo del sistema particular, puede o no ser el más adecuado paraimplementar dicho sistema (Fowler, 2002). En esta tesis nos ocuparemos principalmente de aplicacionesque modelan sus entidades en modelos de dominio.

1.1.3. El problema del Domain Model Search

Introducción

Cuando se desarrolla un sistema orientado a objetos, las metodologías de análisis y diseño aportan unbuen grado de certidumbre acerca de qué entidades se van a modelar y qué operaciones van a realizar.

Sin embargo, ya sea por omisión a la hora de hacer el análisis o porque se considera innecesario, inadecuadoo fuera de alcance, no solemos contemplar la necesidad de acceder a los datos de manera desestructuradautilizando el lenguaje natural. Veamos algunos ejemplos:

Ejemplo 1.1.1. Para una aplicación que administra una librería, construimos un modelo del negociocon las entidades: libros, autores y sucursales. Suponiendo que este sistema almacena sus datos en unabase de datos relacional (RDBMS), de�nimos formularios que ejecutan consultas prede�nidas en lenguajeSQL.

Si quisiéramos responder la pregunta ¾Qué libros de �ciencia �cción� hay en la sucursal �San Martín�?,deberíamos implementar un formulario que ejecute una consulta como la siguiente:

SELECT

BOOK_TITLEFROM

BOOKS B, BOOK_STORE_MAP BSM, STORES SWHERE

S .LOCATION = 'SAN MARTÍN ' AND B.GENRE = 'CIENCIA FICCIÓN ' AND BSM.STORE_ID = S .STORE_IDAND BSM.BOOK_ID = B.BOOK_ID

Los inconvenientes más claros al resolver el problema de esta forma son:

Es poco �exible ya que las consultas deben ser previstas durante el análisis.

1.1. MOTIVACIÓN 3

No se extiende automáticamente a buscar elementos en diferentes esquemas. Esto es, es capaz debuscar �libros� o �autores� que cumplen con un criterio, pero si luego agregamos el esquema �música�,no incluye automáticamente al nuevo esquema.

Se depende del RDBMS particular para contar con herramientas que permitan procesar textos. Ellenguaje SQL no está diseñado para aplicar procesos que faciliten la coincidencia entre los términosde búsqueda y de indexación (elementos sobre los que uno busca). Si vamos a desarrollar estosprocedimientos, normalmente se deben implementar en un lenguaje procedural propietario (ejemplo:PL/SQL).

Las búsquedas recaen enteramente sobre la base de datos, de manera que para soportar volumen debúsquedas, se debe contar con un RDBMS de gran escala.

En este ejemplo anterior comenzamos a ver que un RDBMS no se adecua al tipo de consultas que estamosqueriendo resolver. Veamos otros ejemplos de sistemas donde tenemos requisitos de procesamiento delenguaje natural y un RDBMS no se ajusta a la solución:

Ejemplo 1.1.2 (Consultas a Sistema de Bibliotecas). A continuación analizamos dos ejemplos deconsultas en lenguaje natural a un sistema bibliotecario:

1. Consulta: �libros sobre information retrieval publicados desde 1999�

a) Libros debe reconocerse como una entidad, no es un tópico. Ver que si la biblioteca no cuentacon libros, podría sugerir revistas.

b) Information retrieval se debe reconocer como un tópico. En caso de no tener su�cientes librosdel tema podríamos ofrecer resultados que traten acerca de �search engines� o �procesamientodel lenguaje natural�.

2. Consulta: �traducciones de Macbeth al español�

La lógica a aplicar debe reconocer que:

a) Macbeth es una obra y no un autor,

b) entre todas las obras, buscamos sólo las del español.

Nuevamente, el ejemplo nos muestra que la lógica estándar de una base de datos no es la más adecuadaya que la mejor respuesta requiere un análisis semántico de la consulta.

Otros ejemplos de sistemas donde podríamos efectuar consultas en lenguaje natural:

Sitio Web de Comercio Electrónico:

1. Consulta: �stereo�

2. Consulta: �alarmas vehiculares�

3. Consulta: �guitarras en capital�

Sistema Universitario:

1. Consulta: �certi�cación de normas técnicas�

2. Consulta: �olimpiadas�

En todos estos casos vemos que las preguntas son consistentes dentro del contexto que maneja el usuarioque realiza las mismas, pero no necesariamente estarán contempladas por el análisis inicial del sistema.Además, estas consultas presentan un cierto grado de ambigüedad que las vuelve difíciles de resolver conel mismo lenguaje SQL que utilizamos para recuperar objetos y generar reportes.


Herramientas Actuales

En las últimas décadas han surgido herramientas de IR que nos permiten utilizar el lenguaje naturalpara encontrar información útil entre vastas colecciones de documentos, libros, audio o video. Algunosejemplos de esto son los buscadores web como (Google, 2009b; Yahoo, 2009). Estas herramientas de IRtransforman nuestras expresiones del lenguaje natural en items de información (enlaces a páginas web).

Además de las los buscadores web, existen herramientas maduras que permiten hacer IR sobre documentosde texto y están emergiendo las que permiten hacerlo sobre los objetos de nuestras aplicaciones. Dentrode las primeras, la más popular es Apache Lucene (Apache, 2009b). Entre las segundas debemos destacarHibernate Search (Hibernate, 2009b) y Compass Project (Compass Project, 2009).

El objetivo de Lucene es indexar y recuperar documentos de forma e�ciente y �exible. Sin embargo,Lucene no es una herramienta adecuada para indexar objetos de un modelo de dominio. Adelantándonosal análisis del problema, podemos señalar las de�ciencias que encontraron los autores de Compass alintentar utilizar Lucene como herramienta de IR sobre objetos:

Es relativamente difícil de integrar,

Sus APIs son de bajo nivel,

No es transaccional,

No soporta búsquedas sobre todos los campos de un documento,

No indexa directamente datos de un RDBMS,

Las actualizaciones de documentos son difíciles de implementar

A esto agregamos las críticas de los autores de Hibernate Search, quienes plantean que Lucene produce�desajustes� en el paradigma:

Desajuste de Sincronización (Synchronization Mismatch): con Lucene somos responsables de man-tener sincronizado el almacén de objetos (típicamente un RDBMS) y los índices de Lucene.

Desajuste Estructural (Structural Mismatch): debemos resolver el problema de efectuar un mapeode objetos a documentos de texto.

Desajuste de Recuperación (Retrieval Mismatch): al recuperar información, Lucene no devuelvedirectamente nuestros objetos de dominio sino objetos genéricos de Lucene.

Estos son problemas que veremos en detalle a lo largo de esta tesis y que hacen que librerías como ApacheLucene no sean adecuadas para indexar objetos. En en esta tesis también vamos a analizar herramientascomo Compass y Hibernate Search, las cuales fueron pensadas para indexar y recuperar objetos y sobrelas cuales también implementaremos mejoras.

Teniendo un panorama de las herramientas actuales y del problema que queremos resolver, en la próximasubsección explicaremos el objetivo de esta tesis.

1.1.4. Objetivo

El objetivo de esta tesis se puede enunciar de la siguiente forma:

Objetivo en esta Tesis se busca resolver el problema de aplicar las técnicas de IR para encontrar infor-mación almacenada en los objetos de los modelos de dominio. Para esto es necesario determinar lasactividades y componentes de un motor de búsqueda sobre objetos del dominio y las alternativasde implementación de cada una de ellas.

El objetivo implica resolver el problema planteado de forma general, esto es, permitiendo indexar objetosprovenientes de cualquier modelo de dominio.

En las próximas subsecciones se trata cómo contribuye esta Tesis a la solución del problema así comoexplicamos su plan de desarrollo.

1.2. CONTRIBUCIÓN DE LA TESIS 5

1.2. Contribución de la Tesis

Enunciemos el aporte que hace este trabajo al entendimiento del campo del conocimiento:

Esta tesis contribuye en:

la de�nición acerca de cuáles son los componentes principales de un motor de búsqueda sobreobjetos, sus alternativas de implementación y las consecuencias de distintas variantes de diseño,

la implementación de una solución concreta al problema de IR sobre información contenida enobjetos, escogiendo las alternativas de implementación más adecuadas.

Para probar la adecuación de la solución al problema, se implementa una pieza de software que actúacomo un framework de recuperación de información sobre objetos, tres aplicaciones de referencia sobrelas que validar el framework y un conjunto de pruebas cuantitativas y cualitativas que lo contrastan conlas soluciones previas. Este framework re�eja las mejores prácticas, criterios y premisas defendidas a lolargo de los próximos capítulos en base al estudio del problema y el análisis de las soluciones actuales.

1.3. Plan de Tesis

En esta sección vamos a organizar el resto de la tesis, describiendo la función que cumplen los próximoscapítulos:

El segundo capítulo describe el estado del arte. Este capítulo tiene un objetivo mixto. La primera parteincluye el soporte tecnológico y cientí�co necesario en materia de IR, diseño orientado a objetos y per-sistencia. El objetivo de esta primera parte es sentar las bases sobre la cual analizar los componentes delproblema, sus soluciones actuales y nuestra propuesta. En la segunda parte del capítulo tomamos comocasos de estudio para su análisis en profundidad las tres herramientas más importantes de la actualidad.Dicho análisis producirá el aprendizaje necesario para que nuestra propuesta incorpore los aciertos y evitelos desaciertos de otras herramientas.

El tercer capítulo trata la propuesta de solución y su implementación. Con las bases teóricas adquiridasen los capítulos previos, se analiza en profundidad cada uno de los aspectos intervinientes en el problema,las alternativas de solución y la justi�cación de cada una de las elecciones. Por último, se presenta undiseño detallado de la solución y, donde corresponda la comparación, se contrastan los casos de estudiocon la solución diseñada.

El cuarto capítulo trata acerca de la experimentación. El primer objetivo de este capítulo es validarla solución diseñada en situaciones reales de aplicación. El segundo objetivo es establecer un análisiscomparativo de resultados entre nuestra solución y las alternativas actuales, tanto en términos cualitativoscomo cuantitativos.

Finalmente, el quinto capítulo concluye la tesis con las conclusiones. Las conclusiones hacen una retro-spectiva de la tesis y ponen en blanco sobre negro los avances logrados así como el avance sobre la solucióndel problema. Como cierre de este trabajo planteamos las futuras lineas de investigación.

1.4. Algunas convenciones adoptadas

En el desarrollo de esta Tesis vamos a seguir consistentemente estas convenciones:

Referencias Cruzadas: la tesis está dividida en capítulos, secciones, subsecciones y apartados. Lasreferencias cruzadas que haremos a lo largo de este trabajo indicarán el nivel jerárquico del contenidoreferenciado utilizando estos cuatro niveles. Todas las referencias cruzadas a secciones, ejemplos y�guras se indican entre paréntesis.

Referencias Bibliográ�cas: las referencias se indican entre paréntesis, utilizando el autor y el año dela publicación. Cuando exista más de una publicación del autor en el mismo año, se agregará unaletra al �nal del año, tal de desambiguar la referencia en la sección de bibliografía.


Numeración de Ejemplos: los ejemplos están numerados secuencialmente de manera interna a lasección a la que pertenecen. Esto quiere decir que si tenemos cinco ejemplos en el capítulo 1 contres en la sección 1.1 y dos en la sección 1.2, la numeración será: 1.1.1, 1.1.2, 1.1.3, 1.2.1, 1.2.2 .

Cuando expresemos algoritmos, hagamos referencia a un identi�cador de un lenguaje de progra-mación, referenciemos clases o expresemos una frase literal utilizaremos la familia tipográ�ca SansSerif.

Al �nal de este trabajo se incluye también un índice alfabético de palabras clave.

Para �nalizar este capítulo introductorio, queremos señalar que previo al desarrollo de esta tesis el au-tor publicó un artículo introductorio al problema. Dicho artículo se puede encontrar en la sección debibliografía bajo la clave (Klas, 2009).

Capítulo 2

Estado del Arte

En este capítulo se presentan los conceptos, herramientas y tecnologías necesarias para construir un motorde búsqueda sobre objetos.

El objetivo de este capítulo es plantear el estado del arte en cada uno de los componentes del problemay efectuar un análisis comparativo entre las herramientas actuales.

En la sección 2.1 presentamos los conceptos y técnicas utilizadas actualmente en los sistemas de IR. Estastécnicas serán referenciadas al analizar los casos de estudio así como en el capítulo 3 para elegir la mejoralternativa de implementación para el motor de búsqueda.

En la sección 2.2 introducimos conceptos de diseño de software como: modelo de dominio, framework,librería, patrones de diseño y de arquitectura, inversión del control e inyección de dependencias. Estosconceptos serán fundamentales para analizar los casos de estudio y diseñar el motor de búsqueda sobreobjetos del capítulo 3.

En la sección 2.3 explicamos las técnicas de persistencia de objetos, las cuales veremos que interactúancon los motores de búsqueda sobre objetos e impactan sobre sus diseños.

Finalmente, en la sección 2.4 nos apoyamos en lo visto durante todo el capítulo para analizar las her-ramientas más importantes de IR sobre texto y objetos. Este análisis abre la discusión acerca de cómoimplementar la solución al problema planteado, la cual �nalmente se desarrollará en el capítulo 3. Elanálisis de los casos de estudio permitirá que nuestra propuesta de motor de búsqueda sobre objetosadopte sus mejores prácticas y evite que repitamos sus errores.

2.1. Information Retrieval

En esta sección presentamos los conceptos y técnicas utilizadas actualmente en los sistemas de IR.

Comenzaremos proponiendo una clasi�cación para los sistemas de IR (subsección 2.1.1), para luego pre-sentar los conceptos básicos de cualquier sistema de IR (subsección 2.1.2) y las métricas que determinansu éxito en términos de relevancia (subsección 2.1.3).

El centro de atención de esta sección estará en presentar los modelos de IR (subsección 2.1.4) y lastécnicas que vuelven a los sistemas de IR efectivos y e�cientes (subsecciones 2.1.5 y 2.1.6).

2.1.1. Clasi�cación de los Sistemas de IR

Como introducción a los conceptos de Information Retrieval es conveniente realizar una clasi�caciónfuncional de las herramientas de IR.

Algunos ejemplos de distintos tipos de herramientas de information retrieval:

Para usuarios �nales, de uso publico:

7

8 CAPÍTULO 2. ESTADO DEL ARTE

• Web Search: páginas web, documentos de o�cina, imágenes, etc. Ejemplo: Google Web Search, Yahoo Web Search.

• Product Search: bienes de uso y consumo en mercados virtuales. Ejemplo: e-Bay, Shopping.com,MercadoLibre.

• Scienti�c Publications: sobre publicaciones académicas y revistas. Ejemplo: ACM Digital Li-brary, IEEExplore.

• Legal: acerca de leyes y casos judiciales. Ejemplo: LexisNexis (Lexis Nexis Research, 2009).

Para usuarios �nales, de uso privado:

• Enterprise Search: sobre páginas web en Internet e intranets, e-mails y documentos en unrepositorio corporativo. Ejemplo: Oracle Enterprise Search (Oracle, 2009b), Google SearchAppliance (Google, 2009a).

• Personal Search: sobre contenido en una computadora personal. Ejemplo: Google Desktop,Windows Search.

Para uso en desarrollo de software:

• Text Retrieval: framework de indexación de texto para aplicaciones. Ejemplo: Apache Lucene(Apache, 2009b) (ver subsección 2.4.1).

• Object Search: framework de indexación de objetos. Es el tipo de framework que analizamosen este trabajo. Ejemplo: Hibernate Search, Compass Project (ver subsecciones 2.4.2 y 2.4.3).

La herramienta que construiremos como solución al problema propuesto entra en la categoría de her-ramientas �para uso en desarrollo de software�, más precisamente en �Object Search�. En la próximasubsección vamos a introducir los conceptos básicos que son comunes a todos estos sistemas.

2.1.2. De�niciones Generales

En esta sección de�nimos los conceptos básicos de IR. Como primer paso, repasemos la segunda de lasde�niciones de IR que vimos en la subsección (1.1.1):

Information Retrieval consiste en encontrar material (usualmente documentos) de naturaleza deses-tructurada (usualmente texto) que satisfaga una necesidad de información sobre grandes coleccionesde documentos (usualmente almacenada en computadoras) (Manning et al., 2008).

Esta de�nición de Manning está sesgada hacia la indexación y recuperación de texto como artículos,libros, etc). Este sesgo responde a los usos clásicos que se les han dado a los sistemas de IR, los cualestuvieron sus inicios indexando publicaciones cientí�cas y registros bibliotecarios (Manning et al., 2008).Con cierto sesgo hacia ése contexto se de�nieron entidades y conceptos básicos como: documento, corpusy léxico. A continuación presentamos sus de�niciones:

Documentos son las unidades hacia las que se construye el sistema de IR.

Estructuralmente, los documentos pueden ser de naturaleza homogénea o heterogénea. Por ejemplo, unsistema orientado a documentos homogéneos podría ser un sistema de IR sobre �cheros de biblioteca(en este caso los documentos son �cheros estructuralmente idénticos). Para el caso heterogéneo podemostomar como referencia al buscador web Google (Google, 2009b), el cual indexa páginas web, documentosPDF, presentaciones PowerPoint y muchos otros formatos heterogéneos.

En el problema del Domain Model Search, los documentos son los objetos del dominio de problema, loscuales pueden ser tanto homogéneos (objetos de una misma clase) como heterogéneos (objetos de distintasclases).

Corpus es el conjunto de documentos recuperables en el sistema.

2.1. INFORMATION RETRIEVAL 9

El corpus se puede caracterizar según varios criterios, los cuales dependen de la naturaleza del sistema.Un corpus puede ser:

Estático vs. Dinámico: en base a si el contenido de sus documentos cambia o permanece inmutableen el tiempo.

Interno vs. Externo: dependiendo si el almacenamiento de los documentos está controlado por elsistema o fuera de su control.

Un ejemplo de corpus estático e interno puede ser el sistema bibliotecario de registro de �cheros. Estecorpus es estático porque las �chas no cambian en el tiempo e interno porque están en poder exclusivodel sistema bibliotecario. Un ejemplo de corpus dinámico y externo son las páginas de Internet, cuyocontenido varía en el tiempo sin el control de los sistemas que las indexan.

En nuestro problema de IR sobre objetos, el corpus son los objetos persistentes del sistema. Este corpuses interno (normalmente el sistema controla los objetos de su modelo de dominio) y puede ser tantodinámico como estático.

Léxico es el conjunto de términos presentes en el corpus.

A los �nes prácticos, esta de�nición deja algunos problemas dependientes de la manera en la cual in-terpretamos el contenido de los documentos. Por ejemplo el léxico de un corpus de un único documentoD = ”procedimiento ad-hoc” puede ser L = {procedimiento, ad-hoc} ó L = {procedimiento, ad, hoc}. Alos efectos de nuestro problema, tomamos la de�nición de (Manning et al., 2008), la cual de�ne al léxicoen base a los términos que poblarán el índice invertido (ver subsección 2.1.5).

Al presentar la de�nición de IR mencionamos el concepto de indexación, el cual podemos de�nir como:

Indexación es el proceso que incorpora los documentos al corpus y actualiza los índices.

Esta de�nición introduce un nuevo término: el índice. Los índices son estructuras de datos que tienen porobjetivo recuperar e�cientemente entidades que cumplen con cierto criterio de �ltrado u ordenamiento.En la subsección (2.1.5) estudiaremos los índices utilizados en sistemas de IR.

2.1.3. Métricas

Las métricas en IR son medidas cuyo objetivo es mensurar la percepción de "éxito" del sistema de IRfrente a una consulta. Presentemos dos medidas básicas de IR (Baeza-Yates et al., 1999; Manning et al.,2008):

Recall es la fracción de documentos relevantes que ha sido recuperada del total de documentos recuper-ables.

Precisión es la fracción de objetos recuperados que es relevante.

Figura 2.1: Precisión y Recall. Las relaciones entre las cardinalidades de los conjuntos nos dan métricasde éxito del sistema.


Estas relaciones las podemos visualizar grá�camente en el diagrama de Venn presentado en la �gura (2.1):

Recall =|RR||DR|

(2.1.1)

Precision =|RR||R|

(2.1.2)

Las ecuaciones (2.1.1) y (2.1.2) se pueden ver en una tabla de contingencia:

DR DR

R verdadero positivo (vp) falsos positivos (fp)R falso negativo (fn) verdadero negativo (vn)

Cuadro 2.1: Tabla de contingencia para documentos relevantes y recuperados.

ahora rede�nimos las dos medidas en base a esta tabla:

Recall =vp

(vp+ fp)(2.1.3)

Precision =vp

(vp+ fn)(2.1.4)

A continuación profundizamos los conceptos de recall y precisión con un ejemplo:

Ejemplo 2.1.1. Dado un sistema de IR con un corpus C = {di} donde di son sus documentos, supong-amos que para una query puntual q, el conjunto C contiene 50 documentos relevantes. En base a susalgoritmos y parámetros, el sistema puede encontrar un conjunto variable de resultados R = {di}i∈〈0,j〉con 0 6 j 6 100, los cuales están ordenados según la relevancia asignada por el sistema. Para este ordenasignado, los resultados relevantes son RR = {d1, d5, d8, d12, d30, d40, d59, d80}.

A medida que ampliamos la cantidad j de resultados en R, obtenemos curvas de precisión y recall segúnesta tabla:

Número de Resultados(|Rj |) Documentos Relevantes (|RRj |) Recall(|RRj ||DR|=50 %

)Precisión

(|RRj ||Rj | %

)10 3 6% 30%20 4 8% 20%30 5 10% 17%40 6 10% 15%50 6 10% 12%60 7 14% 12%70 7 14% 10%80 8 16% 10%90 8 16% 9%100 8 16% 8%

Si gra�camos precisión en función del recall para segmentos de recall de 1% de amplitud obtenemos elgrá�co (2.2):


Figura 2.2: Precision(recall) . La curva muestra cómo varía la precisión a medida que aumentamos lacantidad de resultados retornados.

El ejemplo (2.1.1) puso de mani�esto una característica de los sistemas de IR: la solución de compromisoentre encontrar documentos relevantes (recall) y que éstos sean una cantidad signi�cativa del total deresultados (precisión). En general estas dos medidas están relacionadas de manera inversa, es decir,cuando una crece la otra tiene a decrecer.

Según necesitemos favorecer el recall o la precisión, esta relación inversa nos obligará a tomar decisionesde diseño en cada sistema de IR a construir. Por ejemplo, en un buscador web el objetivo es obtenerpáginas relevantes entre los primeros 10 resultados a costa de producir falsos negativos (favorece pre-cisión), mientras que en un sistema legal es más importante abarcar todos los casos que retornar sóloverdaderos positivos (favorece recall). Vemos entonces que el balance óptimo entre precisión y el recall esuna solución de compromiso determinada por las características del problema que resuelve la herramientade IR (Manning et al., 2008).

Una forma de cuanti�car la relevancia en un sistema de IR es otorgarle a los documentos una cali�caciónde relevancia (ranking) respecto de la búsqueda. Este ranking podría ser un valor real r ∈ [0, 1]. Utilizandoeste ranking, podemos de�nir un nivel α a partir del cual:

di ∈ RR ⇐⇒ rdi > α

Donde di es un documento particular y rdi su ranking para una query dada.

Notemos que cuando el parámetro α→ 0, estamos favoreciendo el recall por sobre la precisión (en el límite,si α = 0⇒ RR = DR, lo que implica un recall del 100%). En el otro extremo, si α→ 1 tendremos bajorecall y posiblemente mejoremos la precisión (asumiendo que en general logramos posicionar resultadosrelevantes entre los primeros lugares del ranking).

Continuemos presentando las métricas de IR con dos medidas adicionales, accuracy y F-measure:

Accuracy 1Esta medida se de�ne utilizando los valores de la tabla (2.1):

Accuracy =tp+ tn

tp+ fp+ fn+ tn

Asumiendo la herramienta de IR como un clasi�cador binario de documentos en las clases DR y DR(recordemos que la herramienta intenta obtener R = RR = DR), es plausible utilizar esta métrica, lacual es adecuada para evaluar sistemas de clasi�cación automática. La razón por la que normalmentedescartaremos esta medida es porque al estar los datos fuertemente desviados hacia la categoría DR,podemos conseguir alto accuracy clasi�cando todos los documentos como DR, lo que produciría de todosmodos un sistema malo, ya que el usuario pre�ere que retornemos algún documento antes que ninguno.Es decir, los usuarios suelen tolerar algunos falsos positivos en favor de conseguir algunos verdaderospositivos (Manning et al., 2008).

1En español el término re�ere a cuan "correcto" es el criterio de selección de documentos.

F-measure se utiliza para establecer una solución de compromiso entre recall y precisión. La medida Fes la media armónica ponderada de la precisión y el recall:

F =1

α 1P + (1− α) 1

R

=

(β2 + 1

)PR

β2P +R

Donde β = 1−αα y α ∈ [0, 1]. Para hacer una ponderación equivalente de precisión y recall tomamos α = 1

2(β = 1). Si quisiéramos darle mayor importancia a la precisión utilizaríamos β < 1 mientras que β > 1prioriza el recall.

Ejemplo 2.1.2. Para ver por qué la F-measure utiliza la media armónica por sobre la aritmética veamosque: recuperando el 100% de los documentos obtenemos como mínimo un 50% de media aritméticapor más que hayamos recuperado 1 documento relevante sobre 10.000 recuperados. Por el contrario, siaplicamos la media armónica obtenemos:

F =2×

(1

10000

)×(11

)(1

10000

)+(11

) = 0,00019 ∼ 0,02 %

Con este pequeño ejemplo se ve como la media armónica (la cual es siempre menor o igual a la aritmética)es una mejor medida para la efectividad de un sistema de IR.

En esta subsección hemos presentado las medidas básicas que nos permiten evaluar en términos cuanti-tativos las decisiones que tomamos al diseñar un sistema de IR. En la próxima subsección presentaremosdistintos modelos de IR, cuya efectividad se mide en términos de estas métricas.

2.1.4. Modelos de Information Retrieval

Introducción

Para explicar qué es un modelo de Information Retrieval podemos utilizar una analogía:

Normalmente los fenómenos físicos se analizan mediante un modelo de la realidad. Este modelo establecesuposiciones e idealizaciones que permiten utilizar deducciones para resolver una versión simpli�cada delproblema real.

En el campo de las ciencias de la computación el panorama es muy similar: los problemas de InformationRetrieval también se resuelven planteando suposiciones e idealizaciones que nos permiten simpli�car lacomplejidad del problema subyacente. Estas suposiciones e idealizaciones forman parte de modelos deInformation Retrieval.

Otro enfoque es el planteado por (Baeza-Yates et al., 1999): el factor central de un sistema de IR es ladeterminación de cuáles son los documentos relevantes para una query. La decisión acerca de la relevanciade los documentos suele estar dada por algoritmos de puntuación (los mejor puntuados serán los másrelevantes). A su vez, estos algoritmos de puntuación operan de acuerdo a premisas básicas respecto de lanoción de relevancia de documentos. Ésas premisas son las que producen distintos modelos de IR. Dentrode un sistema de IR, quien determina qué es relevante es el modelo de information retrieval.

Como se desprende de los párrafos previos (especialmente del segundo enfoque), la decisión de qué modelode IR utilizar es central al sistema. Esta decisión tiene fuertes implicancias en la indexación, recuperacióny valoración de los documentos y determinará buena parte del éxito del sistema.

En esta subsección nos dedicamos a formalizar y conocer los modelos más populares de IR para luegopoder analizar cómo se implementan en los casos de estudio y proponer una implementación para nuestromotor de búsqueda sobre objetos.

Formalización

Es posible establecer una formalización matemática acerca de qué es un modelo de IR. La siguientede�nición pertenece a (Baeza-Yates et al., 1999):

De�nición 2.1.1. Un modelo de Information Retrieval es una 4-upla [D,Q,F,R (qi, dj)] donde:


D es un conjunto de representaciones de documentos en la colección.

Q es un conjunto de representaciones de las necesidades de información del usuario llamadasqueries.

F es un marco de trabajo (framework) para modelar representaciones de documentos, queries y susrelaciones.

R(qi, dj) es una función de puntaje2 con dominio en el conjunto Q ×D e imagen en los númerosreales.

Esta de�nición permite uni�car los modelos clásicos de IR bajo un mismo marco formal (para mayordetalle se puede consultar Baeza-Yates et al., 1999, p. 24).

A continuación vamos a tratar los llamados modelos clásicos de IR: booleano, vectorial y probabilístico.

Modelo Booleano

El modelo booleano está basado en operaciones de conjuntos entre términos de la query y los documentos.Las expresiones de búsqueda se convierten en una expresión booleana de términos (palabras) y operadoresAND, OR y NOT. La semántica de estos operadores lógicos se traduce en �la expresión debe estar presenteen el documento�, �puede estar presente� ó �no debe estar presente�. A continuación veremos un ejemplode una query en el sistema booleano.

Ejemplo 2.1.3 (Especi�cación booleana de consultas). A continuación vemos necesidades concretas deinformación y consultas booleanas para satisfacerlas.

Necesidad de información: �documentos acerca del emperador Julio Caesar�

query = julio AND caesar

Necesidad de información: �documentos acerca de Julio Caesar o Brutus�

query = (julio AND caesar) OR brutus

Necesidad de información: �documentos acerca del emperador Julio Caesar donde no se mencionea Brutus�

query = (julio AND caesar) AND NOT (brutus)

El modelo booleano clasi�ca los documentos como totalmente relevantes o totalmente irrelevantes segúncumplan con la condición booleana impuesta en la query. El modelo no incorpora intrínsecamente unamedida de relevancia o similitud entre queries y documentos. La única medida intrínseca es la dicotómica:�relevante� vs. �no relevante�. Si bien este modelo ha sido y sigue siendo ampliamente utilizado, estosfactores son una de las críticas principales hacia él (Baeza-Yates et al., 1999; Manning et al., 2008).

De�nición 2.1.2. Para el modelo booleano podemos de�nir la similitud entre una query q y un documentodj como:

Similitud(q, dj) =

{1 ⇐⇒ q se cumple en dj

0 ⇐⇒ q no se cumple en dj

A continuación presentamos algunos ejemplos de consultas en el modelo booleano.

Ejemplo 2.1.4. En este ejemplo resolvemos algunas consultas donde el documento se presenta al usuariosí y sólo si Similitud(q, dj) = 1.

De�nimos el conjunto Corpus = {d1, d2, d3} y la representación de sus documentos en términos:

d1 = {caesar, dictador, romano}

d2 = {hijo, caesar, octavianus}2El término �puntaje� se utiliza como equivalente del término �ranking� del inglés.

d3 = {brutus, conspirador, romano}

Veamos cómo resultarían algunas búsquedas booleanas sobre este corpus:

q1 : brutus→ {d3}

q2 : caesar AND brutus→ {∅}

q3 : brutus OR (hijo AND caesar)→ {d2, d3}

q4 : NOT (brutus)OR (hijo AND caesar)→ {d1, d2}

Las principales ventajas del modelo booleano son:

su simplicidad,

el soporte formal por la teoría de conjuntos,

buen grado de control al especi�car la consulta.

Las principales desventajas de este modelo nacen de su de�nición de similitud:

al no contar con noción de coincidencia parcial, la curva de recall vs. precisión varía bruscamentecon la adición y sustracción de términos,

necesita técnicas externas al modelo para ordenar el conjunto de resultados.

El modelo booleano original (el cual utiliza sólo AND, NOT y OR) es demasiado limitado para muchasaplicaciones prácticas, por lo cual se ha ido extendiendo para �exibilizar la recuperación. Algunas deestas operaciones extendidas son la búsqueda por proximidad y la utilización de comodines (ver subsec-ción 2.1.5). Estas mejoras en sus capacidades de recuperación junto a la sensación de control sobre susresultados son seguramente los factores que hacen que en la práctica aún sea muy utilizado.

Modelo Vectorial

En este apartado exponemos el modelo vectorial propuesto por Gerard Salton (Salton et al., 1975).

Entre las limitaciones del modelo booleano, vimos que la ausencia de una función de similitud intrínseca almodelo nos impide priorizar gradualmente los documentos en los cuales la query se ve mejor representada.El modelo vectorial resuelve este problema introduciendo la noción de coincidencia parcial entre queriesy documentos.

En el modelo vectorial, la función de similitud entre una query y un documento permite:

retornar documentos que no contienen todas las palabras de la búsqueda,

diferenciar la relevancia de dos documentos que contienen todas las palabras de la búsqueda,

calcular la similitud entre documentos.

A continuación presentamos algunas de�niciones necesarias para trabajar en el modelo vectorial (puedenencontrarse mayormente en Baeza-Yates et al., 1999).

De�nición 2.1.3 (Pesos de Relevancia). Sea un léxico de términos ki ∈ K , una query q y un documentodj de�nimos:

wi,q: relevancia del término ki en la query q

wi,j: relevancia del término ki en el documento dj

con w ∈ <+0 .

Destaquemos dos aspectos de la de�nición (2.1.3):

el modelo vectorial sólo permite relevancias wi,q y wi,j mayores o iguales a cero,

los términos ki tienen relevancias distintas según se encuentren en el contexto de la query o deldocumento.

Enunciemos otra de�nición para caracterizar al modelo:

De�nición 2.1.4 (Representación Vectorial de Documentos y Queries). Sea un léxico K de t ele-

mentos, una query q y un documento dj, de�nimos los vectores −→q = (w1,q, w2,q, . . . , wt,q) y−→dj =

(w1,j , w2,j , . . . , wt,j), donde wi,q y wi,j son los respectivos pesos de relevancia de los términos ki ∈ Ken q y dj.

Vemos entonces que en el modelo vectorial las queries y los documentos se representan como vectores enun espacio t-dimensional donde cada componente es la relevancia de cada término. Intuitivamente, losdocumentos que más se asemejan a una query son los que tienen su vector ~dj más próximo al vector ~q . Estacorrelación se puede cuanti�car utilizando la función coseno, la cual otorga un valor nulo para vectoresortogonales (irrelevantes entre sí) y un valor unitario para los vectores perfectamente correlacionados(relevantes entre sí).

De�nición 2.1.5 (Similitud en el Modelo Vectorial). Sea un léxico K de t elementos, una query q y undocumento dj, el modelo vectorial de�ne la similitud entre la query y el documento como:

Similitud (q, dj) = cos (q, dj) =

−→dj • −→q∥∥∥−→dj∥∥∥× ‖−→q ‖ =

t∑i=1

wi,j × wi,q√∑ti=1 w

2i,j ×

√∑tj=1 w

2i,q

(2.1.5)

En la de�nición (2.1.3) establecimos que wa,b ∈ <+0 , por lo tanto la función de similitud del modelo

vectorial toma valores continuos en el intervalo [0, 1].

A diferencia del modelo booleano, el vectorial establece un ranking de grano �no que permite ordenarlos documentos en forma gradual según su relevancia. Si bien la función de similitud es continua, estono quita que bien podríamos establecer un valor umbral para mostrar únicamente los documentos quecumplen Similitud(q, dj) > sumbral.

Es preciso notar que la representación vectorial no modela el ordenamiento relativo entre términos dentrode un documento o una query. Esta simpli�cación caracteriza al modelo como uno del tipo bag of words(bolsa de palabras).

A continuación vemos un ejemplo en el que vemos grá�camente los vectores y su similitud:

Ejemplo 2.1.5. Supongamos un léxico K = {Brutus,Caesar} y dos documentos que contienen dichas

palabras con relevancias ~d1 =(12 ; 4

5

)y ~d2 =

(34 ; 2

5

). Si efectuamos una query cuyo vector de relevancias

es ~q =(13 ; 4

5

), tenemos un escenario como el de la �gura (2.3):


Figura 2.3: Relación grá�ca entre una query y los documentos en el modelo vectorial.

Grá�camente, dado el ángulo que forma cada documento con la query, por simple inspección esperamosque Similitud(~q, ~d1) > Similitud(~q, ~d2). Efectuando el cálculo analítico:

Similitud(~q, ~d1

)=

2∑i=1

wi,q × wi,d1√√√√ 2∑i=1

w2i,q

√√√√ 2∑i=1

w2i,d1

=

1

3× 1

2+

4

5× 4

5√(1

3

)2

+

(4

5

)2√(

1

2

)2

+

(4

5

)2= 0, 9866

Similitud(~q, ~d2

)=

2∑i=1

wi,q × wi,d2√√√√ 2∑i=1

w2i,q

√√√√ 2∑i=1

w2i,d2

=

1

3× 3

4+

4

5× 2

5√(1

3

)2

+

(4

5

)2√(

3

4

)2

+

(2

5

)2= 0, 7738

A diferencia del modelo booleano, vemos que por más que los dos documentos contienen ambos términos,podemos establecer un ranking basado en la relevancia de cada término en la query y los documentos.

El modelo vectorial que hemos de�nido hasta aquí no menciona cómo calcular los pesos de relevanciawi,q y wi,dj (de hecho existen muchas fórmulas distintas para el cálculo de pesos). A continuación vamosa de�nir algunos valores para luego describir una familia de pesos que busca resolver este problema:

De�nición 2.1.6. Dado un documento dj, una query q, un léxico K y un término ki ∈ K, de�nimos:

c (ki, dj) : cantidad de apariciones de ki en dj

c (ki, q) : cantidad de apariciones de ki en q

|dj | y |q| como las longitudes del documento dj y la query q

Nota: si bien las notaciones son similares, es preciso notar que |dj | y |q| no representan las normaseuclídeas de un vector sino la cantidad de términos que encontramos en el texto. Es decir, la longitud del

documento se calcula como |dj | =∑∀i

c (ki, dj) mientras que la norma es∥∥∥−→dj∥∥∥ =

√∑ti=1 w

2i,j.

Si nos detenemos a analizar la ecuación (2.1.5) podemos ver que los divisores∥∥∥−→dj∥∥∥ y ‖−→q ‖ cumplen

la función de normalización por longitud del documento y la query. Dado que en el contexto de una


búsqueda puntual el valor de ‖−→q ‖ es una constante para todos los documentos, la normalización de laquery sólo tiene sentido si queremos comparar puntajes entre búsquedas distintas. Por otro lado, el valor

de∥∥∥−→dj∥∥∥ sí es de mayor importancia ya que nos permite diferenciar documentos cuyos valores c (ki, dj)

son similares pero sus longitudes |dj | son muy distintas (es decir, nos ayuda a favorecer los documentoscon concentración de términos relevantes).

A continuación presentamos la familia de fórmulas TF-IDF (Term Frequency - Inverse Document Fre-quency), mediante la cual podremos obtener los pesos wi,j y wi,q:

De�nición 2.1.7 (Term Frequency). De�nimos tfi,dj como la cantidad de apariciones del término ki enel documento dj:

tfi,dj = c (ki, dj)

El valor de tfi,dj (en adelante también tft,d o simplemente tf ) nos indica cuán importante es un términot dentro de un documento dj . Esta medida es una heurística que propone una relación directa entre larelevancia de un término en un documento y su cantidad de apariciones.

De�nición 2.1.8 (Document Frequency e Inverse Document Frequency). De�nimos el valor dfi (documentfrequency) de un término ki como el número de documentos dj que contienen el término ki.

Recíprocamente, de�nimos inverse document frequency como:

idfi = logN

dfi

donde N es el número total de documentos en el corpus.

El valor de idfi (en adelante simplemente idf) se utiliza como heurística para conocer el poder de dis-criminación de un término ki. Esto es, si un término está presente en muchos documentos, su uso nosirve para discriminarlos (valores bajos de idf), pero si el término es muy especí�co (presente en pocosdocumentos) entonces su uso permite discriminar un conjunto de documentos potencialmente relevantes.

Utilizando TF-IDF podemos replantear la similitud entre q y dj como:

Similitudtf−idf

(~q, ~dj

)=∑ki∈q

tfki,dj × idfki (2.1.6)

Los valores tf e idf son ampliamente utilizados para generar fórmulas de relevancia. A continuaciónanalizaremos variantes de la fórmula (2.1.6) que nos permiten controlar mejor sus efectos. La descripciónde estas variantes siguen el desarrollo presente en (Manning et al., 2008).

TF sub lineal La de�nición (2.1.7) implica que la relevancia de un término aumenta linealmente conla cantidad de veces que éste aparece en un documento. Si tenemos los documentos d1 y d2 ; las cuentasc (ki, d1) = 30 y c (ki, d2) = 40; no es intuitivamente lógico que d2 sea un 25% más relevante que d1.

Para evitar este problema se plantea una variación al cálculo de tf :

wfki,dj =

{1 + log tfki,dj si tfki,dj > 0

0 otro caso

Si reemplazamos tf por wf en la fórmula (2.1.6), obtenemos una nueva fórmula de similitud menossensible a la repetición de términos.


Normalización de TF por Máximos En el párrafo anterior vimos cómo podríamos utilizar wf paraevitar que la repetición de términos produzca serios desajustes en tf . Sin embargo, wf es una medida�local� a cada término que no tiene en cuenta la longitud del documento ni la frecuencia del resto de lostérminos.

Buscando resolver estos problemas de�nimos una nueva medida:

ntfki,dj = a+ (1− a)tfki,djtfmax(dj)

En este caso introdujimos una variable a ∈ [0, 1], la cual suaviza el impacto en transiciones leves de tfki,dj(por ejemplo de 1 a 2). El valor de a se ajusta típicamente en 0,4 (Manning et al., 2008).

La idea de este método es notar que los documentos largos tienen tendencia a repetir los términos, porlo que deberíamos normalizar los valores respecto del término con más apariciones.

Este método tiene los siguientes inconvenientes:

cambios en la lista de stop words (ver subsección 2.1.5) impactan bruscamente en los valores dentf ,

un documento puede contener un término inusualmente frecuente que no sea representativo delcontenido del documento,

si un documento tiene una distribución de frecuencias de términos uniforme debería ser tratado deforma distinta que uno que acumula frecuencias alrededor de un conjunto de términos.

Sumado a las características que enumeramos al comenzar este apartado, a continuación presentamosalgunas ventajas y desventajas del modelo vectorial.

Las principales ventajas son (Baeza-Yates et al., 1999):

el esquema de pesos mejora la calidad de la recuperación respecto del modelo booleano y permiterecuperar documentos parcialmente coincidentes con la query,

incorpora una función de relevancia continua inherente al modelo,

permite buscar documentos similares entre sí.

Las desventajas del modelo vectorial son:

al igual que el resto de los esquemas clásicos, los términos del léxico son considerados de maneraindependiente, es decir no se modelan interdependencias entre términos (en el próximo apartadoejempli�caremos esto al presentar el modelo de independencia binaria),

es más difícil de mantener que el sistema booleano (requiere que mantengamos datos globales comoel número de apariciones de los términos en el corpus).

Si bien el modelo ya tiene veinticinco años de antigüedad, sigue siendo adoptado en muchos sistemas deIR gracias a que da muy buenos resultados con un costo de implementación aceptable.

Es preciso notar que el modelo vectorial no es mutuamente excluyente con el booleano sino que puedencomplementarse. En sistemas con corpus extensos, podríamos utilizar el modelo booleano para determinarel conjunto de documentos recuperables y luego utilizar el modelo vectorial para ordenarlos y recortarlossegún un umbral. En la subsección (2.4.1) tomaremos como primer caso de estudio un sistema que utilizaesta estrategia.


Modelo Probabilístico

El tercer modelo clásico que vamos a mencionar interpreta la relevancia en términos de probabilidades yes conocido como modelo probabilístico (Robertson y Jones, 1976). Este modelo se tomó en cuenta desdeprincipios de la década de 1970 por su capacidad de llevar los problemas de IR a un terreno formal �rme(Manning et al., 2008).

El modelo probabilístico será presentado brevemente ya que su desarrollo es algo más extenso que losanteriores y, como veremos más adelante, no produce resultados muy distantes del modelo vectorial.Persiguiendo esta brevedad seguimos el desarrollo de (Baeza-Yates et al., 1999) el cual es similar al de(Manning et al., 2008) (para más detalle se sugiere consultar este último o el trabajo original referenciadoal principio del apartado).

Dentro de los modelos probabilísticos, presentaremos el más simple conocido como modelo de indepen-dencia binaria (binary independence model ó BIM ). Las asunciones del BIM son:

los documentos se representan de forma booleana (esto es, un vector de unos y ceros indicando lapresencia/ausencia de un término),

la ocurrencia de dos términos distintos es estadísticamente independiente entre sí,

los términos que no se encuentran en la query no afectan a los resultados,

la relevancia entre documentos es estadísticamente independiente.

Estas simpli�caciones son cuestionables ya que existen casos particulares donde fallan. La segunda asun-ción es especialmente cuestionada ya que términos como Hong y Kong ó New y York están fuertementerelacionados estadísticamente.

Continuando con la presentación del modelo, asumamos una noción binaria de relevancia tal que undocumento sólo puede pertenecer a uno de dos grupos: relevantes ó no relevantes. Bajo esta asunciónpodemos de�nir una variable aleatoria:

R(d, q) =

{1 ⇐⇒ d es relevante para la query q0 ⇐⇒ d no es relevante para la query q

Es decir, R(d, q) es una variable aleatoria bidiscreta binaria, la cual no es nula sólo para los documentosrelevantes para la query. En adelante nos referimos a R(d, q) simplemente como R.

Dada una necesidad de información puntual, la propuesta del modelo es presentar a los documentos pororden decreciente de probabilidad de relevancia P (R = 1|d, q). El modelo probabilístico se basa entoncesen la siguiente asunción (Robertson, 1977):

Principio Probabilístico del Puntaje 3 Si la respuesta de un sistema de IR a cada pedido de unusuario es una lista de documentos puntuados por orden decreciente de probabilidad de relevanciapara quien efectuó el pedido, donde las probabilidades se estiman de la forma más precisa posible enla base de los datos que estaban disponibles al sistema para este propósito, entonces la efectividadgeneral del sistema para este usuario será la mejor que se pueda obtener en base a ésos datos.

Este principio tiene el inconveniente de que no nos da un indicio acerca de cómo calcular esta probabilidadde relevancia, por lo que tenemos que buscar otra medida de similitud (Baeza-Yates et al., 1999).

Dada una query q, el modelo asigna a cada documento dj una medida de similitud dada por la relación

Odds(dj relevante para q) =P (dj relevante para q)

P (dj no relevante para q).

De�nición 2.1.9. Sean:

un conjunto de términos q,

el conjunto de documentos inicialmente relevantes R y su complemento R,

3La versión original del inglés se puede encontrar tanto en (Robertson, 1977) como en (Manning et al., 2008).


los pesos binarios wi,j y wi,q tal que wi,j ∈ [0, 1], wi,q ∈ [0, 1] (ver de�nición 2.1.3),

la probabilidad P(R|~dj

)de que un documento dj sea relevante para la query q,

la probabilidad P(R|~dj

)de que un documento dj no sea relevante para la query q,

entonces el modelo probabilístico de�ne la similitud del documento dj con la query q como:

Similitud (dj , q) =P(R|~dj

)P(R|~dj

) (2.1.7)

Utilizando la regla de Bayes sobre la ecuación (2.1.7) obtenemos:

Similitud (dj , q) =P(~dj |R

)× P (R)

P(~dj |R

)× P

(R)

donde P(~dj |R

)se interpreta como �la probabilidad de obtener dj al azar entre los documentos relevantes�

y P (R) como �la probabilidad de que un documento tomado al azar sea relevante�. Como es de esperar,

P(~dj |R

)y P

(R)son los respectivos complementos.

Dado que P (R) y P(R)no varían documento a documento, podemos tomarlos como una constante y

quitarlos de la fórmula de similitud obteniendo:

Similitud (dj , q) ∼P(~dj |R

)P(~dj |R

)A continuación utilizamos la asunción de independencia entre términos del BIM, lo que nos permiteexpandir la ecuación anterior en una productoria término a término:

Similitud (dj , q) ∼

∏g( ~dj)=1

P (ki|R)

× ∏g( ~dj)=0

P(ki|R

) ∏g( ~dj)=1

P(ki|R

)× ∏g( ~dj)=0

P(ki|R

)donde P (ki|R) se interpreta como �la probabilidad de que el término ki esté presente en un documento

al azar tomado de R� y g(~dj

)vale 1 para los términos que están en la query y 0 para los que no están

presentes.

Si tomamos logaritmos y consideramos que P (ki|R)+P(ki|R

)= 1, esta expresión puede ser reformulada

como:

Similitud (dj , q) ∼t∑i=1

wi,q × wi,j ×

[log

P (ki|R)

1− P (ki|R)+ log

1− P(ki|R

)1− P

(ki|R

)]

la cual es una expresión clave para el cálculo de relevancia en el modelo probabilístico (Baeza-Yates et al.,1999).

Dado que inicialmente no conocemos el conjunto R, para calcular la similitud necesitamos estimar P (ki|R)y P

(ki|R

). Existen diferentes métodos para computar estos valores, una forma es asumir que (a) P (ki|R)


es constante para todos los términos del índice y (b) inferir que la mayoría de los documentos serán norelevantes para aproximar P

(ki|R

)con la estadística global, lo que se traduce en:

P (ki|R) = 0, 5

P(ki|R

)=niN

donde ni es el número de documentos que contienen el término ki y N el número total de documentosen el corpus.

Si bien no queremos profundizar más en el tema, cabe destacar que existen mejores métodos para estimarP (ki|R) y P

(ki|R

)así como existen otros modelos además del BIM que producen fórmulas de similitud

similares a las del modelo vectorial (Manning et al., 2008).

Las principales ventajas del modelo probabilístico son:

se basa en un marco teórico �rme,

incorpora una función de relevancia continua inherente al modelo.

Las desventajas del modelo probabilístico son:

la necesidad de conjeturar la separación inicial entre documentos relevantes y no relevantes,

para el caso de utilizar el BIM, asunciones como la independencia entre términos pueden ser pocorealistas.

En la práctica ocurre que algunos modelos comienzan siendo vectoriales y luego migran al probabilísticoefectuando algunas variaciones en las fórmulas de similitud (Manning et al., 2008).

Otros Modelos de IR

Existen muchos otros modelos de IR derivados de los que hemos presentado. Algunos de ellos son: mod-elo booleano extendido, modelo vectorial generalizado, fuzzy sets, latent semantic indexing (LSI), redesneuronales y bayesianas.

Estos modelos pueden reemplazar a los clásicos una vez que estamos convencidos que los primeros noson adecuados para resolver el problema. Adelantándonos a la explicación de los modelos a elegir para lapropuesta (capítulo 3), podemos decir que los modelos clásicos proveen una buena base para construir elmotor de búsqueda sobre objetos, por lo que preferimos profundizar en técnicas de matching o priorizacióny no en so�sticar los modelos de IR.

Respecto de las fórmulas de similitud; Fang, Thao y Zai proponen comparar las fórmulas de relevanciasurgidas de distintos modelos de IR de�niendo un conjunto de criterios funcionales a satisfacer (Fanget al., 2004). Estos criterios o premisas son similares a las que hemos propuesto durante la exposicióndel modelo vectorial al describir TF sub lineal y normalización por máximos. Las premisas se formalizanprincipalmente en términos de TF, IDF y otras estadísticas para luego evaluar fórmulas de relevanciavectoriales y probabilísticas, analizando el grado de cumplimiento de las premisas. Las conclusiones alas que arriban los autores es que cada modelo tiene una parametrización ligada a criterios funcionalesconcretos que determinan un rango de validez para sus parámetros.

2.1.5. Técnicas de Matching y Acceso a Datos

En las subsecciones previas clasi�camos los sistemas de IR y presentamos sus métricas y modelos másimportantes. En esta subsección vamos a explicar las distintas técnicas que nos permiten implementarestos sistemas y modelos de IR.


Índices Invertidos

Si tuviéramos que procesar la query caesar AND brutus del ejemplo (2.1.4), la forma ingenua de hacerlosería recorrer línea por línea todos los documentos del corpus, quedándonos con aquellos que contienenlas dos palabras. Esta forma de solucionar el problema equivale a procesar los documentos uno a uno conel comando grep de Unix. Otra solución similar sería utilizar consultas like de SQL sobre una tabla de unRDBMS, cuyos campos contengan el cuerpo del documento.

Si el problema a resolver es pequeño o surge de una consulta ad-hoc que sólo necesita ejecutarse unavez, el modelo grep o el like puede ser su�ciente. Ahora, si queremos recuperar información rápidamenteen colecciones de millones de documentos, efectuar consultas avanzadas (por ejemplo: �Caesar a 5 pal-abras de distancia de Brutus�) y establecer un puntaje para los resultados como en el modelo vectorial,necesitaremos de un índice invertido (Manning et al., 2008).

Un índice invertido o archivo invertido es una estructura de datos similar a un mapa cuya clave es untérmino y su valor es una lista de identi�cadores de documentos. Las claves del índice invertido formanel léxico ó diccionario mientras que los valores de cada clave son las posting lists. Cada documento de laposting list es un posting. En la �gura (2.4) podemos ver la estructura del índice invertido:

Figura 2.4: Diccionario y Posting Lists. A la izquierda se ven los términos y a la derecha la lista dedocumentos coincidentes.

Los índices invertidos se utilizan principalmente para recuperar y valorizar los documentos de formae�ciente. A continuación presentamos un ejemplo de construcción del índice invertido:

Ejemplo 2.1.6. Construyamos un índice invertido para los documentos del ejemplo (2.1.4). Para con-struir el índice necesitamos llevar a cabo estos pasos:

1. Transformar las palabras del documento dj en términos ki pertenecientes al léxico K obteniendo unmapa dj →

(ki, ki+1, . . . ,ki+Nj−1

)donde Nj es el número de términos distintos en dj.

2. Invertir el mapa obteniendo un nuevo mapa / índice: ki →(dj , dj+1, . . . ,dj+Mj−1

)donde Mj es el

número de documentos donde aparece el término ki.

Apliquemos estos pasos sobre los documentos del ejemplo (2.1.4):

1. (d1 → {caesar; dictador; romano} ; d2 → {caesar;hijo; octavianus} , d3 → {brutus; conspirador; romano})

2. Invertimos las listas:

caesar →(d1, d2)

dictador →(d1)

romano→(d1, d3)

hijo→(d2)

octavianus→(d2)

brutus→(d3)

conspirador →(d3)

Si ahora quisiéramos efectuar la consulta caesar AND brutus OR conspirador vemos que basta con inter-sectar y unir listas del índice:

[caesar = (d1, d2)∩ brutus = (d3)] ∪ conspirador = d3

El objetivo del índice es entonces acelerar la recuperación de documentos, permitiéndonos acceder rápida-mente a la lista de documentos que contienen un término. Dependiendo cómo esté implementado el índice,el costo de acceso a los posting lists varía desde el simple acceso a un archivo hasta técnicas complejasque involucran compresión, front coding, árboles B, etc. A continuación presentamos algoritmos para laconstrucción del índice y algunas variantes para su implementación.

Construcción del Índice

Dependiendo de modelo de IR, debemos considerar distintos componentes en la construcción del índice.

Para el modelo booleano nos alcanza con un índice como el del ejemplo (2.1.6), esto es, un mapa detérminos a documentos.

En el modelo booleano, para acelerar la intersección entre conjuntos, es conveniente construir el índiceordenando las posting lists por identi�cador de documento (docID). Si la posting list está ordenada, laintersección se puede efectuar mediante el siguiente algoritmo:

Algoritmo 2.1 Intersección de dos posting lists cuando los docID están ordenados de forma ascendente.

pub l i c L i s t <DocID> i n t e r s e c t ( S t r i n g k1 , S t r i n g k2 ) {L i s t <DocID> r e s u l t s = new Ar r a yL i s t <DocID>() ;L i s t <DocID> l i s t A = g e t P o s t i n g L i s t ( k1 ) ;L i s t <DocID> l i s t B = g e t P o s t i n g L i s t ( k2 ) ;

i n t indexA = 0 ;i n t indexB = 0 ;whi le ( indexA < l i s t A . s i z e ( ) && indexB < l i s t B . s i z e ( ) ) {

// docID1 == docID2docID1 = l i s t A . ge t ( indexA ) ;docID2 = l i s t B . ge t ( indexB ) ;i f ( docID1 . e qua l s ( docID2 ) ) {

r e s u l t s . add ( docID1 . c l o n e ( ) ) ; // i d é n t i c o a hace r docID2 . c l o n e ( ) ;indexA++; indexB++;

} e l s e i f ( docID1 . g rea te rThan ( docID2 ) ) {indexB++;

} e l s e {indexA++;

}}return r e s u l t s ;

}

Este algoritmo aprovecha el ordenamiento de las claves para avanzar el puntero sobre la posting list queaún puede aportar coincidencias (si una lista se acaba con un docID menor al de la otra lista, la segundano necesita seguir siendo recorrida) y no requiere recorrer completamente todas las posting lists.

Sin embargo, si los documentos no están ordenados, podríamos resolver la intersección mediante unalgoritmo como el siguiente:

Algoritmo 2.2 Intersección de dos posting lists cuando estas no están ordenadas por docID.

L i s t <DocID> i n t e r s e c t ( S t r i n g k1 , S t r i n g k2 ) {L i s t <DocID> r e s u l t s = new Ar r a yL i s t <DocID>() ;L i s t <DocID> l i s t A = g e t P o s t i n g L i s t ( k1 ) ;L i s t <DocID> l i s t B = g e t P o s t i n g L i s t ( k2 ) ;

L i s t <DocID> sho r t e s t , l a r g e s t ;

i f ( l i s t A . s i z e ( )< l i s t B . s i z e ( ) ) s h o r t e s t = l i s t A ;e l s e s h o r t e s t = l i s t B ;

Set<DocID> sma l l S e t=new HashSet<DocID>() ;sma l l S e t . addA l l ( s h o r t e s t ) ;whi le ( i n t i =0; i<l a r g e s t . s i z e ( ) ; i++) {

i f ( sma l l S e t . c o n t a i n s ( l a r g e s t . ge t ( i ) ) ) r e s u l t s . add ( l a r g e s t . ge t ( i ) ) ;}return r e s u l t s ;

}

Notemos que a diferencia del caso previo, el algoritmo (2.2) obliga a leer completamente las posting listspero no requiere ordenarlas (lo cual puede ser costoso).

Estos algoritmos son similares a los utilizados para resolver juntas en una base de datos. En particular,el segundo es conocido como hash-join.

Si queremos optimizar un índice para un modelo de IR con puntajes como el vectorial, podemos almacenarlos puntajes de los documentos en el índice mismo, ordenando las posting lists por estos puntajes. Dadoque el usuario suele recibir sólo una pequeña porción de los resultados totales, podemos acelerar labúsqueda recuperando los N documentos de mejor puntaje y trabajar con esas listas reducidas de hastaN elementos.

Otras estadística que podemos almacenar en el índice son los valores de las fórmulas TF-IDF. Paraesto podemos almacenar df a la cabeza de cada término (notar que df es la longitud del posting list) einsertar el valor de tf junto a cada posting. Para usos como las búsquedas por proximidad (ver subsección2.1.5), también es conveniente almacenar junto a cada posting el conjunto de posiciones donde ocurrió lacoincidencia. Esta última técnica también es útil para mostrar un resumen del texto con la coincidenciaresaltada (esto es conocido como Keyword In Context o KWIC ).

Para la construcción física del índice se pueden utilizar una variedad de métodos que dependen de:

el método de almacenamiento del índice (archivos, bases de datos, etc),

tipo de acceso al índice (sólo lectura vs. lectura y escritura),

la escala del sistema (corpus, hardware, nivel de concurrencia, etc).

Para resolver el problema del almacenamiento del índice, se debe implementar una estructura de datosconocida como diccionario. El diccionario actúa como un mapa de términos a posting lists. Los candidatospara almacenar un diccionario son mapas hash y arboles B.

Si el sistema es relativamente pequeño, el índice se puede cargar en memoria y luego refrescarlo periódica-mente. Otra alternativa es utilizar una base de datos, la cual resuelve los problemas de concurrencia yalmacenamiento físico de los posting lists (normalmente utilizando árboles B). Por otro lado, cuando elíndice es de cierta envergadura, se suele almacenar en archivos ad-hoc. A continuación veremos algunastécnicas de construcción de índices en archivos, las cuales pueden adaptarse para almacenar el índice enun RDBMS.

Para generar el índice normalmente se utilizan variantes de dos algoritmos que presentaremos a contin-uación: Indexación por Ordenamiento en Bloques4 (algoritmo 2.3) e Indexación por Barrido Simple enMemoria5 (algoritmo 2.4).

4Traducción del inglés �Block sort-based indexing�.5Traducción del inglés �Single-pass in-memory indexing�.

Algoritmo 2.3 Pseudocódigo Java para el método de Indexación por Ordenamiento en Bloques.

/∗∗∗ I n d e x a c i ó n por Ordenamiento en Bloques .∗ − Reco r r e una ún i c a vez l o s da tos y gene ra pa r e s <termID , docID>∗ − Mantiene en memoria un mapa [ t e rm ino −> termID ]∗∗ 1 . Re co r r e r l a l i s t a de documentos∗ 1 .1 Token i za r e l documento generando para cada té rm ino un termID

ún i co∗ 1 .2 Agregar a l b loque l o s pa r e s <termID , docID>∗∗ 2 . S i procesamos más de ' maxBlockSize ' documentos o no tenemos∗ más para p r o c e s a r en tonce s almacenamos e l b loque en d i s c o∗ y renovamos l a s e s t r u c t u r a s de da tos∗∗ 3 . Con s o l i d a r l o s b l oque s e s c r i t o s en e l í n d i c e f i n a l∗∗/

pub l i c void i n d e x ( L i s t <Document> docL i s t , i n t maxBlockSize ) {HashMap<St r i ng , I n t e g e r > termMap = new HashMap<St r i ng , I n t e g e r >() ;I ndexB lock i d xB l o ck = new I ndexB lock ( ) ;

f o r ( I t e r a t o r <Document> i t = do cL i s t . i t e r a t o r ( ) ; i t . hasNext ( ) ; ) {i d xB l o ck . addPa i r s ( t o k e n i z e ( i t . nex t ( ) , termMap ) ) ;

i f ( i d xB l o ck . g e t S i z e ( )>=maxBlockSize | | i t . hasNext ( )==f a l s e ) {// ordenamos por termID y luego por docID// y c r e a l a s p o s t i n g l i s t si d xB l o ck . s o r tAnd I n v e r t ( ) ;

// grabamos e l b loque a d i s c o y l o regeneramosi d xB l o ck . saveToDisk ( ) ;i d xB l o ck . r e s e t ( ) ;

}}saveTermMap ( termMap ) ;me rg eB l o ck s I n t o I ndex ( termMap ) ;

}

El algoritmo (2.3) es simple pero tiene el problema de que requiere almacenar en memoria principalla correspondencia entre términos e identi�cadores de términos, lo cual puede ser excesivo en algunoscorpus. Para evitar esto, existe una técnica conocida como Indexación por Barrido Simple en Memoria(ver pseudocódigo Java en algoritmo 2.4):

Algoritmo 2.4 Pseudocódigo Java para el método de Indexación por Barrido Simple en Memoria.

/∗∗∗ I n d e x a c i ó n de S imple Ba r r i d o en Memoria∗ − Reco r r e una ún i c a vez l o s da tos∗ − No u t i l i z a i d e n t i f i c a d o r e s de t é rm ino s∗ − Genera i n d i c e s comp le tos p a r c i a l e s que l u ego se c o n s o l i d a n∗∗ 1 . Re co r r e r l a l i s t a de documentos∗ 1 .1 Para cada token busca r su p o s t i n g l i s t s y a lmacenar su docID∗∗ 2 . S i a lcanzamos e l l í m i t e de memoria almacenamos e l í n d i c e i n v e r t i d o∗ p a r c i a l en un a r c h i v o y renovamos l a s e s t r u c t u r a s de datos∗∗ 3 . Con s o l i d a r l o s í n d i c e s p a r c i a l e s en e l í n d i c e f i n a l∗∗/

pub l i c void i n d e x ( L i s t <Document> docL i s t , i n t maxPost ings , i n t maxDictS ize ){

I n v e r t e d I n d e x p a r t i a l I n d e x = new I n v e r t e d I n d e x ( ) ;

f o r ( I t e r a t o r <Document> i t = do cL i s t . i t e r a t o r ( ) ; i t . hasNext ( ) ; ) {Token i z e r tokens = new DocumentTokenizer ( i t . nex t ( ) ) ;

whi le ( tokens . hasMoreElements ( ) ) {p a r t i a l I n d e x . addPos t ing ( tokens . nextE lement ( ) , tok . getDocID ( ) ) ;

i f ( p a r t i a l I n d e x . ge tPos t i ngCount ( )>=maxPost ings | |p a r t i a l I n d e x . g e tD i c t i o n a r y S i z e ( )>=maxDictS i ze )

{p a r t i a l I n d e x . saveToDisk ( ) ;p a r t i a l I n d e x . r e s e t ( ) ;

}}

}me r g ePa r t i a l I n d e x e s ( ) ;

}

Para que el algoritmo (2.4) sea e�ciente, se debe almacenar cada bloque con su diccionario y posting listsordenadas. De esta manera el paso de consolidación puede recorrer secuencialmente todos los archivosen una única iteración (podría hacerse en etapas si fueran demasiados) y consolidar las listas término atérmino. Si las posting lists están ordenadas, consolidarlas será más simple ya que sólo requerirá compararvalores avanzando secuencialmente sobre todas al mismo tiempo.

Tal como fueron presentados, los algoritmos (2.3) y (2.4) son esencialmente centralizados porque nobalancean la carga de la indexación entre varias computadoras. Además de estos algoritmos centralizados,en corpus extensos podemos utilizar algoritmos de indexación distribuida.

Para efectuar una indexación distribuida es posible utilizar un modelo de programación llamado MapRe-duce (Dean y Ghemawat, 2008). Este modelo consiste en dividir �un gran trabajo� en pequeñas tareassimilares, las cuales pueden llevarse a cabo en paralelo por muchas computadoras. El algoritmo (2.5)implementa la indexación distribuida utilizando MapReduce:

Algoritmo 2.5 Pseudocódigo Java para indexación distribuida con MapReduce.

/∗∗∗ I n d e x a c i ó n D i s t r i b u i d a u t i l i z a n d o MapReduce .∗∗ El p roc e so comprende l o s s i g u i e n t e s pasos :∗ 1 . D i v i s i ó n de documentos en N mappers∗ 2 . Procesamiento d e l documento en l o s mappers∗ 3 . D i s t r i b u c i ó n de l o s pa r e s ( termino , docID ) ha c i a l o s r e d u c e r s∗ 4 . Merge y s o r t de l o s pa r e s ( termino , docID ) por té rm ino ( y∗ opc i ona lmente por docID )∗ 5 . Reducc ión de l o s pa r e s ( termino , docID ) a ( termino , l i s t a de docID )∗∗/

/∗∗∗ La f un c i ó n Map r e c i b e documentos , l o s d i v i d e en tokens y∗ emi te pa r e s ( termino , docID )∗/

pub l i c void Map( Input<Document> input , Output<St r i ng , I n t e g e r > output ) {L i s t <St r i ng> tokens = t o k e n i z e ( i n pu t . getE lement ( ) ) ;f o r ( S t r i n g token : tokens ) {

output . add ( token , doc . g e t I d ( ) ) ;}

}

/∗∗∗ El r educe r e c i b e todas l a s em i s i o n e s ( docID ) de una misma c l a v e ( t é rm ino

)∗ y gene ra e l p o s t i n g l i s t en l a forma ( te rm ino −> [ docId1 , . . . , docIdN ] )∗/

pub l i c void Reduce ( Input<St r i ng , I t e r a t o r > input , Output<St r i ng ,L i s t > output ) {

S t r i n g term = i n t p u t . getKey ( ) ;I t e r a t o r d o c I d I t e r a t o r = i npu t . ge tVa lue ( ) ;L i s t p o s t i n g L i s t = new L i n k edL i s t () ;

whi le ( d o c I d I t e r a t o r . hasNext ( ) ) {p o s t i n g L i s t . add ( i t . nex t ( ) ) ;

}

output . add ( term , p o s t i n g L i s t ) ;}

Para implementar el algoritmo anterior debemos contar con un framework que implemente MapReducecomo Hadoop (Apache, 2010). Al tratar la indexación o�ine de nuestra propuesta de solución, veremosque es factible indexar un dominio en forma distribuida sin utilizar MapReduce o Hadoop.

Indexación Dinámica

Al abordar los algoritmos para la construcción del índice, no nos hemos preocupado por saber qué ocurrecuando el sistema se encuentra en funcionamiento y ya existe un índice productivo. El problema deindexar documentos y agregarlos a un índice existente se conoce como indexación dinámica. La indexacióndinámica es de nuestro especial interés porque al indexar objetos se debe considerar su frecuencia decreación, actualización y eliminación.

Si el índice se mantiene en una base de datos, su actualización no presenta ningún inconveniente ya que


las propiedades ACID nos permiten agregar y eliminar documentos independientemente de las consultasque se hagan a la tabla.

Por el contrario, si decidimos almacenar el índice en archivos, debemos considerar cómo actualizarlos �encaliente� de forma tal que las tareas de búsqueda no inter�eran con las de indexación. Veamos algunasformas de resolver el problema de la indexación dinámica sobre archivos:

Reindexación Completa Esta es la solución más simple y consiste en regenerar el índice completa-mente �desde cero�. Esta solución tiene como principal ventaja su simplicidad pero requiere de espaciosu�ciente para mantener el índice actual mientras se genera la nueva versión. Además debemos considerarque el tiempo para generar el índice puede ser prohibitivo en corpus grandes. Esta opción es viable en loscasos en los que la frecuencia de actualización del corpus es baja y el retardo en hacer visibles los nuevosdocumentos es aceptable (Manning et al., 2008).

Índices Auxiliares y Generacionales Este método consiste en mantener un índice principal quecontiene la mayor cantidad de documentos y disponer pequeños índices auxiliares para agregar los nuevosdocumentos. Para manejar las eliminaciones sin requerir la actualización física del índice, se puedenutilizar vectores de invalidación (bit vectors), los cuales utilizan el bit j para indicar si el documento djexiste. Periódicamente se fusionan los índices principales y los auxiliares y se eliminan los documentosmarcados en el vector de invalidación. En la subsección (2.4.1) veremos que Apache Lucene aplica unaestrategia similar.

Archivos Indexados En este caso se generan un archivo índice (posiblemente implementado con ár-boles B) y un archivo de datos con las posting lists. Este esquema permite actualizar el índice con facilidadpero puede ser costoso de implementar (equivale a resolver problemas típicos de un RDBMS). Un análisiscompleto de esta alternativa se presenta en (Cutting y Pedersen, 1990).

Operaciones Extendidas

La búsqueda de términos en un índice invertido es una forma e�ciente de encontrar documentos cuandosomos efectivos en escoger los términos que producirán mayor relevancia. Sin embargo, hay casos en losque no estamos seguros de cuáles son los mejores términos y necesitamos de cierta ayuda adicional.

A continuación presentamos algunas técnicas que �exibilizan la tarea de recuperación.

Búsquedas de proximidad Consiste en especi�car la distancia máxima entre dos términos. Por ejem-plo, la búsqueda Caesar AND/5 Brutus retornaría el documento Brutus fue hijo de Caesar pero no eldocumento Caesar fue asesinado por el senado con la ayuda de Brutus. El objetivo de esta técnica esrecuperar documentos donde las palabras se encuentran en un mismo contexto.

Las búsquedas por proximidad se pueden resolver utilizando un índice posicional, el cual mantiene juntoa cada posting las posiciones donde podemos ubicar el término en el documento original.

Otra variante de implementación es efectuar una búsqueda lineal sobre los documentos recuperados,�ltrando los que no cumplan con el criterio de proximidad. Esta variante tiene peor rendimiento perorequiere menor espacio de almacenamiento en el índice y disminuye tanto su complejidad como la delproceso indexador.

Phrase Queries Este tipo de búsquedas son conocidas también como búsquedas literales. Las búsquedasliterales pueden verse como un caso particular de búsquedas de proximidad en el cual se deben cumplir:

la proximidad entre los términos de la query es exactamente uno

la proximidad se aplica sólo hacia adelante (es decir, la query rosa salmón no equivale a salmónrosa).

La implementación de las phrase queries se basa nuevamente en índices posicionales o en �ltrado dedocumentos.


Wildcards Los wildcards son símbolos que nos ayudan a buscar todos los términos que siguen un patrónespecí�co. Por ejemplo, en SQL los wildcards se especi�can mediante el símbolo%, mientras que en un�lesystem, es común especi�carlos con el símbolo *. En un search engine los wildcards se utilizan cuandoconocemos la forma de una parte del término de búsqueda pero no podemos especi�carlo completamente.Utilizando wildcards, queries como bol* retornan documentos que contienen las palabras bolsa, bolero,bola, etc.

Las búsquedas por wildcards se pueden resolver utilizando índices permuterm (Gar�eld, 1976) ó n-gram(ver Zobel y Dart, 1995).

Edit distance Cuando la query contiene pequeños errores de ortografía, podemos reconvertirla buscan-do términos �cercanos� al original. Para lograrlo, podemos utilizar una medida de distancia entre términosdel léxico llamada edit distance ó Levenshtein distance (Levenshtein, 1965). La idea general detrás deledit distance es calcular cuántas inserciones, modi�caciones y eliminaciones hay que efectuar sobre dosstrings para que uno se convierta en el otro. El edit distance se puede calcular fácilmente utilizandoprogramación dinámica.

Un procedimiento para corregir una query por medio de edit distance es correr el algoritmo sobre lostérminos del léxico y la query, suplantando ésta por los términos de menor edit distance. Una vez obtenidoslos candidatos de menor edit distance, se accede al índice invertido utilizando el conjunto ampliado detérminos.

Para que este procedimiento no sea excesivamente costoso existen heurísticas como asumir que lasprimeras n letras de la query son correctas y calcular el edit distance sólo sobre los términos del léx-ico que comienzan con esas letras.

Una variante a los edit distance es la utilización de un tesauro. Esta técnica la veremos en las próximassubsecciones.

Range Queries Las búsquedas por rango o range queries consisten en especi�car un criterio (rango),el cual debe cumplirse en el documento para que éste sea recuperado. Ejemplos: 2009 to 2010, Brutus toCaesar (aquí el rango es por orden lexicográ�co) ó Bares en Rivadavia al 1000 to 1900.

Este tipo de búsquedas se pueden resolver de distintas formas. Una forma de resolver el problema consisteexpandir la query en forma de una conjunción dentro del rango. Esta solución tiene como principalproblema la granularidad de la expansión ya que queries como 1,1 to 1,999 ó 1 to 1.000.000 serán demasiadocostosas de implementar.

Otra opción de implementación es recorrer el léxico y �ltrar los términos que cumplen con el criterio delrango. Para léxicos moderados esta puede ser una opción factible. Una tercera vía de solución consisteen utilizar un índice de búsqueda como los utilizados en un RDBMS.

Por supuesto también podemos resolver este problema mediante pos �ltrado de resultados. Este esquemarequiere eliminar los términos de la disyunción (en caso de recuperación booleana) y luego recorrer losresultados �ltrando los documentos.

Para resolver este problema, ciertos motores no utilizan el operador to o el hasta de nuestros ejemplossino que el usuario debe explicitar cómo efectuar la búsqueda dando una ayuda acerca del tipo de datosdel rango y su granularidad.

Las búsquedas literales, wildcards, por rangos y edit distance son soportadas en Apache Lucene (ver casosde estudio en subsección 2.4.1).

Búsquedas Facetadas Tradicionalmente han coexistido dos modelos de búsqueda, el modelo de nave-gación y el modelo de búsqueda directa (SIGIR, 2006).

En el modelo de navegación, el usuario especi�ca iterativamente el tema de interés navegando a travésde una taxonomía (cuyas categorías no necesitan ser necesariamente excluyentes entre sí). Ejemplosde este modelo se implementan en Google Directory (http://directory.google.com), Yahoo! Directory(http://dir.yahoo.com) y Open Directory Project (http://www.dmoz.org/). Por otro lado, en el modelode búsqueda directa el usuario escribe una búsqueda en lenguaje natural para luego navegar a través


de páginas de resultados o re�nar iterativamente los términos de búsqueda. Los ejemplos de búsquedadirecta son los buscadores de Google (http://www.google.com) y Yahoo! (http://www.yahoo.com).

La combinación de estos dos modelos de búsqueda han dado lugar a un tercer modelo, la búsqueda facetadao faceted search.

En la búsqueda facetada el usuario comienza una búsqueda directa y el motor de búsqueda presenta losresultados junto a una categorización por características ortogonales entre sí. En la �gura (2.5) vemos unejemplo de búsqueda facetada en el marketplace e-Bay (http://www.ebay.com).

Figura 2.5: Búsqueda Facetada. Al buscar un ipod, podemos �cortar� los resultados en distintas facetaso dimensiones. En este caso las facetas son el tipo de producto, la condición, capacidad y color. Otrasfacetas podrían ser el precio, la garantía, etc.

Si bien en el caso de la �gura (2.5) se efectuó una búsqueda directa, bien podríamos llegar al mismolanding6 utilizando el modelo de navegación (el cual suele permitirse en los sitios de comercio electrónicocomo e-Bay). La diferencia principal reside en que el landing obtenido por navegación no es un modelomixto sino que es una navegación a través de una taxonomía.

Un desafío que se presenta al implementar las facetas es el hecho de que los resultados pueden ser muyheterogéneos, por lo cual la elección de facetas como el �color� de un reproductor de música sólo podríanaparecer cuando eliminamos otros resultados que no admiten dicha faceta (como por ejemplo una �fuentede alimentación�).

La búsqueda facetada no es implementada directamente por ninguno de los casos de estudio de la sec-ción (2.4), sin embargo, sí es implementada por una derivación del proyecto Lucene conocida comoSolr (http://lucene.apache.org/solr/). En nuestra propuesta de solución vamos a retomar este tipo debúsquedas.

Stemming y Lematización

Si bien las operaciones extendidas nos permiten mejorar la coincidencia entre la query y los términosdel léxico, siguen operando sobre un espacio de alta dimensionalidad (según el modelo vectorial de la

6El término �landing� se utiliza para referir a la página donde se llega luego de una búsqueda.


subsección 2.1.4). Si reducimos las dimensiones del problema proyectando los términos sobre un espaciode menor orden, posiblemente obtengamos un mayor recall. La proyección de un espacio sobre otro demenores dimensiones implica necesariamente pérdida de información, la cual naturalmente se traduciráen peor precisión.

A continuación vamos a explicar las técnicas de stemming y lematización, las cuales buscan reducir elnúmero de dimensiones del léxico con la menor pérdida de información posible.

Lematización El proceso de lematización busca remover las formas �exivas de las palabras para obteneruna versión canónica del término llamado lema.

La lematización es un proceso complejo que requiere llevar una palabra del diccionario a otra palabra deldiccionario, reconociendo correctamente cuál es el lema del término ingresado (normalmente esto requierereconocer el POS7 del término).

Veamos un caso práctico en el siguiente ejemplo:

Ejemplo 2.1.7. Efectuemos la canonización de algunas �exiones del verbo escribir:

lema(escribiendo)=escribir

lema(escrito)=escribir

lema(escribí)=escribir

El proceso de lematizar términos es una solución de compromiso entre recall y precisión que puede sermás o menos útil dependiendo del lenguaje. De los casos de estudio que tomamos en la sección (2.4),ninguno utiliza por defecto un lematizador.

Un caso práctico de lematización automática se describe en (Galceran, 2006), donde además se concluyeque la distribución de lemas en un texto promedio se encuentra muy concentrado alrededor de unospocos lemas. Un ejemplo de lematizador online se puede encontrar en (Grupo de Estructuras de Datos yLingüística Computacional, 2006).

Stemming El proceso de stemming consiste en transformar palabras con el �n de colisionar términosde semántica similar en un mismo término (el cual no necesita ser una palabra del diccionario comoocurría con el lema). El resultado de aplicar stemming a una palabra es un stem8. A continuación vemosalgunos ejemplos de stemming en español.

Ejemplo 2.1.8. Efectuamos el stemming de una lista de palabras utilizando un stemmer Snowball (vermás adelante):

stem(tornado)=torn

stem(tornados)=torn

stem(tornar)=torn

Como podemos ver en el ejemplo anterior, el stemming logra colisionar en torn los términos de semánticasimilar tornado y tornados. Un problema que debe observarse en el ejemplo anterior es que tornado (cuyaacepción principal podría referir al fenómeno meteorológico) colisiona en su stem con el de tornar (cuyasemántica re�ere al acto de �convertir una cosa en otra�). Este problema derivado de la heurística empleadapara buscar los stems es conocido como overstemming.

Implementativamente, los stemmers son un conjunto de reglas aplicadas en orden para transformar yeliminar su�jos de palabras. Al igual que el lematizador, el stemmer es una herramienta que incrementael recall a costa de la precisión. Normalmente, un stemmer es más agresivo que el lematizador en cuantoa las colisiones que genera ya que se basa en heurísticas y no en un análisis morfológico de las distintasin�exiones del vocabulario.

7El término POS (part of speech) del inglés se utiliza para referir a la identi�cación de una palabra como verbo, adjetivo,sustantivo, adverbio, etc. Por ejemplo, los POS de la frase �escribiendo el libro� son (verbo,artículo,sustantivo).

8El término �stem� se traduce al español como �raíz�, lo cual mani�esta la intención del stemming de encontrar unaraíz entre palabras similares semanticamente. No se debe confundir la raíz obtenida del stemming con la verdadera raíz dellenguaje correspondiente, ya que la segunda sí es una palabra del diccionario.


Existen implementaciones de stemmers para muchos lenguajes, para el inglés la más conocida es la versiónde Porter (Porter, 1980), mientras que para lenguajes como el castellano contamos con stemmers derivadosde los algoritmos snowball que describiremos en el próximo apartado.

Es preciso notar que el stemming no es aplicable a todos los lenguajes. Un ejemplo de esto es el chino,el cual no permite el simple truncado sus palabras. El stemming tampoco tiene la misma efectividaden todos los lenguajes. Por ejemplo, en lenguajes como el inglés el stemming es menos efectivo que enespañol o francés ya que estos últimos son más �exivos (Porter, 2001).

Stemmers Snowball Snowball es un lenguaje para la generación automática de algoritmos de stem-ming (Porter, 2001). El propósito de snowball fue crear un lenguaje común a partir del cual poderespeci�car stemmers para distintos lenguajes.

A partir de snowball han surgido stemmers para lenguajes como inglés, francés, español, portugués,italiano, rumano, alemán y muchos otros.

Los casos de estudio que vamos a analizar en la sección (2.4) utilizan stemmers construidos mediantesnowball.

Expansión de Consultas

A pesar de nuestros esfuerzos de matching mediante stemming o lematización, el problema subyacente ala tarea de recuperación es complejo por las distintas formas de expresión y las ambigüedades que surgendel uso del lenguaje.

A continuación de�nimos y ejempli�camos estas relaciones del lenguaje, las cuales presentamos grá�ca-mente en la �gura (2.6).

Sinónimo �Dicho de un vocablo o de una expresión: Que tiene una misma o muy parecida signi�caciónque otro.� (RAE, 2006). Los sinónimos son palabras que comparten la misma semántica. Ejemplos:después vs. luego, comencé vs. empecé, violonchelo vs. cello.

Parónimo �Se dice de cada uno de dos o más vocablos que tienen entre sí relación o semejanza, por suetimología o solamente por su forma o sonido.� (RAE, 2006). En general los parónimos son palabrascon pronunciaciones iguales o similares pero semántica distinta. Ejemplos: maya vs. malla, concejovs. consejo, vaya vs. valla (en particular estos parónimos además son homófonos).

Merónimo y Holónimo Cuando en dos palabras una de ellas constituye semanticamente la parte de untodo representado por la otra, la parte es llamada merónimo y el todo es conocido como holónimo.Ejemplos: dedo es merónimo de su holónimo mano, país es holónimo de su merónimo provincia.

Hiperónimo e Hipónimo Cuando en dos palabras una de ellas constituye semanticamente un conceptoparticular y la otra representa un concepto general, el concepto particular es llamado hipónimo yel concepto general es el hiperónimo.


asiento (verbo)

asiento (sust.)

automóvil

butaca

parónimos

merónimo

holónimo

merónimo

sinónimos

vehículohiponimo

hiperónimo

Figura 2.6: Relaciones entre palabras. En este ejemplo vemos la sinonimia, paronimia, meronimia ehiperonimia.

Estas relaciones del lenguaje traen consecuencias al motor de búsquedas, quien debe poder diferenciarentre parónimos, asociar sinónimos y contextualmente tratar de forma adecuada merónimos, holónimos,hipónimos e hiperónimos.

Por ejemplo, si nos encontramos en el contexto de un buscador de avisos clasi�cados, es común que existauna diferencia de vocabulario entre quien publica avisos y quien busca servicios. La persona que ofrece susservicios como mecánico de autos puede publicar el aviso reparación de Mercedez-Benz, Audi y Volkswagen,mientras que la persona que busca puede escribir la query servicio de chapa y pintura de Passat (siendoéste un modelo particular de la línea Volkswagen).

Las herramientas que poseen los motores de búsqueda para mejorar su conocimiento y capacidad de tratarexpresiones son los tesauros. Un tesauro es una colección de relaciones entre palabras y conceptos queayudan al sistema a encontrar la forma adecuada de mejorar la respuesta ante una query. En un tesauropodemos modelar las relaciones entre palabras, permitiendo expandir consultas utilizando sinónimos oformas canónicas de un concepto.

De�nición 2.1.10 (Expansión de Consultas). El proceso de expansión de consultas consiste en convertiruna query inicial q0 en una nueva query q1 de forma tal que el conjunto de métricas asociadas el éxitodel sistema mejoren sus indicadores.

La de�nición (2.1.10) es intencionalmente general porque (a) la elección de las métricas que indican eléxito del sistema es un problema en sí mismo con distintas soluciones (ver subsección 2.1.3) y (b) laexpansión de consultas normalmente se da mediante tesauros o relevance feedback.

En la actualidad existe una herramienta que modela las relaciones entre palabras conocida como WordNet(Princeton, 2010). Esta herramienta ha sido portada a varios lenguajes y puede ser útil para resolver losproblemas de sinonimia, meronimia, etc. En la �gura (2.7) podemos ver la versión web de WordNet 3.0.


Figura 2.7: Versión web de WordNet 3.0. Para la palabra �soccer� del inglés obtenemos conjuntos desinónimos y otras relaciones.

Si bien WordNet es una herramienta muy útil, el modelado de un dominio particular suele tener com-plicaciones adicionales como palabras en otros lenguajes o marcas comerciales como sony o notebook, locual hace difícil usarlo tal como se presenta. Además, en la �gura (2.7) podemos ver que si quisiéramosexpandir la consulta soccer (fútbol) utilizando relaciones como header, seguramente perjudicaríamos laprecisión debido a las relaciones de sinonimia de esta última (header se puede utilizar para referirse aencabezados de documentos).

Caches

Dependiendo de los volúmenes de datos y niveles de concurrencia del sistema de IR, es común que labúsqueda o la indexación de documentos utilicen intensivamente recursos como disco, red o el RDBMS.Las respuestas a operaciones repetitivas pueden reutilizarse para ahorrar recursos y mejorar los tiemposde respuesta del sistema. Esta reutilización se implementa por medio de memorias caché.

Existen distintos niveles de caché que responden a distintas granularidades de acceso a la información.En la capa más externa, de grano grueso, tenemos caches de páginas de resultados. Cuando la query delusuario es idéntica a otra query efectuada recientemente, los caches de páginas de resultados retornan unaversión servida con anterioridad. Es preciso notar que si las búsquedas se sirven de forma personalizada,la clave del caché (típicamente la URL) debe contener información que identi�que al usuario, de formade no servir a un usuario A un listado hecho a medida de un usuario B.

Un nivel más abajo, podemos tener un caché de resultados del índice invertido, el cual responde cuandoun usuario busca un conjunto de términos que ya ha sido buscado por el resto de los usuarios. Este tipo decaches suele ser muy efectivo ya que la entradas del índice invertido no deberían depender de un usuarioparticular, permitiendo alto reuso de las entradas en caché.

Si el número de objetos a almacenar es muy grande, podemos utilizar un caché externo como Memcached(Memcached, 2009). La utilización de un caché externo permite aumentar la tasa de aciertos (hit ratio)en caso de que las búsquedas o procesos de indexado corran en paralelo en varios equipos.


Es preciso notar que el caché de grano grueso como el de páginas de resultados tiene un hit ratio menora uno de grano �no (como el del índice invertido). Sin embargo, el caché de páginas típicamente agregael trabajo de confección del listado. Estos temas se discuten extensamente en (Baeza-Yates et al., 2008).

Para el caso de las búsquedas, debemos tener en cuenta que el nivel de uso concurrente del sistema sueleser una variable difícil de controlar, por lo que debemos estar preparados para utilizar caches donde seanecesario.

Como veremos al hablar de mapeos objeto relacionales (ORM, ver subsección 2.3.7) y al tratar HibernateSearch y Compass (subsecciones 2.4.2 y 2.4.3), el hecho de recuperar objetos desde un índice requiereobtener todos sus atributos mediante un proceso llamado hidratación. Si la hidratación se implementautilizando el ORM, es importante disponer de un caché que evite comunicación innecesaria con el RDBMS.Para esto, los ORM de mayor envergadura suelen implementar un caché a nivel de sesión (caché L1) yotro compartido entre sesiones (caché L2).

2.1.6. Técnicas de Puntaje y Relevancia

En esta subsección vamos a analizar técnicas para generar ordenamientos de documentos aplicables anuestro motor de búsqueda sobre objetos. En particular nos interesa saber cómo:

puntuar documentos más allá de la noción de relevancia dada por el modelo de IR,

indexar objetos cuya estructura excede la del texto plano,

utilizar técnicas de puntuación por relación entre documentos (PageRank y HITS),

mejorar la relevancia por medio de análisis de query logs y realimentación por parte del usuario.

Reglas de Negocio

Los modelos de IR que hemos analizado en la subsección (2.1.4) están orientados a recuperar y puntuarlos documentos desde el punto de vista de la relevancia.

Sin embargo, cuando se construye un sistema de IR se debe tener en cuenta que el éxito del mismo excedela capacidad de asociar documentos u objetos con queries. Las fórmulas de puntajes derivadas de las reglasdel negocio son las que tienen la última palabra acerca de cómo se presentan los resultados al usuario.Para esto se suelen utilizar variables de negocio (antigüedad del resultado, pago por posicionamiento, etc)como fuentes adicionales de puntaje, las cuales complementan la relevancia del modelo de IR.

Las distintas fuentes de puntajes se introducen en fórmulas matemáticas que determinan el orden �nalde los resultados. Mas allá del tipo de fórmula a utilizar, nos encontraremos con dos tipos de reglas:clusterización y posicionamiento. Las reglas de clusterización separan documentos en clases, mientrasque las reglas de posicionamiento priorizan documentos de forma interna a un cluster. Este tipo de reglastambién se las puede conocer como reglas duras y reglas blandas.

Los atributos del documento y la query se suelen utilizar como variables de entradas a algoritmos depuntuación. Esas variables de entradas se suelen llamar proxys. A continuación presentamos un ejemplode este modelo de puntajes.

Ejemplo 2.1.9 (Reglas duras y blandas). Un sistema de clasi�cados online prioriza sus avisos mediantelas siguientes reglas de negocio:

Los avisos se dividen en dos sectores: pagos y gratis. Los avisos pagos aparecen siempre primeroque los avisos gratis.

La relevancia dada por el modelo de IR es un valor entre 0 y 1 que se pondera como el 60% delpuntaje �nal del aviso.

La antigüedad del aviso pondera el 40% restante del puntaje, siendo este valor igual a 1− meses antiguedad

12.

Los avisos de más de 1 año de antigüedad no suman puntaje en este proxy.


Figura 2.8: Reglas duras y blandas. En este ejemplo generamos dos clusters: avisos pagos y gratuitos.Dentro de cada cluster opera la formula descripta en el ejemplo.

Para cumplir con la primera restricción podemos sumar un valor unitario a los avisos pagos y luegoponderar según la segunda y tercera restricción:

Score (q, dj) = 1×AvisoPago (dj) + 0, 6× Similitud (q, dj) + 0, 4×[1− Antiguedad (dj)

12

]Donde:

AvisoPago (dj) ∈ {0, 1} según si el aviso es pago o no.

Similitud (q, dj) ∈ [0, 1] según de�nido en la implementación del modelo de IR.

Antiguedad (dj) ∈ {0; 1; . . . ; 12} representando los meses del año.

En el diseño de la propuesta que presentaremos en el capítulo 3 tendremos en cuenta las reglas duras yblandas, proveyendo las herramientas necesarias para implementarlas en cada dominio.

Zonas y Campos

Usualmente, los documentos suelen contener meta datos o estructuras de mayor organización que elsimple texto libre. Un ejemplo podría ser un documento que contiene una fecha de creación, un autor yun cuerpo principal.

Estos meta datos o estructuras son conocidos como campos y zonas (Manning et al., 2008). Manningpropone distinguir estos dos conceptos llamando campo a un breve fragmento de meta datos y zona a uncampo de texto libre de mayor tamaño.

El hecho de contar con campos y zonas genera la oportunidad de efectuar queries más precisas sobredistintas partes de la estructura del documento. Por ejemplo, podríamos efectuar búsquedas por rangos(ver subsección 2.1.5) sobre ciertos campos y búsquedas booleanas sobre determinadas zonas.

Ejemplo 2.1.10. Supongamos que contamos con un sistema que almacena noticias estructurándolas en:publish-date, autor, title y content. Si contamos con la posibilidad de efectuar consultas booleanas sobre elcorpus de noticias, podemos pensar en las siguientes consultas:

autor:(Kevin*) AND publish-date:(2009) AND content:(taiwan china con�ict)

publish-date:(2001 to 2009) AND content:(stock market IPO)

Al introducir campos y zonas debemos replantearnos cómo valorizar los documentos en cada una de lasfórmulas de similitud de los modelos de IR.

En adelante, sin pérdida de generalidad, vamos a asumir que los campos se utilizan para �ltrado y sólonecesitamos incluir la zonas en el cálculo de similitud del modelo de IR.


De�nición 2.1.11 (Similitud Booleana para Zonas). Para el caso del modelo booleano, rede�nimos lasimilitud como la suma ponderada de la relevancia booleana en cada zona (Manning et al., 2008):

SimilitudBool−Zones (q, dj) =∑∀i

gi×SimilitudBool (q, dj [i]) (2.1.8)

donde:

gi ∈ [0, 1] es un valor que pondera la importancia de la zona i (constante para todos los documentos),∑∀i

gi = 1,

SimilitudBool (q, dj [i]) ∈ {0; 1} representa la similitud binaria de la query q en la zona i del docu-mento dj.

La de�nición (2.1.11) introduce valores gi asociados a la importancia de cada zona en un documento,pero no explicita cómo se deben escoger dichos pesos. El problema de elegir el valor de los pesos gi escrucial ya que afecta de manera determinante al éxito del sistema.

Para escoger dichos valores, podemos utilizar un método de aprendizaje supervisado en el cual etiquetamospares (qn, dj) mediante la función de entrenamiento Φ (qn, dj) ∈ [0, 1] , la cual da valores cercanos a 1 parapares relevantes entre si y cercanos a 0 para pares poco relevantes. Utilizando Φ (qn, dj), podemos obtener

los pesos gi ∈−→G planteando una función de costo ε

(−→G,Φ (qn, dj)

)para luego resolver el problema de

optimización:

arg mın−→G

∑∀n,j

ε[−→G,Φ (qn, dj)

] = arg mın−→G

∑∀n,j

[Φ (qn, dj)− SimilitudBool−Zones (qn, dj)]2

= arg mın

gi

∑∀n,j

[Φ (qn, dj)−

∑∀i

gi×SimilitudBool (qn, dj [i])

]2 (2.1.9)

Ejemplo 2.1.11. Obtengamos el valor óptimo de los pesos gi para documentos de 2 zonas (i = 2) y losresultados de una función Φ binaria (sólo toma los valores 0 y 1).

Para resolver el problema es conveniente realizar algunas de�niciones y simpli�caciones a la notación:

establecemos SimilitudBool (qn, dj [0]) = s0 (qn, dj) = s0 y SimilitudBool (qn, dj [0]) = s1 (qn, dj) =s1

de�nimos las variables Rij = {R00;R01;R10;R11} para indicar la cantidad de casos en los queΦ = 1 y a su vez hubo/no hubo coincidencia booleana en la zona i y j (R00 es el caso en el que nohubo coincidencia en ninguna zona, R10 indica que hubo coincidencia en la primera zona y no enla segunda, etc).

las variables Nij = {N00;N01;N10;N11} de forma idéntica a Rij, pero para el caso en el que Φ = 0.

dado que g0 + g1 = 1, podemos simpli�car de�niendo una única variable g/g0 = g → g1 = 1− g

Entonces debemos reemplazar estas variables en la ecuación (2.1.9):

∑∀n,j

[Φ (qn, dj)−

∑∀i

gi×SimilitudBool (qn, dj [i])

]2=

εtotal =∑∀n,j

{Φ− [s0g + s1 (1− g)]}2 (2.1.10)

Vemos las contribuciones aportadas en cada caso:


cuando s0 = 0 y s1 = 0 se produce una contribución Φ − [0× g + 0× (1− g)] = Φ. Variando Φpara sus valores 0 y 1 se obtiene una contribución de R00 (ver que estamos sumando R00 veces elvalor Φ = 1).

s0 = 0 y s1 = 1 produce una contribución [Φ− (1− g)]2. Variando Φ se expande en R01g

2 +

N01 (g − 1)2

s0 = 1 y s1 = 0 produce una contribución (Φ− g)2. Variando Φ se expande en R10 (1− g)

2+N10g

2

s0 = 1 y s1 = 1 produce una contribución {Φ− [g + (1− g)]}2 = (Φ− 1)2. Variando Φ se obtiene

N11.

Entonces reescribimos la ecuación (2.1.10) como:

εtotal = R01g2 +N01 (g − 1)

2+R10 (1− g)

2+N10g

2 +R00 +R11

Utilizando el hecho de que (g − 1)2

= (1− g)2:

εtotal = (N01 +R10) (1− g)2

+ (R01 +N10) g2 +R00 +R11

Diferenciando respecto de g e igualando a cero obtenemos:

dεtotaldg

= −2 (N01 +R10) (1− g) + 2 (R01 +N10) g = 0

goptimo =N01 +R10

N01 +R10 +R01 +N10

De esta manera obtenemos el estimador goptimo que minimiza el error cuadrático para el conjunto deentrenamiento.

Cuando las funciones Φ (qn, dj) o Similitud (qn, dj) no asumen valores binarios, el problema del ejemplo(2.1.11) se vuelve más difícil de resolver analíticamente. Para estos casos es necesario utilizar otros métodospara minimizar los errores de clasi�cación.

Al estudiar Apache Lucene (subsección 2.4.1) veremos que la heurística que utiliza para priorizar zonas(en la terminología de Lucene se habla de campos) es una alteración de la fórmula de puntajes muysimilar a la ecuación (2.1.8). La diferencia en el caso de Lucene es que los pesos gi pueden tomar valoresarbitrarios.

Un caso adicional a contemplar es cuando los documentos son heterogéneos. Este es el caso del buscadorsobre objetos que propondremos en el capítulo 3, siendo que las soluciones para dicho caso las posponemoshasta tratar la propuesta de solución.

PageRank y HITS

Los modelos de IR que hemos tratado hasta ahora ignoraban las inter relaciones entre documentos. Encasos como la búsqueda web, es bene�cioso tener en cuenta la relación entre documentos como una medidade la autoridad que tiene una página como fuente de información relevante.

En esta sección describiremos dos algoritmos muy conocidos que generan métricas de relevancia basándoseen la estructura del grafo que interconecta entes del dominio del problema, para luego en el capítulo 3analizar la factibilidad de incluir estos algoritmos en nuestro motor de búsqueda sobre objetos.

Para ser consistentes con la bibliografía, en esta subsección vamos a dejar de hablar momentáneamentede documentos para pasar a hablar de páginas. Mas allá de que este último término denota el uso deestos algoritmos en los buscadores web, no hay mayores diferencias entre una página y un documento.


PageRank El algoritmo PageRank descripto en (Page et al., 1998) fue utilizado como fuente de rel-evancia para el algoritmo de búsqueda del buscador web Google9. A continuación vamos a explicar losconceptos detrás de PageRank así como su mecánica de cálculo basándonos en (Austin, 2006).

La idea principal detrás de PageRank es dejar que las páginas se �voten� entre sí mediante hipervínculos.Para explicar este proceso es necesario introducir algunas de�niciones.

De�nición 2.1.12 (PageRank). Sea una página puntual Pi y un conjunto de páginas Pj ∈ Bi de impor-tancia I (Pj), cada una con lj hipervínculos apuntando a Pi, entonces de�nimos el valor:

PageRank (Pi) = I (Pi) =∑Pj∈Bi

I (Pj)

lj(2.1.11)

Según la de�nición (2.1.12), cada Pj que apunte a Pi emite un �voto� proporcional a su importancia(PageRank) e inversamente proporcional al número de enlaces presentes en ella.

Lo primero que notamos al analizar esta de�nición es que para calcular el PageRank de una páginadebemos conocer el de todas las que enlazan a ella. Otro aspecto a notar de la de�nición (2.1.12) es quelos valores de I (Pj) tienen sentido sólo en términos relativos a las páginas que entraron en el cálculo yno representan valores absolutos de importancia para todo el universo.

A lo largo de este apartado veremos cómo calcular simultáneamente los valores de I (Pi) mediante cálculomatricial y teoría de probabilidades. Comencemos con algunas de�niciones:

De�nición 2.1.13 (Matriz de Hipervínculos). De�nimos la matriz de hipervínculos H = [Hij ] de lasiguiente forma:

Hij =

{1/lj si Pj ∈ Bi(esto es, Pjapunta a Pi)

0 otro caso

Preventivamente podemos pensar en H como una matriz que expresa la probabilidad de que pasemos alazar de una página Pj a una Pi. Utilicemos la matriz H para rede�nir I (Pi):

De�nición 2.1.14 (Vector de PageRank). De�nimos el vector−→I = [I (Pi)] cuyas componentes son los

PageRank de cada página Pi tal que−→I = H

−→I . Esto es,

−→I es un autovector de H cuyo autovalor es

λ = 1.

Este tipo de autovectores cuyo autovalor es unitario se conoce como autovector estacionario.

El problema al que nos enfrentamos ahora es cómo obtener−→I . Para esto podemos utilizar un método

estándar para la obtención de autovectores conocido como el método de potencias:

−−→Ik+1 = H

−→Ik

Para utilizar el método de potencias debemos proponer un vector inicial−→I0 e iterar hasta obtener una

diferencia entre pasos menor a un valor umbral.

El siguiente problema con el que nos encontramos ahora es cómo asegurar que este procedimiento:

1. sea convergente,

2. no dependa del vector inicial−→I0,

3. nos entregue la información que estamos buscando.

9Google no ha dado a conocer cuál es la incidencia que hoy en día tiene PageRank en el puntaje de una página.


Con la formulación de H que hemos hecho a priori, ninguno de estos tres requerimientos se cumpleincondicionalmente.

Estos problemas se pueden resolver replanteando el modelo en un esquema de navegación al azar (randomsurfer, Page et al. 1998). Este modelo supone un usuario que sigue al azar los lj hipervínculos de Pj ,saltando aleatoriamente de página en página. Dado este esquema de navegación al azar, los autoresproponen considerar el PageRank como el tiempo promedio que se pasa en una página Pi llegando desdelas distintas páginas Pj .

Sin embargo, la navegación al azar tiene problemas al encontrarse con un sub grafo de la web que actúacomo sumidero. Si el grafo web contiene un sumidero (totalmente factible), una vez que navegamosdentro de él no podremos salir (de hecho los sumideros producen PageRank nulos para las páginasfuera del sumidero). Para resolver esta situación se plantea una operación adicional de teleportación. Lateleportación se implementa �jando un valor a las columnas nulas de H, modelando un salto aleatoriohacia cualquier página del grafo web. Formalizando:

De�nición 2.1.15. Sea la matriz H ∈ Rn×n como en la de�nición (2.1.13), entonces de�nimos:

la matriz A ∈ Rn×n cuyos valores serán nulos excepto para las columnas donde H sea nula, casoen el que los elementos de A tomarán el valor 1/n.

la matriz S ∈ Rn×n/S = H + A

Vemos entonces que A representa una probabilidad uniforme de teleportarnos desde una página sumiderohacia cualquier otra página del grafo web. En consecuencia, la matriz S es una nueva versión de H queno sufre del problema de PageRank nulos debido a sumideros.

Para poder utilizar el método de las potencias con S y asegurarnos que el proceso sea tanto convergentecomo correcto, necesitamos que S sea estocástica y primitiva (Austin, 2006). La condición de estocásticase cumple fácilmente porque la matriz cuenta con entradas positivas y la suma de sus columnas es unitaria.La condición de primitiva requiere que para algún m se cumpla que Sm tenga todas sus entradas positivas(esto se traduce en que luego de m iteraciones podremos navegar desde una página hacia cualquier otracon probabilidad no nula).

La solución �nal al problema se da introduciendo una dualidad en el comportamiento del navegante:

De�nición 2.1.16 (Google Matrix). Sea la matriz estocástica S de la de�nición (2.1.15), de�nimos lamatriz de Google:

G = αS + (1− α)1

con α ∈ [0, 1] .

La nueva matriz G incorpora el conocimiento de probabilidades surgido de los enlaces del grafo web másun comportamiento aleatorio de teleportación regulado por (1− α). El valor de α no sólo tiene que veren el grado de aleatoriedad introducido al modelo de navegación, sino que es responsable de la velocidadde convergencia del método (esto se relaciona con el método de las potencias y la magnitud del segundoautovalor de S).

Con esta de�nición, dado queG es una suma de matrices estocásticas, esta también lo es. Adicionalmente,como todas sus entradas son positivas, G también es primitiva. Estas dos propiedades nos aseguran laconvergencia por el método de las potencias, permitiéndonos calcular el PageRank mediante la fórmula:

−−→Ik+1 = G

−→Ik (2.1.12)

En conclusión, PageRank es un modelo heurístico de puntajes con sustento en una matemática �rme quenos permite obtener un puntaje estático dependiente de la estructura de enlaces del dominio (en este

caso, páginas web). Los autores han calculado el PageRank para 322 millones de links aproximando−→I

por−→I52 obteniendo un mínimo margen de error (Page et al., 1998).

La explicación que acabamos de dar muestra los conceptos y pasos más importantes para su cálculo.Nuestro interés en presentar PageRank es considerar estos conceptos para dar valor a la relación entreobjetos del dominio. En el capítulo 3 se retomará este problema para analizar qué grado de soportepodemos dar a este tipo de técnicas. Para profundizar acerca del cálculo de PageRank se puede consultar(Austin, 2006).


HITS Además del PageRank que acabamos de estudiar, existen otros métodos que tienen en cuentala estructura de links de las páginas web. Un método muy conocido es HITS (Hyperlink-Induced TopicSearch).

Conceptualmente, este método plantea que existen dos clases de páginas importantes: los hubs (concen-tradores) y authorities (autoridades, en el sentido de �referente acerca de un tema�). La propuesta esentonces asignar a cada página un puntaje como hub y otro como authority.

Las autoridades son páginas que contienen información de calidad acerca de un tema. Por ejemplo, si bus-camos el término Ingeniería, algunas autoridades podrían ser http://www.�.uba.ar (Facultad de Ingenieríade la UBA), http://www.ieee.org (IEEE) o http://www.cai.org.ar (Centro Argentino de Ingenieros).

Por otro lado, existen páginas concentradoras que no son en si mismas una fuente �nal de informaciónsino que apuntan a autoridades mediante un listado de enlaces acerca de un tema (un directorio comolos que vimos en la subsección 2.1.5 sería un caso de concentrador).

La heurística que podemos aplicar para valorizar páginas es pensar que un buen concentrador apunta abuenas autoridades y una buena autoridad es apuntada por buenos concentradores.

A continuación mostramos brevemente el procedimiento matemático para luego obtener el algoritmoHITS basándonos en el desarrollo propuesto en (Manning et al., 2008).

De�nición 2.1.17 (Puntaje de Hub y Authority). Dada una página v que enlaza a una página yi/v 7→ yi,de�nimos los puntajes hub h (v) y authority a (v) como:

h (v) =∑v 7→yi

a (yi)

a (v) =∑v 7→yi

h (yi)

De�nición 2.1.18 (Vector de Hub y Authority). Para una web de N páginas, de�nimos los vectores−→h = (h1, . . . , hn) y −→a = (a1, . . . , an), donde cada componente de los vectores son los puntajes respectivosde cada página como hub y authority.

Conceptualmente, una página incrementa su puntaje como concentrador si enlaza páginas con alto puntajede autoridad. Recíprocamente, una página es una buena autoridad cuando esta enlazada por buenosconcentradores.

De�nición 2.1.19 (Matriz de Adyacencia). De�nimos la matriz de adyacencia A, donde la componenteAij vale uno si la página i enlaza a la página j y cero en otro caso.

Ahora estamos en condiciones de reescribir las ecuaciones de la de�nición (2.1.17) utilizando la matriz deadyacencia:

−→h ← A−→a (2.1.13)−→a ← AT−→h

Dado que el término izquierdo de la ecuación (2.1.13) forma parte del derecho, podemos proponer uncálculo iterativo y reescribirla como:

−→h ← AAT−→h (2.1.14)−→a ← ATA−→a

Si en la ecuación (2.1.14) reemplazamos el signo← por un =, entonces−→h y −→a serían respectivamente los

autovectores deAAT yATA . Utilizando este último hallazgo reescribimos la fórmula (2.1.14) asumiendolos autovectores λh y λa:


−→h = (1/λh)AAT−→h (2.1.15)−→a = (1/λa)ATA−→a

Las actualizaciones iterativas de la fórmula fórmula (2.1.14) pueden ser escaladas por el autovalor apropi-ado, lo que equivale a utilizar el método iterativo de las potencias para encontrar los autovectores deAAT y ATA (Manning et al., 2008). Dado que el autovector principal de AAT y ATA es único, los

valores de−→h y −→a no solo son únicos sino que son estacionarios y sólo dependen la estructura de enlaces

de la web considerada (Manning et al., 2008).

Cuando estudiamos PageRank vimos que dicha medida no dependía de la query en particular10, sin em-bargo, para aplicar el concepto de concentrador y autoridades, el puntaje de Hubs y Authorities debecalcularse para un tópico en particular. Para esto existe un paso adicional que implica seleccionar unsubconjunto de la web que es potencialmente concentradora o autoridad acerca de un tópico para luegogenerar vectores

−→h y −→a respecto de dicho tópico. Existen distintas heurísticas para elegir este subcon-

junto, las cuales exceden el tratamiento que queremos dar a este sistema de puntajes.

Al igual que con PageRank, la combinación de los puntajes entregados por el modelo de IR, reglas denegocio y el análisis estructural (en este caso de enlaces) depende de la aplicación particular. Para unanálisis exhaustivo acerca de HITS puede consultarse (Kleinberg, 1999).

Relevance Feedback y Query Log Mining

Las técnicas de relevance feedback (en adelante también retroalimentación o simplemente de RF ) �buscaninvolucrar al usuario en el proceso de recuperación para mejorar el conjunto �nal de resultados� (Manninget al., 2008).

En general el ciclo de RF tiene los siguientes pasos:

1. El usuario especi�ca una query simple

2. El sistema retorna un conjunto inicial de resultados

3. El usuario marca qué resultados son relevantes y cuáles no lo son

4. El sistema computa una nueva representación de la necesidad del usuario y corrige el conjuntoinicial efectuando una nueva recuperación que tiene en cuenta la retroalimentación.

Existen técnicas de RF que requieren que el usuario indique explícitamente qué documentos son relevantesasí como técnicas menos intrusivas que se nutren de la relevancia implícita que surge de la interaccióncon el sistema. Esos dos modelos se llaman respectivamente RF explícito y RF implícito.

RF Explícito y Algoritmo de Rocchio Dentro del modelo vectorial de IR, Rocchio propuso unalgoritmo que reformula la query del usuario buscando mejorar su efectividad (Rocchio, 1971). Estealgoritmo utiliza la clasi�cación explícita de relevancia provista por los usuarios y comprende los siguientespasos:

1. El usuario inicia la búsqueda con una query inicial q

2. El usuario clasi�ca los resultados explícitamente, creando dos conjuntos: Dr para documentos rel-evantes y Dnr para los no relevantes

3. El sistema expande la query inicial q en una nueva query ˆqopt

10Existen adaptaciones que calculan el PageRank para tópicos particulares.


Los conjuntos Dr y Dnr son una aproximación de los verdaderos conjuntos Rq y Rq (relevantes y norelevantes). Si conociéramos estos últimos y asumiendo un modelo vectorial de IR, tendríamos que buscaracercar la query −→q al centroide del conjunto Rq, alejándolo del centroide de Rq. Esto equivale a resolverel problema de optimización:

−−→qopt = arg max−→q

{Similitud (q,Rq)− Similitud

(q,Rq

)}Bajo la fórmula de similitud del coseno, la separación óptima se da cuando (Manning et al., 2008):

−−→qopt = arg max−→q

1

|Rq|∑−→dj∈Rq

−→dj −

1∣∣Rq∣∣∑−→dj∈Rq

−→dj

(2.1.16)

El algoritmo propuesto por Rocchio varía la fórmula (2.1.16) para tener en cuenta que no conocemos losconjuntos Rq y Rq sino que tenemos sus aproximaciones Dr y Dnr. Teniendo esto en cuenta llegamos ala fórmula:

−−→qopt = α−→q0 +β

|Dr|∑−→dj∈Dr

−→dj −

γ

|Dnr|∑−→dj∈Dnr

−→dj (2.1.17)

Donde (α, β, γ) ∈ [0, 1] × [0, 1] × [0, 1] /α + β + γ = 1, −→q0 es la query inicial del usuario y −−→qopt es unestimador de la query óptima de la ecuación (2.1.16). En los casos en los que un componente de −−→qoptresulta negativo, éste se ignora (es decir, se iguala a cero).

La fórmula (2.1.17) produce una mezcla entre la query inicial−→q0 y los términos presentes en los documentosde Dr y Dnr. Es decir, si los documentos relevantes para la query glaciares suelen contener el términoantártida, entonces la versión modi�cada de la query dará mayor exposición a los documentos acerca deeste último término.

Hagamos algunas consideraciones prácticas acerca de este método:

En la práctica se ha encontrado que el feedback positivo (asignación de documentos a Dr) es de mayorutilidad que el feedback negativo (asignación a Dnr) (Manning et al., 2008). Si queremos ajustar lafórmula (2.1.17) para re�ejar este hecho, debemos escoger β → 1 y γ → 0.

También debemos notar que normalmente −→q0 tiene pocos términos, mientras que∑−→dj agregará poten-

cialmente muchos términos a la nueva query (además de que estamos agregando varios documentos, éstostienden a ser más largos que las queries). Al agregar términos debemos efectuar más accesos al índiceinvertido, lo cual seguramente degrade el rendimiento del sistema. Para contener este problema podemosexpandir la query solo con los n términos de mayor score en

∑−→dj .

RF Indirecto y Query Log Mining Comúnmente los usuarios buscan satisfacer sus necesidades deinformación en el menor tiempo posible, siendo muy difícil que se detengan a proveer feedback explícitosobre los resultados (sobre todo cuando los bene�cios de hacerlo no son claros). Para poder obtenerfeedback en un contexto donde el usuario no provee una clasi�cación explícita, tenemos que modelar lasacciones del usuario como actos de clasi�cación.

Este modelado se traduce en interpretar como señales de relevancia la concentración de clics en ciertosresultados o nodos de una taxonomía. Por otro lado, podemos interpretar hechos como abandono de lasesión, inactividad por periodos extensos, reformulación sistemática de queries o bajo CTR (click-thrurate o tasa de clics sobre impresiones) como señales de ausencia de resultados relevantes.

El método de inferir la clasi�cación utilizando la actividad indirecta del usuario se conoce como RFimplícito o indirecto.

En la práctica, los métodos derivados del RF indirecto son menos con�ables que los del RF explícito,donde el usuario juzga explícitamente los documentos (Manning et al., 2008). Esto es intuitivo ya quesiempre que haya un uso honesto de la herramienta, los juicios explícitos de relevancia tienen mayor�delidad que un modelado mediante timeouts, abandonos y CTR.


Para efectuar el RF indirecto necesitamos técnicas de análisis del �ujo de queries (también conocido comoquery log analysis o clickstream mining). Estos logs deben ser su�cientemente expresivos para permitirnosmodelar el uso del sistema. Es decir, si vamos a trabajar con medidas de CTR, debemos poder ordenarlos registros secuencialmente por usuario, lo que requiere contar con marcas de tiempo, identi�cadores desesión y la acción que efectuó el usuario.

Los logs de queries también tienen usos que van mas allá del relevance feedback como ser la generaciónde tesauros, análisis de uso del sistema, etc.

En nuestra propuesta del capítulo 3 retomaremos este tema para analizar cómo se puede incluir este tipode herramientas al hacer IR sobre objetos.

En este punto hemos completado la descripción necesaria del estado del arte en cuanto a Recuperaciónde Información.

Sobre el �nal de este capítulo (sección 2.4), retomaremos estos temas para describir y comparar lasherramientas del estado del arte, profundizando nuevamente durante los capítulos de desarrollo de lapropuesta y experimentación.

2.2. Modelos de Dominio

Esta segunda sección trata la segunda componente de nuestro problema: el diseño de software. Dado queestamos interesados en generar un framework de indexación y recuperación, es necesario que establezcamosbases objetivas sobre las cuales analizar las alternativas de diseño y construir nuestra propuesta.

La subsección 2.2.1 presenta los conceptos sobre los que tratará esta sección: modelos de dominio, frame-works, arquitecturas empresariales y patrones de arquitectura. Luego de sentar estas bases, en las subsec-ciones (2.2.2) y (2.2.3) profundizamos acerca de criterios de implementación.

2.2.1. De�niciones Generales

Las próximas subsecciones hablan de frameworks (qué son, tipos y características), arquitecturas em-presariales (sobre las cuales vamos a obtener el mayor provecho del motor de búsqueda sobre objetos),patrones de diseño y arquitectura (los que utilizaremos como conocimiento de base para discutir criterios eimplementaciones) , modelos de dominio (patrón de arquitectura utilizado para construir las aplicacionesque vamos a indexar), inversión del control e inyección de dependencias (técnicas que diseño que tienenconsecuencias sobre los frameworks como el que queremos construir).

Frameworks y Librerías

Para proponer el framework de indexación de objetos, primero debemos preguntarnos qué es un framework.

De�nición 2.2.1 (Framework). Un framework es un conjunto de clases que encarnan un diseño ab-stracto para solucionar una familia de problemas relacionados soportando reutilización en una mayorgranularidad a la de las clases (Johnson y Foote, 1988).

Un framework nace a partir de la observación y aprendizaje de un dominio de problema particular(Roberts y Johnson, 1996). La experiencia acumulada en un dominio de problema nos permite gener-alizar y crear abstracciones que resolverán un problema concreto. Por ejemplo: persistencia, rendering,remotización o indexación.

A continuación clasi�camos los frameworks en dos clases principales: caja negra y caja blanca (Johnsony Foote, 1988; Roberts y Johnson, 1996).

El tipo de framework en el que debemos proveer el comportamiento especí�co de nuestra aplicaciónmediante subclasi�cación es conocido como de framework de caja blanca. Para dar el comportamientopropio de nuestra aplicación, debemos subclasi�car clases del framework, implementando métodos en

2.2. MODELOS DE DOMINIO 45

forma polimór�ca. Los frameworks de caja blanca no pueden ser utilizados directamente sino que requierenque creemos clases especí�cas para utilizarlos. Este proceso de creación de clases requiere que tambiénsepamos cómo funciona el framework, por lo que son más difíciles de aprender (respecto de los de cajanegra que explicaremos en el próximo párrafo). Dos ejemplos de frameworks de caja blanca podrían ser(a) servlets de Java y (b) variantes del MVC en las que aportamos nuestro comportamiento especí�coextendiendo una clase Controller.

Por otro lado, existen frameworks en los cuales la comunicación se da mediante componentes que entiendenun protocolo especí�co. Estos frameworks son los de caja negra. El usuario de este tipo de frameworkprovee comportamiento a través de colaboración entre objetos. Los frameworks de caja negra no requierende la subclasi�cación, por lo que introducen menor acoplamiento y requieren menor conocimiento acercade cómo está construido el framework .

En los frameworks de caja blanca, el estado de cada instancia se encuentra implícitamente disponible atodos los métodos del framework como si fueran variables globales, mientras que en los de caja negra,los parámetros se deben declarar e intercambiar explícitamente. Además, los frameworks de caja blancaimplementan reglas internas la jerarquía de subclasi�cación, mientras que en los de caja negra las reglasson protocolares.

La madurez de un framework está dada por una transición que comienza con frameworks de caja blancahasta convertirse en un diseños reusables de caja negra (Roberts y Johnson, 1996).

Es importante poder distinguir un framework de una librería. Fowler de�ne una librería como un conjuntode funciones (hoy en día organizadas en clases) a las que uno puede llamar para luego retomar el �ujode control (Fowler, 2005). Según Fowler, la diferencia principal entre una librería y un framework es lainversión de control (ver subsección 2.2.3).

En esta sección comentaremos algunos aspectos relacionados con los frameworks, para luego retomarel tema al analizar los casos de estudio (subsección 2.4) y el comportamiento como framework de lapropuesta de solución.

Aplicaciones Empresariales

Las aplicaciones empresariales, tipo enterprise ó enterprise applications son uno de los distintos tipos desistemas posibles de construir. Este tipo de aplicaciones se desarrollan para soportar la actividad de unaorganización, ya sea ejecutando directamente el negocio o soportando sus procesos y �ujos de trabajo.

Las aplicaciones de este tipo se de�nen por ciertas características:

Envergadura: suelen ser grandes, costosas de construir y mantener; requieren de un equipo de trabajodedicado. Poseen múltiples pantallas para interactuar con usuarios. El volumen de informaciónprocesada y almacenada es relativamente grande.

Transversales: interconectan procesos y datos de distintas áreas y departamentos de la organización(Ej: contable, legal, atención al cliente, etc).

Integradores: suelen interconectar sistemas heterogéneos (de múltiples vendedores) y heredados.

Concurrentes y Distribuidos ó Clusterizados: soportan el acceso de múltiples usuarios concurrentesy pueden estar distribuidos geográ�camente o clusterizados para soportar altos niveles de concur-rencia.

Transaccionales: suelen funcionar realizando transacciones sobre un RDBMS.

Multicapa: requieren un diseño de múltiples capas (tier11).

Multiper�l: hay usuarios y roles diferenciados (Ejemplo: usuarios frontend que utilizan el sistema yusuarios backend que lo administran).

Seguridad y Certi�cación: al ser sistemas abiertos y que operan con datos sensibles se diseñan conla seguridad en mente. Dependiendo de las características de la organización, el diseño del sistemapuede estar sujeto a certi�cación de normas como SOX (SOX, 2002) y/o PCI (PCI, 2006).

11La traducción de �capa� es �layer� y no �tier� (cuya traducción es �feta�). Sin embargo, a menos que sea necesariodistinguir entre tiers y layers, utilizamos los términos de manera intercambiable.


Algunos ejemplos de sistemas empresariales:

reserva online de tickets aéreos,

banca electrónica,

voto electrónico,

tienda online de productos electrónicos,

sistemas de atención al público

Ejemplos de sistemas que no son enterprise:

juegos,

compiladores,

suites de dibujo y animación,

navegador web

Estamos especialmente interesados en indexar los objetos de aplicaciones enteprise por las siguientesrazones:

El volumen de información da lugar a la necesidad de hacer búsquedas de texto libre,

tienen diversidad de entidades, favoreciendo la necesidad de hacer búsquedas horizontales sobre losdatos (multi esquema),

tienen requerimientos particulares en materia de seguridad y distribución.

Vemos entonces que, siendo nuestro framework un �huésped� de este tipo de aplicaciones, el motor debúsqueda que construiremos debe funcionar en sintonía con estos requerimientos.

Patrones de Diseño y Arquitectura

Para comenzar con este apartado, recordemos la de�nición de patrón de diseño:

De�nición 2.2.2 (Patrón de Diseño). Son descripciones de objetos y clases comunicadas que se person-alizan para resolver un problema general de diseño en un contexto particular� (Gamma et al., 1995).

Ampliando esta de�nición, podemos decir que los patrones de diseño son soluciones reutilizables y probadaspara problemas recurrentes en el diseño de software.

Así como los patrones de diseño solucionan problemas de diseño comunes del desarrollo de software,existen problemas recurrentes desde el punto de vista de la estructura o arquitectura de un sistema, loscuales también pueden ser resueltos aplicando soluciones estándar.

Una pregunta importante que surge al analizar los patrones de arquitectura es ¾Qué es la arquitecturade un sistema?

Lo que caracteriza a la arquitectura de un sistema es (Fowler, 2002):

las decisiones de alto nivel acerca de cómo dividir una aplicación en partes,

las de�niciones acerca de las bases de una aplicación, decisiones que uno quiere tomar �lo antesposible�,

elecciones difíciles de cambiar una vez establecido el patrón de arquitectura, tienen efectos a largoplazo en el diseño,


de�niciones que eventualmente determinan qué responsabilidades se asignan a cada parte de laaplicación.

En base a los puntos anteriores se catalogan soluciones bien conocidas en un conjunto amplio de escenariosllamados patrones de arquitectura.

Como vemos, no es fácil de�nir con precisión qué es arquitectura en una aplicación ni tener la últimapalabra acerca de si un patrón cumple con los puntos enumerados anteriormente. Lo que hoy cumple conestos criterios puede dejar de hacerlo (por ejemplo, siendo simple de modi�car) y plantearnos la dudaacerca de si realmente era una decisión de arquitectura.

Los patrones que reunen mayor consenso acerca de su pertenencia a esta clase son: patrones de lógicade dominio (domain model, table module y transaction script), el service layer, la arquitectura en layersy los de patrones de presentación (model view controller y front controller). Seguramente los patronesque tratan acerca de cómo mantener conversaciones con los medios de persistencia también puedenconsiderarse patrones de arquitectura: Table Data Gateway, Row Data Gateway, Active Record y DataMappers.

Así como originalmente los patrones de diseño fueron clasi�cados en creacionales, estructurales y decomportamiento (Gamma et al., 1995), los patrones arquitecturales pueden clasi�carse según el tipo deproblema que resuelven o la capa de la aplicación donde aplican (Fowler, 2002).

En el próximo apartado se trata el patrón de arquitectura domain model, el cual constituye una partefundamental del problema a resolver ya que sus miembros (objetos de negocio) son los objetivos a indexarpor el motor de búsqueda.

Modelos de Dominio

En el capítulo 1 de�nimos la noción de modelo de dominio por Fowler y luego enunciamos una versiónalgo más rigurosa. Vamos a repasar brevemente la segunda de�nición que representa mejor nuestrasconvicciones:

Domain Model es un diseño de objetos que representa un dominio de problema de la realidad.

Este enfoque nos permite ver a los objetos como verdaderos modelos de entes de un dominio de problema.

Para cerrar esta de�nición profundizamos sobre las nociones de dominio de problema y realidad :

Realidad comprende cualquier tipo de idea que podamos concebir (un objeto concreto, el amor, el odio,la nada, etc).

Dominio de problema es una porción de la realidad que vamos a modelar.

Algunos ejemplos de dominios de problema podrían ser las cuentas bancarias, un �lesystem o la sin-cronización entre procesos.

Los modelos de dominio no son un concepto nuevo en el diseño de software, sino que implementan laspremisas básicas del diseño orientado a objetos. Dentro de un dominio particular se efectúa un análisissegún el cual se modelan entes de negocio junto a sus responsabilidades, protocolo y colaboraciones. Enun domain model encontraremos objetos como productos, personas, pagos, páginas web, etc.

El contexto de arquitecturas empresariales, Fowler propone al domain model como un patrón de arqui-tectura. Las alternativas en dicho contexto son el transaction script y el table module (Fowler, 2002). Acontinuación vamos a ejempli�car construyendo un pequeño modelo de dominio:

Ejemplo 2.2.1. En este ejemplo presentamos un modelo de dominio para una aplicación que implementauna red de contactos. Este modelo incluye las entidades fundamentales, sus relaciones y su comportamien-to no trivial (esto es, excluimos operaciones como los set y get de atributos).

User-stories: List<Story>-apps: List<Application>-photoAlbums: List<PhotoAlbum>-profile: ProfileStory-content-likesThis: List<User>**

PhotoAlbum-imageList: List<Image>-creation: DateImage-title-taggedUsers: List<User>1*1* +start()+end()MiniApplication

* *Profile-job-interests 11 contacto 1 *publicación

* *etiquetado * *le gustautiliza

Figura 2.9: Modelo de Dominio para una red social.

En este ejemplo se modelaron entidades de interés para el negocio junto con las operaciones que sonnecesarias. Veamos que la relación entre clases puede afectar la manera en la que un motor de búsquedapresentaría los resultados de una consulta. Por ejemplo, ante la búsqueda �Viaje a París� podemos pri-orizar los objetos Story que han sido más votados entre los usuarios o los PhotoAlbum de contactos dondeaparezcan fotos de París.

Es preciso mencionar algunos aspectos relacionados al comportamiento de los objetos:

Los modelos de dominio implementan las reglas de negocio de la aplicación. Estas reglas de negocio entranen acción al ejecutar servicios de negocio ó lógica de aplicación. Estos servicios de negocio son ejecutadospor consumidores ó clientes del negocio. Para desacoplar los consumidores del modelo mismo, es posibleutilizar el patrón Service Layer (Fowler, 2002). El service layer presenta una API bien de�nida hacia losconsumidores, actuando como un Façade (Gamma et al., 1995). Una variante de esta implementación deinterfaz �na entre los consumidores y el modelo es cuando el service layer actúa como objeto de negocio,orquestando la secuencialidad en la invocación de los objetos de dominio. En la �gura (2.10) vemosgrá�camente cómo se organizan estas capas.


Figura 2.10: Organización de capas en una aplicación enterprise con Service Layer, Domain Model y DataAccess Layer.

Habiendo comentado acerca de los datos y comportamiento en un modelo de dominio, podemos adelan-tarnos al análisis del problema y decir que, a los efectos del motor de búsqueda que vamos a construir,nos interesa el estado de los objetos (valores de los atributos persistentes de la instancia) y no su com-portamiento (métodos de la clase).

Los modelos de dominio expresan relaciones entre objetos por medio de subclasi�cación y colaboraciones.Estas dos relaciones deben ser tenidas en cuenta en la recuperación de objetos ya que introducen com-plejidades que no están presentes en sistemas clásicos de IR.

Tanto la subclasi�cación como las colaboraciones presentan situaciones ante las que debemos decidir cómoindexar los objetos. Veamos algunas de ellas:

Consolidación de la Jerarquía: cuando se indexa un objeto cuya jerarquía de�ne múltiples atributos,es necesario consolidar la lista de los atributos indexables de dicha jerarquía.

Relaciones Todo-Parte: si un objeto de tipo Persona contiene un objeto indexable de tipo Nombre,al efectuar una búsqueda que produce una coincidencia en los atributos de la clase Nombre, posi-blemente queramos recuperar el objeto de tipo Persona. Este problema se mani�esta en relacionestodo-parte, donde las partes son indexables pero el objeto recuperable es el todo.

Colecciones: si tenemos una clase Receta que contiene una lista de objetos Ingrediente, probablementeestemos interesados en indexar los objetos de la lista pero no la lista en sí misma. Para esto esnecesario diferenciar las colecciones de las relaciones todo-parte del caso anterior.

Referencias Circulares: si distintos objetos se referencian entre sí, debemos cuidar que la indexaciónno caiga en bucles in�nitos.

Identidad. para que un objeto indexable pueda ser hidratado12 debe proveer una identidad. Enocasiones esta identidad es un objeto complejo en sí mismo. Cuando esto sucede, si el motor debúsqueda necesita interactuar con el ORM para hidratar el objeto, debe ser capaz de almacenar laclave de forma de poder reconstruirla al momento de recuperarlo.

Para resolver las tareas que estuvimos mencionando, es necesario que el lenguaje de programación cuentecon capacidades de meta programación. En el caso del lenguaje en el cual desarrollaremos nuestro frame-work (Java), la meta programación está mayormente soportada mediante re�ection.

12La hidratación de un objeto del índice consiste en completar su contenido, el cual a priori sólo contiene su clave principal,con el resto de sus atributos. Este concepto lo revisaremos apropiadamente en las próximas secciones.


Estos últimos párrafos son una primera muestra de los problemas que aparecen al considerar la indexaciónde objetos cuya estructura y relaciones son de mayor riqueza que la del texto plano. La respuesta acercade cómo resolver estos problemas se di�ere hasta el capítulo 3, donde haremos propuestas concretasteniendo también en cuenta las soluciones aportadas por los casos de estudio (sección 2.4).

2.2.2. Independencia del Modelo de Dominio

A medida que evolucionan las necesidades del negocio, el modelo de dominio deberá re�ejar los cambios enéste. Dichos cambios generan la necesidad de actualizarlo y probarlo aisladamente. Estas dos actividadesrequieren el desacoplamiento entre el modelo de dominio y otras capas del sistema (Dahan, 2009).

Para entender mejor el problema veamos un caso concreto: en una aplicación enterprise la capa de pre-sentación puede ser especialmente volátil. Supongamos que con el paso del tiempo cambiamos nuestroframework de presentación, dejando de lado tecnologías de reemplazos de strings para pasar a herramien-tas como JSP. Si nuestro modelo de dominio es independiente, seguramente no tendremos mayores prob-lemas en migrar. Ahora, si nuestro modelo estaba acoplado a las vistas, la tarea de migración requeriráun esfuerzo de desacoplamiento. Para este caso, si la lógica de negocio fue mezclada con la lógica depresentación, generar una nueva vista (por ejemplo para dispositivos móviles) requerirá migrar códigoque no estuvo correctamente encapsulado.

Los conceptos subyacentes en el ejemplo anterior son la cohesión y desacoplamiento, quienes favorecenla reutilización y portabilidad del modelo. Para lograr estas premisas, necesitamos que los frameworksque interactúan con el modelo permitan la independencia del modelo.

A los efectos del motor de búsqueda que plantearemos en el capítulo 3, la independencia del modeloes un aspecto que queremos respetar para ser �buenos ciudadanos en el mundo de los frameworks�. Acontinuación vemos distintos ejemplos donde aparecen dependencias entre el modelo y los frameworksque componen la aplicación:

Ejemplo 2.2.2. Tomando el modelo de dominio del ejemplo (2.2.1), presentaremos una porción de códigodependiente del esquema de persistencia y otro independiente:

pub l i c c l a s s User {

// a t r i b u t o s , get , s e t . . .

/∗∗ En e s t e método se i n t r o du c en dependenc i a s e n t r e e l domin io y∗ e l f ramework de p e r s i s t e n c i a . E x i s t e un f u e r t e acop l am ien to∗ e n t r e e l modelo de domin io y e l esquema de base de datos y l a∗ demarcac ión de t r a n s a c c i o n e s .∗/pub l i c void i n s e r t ( ) throws Mode lP e r s i s t E x c ep t i o n {

t ry {Transact ionManager . s t a r t T r a n s a c t i o n ( ) ;MySq l I n s e r t i n s e r t = new MySq l I n s e r t ( "INSERT INTO SOCIALNET .USER

VALUES( ? , ? , ? , ? ) " ) ;P r o f i l e p r o f = g e t P r o f i l e ( ) ;i f ( p r o f == nu l l )p r o f . i n s e r t ( ) ;. . .i n s e r t . e x e cu t e ( ) ;Transact ionManager . commit ( ) ;

} catch ( P e r s i s t E x c e p t i o n e ) {Transact ionManager . r o l l b a c k ( ) ;throw new Mode lP e r s i s t E x c ep t i o n ( "No fue p o s i b l e i n s e r t a r e l u s u a r i o " ,

e ) ;}

}}


pub l i c c l a s s Us e r S e r v i c e L a y e r {pub l i c void addUser (UserDTO dto ) throws Bus i n e s sE x c ep t i o n {

t ry {User u = new User ( dto . getName ( ) , dto . ge tEma i l ( ) ,new P r o f i l e ( dto .

g e t P r o f i l e I n f o ( ) ) ) ;u s e r . i n s e r t ( ) ;

} catch ( Mode lP e r s i s t E x c ep t i o n mpe) {throw new Bus i n e s sE x c ep t i o n ( " E r r o r a l i n s e r t a r e l u s u a r i o " + u + " a

p a r t i r d e l DTO " + dto ,mpe) ;}

}}

En el caso anterior introdujimos responsabilidades sobre el modelo de dominio que lo acoplaron respectodel esquema y motor de bases de datos así como la demarcación de transacciones. En el siguiente ejemploutilizamos un motor de persistencia que se responsabiliza de estos tres factores, dejando al modelo dedominio desacoplado de ellos:

pub l i c c l a s s User {// a t r i b u t o s , get , s e t

pub l i c User ( S t r i n g name , S t r i n g emai l , P r o f i l e p r o f i l e ) {s e tEma i l ( ema i l ) ;setName (name) ;s e t P r o f i l e ( p r o f i l e ) ;

}}

pub l i c c l a s s Us e r S e r v i c e L a y e r {pub l i c void addUser (UserDTO dto ) throws Bus i n e s sE x c ep t i o n {

t ry {Pe r s i s t e n c eF r amewo rkSe s s i on p f s = Pe r s i s t enceF ramewo rkFac to r y .

g e t S e s s i o n ( ) ;User u = new User ( dto . getName ( ) , dto . ge tEma i l ( ) ,new P r o f i l e ( dto .

g e t P r o f i l e I n f o ( ) ) ) ;p f s . s t a r t T r a n s a c t i o n ( ) ;p f s . s ave ( u ) ;p f s . commit ( ) ;

} catch ( Mode lP e r s i s t E x c ep t i o n mpe) {p f s . r o l l b a c k ( ) ;throw new Bus i n e s sE x c ep t i o n ( " E r r o r a l i n s e r t a r e l u s u a r i o " + u + " a

p a r t i r d e l DTO " + dto ,mpe) ;}

}}

La preocupación acerca de la independencia del modelo suele surgir en el contexto de modelos queinteractúan con frameworks. En los de caja blanca debemos esperar una baja independencia del modelo,ya que estamos obligados a subclasi�car. Por el contrario, en los frameworks de caja negra contamos conun encapsulamiento que nos garantiza un mayor grado de independencia.

2.2.3. Inversión del Control e Inyección de Dependencias

La inversión de control y la inyección de dependencias son dos aspectos que han ganado gran aceptaciónya que ayudan a desacoplar servicios, generalizar implementaciones y facilitar las pruebas unitarias.

La inyección de dependencias nace en el contexto del consumo de servicios por parte de un cliente. Unproblema común en el desarrollo de aplicaciones enterprise es cómo �atar� (también llamado wiring) loscomponentes para que cooperen entre sí (Fowler, 2004). Veamos un ejemplo:

Ejemplo 2.2.3. En este ejemplo se presenta el problema del wiring de componentes. El siguiente códigono utiliza inyección de dependencias:

1 pub l i c c l a s s I n d e x e r {2 pub l i c i n d e x (Document document ) {3 Pa r s e r p a r s e r = new TextPa r s e r ( ) ;4 I n d e xWr i t e r w r i t e r = new Sq l I n d e xWr i t e r ( ) ;5 TextNorma l i z e r n o rma l i z e r = new Span i shTex tNo rma l i z e r ( ) ;6

7 L i s t <St r i ng> tokens = pa r s e r . p a r s e ( document . getText ( ) ) ;8 long doc Id = document . getDocumentID ( ) ;9 f o r ( S t r i n g token : tokens ) {10 S t r i n g normal i zedToken = no rma l i z e r . n o rma l i z e ( token ) ;11 w r i t e r . w r i t e ( docId , norma l i zedToken ) ;12 }13 }14 }

En las líneas 3,4 y 5 se instancian explícitamente clases que se ocupan de interpretar, normalizar y alma-cenar las palabras de un documento a indexar. En esta implementación, una vez compilado el programa,no se permite variar la implementación de los servicios Parser, IndexWriter y TextNormalizer.

Para resolver los problemas respecto de cómo desacoplar el consumidor de un servicio respecto del im-plementador, se utilizan técnicas de inyección de dependencias. Estas técnicas consisten en utilizar uncomponente externo que se ocupa de inyectar el implementador del servicio en el consumidor.

Ejemplo 2.2.4. En este ejemplo resolvemos el problema del ejemplo (2.2.3) utilizando buenas prácticasde inyección de dependencias:

pub l i c c l a s s I n d e x e r {pr i va te Pa r s e r p a r s e r ;pr i va te I n d e xWr i t e r w r i t e r ;pr i va te TextNorma l i z e r n o rma l i z e r ;

pub l i c void s e t P a r s e r ( Pa r s e r p a r s e r ) { t h i s . p a r s e r = p a r s e r ; }pub l i c void s e t I n d e xWr i t e r ( I n d e xWr i t e r w r i t e r ) { t h i s . w r i t e r = w r i t e r ; }pub l i c void s e tTex tNo rma l i z e r ( Tex tNorma l i z e r n o rma l i z e r ) { t h i s . n o rma l i z e r

= no rma l i z e r ; }

// g e t s para l o s a t r i b u t o s . . .

pub l i c void i n d e x (Document document ) {L i s t <St r i ng> tokens = pa r s e r . p a r s e ( document . getText ( ) ) ;long doc Id = document . getDocumentID ( ) ;f o r ( S t r i n g token : tokens ) {

S t r i n g normal i zedToken = no rma l i z e r . n o rma l i z e ( token ) ;w r i t e r . w r i t e ( docId , norma l i zedToken ) ;

}}

}

pub l i c c l a s s Bus ines sWork f low {pub l i c s t a t i c void main ( S t r i n g [ ] a r g s ) {

Wi r i ngFac to r y wf = WiringFramework . g e tFac t o r y ( " i n j e c t i o n . xml" ) ;

Document doc = Document . r ead ( "mydoc . t x t " ) ;

I n d e x e r i d x = ( I n d e x e r ) wf . g e t I n s t a n c e ( " i n d e x e r " ) ;i d x . i nd ex ( doc ) ;

}}

Archivo injection.xml:

<w i r i n g i d=" i n d e x e r " c l a s s="com . mydomain . s e r v i c e s . I n d e x e r ">

<prope r t y− i n j e c t i o n p r op e r t y=" p a r s e r " imp l="com . mydomain . p a r s e r .Span i s hPa r s e r "/>

<prope r t y− i n j e c t i o n p r op e r t y=" w r i t e r " imp l="com . mydomain . i nd ex . w r i t e r .S q l I n d e xWr i t e r "/>

<prope r t y− i n j e c t i o n p r op e r t y=" no rma l i z e r " imp l="com . mydomain . i nd ex . t e x t. Span i s hNo rma l i z e r "/>

</ w i r i n g>

En este ejemplo utilizamos una clase WiringFactory que se ocupa de leer el archivo de con�guracióninjection.xml para hacer el wiring de los objetos. Con este esquema desacoplamos el servicio de quien loimplementa, facilitando la elección dinámica de la implementación y el testeo unitario.

En el ejemplo (2.2.4) utilizamos la inyección de los servicios mediante atributos de la clase. Esto tambiénse puede llevar a cabo inyectando las dependencias en el constructor. La elección entre un método y otrose basa en criterios acerca de si es correcto construir un objeto que no tiene resueltas sus dependencias(de hecho no lo es, por lo que este criterio favorece el método de inyección en constructor) versus laposibilidad de reinyectar las dependencias sobre un objeto construido (variando su comportamiento entiempo de ejecución). Esta discusión aparece en (Spring, 2008).

Además de la inyección de dependencias, otra práctica que utilizaremos en la construcción del motor debúsqueda es la inversión de control (también conocido como inversion of control ó IoC ).

La inversión del control se basa en poner el locus de control en el framework que se está utilizando y dejarque la lógica de aplicación sea llamada cuando es necesario. Esto se conoce como el hollywood principle:�Don't call us, we'll call you� (Johnson y Foote, 1988). El IoC se complementa con la inyección dedependencias. Por ejemplo, si tenemos un framework que implementa un motor de búsqueda, podemosinyectar plugins en forma de dependencias, lo que permitirá extender la forma en la que el motor debúsqueda procesa los documentos. Veamos un ejemplo:

Ejemplo 2.2.5. A continuación se utiliza inyección de dependencias e inversión del control para auditarqué documentos se indexan.

/∗∗∗ Esta c l a s e implementa l a i n v e r s i ó n de c o n t r o l l l amando a todos l o s

mane jadores∗ r e g i s t r a d o s para r e c i b i r l a n o t i f i c a c i ó n de un nuevo documento indexado∗/pub l i c c l a s s NewIndexEventHandler implements EventHand le r {

// c on s t r u c t o r , a t r i b u t o s y métodos para manejar// l o s e v en to s de un nuevo documento que se i ndexa . .

pr i va te L i s t <Document IndexL i s t ene r> l i s t e n e r s = new Ar r a yL i s t <Document IndexL i s t ene r >() ;

// con e s t e método se r e g i s t r a n qu i e n e s s e r án l l amados a l o c u r r i r unevento

pub l i c void r e g i s t e rN ewL i s t e n e r ( Document IndexL i s t ene r n ewL i s t e n e r ) {t h i s . l i s t e n e r s . add ( n ewL i s t e n e r ) ;

}

// despacha l o s e v en to s implementando l a i n v e r s i ó n de c o n t r o lpub l i c void hand l eEvent ( ) {

Document d = getDocument ( ) ;EventContext c t x = ge t I ndexCon t e x t ( ) ;L i s t <Document IndexL i s t ene r> l i s t e n e r s = g e t L i s t e n e r s ( ) ;

i n d e x e r . i nd e x ( d ) ;

f o r ( Document IndexL i s t ene r d i l : l i s t e n e r s ) {d i l . onDocumentIndex (d , c t x ) ;

}}

}

pub l i c c l a s s I n d e x e r {// como en e l e j emp lo p r e v i o , s ó l o que cuando i ndexa un documento a v i s a

a l NewIndexEventHandler}

// e s t a c l a s e hace l a a u d i t o r i a de cada nuevo documento que i n g r e s a a lí n d i c e

pub l i c c l a s s F i l eAud i t L o g g e r implements Document IndexL i s t ene r {pub l i c S t r i n g onDocumentIndex (Document doc , EventContext c t x ) {

// e s c r i b i r a un a r c h i v o l o s da to s impo r t an t e s}

}

En este ejemplo el control lo tiene un hilo de ejecución que recibe el evento de indexación y sabe (porcon�guración externa) que debe instanciar un NewIndexEventHandler, programado para orquestar el restode los pasos. En este ejemplo se ve claramente que es fácil crear tests unitarios ya que podemos utilizarobjetos mock (Mackinnon et al., 2001) que simulan ser el NewIndexEventHandler o el FileAuditLogger.

Estos breves ejemplos muestran bene�cios de las técnicas de inyección de dependencias e inversión decontrol. Dichos bene�cios harán que las utilicemos en la construcción del framework de búsqueda eindexación de objetos.

2.3. Persistencia de Modelos de Dominio

Information Retrieval y Persistencia

En sistemas de IR como los buscadores web, los documentos están persistidos de manera que son re-cuperables tanto por el proceso indexador del motor de búsqueda como por el browser que utiliza elusuario.

Cuando los documentos son objetos de una aplicación el panorama no es distinto: necesitamos acced-erlos para indexarlos y visualizarlos. Si calculáramos puntajes estructurales como PageRank, tambiénnecesitaríamos acceder a los objetos para calcularlo. Adicionalmente, la eliminación de objetos se deberíare�ejar eventualmente en los índices del motor de búsqueda para no recuperar objetos innecesarios ydegradar su rendimiento.

Por estas razones, para llevar a cabo las actividades del motor de búsqueda, necesitaremos interactuarcon el mecanismo de persistencia que utiliza la aplicación para sincronizar el índice con el estado de laaplicación.

La interacción entre el sistema de persistencia y el motor de búsqueda puede ser:

Manual (estilo librería): el programador indica que se debe invocar al motor de búsqueda luegode interactuar con el ORM.

2.3. PERSISTENCIA DE MODELOS DE DOMINIO 55

Automática (estilo framework): el motor de búsqueda intercepta los eventos CRUD13 generadospor la aplicación y delega en el usuario si es necesario.

El modelo manual es simple de implementar ya que sólo requiere que el motor de búsqueda expongauna API genérica hacia las aplicaciones. Esa simplicidad redunda en una solución de bajo nivel, cuyoscostos asociados serán código duplicado y los errores propios de éste. El modelo automático requiere podersuscribirse a los eventos CRUD manejados por la herramienta de persistencia, lo que requiere proveerconectores especí�cos.

Organización de esta Sección

Las siguientes subsecciones explican brevemente los distintos mecanismos de persistencia del lenguajeJava. En las subsecciones (2.3.2) y (2.3.3) se explican los dos estilos principales de persistencia: manualvs administrada. En las subsecciones siguientes se muestran las tecnologías a las que haremos referenciaal presentar la propuesta en el capítulo 3.

Dada la gran adopción de las bases de datos relacionales en la en la industria del software, pondremosespecial atención sobre las herramientas que mapean objetos hacia/desde los RDBMS.

Como se explicó en el Plan de Tesis (sección 1.3), el software desarrollado está construido en Java, porlo que los desarrollos tecnológicos se harán sobre este lenguaje de programación. Sin embargo, el análisissigue siendo válido en otros lenguajes orientados a objetos que disponen de mecanismos de persistenciasimilares.

2.3.1. Persistencia y Ciclos de Vida en Aplicaciones Enterprise

En aplicaciones enterprise los objetos del dominio tienen ciclos de vida y ubicaciones que dependen depatrones de diseño y arquitectura propios de este tipo de aplicaciones. En estos entornos es posible queencontremos conviviendo un conjunto de procesos, los cuales no forman parte de una misma unidad decompilación, sino que son independientes e interactúan mediante IPC (Inter-Process Communication),RPC (Remote Procedure Call), colas de mensajes, bases de datos, web services o archivos. Además, esfrecuente que estos procesos y componentes provengan de proveedores diferentes que utilizan distintosmedios para el almacenamiento de la información. Aún siendo todos los módulos desarrollados con lasmismas tecnologías, es muy posible encontrarse con almacenamientos mixtos, por ejemplo: archivos ybases de datos.

En este entorno dependemos de la capacidad de interrogar e interpretar fuentes de datos de distintasnaturalezas, lo que complejiza el acceso a la información. Este acceso a la información es importante a lahora de diseñar los métodos de indexación, recuperación y visualización de los objetos del dominio (versección 2.1).

Para resolver este problema es crucial conocer los mecanismos por los cuales los objetos se vuelvenpersistentes.

2.3.2. Persistencia Manual

Cuando la persistencia se administra de forma manual, es responsabilidad del programador manejar elciclo de vida de los objetos así como las técnicas de almacenamiento. El esquema manual otorga la mayor�exibilidad posible a cambio de un esfuerzo mayor de programación.

En este esquema el programador utiliza las APIs provistas por el lenguaje para serializar/deserializarlos objetos, acceder al medio de almacenamiento, instanciar y destruir los objetos (en el caso de Javahablamos de �desreferenciar�).

Para tener un motor de búsqueda sobre objetos, es necesario sincronizar el ciclo de vida de los objetos conel motor de búsqueda. Dado que la persistencia manual puede implementarse de muchas maneras distintas,en este esquema de trabajo los eventos CRUD son difíciles de interceptar por cualquier herramientaexterna.

13CRUD: siglas en inglés para crear, leer, actualizar y eliminar objetos (create, read, update y delete).


Si bien es cierto que necesitamos conocer los eventos para sincronizar la aplicación y el motor de búsqueda,en un esquema de persistencia manual se puede modi�car la aplicación para dar aviso de los eventos CRUDprogramaticamente o soportar cierto grado de divergencia entre la aplicación y el motor de búsqueda.Como ejemplo de divergencia controlada entre el motor de búsqueda y la aplicación tomemos el casode los buscadores web, los cuales desconocen cuándo se genera, actualiza o elimina una página web.Sin embargo, el webmaster puede indicar por dónde comenzar la indexación y generar meta datos queindican cómo recorrer el sitio web que está indexando, así como es posible descubrir páginas y sitios webpor los enlaces presentes en el HTML. Para el caso de un grafo de objetos, también podemos iniciar elrecorrido por nodos bien conocidos o por un lugar indicado manualmente y luego navegar las relacionesentre objetos de forma de indexar los que vamos descubriendo.

2.3.3. Persistencia Administrada

Dada la complejidad de desarrollo de un esquema de persistencia manual, existen soluciones que admin-istran la persistencia de objetos de manera automática. Existen muchas advertencias acerca del costo demapear a mano un modelo de dominio a un RDBMS (una de ellas se puede encontrar en Fowler, 2002).

Muchas de estas herramientas se presentan como frameworks que persisten objetos en bases de datos rela-cionales. Algunos ejemplos son Hibernate Core, iBATIS, JDO y JPA (Hibernate, 2009a; Apache, 2009c;JCP, 2006b,a). Eventualmente también hay mecanismos de persistencia sobre archivos como BerkeleyDB(Oracle, 2009a).

El objetivo de estas herramientas es asistir al programador en el manejo del ciclo de vida de los objetos,facilitando el traslado entre la memoria principal y secundaria. Estos frameworks además colaboran entareas más complejas como las transacciones y la optimización de consultas.

Los frameworks de persistencia administrada introducen distintos grados de dependencia entre el modelode dominio y el framework, así como también permiten distintos grados de transparencia respecto delesquema de base de datos. Los ORMs (mapeadores objeto-relacionales ú object-relational mappers) demás bajo nivel sólo proveen una API para transformar consultas SQL en objetos y vice versa, mientrasque los ORM de más alto nivel nos abstraen completamente del mecanismo de persistencia (a cambio deque especi�quemos cómo persistir los objetos con una buena cantidad de metadatos).

En las próximas subsecciones analizamos distintos mecanismos de persistencia que pueden utilizarse tantoen un esquema de persistencia manual como administrada.

2.3.4. Binaria

El lenguaje Java incluye entre sus bibliotecas estándar la capacidad de convertir objetos en una formaserializada, el cual es tanto transmisible por un canal como almacenable en memoria secundaria.

La persistencia binaria en Java consiste en enviar los datos necesarios hacia un �ujo de salida14 paraluego reconstruir el objeto a partir de un �ujo de entrada sobre ésos datos. Java almacena a la salida elnombre y �rma de la clase así como los campos no transientes ni estáticos de la misma (Sun, 2008).

Para poder persistir un objeto, es necesario que algún ancestro en la jerarquía de clases implemente lainterfaz java.io.Serializable.

Ejemplo 2.3.1. Una adaptación del ejemplo de persistencia binaria en Java presente en (Sun, 2008):

1 F i l eOutputSt ream f o s = new F i l eOutputSt ream ( "payment−1258302209. dat " ) ;2 ObjectOutputStream oos = new ObjectOutputStream ( f o s ) ;3 oos . w r i t eOb j e c t (new Cred i tCardPayment ( i t em In f o rma t i on , c r e d i t C a r d ) ) ;4 oos . c l o s e ( ) ;

La línea número 2 del ejemplo (2.3.1) genera un �ujo de escritura de objetos sobre el �ujo de�nido en lalínea número 1. La línea 3 genera un objeto que contiene información de pago de una tarjeta de crédito(asumiendo que los parámetros se generan previamente) y persiste el objeto CreditCardPayment en el disco.

El sistema de persistencia binario de Java permite con�gurar otros aspectos del proceso como:

14Hablar de ��ujos de salida� es más general que hablar de �archivos�. Los �ujos de salida pueden ser valores de retornode una llamada a procedimiento remoto, un canal TCP, un archivo o cualquier otro almacenamiento físico ó medio detransmisión.


protocolos propios de serialización/deserialización

control de versiones

seguridad

La información detallada del sistema de persistencia binaria se encuentra en (Sun, 2004).

En conclusión, el sistema de serialización binaria permite serializar un grafo de objetos serializables através de un �ujo. Si bien esto es muy útil, este sistema no nos da ninguna facilidad respecto de:

transacciones

recuperación e�ciente de datos (índices)

inspección y manipulación fuera de linea de los objetos

generación de reportes ad-hoc / cálculo de agregaciones sobre campos

integridad referencial

control de unicidad

En las próximas subsecciones analizaremos los sistemas más populares de persistencia, los cuales solucio-nan algunos de estos problemas.

2.3.5. Ad-Hoc

Es posible evitar problemas de la persistencia binaria (ver subsección 2.3.4) utilizando un método depersistencia ad-hoc.

Si bien en el extremo podríamos decir que todos los sistemas de persistencia que no son binarios son ad-hoc, vamos a referirnos a la persistencia ad-hoc como el método de serialización utilizado para resolverla persistencia de un conjunto de clases de una aplicación determinada.

Algunos ejemplos de persistencia ad-hoc:

conversión a texto delimitado por comas (CSV),

serialización a texto plano con cifrado AES,

en texto plano hacia archivos indexados.

La serialización ad hoc puede ser adecuada si queremos mantener compatibilidad con futuros cambios alos objetos persistentes.

Otro caso donde conviene generar nuestro propio serializador es cuando tenemos que persistir gran canti-dad de objetos y queremos optimizar el espacio utilizado. Con un serializador propio podemos aprovecharnuestro conocimiento acerca de los datos para obtener estadísticamente mejoras en el espacio utilizado(comprimiendo enteros, cadenas de texto, etc.).

En Java se puede utilizar un esquema híbrido entre persistencia binaria y ad-hoc implementando lainterfaz java.io.Externalizable. Al implementar esta interfaz podemos utilizar las clases ObjectOutputStreamy ObjectInputStream para leer y escribir de los �ujos, pero seremos nosotros quienes programemos elprotocolo de serialización. A continuación vemos un ejemplo en el que se utiliza este sistema.

Ejemplo 2.3.2. Serialización Ad-Hoc implementando java.io.Externalizable. Al ejecutar este código seimprime en la pantalla la misma información que se persistió en el archivo.

pub l i c c l a s s Cred i tCardPayment implements E x t e r n a l i z a b l e {

pr i va te I t em I n f o rma t i o n i t em I n f o rma t i o n ;pr i va te Cred i tCa rd c r e d i t C a r d ;

// Con s t r u c t o r e s , get , s e t y t o S t r i n g . .

// Ca l l b a c k para l a s e r i a l i z a c i ó npub l i c void w r i t e E x t e r n a l ( ObjectOutput out ) throws IOExcept i on {

out . w r i t e I n t ( i t em I n f o rma t i o n . g e t I t em Id ( ) ) ;

S t r i n g c i p h e rV e r s i o n = c r e d i t C a r d . c i p h e r ( ) ;f o r ( i n t i = 0 ; i < c i p h e rV e r s i o n . l e n g t h ( ) ; i++) out . w r i t eCha r (

c i p h e rV e r s i o n . charAt ( i ) ) ;}

// Ca l l b a c k para l a d e s e r i a l i z a c i ó npub l i c void r e a dE x t e r n a l ( Ob j e c t I npu t i n ) throws IOExcept ion ,

C la s sNotFoundExcept ion {t h i s . i t em I n f o rma t i o n = new I t em I n f o rma t i o n ( i n . r e a d I n t ( ) ) ;t h i s . c r e d i t C a r d = new Cred i tCa rd ( ) ;

char [ ] c i p h e rCha r s = new char [ C r ed i tCa rd .NUMBER_LENGTH] ;f o r ( i n t i = 0 ; i < Cred i tCa rd .NUMBER_LENGTH; i++) c i p h e rCha r s [ i ] = i n .

readChar ( ) ;

t h i s . c r e d i t C a r d . setCipherNumber (new S t r i n g ( c i p h e rCha r s ) ) ;}

// Ejemplo de usopub l i c s t a t i c void main ( S t r i n g [ ] a r g s ) throws IOExcept ion ,

C la s sNotFoundExcept ion {Cred i tCardPayment o r i g i n a l = new Cred i tCardPayment (new I t em I n f o rma t i o n

(10) , new Cred i tCa rd (321654987456L) ) ;

F i l eOutputSt ream f o s = new F i l eOutputSt ream ( "payment−1258302209. dat " ) ;ObjectOutputStream oos = new ObjectOutputStream ( f o s ) ;oos . w r i t eOb j e c t ( o r i g i n a l ) ;oos . c l o s e ( ) ;

F i l e I n pu tS t r e am f i s = new F i l e I n pu tS t r e am ( "payment−1258302209. dat " ) ;Ob jec t InputSt r eam o i s = new Objec t InputSt r eam ( f i s ) ;Cred i tCardPayment r e s t a u r a d o = ( Cred i tCardPayment ) o i s . r e adOb j ec t ( ) ;o i s . c l o s e ( ) ;

System . out . p r i n t l n ( r e s t a u r a d o ) ;}

}

En el ejemplo (2.3.2) se persistió una versión cifrada del número de tarjeta de crédito para no transmi-tir la versión original en texto plano. Si no se desea implementar java.io.Externalizable, se puede hacerpersistencia ad-hoc mediante re�ection de Java.

Respecto del manejo de los eventos CRUD, la serialización ad-hoc es muy similar a la binaria ya que nohay un mecanismo estándar de noti�cación de estos eventos. La noti�cación de estos eventos queda enmanos del programador.

2.3.6. XML

La serialización XML es un tipo de serialización ad-hoc que tiene algunas ventajas:

interoperabilidad con otros lenguajes

legible y editable por un humano

herramientas que soportan lectura y escritura de XML, DTD y Schema

Estas ventajas tienen el costo de no tener la misma �exibilidad de la serialización ad-hoc.

Una herramienta que se ocupa de la serialización XML es XStream (XStream, 2009). A continuaciónvemos una adaptación de un ejemplo presente en la documentación de esta herramienta:

pub l i c c l a s s Cred i tCardPayment {pr i va te I t em I n f o rma t i o n i t em I n f o rma t i o n ;pr i va te Cred i tCa rd c r e d i t C a r d ;// Con s t r u c t o r y métodos . . .

}

pub l i c s t a t i c void main ( S t r i n g a r g s [ ] ) throws Excep t i on {XStream xst ream = new XStream (new DomDriver ( ) ) ;xs t ream . a l i a s ( "payment" , Cred i tCardPayment . c l a s s ) ;xs t ream . a l i a s ( " i tem" , I t em In f o rma t i o n . c l a s s ) ;xs t ream . a l i a s ( " c r e d i t−ca rd " , C r ed i tCa rd . c l a s s ) ;

Cred i tCardPayment o r i g i n a l = new Cred i tCardPayment (new I t em I n f o rma t i o n(10) , new Cred i tCa rd (321654987456L) ) ;

S t r i n g xml = xst ream . toXML( o r i g i n a l ) ;}

Esto produce el XML:

<payment><item>

10</ item><c r e d i t−ca rd>

<number>321654987456</number></ c r e d i t−ca rd>

</payment>

La deserialización es también muy simple:

Cred i tCardPayment r e s t a u r a d o = ( Cred i tCardPayment ) xs t ream . fromXML( xml ) ;

Es preciso notar que para el caso de XStream, el framework toma responsabilidades avanzadas como elmapeo en jerarquías de herencia y agregaciones (XStream, 2009).

En muchos casos la serialización XML puede ser una mejor alternativa que los métodos ad-hoc por lasventajas que hemos comentado, sin embargo, existen algunos aspectos a resolver: transacciones, controlde unicidad e integridad referencial, acceso e�ciente y generación de reportes. Este tipo de problemaspueden abordarse mejor con el respaldo de una base de datos, por lo que en las próximas secciones vamosa abordar las técnicas que utilizan RDBMS como parte de la persistencia de objetos.

2.3.7. Object Relational Mapper (ORM)

Los RDBMS han sido la base para miles de sistemas por más de 30 años. Asimismo, la gran masa deesfuerzo en desarrollo de software se orienta a la programación orientada a objetos.


Basándose en estos dos hechos, la industria del software ha buscado combinar tanto la programación orien-tada a objetos como los RDBMS. Sin embargo, a pesar del éxito de estos dos modelos existe un problemaentre ellos llamado desajuste de impedancia (Fowler, 2002)15. Algunos de los ítems que componen estedesajuste son:

Tipos de Datos: no existe un mapeo 1:1 entre los tipos de datos primitivos de los lenguajes deprogramación y los de las bases de datos. Algunos ejemplos en Java y Oracle: String vs. Varchar eInteger vs. Number.

Herencia y Polimor�smo: son fáciles de implementar en un lenguaje orientado a objetos, mientrasque en un RDBMS requieren elegir cuidadosamente la estrategia de implementación.

Recuperación de Datos y Junta: el mapeo entre relaciones y clases debe generar resultsets com-patibles con las clases, ya que el esquema del resultset se genera dinámicamente dependiendo lascolumnas que especi�que en la consulta. La navegación entre asociaciones en un mundo de objetosconsiste en iterar a través de colecciones, mientras que en una base de datos puede requerir unajunta, la cual no se corresponde con una clase real del modelo de objetos o bien ejecutar consultasadicionales para obtener los objetos agregados.

Orden de Creación: en un esquema de base de datos podemos tener dos tablas cuyas relaciones sereferencian entre sí, lo cual puede ser un problema al momento de la creación de objetos, ya que unobjeto depende del otro para su creación, dando lugar a la pregunta de quién debe crearse primero.

Esquema Duplicado: estamos obligados a conservar una estructura de datos en el modelo de dominioy otra en las tablas de la base de datos. En las consideraciones de diseño no debe perderse el balanceentre los dos esquemas y se debe tener en mente técnicas para que la navegación de objetos no genereconsultas excesivas en el RDBMS.

Identidad vs. Equivalencia: en los lenguajes de programación como Java es factible que a.equals(b)sea cierto pero que a==b no lo sea, mientras que en una relación no pueden existir dos tuplasdiferentes con la misma clave.

Reglas de Acceso: el modelo de objetos tiene atributos públicos y privados, mientras que los RDBMStienen �permisos�.

Si bien es posible plantear otros desajustes entre los dos modelos, los expuestos dan un panorama delproblema de conciliar dos modelos exitosos por separado pero di�ciles de reunir.

Dado el esfuerzo que requiere persistir objetos en bases de datos relacionales, se ha desarrollado una ampliagama de herramientas que asisten al programador en esta tarea. Estas herramientas son los ORM. LosORM varían desde wrappers de bajo nivel de las API del lenguaje hasta herramientas de alto nivel quepermiten abstraernos del esquema y el SQL.

A continuación presentamos pequeños casos de estudio de ORM básicos, donde el programador tieneun rol activo en resolver los desajustes de impedancia y ORM Completos, donde el framework asiste alprogramador en resolver estos desajustes.

ORM Básicos

A continuación vemos dos ejemplos de ORM básicos donde debemos resolver la mayoría de los problemasde impedancia: JDBC y Apache iBATIS.

JDBC (Java DataBase Connectivity) JDBC es la API de Java para estandarizar el diálogo con losdistintos RDBMS. Esta API establece las primitivas de manejo de conexiones, transacciones y ejecuciónde consultas sobre el RDBMS.

En los casos en los que se quiere hacer el esfuerzo de codi�car una capa propia de persistencia, normalmentese construyen las clases del framework conectándolas con JDBC para la ejecución de consultas. En rigor

15Si bien Fowler efectivamente utiliza el término �impedance mismatch� en su obra, pueden encontrarse otras notas,artículos o libros donde se re�ere al tema con la misma frase, por lo que no podemos asegurar cuál sería la cita másadecuada.

JDBC no es un ORM en sí mismo sino que es la herramienta que éstos utilizan para dialogar con elRDBMS.

Al utilizar JDBC se obtiene una gran �exibilidad, pero queda en manos del desarrollador resolver todoslos problemas de impedancia.

Los eventos CRUD no se noti�can por ningún medio estándar ya que su implementación es totalmentead-hoc.

Ejemplo 2.3.3. A continuación vemos un caso en el que hacemos un mapeo básico entre la base de datosy un objeto utilizando JDBC.

pub l i c s t a t i c void main ( S t r i n g a r g s [ ] ) throws SQLException{

Loca l e . s e tD e f a u l t ( Loca l e . ENGLISH) ;

Dr ive rManager . r e g i s t e r D r i v e r (new o r a c l e . j dbc . d r i v e r . O r a c l eD r i v e r ( ) ) ;

Connect ion conn=Dr iverManager . g e tConnec t i on ( " jdbc : o r a c l e : t h i n : @ l o c a l h o s t: 1 5 2 1 :XE" , " u s u a r i o " , " password " ) ;

Statement stmt = conn . c r e a t eS ta t emen t ( ) ;

i n t u s e r I d = 10 ;Re s u l t S e t r s e t = stmt . executeQuery ( "SELECT f i r s t_name , last_name , l owe r (

nickname ) FROM use r WHERE i d="+u s e r I d ) ;whi le ( r s e t . nex t ( ) ) {

System . out . p r i n t l n (new com . mydomain . User ( u s e r I d , r s e t . g e t S t r i n g (1 ) , r s e t .g e t S t r i n g (2 ) , r s e t . g e t S t r i n g (3 ) ) ;

}stmt . c l o s e ( ) ;conn . c l o s e ( ) ;

}

Como se ve en este fragmento de código, el usuario se ocupa de la conexión y recuperación de datos desdela base, mapeando el esquema de relación a los objetos del dominio en forma manual.

Apache iBATIS Existen herramientas populares que facilitan las tareas rutinarias de persistencia conJDBC sin obligarnos a ceder el control total de la persistencia. Una herramienta muy popular en estesentido es Apache iBATIS (ver Apache, 2009c).

En iBATIS 3 podemos de�nir las operaciones que queremos realizar sobre la base de datos medianteinterfaces. Estas interfaces reciben y devuelven objetos de dominio o en su defecto objetos de transferenciade datos (data transfer objects óDTO). Las reglas acerca de cómo insertar, actualizar, eliminar o recuperarobjetos desde el RDBMS las debemos con�gurar explícitamente mediante archivos de con�guración, loscuales contienen el SQL necesario. A continuación vemos un ejemplo.

Ejemplo 2.3.4. En este ejemplo vemos cómo manejar la persistencia de un objeto Person de un dominiocualquiera.

Clase del dominio:

pub l i c c l a s s Person {

pr i va te long i d ;pr i va te S t r i n g f i r s tName ;pr i va te S t r i n g lastName ;pr i va te S t r i n g ema i l ;pr i va te L i s t <Person> con t a c t s ;pr i va te Company company ;

pub l i c Person ( ) { }

// get , s e t , . . .}

Interfaz de mapeo:

pub l i c i n t e r f a ce PersonMapper {pub l i c Person s e l e c t P e r s o n ( i n t i d ) ;pub l i c L i s t <Person> selectByCompany ( long i d ) ;pub l i c void i n s e r t P e r s o n ( I n s e r tPe r s onDto i n s e r tD t o ) ;

}

Archivo Person.xml con el SQL de mapeo:

<?xml vers ion=" 1 .0 " encod ing="UTF−8" ?><!DOCTYPE mapper PUBLIC "−// i b a t i s . apache . org //DTD Mapper 3 .0//EN" "

h t t p : // i b a t i s . apache . org / dtd / i b a t i s −3−mapper . dtd ">

<mapper namespace="com . mydomain . PersonMapper "><resu l tMap i d=" personResu l tMap " type="Person ">

<con s t r u c t o r><idArg column=" i d " javaType=" long " /><arg column=" f i r s t_name " javaType=" S t r i n g " /><arg column=" last_name" javaType=" S t r i n g " /><arg column=" ema i l " javaType=" S t r i n g " />

</ c o n s t r u c t o r><r e s u l t p r o p e r t y=" f i r s tName " column=" f i r s t_name " /><r e s u l t p r o p e r t y=" lastName" column=" last_name" /><r e s u l t p r o p e r t y=" ema i l " column=" ema i l " /><a s s o c i a t i o n p r op e r t y="company" column="company_id"

javaType="Company" s e l e c t="com . mydomain . CompanyMapper .se lectCompany " />

<c o l l e c t i o n p r op e r t y=" con t a c t s " javaType=" A r r a y L i s t "column=" i d " ofType="Person " s e l e c t=" s e l e c t C o n t a c t s " />

</ resu l tMap>

<s e l e c t i d=" s e l e c t P e r s o n " parameterType=" i n t " r e s u l tTyp e="Person "re su l tMap="personResu l tMap ">s e l e c tid , f i r s t_name , last_name , emai l , company_idfromMYAPPSCHEMA. Person where i d = #{i d }

</ s e l e c t>

<s e l e c t i d=" s e l e c t C o n t a c t s " parameterType=" i n t " r e s u l tTyp e="Person "re su l tMap="personResu l tMap ">s e l e c tp . id , p . f i r s t_name , p . last_name , p . ema i lfromMYAPPSCHEMA. Contact c , MYAPPSCHEMA. Person pwherec . from_id = #{i d } andc . to_id = p . i d

</ s e l e c t>

<s e l e c t i d=" selectByCompany " parameterType=" i n t " r e s u l tTyp e="Person "re su l tMap="personResu l tMap ">

s e l e c tid , f i r s t_name , last_name , ema i lfromMYAPPSCHEMA. Person where company_id = #{i d }

</ s e l e c t>



<se l e c tKe y o r d e r="BEFORE" r e s u l tT yp e=" j a v a . l ang . Long" keyPrope r t y="pe r son . i d " >

SELECT NEXT VALUE FOR MYAPPSCHEMA. person_id FROM DUAL AS ID</ s e l e c tKe y>INSERT INTO MYAPPSCHEMA.PERSON( ID , FIRST_NAME, LAST_NAME, PASSWORD, EMAIL , COMPANY_ID )v a l u e s( #{pe r son . id , jdbcType=BIGINT} ,#{pe r son . f i r s tName , jdbcType=VARCHAR} ,#{pe r son . lastName , jdbcType=VARCHAR} ,#{password , jdbcType=VARCHAR} ,#{pe r son . emai l , jdbcType=VARCHAR} ,#{pe r son . company . id , jdbcType=BIGINT} )

</mapper>

Finalmente vemos caso de uso de ejemplo RegisterPerson:

pub l i c c l a s s Reg i s t e rP e r s o n {pr i va te s t a t i c void i n s e r t P e r s o n (Company company , S t r i n g f i r s tName ,

S t r i n g lastName , S t r i n g emai l , S t r i n g password ) throws

Bus i n e s sE x c ep t i o n {S t r i n g r e s o u r c e = "com/mydomain/ p e r s i s t e n c e / Con f i g u r a t i o n . xml" ;Reader r e a d e r = Resou rce s . ge tResourceAsReade r ( r e s o u r c e ) ;S q l S e s s i o nF a c t o r y sq lMapper = new Sq l S e s s i o n F a c t o r yBu i l d e r ( ) . b u i l d (

r e a d e r ) ;

S q l S e s s i o n s e s s i o n = sqlMapper . openSe s s i on ( ) ;t ry {

PersonMapper personMapper = s e s s i o n . getMapper ( PersonMapper . c l a s s );

I n s e r tPe r s onDto dto = new I n s e r tPe r s onDto ( ) ;

Person p = new Person ( f i r s tName , lastName , ema i l ) ;p . setCompany ( company ) ;

dto . s e tPe r s on ( p ) ;dto . s e tPas sword ( password ) ;

personMapper . i n s e r t P e r s o n ( dto ) ;

s e s s i o n . commit ( ) ;} f i n a l l y {

s e s s i o n . c l o s e ( ) ;}

}}

En este ejemplo vimos los actores que intervienen en la persistencia con iBATIS. Para �nalizar el ejemplovamos a enumerarlos y describir sus responsabilidades:


Objetos de dominio (Person): implementan la lógica de negocio, no tienen dependencias explícitashacia el ORM.

Interfaz de acceso a datos (PersonMapper): de�ne las operaciones de persistencia sobre el objeto amapear. Permite proveer implementaciones alternativas al ORM.

Archivo de con�guración del mapeo (Person.xml): de�ne la lógica de mapeo entre el esquema de basede datos y el modelo.

Objeto de negocio (RegisterPerson): implementa la secuencialidad del caso de uso.

iBATIS evita que escribamos y dupliquemos buenas cantidades de código ad-hoc para la transformaciónde datos entre el esquema de base de datos y el modelo de clases. Además ayuda a resolver desajustes deimpedancia de conversión de tipos de datos, herencia y polimor�smo.

Entre las ventajas de utilizar este ORM está la provisión de caches de objetos que evitan consultasinnecesarias a la base de datos, lo cual es conveniente para hidratar objetos recuperados.

ORM Completos

Los ORM completos buscan resolver integralmente los desajustes de impedancia entre modelos. EstosORM son herramientas administradas de mayor complejidad que los ORM básicos.

El primer caso de estudio es el estándar JPA (Java Persistence API, JCP, 2006a). Este es el estándarde Java para persistencia objeto-relacional. El segundo caso de estudio es JDO, un estándar más antiguoque JPA pero que tiene varias implementaciones y usuarios.

El tercer caso de estudio es una herramienta de persistencia no estandarizada por un JSR16 llamadaHibernate (ver Hibernate, 2009a). Este ejemplo es especialmente signi�cativo ya que el mismo grupo dedesarrollo provee un motor de búsqueda para el ORM llamado Hibernate Search (ver Hibernate, 2009b),el cual tomaremos como caso de estudio en la sección (2.4.2).

JPA (Java Persistence API) Es un estándar de persistencia objeto-relacional introducido en (JCP,2006a). La intención de este estándar es simpli�car el desarrollo de aplicaciones que requieren persistenciaobjeto-relacional y uni�cando a los usuarios detrás de una sola API.

JPA impone algunos requerimientos sobre el modelo de dominio:

debemos anotar las clases con el annotation @Entity

la clase debe tener al menos un constructor público o privado sin argumentos

ni la clase, ni sus métodos o variables persistentes de instancia pueden ser declarados final

para ciertos usos, la clase debe implementar la interfaz java.io.Serializable

los clientes deben acceder al estado a través de métodos de acceso (get/set) ó métodos de negocio(calcularSaldo, etc).

A cambio de estas restricciones, JPA es capaz de mapear jerarquías de clases hacia tablas, generar clavesprimarias y mapear tipos de datos entre Java y el RDBMS.

Además del SQL estándar que siempre podemos ejecutar sobre el RDBMS, JPA permite consultas sobreobjetos en un lenguaje similar a SQL (JPA-QL), lo que facilita la recuperación y mapeo de objetos.

La implementación de referencia de JPA es Oracle TopLink (Oracle, 2008). Además de esta imple-mentación de referencia, existen otras como OpenJPA y Hibernate (a través de módulos adicionales).

Nuestro interés principal en JPA es mostrar su importancia en el ecosistema de persistencia y contarlocomo posible actor en la relación de las aplicaciones con nuestro motor de búsqueda.

16Java Speci�cation Requests (JSR): son descripciones técnicas propuestas en el marco del Java Community Process(JCP). Funcionan como propuestas de estándares hasta eventualmente incorporarse a la especi�cación Java.

2.4. CASOS DE ESTUDIO 65

JDO (Java Data Objects) La especi�cación de este sistema de persistencia para objetos conocidocomo se publicó inicialmente en el JSR-12 (2002), previamente a JPA. Más tarde, el JSR-243 (2006)especi�ca la versión 2 de JDO, la cual cuenta con las siguientes características:

soporte para múltiples data stores (puede almacenar objetos fuera de un RDBMS),

no requiere modi�car los objetos de dominio (Plain Old Java Objects ó POJO),

generación automática del esquema,

auto generación de claves primarias,

no requiere escribir código relacionado a JDBC.

Técnicamente, dado que JDO persiste objetos hacia otros medios además de un RDBMS, no es un ORMsino que es una herramienta de �persistencia transparente�. A pesar de esto tomamos el caso de particularen que el data store es un RDBMS y lo tratamos como un ORM.

En JDO el proceso de compilación requiere un tratamiento de post-compilación llamado enhancer (poten-ciador). El enhancer le permite al framework reconocer los cambios de estado en un objeto para manejarsu persistencia.

JDO dispone de múltiples implementaciones como JPOX y DataNucleus así como una implementaciónde referencia (ver JCP, 2006b).

Así como en JPA, nuestro interés en JDO pasa por tenerlo en cuenta como un posible actor con el cualinteractuar en la construcción del motor de búsqueda.

Hibernate El módulo base de Hibernate es el framework de persistencia no estándar más difundidoentre los ORM. Como ya hemos comentado anteriormente, Hibernate es una suite de productos con-struidos alrededor de Hibernate Core (módulo autónomo base del ORM) e implementa el estándar JPAmediante módulos opcionales.

Hibernate es muy similar a JPA y JDO en el sentido de que impone algunos requerimientos básicos sobreel modelo de dominio (constructor sin argumentos) y se ocupa de transparentar la persistencia de objetosal RDBMS.

Este ORM tiene la particularidad de que avanzó en la solución del problema de IR sobre objetos medianteun módulo adicional llamado Hibernate Search (Hibernate, 2009b). En la subsección (2.4.2) ampliaremosacerca de éste.

2.3.8. Bases de Datos Orientadas a Objetos

Tras muchos años de existencia, las Bases de Datos Orientadas a Objetos (Object Oriented DataBaseManagement System ó OODBMS ) han atravesado distintos esfuerzos de estandarización sin lograr unaadopción masiva.

Si bien en ciertos campos del conocimiento pueden ser una muy buena solución (se suele citar el CAD/-CAM como campo de aplicación), tienen bajo nivel de adopción en el ambiente de aplicaciones empre-sariales (donde planteamos mayormente el campo de aplicación del motor de búsqueda).

Por estas razones excluimos los OODBMS como caso de interacción con el motor de búsqueda, siendoque las aplicaciones que efectivamente utilicen un OODBMS deberán comunicarse mediante una APIgenérica (tal como si utilizaran persistencia manual).

2.4. Casos de Estudio

En esta sección estudiamos tres herramientas que representan el estado del arte en materia de IR parauso en desarrollo de software. Éstas herramientas son de especial interés a la hora de realizar un análisiscomparativo y extraer las mejores prácticas para generar la herramienta de IR que construimos.

La primera herramienta es Apache Lucene (Apache, 2009b). Lucene está orientado a la indexación yrecuperación de documentos de texto generales. La segunda y tercera herramienta son respectivamenteHibernate Search y Compass Project. Estas dos herramientas son so�sticados envoltorios de Lucene (loutilizan como motor de indexación y recuperación) que intentan resolver los problemas de utilizarlodirectamente como indexador de objetos (ver subsección 1.1.3).

Para la categorización de sistemas de IR que hemos hecho en la subsección (2.1.1), dentro de la categoríade IR para desarrollo de software, Lucene entra en la sub categoría de Text Retrieval mientras queHibernate Search y Compass pertenecen a la sub categoría de Object Search.

2.4.1. Apache Lucene

Apache Lucene es un sistema maduro de indexación y recuperación de textos de código abierto paraJava (existen traducciones a otros lenguajes como C, C++, Perl, Python, etc). Este sistema se presentaal programador por medio de una API extensible y permite efectuar la indexación y recuperación dedocumentos en cualquier aplicación.

En los próximos apartados analizamos los conceptos básicos de Lucene y vemos ejemplos de su utilización.

Documentos y Campos

En Lucene el diseñador debe de�nir las entidades a indexar mediante la de�nición de un objeto de claseDocument. Los documentos aplican los conceptos de campos y zonas (ver subsección 2.1.6) medianteobjetos de tipo Field, los cuales se implementan como pares clave/valor sin un tipo de datos especí�co(en rigor se implementan como Strings). Lucene diferencia un campo y una zona mediante parámetrosque permiten especi�car si el Field se debe almacenar y/o indexar. A continuación vemos un ejemplo deesta estructura.

Ejemplo 2.4.1. De�nición de un documento que representa una página web.

Document doc = new Document ( ) ;doc . add (new F i e l d ( "URL" , " h t tp : //www. f i . uba . a r " , S to r e . YES , I ndex .NOT_ANALYZED

) ) ;doc . add (new F i e l d ( "TITLE" , " Facu l t ad de I n g e n i e r í a − Un i v e r s i d a d de Buenos

A i r e s " , S to r e . YES , I ndex .ANALYZED) ) ;doc . add (new F i e l d ( "BODY" , "<body><h1>Bienven i do a . . . " , S to r e . YES , I ndex .

ANALYZED) ) ;

Antes de almacenar el texto en el índice debemos especi�car si queremos preprocesarlo o efectuar unalmacenamiento literal. Los campos que elegimos preprocesar son tomados por objetos Analyzer que efec-túan tareas como: fragmentación del texto, conversión a minúsculas y eliminación de stopwords. En elejemplo (2.4.1) utilizamos un campo para almacenar la URL de la página web y elegimos no preprocesarloporque estamos interesados en usarlo sólo para búsquedas literales (de hecho como comentamos anterior-mente, podríamos almacenarlo sin indexarlo, lo que haría que no haya coincidencia aunque se lo busqueliteralmente). Por el contrario, para los campos TITLE y BODY sí queremos un preprocesamiento quefacilite la coincidencia con el documento, por lo que los marcamos con el parámetro Index.ANALYZED.

Como comentamos en al párrafo anterior, además de procesar los campos podemos almacenarlos en formaliteral. En el ejemplo (2.4.1) indicamos que íbamos a almacenar todos los campos al crearlos utilizandoel parámetro Store.YES. Si almacenamos los datos luego podremos recuperar la versión literal del textoindexado (sin preprocesamientos). El almacenamiento es útil para construir un vínculo entre el pseudo-esquema construido en los campos de Lucene y el esquema del documento original.

Índices, Lectores y Escritores

La indexación y la recuperación de documentos se da a través de lectores y escritores del índice (IndexSearchere IndexWriter). Los lectores y escritores son partes fundamentales de la API de Lucene, siendo que unaimplementación básica no necesita conocer mucho que estas interfaces.

Consultas y Analizadores

Como comentamos en apartados previos, Lucene trata las búsquedas y documentos a indexar medianteextensiones de la clase abstracta Analyzer. El objetivo de los analizadores es almacenar los términos enel índice utilizando las técnicas de matching y relevancia que vimos en la subsección (2.1.5).

Lucene cuenta con un lenguaje propio para especi�car las búsquedas, el cual se interpreta para construir unobjeto de tipo Query. Este lenguaje permite, entre otros, de�nir conjunciones y disyunciones de términos,impulsar campos (boosting), búsquedas por proximidad y edit distance. Para generar las consultas esposible utilizar un QueryParser, el cual interpreta la búsqueda, la analiza (utilizando el analizador de�nido)y construye el objeto de tipo Query.

El boosting al que referimos en al párrafo anterior es la implementación de Lucene de los conceptos decampos y zonas presentes en la subsección (2.1.6). Cuando revisemos la fórmula de relevancia utilizadapor Lucene veremos cómo se implementa el boosting.

Directorios

En Lucene existe la posibilidad de almacenar el índice en memoria RAM, �lesystems, bases de datosy otros. Esta capacidad de variar la implementación de la capa de acceso a datos se da a través dedescendientes de la clase abstracta Directory. Esta capa de acceso a datos es extensible, permitiendodiseñar implementaciones particulares que permitirían funcionalidades no estándar como cifrar los datos.

A continuación vemos un ejemplo sintético de indexación y recuperación en Lucene que integra losconceptos que hemos expuesto en los apartados anteriores.

Ejemplo 2.4.2. En este ejemplo generamos un método de indexación y uno de recuperación. Para laindexación creamos un documento que describe personas, siendo que utilizamos un campo para su tesis yotro campo para otros trabajos.

p r i v a t e s t a t i c vo i d i n d e x ( ) throws IOExcept ion{

D i r e c t o r y d i r = NIOFSDirectory . g e tD i r e c t o r y (new F i l e ( "/ l u c en e / l u c e n e t e s t /" ) ) ;I n d e xWr i t e r w r i t e r = new I n d e xWr i t e r ( d i r , new Standa rdAna l y z e r ( ) , MaxFie ldLength .

LIMITED) ;

Document doc = new Document ( ) ;doc . add (new F i e l d ( "AUTHOR" , " J u l i á n Klas " , S to r e . YES , I ndex .ANALYZED) ) ;doc . add (new F i e l d ( "TESIS" , " Recupe rac i ón de I n f o rmac i ón sob r e Modelos de Dominio"

, S to r e . YES , I ndex .ANALYZED) ) ;doc . add (new F i e l d ( "OTHER_WORKS" , "38 JAIIO − Recupe rac i ón de I n f o rmac i ón sob r e

Modelos de Dominio" , S to r e . YES , I ndex .ANALYZED) ) ;w r i t e r . addDocument ( doc ) ;w r i t e r . o p t im i z e ( ) ;w r i t e r . c l o s e ( ) ;

}

p r i v a t e s t a t i c vo i d s e a r c h ( ) throws IOExcept ion , Pa r s eExcep t i on {D i r e c t o r y d i r = NIOFSDirectory . g e tD i r e c t o r y (new F i l e ( "/ l u c en e / l u c e n e t e s t /" ) ) ;I n d e xS ea r c h e r s e a r c h e r = new I n d e xS e a r c h e r ( d i r ) ;

Query query = new QueryPar se r ( "OTHER_WORKS" ,new Standa rdAna l y z e r ( ) ) . p a r s e ( " j a i i o" ) ;

TopDocs r s = s e a r c h e r . s e a r c h ( query , nu l l , 10) ;System . out . p r i n t l n ( " Encontrado ( s ) "+r s . t o t a l H i t s+" r e s u l t a d o ( s ) " ) ;

f o r ( i n t i = 0 ; i < r s . t o t a l H i t s ; i++) {Document h i t = s e a r c h e r . doc ( r s . s co reDocs [ i ] . doc ) ;System . out . p r i n t l n ( "Autor : "+h i t . g e t F i e l d ( "AUTHOR" ) . s t r i n gV a l u e ( ) ) ;System . out . p r i n t l n ( " Te s i s : "+h i t . g e t F i e l d ( "TESIS" ) . s t r i n gV a l u e ( ) ) ;System . out . p r i n t l n ( " Otros : "+h i t . g e t F i e l d ( "OTHER_WORKS" ) . s t r i n gV a l u e ( ) ) ;

}


}

p ub l i c s t a t i c vo i d main ( S t r i n g [ ] a r g s ) throws IOExcept ion , Pa r s eExcep t i on {i ndex ( ) ;s e a r c h ( ) ;

}

Este ejemplo produce el resultado:

Encontrado ( s ) 1 r e s u l t a d o ( s ) :Autor : J u l i á n Klas

Te s i s : Recupe rac i ón de I n f o rmac i ón sob r e Modelos de DominioOtros : 38 JAIIO − Recupe rac i ón de I n f o rmac i ón sob r e Modelos de Dominio

Modelos de IR de Lucene

El modelo de IR (ver subsección 2.1.4) utilizado por Lucene es una combinación del modelo vectorial yel booleano (Apache, 2009b). En Lucene esta combinación consiste en utilizar el modelo booleano parade�nir qué documentos se recuperarán y luego priorizarlos con el modelo vectorial. Tal como comentamosal momento de introducir el modelo booleano, Lucene amplia los operadores AND, OR y NOT permitiendobúsquedas por wildcards, edit distance, frases y rangos (ver subsección 2.1.5).

Dentro del modelo vectorial, los pesos de relevancia aplicados por Lucene son variantes de la familiaTF-IDF. Como veremos a continuación, la aplicación de TF-IDF tiene en cuenta la presencia de campos.

La fórmula de similitud de Apache Lucene17 es (Apache, 2009b):

Similitud (q, dj) = coord (q, dj)× queryNorm (q)×∑∀t∈q

tfL (t, dj)× idfL (t)2 × norm (dj)× boost (t)

(2.4.1)

Donde t es un termino de la query q y dj es el documento que se está evaluando. En el caso de Lucenelas funciones tf e idf que vimos en la subsección (2.1.4) están recalculadas de la siguiente manera:

tfL (t, dj) =√tf (t, dj)

idfL (t) = 1 + logN

df (t) + 1

Los demás términos tienen estos signi�cados:

coord (q, dj) es una escala que depende de cuántos términos de la query aparecen en el documento(a mayor cantidad de términos presentes, mayor peso).

queryNorm (q) es un factor de normalización del tipo(∑

w2i,q

)− 12 . Los valores wi,q dependen del

tipo de objeto Query que se utilice. Este factor de normalización no cambia el orden relativo de losdocumentos (ver que no depende del documento) pero permite comparar los puntajes otorgados aun mismo documento en dos queries distintas.

boost (t) es un valor de impulso18 para el término de la query. Si queremos impulsar dinámicamenteun término de la query lo marcamos con un circun�ejo y un número que Lucene traducirá a lafórmula (2.4.1). Ej: information retrieval^4.

norm (dj) es un cálculo efectuado al indexar que incluye los siguientes factores:

• el boost efectuado sobre el documento antes de indexarlo17Este análisis se hizo para la versión 3 de Lucene, sin embargo, la forma general de esta fórmula suele mantenerse estable.18Traducción del inglés �boost�.


• el boost efectuado sobre el campo antes de agregarlo al documento

• un valor de normalización respecto de la cantidad de términos en el documento. La clase

DefaultSimilirity lo implementa como1

número de términos.

Si queremos que un documento o un campo de un documento del corpus sea más relevante en formaestática, podemos especi�car un valor de impulso de forma similar a como especi�camos boost (t).

Ordenamiento y Filtrado

Comúnmente tenemos que mezclar tareas de recuperación ad hoc con operaciones típicas de un RDBMScomo el ordenamiento y el �ltrado. Si suponemos una aplicación que indexa y recupera información deun corpus de artículos cientí�cos, seguramente nos interese ordenar los resultados (artículos) según elnúmero de veces que fueron citados o �ltrarlos para que la antigüedad de un artículo no exceda ciertacantidad de años.

Lucene permite este tipo de recuperación mediante la clase Sort y las subclases de Filter. Con estemecanismo podemos efectuar ordenamientos y �ltros según el campo del documento que especi�quemos.

Análisis de Lucene

En esta sección vamos a analizar Lucene desde distintos ángulos considerando su uso para la indexaciónde objetos de un modelo de dominio.

Siguiendo los criterios propuestos en (Johnson y Foote, 1988), Lucene no es un framework sino que esuna librería ó biblioteca. El �ujo de control lo debe mantener la aplicación huésped invocando a Luceneal momento de indexar o buscar documentos, por lo que esta herramienta no cuenta con inversión delcontrol (recordemos de la subsección 2.2.1 que los enfoques más puristas agregan IoC como un requisitopara formar un framework). Dado que bajo estos criterios no es un framework, sólo podemos discutirsus características de caja blanca y negra desde el punto de vista de la abstracción como librería. En esecontexto presenta un comportamiento de caja negra ya que posee una API bien de�nida que no requieregrandes conocimientos de su estructura interna. Para usuarios expertos, Lucene se puede extender paraalterar, por ejemplo, las fórmulas de similitud y análisis de texto.

Si bien Lucene permite indexar y recuperar documentos en cualquier aplicación Java, la herramienta estáorientada a documentos. Para indexar objetos de dominio surgen desajustes similares a los estudiados alhablar de persistencia de objetos (ver subsección 2.3.7), los cuales deben ser resueltos por el usuario deLucene.

Los autores de Hibernate Search (Bernard, 2007b) señalan tres desajustes surgidos de utilizar ApacheLucene para indexar objetos de un dominio:

Desajuste de Sincronización (Synchronization Mismatch): consiste en el problema de mantenersincronizado el datastore y el índice en base a los eventos CRUD.

Desajuste Estructural (Structural Mismatch): es el problema de efectuar un mapeo de objetos adocumentos. Este desajuste es similar al que existe cuando se mapean objetos de dominio con JDBCsegún analizamos en la subsección (2.3.7).

Desajuste de Recuperación (Retrieval Mismatch): al recuperar información Lucene devuelve instan-cias de la clase Document y no objetos del dominio.

Una crítica común hacia Lucene desde los autores de Hibernate Search y Compass es que es una soluciónde �bajo nivel�. Si bien esto es especialmente subjetivo, es verdad que Lucene está lejos de ser tan simplede utilizar como, por ejemplo, librerías de logging. Las críticas que hacen los autores de Hibernate yCompass parece estar dirigida a que Lucene puede ser utilizado incorrectamente con facilidad y que tardeo temprano no nos permite abstraernos de qué ocurre dentro de la herramienta.

A continuación vamos a comentar cómo se implementan en Lucene las técnicas principales de IR quehemos visto en la sección (2.1). Es preciso notar que la mayoría de las técnicas de IR aplicadas porLucene son soluciones estándar bien conocidas y descriptas en la literatura.


Lucene implementa la indexación dinámica mediante técnicas similares a las de índices auxiliares ygeneracionales (ver subsección 2.1.5). Estos índices auxiliares son llamados segmentos. Los segmentos sonsubíndices independientes sobre los que es posible agregar y eliminar documentos. Vemos entonces queel índice no es un archivo o estructura privilegiada sino que está formado por un conjunto de segmentosindependientes. Un segmento esta formado por más de una decena de archivos, los cuales almacenan elíndice invertido, las zonas y campos, documentos eliminados y estadísticas para el cálculo de similitud(ver análisis de ecuación 2.4.1).

Una característica de Lucene es que sus índices requieren un mantenimiento explícito mediante la opti-mización. El proceso de optimización aplica la eliminación de documentos dados de baja en el índice asícomo la fusión de segmentos según la política de fusión. El algoritmo de fusión de segmentos tiende abuscar una solución de compromiso entre necesitar acceder a muchos archivos para las búsquedas (lo quedegrada la performance) y requerir fusiones excesivas (lo que afecta principalmente la performance deindexación). El algoritmo de fusión es similar a la fusión logarítmica (Manning et al., 2008) y se explica endetalle en (Cutting, 2004a). Adicionalmente, la operación de optimización también remueve físicamentedel segmento los documentos eliminados y recupera los huecos en la secuencia de numeración introducidospor la eliminación de documentos.

Los eventos de altas, bajas y modi�caciones de documentos se implementan con ciertas sutilezas quedeben comprenderse para trabajar correctamente con Lucene19. En el caso de las altas, luego de queel escritor (IndexWriter) actualiza el índice, los nuevos documentos sólo se hacen visibles a los lectores(IndexReader) al reabrir el índice (en caso de que el índice no estuviera abierto alcanza con abrirlo porprimera vez). Las bajas de documentos se marcan en un vector de invalidaciones y se aplican físicamenteal optimizar el índice. La modi�cación de documentos en Lucene no se implementa estrictamente comotal sino que es necesario efectuar una baja del documento original y un alta del documento modi�cado.De hecho, estas operaciones se aplican sobre interfaces distintas (IndexReader para la baja e IndexWriterpara el alta).

Respecto de la performance de indexación y recuperación, existe un consenso acerca de las buenas mar-cas obtenidas por Lucene. En general se encuentra que Lucene emplea varias técnicas para mejorar superformance (debemos tener en cuenta que la herramienta ha ido adoptando y mejorando técnicas desdesu aparición en el año 2000). Para acelerar la intersección de posting lists, Lucene utiliza skip pointers.Debido a la necesidad de comprimir el índice, se utiliza compresión por front coding para el diccionariode términos junto con variable bit encoding para los identi�cadores de documentos. Esta información sepuede obtener de la documentación de Lucene así como de (Cutting, 2004b). Las técnicas de skip pointers,front coding y variable bit encoding se pueden encontrar en (Manning et al., 2008).

La calidad de los resultados de Lucene (en términos de similitud) está reconocida en la industria como muybuena. Como hemos analizado previamente, Lucene implementa el modelo vectorial mediante variantesde TF-IDF (ver subsección 2.1.4). Las variaciones hechas a TF-IDF se explican bajo criterios heurísticospero la documentación no referencia justi�cativos analíticos de estas modi�caciones. La solución utilizadapara valorizar zonas es intuitiva aunque la documentación no referencia un sustento formal como elpresentado en la subsección (2.1.6). Esto último se explica seguramente por la ausencia de un entrenadory la variabilidad en el número de zonas en un documento.

En términos de concurrencia, Apache Lucene resuelve la indexación y búsqueda con un mecanismo similar(pero no idéntico) al clásico problema de concurrencia de lectores y escritores. El proceso de búsqueda(lector) puede acceder al índice en forma concurrente al mismo tiempo que un indexador (escritor). Ladiferencia con la semántica de lectores y escritores es que éstos debían excluirse mutuamente mientrasque en Lucene es posible buscar mientras se indexa. La exclusión mutua entre escritores sí es necesariay se da mediante archivos de bloqueo (lock �les), quienes previenen la escritura concurrente del índicelanzando una excepción. La existencia de lock �les provee exclusión mutua no solo entre hilos sino entreprocesos.

2.4.2. Hibernate Search

En esta sección analizamos la primera herramienta que busca solucionar el problema de indexación deobjetos de un modelo de dominio, conocida como Hibernate Search (en adelante también la llamare-

19Estas consideraciones seguramente cambien con futuras versiones de Lucene. Recordemos que esta descripción corre-sponde a la versión 3 de la herramienta.


mos simplemente HS ). A continuación vamos a analizar esta herramienta desde distintas perspectivasrelevantes al problema que queremos resolver.

Descripción General

El objetivo de HS es indexar un modelo de dominio persistido con Hibernate Core o JPA, abstrayendo alprogramador de los desajustes que analizamos en las subsecciones (1.1.3) y (2.4.1). HS es una herramientade código abierto implementada en Java, la cual no es independiente sino que depende de Apache Lucene,Hibernate Core y complementos de éste como Hibernate Annotations.

A diferencia del próximo caso de estudio (subsección 2.4.3), los autores de HS recomiendan utilizarlo sóloen conjunto con Hibernate o JPA (Bernard, 2007a)20.

Indexación y Modelo de Dominio

Para poder indexar un dominio particular, HS requiere que introduzcamos annotations de Java que mar-can las clases cuyas instancias son indexables (en adelante hablaremos simplemente de clases indexablesentendiendo que lo que se indexan son instancias).

Estas clases indexables se marcan con @Indexed y junto a ellas se debe indicar qué directorio de Lucenealojará el índice (a priori los índices de cada clase se separan en directorios con un índice propio, aunquees posible almacenar distintas jerarquías en un mismo índice).

El hecho de indexar una clase no sirve para mucho sin indexar sus atributos. Para que un atributo ingreseal índice es necesario anotarlo con @Field. Esta anotación lleva parámetros que especi�can si el contenidodel atributo se debe almacenar, analizar, etc. Estos parámetros son idénticos a los utilizados con Lucenepara crear un Field (ver subsección 2.4.1). Al recuperar un objeto, HS permite efectuar una operación de�proyección� que sólo retorna los atributos indicados (proyectados), ahorrando la carga de recuperar elgrafo de referencias de un objeto. Dado que la proyección no utiliza el RDBMS, para hacer uso de ella esnecesario almacenar en el índice el valor del atributo proyectado.

Para ser indexado y recuperado unívocamente desde el ORM, cada objeto necesita tener una identidad.Para marcar que un atributo identi�ca la instancia, HS utiliza las anotaciones @Id y @DocumentId.Es posible hacer que la identi�cación de un objeto provenga desde otra fuente mediante la anotación@ProvidedId.

Procesos de Indexación

Como discutiremos al abordar la propuesta de solución en la subsección (3.1.3), existen básicamente tresmodos de indexación que tendrían que cubrirse: indexación online, semi-online y o�ine.

HS implementa los tres modos de indexación mediante �backends�, los cuales son llamados de la siguienteforma:

Lucene: utiliza directamente el índice de Lucene. Equivale al modo Online o Semi-Online dependi-endo de si es sincrónico (online) o asincrónico (semi-online).

JMS: equivale al modo O�ine. Se utilizan colas JMS para indicar la necesidad de indexar los objetos.

Los índices se pueden dividir siguiendo un proceso conocido como index sharding, lo cual promueveventajas de performance. En todos los casos, Lucene es quien �nalmente accede al índice, por lo que laspolíticas de bloqueos de archivos son las que maneja esa librería.

20Si bien han pasado algunos años desde esta a�rmación, entendemos que el diseño de Hibernate Search no ha cambiadosustancialmente y se sigue cumpliendo esta recomendación


Jerarquías de Subclasi�cación y Asociaciones

HS permite la indexación automática de todos los atributos de la jerarquía de clases del objeto así comolas asociaciones que ocurren en dicha jerarquía.

Utilizando las anotaciones @IndexedEmbedded y @ContainedIn, es posible indexar grafos de objetos referen-ciados explícitamente o en colecciones. Esto es importante ya que un modelo rico de objetos posiblementerequiera colaboraciones, las cuales formarán un grafo de objetos compuestos. Cuando un objeto com-puesto en otro es modi�cado, HS actualiza el índice para que el objeto huésped se actualice con la nuevainformación del objeto contenido (eso es porque HS asigna al objeto contenedor como �dueño� de lospostings).

Para generar el índice invertido es necesario convertir las entidades del dominio a una representación comotexto. En HS esta conversión se aplica mediante �puentes� (bridges). Los puentes tienen la responsabilidadde convertir un tipo particular de objeto a String. Un hecho positivo de la implementación de HS es que noobliga a la entidad en si misma a implementar una interfaz de conversión sino que inyecta una dependenciaal conversor mediante el annotation @FieldBridge.

Modelos de IR y Puntajes

El modelo de IR y puntajes es heredado directamente de Lucene, por lo que HS implementa internamenteun modelo vectorial. Los cálculos de TF-IDF, impulsos y demás se mantienen tal como de�nimos en lasubsección (2.4.1). Para manejar los valores de impulso, HS implementa un annotation @Boost, el cualtraslada este valor al índice de Lucene.

Para alterar la implementación de similitud es necesario modi�car directamente las clases de Lucene comoDefaultSimilarity o Weight.

En HS existe la posibilidad de ordenar y �ltrar los resultados tal como hacíamos con Lucene. Para elcaso del ordenamiento se debe usar la API de Lucene mediante las clases Sort y SortField. El �ltrado seresuelve también utilizando la API de Lucene, pero con cierta abstracción provista por HS.

Recuperación, Queries, Matching y Acceso a Datos

La recuperación de objetos en HS funciona como un wrapper de una búsqueda de Lucene. Para el usuariode HS, la tarea de recuperación se presenta como un híbrido entre el trabajo con el ORM y con Lucene.

Como resultado de las búsquedas, HS retorna el objeto de dominio que considera relevante para labúsqueda. La rigurosidad con la que esto se implementa garantiza la identidad, es decir, si utilizamosel operador == entre los objeto devueltos por el ORM y HS el resultado sera true. Esto implica queexiste una única representación de los objetos de dominio (en rigor, internamente también existe larepresentación como Document de Lucene).

Las operaciones extendidas (ver subsección 2.1.5) de HS se resuelven utilizando el motor de IR de Lucene,por lo cual HS tiene la misma expresividad que éste.

En la terminología de Hibernate se suele utilizar el término hidratación para referir al proceso de convertirobjetos que sólo tienen inicializados sus identi�cadores (deshidratados) en los objetos completos con todossus atributos (hidratados). Esto es importante al trabajar con proyecciones (este concepto también estápresente en Hibernate Core). Una proyección permite recuperar una forma deshidratada del objeto, en lacual sólo podemos obtener (proyectar) datos que hemos almacenado en el índice de Lucene. La proyecciónpuede ser útil para obtener valores del objeto sin cargarlo completamente (lo cual requiere utilizar el ORMy eventualmente cargar un grafo de objetos). Existe una discusión respecto de si el método de proyecciónes mejor que una hidratación desde el ORM ya que el segundo utiliza caches del ORM para evitar accederal RDBMS, lo que podría resultar en una solución aún más e�ciente.

A la hora de procesar los textos de los atributos, HS utiliza los analizadores de Lucene, permitiendo variarla implementación por clase o atributo. De todas formas, la utilización de analizadores distintos dentrode una misma clase es compleja ya que vuelve difícil efectuar las queries (porque no podemos usar unúnico analizador para todos los campos).


Una característica interesante de HS es que permite variar el analizador de forma dinámica dependiendodel estado de la entidad que se indexa. Esto permite que si un objeto representa, por ejemplo, la entradade un blog en español, podremos utilizar un analizador distinto que si la entrada esta escrita en hebreo.Existen algunas otras particularidades respecto de analizadores en HS para las cuales sugerimos consultarla documentación.

Otra característica de HS es que permite restringir los resultados de las consultas a una entidad de negocioparticular. Esto permite que una query como Batman retorne instancias de la clase Film (película) pero noinstancias de la clase Toy (juguete). Este comportamiento además es polimór�co, esto es, si B es subclasede A y aplicamos un �ltro para los objetos de tipo A, también obtendremos objetos del tipo B.

Análisis de Hibernate Search

El análisis de esta herramienta lo diferimos hasta después de describir la próxima herramienta (CompassProject). Al �nalizar la próxima sección haremos un análisis conjunto y comparativo de HS y Compass.

2.4.3. Compass

Compass Project es otra herramienta que busca resolver el problema del Domain Model Search. En lospróximos apartados analizaremos esta herramienta desde perspectivas similares a las que utilizamos paraanalizar Hibernate Search.


El objetivo de Compass es permitirnos indexar distintas fuentes estructuradas de información. Compasspermite indexar no sólo modelos de dominio sino archivos XML, representaciones JSON y otros. Al igualque Hibernate Search, esta herramienta está construida sobre Apache Lucene.

Compass se compone de tres módulos principales:

Core: es responsable de implementar el sistema de mapeo de entidades, las transacciones, la APIhacia el usuario y las extensiones a Lucene.

Gps: se ocupa de la integración con distintos ORM (Hibernate, JDO, JPA) y las utilidades para laindexación de datos desde una base de datos mediante SQL.

Spring: efectúa la integración entre Compass y los módulos del framework Spring.

La mayor parte de nuestra descripción se basará en el módulo Core y en menor medida en el Gps.

Como comentamos al estudiar HS, mientras éste está dirigido a los usuarios con un modelo de dominiopersistido con Hibernate o JPA, Compass presenta una visión más generalista, admitiendo otras combi-naciones de entidades y frameworks de persistencia.

Veremos que Compass tiene un comportamiento intermedio entre framework y librería. En general lainteracción con Compass requiere que instanciemos la clase Compass y dirijamos el �ujo de control, locual es propio de una librería. En situaciones como la inspección de los objetos y la conversión de atributospara indexación, es la herramienta quien invoca nuestro código trabajando como un framework de cajanegra.


El trabajo con nuestras entidades depende de si vamos a indexar un modelo de dominio, archivos XML,JSON o el resultado de una consulta a una base de datos. Estos mapeos se implementan en cuatro modosde trabajo conocidos como OSEM (Object/Search Engine Mapping), XSEM (XML to Search EngineMapping), JSEM (JSON Search Engine Mapping) y RSEM (Resource/Search Engine Mapping).

Compass reimplementa conceptos y objetos de Lucene que permiten que nuestro trabajo tome ciertadistancia de este. En particular las clases Document y Field de Lucene se respectivamente en Resource yProperty.


Indexación OSEM (Object/Search Engine Mapping) Este tipo de indexación se corresponde conla provista por Hibernate Search y es la que más nos interesa ya que apunta a indexar un modelo dedominio.

En el OSEM es necesario indicar qué clases y atributos son indexables mediante anotaciones de Java,con�guración XML o JSON. En esta descripción vamos a cubrir el método de anotaciones, siendo quebasta con saber que el resto de los métodos son equivalentes.

Para indexar las instancias de cierta clase, se debe utilizar la anotación @Searchable. Por defecto, cadaentidad se indexa en un sub índice separado. La anotación @SearchableId le indica a Compass cuál es elidenti�cador de la entidad. Este identi�cador deberá ser usado si queremos obtener la entidad real desdeel ORM. Para los casos en los que es necesario que la clave de una entidad esté representada por otraentidad compleja, se agrega un annotation @SearchableIdComponent, la cual traslada el mapeo de clave ala segunda entidad.

Existe un tipo distinguido de clases llamadas �raíces�. Las clases raíces son las que efectivamente puedenser recuperadas en una búsqueda. Esto implica que si tenemos un objeto Client que contiene un objetoName, las búsquedas que coincidan por dicho atributo retornarán el Client. Dado que el objeto recuperadoes el de la clase raíz, éstos están obligados a de�nir un atributo @SearchableId.

En términos de independencia del modelo de dominio (ver subsección 2.2.2), Compass introduce algunasrestricciones como:

Default Constructor: es necesario para instanciar los objetos mediante Constructor.newInstance().Este requerimiento suele estar presente en los frameworks de persistencia como Hibernate Core.Este constructor puede tener cualquier grado de visibilidad.

Property Identi�er: toda clase raíz debe poseer al menos un identi�cador de clave primaria.

Vemos entonces que las imposiciones sobre el modelo de dominio son bastante básicas, siendo que lanecesidad de un constructor sin argumentos es con seguridad la más discutible.

Las clases pueden de�nir meta datos que se indexarán de forma idéntica para todas sus instancias mediantela anotación @SearchableConstant.

Otros métodos de indexación (XSEM , JSEM y RSEM) Compass permite indexar fácilmenteXML y JSON así como nos da facilidades para mapear una fuente arbitraria de datos a un Resource,el cual luego puede ser indexado. Este último mapeo es útil para indexar tablas de una base de datoscuando no se dispone de un modelo de dominio que acompañe dicho esquema.

Si bien estos modos de mapeo son útiles para algunos casos, no forman parte de la solución al problemaprincipal que queremos atacar (subsección 1.1.3). Por esto en adelante hablaremos principalmente delmétodo de indexación OSEM. Continuando con esta línea, a continuación vemos un ejemplo básico:

Ejemplo 2.4.3. La indexación de objetos se efectúa mediante una interfaz muy similar a la utilizada conotros ORM como Hibernate Core. Veamos un ejemplo tomado de la documentación de Compass (CompassProject, 2009):

1 CompassCon f i gu ra t i on con f =2 new CompassCon f i gu ra t i on ( ) . c o n f i g u r e ( ) . addC la s s ( Author . c l a s s ) ;3 Compass compass = con f . bu i ldCompass ( ) ;4 CompassSess ion s e s s i o n = compass . openSe s s i on ( ) ;5 CompassTransact ion tx = nu l l ;6 t ry {7 t x = s e s s i o n . b e g i nT r an s a c t i o n ( ) ;8 . . .9 s e s s i o n . save ( autho r ) ;10 CompassHits h i t s = s e s s i o n . f i n d ( " j a c k london " ) ;11 Author a = ( Author ) h i t s . data (0 ) ;12 Resource r = h i t s . r e s o u r c e (0 ) ;13 . . .14 t x . commit ( ) ;


15 } catch ( CompassExcept ion ce ) {16 i f ( t x != nu l l ) t x . r o l l b a c k ( ) ;17 } f i n a l l y {18 s e s s i o n . c l o s e ( ) ;19 }

Las líneas 1 a 3 generan una con�guración de Compass y una fábrica de sesiones (en este caso la con�gu-ración es programática). La con�guración y la generación de la fábrica de sesiones es un proceso costoso,por lo que se suele efectuar una única vez por instancia de la aplicación. Después de la línea 4 aparece elcódigo que se ocupa de abrir una transacción, efectuar una query y obtener los resultados como objeto dedominio o Resource (este es el código que veremos con mayor frecuencia en la aplicación).

Compass tiene un tratamiento transaccional del índice, el cual requiere una demarcación programática delas transacciones. Los niveles de aislamiento provistos por Compass son: read_commited, lucene y async.En los próximos apartados detallaremos la semántica de estos modos.

Como vimos en el ejemplo (2.4.3), el estilo de programación para la actualización del índice es muy similaral de los ORM como Hibernate. Asimismo, la tarea de recuperación es similar al trabajo con Lucene.Según los autores de Compass, estos dos hechos son una estrategia para facilitar la adopción de Compasspor parte de quienes ya trabajan con Apache Lucene y los ORM tipo Hibernate Core.


Compass permite la indexación programática utilizando la interfaz CompassSession así como la indexaciónautomática mediante el módulo Gps.

El módulo Gps permite indexar de forma transparente un �dispositivo� de tipo CompassGpsDevice. Dosejemplos de dispositivos pueden ser Hibernate o iBATIS. El Gps puede indexar todos los datos deldispositivo (eventualmente un RDBMS) así como estar a la �escucha� de eventos y replicar lo que sucedeen el ORM hacia su índice.

El índice en Compass está formado por un conjunto de subíndices. Cada subíndice contiene exactamenteun índice de Lucene (el cual internamente además contiene segmentos generacionales). Para garantizar latransaccionalidad, las operaciones de escritura bloquean los subíndices (por lo cual es útil contar con unabuena dispersión de entidades entre los subíndices). Dentro de un mismo subíndice, la exclusión mutuasobre los segmentos se resuelve utilizando los mecanismos de bloqueos ínter e intra procesos de ApacheLucene.

Compass permite utilizar distintos tipos de transacciones mediante transaction managers (TM). Un TMes encargado de proveer semánticas de consistencia en la lectura y escritura del índice. Los TM másdiscutidos en la documentación son: read_commited, lucene y async.

El TM read_commited garantiza que las transacciones sólo ven cambios con�rmados en el índice (con ex-cepción de los cambios que la propia transacción está llevando a cabo). Este TM bloquea el subíndice sóloal efectuar una operación de escritura. El siguiente TM conocido como lucene, es similar al read_commitedcon la diferencia de que los cambios hechos por la transacción no son visibles por ella hasta con�rmarse.Estos TM son similares al modo de indexación online que comentamos junto a HS. El TM async permiteque un hilo en paralelo tome la tarea de indexación (es decir, el método commit() retorna sin con�rmarrealmente la escritura), lo que relaja la semántica de consistencia. La documentación de Compass tambiénhabla de otros niveles transaccionales conocidos como mt, search y tc. En particular el TM tc (terracota)funciona de manera similar al modo de indexación o�ine que discutimos en HS, permitiéndonos efectuaruna indexación diferida respecto de la con�rmación de la sesión.

Al efectuar búsquedas, podemos trabajar fuera de una transacción pidiendo instancias de CompassDe-tachedHits (el cual no permite escribir en el índice).

Jerarquías de Subclasi�cación y Asociaciones

Dado que la subclasi�cación es una herramienta muy importante en los diseños de objetos, Compasssoporta la indexación de jerarquías de entidades anotadas con @Searchable. Cuando se indexa una entidad


de la parte inferior de la jerarquía, todos los campos anotados de la parte superior de la jerarquía seheredan automáticamente.

Una propiedad interesante soportada por Compass es la capacidad de indexar entidades que no fueronanotadas pero que su jerarquía contiene en sus capas superiores clases anotadas con @Searchable. En estoscasos, la indexación sólo trabaja sobre los campos anotados en la parte superior de la jerarquía, mientrasque la búsqueda recupera y entrega objetos a partir de los atributos de toda la jerarquía.

Tal como sucedía con HS, Compass también permite indexar clases compuestas. Si queremos indexar unaasociación debemos anotarla con @SearchableProperty. Esta anotación permite indexar automáticamenteobjetos de tipo String, primitivos de Java (int, �oat, double, etc.), java.util.Date y java.util.Calendar.

Si tenemos una asociación entre objetos anotados como @Searchable y requerimos que la recuperación deuno de ellos también recupere (hidrate) el otro, podemos anotar la asociación con @SearchableReference.Este mecanismo permite utilizar lazy-loading para evitar recuperar grafos extensos desde el índice. Pararesolver las asociaciones circulares existe una anotación @SearchableParent, la cual previene a Compassde tal situación.

Cuando estamos asociando objetos anotados con @Searchable, podemos lograr que una búsqueda quedebería retornar el objeto �contenedor� también recupere el objeto �contenido�. Para lograr este efectodisponemos de la anotación @SearchableComponent.

En ocasiones una entidad contiene una lista o un mapa que permite implementar algo así como una �clasecon atributos variables�. En ciertos casos ésos elementos deben ser indexados como si fueran atributosconcretos, por lo que Compass permite resolver dinámicamente el nombre y el valor de esos atributosdinámicos utilizando la anotación @SearchableDynamicProperty.


Analizando la documentación de Compass (Compass Project, 2009), el modelo de IR y puntajes ocupaun lugar relativamente pequeño en comparación con las características de transaccionalidad. Este hechotambién se re�eja en la herramienta, la cual se limita a utilizar el modelo de similitud de Lucene. Aligual que con HS, es posible utilizar la API de Lucene para modi�car las fórmulas de similitud y efectuarordenamientos basados en atributos especí�cos.

Desde el punto de vista de la con�guración, Compass permite de�nir un valor de impulso para el algoritmode similitud de Lucene mediante la anotación @SearchableBoost, la cual es idéntica al annotation @Boostde HS.


Compass implementa directamente el modelo de consultas de Lucene envolviéndolo en un objeto de tipoCompassQuery. Las consultas que se pueden efectuar tienen exactamente la misma expresividad que lasde Lucene, excepto por pequeños agregados como mejoras al sistema de consultas de rangos.

Un aspecto central que distingue la forma de trabajar de Compass es el método de hidratación de losresultados. La hidratación depende de si activamos o no el marshalling. Cuando el marshalling estáactivo, los datos necesarios para hidratar el objeto se obtienen desde los campos almacenados en elíndice invertido. Esto implica que para recuperar los objetos de dominio tenemos dos caminos: utilizarmarshalling para hidratar el objeto en base a la representación del índice o recuperar desde el índice losidenti�cadores para luego consultar nuestro ORM.

Es inmediato notar que el marshalling tiene impacto sobre el tamaño del índice de Lucene, el consumode memoria y la velocidad del sistema. Por esto también es posible escoger la solución de compromisomás adecuada al problema efectuando un marshalling parcial del objeto. Cuando efectuamos un marshallparcial, los atributos que no pueden recuperarse se cargan con un valor null. Eventualmente, también esposible no hacer marshalling y trabajar directamente sobre los objetos de tipo Resource.

Como es de esperar, la expresividad de las consultas es la misma que la de Apache Lucene. Si bienCompass posee objetos de tipo Resource, la hidratación permite obtener como resultado de una búsquedanuestro objeto de dominio.


Internamente Compass utiliza analizadores compatibles con los Analyzer de Lucene. Es factible escogerel analizador en función del atributo que se está indexando mediante la anotación @SearchableAnalyzer.

Así como vimos que podemos utilizar un objeto CompassDetachedHits, la implementación más comúnutilizará el envoltorio del objeto Hits de Lucene llamado CompassHits. Esta reimplementación del objetode Lucene agrega el comportamiento necesario para trabajar en el entorno transaccional de Compass.

Al estudiar las técnicas de operaciones extendidas (subsección 2.1.5), vimos que puede ser util contarcon un motor de correcciones o sugerencias soportado por un tesauro. Compass provee este servicio desugerencias simulando el �Did you mean� que ofrecen buscadores como Google. El proceso de generaciónde sugerencias corre en segundo plano, reconstruyendo periódicamente el índice de correcciones.

Ejemplos

En este apartado vamos a ver algunos casos concretos de trabajo con Compass (los ejemplos son mayor-mente adaptaciones de muestras y tests JUnit que acompañan a la herramienta).

Ejemplo 2.4.4 (Con�guración e Indexación de un Objeto de Dominio). En este ejemplo vemos (a) cómose construye la con�guración de Compass y (b) se opera con los objetos de dominio.

1 CompassCon f i gu ra t i on c o n f i g = new CompassCon f i gu ra t i on ( ) . c o n f i g u r e ("/ org /compass/ sample / l i b r a r y / compass . c f g . xml" ) . addC la s s (

Author . c l a s s ) . addC la s s ( A r t i c l e . c l a s s ) . addC la s s (Book . c l a s s ) ;2 compass = c o n f i g . bu i ldCompass ( ) ;3 compass . ge tSea rchEng ine IndexManage r ( ) . d e l e t e I n d e x ( ) ;4 compass . ge tSea rchEng ine IndexManage r ( ) . c r e a t e I n d e x ( ) ;5 compassTemplate = new CompassTemplate ( compass ) ;

La línea número 1 genera la con�guración desde un XML y agrega el mapeo de dos clases. La líneanúmero 2 genera el objeto compass a partir de esta con�guración, dejando el sistema listo para generarsesiones (CompassSession) o trabajar mediante un template (CompassTemplate). Las líneas 3 y 4 eliminanel índice actual. La línea número 5 genera un objeto de tipo CompassTemplate que explicaremos en breve.

En el siguiente fragmento de código vemos la forma transaccional de operar en Compass para almacenardos objetos:

// generamos dos o b j e t o s de domin ioAuthor jackLondon = new Author ( ) ;jackLondon . s e t I d (new Long (1 ) ) ;jackLondon . setName (new Name( "Mr" , " Jack " , "London" ) ) ;Ca l enda r c = Ca l enda r . g e t I n s t a n c e ( ) ;c . s e t (1876 , 0 , 12) ;jackLondon . s e t B i r t h d a t e ( c . getTime ( ) ) ;jackLondon . setKeywords (new S t r i n g [ ] { " amer i can autho r " }) ;

whiteFang = new Book ( ) ;whiteFang . s e t I d (new Long (1 ) ) ;whiteFang . s e t T i t l e ( "White Fang" ) ;c . s e t (1906 , 0 , 1) ;whiteFang . s e tPub l i s hDa t e ( c . getTime ( ) ) ;whiteFang . setSummary ( "The r emarkab l e s t o r y o f a f i e r c e l y i ndependen t

c r e a t u r e o f the w i l d " ) ;whiteFang . setKeywords (new S t r i n g [ ] { " j a c k london " , " c a l l o f the w i l d " }) ;jackLondon . addBook ( whiteFang ) ;

// comienza l a i n t e r a c c i ó n con CompassCompassSess ion s e s s i o n = compass . openSe s s i on ( ) ;CompassTransact ion tx = nu l l ;t ry {

tx = s e s s i o n . b e g i nT r an s a c t i o n ( ) ;


s e s s i o n . save ( jackLondon ) ;s e s s i o n . save ( whiteFang ) ;t x . commit ( ) ;

} catch ( Excep t i on e ) {i f ( t x != nu l l ) { tx . r o l l b a c k ( ) ; }throw e ;

} f i n a l l y {s e s s i o n . c l o s e ( ) ;

}

Si no queremos encargarnos de abrir y cerrar la sesión, podemos utilizar una colaboración que respondeal patrón de diseño Template (Gamma et al., 1995):

compassTemplate . save ( jackLondon ) ;

En este último caso Compass fue el responsable de abrir la sesión, con�rmarla y cerrarla, actuando comoun framework de caja negra. Si quisiéramos efectuar una operación más compleja utilizando este patrón,podemos hacer que colaboren CompassCallbackWithoutResult y CompassTemplate como en el siguientefragmento de código:

compassTemplate . e x e cu t e (new CompassCa l lbackWithoutResu l t ( ) {protected void doInCompassWithoutResu l t ( CompassSess ion s e s s i o n ) throws

CompassExcept ion {// cargamos un " j a c k london "Author autho r = ( Author ) s e s s i o n . l o ad ( Author . c lass , jackLondon . g e t I d ( ) )

;// y su l i b r o " wh i t e fang "Book whiteFang = (Book ) s e s s i o n . l o ad (Book . c lass , whiteFang . g e t I d ( ) ) ;

// borramos a l au to r y a su l i b r o ( ún icamente d e l í n d i c e )s e s s i o n . d e l e t e ( au tho r ) ;s e s s i o n . d e l e t e ( book ) ;

}}) ;

A continuación efectuamos el análisis de Hibernate Search y Compass Project.

2.4.4. Análisis de Hibernate Search y Compass

En esta subsección analizamos HS y Compass buscando los siguientes objetivos:

entender las decisiones de diseño que se tomaron,

identi�car sus debilidades y fortalezas,

establecer un análisis comparativo entre ellas.

Este aprendizaje permitirá que nuestro motor de búsqueda adopte sus mejores prácticas y evite suscaracterísticas no deseables. A medida que avancemos sobre cada tema vamos a formalizar la discusiónmediante proposiciones, las cuales expresan los criterios que surgen del análisis de las herramientas. Estasproposiciones quedarán completas cuando tratemos la propuesta de solución, donde agregaremos casos yaspectos que no han sido cubiertos por HS y Compass.

Características Generales

Tanto HS como Compass buscan resolver el problema de indexación y recuperación de información deun modelo de dominio envolviendo Apache Lucene para que pueda indexar y recuperar objetos de undominio.


La principal crítica que podemos formular hacia HS y Compass es que no aprovechan al máximo elhecho de trabajar con objetos de dominio por sobre los documentos de Lucene. El hecho de haber sidoconcebidos como un envoltorio de Lucene o un atajo para reutilizar su infraestructura ha importado viciosdel mundo de los motores de búsqueda orientados a texto plano o documentos. En los próximos apartadosveremos cómo la delegación de trabajo sobre Lucene (orientado a documentos) tiende a limitar la riquezade indexación y recuperación de objetos de estas dos herramientas.

Veamos algunos problemas del esfuerzo por integrarse con Lucene:

Abstracción Incompleta: a pesar de la so�sticación de estos envoltorios, aún debemos conocer losconceptos principales y funcionamiento de Lucene. Esto ocurre principalmente en HS, donde nosencontramos con grados de abstracción propios del trabajo con Lucene. Por ejemplo, si en HSqueremos efectuar una búsqueda, debemos instanciar explícitamente un objeto Query de Lucene.Otro ejemplo que impacta tanto a Compass como a HS es la inspección física de los índices, la cualrequiere utilizar inspectores de índices de Lucene como Luke.

Infraestructura Correctiva: en HS y Compass se construyen infraestructuras cuyo único propósitoes evitar limitaciones de Lucene. Por ejemplo, las técnicas de partición de índices en HS y Compasstienen por objetivo mejorar aspectos negativos de la implementación del índice de Lucene (como losbloqueos). Otro caso es la optimización de los índices, la cual propaga decisiones de con�guraciónhasta las capas de HS y Compass por más que son problemas exclusivos de Lucene. Es decir, estasinfraestructuras están condicionadas por forzar la reutilización a bajo nivel de Lucene.

Desaprovechamiento Estructural y Semántico: al momento de implementar las fórmulas de similitud,ninguna de las dos herramientas toma su�cientemente en cuenta las interrelaciones entre objetosy su riqueza estructural. Más adelante veremos cómo esta riqueza estructural podría traducirse enconsultas jerárquicas como las de XML retrieval (ver Manning et al., 2008). Técnicas como PageR-ank y HITS (subsección 2.1.6) tampoco están aprovechadas. Esta no es una limitación necesaria delas herramientas sino que existe por el uso directo de las fórmulas de similitud de Lucene, el cualse limita a implementar zonas y campos (ver subsección 2.1.6).

Es preciso comentar que en ninguna de las dos herramientas plantea como objetivo primordial el ocul-tamiento de Lucene. Sin embargo, veremos muchos ejemplos en los cuales en vez de trabajar con unframework de indexación de objetos terminamos haciéndolo con dos herramientas: una librería de in-dexación y un envoltorio de ésta. Un ejemplo de esta dualidad aparece en HS, el cual obliga a elegir unaestrategia de lectura del índice (shared, not-shared o custom). Para elegir esta estrategia es necesario com-prender que los índices de Lucene mejoran su performance luego de un tiempo de precalentamiento. Esdecir, para tomar una decisión debemos conocer una herramienta adicional (Lucene) que trabaja sobreuna abstracción diferente a los objetos (documentos). En general encontraremos que, respecto de HS,Compass cubre en objetos propios una mayor porción de la API de Lucene.

Dado que Lucene evoluciona independientemente de Compass y HS, existe una tensión propia de lanecesidad de éstos de ser compatibles con Lucene. A medida que Lucene introduce mejoras progresivas,eventualmente se vuelve incompatible con versiones previas (de hecho la versión 3.0 muestra incom-patibilidades con las anteriores). Para aprovechar dichas mejoras, los dos proyectos deberán producirperiódicamente versiones compatibles con Lucene (en el caso de HS, además estamos acoplados a ciertasversiones de Hibernate Core, Annotations y otros).

Comportamiento como Framework

Tanto HS como Compass dan un gran paso adelante respecto de Lucene, el cual hemos visto que tienecomportamiento de librería. En el caso de HS, la indexación se maneja automáticamente invocandocódigo del usuario cuando el framework lo decide (un ejemplo son los bridges que convierten tipos dedatos). En Compass, la indexación mediante un Gps también tiene el mismo estilo que el de HS. Amboscomportamientos son típicos de un framework de caja negra, lo cual hemos visto que es un aspectodeseable (ver subsección 2.2.1)

Sin embargo, tanto HS como Compass exhiben algunos comportamientos que no son propios de unframework de caja negra sino de una librería. Como veremos en el próximo apartado, Compass permite


indexar objetos programaticamente mediante sesiones, lo cual produce una interacción muy similar a laque existía con Lucene (cuyo comportamiento vimos que era del tipo librería).

Las situaciones que requieren manejo explícito del �ujo de control no siempre son indeseables. Existenocasiones en la cual es conveniente operar de forma explícita ignorando los eventos CUD que suceden encada transacción, como el caso de la indexación en lotes. De aquí surge la siguiente proposición:

Proposición 1. Es deseable que el motor de búsqueda provea un comportamiento de caja negra medianteinversión del control (subsección 2.2.1). Sin embargo, es importante que el usuario del framework puedahacerse dueño del �ujo de control en los puntos donde la inversión de control no sea conveniente.


En esta sección vamos a analizar el espíritu de trabajo de cada una de las herramientas en cuanto aindexación de objetos. Las perspectivas desde las cuales necesitamos analizar la indexación son: soportetransaccional, modelo de programación de actualizaciones al índice y mapeo de entidades de dominio.

A la hora de la indexación, Compass y Hibernate Search muestran �losofías muy distintas en cuanto atransaccionalidad. Compass implementa transacciones con distintos niveles de aislamiento mientras queHS no implementa transacciones sino que simplemente utiliza los mecanismos de exclusión mutua deLucene. Este hecho forma parte de una gran controversia entre los dos proyectos, ya que desde Compassven la transaccionalidad como algo indispensable y desde HS como algo secundario cuya solución debevenir desde Lucene.

Las transacciones de Compass incluyen la etapa de actualización del índice pero dejan fuera de su alcancela etapa persistencia en el ORM. Esto es, las transacciones de Compass sólo garantizan niveles ACIDsobre el índice de Lucene. En el caso de Compass, dado que la hidratación se hace desde el índice, estasemántica puede ser importante para evitar inconsistencias entre sesiones concurrentes. Fuera del casode Compass, esta semántica no parece brindar mayores bene�cios que la garantía de consistencia sobreel índice (la cual se puede obtener mediante exclusión mutua como en HS).

Los autores de Hibernate señalan que no es deseable que una falla en la indexación produzca un rollback enla transacción de negocio (esto es discutible caso por caso), por lo que una semántica transaccionalmentefuerte que incluya al ORM puede no ser la más adecuada. Esto induce a una nueva proposición.

Proposición 2. Si el motor de búsqueda implementa un comportamiento transaccional, el mismo seráajustable, permitiendo variarlo entre los niveles:

Nivel 1: no hay comportamiento transaccional, sólo garantías de consistencia frente al acceso con-currente al recurso.

Nivel 2: ídem nivel anterior pero agrega propiedades ACID para el acceso al índice.

Nivel 3: ídem nivel anterior pero las propiedades ACID tienen en su alcance tanto la operación conel ORM como con el índice.

La implementación del nivel 1 es condición necesaria para cualquier motor de búsqueda que quiera man-tener su índice consistente. Los niveles 2 y 3 son opcionales pero la implementación debe permitir alusuario la elección de los niveles previos ya que hay aplicaciones que no requieren esta semántica.

Compass permite trabajar sobre el índice con �exibilidad mediante transacciones programáticas (enadelante TP), Templates y Gps.

Las TP se asemejan al trabajo con una librería ya que el usuario de la herramienta debe mantener el �ujode control, demarcar las transacciones y atrapar excepciones. El caso de las transacciones programáti-cas debe evitarse ya que obliga a tener código duplicado para crear/iniciar/cerrar la sesión y atraparexcepciones.

La utilización de Templates es más razonable ya que sólo requiere que especi�quemos operaciones entreobjetos de dominio y el índice, sin requerir el código relacionado con la transacción. Sin embargo, siutilizamos el Template para eventos de escritura sobre el índice (toda operación excepto las búsquedas),


estamos desaprovechando la inversión de control de los ORM que pueden ser programados para noti�-carnos de eventos de persistencia.

Este último comportamiento por eventos está dado por el Gps, quien se registra a los eventos de persis-tencia y se ocupa de todo el trabajo de indexación.

Como ya comentamos, HS no soporta las transacciones de la misma forma que Compass. Por esto, en HSno encontraremos problemas de demarcación de transacciones sino que éste indexa los objetos en base aeventos del ORM (muy similar al Gps de Compass). Sin embargo, para casos en los que las capacidades debúsqueda se agregan después de que el sistema entra en operación, existen un mecanismo de indexaciónmanual. Dado que HS no soporta transacciones, este mecanismo de persistencia manual no es exactamentecomparable a las TP o a los Templates, sino que es similar a la indexación de documentos en Lucene.

Con este análisis podemos llegar a la siguiente observación para tener en cuenta en nuestro buscador:

Proposición 3. Para evitar la repetición de código, aprovechar la inversión del control y ganar compor-tamiento de framework de caja negra, las operaciones sobre el índice deben ocultarse al usuario del motorde búsqueda y, cuando esto no sea posible, se deben proveer Templates que eviten la repetición de código.

Existe un caso para el cual la utilización de Templates y eventos no es posible. Si necesitamos lanzaruna excepción propia de la aplicación, no tenemos forma de lanzarla desde dentro del Template ya quela cláusula throws debe especi�car una tipo de excepción del motor de búsqueda (o un Exception, lo cualtampoco se aconseja ya que estaríamos atrapando más casos que los que sabemos manejar).

Respecto del problema del desajuste de sincronización (synchronization mismatch, ver subsecciones 1.1.3y 2.4.1), utilizar TP o Templates requiere que cualquier actualización de los objetos de dominio sereplique explícitamente sobre el índice, lo que tiende inevitablemente a un sistema difícil de mantener ya la aparición de errores. Esto nos lleva a la siguiente observación:

Proposición 4. Para evitar el problema del desajuste de sincronización, las operaciones CUD (cre-ate, update y delete) deben ser atrapadas por el motor de búsqueda sin intervención del usuario de laherramienta.

Existen excepciones por las cuales todavía es necesario contar con Templates o TP. Una de estas excep-ciones es el caso de que el ORM no dé aviso de los eventos CUD. Por esto el motor de búsqueda tambiéndebe dar un acceso similar a las TP o Templates de Compass, siempre pre�riendo estos últimos. Otraexcepción a la indexación automática por eventos tiene que ver con la necesidad de indexar las entidadesmanualmente fuera de los procesos de negocio transaccionales (este caso fue analizado previamente en elapartado de �Comportamiento como Framework�).

Un campo en el cual las dos herramientas son muy potentes es en la resolución del structural mismatch(ver subsección 2.4.1). Las dos implementaciones proveen mecanismos a tener en cuenta como: soporte desubclasi�cación, composición de objetos, indexación de colecciones, reconocimiento de claves complejas,�ltrado de resultados por tipo de instancia y transformación de tipos de datos complejos. Como vimospreviamente, si bien las dos herramientas logran una expresividad similar en cuanto a qué pueden indexarde un objeto y sus relaciones, la forma en la que lo hacen produce controversias acerca de cómo recuperaresta información (ver discusión acerca de los modelos de hidratación en HS y Compass). Esto lo podemosenunciar en la siguiente proposición:

Proposición 5. Las capacidades de indexación y recuperación de objetos del motor de búsqueda debenincluir soporte para:

Subclasi�cación

Polimor�smo

Composición

Colecciones

Claves complejas

Transformación de atributos


Restricción de resultados por tipo de instancia

El tipo de soporte que debemos dar a cada característica varía dependiendo de si estamos en un contextode indexación o recuperación. Como ejemplo, podemos adelantar que reconocer colecciones durante laindexación nos permite indexar los objetos contenidos en una lista y no la lista en sí misma, mientrasque al recuperar objetos podemos reconocer las listas para generar proxys que utilicen lazy loading.Estos casos se abordarán en detalle el tratar la propuesta de solución, donde también incluiremos otrasdimensiones como la seguridad.

Al comenzar este apartado dijimos que una de las perspectivas desde la cual analizaríamos el problemaes el mapeo de los objetos de dominio. El término mapeo debe ser utilizado con mucho cuidado ya quees propenso a confusiones. En el ámbito de los ORM hablamos de mapeos entre objetos y tablas deun RDBMS. En un motor de búsqueda sobre objetos, este concepto debe tomarse con pinzas ya quehay una diferencia importante entre introducir un objeto y sus atributos en el índice vs. mapearlos atablas. Justamente, en un motor de búsqueda sobre objetos no necesitamos garantizar que el objeto esrepresentado �elmente por el índice, sino que sólo debemos garantizar que éste permitirá eventualmenteobtener su identidad.

Durante el mapeo de objetos en Compass, éste utiliza tres representaciones de los objetos: la entidadmisma, el Resource de Compass y el Document de Lucene. Esto también ocurre para los atributos de unaentidad, los cuales existen como objetos del dominio, objetos Property de Compass y Field de Lucene. Sibien Compass agrega dos representaciones adicionales de la entidad, a los ojos del usuario sólo se exponela entidad de dominio y los envoltorios de Compass (Resource y Property).

Por el lado de Hibernate Search, sólo existen las representaciones como entidad del dominio y sus con-trapartes de Lucene (Document y Field). Sin embargo, HS facilita el acceso a las estructuras de Lucene,dando acceso a un trabajo puramente orientado a documentos.

Estas representaciones intermedias entre el dominio y el índice sólo tienen sentido en el contexto deherramientas que necesitan interactuar con Lucene o indexar fuente como archivos XML o JSON (casosen los que no estamos interesados). En un motor de búsqueda sobre objetos no hay necesidad de que elusuario maneje una abstracción adicional a la entidad misma. Establezcamos esto en una proposición:

Proposición 6. El proceso de indexación y recuperación debe minimizar la presencia de representacionesno polimór�cas de los objetos de dominio.


Tanto HS como Compass dan soporte a procesos de indexación online, semi-online y o�ine (ver sección3.3.4).

En el caso de HS la indexación o�ine se implementa a través de colas de mensajes JMS, lo cual es unabuena alternativa pero requiere que el contexto de ejecución de la transacción de negocio utilice JMS.

Proposición 7. El proceso de indexación de objetos debe permitir elegir entre una indexación sincrónicacon la transacción de negocio y una indexación asincrónica. Esta elección es una solución de compromisoque deberá pesar las eventuales demoras en completar una transacción a causa de la indexación vs. elretardo de sincronización entre el índice y el RDBMS.


Excepto por optimizaciones puntuales como la implementación de subíndices o la reutilización de lec-tores, HS y Compass delegan la lectura del índice en Lucene. Las optimizaciones son agregados de cadaherramienta y sólo tienen sentido en un contexto de falta de abstracción en cuanto a índices de Lucene.Idealmente, cualquiera de estas optimizaciones deberían ser parte de cómo el motor de búsqueda resuelveel almacenamiento de sus índices y no un agregado para resolver de�ciencias de una librería subyacente.

A la hora de especi�car búsquedas, vimos las dos herramientas agregan a Lucene la mínima expresividadnecesaria para referenciar los atributos de los objetos. Las queries se especi�can en texto plano siguiendouna nomenclatura híbrida que permite tanto utilizar las operaciones extendidas de Lucene (wildcards,phrase queries, etc) como referenciar los atributos mapeados a campos de Lucene.

Existen casos en los cuales tanto el documento como la query son ricos en su estructura. Uno de estoscasos es la recuperación de XML (ver Manning et al., 2008). Para el caso de objetos, la presencia deestructuras y relaciones es aún mucho más evidente. Teniendo esto en cuenta, una característica que noestá presente en ninguna de las dos herramientas es la capacidad de especi�car información de relacionesentre objetos. Veamos un ejemplo de este caso:

Ejemplo 2.4.5 (Grafo de Objetos como Query). En este ejemplo especi�camos una query en base a ungrafo de personas relacionadas en una red social.

// u s u a r i o s de nu e s t r a red de con t a c t o sPerson aUser = new Person ( "Pablo M. López" ) ;Person ano the rUse r = new Person ( "Pablo S a l a d i l l o " ) ;Person aTh i rdUse r = new Person ( " José " ) ;

// Creamos e s t e g r a f o de r e l a c i o n e s :// ( Pablo M. López ) <−> ( Pablo S a l a d i l l o ) <−> ( Jose )aUser . addContact ( ano the rUse r ) ;ano the rUse r . addContact ( aTh i rdUse r ) ;

// sa lvamos l o s o b j e t o s en e l ORMs e s s i o n . save ( . . . ) ;

// en o t r a pa r t e creamos una query en forma de g r a f o para busca r p e r s ona s ad i s t a n c i a 2 de un " José "

Person query = new Person ( " j o s e " ) ;

// cramos un f i l t r o que s ó l o pe rm i t e r e t o r n a r o b j e t o s a exactamente 2g rados de d i s t a n c i a de l a query

F i l t e r f i l t e r = new Se condDeg r e eF i l t e r ( ) ;

// hacemos una búsqueda que d e b e r í a r e t o r n a r a "Pablo M. López" y NO a "Pablo S a l a d i l l o "

Co l l e c t i o n <Person> s e a r c hR e s u l t s = Search . f i n d ( query , f i l t e r ) ;

Como vimos al estudiar el modelo vectorial (subsección 2.1.4), éste nos permite recuperar documentossimilares entre sí. Esta característica es conocida como �More like this� (en adelante MLT). En Compassse provee un MLT a través de la implementación de Lucene, la cual naturalmente no conoce nada acercade objetos por lo que se limita a utilizar el modelo vectorial sobre la unión de todos los campos indexados.A diferencia de Compass, HS no dispone actualmente21 de un MLT.

Así como quisiéramos contar con la capacidad de efectuar búsquedas a partir de un objeto teniendo encuenta sus relaciones, también deberíamos tener una implementación del MLT que reciba un objeto yentregue los objetos similares. Consolidamos este análisis en la siguiente proposición:

Proposición 8. Un motor de búsqueda orientado a objetos debería permitir búsquedas a partir de objetos.En caso de implementar una funcionalidad del tipo MLT, la misma también debería aceptar objetos.

La implementación de MLT en Compass no puede cumplir con esta proposición porque está basada enuna extensión a Lucene, la cual sólo conoce acerca de documentos.

Como hemos comentado previamente, un aspecto que genera gran controversia entre los dos proyectos esla hidratación de los objetos recuperados. En Compass el proceso de hidratación se hace desde el índice,lo que requiere almacenar todos los datos necesarios en éste. Esta solución evita acceder a la base dedatos para obtener los resultados a cambio (a) un índice más grande, (b) asignar al motor de búsquedala responsabilidad de resolver la persistencia de los objetos y (c) exponerse al sincronization mismatch silas tablas se modi�can mediante SQL. Por el lado de Hibernate Search, la hidratación se hace desde elORM, con la penalidad teórica de requerir acceso al RDBMS para resolver las búsquedas.

21Al momento de escribir este trabajo, el MLT está en la lista de funcionalidades a implementar en la versión 3.2 de laherramienta.


Entre las dos posiciones, la hidratación desde el RDBMS es más sensata en cuanto que evita tanto el sin-cronization mismatch como la reimplementación de la persistencia en el motor de búsqueda. Además, talcomo dependen los autores de HS, la presencia de caches en el ORM puede evitar la necesidad de utilizarel RDBMS. Otro aspecto que se gana manteniendo la hidratación desde el ORM es la identidad (recordarque HS garantiza que el operador == retorna true cuando se compara un mismo objeto recuperado desdeel motor de búsqueda y el ORM). En base a esto enunciamos la siguiente proposición:

Proposición 9. Mientras sea posible, la hidratación de los objetos se debe delegar en el ORM para evitarel sincronization mismach, aprovechar sus caches y mantener la identidad de los objetos.

Cabe comentar que existen casos donde podemos almacenar datos en el índice para resolver problemaspuntuales como la previsualización del contexto donde hubo coincidencia con la query. Este tipo detécnicas no deben ser consideradas una hidratación ya que tienen un propósito muy especí�co que noincluye sustituir polimor�camente al objeto indexado.


En lo que respecta al modelo de IR y la valoración de los resultados, vimos que tanto HS como Compassutilizan las fórmulas estándar de Lucene. Al igual que cuando estamos utilizando Lucene, podemos variarla implementación de similitud. En HS es posible indicar la implementación mediante una anotación anivel de clase. Para el caso de Compass, la documentación establece la posibilidad de ajustar las clasesde similitud por separado para la indexación y la recuperación en forma global y no por tipo de instanciacomo en HS.

En ninguna de las dos herramientas se resuelve el problema de decidir qué tipo entidad es la que mejorresponde a una necesidad de información sino que se utilizan las fórmulas de similitud y eventualmentese �ltra por tipo de instancia.

Por otro lado, como vimos en la subsección (2.1.6), en ocasiones es necesario poder valorizar los resultadosno solo en base a la relevancia sino a reglas de negocio. Para implementar estas reglas en HS o Compass,debemos modi�car la fórmula de similitud o reordenar los resultados de búsqueda. En cualquier de losdos casos, necesitamos conocer ciertos detalles avanzados de Lucene, lo que nos induce a la siguienteproposición:

Proposición 10. El motor de búsqueda debe permitir incorporar reglas de puntajes y ordenamientos queexcedan la noción de similitud del modelo de IR, dando la �exibilidad de ajustar parámetros de negociopor con�guración.

Respecto de técnicas de valoración estructural global como HITS y PageRank, ninguna de las dos her-ramientas analiza cómo incorporarlas. Dado que estas herramientas son principalmente envoltorios deLucene y éste no implementa técnicas como HITS y PageRank, éstas exceden el alcance de HS y Com-pass. Una posible implementación bajo HS o Compass seguramente requeriría de un cálculo externo a laherramienta y la consecuente aplicación de impulsos a entidades particulares. Es probable ver la solucióna este tipo de problemas desde Lucene más que desde HS y Compass, los cuales no dedican sus principalesesfuerzos a adaptar la similitud provista por Lucene a la recuperación de objetos.

Analizando la documentación de las herramientas podemos observar que la relevancia no toma un papelcentral en ninguna de ellas, quizás asumiendo que Lucene es el encargado de resolver estos problemas. Encaso de que tal suposición exista, entendemos que es errónea ya que Lucene no cuenta con nociones derecuperación de objetos, por lo que difícilmente ayude a resolver los problemas que excedan la abstracciónde documentos.

Capítulo 3

Desarrollo de la Propuesta de Solución

El objetivo de este capítulo es exponer el diseño de nuestra solución al problema de IR sobre modelos dedominio, basándonos en el análisis del estado del arte y en las diferentes soluciones posibles al problema.

La sección 3.1 analiza el problema que queremos resolver planteando las distintas variantes de solución,teniendo en cuenta lo que hemos estudiado en el capítulo anterior acerca del estado del arte. Como esesperable de una etapa de análisis, el objetivo de esta sección es comprender qué queremos construir.

En la sección 3.2 explicamos la estrategia por la cual el framework de IR puede conocer el modelo dedominio, de forma de poder indexarlo y recuperar información sobre éste. Esta sección funciona tambiéncomo transición del análisis al diseño.

En la sección 3.3 describimos el diseño interno del framework, explicando su arquitectura y la integracióncon los distintos ORM y motores de acceso a índices invertidos. Al �nalizar esta sección, quedará explicitocómo construimos este framework.

3.1. Análisis General del Problema

Luego de haber analizado el estado del arte, estamos en mejor posición de rea�rmar que la recuperaciónde información no es una tarea trivial y que no puede ser resuelta íntegramente a base de consultas a unabase de datos, por lo que necesitamos un software especí�co que se ocupe de esto. Esto es, un frameworkreusable.

También vimos que las librerías de IR como Lucene efectúan un muy buen trabajo pero que no sonadecuadas para trabajar transparentemente sobre modelos de objetos.

Por último, sabemos que existen muy buenas herramientas como Compass y Hibernate Search, las cualesllevan años de maduración pero, al estar montados sobre Lucene, exponen el hecho de que no son unframework único e independiente sino que son capa adaptadora de Lucene. Esta adaptación tampoco estransparente, ya que vemos expuestos conceptos propios de Lucene y no de un framework de indexación deobjetos. Aún aceptando su modelo mixto, al contrastar las herramientas (subsección 2.4.4) encontramosque proponen diferentes soluciones a cada problema, lo que nos llevó a enunciar una serie de proposicionesacerca de cómo debería resolverse el problema de IR sobre objetos.

En las siguientes subsecciones vamos a analizar distintos aspectos del problema y escoger la mejor soluciónpara nuestro framework.

3.1.1. Modelos de IR

En la subsección (2.1.4) estudiamos tres modelos clásicos de IR: booleano, vectorial y probabilístico.Como vimos, los distintos modelos de IR son determinantes en cuanto a qué resultados entrega el motorde búsqueda y cómo los prioriza de cara al usuario.

Vimos que el modelo booleano es muy simple pero todavía sigue siendo aceptado en sistemas dondeel usuario es un experto creador de consultas. Por otro lado, sabemos que el modelo vectorial y elprobabilístico parten de orígenes distintos pero llegan a fórmulas de relevancia similares.

85

86 CAPÍTULO 3. DESARROLLO DE LA PROPUESTA DE SOLUCIÓN

Lucene implementa un híbrido entre el modelo booleano y el vectorial (ver subsección 2.4.1), teniendo encuenta una noción de zonas y campos (ver subsección 2.1.6).

Para nuestro framework de IR tomamos las siguientes decisiones:

Proposición 11 (Modelo de IR). En esta versión del framework implementaremos tanto el modelobooleano como el modelo vectorial.

La decisión de implementar el modelo booleano se basa en que (a) su simplicidad nos permite diseñar elframework comenzando por un problema �más simple� que si tuviéramos que comenzar por otro modeloy (b) a pesar de su simpleza es muy utilizado, aún en escenarios reales.

A su vez, la decisión de implementar el modelo vectorial se basa en que (a) la literatura lo respalda comoun avance sobre el modelo booleano y (b) tanto los frameworks que estudiamos en la sección (2.4) comoel resto de la industria lo han adoptado logrando muy buenos resultados.

Dentro de la elección del modelo vectorial, decidimos comenzar con la versión más simple de las fórmulasTF-IDF e ir complejizándolas a medida que sea necesario.

Es preciso tener en cuenta que respecto del modelo booleano, la implementación del modelo vectorialsupone un esfuerzo extra ya que nos obliga a almacenar y mantener los valores TF-IDF para cadatérmino y posting.

Si bien decidimos comenzar con una implementación de los modelos booleanos y vectorial, bien podríamosquerer incorporar el modelo probabilístico. En consecuencia, una de las ventajas que queremos incorporaren nuestro framework es la facilidad de variar entre modelos de IR con un mínimo impacto en la aplicaciónhuésped (en lo posible, quisiéramos variar el modelo por con�guración). Esto es especialmente importanteporque nos permite escoger el modelo más apto para nuestra aplicación en base a los resultados queproduce cada uno.

Esto último nos induce a la siguiente proposición:

Proposición 12. Permitiremos variar el modelo sin afectar al usuario del framework.

En la próxima subsección continuamos el análisis abordando las técnicas de acceso a datos y la inteligenciapara lograr coincidencia entre términos.


Registro Maestro e Índices Invertidos

Como sabemos de la subsección (2.1.5) y de los casos de estudio de la sección (2.4), tanto la literaturacomo los frameworks actuales señalan que los índices invertidos son la mejor solución disponible para latarea de recuperación de información en base a términos.

Una característica innovadora que queremos incorporar en el framework es un registro maestro de objetosindexados.

El objetivo de este registro es:

evitar reprocesar el texto del objeto para conocer sus postings al momento de actualizar/eliminarobjetos,

no requerir acceso al objeto persistido para que el proceso de reindexación pueda saber qué objetosestán indexados,

conocer en todo momento qué objetos deberían estar en el índice y bajo qué términos a los �nesde resolver eventuales inconsistencias. Esto es, evitar postings �fantasma� que existen en el índicepero no en la base de datos (este problema ocurre si se actualiza el objeto persistido mediante unaconsulta SQL).

3.1. ANÁLISIS GENERAL DEL PROBLEMA 87

Respecto de implementar sólo un índice invertido, incorporar un registro maestro trae aparejado unincremento del espacio necesario en disco o memoria para alojar este registro así como un incrementoen la complejidad de la solución. Haciendo un balance de lo anterior, decidimos que es bene�cioso hacerel esfuerzo de incorporar este índice ya que brinda un grado de robustez necesario para aplicaciones delmundo real.

Además de este registro maestro vamos a construir un índice invertido tradicional, el cual debe estarsincronizado con el anterior.

La pareja registro maestro-índice invertido debe presentar una interfaz que soporte las siguientes opera-ciones:

Operaciones sincronizadas entre Índice Invertido y Registro Maestro:

• creación de nuevos Postings

• eliminación de Postings

Operaciones del Índice Invertido:

• leer una Posting List

• obtener el valor de DF por término (para soportar el cálculo TF-IDF)

• obtener el tamaño del diccionario de términos (para soportar el cálculo TF-IDF)

Operaciones del Registro Maestro

• obtener iterador sobre la lista de objetos indexados

• obtener el número total de objetos indexados (para soportar el cálculo TF-IDF)

Especi�cando este conjunto de operaciones en una interfaz, podemos componentizar el par registro-índiceen una capa de acceso a datos intercambiable, permitiendo variar la implementación por con�guración.

La mayoría de las operaciones anteriores son necesarias para intersectar posting lists (ver subsección2.1.5) y luego indicarle al usuario o al ORM qué objeto es necesario hidratar.

Respecto de esto surgen dos preguntas:

¾La hidratación debe ser responsabilidad del framework?

¾Cuál es la forma correcta referenciar el objeto indexado de forma de poder hidratarlo?

La primera pregunta la vamos a responder parcialmente en la siguiente proposición para luego completarlaal presentar los plugins de Hibernate e iBATIS (ver subsecciónes 3.3.4 y 3.3.4).

Proposición 13. La hidratación no es responsabilidad del framework de búsqueda sino que es respons-abilidad del framework de persistencia. Por lo tanto, nuestro framework sólo mantendrá la informaciónnecesaria para que el framework de persistencia pueda hidratar los objetos luego de ser recuperados.

Esta proposición nos da el pié para responder a la segunda de las preguntas que nos hicimos:

Proposición 14. Tanto el índice invertido como el registro maestro de objetos mantendrán referenciade los objetos indexados mediante la combinación de:

una versión serializada del identi�cador del objeto a indexar y

el nombre completo de la clase a la que pertenece dicho objeto.

A esta combinación la llamaremos �clave del objeto�.

Esta proposición se justi�ca por las siguientes razones:

la hidratación en los ORM siempre requiere el identi�cador del objeto y, de una u otra forma, laclase del objeto a recuperar.


dado que tanto el identi�cador original del objeto como el nombre de su clase son serializables, laclave del objeto es serializable, lo que permite almacenar el índice en un medio persistente.

es independiente del espacio de memoria donde se ejecuta el motor de búsqueda, esto es, los objetosindexados en una máquina virtual pueden recuperarse en otra.

si el identi�cador del objeto implementa el método equals, permite aplicar álgebra de Boole sobrelas postings lists (necesario para los modelos de IR que queremos soportar).

En la próxima subsección veremos cómo construir físicamente el índice y el registro para soportar estasoperaciones.

Construcción del Índice

Dado que vamos a soportar el modelo booleano y el vectorial, necesitamos que los índices invertidossoporten las operaciones básicas de cada modelo:

Modelo Booleano

• obtención de postings lists a partir de un término

• operaciones AND, OR y NOT sobre los postings

Modelo Vectorial con TF-IDF (ver subsección 2.1.4)

• obtención de postings lists a partir de un término

• operación OR sobre postings

• obtención del tamaño del diccionario de términos

• obtención de la cantidad de objetos asociados a un término

Para soportar el modelo booleano nos alcanza con un generar un índice invertido simple, capaz de asociartérminos y claves de objetos. Este índice se visualiza en la �gura (3.1).

(A;1)

(A;1)

(B;1)

(B;1)

(A;2)

Figura 3.1: Índice Invertido para recuperación booleana. En este ejemplo �A� y �B� son nombres de clasesy los números son el identi�cador serializado del objeto.

El modelo vectorial requiere llevar cuenta de la cantidad de objetos indexados, la cantidad de términosen el diccionario y la cantidad de veces que aparece un término en un objeto. El primer valor se puedeconseguir en el registro maestro de objetos indexados, mientras que el segundo y el tercero se suelenubicar en el índice invertido según se muestra en la �gura (3.2).

(A;1) tf=1

(B;1) tf=1

(B;1) tf=2

1

2

2

tamaño = 3

(A;1) tf=1

(A;2) tf=3

con TF por posting

Figura 3.2: Índice Invertido para recuperación vectorial. Respecto del caso booleano, agregamos el tamañodel diccionario, el número de postings por término y la cantidad de apariciones del término en el objeto.


Si bien este último modelo de índice es su�ciente a los efectos de la recuperación pura, al explicarordenamiento y �ltrado veremos que normalmente necesitamos conocer qué atributo del objeto es el queprodujo determinado posting así como será necesario almacenar valores en el índice.

Como vimos en la subsección (2.1.6), en ocasiones tenemos la necesidad de �ltrar los resultados y/opriorizarlos por un criterio de negocio. Para poder hacer esto dentro de los pocos milisegundos que seespera que tome una consulta, es necesario almacenar el valor de dichos atributos fuera del ORM.

Este último requerimiento nos obliga a retroceder en cuanto a sólo mantener una referencia al objetoindexado y no superponer nuestras responsabilidades con el ORM. Sin embargo, a falta de una mejoralternativa debemos aceptar el requerimiento como tal e implementarlo de la mejor forma posible (espreciso notar que los frameworks que estudiamos en la sección 2.4 resuelven este problema de la mismaforma).

Entonces tenemos que agregar al índice de la �gura (3.2) la capacidad de:

indicar TF para cada atributo que contenga el término de la posting list

almacenar los campos que intervengan en �ltrado y ordenamiento

Estos cambios se ven aplicados en la �gura (3.3):

A ; 11

2

2

tamaño = 3 con TF y Stored Fields por posting

fieldX.tf=1

fieldY.value=5

B ; 1 fieldA.tf=2 A ; 1fieldX.tf=1

fieldY.value=5

B ; 1 fieldA.tf=2 A ; 2fieldX.tf=3

fieldY.value=3

Figura 3.3: Índice Invertido con almacenamiento y TF diferenciado por atributo. Este índice soporta tantoel modelo booleano como el vectorial, así como los conceptos de zonas y campos y ordenamiento/�ltradopor reglas de negocio.

Si bien es verdad que el almacenamiento de campos superpone roles del ORM con los del frameworkde IR, si somos conservadores acerca de almacenar únicamente atributos inmutables, evitamos la desin-cronización con la base de datos, lo cual reduce el desajuste de sincronización (ver subsección 2.4.1).

Por el lado de las optimizaciones, este último índice invertido puede utilizar todas las técnicas disponiblesen la literatura como front coding, skip pointers y merge generacional ( ver Manning et al., 2008).

Además de las optimizaciones clásicas que podemos encontrar en la literatura, podríamos enviar los atrib-utos almacenados al registro maestro y así tener una única versión de dichos valores, lo cual ahorra espacioen el índice invertido y reduce la probabilidad de anomalías de actualización. Esta última optimizaciónpuede ser contraproducente en las búsquedas, ya que no podemos resolver la búsqueda con un únicoacceso al índice invertido.

Para esta versión del framework decidimos utilizar la opción más simple de alojar los atributos almace-nados en los postings. Si en el futuro esto probara ser una oportunidad de mejora, gracias a la compo-nentización de los índices, podríamos pasar estos valores al registro maestro sin mayor impacto.

Procesamiento de Textos

El procesamiento de textos comprende toda la inteligencia para lograr coincidencia entre la consulta delusuario (query) y los textos presentes en los objetos. Los procesadores de textos deben ser simétricos encuanto a la indexación y la recuperación. Es decir, necesitamos que al indexar un objeto se produzcanlos mismos términos que se producirán al analizar la query del usuario.

Tanto la indexación como la interpretación de la query requieren dos pasos: normalización del texto ydelimitación en términos.


Las normalización del texto consiste en conversión a mayúsculas/minúsculas, quitar símbolos, aplicarstemming ó lematización, corregir ortografía, quitar espacios redundantes, etc.

La estrategia que elegimos para delimitar términos es separar mediante espacios en blanco, comas, puntosy demás símbolos ortográ�cos. Esta estrategia es muy efectiva en lenguajes como el español, pero puedeser inefectiva en otros como el alemán o el chino. También pueden existir problemas en dominios dondealgunas palabras pierdan signi�cado al ser tratadas por separado. Por ejemplo, la query X-MEN tendríamenor efectividad separando los términos por el guión ya que el primer termino (X) se tomaría como unstopword y el término restante (MEN) tendría alto recall y baja precisión. Por este tipo de problemaslocales a cada lenguaje y dominio, incluimos la posibilidad de variar el comportamiento de los procesadoresde texto en forma dinámica según el lenguaje y modi�car la implementación para soportar excepcionesespecí�cas del dominio.

En la �gura (3.4) presentamos un ejemplo simple de normalización y delimitación:

Figura 3.4: El primer paso de normalización convierte las mayúsculas a minúsculas y los caracteresacentuados a su versión sin tildes. Luego se convierten signos ortográ�cos a espacios en blanco, eliminandolos espacios redundantes. Por último, se delimita el texto en base a los espacios blancos, en este caso seobtiene el conjunto {brutus, conspiro, contra, caesar, su,padre}.

Nuestro framework proveerá un procesador de textos por defecto que aplica eliminación de stop words,normalización de textos y stemming. El procesador es un componente especialmente sensible al lenguaje,por lo que nuestra implementación debe ser variable según el lenguaje del texto.

Adicionalmente a la normalización y la delimitación, la interpretación de la query del usuario requiere laconstrucción de un árbol de consulta, el cual explicaremos en el próximo apartado.

Consultas Booleanas y Vectoriales

En el apartado previo vimos que la resolución de consultas y la indexación requieren de normalización ydelimitación de términos. Estas dos operaciones son agnósticas respecto del modelo de IR utilizado.

Por otro lado, el procesamiento de consultas sí depende del modelo de IR, ya que en un modelo comoel booleano debemos poder utilizar conectores lógicos AND, OR y NOT1. Esta característica constituyediferencia la indexación de texto de la interpretación de consultas, la cual requiere la construcción de unárbol de consulta.

El árbol de consulta determina el orden jerárquico de recuperación de los términos en el índice así comolas operaciones booleanas a aplicar entre posting lists. A continuación vemos un ejemplo:

Ejemplo 3.1.1 (Árbol de Consulta). Veamos el árbol de consulta para una query en el modelo booleano:

1Si bien adoptamos la convención de uso del término NOT, el término debería ser MINUS ya que estamos substrayendoelementos entre conjuntos (operación binaria) y no complementándolos (operación unaria).


coca cola light +OR pepsi diet +NOT zero

coca cola light pepsi diet

zero

AND AND

OR

NOT

En este ejemplo los rectángulos simbolizan las posting lists resultantes de cada operación y los operadoreslógicos se simbolizan con un + por delante del conector.

En primer lugar tenemos una intersección entre los postings de las palabras coca cola light y en segundolugar entre las de pepsi diet. Luego de estas dos intersecciones, se efectúa una unión entre los resultadosde cada sub rama del árbol y por último se eliminan todos los elementos presentes en la posting lists dezero.

En el ejemplo anterior se evidenció que existen algunos estándares �de facto� respecto de cómo interpretarlógicamente una consulta:

la consulta se interpreta según el sentido de lectura del idioma del usuario. Esto es, de izquierda aderecha para inglés o español y de derecha a izquierda para hebreo o árabe,

en el modelo booleano, ante la ausencia de un conector lógico entre términos se asume un ANDbooleano,

en el modelo vectorial los términos están conectados implícitamente por un OR booleano.

Además de los estándares de cada modelo, el árbol de consulta varía al momento de su ejecución en dosaspectos:

el tipo de resultados que entrega cada modelo puede diferir ya que el modelo booleano sólo retornaclaves de objeto, mientras que el vectorial además retorna un valor de similitud para cada resultado,

en el caso vectorial necesitamos calcular valores de TF-IDF sobre los objetos recuperados.

Resumiendo lo que vimos en este apartado:

el motor de búsqueda interpreta las consultas según convenciones adecuadas de cada modelo de IR,

la interpretación produce como resultado un árbol de consulta.

En el próximo apartado utilizaremos estos conceptos para generar un método de consulta a partir deobjetos.


Consultas de Objetos

Una característica original incluida en nuestro framework es la posibilidad de especi�car consultas a partirde objetos.

Al contar con un objeto como elemento de consulta, podemos aprovechar la inteligencia de mapeos (versección 3.2) para generar una consulta simétrica al objeto indexado. Esta característica propone salir deun esquema clásico en el cual la consulta es una frase para pasar a un esquema donde la query y el corpusson de un mismo tipo (objetos). Veamos esto aplicado a un ejemplo:

Ejemplo 3.1.2. Supongamos un sitio web en el cual queremos crear un buscador de opiniones acerca deautos.

El siguiente fragmento de código muestra una clase que representa una opinión particular sobre un au-tomóvil:

pub l i c c l a s s CarOpin ion {// e s t o s a t r i b u t o s se no rma l i z an pero no se l e s a p l i c a n stemming n i

e l i m i n a c i ó n de s top wordsS t r i n g brand , model ;

// sob r e e s t o s a t r i b u t o s ap l i c amos no rma l i z a c i ón , e l i m i n a c i ó n de s topwords y stemming según e l l e n g u a j e de l a a p l i c a c i ó n

S t r i n g s ub j e c t , o p i n i o n ;

// se almacena para p e rm i t i r f i l t r a r l o s r e s u l t a d o si n t s t a r s ;

// i d e n t i f i c a d o r d e l o b j e t olong o p i n i o n I d ;

}

Entonces el usuario ingresa algunos valores a partir de los cuales quiere buscar opiniones:

fiatMarca

BuscarÓpticas Delanteras

Quiero refinar mi búsqueda:

bravaModelo

Tema

Car Reviews

Sólo opiniones con calificación mínima:

En base a estos valores, podemos generar un objeto de tipo CarOpinion y proveerlo al motor de búsquedapara que retorne opiniones como las que buscamos.

Veamos que si utilizamos el mismo tipo de objetos en la búsqueda e indexación, el motor de búsqueda puedeaplicar selectivamente el procesamiento de textos y normalizar Ópticas Delanteras en óptica delantera sólopara un atributo, evitando el stemming del atributo model, el cual resultaría en un overstemming entrelos modelos brava y bravo (modelos existentes de la marca Fiat), empeorando la precisión de la respuesta.

La capacidad de proveer objetos como consulta nos abre las puertas a una implementación sencilla dela función �More Like This� que discutimos en la subsección (2.4.4). Para implementar el MLT, sólo


necesitamos proveer el objeto resultante de una búsqueda, y el motor de búsqueda buscará los objetos demayor similitud en términos de IR.

La recuperación a partir de objetos no es un modelo completo en sí mismo sino que se monta sobre elmodelo vectorial. Esto es, la similitud entre objetos se realiza en base a fórmulas TF-IDF.

3.1.3. Procesos de Indexación

Las tareas de recuperación que estamos describiendo requieren la capacidad de indexar objetos en elíndice invertido. En los apartados previos discutimos la estategia para llevar adelante esta indexación,siendo que nos resta analizar la dinámica con la cual esto se llevará a cabo.

En esta subsección veremos tres dimensiones en las que una aplicación puede variar sus procesos deindexación, explicando cómo vamos a dar soporte desde el framework a cada caso de uso.

Tipos de Indexación

En cuanto al �ujo de objetos hacia el indexador, podemos trabajar en dos formas distintas:

Indexación Automática o por Eventos: consiste en utilizar un plugin del framework de IR (verúltimo apartado) que interconecta los eventos CUD del ORM con el proceso indexador. Este tipo deindexación es la recomendada ya que transparenta el uso del framework y nos garantiza consistenciaentre el almacén de datos y los índices.

Indexación Proactiva: esta es una opción de más bajo nivel en la cual el usuario se ocupa de inyectarlos objetos al indexador para que este aplique los cambios sobre los índices. Esta variante es másversátil que la anterior ya que ya que puede utilizarse en ausencia de un ORM y puede combinarsecon la indexación automática a efectos de �reindexar� manualmente un conjunto de objetos.

Nuestro framework permite tanto la indexación por eventos como la proactiva. Para el caso de la in-dexación automática, proveemos plugins que re�ejan los eventos de los ORM Hibernate e iBATIS. En elúltimo apartado retomaremos la explicación acerca de la funcionalidad de plugins.

La segunda dimensión en la que podemos variar nuestro proceso indexador tiene que ver con el grado desincronismo de la indexación:

Indexación Online: se ejecuta sincronicamente con la transacción de negocio, no deja que éstaconcluya hasta haber terminado la indexación del grupo de objetos implicados en la transacción.

Indexación Semi-Online: ocurre en la misma máquina virtual que desarrolla las transacciones denegocio, pero en forma asincrónica a ésta. A su vez puede ser mono o multi hilo.

Indexación O�ine: el proceso indexador se ejecuta en forma asincronica en una máquina virtualdistinta a la transacción de negocio.

En los próximos apartados damos algunos detalles más de estos tres modos de indexación.

La tercera y última dimensión involucra la distribución del indexador:

Indexación Centralizada: la indexación se efectúa en un único nodo.

Indexación Distribuida: la indexación se efectúa en distintos nodos al mismo tiempo.

En los siguientes apartados tratamos cada tipo de indexación desde el punto de vista del sincronismo yexplicamos cómo se ven afectadas por el resto de las dimensiones.


Indexación Online

En esta modalidad el framework de IR aplica el procesamiento de objetos y los cambios sobre índicesdesde el mismo hilo que invoca la indexación, ya sea por eventos o proactivo (ver �gura 3.5).

: objetos a indexar

Figura 3.5: Indexación Online. La aplicación efectúa operaciones transaccionales que se ejecutan sincróni-camente con la indexación de objetos.

Es preciso notar que la indexación online no excluye la posibilidad de que varios hilos indexen un mismoobjeto concurrentemente, por lo que debemos resguardar el índice de operaciones inconsistentes. En unapartado posterior profundizaremos acerca de la concurrencia y distribución.

La indexación online es la modalidad más simple, sobre todo cuando la indexación es centralizada. Estamodalidad está dirigida a aplicaciones que pueden esperar a que se indexe un objeto antes de completarla transacción de negocio.

Indexación Semi-Online

En este caso el framework encola las operaciones de indexación y las asigna a hilos �trabajadores� o�workers�. Estos workers se comportan como indexadores online paralelos que se ejecutan fuera del entornode la transacción de negocio (ver �gura 3.6).


: objetos a indexar : cola de mensajes

Figura 3.6: Indexación Semi-Online. Los hilos de ejecución de la aplicación y el ORM están desacopladosde

En un escenario de tolerancia a fallas, este método de indexación se complejiza porque el sistema puedefallar luego de que la transacción de negocio ha sido con�rmada pero antes que el indexador complete sutrabajo. Para resolver este problema, el indexador debería mantener un log de transacciones similar al deun RDBMS, de forma tal de poder recuperarse ante un fallo inesperado.

Indexación O�ine

La indexación o�ine consiste en encolar mensajes de indexación persistentes en una máquina virtualy aplicarlos a los índices en forma asincrónica en otra máquina virtual. El o los procesos indexadoresdeberán desencolar los mensajes, procesar los objetos y aplicar los cambios en los índices. Este esquemase presenta en la �gura (3.7):


: objetos a indexar : cola de mensajes

Figura 3.7: Indexación O�ine. La máquina virtual en la que ejecuta la aplicación persiste los datos en sualmacén de datos y encola mensajes de indexación. En forma asincrónica, la máquina virtual indexadoradesencola los mensajes, procesa los objetos y aplica los cambios sobre el índice.

Esta indexación o�ine requiere la utilización de un sistema de mensajería, el cual debe ser asincrónicoy puede o no ser persistente. Es importante que el sistema de mensajería preserve el orden en el que seproducen los eventos de indexación, de otro modo nos arriesgamos a que una ejecución fuera de ordenproduzca inconsistencias en los índices. Por otro lado, los mensajes de indexación se pueden generar tantopor eventos como en forma proactiva.

Los problemas como el ruteo, concurrencia y orden de mensajes son especialmente complejos en unentorno distribuido, por lo delegaremos la implementación a un framework o librería que implemente elestándar de mensajería JMS de Java. La indexación o�ine distribuida se trata en el siguiente apartado.

Indexadores Concurrentes y Distribuidos

Tanto las indexaciones concurrente como distribuida presentan algunas sutilezas que debemos mencionar.

La indexación concurrente y la distribuida pueden generar la ejecución de los eventos de indexación enun orden distinto al que se da en el ORM. Por ejemplo, si las operaciones de indexación y desindexaciónde un objeto invierten su orden, al �nalizar la ejecución los datos no habrán sido eliminados del índice.

En este escenario, podemos decir que el framework de IR es responsable de aplicar los cambios en elmismo orden que le son indicados, asumiendo que el ORM o la aplicación proveen este orden en forma


correcta.

La combinación de un indexador concurrente y uno distribuido nos dan cuatro escenarios donde indexarobjetos:

Indexador Concurrente Indexador Distribuido Problemas de Aislamiento Problemas de Orden

no no no nono si no sisi no si sisi si si si

Los problemas de aislamiento ocurren cuando un objeto se indexa en simultaneo desde más de un hilo,de forma tal que los cambios producidos por uno de ellos se hace visible al otro antes que el primerocomplete su ejecución. Esto da lugar a problemas clásicos de los RDBMS como las lecturas fantasma(este es el caso en el que un hilo ve como válido un dato temporal que sólo existió durante el transcursode otra transacción).

La resolución de los problemas de aislamiento los delegamos en la capa de acceso a datos. Es decir, esresponsabilidad de quien provee el sistema de almacenamiento de índices que una escritura no se hagavisible hasta tanto se con�rme la operación.

Los problemas de orden se dan cuando la aplicación ejecuta las transacciones T1 y T2 en orden T1→T2pero nuestro framework aplica los cambios en el orden T2 → T1. En el caso centralizado, esto ocurrecuando el hilo H1 se demora procesando los objetos de la transacción T1, de forma tal que el hilo H2

procesa e indexa los objetos de la transacción T2 antes que H1 termine. En el caso distribuido, ademáspuede ocurrir que nuestro framework demore el encolado en un nodo, de forma que el indexador recibelas operaciones en un orden distinto al especi�cado por el ORM.

Este último problema es especialmente complejo, pero tiene algunas soluciones posibles:

la solución más simple es asegurar aplicativamente que un mismo objeto no es operado desde nodosdistintos, o en términos más generales, que las operaciones de indexación son conmutativas entrenodos (no así dentro de un mismo nodo, donde debemos dar garantías FIFO). Si podemos generareste escenario, se eliminan los problemas de ordenamiento.

para el caso centralizado-concurrente, podemos establecer una cola FIFO que nos asegure un des-encolado en el orden especi�cado por el ORM, mas un sistema de bloqueos que prevenga a un hilode indexar objetos en con�icto con otro. Por ejemplo, si el hilo H1 bloquea los objetos antes decomenzar, cuando H2 intenta operar sobre un objeto compartido con H1 deberá esperar a que éste�nalice su trabajo, evitando la ejecución fuera de orden.

para los casos distribuidos, debemos implementar algoritmos distribuidos que nos permitan simular(a) la cola FIFO del caso anterior y (b) el bloqueo de objetos.

Los detalles de implementación de este escenario son problemas complejos típicos de sistemas dis-tribuidos, por lo que exceden el análisis que queremos dar al caso. Sin embargo, es preciso notar quepodemos evitar algunos problemas si contamos con una herramienta centralizada como un RDBMS,el cual nos puede facilitar la generación de números secuenciales y el bloqueo de objetos mediantetablas de bloqueos.

En aplicaciones en las cuales los objetos son relativamente simples, podemos paralelizar la indexaciónsimplemente partiendo el espacio de claves del objeto en particiones disjuntas e indexando cada lote porseparado. En estos casos, los dos problemas anteriores desaparecen.

En general los escenarios donde tenemos que indexar objetos suelen ser más benignos y no es necesarioconsiderar la indexación de objetos cruzados entre nodos o al menos no al mismo tiempo.

Reindexación

Si los objetos de la aplicación se actualizan por un circuito externo al aplicativo (por ejemplo, medianteconsultas SQL), el índice tenderá a divergir respecto del contenido real de los objetos.

Este problema se puede resolver utilizando un proceso reindexador.


Para reindexar un objeto es necesario (a) eliminar los postings del objeto previo y (b) indexar los nuevospostings.

Para eliminar los postings del objeto anterior entra en juego el registro maestro de objetos, el cual conocequé términos generó el objeto originalmente indexado. Utilizando el registro maestro podemos ubicar lostérminos �viejos� y eliminarlos.

Por otro lado, el reindexador necesita saber qué objetos hay que reindexar, lo cual debe quedar a cargode la aplicación o quien parametrice dicho proceso.

En el capítulo 4 veremos que no es necesario proveer un reindexador genérico ya que el código ligado almotor de búsqueda es trivial.

Plugins

Como explicamos al principio de esta subsección, tenemos la intención de componentizar algunas partesdel framework, de forma de poder cambiar su implementación por con�guración sin impacto en el códigode la aplicación huésped. Estos componentes serán llamados plugins.

En cuanto al acceso a datos y la indexación, tenemos tres tipos de plugins:

Plugins de Indexación por Eventos desde ORM: se conecta con el mecanismo de eventos del ORMy adapta su interfaz para re�ejar los eventos CUD en los índices.

Plugins de Backend de Acceso a Índices: implementan el acceso físico a los índices invertidos y alregistro maestro.

Plugins de Indexación O�ine: conecta el framework de IR con el proveedor del servicio de colas demensajes.

Los plugins se pueden con�gurar y asocian a las clases que los requieren por medio de inyección dedependencias. En el capítulo 4 retomaremos este tema mostrando cómo inyectamos los plugins en unaaplicación editando archivos de con�guración.


Hasta aquí hemos analizado qué modelos de IR se adecúan al problema que estamos resolviendo, quéíndices debemos construir y qué procesamiento debemos efectuar sobre los textos. Dado que hemossentado las bases para indexar y recuperar objetos, en esta subsección vamos a explicar cómo priorizar y�ltrar estos objetos recuperados por una query.

Las técnicas de puntajes las abordaremos desde el punto de vista de la similitud de cada modelo de IR ydesde el ordenamiento por reglas de negocio, dependientes de cada aplicación.

Además de priorizar los resultados, también necesitaremos aplicarles clasi�cación y �ltrado.

La clasi�cación consiste en un proceso opcional de separación de los resultados en clases, lo cual abre laspuertas a la búsqueda facetada (ver subsección 2.1.5).

El �ltrado se utiliza para eliminar de la respuesta los resultados que no cumplen con una condición dadaal momento de la búsqueda. Esta funcionalidad se puede utilizar para tareas de seguridad (�ltrar objetosa los que una persona no tiene acceso), para implementar reglas de negocio (por ejemplo eliminando dela respuesta objetos de cierta antigüedad) o para implementar la búsqueda facetada.

Notemos que tanto la clasi�cación como el �ltrado responden a necesidades particulares de negocio. Esdecir, en general no son herramientas portables entre dominios como sí lo pueden ser los modelos de IR.

En los próximos apartados analizamos cómo vamos a incorporar las nociones de similitud, clasi�cación y�ltrado.


Similitud Para soportar el modelo vectorial vamos a implementar una fórmula de similitud del tipoTF-IDF. Las fórmulas TF-IDF que aplicaremos tendrán la forma general:

Similitud (q, o) =∑∀t∈q

idft ×

(∑∀a∈o

tft,a

)(3.1.1)

donde:

q es una query compuesta de términos t

o es el objeto que está siendo evaluado y a son sus atributos

Si bien esta fórmula es relativamente simple, es buen punto para comenzar y luego ajustarla o reemplazarlasegún el problema que estemos resolviendo.

Es preciso notar que esta sencilla fórmula requiere bastante información:

idft: necesita el número de postings para t y la cantidad total de objetos indexados

tft,a: requiere saber cuántas ocurrencias se dieron para cada término en cada atributo

Notemos que la ecuación de similitud di�ere de la fórmula de Lucene (ecuación 2.4.1) principalmente enfactores de normalización y en el valor de impulso que Lucene aplica a cada campo.

Nuestra propuesta de implementar esta fórmula simple se debe a que queremos evitar una sobre ingenieríaen la fórmula de similitud desde el comienzo para todos los dominios. Dado que la similitud tiene menorprelación que los ordenamientos por reglas duras y blandas, una sobre ingeniería puede perjudicar elrendimiento y quedaría oculta detrás de reglas de negocio de mayor prioridad. Sin embargo, vamos aaseguremos que el diseño del framework permita extender esta fórmula para el caso en el que muestre serinefectiva.

En el capítulo 4 ejempli�caremos el uso de esta fórmula sobre tres dominios distintos, donde analizaremosen detalle su desempeño.

Ordenamiento y Reglas de Negocio Como vimos en la subsección (2.1.6), el éxito de un sistemade IR excede a la relevancia provista por el modelo de IR.

Mientras el modelo de IR se ocupa de dar una solución global al problema de la relevancia, nosotrosdebemos permitir implementar una solución local a cada aplicación mediante reglas duras y blandas (versubsección 2.1.6).

Nuestro framework soporta la inclusión de ordenamiento por reglas de negocio previo al retorno de losobjetos recuperados.

El hecho de permitir un ordenamiento previo a la entrega de los resultados paginados es distintivo delframework y es importante ya que nos permite aplicar ordenamiento antes de hidratar los objetos (lo cualpuede ser prohibitivo si una búsqueda retorna cientos de miles de objetos).

Filtrado El �ltrado se utiliza cuando queremos implementar algún tipo de búsqueda facetada o sim-plemente eliminar objetos que no cumplan con ciertas condiciones (de seguridad, de antigüedad, etc.)

El framework provee una implementación de algunos �ltros básicos como el �ltrado por tipo de objeto(clase) y antigüedad de un atributo. Mas allá de estos casos puntuales, la actividad de �ltrado respondesiempre a un requerimiento de negocio, por lo que es responsabilidad del usuario del framework proveerlos �ltros.

La etapa de �ltrado recorre todos los objetos retornados desde los índices, permitiendo la clasi�caciónde los resultados. Esta clasi�cación bien puede contar los objetos que cumplen con ciertos criterios y asíimplementar búsquedas facetadas (ver subsección 2.1.5).

La actividad de �ltrado necesita recorrer completamente la lista de resultados, por lo que se ejecuta entiempo O (n). Dado que el ordenamiento de los resultados se ejecuta en el mejor de los casos en tiempoO (n log n), para reducir el tiempo total de ejecución, el �ltrado debe preceder al ordenamiento.


3.2. Mapeo de Clases

3.2.1. Introducción

En la sección (3.1) recorrimos los problemas que componen un framework como el que queremos desar-rollar, investigamos las variantes de implementación y efectuamos propuestas concretas acerca de cómoresolver el problema.

En esta sección haremos una transición del análisis al diseño abordando los siguientes problemas:

cómo indicar al framework de IR las decisiones que tomamos en cuanto a cómo queremos indexary recuperar los objetos,

cómo procesar los objetos de forma que éstos se conviertan desde y hacia las posting lists.

Comencemos a resolver estos problemas con una analogía:

La mayoría de los frameworks de persistencia automática requieren que el programador indique cómo debeser mapeo entre el modelo de objetos y al RDBMS. Mas allá de cuan �inteligente� sea el framework depersistencia, el framework desconoce la semántica de cada atributo (por ejemplo, para saber qué camposdeben ser persistentes o claves) y existen muchas formas de mapear un conjunto de clases.

Análogamente, un framework de IR sobre objetos tampoco puede deducir qué clases deben indexarse oqué atributos deben utilizarse para la recuperación.

Para resolver este problema, es necesario idear un sistema de mapeos de clases 2 que produzca directivasde indexación3 tal que el framework pueda obtener información semántica del dominio.

Este mapeo de clases debe especi�car qué tipos de objetos deben ingresar al framework de IR para serindexados y recuperados. Estos tipos son llamados clases indexables.

Además, para poder recuperar los objetos desde los índices invertidos e hidratar los resultados, necesita-mos conocer qué atributo identi�ca unívocamente al objeto. Estos son los identi�cadores de objeto.

Por último, es necesario especi�car qué parte del objeto contiene la información a indexar. Estos son losatributos indexables.

Si bien veremos que hay otras directivas más complejas, las directivas básicas deben determinar (a) cuálesson las clases indexables, (b) los identi�cadores de objeto y (c) los atributos indexables.

A continuación explicamos cómo se con�guran los mapeos en el framework de IR para luego explicarmapeos más avanzados.

3.2.2. Con�guración y Mapeo

El conjunto de directivas de indexación de todas las clases indexables constituyen lo que llamamos lacon�guración del framework.

Enumeremos algunas propiedades de la con�guración:

1. Para efectuar cualquier acción de indexación o recuperación debe existir una con�guración activa.

2. En todo momento existe a lo sumo una con�guración activa (puede no haber ninguna).

3. Las con�guraciones son modi�cables durante el ciclo de vida de la aplicación sin requerir reiniciosde la misma.

4. Se pueden generar programaticamente o a partir de anotaciones Java.

La con�guración es un punto centralizado del framework, por lo cual lo implementamos en la claseSearchCon�guration siguiendo el patrón Singleton (Gamma et al., 1995).

2En rigor, el término mapeo no debería ser usado ya que suele referir a un isomor�smo entre un modelo de objetos y unmodelo distinto como el relacional, lo cual veremos que no sucederá en este caso.

3Si bien estas directivas se suelen utilizar simétricamente en la indexación y la recuperación, por simplicidad hablamossólo de directivas de indexación implicando también la recuperabilidad de los objetos.

3.2. MAPEO DE CLASES 101

Mapeo Programático

Como explicamos anteriormente, el motor de búsqueda se puede con�gurar programaticamente o medianteanotaciones. Para el caso programático, el programador de�ne los mapeos invocando los métodos de laclase SearchCon�guration.

Ejemplo 3.2.1 (Con�guración y Mapeo Programático). El siguiente fragmento de código muestra elmapeo programático de una clase y un atributo mediante un test JUnit.

1 pr i va te c l a s s DummyEnt i tyWithAttr ibute {2 pr i va te Object a t t r i b u t e ;3 }45 @Test6 pub l i c void t e s tMappedAtt r i bu te I sMapped ( ) {7 // creamos una nueva c o n f i g u r a c i o n y obtenemos una r e f e r e n c i a a e l l a8 Se a r c hCon f i g u r a t i o n c o n f i g u r a t i o n = SearchEng ine . g e t I n s t a n c e ( ) .

n ewCon f i gu r a t i on ( ) ;910 // l a en t i d ad a mapear11 DummyEnt i tyWithAttr ibute dummyWithAttr ibutes = new

DummyEnt i tyWithAttr ibute ( ) ;1213 // g e t A t t r i b u t e F i e l d e x t r a e e l campo ' a t t r i b u t e ' de una c l a s e c u a l q u i e r a14 F i e l d a t t r i b u t e F i e l d = g e t A t t r i b u t e F i e l d ( dummyWithAttr ibutes ) ;1516 // agregamos un mapeo para l a c l a s e y e l a t r i b u t o17 c o n f i g u r a t i o n . addEmptyMapping ( dummyWithAttr ibutes . g e tC l a s s ( ) ) . put (

a t t r i b u t e F i e l d , new MappedF i e l dDe s c r i p t o r ( a t t r i b u t e F i e l d ) ) ;1819 // v e r i f i c amo s que e l a t r i b u t o ha s i d o mapeado20 As s e r t . a s s e r tT r u e ( c o n f i g u r a t i o n . isMapped ( dummyWithAttr ibutes . g e tC l a s s ( ) ,

a t t r i b u t e F i e l d ) ) ;21 }

Analicemos las líneas más importantes de este fragmento de código:

El primer paso para iniciar el trabajo se da en la línea 8 con la generación de una nueva con�guración.

En las líneas 11 y 14 extraemos el atributo attribute de la clase DummyEntityWithAttributes, el cual semapea programaticamente en la línea 17.

Por último, la línea 20 veri�ca que el mapeo se haya efectuado.

En el ejemplo anterior podemos intuir que la con�guración programática es una solución relativamente�bajo nivel�. En la próxima subsección veremos una con�guración de más alto nivel a partir de anotaciones.

Mapeo desde Anotaciones Java

Para con�gurar el framework mediante anotaciones contamos con la clase AnnotationCon�gurationMapper.Esta clase inspecciona la estructura de la clase en busca de anotaciones propias del motor de búsqueda einternamente utiliza la interfaz programática para generar el mapeo. Veamos un ejemplo de la con�gu-ración por anotaciones:

Ejemplo 3.2.2. Veri�quemos que una clase anotada como indexable fue mapeada como tal utilizandoun test JUnit.

1 @Indexab l e2 pr i va te c l a s s DummyIndexable {}34 @Test


5 pub l i c void t e s t I n d e x ab l eOb j e c t I sMapped ( ) throws

SearchEng ineMapp ingExcept ion {6 // e l im inamos c u a l q u i e r c o n f i g u r a c i ó n p r e v i a y generamos una nueva7 SearchEng ine . g e t I n s t a n c e ( ) . r e s e t ( ) ;89 // e l o b j e t o a i ndexa r , cuya c l a s e queremos mapear10 DummyIndexable dummyIndexable = new DummyIndexable ( ) ;1112 // creamos una nueva c o n f i g u r a c i ó n y obtenemos una r e f e r e n c i a a e l l a13 Se a r c hCon f i g u r a t i o n c u r r e n t C o n f i g u r a t i o n = SearchEng ine . g e t I n s t a n c e ( ) .

n ewCon f i gu r a t i on ( ) ;1415 // creamos e l mapeador de ano t a c i o n e s y l e pedimos que16 Annota t i onCon f i gu ra t i onMappe r mapper = new Annota t i onCon f i gu ra t i onMappe r

( ) ;1718 // e s t e método e f e c t ú a todos l o s mapeos n e c e s a r i o s19 mapper .map( o b j e c t ) ;2021 // v e r i f i c amo s que l a c l a s e f u e mapeada y que es i n d e x a b l e ( r e c o r d a r que

una cosa no imp l i c a l a o t r a ! )22 As s e r t . a s s e r tT r u e ( c u r r e n t C o n f i g u r a t i o n . isMapped ( dummyIndexable . g e tC l a s s ( )

) ) ;23 As s e r t . a s s e r tT r u e ( c u r r e n t C o n f i g u r a t i o n . getMapping ( dummyIndexable . g e tC l a s s

( ) ) . i s I n d e x a b l e ( ) ) ;2425 }

Nuevamente hagamos un análisis de las líneas más importantes:

La línea 1 comienza con la anotación @Indexable, la cual le indica al framework que los objetos de estetipo deben ser considerados en la indexación.

La línea 7 renueva la con�guración, de forma de eliminar mapeos previos, siendo que la línea 13 obtieneuna instancia de la con�guración.

En la línea 16 creamos un AnnotationCon�gurationMapper, quien será el encargado de leer las anotacionesde los objetos e internamente generar la con�guración programática. Esto se materializa en la línea 19con la ejecución del método map.

Por último, las líneas 22 y 23 veri�can que efectivamente hayamos mapeado la clase como indexable.

Como explicamos antes, dado que el mapeo desde anotaciones utiliza internamente la con�guración pro-gramática, el poder de expresividad de las anotaciones es equivalente al anterior (aunque mucho mássencillo).

Si bien ya hemos visto cómo indicar que una clase es indexable, para constituir la clave del objeto nece-sitamos indicar qué atributo lo identi�ca dentro de la jerarquía de clases. Este atributo se especi�caanotándolo con @SearchId. Utilizando en conjunto las anotaciones @Indexable y @SearchId podemos con-struir la clave del objeto, la cual será necesaria para identi�car unívocamente el objeto recuperado.

La última anotación básica que nos resta presentar es la que nos indica qué atributos deben utilizarsepara indexar el objeto. Esta anotación es @SearchField. Veamos un ejemplo en el que combinamos estastres anotaciones para efectuar un mapeo básico:

Ejemplo 3.2.3. En el siguiente fragmento de código aplicamos las anotaciones @Indexable, @SearchId y@SearchField para indexar una clase de dominio:

1 @Indexab l e2 pr i va te c l a s s A r t i c l e {3 @Search Id4 pr i va te long i d = 1L ;


56 @Sea r chF i e l d7 pr i va te S t r i n g abstract = " In r e c e n t yea r s , advances i n the f i e l d o f . . . " ;8 }

En las próximas secciones veremos capacidades avanzadas de nuestro framework que nos permitirántrabajar con objetos y jerarquías complejas.

3.2.3. Mapeos Avanzados

Los usos más simples del framework requieren mapear una clase como indexable, su identi�cador y loscampos desde los que extraer información. Sin embargo, en los próximos apartados consideraremosmapeosavanzados que nos permitirán trabajar con jerarquías de herencia, asociaciones de objetos, indexar objetosen colecciones y muchos otros casos de uso.

Jerarquías de Herencia

En dominios que utilizan subclasi�cación debemos considerar los siguientes casos:

un objeto debe poder ser indexable por pertenencia a una jerarquía de objetos indexables,

los atributos de un objeto indexable deben poder repartirse a lo largo de toda la jerarquía deherencia sin requerir que todas las clases en dicha jerarquía sean indexables,

en una jerarquía indexable, ciertos miembros de la jerarquía pueden querer ser excluidos de la árboljerarquía de clases indexable.

Ejemplo 3.2.4 (Mapeo en Cascada y Herencia de Atributos). En este fragmento de código, la claseChildWithCascadeParent hereda de su superclase la capacidad de ser indexado, así como sus atributos deindexación.

@Indexab l e ( makeSubc l a s s e s I nd e xab l e = true )pr i va te c l a s s SuperWithCascade {

@Search Id pub l i c i n t i d ;@Sea r chF i e l d pub l i c S t r i n g someValue ;

}

pr i va te c l a s s Ch i ldWithCascadeParent extends SuperWithCascade { }

Ejemplo 3.2.5. En el siguiente fragmento de código, un objeto hereda atributos de su superclase, pormás que esta última no es indexable:

pr i va te c l a s s Not Indexab l eWi th Id {@Search Id pub l i c i n t i d = 1000 ;

}

@ Indexab l e ( c l imb i ngTa rg e t = Not Indexab l eWi th Id . c l a s s )pr i va te c l a s s I n d e x a b l eW i t h I n h e r i t e d I d extends Not Indexab l eWi th Id {

pub l i c S t r i n g a t t r i b u t e = " someth ing " ;}

Ejemplo 3.2.6. Este fragmento de código muestra el caso en el cual una clase propaga su condición deindexable sólo en una rama de la jerarquía de herencia:

@Indexab l e ( makeSubc l a s s e s I nd e xab l e = true )pr i va te c l a s s SuperWithCascade {

@Search Id pub l i c i n t i d ;}

@Not Indexab lepr i va te c l a s s Not I nde xab l eL ea f extends SuperWithCascade {}

pr i va te c l a s s I n d e x a b l e L e a f extends SuperWithCascade {}

Si bien el mapeo de jerarquías es inherentemente complejo, esta herramienta nos da el poder de expre-sividad necesario para controlar la indexación de dominios con uso extensivo de subclasi�cación.

En el próximo apartado tratamos el caso de objetos referenciados entre sí.

Asociación de Objetos

Existen una serie de casos en los cuales el motor de búsqueda debe conocer las relaciones entre objetos,de forma de indexar indirectamente un objeto a partir de sus asociaciones.

Las asociaciones entre objetos pueden requerir indexación en los siguientes casos:

los objetos de una colección deben poder ser indexados a partir del objeto que tiene la referencia ala colección. Ejemplo: relación entre un objeto �autor� y una lista de objetos �libro� correspondientea sus obras.

si un objeto (indexable o no) mantiene una referencia a un objeto indexable, debemos poder indexareste segundo objeto. Ejemplo: un objeto �producto� referenciado por un objeto �orden de compra�.

en los casos previos debemos permitir que el objeto indexado referencie a su contenedor, a él mismoo ambos.

Ejemplo 3.2.7 (Mapeo de Asociaciones). Veamos cómo se indican algunas relaciones de asociaciónmediante anotaciones:

@Indexab l eCon t a i n e rpub l i c c l a s s DummyContainter {

@Sea r c hCo l l e c t i o n ( r e f e r e n c e=Ind e xRe f e r e n c e . SELF) L i s t <DummyContained>o b j e c t L i s t = new Ar r a yL i s t <DummyContained>() ;

}

En el fragmento de código anterior, la anotación @IndexableContainer indica al motor de búsqueda que sibien la entidad no es indexable, debe ser inspeccionada porque contiene elementos indexables.

La anotación @SearchCollection indica que los objetos de la colección deben ser analizados para indexarlosy el parámetro reference indica que cualquier posting resultante de este análisis debe hacer referencia alobjeto de tipo DummyContained y no a DummyContainer. El parámetro reference se puede variar para quelas referencias de los postings producidos referencien al objeto contenedor o a ambos.

Selección de Índices

En ocasiones necesitamos segregar objetos de distinta naturaleza en diferentes índices, tal de permitir laindexación y recuperación de unos y otros en forma independiente. Por ejemplo, en la subsección (4.2.3)utilizaremos la selección de índices para separar la búsqueda e indexación de productos comerciales de lade anuncios publicitarios.

La selección del índice se puede hacer:

a nivel de clase, utilizando un mismo índice para toda instancia de la clase,

en forma dinámica por objeto según el valor de un atributo o el valor retornado desde un método.

Ejemplo 3.2.8. Veamos algunos ejemplos de selección de índices con annotations.


1 @Indeaxab l e ( indexName=" a d v e r t i s i n g " )2 pub l i c c l a s s Ad v e r t i s i n g {3 @Search Id pr i va te Long i d ;4 @Sea r chF i e l d pr i va te S t r i n g t i t l e ;5 pub l i c S t r i n g h y p e r l i n k ;6 . . .7 }89 @Indexab l e ( indexName=" p roduc t s " )10 pub l i c c l a s s Product {11 @Search Id12 pr i va te Long i d ;13 @Sea r chF i e l d14 pr i va te S t r i n g i t emT i t l e ;15 }

En este ejemplo, las líneas 1 y 9 seleccionan de forma estática los índices de cada entidad.

Veamos otro caso:

1 @Indexab l e2 pr i va te c l a s s Something {34 @Search Id5 pr i va te I n t e g e r i d ;67 @ Ind e xS e l e c t o r8 pr i va te S t r i n g i n d e x S e l e c t o r ;910 @Sea r chF i e l d11 pr i va te S t r i n g v a l u e ;12 }

En este nuevo caso, la selección se da en forma dinámica según el valor del atributo indexSelector de lalínea 8.

La separación de objetos en distintos índices también permite a la capa de acceso a datos separar losobjetos indexados en diferentes tablas, archivos o estructuras de datos, lo cual puede mejorar la e�cienciade dicha capa.

Identi�cador y Selector de Lenguaje

El identi�cador de lenguaje le indica al framework que los objetos de una clase poseen textos en unlenguaje determinado. Esto permite que las clases que procesan el texto de los objetos adecúen su listade stopwords, stemmer y demás elementos al lenguaje particular del objeto que tratan.

Esta es una característica original de nuestro framework que no suele estar presente en otros similares.

Esto es muy util en casos como el desarrollo web, donde una misma clase produce objetos para sitiosde países distintos. Con esta directiva, escribimos un único código y en tiempo de ejecución elegimos laimplementación correcta del procesador de textos.

La selección del lenguaje se puede dar en forma general para todos los objetos de una clase o bien serelegida objeto por objeto en base al valor de un atributo. Cuando la selección del lenguaje se da por unatributo, tenemos un selector de lenguaje. A continuación vemos un ejemplo:

Ejemplo 3.2.9 (Indicador y Selector de Lenguaje ). Veamos cómo indicar el lenguaje de un objetomediante anotaciones:

@Indexab l e @LangId ( v a l u e="es_AR" )pr i va te c l a s s DummyIndexableWithLangId {


@Search Id pr i va te long i d = 0 ;@Sea r chF i e l d pr i va te S t r i n g t e x t = "yo u t i l i z o p a l a b r a s l o c a l e s como ' che

' " ;}

@ Indexab l epr i va te c l a s s DummyIndexableWithLangSe lector {

@Search Id pr i va te long i d = 0 ;@LangSe l ec to r pr i va te S t r i n g l ang = "en_US" ;@Sea r chF i e l d pr i va te S t r i n g t e x t = " t h i s t e x t shou l d be i ndexed i n

Eng l i s h . " ;}

En el código anterior, la clase DummyIndexableWithLangId está anotada de forma que todos los objetosde ése tipo serán procesados según la lista de stopwords, stemmers y correcciones del español localizadoen Argentina.

Para el segundo caso, DummyIndexableWithLangSelector especi�ca un atributo que por defecto indica laindexación de texto en inglés localizado en los Estados Unidos, pero que puede variar objeto a objeto.

Filtrado y Ordenamiento

Cuando analizamos las técnicas de puntaje y relevancia (ver subsección 3.1.4), vimos que debemos darsoporte al modelo de similitud del modelo de IR, los ordenamientos por reglas duras y blandas y al �ltradoy clasi�cación de objetos. Para brindar este soporte, debemos indicarle al framework qué campos van aparticipar en estos procesos.

Dado que la recuperación booleana no incorpora una noción de similitud intrínseca al modelo, no necesita-mos almacenar ninguna información adicional a la clave del objeto. Sin embargo, para el modelo vectorialsí debemos almacenar valores adicionales para el cálculo de TF-IDF. Para esto, nuestro framework norequiere una directiva de mapeo explícito sino que automáticamente ubica los valores necesarios junto alos postings y posting lists.

Tratemos ahora el caso de �ltrado y ordenamiento:

Como explicamos en la subsección (3.1.4), tanto el �ltrado como el ordenamiento ocurren antes de lahidratación de los resultados. Por lo tanto, el motor de búsqueda es responsable de proveer los atributosrequeridos en esa etapa. Para identi�car estos valores, incluimos una directiva de mapeo para atributosde �ltrado y ordenamiento. Veamos un ejemplo:

Ejemplo 3.2.10 (Mapeo de Atributos para Filtrado). En este extracto de código mostramos cómo indicarque cierto atributo debe utilizarse para �ltrado utilizando anotaciones:

1 @Indexab l e2 pr i va te c l a s s E n t i t y F o r F i l t e r i n g {3 @Search Id pub l i c i n t i d ;45 @Sea r chF i e l d pub l i c S t r i n g a t t r i b u t e ;67 @Se a r c hF i l t e r ( accessByGet=true ) pub l i c Date da t eO fB i r t h ;89 pub l i c Date ge tDateOfB i r th ( ) {10 Ca l enda r b i r t hC a l e n d a r = Ca l enda r . g e t I n s t a n c e ( ) ;11 b i r t hC a l e n d a r . s e t ( Ca l enda r .YEAR,1983 ) ;12 b i r t hC a l e n d a r . s e t ( Ca l enda r .MONTH,03 ) ;13 b i r t hC a l e n d a r . s e t ( Ca l enda r .DAY_OF_MONTH,30 ) ;14 b i r t hC a l e n d a r . s e t ( Ca l enda r .MINUTE, 0 ) ;15 b i r t hC a l e n d a r . s e t ( Ca l enda r .SECOND, 0 ) ;16 b i r t hC a l e n d a r . s e t ( Ca l enda r .MILLISECOND , 0 ) ;17 return b i r t hC a l e n d a r . getTime ( ) ;18 }19 }


La clave de este ejemplo está en la línea 7. En esta línea especi�camos que el campo dateOfBirth (fecha denacimiento) debe utilizarse en tareas de �ltrado y por lo tanto debe almacenarse. Notemos que el accesoal atributo puede hacerse mediante la convención JavaBeans, llamando al método getDateOfBirth.

En este ejemplo también podemos ver que los objetos que utilizamos para el �ltrado pueden ser objetoscomplejos Java, con el simple requisito de ser serializables.

Para soportar el ordenamiento por reglas el panorama es muy similar. Ya sea �ltrado u ordenamiento,el framework siempre debe proveer los atributos intervinientes. A la hora de especi�car dichos atributos,debemos utilizar nuevamente las directivas de mapeo. Veamos un ejemplo:

Ejemplo 3.2.11 (Mapeo de Atributos para Ordenamiento por Reglas). En este extracto fragmento decódigo especi�camos que un atributo participa del ordenamiento por reglas utilizando anotaciones:

1 @Indexab l e2 pr i va te c l a s s So r t E n t i t y {3 @Search Id pr i va te i n t i d ;45 @SearchSort pr i va te f l o a t p r i c e ;67 @Sea r chF i e l d pr i va te S t r i n g t i t l e ;89 pub l i c So r t E n t i t y ( i n t id , S t r i n g t i t l e , f l o a t p r i c e ) {10 t h i s . i d = i d ;11 t h i s . t i t l e = t i t l e ;12 t h i s . p r i c e = p r i c e ;13 }14 }

En este caso la clave está en la línea 5, donde indicamos que el atributo price debe ser almacenado parautilizarse al aplicar el ordenamiento por reglas.

Con estos ejemplos estamos en condiciones de resumir los puntos claves del mapeo de atributos para�ltrado y ordenamiento:

los atributos deben almacenarse en el motor de búsqueda por utilizarse en forma previa a la hidrat-ación,

existen dos directivas de indexación que indican si un atributo participa del �ltrado y/o del orde-namiento, las cuales son accesibles programaticamente o mediante las anotaciones @SearchSort y@SearchField.

Más adelante retomaremos este tema re�riéndonos a cómo diseñar el framework para que �ltrar, clasi�cary ordenar resultados sea una tarea sencilla y rápida (subsección 3.3.5).

Procesamiento de Textos

Cuando estudiamos las técnicas de matching y acceso a datos (subsección 3.1.2), propusimos implementarcierta inteligencia que normalice y delimite los textos presentes en los objetos indexables.

En nuestro framework esta inteligencia se puede variar a partir de directivas de indexación, las cualesindican qué clase es la encargada de extraer el texto de los atributos, normalizarlos y generar términos.Veamos un ejemplo:

Ejemplo 3.2.12 (Elección del Procesador de Textos). En el siguiente fragmento de código, elegimos elprocesador de textos para la clase utilizando anotaciones:

1 @Indexab l e2 @TextProces so r ( MyTextProcessor . c l a s s )3 pr i va te c l a s s Ent i t yWi thTex tP ro c e s s o r {4 @Search Id i n t i d = 0 ;5 @Sea r chF i e l d pub l i c S t r i n g a t t r i b u t e = "some t e x t to be t r e a t e d " ;6 }


La línea clave de este ejemplo es la número 2, donde indicamos al framework que debe utilizar la claseMyTextProcessor para la extracción y procesamiento del texto �some text to be treated�.

Si no indicamos explícitamente un procesador de textos, el framework utiliza uno por defecto que aplicaeliminación de símbolos y stop words, normalización a mayúsculas, stemming y delimitación de términospor espacios.

Notas Adicionales

Cuando utilizamos un mapeo por anotaciones, todos los mapeos avanzados/directivas de indexación seheredan en la jerarquía de objetos. Es decir, si aplicamos un procesador de objetos o un selector delenguajes a una clase y ésta utiliza el parámetro makeSubclassesIndexable = true, las clases descendientesaplicarán el mismo procesador de objetos o selector de lenguajes. Para evitar la herencia de directivas deindexación podemos rede�nir la directiva en el nivel de la jerarquía donde queremos evitar que se apliquela directiva con�ictiva.

Hasta aquí explicamos qué problemas debemos resolver para generar una herramienta completa de IRsobre objetos, así como expusimos la expresividad del framework en términos de mapeos o directivas deindexación.

En la siguiente sección completamos la propuesta exponiendo el diseño interno del framework y losalgoritmos que dan solución a cada uno de los elementos que analizamos.

3.3. Diseño del Framework de IR sobre objetos

3.3.1. Introducción

Como explicamos al comenzar este capítulo, en esta sección completamos la transición del análisis aldiseño, explicando cómo hemos construido el motor de búsqueda sobre objetos.

El objetivo de esta sección es ajustar el grado de detalle y de�nir el diseño del framework que presentare-mos en funcionamiento en el capítulo 4.

3.3.2. Arquitectura del Framework

Diseño de Capas: Indexación

El framework se estructura en una arquitectura de capas intercambiables por con�guración.

En la �gura (3.8) vemos las capas que vamos a utilizar para la indexación.

3.3. DISEÑO DEL FRAMEWORK DE IR SOBRE OBJETOS 109

Indexer Service

Indexing

Pipeline

Index

Writer

Application

Memory, etc...

Figura 3.8: Arquitectura de Capas de Indexación. La primera capa siempre es la aplicativa, luego aparecenlas capas del framework y por último una sección física de almacenamiento de índices.

Analicemos cada una de estas capas:

Application: produce los eventos de indexación, delegando la indexación en el Indexer Service.

Indexer Service: es el encargado de secuenciar el procesamiento de los objetos y asegurarse que seescriban en los índices. El framework provee las siguientes variantes:

• OnlineIndexer y SemiOnlineIndexer: cumplen las funciones que explicamos en la subsección(3.1.3). Luego de resolver la secuenciación y sincronización de procesos, delegan la indexaciónen DefaultIndexerService. Más adelante veremos que existe un servicio de indexación o�ine através de JMS, el cual es provisto por un plugin.

• DefaultIndexerService: es la terminal de todos los indexadores. Se ocupa de orquestar la conver-sión de objetos a postings a través del IndexingPipeline y la escritura en los índices a través delos IndexWriter. Mantiene un pool de escritores abiertos para minimizar las aperturas y cierresde índices.

Indexing Pipeline: su responsabilidad es procesar una entidad y generar un semi índice con lospostings que deben escribirse en el índice invertido y el registro maestro. El pipeline se utiliza sóloen la creación y actualización de objetos, no en la eliminación. Este proceso lo tratamos en detallemás adelante.

Index Writer: es el encargado del acceso de escritura al índice invertido y al registro maestro.

Para visualizar mejor la solución podemos explicitar estas interfaces en el siguiente listado de código:

pub l i c i n t e r f a ce I n d e x e r S e r v i c e {pub l i c void c r e a t e ( Object e n t i t y ) throws I n d e xOb j e c tEx c ep t i o n ;pub l i c void bu l kC r e a t e ( L i s t <?> e n t i t y ) throws I n d e xOb j e c tEx c ep t i o n ;

pub l i c void d e l e t e ( Object e n t i t y ) throws I n d e xOb j e c tEx c ep t i o n ;pub l i c void bu l kDe l e t e ( L i s t <?> e n t i t i e s ) throws I n d e xOb j e c tEx c ep t i o n ;

pub l i c void update ( Object e n t i t i e s ) throws I n d e xOb j e c tEx c ep t i o n ;pub l i c void bulkUpdate ( L i s t <?> e n t i t i e s ) throws I n d e xOb j e c tEx c ep t i o n ;

pub l i c void c reateOrUpdate ( Object e n t i t y ) throws I n d e xOb j e c tEx c ep t i o n ;pub l i c void bu lkCreateOrUpdate ( L i s t <?> e n t i t y ) throws

I n d e xOb j e c tEx c ep t i o n ;}


pub l i c i n t e r f a ce I n d e x i n g P i p e l i n e {pub l i c Semi Index p r o c e s sOb j e c t ( Object e n t i t y ) throws I n d e xOb j e c tEx c ep t i o n

;}

pub l i c i n t e r f a ce I n d e xWr i t e r {pub l i c void open ( ) ;pub l i c void open ( I n d e x I d i n d e x I d ) ;pub l i c void c l o s e ( ) ;

pub l i c void w r i t e (Term term , ObjectKey key , Post ingMetadata metadata ) ;pub l i c void d e l e t e ( IndexObjec tDto indexOb jec tDto ) ;

pub l i c void openDe le teAndClose ( IndexObjec tDto indexOb jec tDto ) ;pub l i c void openWriteAndClose (Term term , ObjectKey key , Post ingMetadata

metadata ) ;pub l i c void openWriteAndClose ( I n d e x I d indexName , Term term , ObjectKey key

, Post ingMetadata metadata ) ;

}

Como comentamos al principio de este apartado, estas capas están bien de�nidas por interfaces, por loque podemos variar su implementación con facilidad.

Diseño de Capas: Recuperación

Así como la etapa de indexación cuenta con una arquitectura de capas, la etapa de búsqueda tambiéncuenta con una arquitectura de este tipo.

Veamos un diagrama de las capas del motor de recuperación:

Query Parser

Core Engine

Index Reader

Result Windowing

Sorting Rules

Filtering Rules

IR Model Similarity (Vector Model only)

Memory, etc...

Application

Figura 3.9: Arquitectura de Capas de Búsqueda. La capa aplicativa colabora con el intérprete de consultasy el motor de búsquedas. Éste se compone de sub capas según el modelo de IR correspondiente, accediendoa los índices mediante la capa de acceso a datos (IndexReader).

Analicemos en detalle las capas de la �gura (3.9):

Application: provee al QueryParser el texto u objeto de búsqueda para que éste lo interprete y envíala consulta al motor de búsqueda (Core Engine). Luego de la ejecución de la búsqueda, la aplicaciónrecibe una lista de objetos deshidratados.

Query Parser: interpreta la consulta que envía la aplicación y colabora con los procesadores de textopara normalizar y delimitar la consulta. El Query Parser es responsable de construir un árbol deconsultas adecuado al modelo de IR. Existe una implementación del Query Parser para el modelobooleano y otra para el modelo vectorial, estas son BooleanQueryParser y VectorQueryParser.

Core Engine: esta capa implementa el núcleo de la recuperación de información. Existen dos im-plementaciones, una para el modelo booleano y otra para el vectorial, estas son: BooleanSearch yVectorSearch.

Según el modelo de IR, se recibe un objeto BooleanQuery o VectorQuery y se procede a ejecutar unaserie de operaciones internas (en orden inverso):

• IR Model Similarity (sólo modelo vectorial): VectorSearch delega en un objeto VectorRanker laevaluación de los puntajes correspondientes al modelo. La implementación por defecto efectúael cálculo de la fórmula (3.1.1).

• Filtering Rules: aplica los �ltros que se especi�quen. Los �ltros se deben agregar a un objetode tipo FilterChain, el cual los recorre uno a uno, eliminando los resultados que no cumplanla condición de algún �ltro. En esta etapa podemos también clasi�car los resultados paraconstruir una búsqueda facetada.

• Sorting Rules: aquí se aplican los ordenamientos por reglas duras y blandas. Existen dos formascombinables de aplicar reglas: proveyendo una implementación de la interfaz PreSort o unaimplementación de la interfaz Comparator. En el primero caso, la implementación de PreSort esresponsable de ordenar los resultados, mientras que en el segundo caso se utiliza el algoritmode ordenamiento de la clase Collections de Java.

• Result Windowing: �nalmente los resultados son segmentados en páginas según lo especi�quela query.

Index Reader: recibe los pedidos de lectura de términos, accede a los índices y retorna las postingslists.

Ejemplo 3.3.1. Veamos un ejemplo de código que muestra la recuperación en el caso booleano y aso-ciemoslo con las capas de la �gura (3.9).

1 Boo leanQueryPar se r p a r s e r = new Boo leanQueryPar se r ( " boo l ean r e t r i e v a l " ) ;2 BooleanQuery query = pa r s e r . getQuery ( ) ;3 query . se tPage (1 ) ;4 query . s e tPageS i z e (30) ;5 Boo leanSearch boo l eanSea r ch = new Boo leanSearch ( query , MemoryIndexFactory .

g e t I n s t a n c e ( ) ) ;6 Set<ObjectKeyResu l t> r e s u l t = boo l eanSea r ch . s e a r c h ( ) ;

Este código que escribimos pertenece a la capa Application. La línea 1 accede a la capa de Query Parsing,la cual nos entrega una query sobre la cual especi�camos el paginado (ver subcapa Result Windowing deCore Engine). La línea 5 accede a la capa Core Engine indicándole al motor booleano qué implementacióndebe utilizar para la capa Index Reader. Por último, la línea 6 ejecuta la búsqueda y obtiene un conjuntode resultados deshidratados (claves de objeto u ObjectKeyResult).

Al igual que la etapa de indexación, podemos intercambiar las capas y cambiar de modelo fácilmente.Veamos una variante en las que modi�camos el motor de búsqueda y el backend de acceso a índices.

Ejemplo 3.3.2. Modi�quemos el ejemplo (3.3.1) para permitir la recuperación vectorial y utilizar unlector de índices en disco.

1 Vecto rQue ryPa r s e r p a r s e r = new Vecto rQue ryPa r s e r ( " v e c t o r r e t r i e v a l " ) ;2 VectorQuery query = pa r s e r . getQuery ( ) ;3 query . se tPage (1 ) ;4 query . s e tPageS i z e (30) ;5 Vecto rSea rch v e c t o r S e a r c h = new Vecto rSea rch ( query ,

Be r k e l e y I nd e xReade rFa c t o r y . g e t I n s t a n c e ( ) ) ;6 L i s t <VectorRankedResu l t> r e s u l t = ve c t o r S e a r c h . s e a r c h ( ) ;

A primera vista, las diferencias principales de este código con el del ejemplo (3.3.1) es el reemplazo de lapalabra �Boolean� por �Vector�. Sin embargo, hay algunos detalles que tenemos que notar:

El tipo de datos de retorno en la línea 6 cambia tanto en el tipo de colección como en su contenido. Estosucede porque la búsqueda booleana simple no aplica un modelo de similitud entre objetos, por lo tantodevuelve un conjunto de objetos (recordemos que un conjunto no tiene noción de orden). El cambio detipo de datos en la colección obedece a que en el caso vectorial los resultados contienen información devaloración, cosa que no ocurre en el caso booleano.

Por otro lado, notamos que la línea 5 cambia el uso de índices en memoria por un índice en disco Berkeley.Tanto el lector de índices en memoria del ejemplo anterior como este lector de índices Berkeley cumplencon la interfaz IndexReader, de forma tal que VectorSearch hará su trabajo independientemente de cómose almacenen los postings. Seguramente este es uno de los ejemplos más fuertes acerca de la simplicidadcon la que podemos intercambiar capas en este diseño.

Plugins

La arquitectura de capas que mostramos en las subsecciones anteriores nos permiten generar componentesintercambiables o plugins.

Cuando hablamos de plugins nos estamos re�riendo a componentes heterogéneos que pueden afectardistintas partes del framework: desde intérpretes de queries hasta acceso a índices, el comportamiento delframework es fácilmente variable por estos plugins.

Actualmente el framework dispone de cuatro plugins: índice BerkeleyDB (subsección 3.3.3), indexadoro�ine JMS (subsección 3.3.4) y los indexadores por eventos para Hibernate (subsección 3.3.4) e iBATIS(subsección 3.3.4).


Arquitectura de Índices, Posting Lists y Postings

La arquitectura de índices se organiza en base al conjunto de interfaces de la �gura (3.10):


Figura 3.10: Arquitectura de Índices. El diseño se desacopla en índices y lectores. Los índices deben imple-mentar MasterAndInvertedIndex, mientras que los lectores hacen lo propio con las interfaces de escrituray lectura.

Veamos el rol de cada interfaz:

MasterAndInvertedIndexReader y MasterAndInvertedIndexWriter: especi�can el conjunto de opera-ciones que se esperan de quien es responsable de abrir, leer/escribir y cerrar índices.

InvertedIndex y MasterIndex: representan el índice invertido y el registro maestro. En nuestro frame-work no implementamos directamente estas interfaces sino que lo hacemos a través de MasterAnd-InvertedIndex.

MasterAndInvertedIndex: representa la combinación de un registro maestro y un índice invertido, talcomo los hemos presentado al hacer el análisis del problema. En nuestro framework proveemos unaimplementación a través del MemoryIndex y otra en el BerkeleyIndex (ver más adelante el apartadoacerca de BerkeleyDB).

IndexReaderFactory e IndexWriterFactory: las implementaciones de estas dos interfaces son el puntode interacción entre la aplicación y la capa de acceso a datos. Esta es una implementación similaral patrón de diseño AbstractFactory (Gamma et al., 1995).

El hecho de contar con este juego de interfaces nos permite extender el backend de acceso a datos a partirde plugins, tal que implementándolos podemos crear índices sobre otras tecnologías como bases de datosrelacionales o archivos.


Además de este conjunto de interfaces, el diseño de los índices cuenta con otras entidades concretas. Acontinuación explicamos las entidades que aparecen como parámetros en los métodos de la �gura (3.10):

Object Key: representa la clave del objeto tal como la de�nimos en la subsección (3.1.2).

Posting List: contiene los postings asociados a un término, representándolos por pares (ObjectKey ;PostingMetadata), los cuales se almacenan en un mapa. El concepto representado por esta clase esel mismo que presentamos en la subsección (2.1.5).

Posting Metadata: este objeto almacena para cada posting los datos necesarios para el �ltrado,ordenamiento y valoración por el modelo de IR. En el caso del modelo vectorial, también llevacuenta del valor de TF para cada atributo del objeto.

Term: es la representación de un término normalizado y delimitado. Luego del procesamiento deobjetos, es la única representación del texto original del objeto operable por el motor de búsqueda.

Cualquier índice que implemente las interfaces de la �gura (3.10) debe representar la información entérminos de estos objetos desde y hacia el motor de búsqueda (por más que internamente utilice otrarepresentación de datos).

En las próximas subsecciones presentamos dos índices concretos sobre las interfaces y objetos estudiados.

Índice en Memoria

El índice en memoria es una implementación de la interfazMasterAndInvertedIndex que mantiene el registromaestro y el índice invertido en memoria RAM.

Esta implementación es útil para pruebas de concepto y el desarrollo de tests unitarios (como comentare-mos en el capítulo 4, esto es especialmente importante para nosotros ya que hicimos un desarrollo basadoen pruebas).

De los casos de estudio de la sección (2.4), podemos recordar que Apache Lucene también implementaun índice en memoria, el cual también es heredado por sus frameworks descendientes (Hibernate Searchy Compass).

Este índice también puede ser utilizado como una representación intermedia o bu�er, por ejemplo, paraun almacenamiento asincrónico en un medio persistente.

Índice Berkeley DB

BerkeleyDB (Oracle, 2009a) es una implementación gratuita de una base de datos embebida, la cual tieneuna implementación Java que incluye soporte transaccional.

Este plugin experimental se construyó para dar soporte a los índices persistentes de las aplicaciones delcapítulo 4, proveyendo versiones en disco del registro maestro y el índice invertido.

Como programador del plugin, BerkeleyDB nos provee una implementación persistente de la clase HashMapde Java, la cual es una muy buena opción para representar el mapeo entre términos y posting lists.

El diagrama de clases de este plugin es el siguiente:

Figura 3.11: Diagrama de clases del plugin BerkeleyDB.

Para utilizar el plugin basta con agregarlo como dependencia en el proyecto que se está desarrollando, yproveerlo al motor de búsqueda tanto al indexar como al recuperar objetos.

Procesador de Textos

Los procesadores de textos forman un componente esencial en cualquier motor de búsqueda ya quedeterminan en gran medida el recall y precisión del sistema.

En nuestro caso, éstos intervienen en la indexación de objetos y en la interpretación de consultas deusuarios.

La interfaz que debe cumplir un procesador de textos para la indexación es la siguiente:

pub l i c i n t e r f a ce Ob j e c tTex tP roce s s o r {pub l i c abst ract L i s t <Term> p r o c e s s F i e l d ( S t r i n g ex t r a c t edTex t ,

MappedF i e l dDe s c r i p t o r f i e l d D e s c r i p t o r ) ;}

y para el caso de la interpretación de consultas:

pub l i c i n t e r f a ce QueryTextProces so r {pub l i c L i s t <Term> proc e s sTex t ( S t r i n g t ex t , Language language ) ;

}

Analicemos cada interfaz para entender sus similitudes y diferencias:


Al momento de indexar un objeto necesitamos conocer información acerca de cómo fue mapeado (porejemplo, para saber qué tipo de stemming aplicar). Dentro de la información de mapeo se encuentranlos detalles acerca del lenguaje del objeto o del atributo, el tipo de stemming a aplicar, cómo extraer lostextos de los atributos, etc.

Por otro lado, al momento de interpretar una query, la interfaz sólo requiere el texto de la consulta y sulenguaje. Otras características como el stemming o la eliminación de stop words no deben pertenecer a lainterfaz de estos objetos porque no son una parte esencial de un procesador de textos sino implementa-ciones particulares que deben con�gurarse por separado de la interfaz de�nida.

Comentemos brevemente respecto de la inclusión explícita de lenguajes:

Una característica original de este framework es que incorpora explícitamente la noción de lenguaje a lolargo de todas las clases de mapeos y procesamiento de textos.

El hecho de conocer el lenguaje de los objetos en tiempo de ejecución podría haber sido opcional, sinembargo, decidimos incluirlo en todo el sistema porque permite extender naturalmente el frameworkpara efectuar operaciones como la corrección de ortografía (lo cual de otra forma requeriría reconocerel lenguaje del texto original, lo cual no es trivial). Si no tuviéramos una fuerte presencia de objetosque representan lenguajes, seguramente tendríamos que resolver este problema por nuestra cuenta ydi�cultaríamos las extensiones del framework, lo cual no es deseable.

En esta versión del framework incluimos un procesador de textos por defecto para la indexación ( De-faultObjectTextProcessor ) y otro para la interpretación de consultas ( DefaultQueryTextProcessor ). Estosprocesadores aplican normalización a mayúsculas, eliminación de caracteres no alfabéticos, delimitaciónde términos por espacios, eliminación de stop words y, en caso de que corresponda, stemming snowball.

Intérprete de Consultas

En la subsección (3.1.2) explicamos que la interpretación de consultas comprende tanto la normalizacióny delimitación de textos, a cargo del procesador de textos, así como la construcción del árbol de consultas.Este apartado expone el diseño de las clases encargadas de la construcción del árbol de consultas.

Cada modelo de IR cuenta con su propio intérprete de consultas: en el caso booleano tenemos el Boolean-QueryParser mientras que en el vectorial tenemos el VectorQueryParser. Estos intérpretes se diferencianen los algoritmos que aplican para generar el árbol de consulta, de forma de soportar sus operadores yestándares �de facto� (ver subsección 3.1.2).

Para soportar estas dos variantes, cada modelo complementa su árbol de consulta con un extractor deposting lists. El trabajo del extractor es:

1. leer las postings lists y generar resultados según el tipo de objeto esperado por cada modelo,

2. recolectar desde el índice los datos necesarios para el modelo correspondiente de IR. En el caso delmodelo vectorial, buscamos el valor de DF sobre los postings recuperados.

Mas allá de qué algoritmo se utilice, cada interprete lee la consulta del usuario y la traduce en unacomposición de operadores lógicos AND, OR, NOT mas un operador adicional no booleano llamadoRETRIEVE ó simplemente R. Este último operador tiene la responsabilidad de leer la posting list desdeel índice y colaborar con el extractor de resultados para generar un resultado parcial de la búsqueda (versubsección 3.1.2).

La jerarquía de clases que representa estos operadores se presenta en la �gura (3.12).


Figura 3.12: Jerarquía de Operadores. Los operadores constituyen el árbol de consulta de una query. Elnodo raíz produce la ejecución en cascada del resto de los operadores, terminando siempre en nodos hojade tipo RETRIEVE.

La jerarquía de la �gura (3.12) se organiza de la siguiente forma:

Operator: clase abstracta que de�ne las responsabilidades de cualquier operador. Estas respons-abilidades son: entregar el término que los representa en una query (getOperatorTerm), efectuar suoperación (work) y rede�nir los métodos hashCode e equals de la clase Object.

BinaryOperator: esta clase abstracta representa un operador que a su vez contiene un operadorizquierdo y derecho. Esta clase es la base de la composición de operadores, lo cual permite laconstrucción del árbol de consulta. La mayoría de los operadores extienden esta clase.

BinarySimetricOperator: esta clase abstracta agrega a BinaryOperator la propiedad de conmutativi-dad. Rede�ne los métodos equals y hashCode para adecuarlos a su semántica.

MinusOperator, OrOperator, AndOperator: estos son operadores concretos cuyos métodos work efec-túan operaciones de substracción, conjunción y disyunción de conjuntos. Cada uno de ellos im-plementa el método getOperatorTerm para indicar cómo se los debe reconocer en una query. ElMinusOperator es un operador simétrico no conmutativo, por lo que extiende a BinaryOperator. Encambio, OrOperator y AndOperator sí son conmutativos, de forma que extienden a BinarySimetric-Operator.

RetrieveOperator: esta clase concreta implementa el único operador unario de la jerarquía. El objetivode esta clase es obtener y extraer los postings a partir del lector del índice. El RetrieveOperator esel único operador hoja de esta jerarquía.

Desde el punto de vista procedural, cuando el intérprete de queries le entrega el árbol de consulta al motorde búsqueda, éste ejecuta el método work del operador raíz, produciendo la ejecución en cascada de losoperadores del árbol. Por ejemplo, si la raíz es un operador binario, éste pedirá a su término izquierdolos resultados de su trabajo, luego hará lo mismo con el derecho y por último operará sobre los conjuntosobtenidos por sus operadores izquierdo y derecho.


3.3.4. Procesos de Indexación

En esta subsección vamos a tratar el diseño de la parte del framework que desglosa objetos de dominioen postings del índice invertido.

El diseño del framework separa los procesos de indexación en tres subcapas con responsabilidades biendiferenciadas:

Dinámica de Indexación: maneja el nivel de asincronismo entre las transacciones de negocio y laactualización de los índices. Aquí tenemos los indexadores online, semi-online u o�ine.

Secuenciamiento de la Indexación y Acceso a Índices: orquesta el procesamiento de objetos y lainteracción con la capa de escritura de índices. Aquí tenemos al DefaultIndexerService.

Procesamiento de Objetos / Pipeline de Indexación: es responsable de generar postings a partir deun objeto y su descripción de mapeo.

Pipeline de Indexación

El pipeline de indexación es el encargado de implementar la lógica de generación de postings a partir deun objeto de dominio.

Este proceso debe tener en cuenta los mapeos que expusimos en la sección (3.2), de forma tal de producirlos resultados esperados por el usuario del framework.

El pipeline de indexación es de�nido de la siguiente forma:

pub l i c i n t e r f a ce I n d e x i n g P i p e l i n e {pub l i c Semi Index p r o c e s sOb j e c t ( Object e n t i t y )

throws I n d e xOb j e c tEx c ep t i o n ;}

La implementación por defecto de este interfaz está dada por la clase DefaultIndexingPipeline. Al igualque otras capas del framework, el pipeline de indexación se puede reemplazar fácilmente proveyendo otraimplementación de IndexingPipeline.

En la �gura (3.13) presentamos un diagrama de actividades simpli�cado para la implementación delmétodo processObject de DefaultIndexingPipeline.


Figura 3.13: Diagrama de actividades para el método DefaultIndexingPipeline.processObject(Object entity).En este diagrama simpli�cado vemos las variantes de generación del semi índice en función de cómo fuemapeada la entidad.

Analizando el diagrama de actividades de la �gura (3.13) vemos que la indexación de un objeto dependeen gran parte de si es indexable por sí mismo y/o si es un contenedor de objetos indexables.

El primer rombo de decisión del diagrama (3.13) insinúa la capacidad de este algoritmo de indexarjerarquías de objetos anidados. Esta capacidad se implementa mediante recursión. Para controlar queesta recursividad sea �nita, cada llamado veri�ca que el objeto actual no haya sido procesado en el árbolde llamadas del hilo actual, retornando en caso de que ello suceda.

El sistema de mapeos permite además que los objetos anidados generen postings con referencias a suscontenedores, y a su vez estos postings pueden almacenarse en un índice distinto al del objeto contenedor.Para soportar estas características, el resultado del método processObject no puede ser simplemente �unconjunto de postings a aplicar en el índice� sino que debe ser una estructura más compleja llamada semiíndice (SemiIndex).

El semi índice representa un mapeo a postings de los objetos que están cursando su proceso de indexación.Además de sus características como estructura de datos, el semi índice permite la operación de fusión(merge) con otro semi índice, tal de permitir acumular postings a medida que procesamos recursivamenteuna jerarquía de objetos anidados.

Indexador Online, Semi-Online & O�ine

En este apartado retomamos la discusión de la subsección (3.1.3), diseñando las tres dinámicas de in-dexación de objetos: indexación online, semi-online y o�ine.

Para crear un indexador que re�eje los eventos CUD en el motor de búsqueda, debemos implementar lainterfaz IndexerService. Los indexadores que vamos a presentar se ocupan de la relación entre la transacción


y la indexación. La generación de postings no es implementada por estas clases sino que se delega en otraimplementación de IndexerService.

El primer indexador que vamos a comentar es el OnlineIndexer, el cual naturalmente se corresponde conel indexador online que presentamos en la sección de análisis. Este indexador hace algunas veri�cacionessimples y delega el procesamiento de los objetos en una implementación de IndexerService (normalmenteen DefaultIndexerService).

El segundo tipo de indexador es el semi-online y está implementado por la clase SemiOnlineIndexer. Eneste modo de indexación debemos trabajar en forma asincrónica a la transacción de negocio, encolandolos pedidos de indexación y retornando inmediatamente el control a la aplicación. El desencolado de estospedidos de indexación se realiza en forma concurrente por un grupo de hilos, los cuales se comportancomo indexadores online en paralelo.

Por último tenemos al indexador o�ine. Éste es similar al indexador semi-online, excepto por la diferenciade que la cola de pedidos se implementa en forma persistente y el proceso que desencola los pedidos debeejecutarse en una máquina virtual distinta al que los encola. El indexador o�ine requiere de un pluginque provea la cola de indexación persistente, siendo que nuestra implementación está basada en JMS (versubsección 3.3.4).

Al discutir los casos de experimentación del capítulo 4 veremos cómo variar la dinámica de indexacióncon una simple con�guración de inyección de dependencias.

Plugin de Indexación O�ine JMS

Este plugin implementa la indexación o�ine utilizando una implementación del estándar de mensajeríade Java, la tecnología JMS (?). La implementación particular de JMS que utilizamos para este plugin esApache ActiveMQ (Apache, 2009a).

Nuestra implementación consiste en un plugin inyectable como dependencia en la capa de interacción conel ORM. Al igual que cualquier indexador, es necesario implementar la interfaz IndexerService, lo cualhicimos en la clase JmsO�ineIndexer.

La migración hacia/desde el indexador o�ine JMS es transparente a la aplicación ya que la imple-mentación de IndexerService es semánticamente equivalente al indexador online o el semi-online.

Plugin Hibernate

El objetivo de este plugin es re�ejar los eventos CUD del ORM en el motor de búsqueda.

Para usar este plugin, debemos registrarlo como un escucha de los eventos que se producen en el ORMmediante con�guración de Hibernate. El plugin consiste en una implementación de las interfaces deescucha de eventos de Hibernate, tal de re�ejar los cambios de estado de los objetos en nuestro motor debúsqueda.

El principio de funcionamiento del plugin es simple: cuando un objeto se crea, actualiza o elimina unobjeto, Hibernate envía a los escuchas registrados la información relativa a dicho evento. Esta informaciónes recibida por nuestro framework, quien la re�eja en los índices.

Ejemplo 3.3.3 (Con�guración Programática del Plugin para Hibernate). Veamos cómo con�gurar Hi-bernate para que utilice el plugin de indexación por eventos.

1 H i b e r n a t eE v e n t I n t e r c e p t o r l i s t e n e r=2 new H i b e r n a t eE v e n t I n t e r c e p t o r (3 new S e a r c h I n t e r c e p t o r (4 new De f a u l t I n d e x e r S e r v i c e (5 new De f a u l t I n d e x i n g P i p e l i n e ( ) ,6 Memory IndexWr i te rFactory . g e t I n s t a n c e ( ) ) ) ) ;78 Con f i g u r a t i o n c o n f i g u r a t i o n = new Con f i g u r a t i o n ( ) . c o n f i g u r e ( ) ;9 c o n f i g u r a t i o n . g e t E v e n t L i s t e n e r s ( ) . s e t P r e I n s e r t E v e n t L i s t e n e r s (new

P r e I n s e r t E v e n t L i s t e n e r [ ] { l i s t e n e r }) ;

10 c o n f i g u r a t i o n . g e t E v e n t L i s t e n e r s ( ) . s e tP r eUpda t eEv en t L i s t e n e r s (newPreUpda t eEven tL i s t ene r [ ] { l i s t e n e r }) ;

11 c o n f i g u r a t i o n . g e t E v e n t L i s t e n e r s ( ) . s e t P r eD e l e t e E v e n t L i s t e n e r s (newP r eDe l e t eE v e n t L i s t e n e r [ ] { l i s t e n e r }) ;

1213 s e s s i o n F a c t o r y = c o n f i g u r a t i o n . b u i l d S e s s i o n F a c t o r y ( ) ;

Las líneas 1 a 6 con�guran las capas de indexación del framework (ver �gura 3.8). La clase Hiberna-teEventInterceptor que referenciamos en la línea 1 será la encargada de escuchar los eventos producidospor Hibernate y enviarlos a SearchInterceptor. La línea 8 le indica a Hibernate que ya puede con�gurarse,mientras que las líneas 9 a 11 son especialmente importantes porque le indican a Hibernate que debecomunicar los eventos CUD al framework de indexación.

Plugin iBATIS

Al igual que el plugin Hibernate, el plugin para iBATIS conecta el ORM con el motor de búsqueda paraque los eventos CUD generados en la aplicación se re�ejen en nuestro framework. Veamos un ejemplo.

Ejemplo 3.3.4 (Con�guración de Plugin Interceptor de iBATIS). Veamos cómo se con�gura un inter-ceptor iBATIS a partir de XML y un fragmento de código.

El primer paso consiste en editar el archivo XML de con�guración iBATIS para indicarle que utilicenuestro plugin:



La clase Ibatis3Interceptor que de�nimos en esta con�guración implementa la interfaz Interceptor deiBATIS, lo que le permite recibir los eventos CUD.

Por último, las capas de indexación se interconectan como hicimos con el plugin de Hibernate:

new I b a t i s 3 I n t e r c e p t o r ( ) . s e t S e a r c h I n t e r c e p t o r (new S e a r c h I n t e r c e p t o r (

new De f a u l t I n d e x e r S e r v i c e (new De f a u l t I n d e x i n g P i p e l i n e ( ) ,

Memory IndexWr i te rFactory . g e t I n s t a n c e ( ) ) ) ) ;

Luego de seguir estos pasos, el framework de IR re�ejará en sus índices operaciones como las siguientes:

@Testpub l i c void Pe r s o n I s I n d e x e d ( ) throws IOExcept i on {

Company c = new Company ( ) ;c . s e t I d (1 ) ;Person p = new Person ( " J u l i á n " , " Klas " , " j k l a s @ f i . uba . a r " ) ;p . setCompany ( c ) ;

new PersonDao ( s e s s i o n ) . i n s e r t P e r s o n (p , "123456" ) ;

A s s e r t . a s s e r t E q u a l s (1 , MemoryIndex . g e tDe f a u l t I n d e x ( ) . getObjectCount ( ) ) ;}

Hasta aquí hemos descripto el diseño de las funcionalidades de indexación. En la próxima subsecciónexpondremos el diseño del framework en términos priorizar los objetos recuperados según el modelo deIR y las reglas de negocio.

En esta subsección vamos a presentar nuestra implementación de los modelos de similitud vectorial, elordenamiento por reglas y el �ltrado de objetos.

Puntaje en el Modelo Vectorial: VectorRanker

Para implementar una fórmula de similitud en el modelo vectorial (recordemos que el modelo booleanono tiene noción de similitud), debemos implementar la interfaz VectorRanker.

Presentemos dicha interfaz:

pub l i c abst ract L i s t <VectorRankedResu l t> rank ( VectorQuery vecto rQuery ,Set<S ing l eTe rmObjec tResu l t> un s o r t e dRe s u l t s ,Mas t e rAnd Inve r t ed IndexReade r r e a d e r ) ;

Las implementaciones de esta interfaz tienen la responsabilidad de retornar una lista priorizada de resul-tados según la relevancia del modelo.

Analicemos b¯evemente los parámetros del método rank:

VectorQuery: representa la consulta del usuario en términos del modelo vectorial. Ésta es necesariapara implementar fórmulas que tengan en cuenta los términos de la query.

Set<SingleTermObjectResult>: es el conjunto de postings obtenidos desde los índices. La imple-mentación de hashCode e equals permite que convivan en el conjunto postings que referencian a unmismo objeto desde diferentes postings lists (es decir, para distintos términos). Este conjunto esvital para efectuar el cálculo de similitud.

MasterAndInvertedIndexReader: el lector de índices es necesario para conocer datos que intervienenen la fórmula de similitud y que no corresponden a la query ni al conjunto puntual de resultados(por ejemplo, el número global de objetos indexados).

Tal como describimos en la subsección (3.1.4), nuestro framework provee una implementación por defectode la fórmula de similitud vectorial a través de la clase DefaultVectorRanker.

En el capítulo 4 presentaremos resultados experimentales en los que analizaremos los resultados de De-faultVectorRanker en aplicaciones reales.

Ordenamiento por Reglas

Tanto al estudiar el estado del arte como al analizar esta propuesta de solución vimos que es necesariotener un mecanismo de ordenamiento previo a la hidratación de objetos, interno a motor de búsqueda yque respete las variables de negocio de la aplicación huésped. Para cumplir con estas premisas, nuestroframework incorpora una capa de ordenamiento inmediatamente posterior a la similitud vectorial (en elcaso booleano se implementa inmediatamente después de la etapa de �ltrado). Para enfatizar que estacapa ejecuta previamente a la hidratación, también la llamaremos capa de pre-ordenamiento.

Si bien podríamos aplicar las reglas de negocio fuera del motor de búsqueda, esto requeriría conocer losatributos del objeto para cada resultado de la recuperación, lo que se puede traducir en miles de consultasal ORM (y potencialmente al RDBMS).

Para solucionar el problema de requerir el valor de los atributos desde el ORM, las capacidades de mapeode nuestro framework permiten almacenar atributos en el índice invertido tal que disponer de ellos almomento de recuperar los objetos.

A diferencia de la similitud vectorial, las reglas de pre-ordenamiento dependen de cada aplicación, por loque no podemos proveer una regla por defecto. Sin embargo, cualquier implementación debe cumplir conla siguiente interfaz:

pub l i c i n t e r f a ce PreSor t {pub l i c L i s t <? extends Objec tRe su l t > work ( C o l l e c t i o n <? extends

Objec tRe su l t > cu r r e n tOb j e c t s ) ;}

A continuación ejempli�camos la implementación de esta interfaz con un extracto de los tests del frame-work:

@Indexab l epub l i c c l a s s HardAndSo f tRu l eEnt i t y {

@Search Id pub l i c f i n a l i n t i d ;@SearchSort pub l i c f i n a l i n t proxy1 ;@SearchSort pub l i c f i n a l f l o a t proxy2 ;@SearchSort pub l i c f i n a l S t r i n g proxy3 ;@Sea r chF i e l d pub l i c f i n a l S t r i n g a t t r i b u t e ;

pub l i c HardAndSo f tRu l eEnt i t y ( i n t id , S t r i n g a t t r i b u t e ,i n t proxy1 , f l o a t proxy2 , S t r i n g proxy3 )

{t h i s . i d = i d ;t h i s . a t t r i b u t e = a t t r i b u t e ;t h i s . p roxy1 = proxy1 ;t h i s . p roxy2 = proxy2 ;t h i s . p roxy3 = proxy3 ;

}}

pr i va te c l a s s HardAndSoftRule implements PreSor t {

pr i va te c l a s s Va lueHo lde r implements Comparable<ValueHolder> {pub l i c Ob j e c tRe su l t okr ;pub l i c f l o a t s c o r e ;

pub l i c Va lueHo lde r ( Ob j e c tRe su l t okr , f l o a t s c o r e ) {t h i s . okr = okr ; t h i s . s c o r e =s c o r e ;

}

@Over r idepub l i c i n t compareTo ( Va lueHo lde r o ) {

return F l o a t . compare ( sco r e , o . s c o r e ) ;}

}

pr i va te f i n a l F i e l d p r o x y1F i e l d , p r o x y 2F i e l d ;

pub l i c HardAndSoftRule ( ) throws Se cu r i t yE x c ep t i o n , NoSuchF i e l dExcep t i on{

t h i s . p r o x y 1F i e l d = HardAndSo f tRu l eEnt i t y . c l a s s . g e tD e c l a r e d F i e l d ( "proxy1 " ) ;

t h i s . p r o x y 2F i e l d = HardAndSo f tRu l eEnt i t y . c l a s s . g e tD e c l a r e d F i e l d ( "proxy2 " ) ;

}

protected f i n a l boolean ob j e c tAccep t ed ( Ob j e c tRe su l t o b j e c t ) {return HardAndSo f tRu l eEnt i t y . c l a s s . e q u a l s ( o b j e c t . getKey ( ) . g e tC l a z z

( ) ) ;}

@Over r ide

pub l i c L i s t <? extends Objec tRe su l t >work ( C o l l e c t i o n <? extends Objec tRe su l t > cu r r e n tOb j e c t s )

{i f ( c u r r e n tOb j e c t s==nu l l )

throw new I l l e g a lA r g umen tE x c e p t i o n ( "Can ' t work on a n u l l r e s u l ts e t " ) ;

L i s t <ValueHolder> t r e a t e d = new Ar r a yL i s t <ValueHolder >() ;

i n t proxy1Max = 0 ;

f o r ( I t e r a t o r <? extends Objec tRe su l t > i t e r a t o r = cu r r e n tOb j e c t s .i t e r a t o r ( ) ; i t e r a t o r . hasNext ( ) ; )

{Ob j e c tRe su l t okr = ( Ob j e c tRe su l t ) i t e r a t o r . nex t ( ) ;i f ( ! ob j e c tAccep t ed ( okr ) ) continue ;i t e r a t o r . remove ( ) ;t r e a t e d . add (new Va lueHo lde r ( okr , 0 f ) ) ;i n t proxy1Va lue = ( I n t e g e r ) okr . g e t S t o r e d F i e l d s ( ) . ge t (

p r o x y 1F i e l d ) ;i f ( proxy1Value>proxy1Max ) proxy1Max = proxy1Va lue ;

}

f o r ( Va lueHo lde r v a l u eHo l d e r : t r e a t e d ) {f l o a t proxy2Va lue =

( f l o a t ) v a l u eHo l d e r . okr . g e t S t o r e d F i e l d s ( ) . ge t ( p r o x y 2F i e l d ) /( f l o a t ) proxy1Max ;

v a l u eHo l d e r . s c o r e = proxy2Va lue ;}

C o l l e c t i o n s . s o r t ( t r e a t e d ) ;L i s t <Ob j ec tRe su l t > r e s u l t =

new Ar r a yL i s t <Ob j ec tRe su l t >( t r e a t e d . s i z e ( ) + cu r r e n tOb j e c t s .s i z e ( ) ) ;

f o r ( Va lueHo lde r v a l u eHo l d e r : t r e a t e d ) {r e s u l t . add ( v a l u eHo l d e r . okr ) ;

}

r e s u l t . addA l l ( c u r r e n tOb j e c t s ) ;

return r e s u l t ;}

}

@Testpub l i c void Boo l eanRe t r i e va lMaxRu l e ( ) throws Se cu r i t yE x c ep t i o n ,

NoSuchF i e l dExcep t i on{

HardAndSo f tRu l eEnt i t y e n t i t y 1 =new HardAndSo f tRu l eEnt i t y (0 , "Something to be r e t r i e v e d " , 1 , 50 .0 f

, "A" ) ;

HardAndSo f tRu l eEnt i t y e n t i t y 2 =new HardAndSo f tRu l eEnt i t y (1 , "Another t h i n g to be r e t r i e v e d " , 5 ,

20 .0 f , "A" ) ;

HardAndSo f tRu l eEnt i t y e n t i t y 3 =

new HardAndSo f tRu l eEnt i t y (2 , " I shou ld be r e t r i e v e d too ! " , 10 , 10 .0f , "A" ) ;

U t i l s . setupSampleMemoryIndex ( e n t i t y 1 , e n t i t y 2 , e n t i t y 3 ) ;

Boo leanSearch s e a r c h = new Boo leanSearch ( new Boo leanQueryPar se r ( "r e t r i e v e d " ) . getQuery ( ) , MemoryIndexReaderFactory . g e t I n s t a n c e ( ) ) ;

L i s t <? extends Objec tRe su l t > r e s u l t s = s ea r ch . s e a r c h (newHardAndSoftRule ( ) ) ;

A s s e r t . a s s e r t E q u a l s (2 , r e s u l t s . ge t (0 ) . getKey ( ) . g e t I d ( ) ) ;A s s e r t . a s s e r t E q u a l s (1 , r e s u l t s . ge t (1 ) . getKey ( ) . g e t I d ( ) ) ;A s s e r t . a s s e r t E q u a l s (0 , r e s u l t s . ge t (2 ) . getKey ( ) . g e t I d ( ) ) ;

}

@Testpub l i c void Vec to rRe t r i e v a lMaxRu l e ( ) throws Se cu r i t yE x c ep t i o n ,

NoSuchF i e l dExcep t i on{

HardAndSo f tRu l eEnt i t y e n t i t y 1 =new HardAndSo f tRu l eEnt i t y (0 , "Something to be r e t r i e v e d " , 1 , 50 .0 f

, "A" ) ;HardAndSo f tRu l eEnt i t y e n t i t y 2 =

new HardAndSo f tRu l eEnt i t y (1 , "Another t h i n g to be r e t r i e v e d " , 5 ,20 .0 f , "A" ) ;

HardAndSo f tRu l eEnt i t y e n t i t y 3 =new HardAndSo f tRu l eEnt i t y (2 , " I shou ld be r e t r i e v e d too ! " , 10 , 10 .0

f , "A" ) ;

U t i l s . setupSampleMemoryIndex ( e n t i t y 1 , e n t i t y 2 , e n t i t y 3 ) ;

Vec to rSea rch s e a r c h = new Vecto rSea rch (new Vecto rQue ryPa r s e r ( " r e t r i e v e d " ) . getQuery ( ) ,new MemoryIndexReader ( )

) ;

L i s t <? extends Objec tRe su l t > r e s u l t s = s ea r ch . s e a r c h (newHardAndSoftRule ( ) ) ;

A s s e r t . a s s e r t E q u a l s (2 , r e s u l t s . ge t (0 ) . getKey ( ) . g e t I d ( ) ) ;A s s e r t . a s s e r t E q u a l s (1 , r e s u l t s . ge t (1 ) . getKey ( ) . g e t I d ( ) ) ;A s s e r t . a s s e r t E q u a l s (0 , r e s u l t s . ge t (2 ) . getKey ( ) . g e t I d ( ) ) ;

}

Analicemos este extracto de código:

Los métodos BooleanRetrievalMaxRule y VectorRetrievalMaxRule muestran cómo una aplicación uti-lizaría las capacidades de pre-ordenamiento de nuestro framework. Estos métodos generan entidades,las indexan y luego las recuperan indicando su implementación de PreSort.

La clase HardAndSoft rule implementa dos criterios de negocio. El primero es una regla dura queindica que las entidades de tipo HardAndSoftEntity deben ubicarse primero que el resto. El segundocriterio es una regla blanda que busca el máximo global de un atributo de HardAndSoftEntity yestablece el puntaje como la división del otro atributo de la entidad sobre el máximo global.

Veamos que el usuario de las reglas de pre-ordenamiento sólo conoce el nombre de la clase queimplementa las reglas, siendo que no es necesario conocer nada mas acerca de cada regla. Esto esimportante porque separa al usuario experto que implementa una regla del usuario que tiene unconocimiento mas básico del framework.

Por último, es importante notar que el mismo conjunto de reglas fue aplicado en una búsquedavectorial y en una booleana, sin alterar en ninguna forma dichas reglas. Este es un claro ejemplode la independencia entre capas.

En el próximo apartado analizamos la operación de �ltrado, la cual completa el circulo de requerimientosbásicos para un uso real.

Filtrado

Al igual que permitimos un pre-ordenamiento de objetos recuperados, también debemos permitir laeliminación de objetos que no cumplan con requisitos de negocio. Esta eliminación o �ltrado es llamadapre-�ltrado y quienes realizan esta acción son los pre-�ltros.

Como ya hemos comentado en capítulos y secciones previas, el hecho de eliminar los objetos previamentea su valoración es especialmente importante en corpus cuyas consultas recuperan muchos objetos. Estose debe a que la operación de �ltrado es de orden O (n) mientras que la de ordenamiento es O (n log n).Es decir, si �ltramos antes de ordenar estamos mejorando el tiempo total de recuperación.

El �ltrado de objetos involucra las siguientes clases e interfaces:

FilterChain: interfaz cuyas implementaciones mantienen la lista de �ltros a aplicar y los ejecutan enel orden especi�cado.

ResultFilter: interfaz que implementan los pre-�ltros.

Presentemos la interfaz FilterChain:

pub l i c i n t e r f a ce F i l t e r C h a i n {pub l i c abst ract void a p p l y F i l t e r s ( C o l l e c t i o n <? extends Objec tRe su l t >

u n f i l t e r e d R e s u l t s ) ;}

y ResultFilter:

pub l i c i n t e r f a ce R e s u l t F i l t e r {pub l i c boolean i s F i l t e r e d ( Ob j e c tRe su l t f i l t r a b l e ) ;

}

A continuación vemos un ejemplo en el que implementamos esta interfaz para generar un pre-�ltro.

Ejemplo 3.3.5. El siguiente es ejemplo de un �ltro que elimina del conjunto de resultados las clases queno pertenecen a cierta jerarquía:

pub l i c c l a s s C l a s s F i l t e r implements R e s u l t F i l t e r {

pr i va te f i n a l Clas s <?> f i l t e r C l a z z ;pr i va te f i n a l boolean a l l owSub c l a s s e s ;

pub l i c C l a s s F i l t e r ( C la s s <?> f i l t e r C l a z z , boolean a l l owSub c l a s s e s ) {i f ( f i l t e r C l a z z==nu l l )throw new I l l e g a lA r g umen tE x c e p t i o n ( "The c l a z z to be used f o r

f i l t e r i n g can ' t be n u l l " ) ;

t h i s . f i l t e r C l a z z = f i l t e r C l a z z ;t h i s . a l l owSub c l a s s e s = a l l owSub c l a s s e s ;

}

pub l i c C l a s s F i l t e r ( C la s s <?> f i l t e r C l a z z ) {i f ( f i l t e r C l a z z==nu l l )


throw new I l l e g a lA r g umen tE x c e p t i o n ( "The c l a z z to be used f o rf i l t e r i n g can ' t be n u l l " ) ;

t h i s . f i l t e r C l a z z = f i l t e r C l a z z ;t h i s . a l l owSub c l a s s e s = true ;

}

pub l i c boolean i s F i l t e r e d ( Ob j e c tRe su l t f i l t r a b l e ) {i f ( a l l owSub c l a s s e s ) {return ! f i l t e r C l a z z . i sA s s i g nab l eF r om ( f i l t r a b l e . getKey ( ) . g e tC l a z z ( ) ) ;

} e l s e {return ! f i l t e r C l a z z . e qu a l s ( f i l t r a b l e . getKey ( ) . g e tC l a z z ( ) ) ;

}}

}

En este extracto de código el �ltro recibe el nombre de la clase que admite y un �ag para determinar siadmite la jerarquía completa o sólo la clase especi�cada.

Como ejercicio para entender mejor el diseño, supongamos que necesitamos implementar un �ltro deseguridad que elimina del conjunto de resultados los objetos a los que el operador actual no tiene acceso.Para esto podríamos implementar un �ltro similar al del ejemplo anterior, controlando que la clave delobjeto esté en la lista de objetos que ése operador puede leer.

Otro �n que se le puede dar a los �ltros es la implementación de la búsqueda facetada. Normalmente, paraimplementar la búsqueda facetada necesitamos contar cuántos objetos cumplen con el criterio de cadafaceta. Tanto esta operación como la de �ltrado se pueden realizar en simultaneo4, siendo que el �ltradotendrá efecto sobre el framework de IR y el recuento deberá ser consultado por el usuario del �ltro.

Para soportar tanto la búsqueda facetada como la normal, tenemos dos implementaciones de FilterChain:

ImmediateRemoveFilterChain: esta implementación elimina de la lista de resultados los objetos queno pasan por un �ltro, evitando que pasen por el resto de ellos.

LateRemoveFilterChain: si queremos que el framework de IR pase todos los objetos por todos los�ltros y luego los �ltre debemos agregar los �ltros a esta implementación. Debemos tener en cuentaque este tipo de FilterChain genera mayor trabajo sobre los últimos �ltros de la cadena.

Por último, queremos resaltar que al igual que ocurrió con los pre-ordenamientos, los pre-�ltros no de-penden del modelo de IR en el que trabajemos.

En este capítulo cumplimos el objetivo de analizar y diseñar una solución al problema de IR sobre objetosde un modelo de dominio, basándonos en los conceptos de recuperación de información, diseño de softwarey persistencia de objetos que estudiamos en el capítulo 2.

En el próximo capítulo ponemos a prueba nuestra solución implementando tres aplicaciones con necesi-dades de information retrieval, las cuales se deberán satisfacer a través de nuestra herramienta.

4Teniendo el cuidado de indicarle al framework de IR que no elimine los objetos hasta pasarlos por todos los �ltros, yaque de otra forma los últimos �ltros contarían menos objetos de los que realmente hay.

Capítulo 4

Experimentación

El objetivo de este capítulo es mostrar cómo probamos la adecuación de la solución propuesta en elcapítulo 3 al problema de IR sobre objetos.

La organización de este capítulo es la siguiente:

La sección 4.1 explica qué tipos de pruebas se diseñaron para veri�car la validez de la propuesta.

La sección 4.2 muestra las tres aplicaciones que utilizamos para validar nuestro framework y analizadistintos aspectos de la integración con estas aplicaciones.

Por último, la sección 4.3 desarrolla las pruebas comparativas cuantitativas y cualitativas.

4.1. Tipo de Pruebas Efectuadas

En esta sección explicaremos los distintos tipos de pruebas que se hicieron para veri�car la validez de lasolución propuesta en el capítulo 3.

Recordemos que el framework construido no es un sistema completo por sí mismo sino que da servicioa aplicaciones que necesitan capacidades de indexación y búsqueda. Esto requiere que veri�quemos lacapacidad del framework de adaptarse a distintos dominios y aplicaciones, característica que llamaremosportabilidad .

Para veri�car la portabilidad decidimos aplicar el primero de los patrones que propone Johnsonn parael desarrollo de un framework: comenzar implementando tres aplicaciones de referencia sobre las cualesluego probar la adecuación del framework (Roberts y Johnson, 1996). Estas aplicaciones pueden serprototipos, pero es importante que �hagan algo real�. Las tres aplicaciones construidas1 son PetClinic,Klink y KStore.

PetClinic es una aplicación �arti�cial� creada por los desarrolladores del framework Spring para mostrarel funcionamiento de �Spring Framework� y es un estándar de facto con el que distintos frameworks comoCompass, iBATIS, Hibernate y otros han mostrado su funcionamiento.

KStore y KLink son aplicaciones arti�ciales creadas especí�camente para este trabajo. La primera simulauna tienda online de productos generales y la segunda una red de contactos entre personas.

Dentro de estas pruebas con aplicaciones reales veri�camos el funcionamiento del framework con ORMscomo Hibernate e iBATIS.

Además de estas pruebas con aplicaciones de referencia, hicimos pruebas de calidad. Las pruebas decalidad buscan re�ejar que el sistema que se construyó es correcto. Para probar este punto, ejecutamosuna serie de tests unitarios que nos aseguran el correcto comportamiento de la herramienta ante los casosprobados y calculamos métricas de cobertura de código.

1A diferencia de Klink y KStore, PetClinic no fue construida para este trabajo sino que fue mayormente tomada de laimplementación que acompaña a Compass. En adelante, para facilitar la redacción, evitaremos marcar esta excepción enforma explícita.

129

130 CAPÍTULO 4. EXPERIMENTACIÓN

Las pruebas comparativas de rendimiento buscan comprobar si existe un comportamiento anómalo en elrendimiento del framework y comprender qué grado de competitividad tiene respecto de las herramientasdel estado del arte.

Por último, las pruebas comparativas cualitativas buscan encontrar las diferencias en la integración de losdistintos frameworks con las aplicaciones.

A continuación presentamos las pruebas con aplicaciones de referencia.

4.2. Pruebas con Aplicaciones de Referencia

4.2.1. PetClinic


PetClinic es una aplicación web que implementa el negocio de una veterinaria y es una aplicación dereferencia con la que frameworks como Spring muestran su funcionamiento.

Las entidades más importantes en este dominio son las mascotas (Pet), dueños (Owner), visitas (Visit),veterinarios (Vet) y la clínica misma (Clinic).

Para nuestro objetivo de probar la integración y adecuación del framework de IR sobre PetClinic, mantuvi-mos las tecnologías y casos de uso originales, agregando el mínimo conjunto de funcionalidades necesariaspara dar a la aplicación capacidades de IR.

PetClinic es una aplicación de tres capas (presentación, negocio y acceso a datos) construida con el patrónmodel-view-controller (MVC) a través de Spring MVC.

La capa de presentación de PetClinic produce vistas HTML utilizando tecnologías como Java ServerPages (JSP) , Java Standard Tag Libraries (JSTL) y Spring Web.

La capa de negocio se basa en objetos simples Java que colaboran entre si y aprovechan facilidades delframework Spring como inyección de dependencias.

La capa de acceso a datos está implementada sobre el ORM Hibernate, por lo que la integración conPetClinic sirvió para hacer una prueba real de integración con este ORM.

Casos de Uso y Modelo de Dominio

Los casos de uso de PetClinic son:

4.2. PRUEBAS CON APLICACIONES DE REFERENCIA 131

Figura 4.1: Casos de Uso en PetClinic.

Vamos a describir brevemente el propósito de cada caso de uso:

See Search Stats: permite conocer el número de objetos indexados por índice.

Search: representa la búsqueda de entidades utilizando el motor de IR a partir de una expresión delenguaje natural.

Find Owner: este caso de uso sirve para encontrar un dueño utilizando Hibernate, es decir, generandouna consulta a la base de datos sin la inteligencia del motor de búsqueda.

Manage Pet: permite agregar y modi�car la información de una mascota. La información ingresadase indexa en el motor de IR.

Add Visit: agrega una visita de una mascota a la clínica. La información ingresada se indexa en elmotor de IR.

Show Vets & Specialties: visualiza los veterinarios y sus especialidades.

Manage Pet Owners: permite agregar dueños así como modi�car sus datos. La información ingresadase indexa en el motor de IR.

Veamos un diagrama de clases de las entidades de dominio:


Figura 4.2: Entidades de dominio en PetClinic.

Para esta prueba seleccionamos un subconjunto de las clases de dominio y las anotamos para volverlasindexables. Respecto del diagrama de clases de la �gura (4.2), en la �gura (4.3) agregamos estereotipospara indicar cómo anotamos las clases para su indexación.

Figura 4.3: Entidades de dominio en PetClinic con información de indexación.

El diseño de clases de la �gura (4.2) es el original de PetClinic. Esto es, no se adaptó de ninguna formapara utilizar nuestro framework. El hecho de no requerir ningún tipo de modi�cación en el dominio marca


el éxito de uno de los criterios de diseño de un buen framework: independencia del modelo de dominio(ver subsección 2.2.2).

Dada la extensiva utilización de la subclasi�cación en el diseño de PetClinic, fue necesario utilizar yextender el framework de IR para cubrir casos complejos. Veamos algunos de ellos:

Person: junto a los objetos de tipo Pet, los objetos de esta clase son los principales objetivos deindexación en la aplicación. El identi�cador de esta clase se encuentra en la superclase (concreta-mente en la clase Entity) pero los objetos concretos a indexar serán principalmente de las subclasesOwner y Vet. Por otro lado, los atributos indexables se encuentran principalmente en la clase Person.Para soportar este mapeo, la anotación @Indexable de la clase Person indica la propiedad climbingTar-get=Entity.class, lo cual obliga a recorrer la jerarquía de clases en busca de atributos e identi�cadores.A su vez, la anotación @Indexable fue necesario indicar la propiedad makeSubclassesIndexable=truetal que las clases Owner y Vet sean indexadas automáticamente.

Owner: el principal desafío en mapear esta clase consiste en que casi todos sus atributos se ubicanen superclases, con excepción de una colección de mascotas, la cual también se indexa.

Pet: los objetos de esta clase no sólo son indexables por si mismos sino que contienen dos atributosindexables por separado: un Owner y un PetType. Particularmente, estos dos objetos referencian ala mascota, de forma tal que cuando se indexa una mascota, una posterior búsqueda de su dueñoretornará entre los resultados a la mascota.

El mapeo de todas las entidades se hizo sobre un mismo índice, es decir, no hubo necesidad de particionarlas entidades en índices distintos. Tampoco fue necesario utilizar características avanzadas del frameworkcomo �ltrado de objetos y ordenamientos ad hoc.

Funciones de IR en PetClinic

Sumado a los casos de uso originales de la aplicación (administración de dueños, mascotas y visitas), seagregó un caso de uso de búsqueda de entidades.

En términos visuales, se implementó un cuadro de texto donde ingresar la expresión de búsqueda (query)y una vista donde se presentan las entidades que coincidieron con la query (�gura 4.4).

Figura 4.4: Cuadro de búsqueda (arriba a la izquierda) y resultados de búsqueda (centro).

La búsqueda de entidades se hace mediante un modelo vectorial simple utilizando la familia de fórmulasTF-IDF. Dado que nuestra estrategia de indexación permite recuperar objetos de tipos heterogéneos,agregamos una pequeña capa con la inteligencia de dirigir los clics de cada tipo de entidad a su pantallacorrespondiente (las mascotas tienen una pantalla de edición distinta a los dueños).

Pruebas de Relevancia

A continuación describimos una prueba de relevancia para un pequeño conjunto de datos generados,analizando los resultados de ejecutar distintas queries sobre el sistema.

El conjunto de datos que se generó utilizando la interfaz web de PetClinic es el siguiente:


3 (tres) dueños: Julián Klas, Pedro Klas y Pedro de Mendoza.

2 (dos) mascotas: Fido (mascota de Pedro Klas) y Cuky (mascota de Julián Klas)

3 (tres) tipos de mascotas: Cat, Dog y Other

3 (dos) visitas de mascotas, una de Fido y dos de Cuky

Para analizar mejor los resultados del sistema de IR, hicimos una modi�cación a la interfaz de la �gura(4.4) que incluye el puntaje que obtuvo cada elemento recuperado (�gura 4.5).

Ejemplo 4.2.1. Ante la query Julián, los resultados son:

Figura 4.5: Resultados para la query Julián sobre el conjunto de datos de prueba.

Para analizar los puntajes debemos tener en cuenta:

se utiliza TF-IDF sobre los términos coincidentes entre la query y el ítem,

hay un total de N = 11 objetos indexados,

al indicarle al framework de IR que debe indexar las mascotas junto a su dueño, cualquier matchen el dueño también aplica a la mascota. Entonces df(Julian) = 2 porque se indexó tanto para eldueño como la mascota.

el único atributo coincidente entre la query y el corpus es el atributo �rstName de la clase Ownerpara el dueño Julián Klas.

Analicemos entonces el puntaje entre la query Julián y el objeto coincidente:

SimilitudTF−IDF (query, owner) = tf(Julian)× idf(Julian)

= tf(Julian)× log10N

df(Julian)= 1× log10

11

2∼= 0,7404

Para el caso del objeto la mascota el cálculo es idéntico sólo que la referencia a la identidad recuperadaapunta a la mascota.

Ejemplo 4.2.2. Veamos la respuesta del buscador y su análisis ante la query Pedro Klas:

Figura 4.6: Resultados para la query Pedro Klas sobre el mismo corpus del ejemplo previo.


A continuación analizamos el resultado posición por posición, teniendo en cuenta:

dfPEDRO = 3 porque se referencia desde los dueños Pedro de Mendoza, Pedro Klas y su mascotaFido.

dfKLAS = 4 porque se referencia desde los dueños Pedro Klas y Julián Klas, mas sus correspondientesmascotas Fido y Cuky.

Si analizamos el resultado posición por posición:

Resultado 1: es el elemento del corpus de mayor coincidencia y su ubicación se explica conceptual-mente porque es el único que contiene todos los términos de la query. Haciendo el cálculo formalde similitud:

SimilitudTF−IDF (query, owner) = tf(Pedro)× idf(Pedro) + tf(Klas)× idf(Klas)

= 1× log1011

3+ 1× log10

11

4= 1, 003604

Resultado 2: es idéntico al anterior porque el mapeo que hicimos de la clase Pet hizo indexar a sudueño Pedro Klas referenciando a la mascota Fido. Es decir, la similitud es igual a la anterior sobreel Owner.

Resultado 3: naturalmente este resultado aparece por la coincidencia parcial en el término Pedro perovemos que tiene un puntaje sensiblemente inferior a los primeros dos resultados por la coincidenciaen un único término. Calculando la similitud:

SimilitudTF−IDF (query, owner) = tf(Pedro)× idf(Pedro) = 1× log1011

3= 0, 564271

Resultado 4: nuevamente tenemos coincidencia parcial, pero ahora en el término Klas. Aquí vemoscómo la familia de formulas TF-IDF da menor prioridad a los términos de poca selectividad de doc-umentos. A diferencia del término Pedro, el cual se asociaba a 3 objetos, el término Klas referenciaa 4 objetos. Esto hace que el término Klas tenga menor relevancia que Pedro, re�ejándose en lasimilitud:

SimilitudTF−IDF (query, owner) = tf(Klas)× idf(Klas) = 1× log1011

4= 0, 439333

Resultado 5: al igual que con el segundo resultado, la mascota Cuky obtiene la misma similitud quesu dueño Julian Klas de la posición anterior.

Otras características de la solución

La interconexión entre componentes como el ORM, el motor de IR y PetClinic se hizo utilizando la objectfactory del framework Spring.

Para re�ejar los eventos CUD sobre el índice invertido utilizamos nuestro plugin de Hibernate, el cualse conectó al sistema de eventos de Hibernate Core mediante Spring. El interceptor de eventos fuecon�gurado para recibir los eventos luego de que éstos se ejecutan en Hibernate.

Como adelantamos al inicio de este apartado, tanto el pipeline de indexación como el tipo de índice(memoria, Berkeley u otro) son con�gurables mediante Spring. Veamos un fragmento del XML queusamos para con�gurar el uso del índice en memoria y el pipeline de indexación por defecto:

<bean i d=" Ob j e c t S e a r c hH i b e r n a t e L i s t e n e r " c l a s s="com . j k l a s . s e a r c h .i n t e r c e p t o r s . h i b e r n a t e . H i b e r n a t e E v e n t I n t e r c e p t o r ">

<con s t r u c t o r−arg r e f=" S e a r c h I n t e r c e p t o r "/></bean>

<bean i d=" S e a r c h I n t e r c e p t o r " c l a s s="com . j k l a s . s e a r c h . i n t e r c e p t o r s .S e a r c h I n t e r c e p t o r ">

<con s t r u c t o r−arg r e f=" On l i n e I n d e x e r "/></bean>

<bean i d=" On l i n e I n d e x e r " c l a s s="com . j k l a s . s e a r c h . i n d e x e r . o n l i n e .On l i n e I n d e x e r ">

<con s t r u c t o r−arg r e f=" D e f a u l t I n d e x e r S e r v i c e "/></bean>

<bean i d=" D e f a u l t I n d e x e r S e r v i c e " c l a s s="com . j k l a s . s e a r c h . i n d e x e r .D e f a u l t I n d e x e r S e r v i c e ">

<con s t r u c t o r−arg r e f=" D e f a u l t I n d e x i n g P i p e l i n e "/><con s t r u c t o r−arg r e f=" I nd e xWr i t e r F a c t o r y "/>

</bean>

<bean i d=" D e f a u l t I n d e x i n g P i p e l i n e " c l a s s="com . j k l a s . s e a r c h . i n d e x e r .p i p e l i n e . D e f a u l t I n d e x i n gP i p e l i n e "/>

<bean i d=" I nd e xWr i t e r F a c t o r y " c l a s s="com . j k l a s . s e a r c h . i nd ex . memory .Memory IndexWr i te rFactory "/>

Comentemos brevemente la con�guración de estos beans 2:

IndexWriterFactory: selecciona el backend/plugin con el que se escribe en el índice invertido. Eneste caso se eligió el índice en memoria que viene incluido dentro del framework. Veamos que lainyección de dependencias permite variar la implementación del backend de índices invertidos deforma transparente a PetClinic, sin modi�car el código de negocio.

DefaultIndexerService: se ocupa de orquestar el procesamiento de los objetos para su indexación yla posterior escritura en el índice. Es preciso notar que estamos inyectando dos dependencias ensu constructor: el backend de escritura en el índice y el pipeline de procesamiento de objetos. Estainyección de dependencias nos permite variar sustancialmente el comportamiento del framework sincambiar una sola línea de código en el framework o PetClinic.

ObjectSearchHibernateListener: este bean es inyectado en otro bean de Hibernate y con�gura lainterceptación de eventos por parte del framework de IR.

OnlineIndexer: este bean con�gura el indexador online que analizamos y diseñamos en las secciones(3.1.3) y (3.3.4). Editando este bean podemos hacer que nuestro framework utilice indexación online,semi-online u o�ine sin tener otra consideración de código sobre la aplicación.

Como acabamos de ver, el medio de almacenamiento del índice invertido se puede variar por con�guraciónutilizando la object factory de Spring. De la misma forma podemos intercambiar el tipo de indexaciónonline por el semi-online o el o�ine.

Dado que esta aplicación fue la primera con la que probamos la integración del framework de IR, sebuscó reducir la complejidad inicial para centrarse en las funcionalidades de IR y en eventuales ajustes alframework. Siguiendo este criterio, las pruebas las desarrollamos utilizando indexación online sobre uníndice en memoria. Si bien el índice en memoria es volatil y sólo se utiliza para pruebas, en las próximasaplicaciones de ejemplo sí utilizaremos un índice persistente.

2En este contexto, un bean es un objeto Java que instanciamos utilizando la Object Factory de Spring y el cual se utilizaen un contexto de inyección de dependencias.


4.2.2. Klink


Klink es una aplicación web arti�cial creada para esta tesis con el objetivo de probar la adecuación delframework a distintos escenarios, siguiendo el patrón propuesto por Johnson (ver sección 4.1).

Klink implementa una red social básica en la que las personas pueden agregar contactos libremente. Losconceptos más importantes en Klink son: el usuario como �miembro� del sitio (Person), los contactos (tam-bién de tipo Person), el per�l (atributos de la clase Person), la compañía para la que trabaja (Company)y el país en el que esta reside (Country).

Al igual que hicimos con PetClinic, esta aplicación se construye utilizando Spring MVC como frameworkestructural y JSP/JSTL como framework de presentación. Se utilizó el framework Spring Core parainyectar dependencias en los objetos y con�gurar la indexación.

La capa de negocio es elemental y se ocupa principalmente de la comunicación con la capa de acceso adatos implementada con Apache iBATIS.

El hecho de utilizar iBATIS para la capa de acceso a datos no es accidental sino que fue elegida para probarla adecuación del framework a distintos entornos de persistencia (recordemos que PetClinic utilizabaHibernate).


Las funcionalidades de Klink se pueden ver fácilmente en este diagrama de casos de uso:

Figura 4.7: Casos de uso en Klink.

Expliquemos brevemente este diagrama:

Unregistered User: es un usuario no registrado en el sistema y por tanto sólo puede ejecutar el casode uso Signup3.

3En rigor, también puede ejecutar el caso de uso Login, el cual no le permitirá acceder al sistema por no estar registrado.Preferimos no mostrar esta relación en el diagrama porque se presta a confusión.


• Signup: este caso de uso permite al usuario formar parte de la red de contactos y requiere elingreso de ciertos datos en el sistema. Luego de ejecutarse el caso de uso, el usuario deja deestar representado por el actor unregistered user para verse representado por el registered user.

Registered User: son los usuarios que ejecutaron con éxito el caso de de uso Signup.

• Login: mediante una contraseña y una dirección de correo electrónico, el caso de uso validaque el usuario que lo ejecuta sea un registered user. En caso de que el usuario demuestre serlo,el sistema le permite ejecutar los casos de uso Search Friends, Add Friends, View Home Page yLogout. En caso de no veri�carse que el usuario sea un registered user, se indica al usuario querevise los datos ingresados o que ejecute el caso de uso Signup.

• Search Friends: este caso de uso permite al usuario encontrar personas a partir de una expresiónde lenguaje natural, utilizando el motor de búsqueda. Entre los resultados de la búsquedapueden haber tanto personas relacionadas con el usuario como personas no relacionadas. Enbase al listado resultante de este caso de uso, el usuario puede iniciar el caso de uso Add Friendsobre las personas no relacionadas con él.

• Add Friend: este caso de uso agrega una relación entre el usuario y la persona seleccionada enel caso de uso Search Friends.

• View Home Page: el usuario inicia este caso de uso para visualizar sus datos propios. Este casode uso permite no sólo ver la página de inicio (Home) sino una pantalla de per�l (Pro�le).

• Logout: se ejecuta cuando el usuario desea dejar de usar el sistema. Luego de ejecutar estecaso de uso, no será posible ejecutar otro caso de uso que no sea el de Login (luego del cual sevolverá a permitir ejecutar el resto de los casos de uso).

El diagrama de clases de Klink es el siguiente:

Figura 4.8: Diagrama de clases en Klink.

Marcando con estereotipos las anotaciones sobre las clases:


Figura 4.9: Diagrama de clases y anotaciones en Klink.

Hagamos una breve descripción acerca de estas entidades:

Person: representan a los usuarios del sistema como entes sociales que se interconectan entre sí.Estos objetos se indexan por sus datos de contacto: email, �rstName y lastName.

Los elementos de la colección contacts se indexan referenciando tanto al objeto que contiene lacolección (contenedor) como al objeto que está dentro de la colección (contenido). Con este mapeo,una persona se indexa referenciando a todos sus contactos y ellos a su vez referencian a éste.

Por último, las personas están asociadas a exactamente un Company, la cual se indexa a referen-ciando a su contenedor (objetos de tipo Person). Esto permite buscar una compañía y recuperarsus empleados.

Company: esta entidad representa una empresa donde trabajan personas y, como vimos, se indexade forma tal de referenciar a todas las personas que trabajan en esa compañía.

Country: representa la información de nacionalidad en el sistema. Es un atributo de Company y nose indexa.

A continuación presentamos algunas capturas de pantalla que muestran partes de los �ujos correspondi-entes a los casos de uso de la �gura (4.7).

Comencemos con Login y Signup:


Figura 4.10: Login. El primer paso en el sistema es la pantalla de login, desde donde podemos identi�carnoso agregarnos como usuarios registrados.

Figura 4.11: Signup. Creamos un usuario en el sistema, el cual se indexará por sus datos de contacto ypor la compañía a la que pertenece.

Veamos ahora los �ujos del caso de uso View Home Page:


Figura 4.12: Sección Home. Esta sección nos muestra un mensaje de bienvenida y, eventualmente, mensajesde otros usuarios o noti�caciones (correo nuevo, invitaciones, etc).

Figura 4.13: Sección Pro�le. Vemos la información pública hacia el resto de la comunidad.

Ahora podemos buscar a un Juan que recordamos que trabaja en FIUBA utilizando el caso de uso SearchFriends:


Figura 4.14: Search Friends. Ingresamos la query juan �uba y obtenemos los resultados priorizados por elmodelo vectorial.

utilizando los resultados de la �gura anterior, hacemos clic en el contacto Juan Ale y seguimos el �ujo deAdd Friend:

Figura 4.15: Add Friend y Search. Utilizando los resultados de la búsqueda anterior agregamos a Juan Alecomo contacto de Julian Klas.


Figura 4.16: Add Friend y Search. Repetimos la búsqueda original y visualizamos que Juan Ale ya escontacto nuestro.

En el próximo apartado describimos en mayor detalle las funciones de IR de esta aplicación.

Funciones de IR en Klink

En esta aplicación utilizamos el framework de IR para implementar el caso de uso Search Friends. Estecaso de uso es central ya que es el punto de acceso para la construcción de la red de contactos (caso deuso Add Friend).

A diferencia de PetClinic, el modelo de Klink es muy simple. Las clases indexables en el dominio de estaaplicación son las personas y compañías (instancias respectivas de Person y Company).

El mapeo que hicimos de la entidad Person nos permite recuperarlas según su correo electrónico, nombre,apellido y contactos. En el caso de las compañías, la recuperación se da por el nombre de ésta.

En todos los casos es necesario establecer un identi�cador de las entidades ya que la hidratación de losobjetos se efectúa con posterioridad a la tarea de IR.

Los puntos clave que marcan el éxito de este ejemplo fueron:

variación del modelo de dominio sin impactar en el framework (portabilidad)

utilización del plugin para iBATIS

utilización del plugin de indexación Berkeley

En el próximo apartado hacemos algunos comentarios tecnológicos sobre este ejemplo/caso de estudio.


Al igual que en el caso anterior (PetClinic), utilizamos Spring y su object factory para la con�guracióne interconexión de componentes.

Los eventos CUD se re�ejaron sobre el índice mediante el plugin para iBATIS provisto por nuestroframework, el cual interceptó los eventos de persistencia de manera similar al plugin de Hibernate queutilizamos en PetClinic. La base de datos utilizada para almacenamiento de datos de aplicación fueHSQLDB (HyperSQL, 2008).

Al presentar PetClinic mencionamos que utilizamos el índice en memoria para acotar la complejidad ala indexación y recuperación. En Klink movimos el foco de la complejidad para abarcar otros ángulostecnológicos del problema. Este movimiento se materializó en la utilización del índice invertido en discoBerkeley.

Respecto de PetClinic, la utilización del backend en disco Berkeley sólo requirió cambios de con�gu-ración en Spring, lo cual probó la transparencia con la que el framework permite elegir el backend dealmacenamiento del índice invertido.

Para generar el conjunto de datos de prueba se obtuvieron tablas de nombres de personas del repositoriopúblico Freebase (Metaweb Techonologies, 2010). Estos datos se importaron mediante un proceso index-ador o�ine. El indexador lee los datos desde un archivo de texto plano y genera objetos de tipo Person,los cuales se persistieron con iBATIS y se indexaron automáticamente por el plugin de iBATIS. Dada lasimplicidad del proceso indexador, concluimos que no tiene sentido proveer un indexador genérico desdeel framework.

Además, tenemos un proceso reindexador que lee todos los registros de la base de datos y los indexa ennuestro framework. Veamos el código fuente de este proceso:

pub l i c c l a s s Fu l l R e i n d e x {

pub l i c s t a t i c void main ( S t r i n g [ ] a r g s ) throws IOExcept ion ,SearchEng ineMappingExcept ion , I nd e xOb j e c tEx c ep t i o n {

S e a r c hL i b r a r y . conf igureAndMap ( Person . c l a s s ) ;

new Be r k e l e yG l o b a l P r o p e r t y E d i t o r ( ) . s e tBa s eD i r ( " i d x /" ) ;

B e r k e l e y I n d e x . r e n ewA l l I n d e x e s ( ) ;

Log l o g = LogFactory . getLog ( Fu l l R e i n d e x . c l a s s ) ;

l o g . i n f o ( " S t a r t i n g Person . c l a s s r e i n d e x . . . " ) ;

S t r i n g r e s o u r c e = "com/ k l i n k / Con f i g u r a t i o n . xml" ;Re sou rce s . s e tD e f a u l t C l a s s L o a d e r ( I B a t i s H e l p e r . c l a s s . g e tC l a s s Load e r ( ) ) ;Reader r e a d e r = Resou r ce s . ge tResourceAsReade r ( r e s o u r c e ) ;

PersonDao personDao = new PersonDao (new Sq l S e s s i o n F a c t o r yBu i l d e r ( ) .b u i l d ( r e a d e r ) . openSe s s i on ( ) ) ;

L i s t <Person> p e r s o n L i s t = personDao . r e t r i e v e A l l ( ) ;

new De f a u l t I n d e x e r S e r v i c e (new De f a u l t I n d e x i n g P i p e l i n e ( ) ,B e r k e l e y I n d e xWr i t e r F a c t o r y . g e t I n s t a n c e ( ) ) . bu l kC r e a t e ( p e r s o n L i s t ) ;

l o g . i n f o ( "Person . c l a s s r e i n d e x f i n i s h e d . . . " ) ;

}}

Notemos del anterior fragmento de código que sólo 4 líneas están relacionadas al motor de búsqueda.Esto muestra el objetivo de generar procesos simples de indexación y reindexación.


4.2.3. KStore


La última aplicación con la que probamos la adecuación del framework se llama KStore.

KStore es una tienda virtual cuyo caso de uso principal es la búsqueda de productos. Es decir, en estaaplicación las tareas de IR están en el centro del problema.

Las entidades principales son los productos a la venta (Item), las categorías bajo las que se agrupan losítems (Category) y los sitios en los que opera KStore (Site).

Una característica particular de KStore es la indexación de anuncios publicitarios (entidad Advertising),la cual permite mostrar anuncios contextuales según la búsqueda que el usuario está llevando adelante.

Los frameworks que colaboran para implementar la arquitectura MVC, las vistas HTML e inversión delcontrol son principalmente: Spring, JSP y las tecnologías que hemos comentado en los ejemplos previos(ver subsecciones 4.2.1 y 4.2.3).


Veamos los casos de uso de KStore y una breve descripción de éstos:

Figura 4.17: Casos de uso en KStore.

Buscar Productos: mediante una expresión de texto libre, el usuario indica el/los productos de interésy el sistema presenta un listado paginado de resultados. Este caso de uso puede comenzarse desdecualquier pantalla del sitio utilizando la barra de búsqueda y es particularmente importante por serel punto de entrada desde el cual se inician el resto de los casos de uso.

Agregar/Quitar Producto en Carrito de Compras: consiste en permitir al usuario administrar losproductos que buscó en el transcurso del caso de uso Buscar Productos, llevando cuenta de cuálesson de su interés. Para utilizar el caso de uso Comprar Productos en Carrito es necesario haberiniciado este caso de uso.

Comprar Productos en Carrito: este caso de uso consiste en adición de los productos agregados alcarrito y la compra mediante una tarjeta de crédito simulada. Este paso requiere que el usuariodemuestre ser un humano y no un robot mediante un CAPTCHA (Ahn et al., 2004).


Ver Enlace Patrocinado: este caso se inicia cuando el cliente selecciona uno de los enlaces patrocina-dos. Comúnmente el resultado de este caso es la aparición de una pantalla promocional o la salidade este sistema hacia otro.

El diagrama de clases de KStore es el siguiente:

Figura 4.18: Diagrama de clases de KStore.

nuevamente utilizamos estereotipos para mostrar las propiedades de indexación:

Figura 4.19: Clases de KStore con estereotipos de indexación.

Hagamos una descripción breve de estas entidades y sus relaciones:

Item: representa los productos pasibles de ser comprados por los clientes. En este ejemplo indexamossólo el campo title, el cual nos da su�ciente información para la mayoría de las búsquedas. A efectosde mantener la simplicidad del modelo, omitimos almacenar atributos como el �stock�, el cual no esrequerido en nuestros casos de uso pero bien podría usarse en un sistema real.


Category: esta entidad representa un concepto de dominio bajo el cual se agrupan items. Algunosobjetos que podrían ser instancias de esta clase: �Electrónica�, �GPS�, etc. En este ejemplo noslimitamos a indexar los títulos de las categorías, lo cual da la posibilidad de construir un índice deitems por categorías.

Advertising: es una publicidad que se presenta en el contexto del caso de uso Buscar Productos. Estosobjetos son recuperados por el motor de búsqueda utilizando un proceso similar al de búsqueda deitems con el �n de proveer al cliente una alternativa relevante a los resultados de búsqueda que se lepresentan. Los objetos advertising son indexados en índices separados de los items para evitar queparticipen del proceso de recuperación y valoración de los items.

Site: representa una instancia particular del sistema KStore para una zona determinada. Normal-mente un site corresponde a un dominio web y todos los objetos que discutimos previamente seagruparán dentro de un sitio particular. El hecho de contar con un objeto site nos permite for-malizar conocimiento como moneda local, dominios web, tasa de cambio respecto de monedas dereferencia, etc.

Veamos algunas pantallas que muestran el �ujo de compra en KStore:

Figura 4.20: Pantalla principal de búsqueda de KStore.


Figura 4.21: Resultados para la query apple ipod nano blue. En la columna central tenemos los resultadosde búsqueda, a la izquierda los anuncios contextuales, a la derecha el carrito de compras y en la parteinferior el paginador.

Figura 4.22: Los resultados se agregan dinámicamente al carrito de compras, el cual luego pasa al procesode pago (checkout).


Figura 4.23: Con�rmación de la compra. El formulario de pago requiere que ingresemos los datos de latarjeta de crédito y un código veri�cador para evitar usos fraudulentos. En la parte inferior se encuentrala lista de productos que estamos comprando junto al monto total a pagar.

Figura 4.24: Pago completado. El sistema con�rma la operación y presenta un botón para continuarutilizando el sistema desde la página de inicio.


Funciones de IR en KStore

Las tareas de recuperación de información son centrales a KStore ya que soportan el modelo de negociode la tienda en línea tanto en cuanto a compra de productos como respecto de la publicidad.

El mapeo de entidades no presentó nuevos desafíos ya que es relativamente simple. Sin embargo, fueconveniente separar los anuncios y los items en índices diferentes, tal de aislar la recuperación de unos yotros. Esto no solo permitió un código más simple, sino que facilita la paralelización de la búsqueda deanuncios e items en forma concurrente.

Para este ejemplo utilizamos el plugin de indexación para Hibernate y el de índices en disco Berkeley. Elprimero de estos plugins fue necesario ya que el modelo de dominio se indexaba utilizando Hibernate yfue natural replicar los eventos CUD utilizando este plugin. El plugin Berkeley fue utilizado para contarcon índices persistentes. A su vez, nuestro indexador o�ine requiere un índice persistente para que laaplicación pueda consultar el índice invertido.


En KStore tuvimos la intención de generar un corpus similar al de un sitio web real de tamaño pequeño-mediano. Para esto �jamos como objetivo generar corpus de volumen no menor a los 5.000 productos(items).

Para generar este corpus se construyó un software ad-hoc (robot) cuya tarea fue extraer información realde sitios comerciales y utilizar dicha información en la generación del corpus. El robot construido efectuópedidos REST (Fielding, 2000) a una API pública del sitio web Shopping.com, desde el cual se extrajeronitems con sus correspondientes categorías.

El robot recibió un archivo de texto plano con 100 palabras clave ingresadas por el autor y, por cada unade ellas, efectuó un llamado a la API REST de búsqueda por palabra de Shopping.com.

Este proceso produjo como resultado un archivo de texto plano con títulos, descripciones, categorías yprecio en dólares estadounidenses para 6149 items. A partir de dichos items se construyó el corpus decategorías, el cual se compone de 93 categorías distintas.

Por último, se escribió un proceso que lee el archivo producido por el robot y almacena dichas entidadesen Hibernate. Los objetos almacenados en Hibernate se indexaron transparentemente por medio de losplugins para Hibernate y BerkeleyDB provistos en nuestro framework (y con�gurados mediante inyecciónde dependencias desde Spring).

En resumen, el proceso de generación del corpus comprendió:

1. Confección de lista de keywords de búsqueda para Shopping.com

2. Ejecución del robot

3. Ejecución del proceso indexador

Con posterioridad a la construcción de la búsqueda de items surgió la propuesta de agregar como adita-mento funcional la indexación y recuperación de anuncios publicitarios. El hecho de agregar los anunciospublicitarios con el sistema �en funcionamiento� sólo requirió replicar el proceso indexador variando lalectura del archivo de texto del cual provenían los items para que se lean los títulos, subtítulos y enlacescorrespondientes a los anuncios.

La posibilidad de particionar los índices por entidad permitió separar la indexación de anuncios en uníndice independiente, de forma tal que la búsqueda de estas entidades no inter�rió con la búsqueda deitems.

A diferencia del corpus de items, el de anuncios se construyó en forma totalmente manual por lo quecuenta pocos anuncios en relación a la cantidad de items.

4.3. PRUEBAS DE CALIDAD Y RENDIMIENTO 151

Notas acerca de Experimentación y Refactorización

La experimentación en situaciones de uso real produjeron una iteración sobre el software construido,aportando una mejora signi�cativa al software entregado con esta tesis. En este apartado hacemos algunoscomentarios puramente experimentales acerca del aprendizaje adquirido en el desarrollo de estas tresaplicaciones de ejemplo.

La primera aproximación a integrar las aplicaciones con el framework de IR y sus dependencias fue la deubicar manualmente todos los archivos Java (JAR) en una ubicación donde el cargador de clases Javapueda encontrarlos. Este mecanismo de administración de dependencias es efectivo pero poco mantenibleya que se producen con�ictos de versiones, redundancias y esfuerzos de mantenimiento innecesarios.

Para mejorar la administración de estos proyectos se adoptó un software robusto para administración deproyectos: Apache Maven (Apache Foundation, 2010).

La adopción de Maven permitió:

que las tres aplicaciones puedan incluir el framework de IR, sus plugins y dependencias automáti-camente con unas pocas líneas de con�guración XML,

delegar en Maven la resolución de dependencias de cada módulo,

generar lanzamientos (releases) con automatización de casos de prueba,

simpli�car la administración de los proyectos.

La adopción de Maven abrió la posibilidad de desacoplar partes del framework, cambiando una estructuramonolítica en la cual un único módulo �hace todo� por una arquitectura de plugins.

Este cambio de estructura consistió en partir el framework originalmente monolítico en:

un módulo básico de IR (core),

plugin de interacción con Hibernate,

plugin de interacción con iBATIS,

plugin para backend de índices en BerkeleyDB,

plugin de indexación distribuida o�ine con JMS.

Esta descripción acerca de la iteración que hicimos sobre la administración del proyecto es ejemplo delacierto en construir distintas aplicaciones reales donde probar el framework.

4.3. Pruebas de Calidad y Rendimiento

En esta sección vamos a explicar cómo se probó que el software construido es correcto y cuál es surendimiento de indexación y recuperación de objetos, estableciendo algunas comparaciones con frame-works similares.

La subsección 4.3.1 desarrolla las pruebas de calidad. La subsección 4.3.2 muestra las pruebas de rendimien-to y las compara con lo obtenido en frameworks similares.

4.3.1. Pruebas de Calidad

El framework de IR se construyó siguiendo la técnica de programación conocida como Test Driven De-velopment (Beck, 2002). Esta técnica tiene como metodología de trabajo construir el sistema completoa partir de pruebas unitarias. La metodología de TDD produce naturalmente un diseño desacoplado y,dado que sólo se desarrolla lo que se está probando, los tests resultantes cubren un alto porcentaje delcódigo.


Las pruebas unitarias tienen por objetivo probar el funcionamiento aislado de una funcionalidad. En estasubsección explicamos algunos reportes y métricas que nos indican el grado de certeza que podemos teneracerca del correcto funcionamiento del framework.

La distribución de pruebas por módulo del framework es la siguiente (los valores que siguen correspondenal release 1.0 del framework4):

Core Search Engine: 192 tests

Plugins Berkeley, Hibernate, iBATIS y JMS: 27 tests

Sumando estos números, el release pasa con éxito 219 tests.

Existen varias métricas para evaluar cuán representativos son los tests. Una de las métricas básicas másutilizadas en la evaluación de los tests es la cobertura de código (o simplemente cobertura). La coberturamide qué cantidad/porcentaje de líneas de código son ejecutadas por los tests.

Cuando analizamos la cobertura, debemos tener cuidado para no llegar a falsas conclusiones. Por ejemplo,el siguiente par test/programa tiene una cobertura del 100% pero sin embargo falla en todos los casosexcepto el probado:

pub l i c c l a s s BadMathTest ( ) {

// t e s t que cubre e l 100% de l cód igo cub r i e ndo s ó l o e l caso p a r t i c u l a rque pasa e l t e s t

@Testpub l i c void e x p on en t i a l F un c t i o nTe s t ( ) {

A s s e r t . a s s e r t E q u a l s (1 , new BadMath ( ) . e x p o n e n t i a l ( 0 ) ) ;}

}

// mal a j u s t e de f ( x )=e^x por g ( x )=x+1pub l i c c l a s s BadMath ( ) {

pub l i c i n t e x p o n e n t i a l ( i n t x ) {return x+1;

}}

por otro lado, las pruebas de este par test/progama son mejores que las del caso anterior, aunque logramenor cobertura:

pub l i c c l a s s GoodMathTest ( ) {

// un t e s t mejor pe ro que cubre poco cód igo@Testpub l i c void e x p on en t i a l F un c t i o nTe s t ( ) {

A s s e r t . a s s e r t E q u a l s ( −1.0 f , new GoodMath ( ) . l o g ( 0 . 1 d ) ) ;A s s e r t . a s s e r t E q u a l s ( 0 . 0 f , new GoodMath ( ) . l o g ( 1 . 0 d ) ) ;A s s e r t . a s s e r t E q u a l s ( 1 . 0 f , new GoodMath ( ) . l o g ( 10 . 0 d ) ) ;A s s e r t . a s s e r t E q u a l s ( 10 .0F , new GoodMath ( ) . l o g (100 . 0 d ) ) ;

}}

// buen a j u s t e por t a y l o r , pe ro con chequeos que ba jan l a c ob e r t u r apub l i c c l a s s GoodMath ( ) {

pub l i c f l o a t l o g ( Double x ) {

i f ( x==nu l l ) {throw new I l l e g a lA r g umen tE x c e p t i o n ( "Can ' t c a l c u l a t e l o g o f n u l l " ) ;

}

4Los releases se etiquetan en el repositorio de código para poder ser reconstruidos con facilidad

i f ( x <= 0 .0 d ) {throw new I l l e g a lA r g umen tE x c e p t i o n ( "Can ' t c a l c u l a t e l o g o f n e g a t i v e

numbers " ) ;}

// d e s a r r o l l o en s e r i e de t a y l o rreturn t a y l o r S e r i e s F o r L o g ( x ) ;

}}

La caída en la cobertura se da porque las excepciones no son cubiertas por los tests. Esto no quiere decirque los tests no deban provocar excepciones, sino que el sólo hecho de tener una buena cobertura noes su�ciente para tener buenos tests. Habiendo explicado esto, podemos continuar con la cobertura denuestro framework.

Para el cálculo de cobertura utilizamos un plugin de Maven llamado Cobertura (Doliner, 2006) y anal-izamos los reportes para el módulo core del framework.

La ejecución inicial de Cobertura nos indica una métrica del 54% de cobertura (1925/3559 líneas decódigo).

Dado que inicialmente este número pareció bajo, analizamos los reportes y encontramos:

Muchísimas líneas de código que no son cubiertas por los tests se encuentran en los stemmers. Dadoque éstos se asumen correctos por construcción (son código auto generado utilizando Snowball),deberíamos excluirlos de nuestros cálculos.

Existen muchas excepciones no lanzadas durante los tests que corresponden a parámetros nulos,erróneos o excepciones lanzadas por la JVM como producto de operaciones, por ejemplo, de re�ex-ión.

En muchas clases se auto generaron los métodos hashCode() e equals() mediante el IDE Eclipse.Estos métodos generalmente no son alcanzados en su totalidad por los tests, ya que su estructurasuele hacer que retornen rápidamente sin ejecutar todas sus líneas. Además, asumiendo que Eclipsefue probado correctamente, no es necesario que los test alcancen estos métodos ya que se suponencorrectos.

Los métodos toString() suelen ser triviales pero no suelen ser alcanzados por los tests.

En algunos casos se presentan versiones sobrecargadas de un método simplemente para adoptar unvalor por defecto (haciendo que un método invoque al otro). Este tipo de prácticas tampoco suelenprobarse por su trivialidad.

Si eliminamos el aporte de los stemmers, la cobertura asciende a 65% (1641/2515 líneas de código).

Ahora, si asumiéramos que los métodos hashCode(), equals(), excepciones y toString de las 140 clasesintervinientes aportan un 15% de código adicional, la cobertura se ubicaría alrededor del 80%, lo cualparece ser una buena marca para un prototipo como el que hemos construido.

Además de la cobertura, existen muchas otras métricas asociadas a la complejidad del código, las cualesexceden el tratamiento que le queremos dar al tema.

4.3.2. Pruebas de Rendimiento

En esta subsección vamos a exponer los resultados de algunas pruebas de rendimiento que efectuamossobre nuestro software.

Si bien el foco de este trabajo no está en que la versión actual del framework tenga un rendimiento superiora las herramientas del estado del arte, queremos veri�car que no existen comportamientos anómalos. Estoscomportamientos anómalos podrían ser, por ejemplo, que el crecimiento lineal en el número de objetos aindexar incremente el tiempo de indexación o bien el uso de memoria en forma no lineal.


Además de detectar comportamientos anómalos, haremos un estudio acerca de dónde se encuentran loscuellos de botella en la indexación y recuperación, a efectos de saber dónde tenemos oportunidades deoptimización.

Descripción del Laboratorio de Pruebas

Todas las pruebas se realizaron en un equipo con la siguiente con�guración:

procesador de doble núcleo Intel Core 2 Duo de 1.83 GHz

2 GB RAM

Ubuntu 10.04 LTS, kernel 2.6.32-23-generic

Sun Java HotSpot(TM) Server VM (versión 1.6.0_21)

Prueba de Indexación en Memoria

El objetivo de esta prueba es comprobar experimentalmente la estabilidad y linealidad del tiempo deindexación, para lo cual vamos a utilizar el corpus de items de KStore.

En esta prueba medimos los tiempos de indexación para los 6619 items, indexándolos en lotes de a100. Las capas de indexación se con�guraron para utilizar DefaultIndexerService, DefaultIndexerPipeline yMemoryIndexWriterFactory.

En los siguientes grá�cos vemos los tiempos de indexación acumulativos y promedio para los 66 lotes:

Figura 4.25: Tiempos de Indexación Acumulativos. El grá�co muestra en trazos continuos de color cuatroensayos más dos trazos discontinuos que representan un desvío a partir del promedio de los cuatro ensayos.


Figura 4.26: Tiempo de Indexación Promedio. Este grá�co muestra en forma de columnas el tiempopromedio de indexación de cada lote para los cuatro ensayos de la �gura anterior.

El loteo de items tiene que ver con la utilización del método IndexerService.bulkCreate(), el cual recibe lositems en listas. Variando el número de lotes desde 1 hasta 6619 items por lote no encontramos variacionessigni�cativas en los tiempos de indexación. Esto nos induce a pensar que el loteo no es necesario cuandose trabaja en memoria.

Si repetimos la prueba anterior sin utilizar el stemmer snowball del inglés para tratar los títulos de lositems, los tiempos de indexación se reducen signi�cativamente:


Figura 4.27: Tiempos de indexación acumulativos comparativos con y sin stemming para el corpus KStore,índice en memoria.

Figura 4.28: Tiempos de indexación promedio por lote comparativos con y sin stemming para el corpusKStore, índice en memoria.

Los datos de las pruebas anteriores corresponden a muestras aleatorias tomadas entre varias indexaciones,excluyendo la primera corrida. Esta precaución debe tomarse debido a que la primera indexación incurre


en una penalidad de carga de clases y caches que en un sistema en funcionamiento ya encontraríamos enmemoria.

Veamos cómo varían los valores de la misma estadística tomando sólo las primeras corridas del indexador:

Figura 4.29: Tiempos de Indexación Acumulativos para Primeras Corridas. En trazos continuos de colortenemos los cuatro ensayos más dos trazos discontinuos que representan un desvío a partir del promedio.

Figura 4.30: Tiempo de Indexación Promedio para Primeras Corridas del Indexador. La línea de tendenciamuestra que el costo en los primeros lotes es superior al de los últimos lotes, donde los tiempos seestabilizan.


Como se puede apreciar en la �gura anterior, respecto de las indexaciones normales, la primera corridaincrementa los tiempos de ejecución en un orden de magnitud.

Pruebas Comparativas de Indexación en Memoria

En este apartado repetimos las pruebas del apartado previo, indexando el corpus KStore sobre ApacheLucene.

La indexación en Lucene requiere la creación explícita de un Document. En nuestro caso, el documentose de�nió de la siguiente forma:

I tem item = itemsToBeIndexed . ge t ( i ) ;doc . add (new F i e l d ( " i d " , ( ( Long ) i tem . g e t I d ( ) ) . t o S t r i n g ( ) , F i e l d . S to r e . YES ,

F i e l d . I ndex .NOT_ANALYZED) ) ;doc . add (new F i e l d ( " t i t l e " , i tem . g e t T i t l e ( ) , F i e l d . S to r e .NO, F i e l d . I ndex .

ANALYZED) ) ;

Es decir, indexamos los ítems por su título, almacenando su identi�cador en el índice invertido, tal depoder hidratar los objetos luego de la recuperación.

Si comparamos la indexación en memoria del corpus KStore sobre nuestro framework versus la indexaciónen memoria con Lucene, tenemos el siguiente grá�co comparativo:

Figura 4.31: Tiempos de Indexación Comparativos. En la prueba con el corpus KStore, nuestro frameworkfue más rápido que Lucene tanto en los casos en los que procesamos el texto con stemming como en losque no lo hicimos.

Analizando la �gura (4.31), vemos que los dos frameworks sufren una degradación al aplicar análisis sobrelos textos5.

Un aspecto curioso de la implementación de Lucene es que el método close() de su índice en memoriatoma un tiempo similar al de toda la indexación junta. Este tiempo puede visualizarse en el grá�co (4.31)como una rampa pronunciada sobre su límite derecho.

5En rigor, en nuestro framework sólo eliminamos el stemming, manteniendo tanto la delimitación como la normalización.


Aún quitando el tiempo que toma el método close(), nuestro framework es hasta un 60% más velozcuando no se utiliza análisis ni stemming y hasta un 15% más veloz cuando se utiliza análisis y stemming.Incluyendo el tiempo que insume el método close(), nuestro framework llega a ser un 73% más rápido sinanálisis ni stemming y un 43% más veloz cuando los incluimos.

Pruebas de Indexación en BerkeleyDB

Así como en el apartado previo hicimos pruebas de indexación sobre memoria RAM, en este apartadovamos a estudiar el rendimiento utilizando nuestro plugin BerkeleyDB (ver subsección 3.3.3).

Las pruebas realizadas sobre este plugin son las mismas que efectuamos en el apartado anterior, es decir,indexamos el corpus KStore en lotes de 100 items.

Antes de presentar los resultados, es preciso comentar que el plugin BerkeleyDB permite trabajar tantoen forma transaccional como no transaccional. Desde el punto de vista del rendimiento, trabajar en formatransaccional degrada la performance en forma muy fuerte. Sin embargo, es sensato trabajar en modotransaccional si el corpus es pequeño, si disponemos de hardware de altas prestaciones o si no tenemosotra opción para resguardar la integridad de nuestro proceso.

Conociendo conceptualmente el impacto que tiene el modo transaccional, estamos en condiciones depresentar los resultados experimentales:

Figura 4.32: Indexación No Transaccional en BerkeleyDB. La línea superior (verde) corresponde a una�primera corrida�, la cual hemos visto que suele demorar más. El resto de las líneas se corresponde conun muestreo de corridas intermedias, las cuales no sufren el efecto anterior.


Figura 4.33: Tiempos de indexación promedio por lote para la indexación no transaccional en BerkeleyDB.A diferencia del caso en memoria, el índice se degrada notablemente a medida que se agregan lotes. Lalínea roja marca la tendencia lineal para la evolución del tiempo promedio por lote.

Figura 4.34: Indexación Transaccional en BerkeleyDB. La versión transaccional toma hasta 30 veces mástiempo en indexar los lotes y diluye el efecto de primeras corridas.

Vemos entonces que la indexación transaccional toma aproximadamente 30 veces más que la versión notransaccional. En el caso transaccional, también vemos que el retardo en la primera corrida se diluyedebido a que el tiempo total de indexación es muy largo.


Sin embargo, el índice no transaccional sí logra buenas marcas. La línea de tendencia gra�cada en colorrojo en la �gura (4.33) tiene fórmula:

t (Li) = 0, 01966i+ 0, 27646 [s]

donde:

t (Li) es el tiempo de indexación en segundos del lote i

cada lote Li tiene 100 items

Asumiendo que la degradación de la performance sigue esta tendencia lineal, podemos calcular cuántotiempo nos tomaría indexar un corpus de 1000 lotes (100000 items):

100∑i=1

t (Li) = 10116, 29 s. = 168, 60 min ∼= 2, 8 hs

Lo cual es una muy buena marca para esta versión no optimizada del índice Berkeley.

Pruebas de Recuperación en Memoria

En esta subsección vamos a estudiar el rendimiento de nuestro framework en cuanto a recuperación deobjetos.

Dado que los tiempos invertidos en recuperación se exponen directamente a los usuarios �nales de laaplicación, la tarea de recuperación es aún más importante que la de indexación.

A continuación explicamos el diseño de las pruebas de recuperación en memoria junto con sus resultados.

El diseño de la prueba comprendió:

índice en memoria,

corpus KStore,

un conjunto 4024 queries distintas, tomadas de las primeras y segundas palabras de los items delcorpus KStore,

un conjunto de 50 ensayos sin efectos de retardo por �primeras corridas�.

La variable que nos interesa medir en este caso es el µq = tiempo promedio de ejecución por consulta.

La medición del tiempo promedio por consulta incluye las operaciones:

Procesamiento de Textos: normalización y construcción del árbol de consulta,

Recuperación: acceso a índices, operaciones sobre posting lists y valoración según modelo vectorial.

Bajo este diseño, obtuvimos los resultados:

µq = 4, 4376× 10−5 [s/query] = 0, 044376 [ms/query]

σq = 0, 7127× 10−5 [s/query] = 0, 007127 [ms/query]

Lo cual nuevamente es una muy buena marca.

Si extrapolamos esta estadística destinando un segundo completo a resolver consultas que toman untiempo µq , podríamos recuperar:

#queries en 1 segundo =1000mss

0, 044376msq= 22534 [queries/s]


Esto es, podríamos resolver más de 22.000 consultas por segundo.

Es muy importante conocer si estos resultados son comparables a los de otras alternativas como ApacheLucene. Para esto repetimos las pruebas anteriores utilizando el RAMDirectory de Lucene y efectuamosconsultas sobre el atributo title de la clase Item.

Ejecutando las pruebas sobre Lucene, obtuvimos los resultados:

µq−Lucene = 6, 6634× 10−5 [s] = 0, 066634 [ms]

σq−Lucene = 0, 6365× 10−5 [s] = 0, 006365 [ms]

Este resultado de Lucene también es muy bueno, sin embargo, si extrapolamos nuevamente la estadística,ahora podríamos efectuar:

#queries en 1 segundo para Lucene =1000mss

0, 066634msq= 15007 [queries/s]

En resumen, para un mismo intervalo de tiempo de un segundo, nuestro framework permite ejecutar un50% más de consultas sobre el corpus KStore que lo que permite Lucene.

Pruebas de Recuperación en BerkeleyDB

Las pruebas de recuperación sobre el índice BerkeleyDB son prácticamente iguales a las que hicimos sobreel índice en memoria, con la única excepción de que indexamos y recuperamos los objetos hacia/desde elíndice Berkeley en modo no transaccional.

La recuperación en Berkeley tuvo el siguiente resultado:

µq−Berkeley = 2, 2748 [ms]

σq−Berkeley = 0, 1811 [ms]

si repetimos la búsqueda para el caso transaccional, encontramos que el rendimiento es casi idéntico:

µq−BerkeleyTrans = 2, 2907 [ms]

σq−BerkeleyTrans = 0, 0386 [ms]

Vemos entonces que la transaccionalidad afecta el rendimiento de la indexación, mientras que la recu-peración no sufre de penalización alguna.

Con el índice Berkeley no transaccional y un equipo como el descripto al principio de esta sección,calculemos cuántas búsquedas por segundo podemos servir sobre el corpus KStore:

#queries en 1 segundo para Berkeley DB (no transaccional) =1000mss

2, 2748msq= 439 [q/s]

Al igual que observamos con la indexación, el rendimiento en memoria es muy superior al obtenido endisco con BerkeleyDB. Sin embargo, en el caso de la indexación la operatoria en memoria mejoraba lostiempos aproximadamente por un factor de 400, mientras que en el caso de la recuperación tenemos unfactor de 50. Esto nos permite obtener las siguientes conclusiones:

la transaccionalidad degrada el rendimiento muchísimo más en la indexación que en la recuperación,

BerkeleyDB mejora su rendimiento en escenarios de lecturas intensivas (recuperación) por sobre elescenario de escrituras intensivas (indexación).

Con esto terminamos las pruebas cuantitativas de rendimiento. En la próxima subsección analizaremoscualitativamente la integración de nuestro framework con PetClinic y haremos una comparativa generalde características con el resto de las herramientas.


4.3.3. Análisis Comparativo Cualitativo

En esta sección vamos a comparar nuestra solución respecto de alternativas similares en términos cual-itativos. Primero vamos a hacer una breve reseña de qué similitudes y diferencias encontramos en laimplementación de PetClinic por Compass y luego vamos a escoger una serie de items sobre las quecomparar las herramientas.

PetClinic sobre Compass

En este apartado seleccionamos algunos puntos clave sobre los que comparar nuestra implementación dePetClinic con la provista por Compass:

Mapeo XML: en vez de utilizar un mapeo por medio de anotaciones (también soportado por Com-pass), se utilizan un archivo XML llamado petclinic.cpm.xml.

Semántica de Mapeos: si comparamos el archivo petclinic.cpm.xml con nuestro mapeo de la �gura(4.2), encontramos que el mapeo es muy similar. Los dos frameworks mapean la jerarquía de clases,incluyendo Entity, NamedEntity, Person, Vet y Pet. En el caso de Compass también se mapea laclase Specialty.

ORM: en el ejemplo de Compass se soportan simultáneamente JDBC, Hibernate y OJB medianteel intercambio de archivos de con�guración de Spring y la utilización del patrón de diseño DAO(Data Access Objects). En nuestro framework, si bien el ORM nos es transparente a través de losplugins, la implementación que hicimos de PetClinic sólo trabaja con Hibernate.

Indexación: en los dos ejemplos se utilizó la indexación por eventos. La con�guración acerca de cómohacerlo varía signi�cativamente entre frameworks, pero en los dos casos el objetivo es el mismo.

Recuperación: en el caso de Compass, la recuperación se efectúa a través de una clase interna delframework que delega la visualización a una vista con�gurada mediante Spring. En nuestro ejemplode PetClinic no utilizamos un controlador provisto por nuestro framework sino que hicimos uncontrolador propio que efectúa explícitamente la búsqueda.

Dado que nuestra prueba sobre PetClinic está basada en la versión que acompaña a Compass, es naturalque no hayan existido grandes diferencias entre una y otra versión.

Los puntos anteriores corresponden a una instancia particular de la utilización de los dos frameworks. Enel próximo apartado seleccionamos características generales sobre las que efectuar una comparativa.

Comparación General de Características

En este apartado seleccionamos algunos puntos sobre los que nos interesa evaluar los distintos frameworksestudiados. Esta lista coincide mayormente con los puntos elegidos para analizar Compass y HibernateSearch en la subsección (2.4.4).

Naturalmente, los trabajos más maduros han incorporado a lo largo del tiempo mayor cobertura de casosde uso satelitales (índices sobre RDBMS, resaltadores de resultados, etc). Sin embargo, queremos guiarnospor la adecuación de la herramienta al problema que queremos resolver y no por los características quepueden incorporarse iterativamente. Por esto, elegimos las características que son las que consideramosfundamentales al problema de indexación de objetos, dejando un último apartado para característicassatelitales e integración con otros frameworks u ORMs.

Características Generales Al analizar las características generales de HS y Compass (ver subsección2.4.4), planteamos tres problemas: abstracción incompleta, infraestructura correctiva y desaprovechamien-to estructural y semántico.

La abstracción incompleta tiene que ver con la presencia en HS y Compass de objetos de Lucene yconceptos de orientación a documentos. Estas características no están presentes en nuestro framework,


donde las consultas, �ltros y ordenamiento se efectúan en términos de los objetos originales y no dedocumentos.

La infraestructura correctiva de HS y Compass eran un conjunto de características implementadas parareutilizar Lucene y ocultar sus limitaciones (bloqueos, optimización de índices, precalentamiento de lec-tores, etc). En la infraestructura de nuestro framework encontraremos que este tipo de problemas noaplican.

El desaprovechamiento estructural tiene que ver con la delegación en Lucene de los problemas de recu-peración, evitando consultas a partir de objetos y valoraciones estructurales del tipo PageRank y HITS.En este campo, nuestro framework crea la capacidad de efectuar consultas a partir de objetos. En cuantoa análisis de enlaces entre objetos, esta característica no fue implementada aún en nuestro framework. Sinembargo, los índices fueron diseñados de forma de ser adecuados para un cálculo de este tipo utilizandoel registro maestro.

Además explicamos que el hecho de que Lucene sea el motor de IR de base para HS y Compass provocados problemas. El primer problema es que la evolución de estas herramientas depende de la evoluciónde Lucene. La segunda es que para aprovechar las mejoras en Lucene, los usuarios del framework debenesperar a que HS y Compass generen una versión compatible con la nueva versión de Lucene.

Comportamiento como Framework Este punto tiene que ver con lo que establecimos en la proposi-ción 1 respecto de tomar un comportamiento de framework de caja negra.

En este sentido, los tres frameworks de indexación de objetos obtienen un adecuado comportamiento decaja negra. El único rezagado es Lucene, quien tiene comportamiento de librería.

Indexación y Modelo de Dominio Cuando analizamos este punto en la subsección (2.4.4), efectu-amos cinco proposiciones que vamos a retomar para discutir este ítem.

La proposición 2 proponía distintos niveles de soporte transaccional. En este sentido, Compass es el únicoque da garantías transaccionales, siendo que el resto de las herramientas sólo garantiza consistencia básicadel índice.

Muy relacionada a la proposición anterior, la proposición 3 plantea que las operaciones sobre los índicesse deben hacer evitando repetir código asociado a transacciones o a lecturas y escrituras de índices. Estees un problema que está mayormente resuelto en todos los frameworks.

La siguiente es la proposición 4, la cual hablaba de la necesidad de proveer indexación automática deeventos CUD en el ORM. En este sentido, los tres frameworks de indexación de objetos soportan estesistema, siendo que nuestro framework y Compass son los únicos que permiten trabajar con distintosORMs. HS sólo indexa automáticamente los eventos CUD del ORM Hibernate Core, mientras que Luceneno soporta indexación automática.

La anteúltima proposición plantea requerimientos mínimos en cuanto a la expresividad del sistema demapeos. En este punto, los tres frameworks de IR sobre objetos presentan una expresividad prácticamenteequivalente. Mas allá de pequeñas diferencias de forma, no hay grandes diferencias de características entreestos tres frameworks. Sin embargo, Lucene sí queda relegado frente al resto por no soportar el mapeode entidades.

Por último, la proposición 6 nos dice que la indexación y la recuperación deben utilizar representacionespolimór�cas de los objetos de dominio. Hemos visto que HS y Compass exponen una serie de objetosno polimór�cos como Document, Resource y Property. Sin embargo, también permiten trabajar con enti-dades polimór�cas o idénticas a las de dominio. En nuestro framework dimos un paso adelante, eliminandocualquier objeto espejado de la entidad de dominio, referenciando los objetos únicamente mediante metaprogramación, utilizando atributos de tipo Class y Field. Sin embargo, introdujimos objetos que represen-tan el concepto de clave de objeto sin proveerlas como un reemplazo de la entidad indexada sino comoun mecanismo para poder hidratarla desde el ORM.

Procesos de Indexación La proposición 7 nos requería permitir una indexación sincrónica con latransacción de negocio y otra asincrónica.

En este sentido, todos los frameworks de indexación de objetos implementan en la indexación online,semi-online y o�ine, por lo que las diferencias tienen que ver con detalles implementativos.


Recuperación, Queries, Matching y Acceso a Datos La principal diferencia conceptual en materiade acceso a datos es que nuestro framework incorpora un registro maestro de objetos que permite conocerqué objetos están indexados y bajo qué términos. Creemos que la utilidad de este registro maestro justi�cael espacio extra que pueda requerir, por lo que es una ventaja comparativa entre frameworks.

Dado el carácter experimental de nuestros índices en BerkeleyDB, creemos es demasiado pronto paracomparar la performance de los índices en disco. Sin embargo, es preciso comentar que Lucene implementatécnicas como front coding o skip pointers, los cuales sin duda colaboran en un excelente rendimiento.

En cuanto a recuperación, Lucene ha implementado una serie de características satelitales que nuestroframework todavía no soporta: consultas por comodines, literales, edit distance, etc.

El �ltrado por atributos se efectúa en forma muy distinta entre frameworks. En el caso de Lucene y susderivados, el campo por el que se quiere �ltrar se debe especi�car en la consulta. En nuestro framework,el �ltrado de campos se efectúa como un pos �ltro dentro de una cadena de �ltrado. El inconvenienteque tiene la versión de Lucene es que asume que el valor por el que se �ltra es texto plano, cuando bienpodría ser un otro objeto completo sobre el que aplicaríamos el método equals(). En este sentido, creemosque nuestra solución se adecúa mejor al problema que queremos resolver.

En el ejemplo (2.4.5) propusimos un dar un paso adelante en cuanto a recuperación, proponiendo larecuperación a partir de objetos. Este tipo de recuperación trata al objeto recibido como al indexado,generando los términos adecuados al procesador de texto, selector de índices y lenguajes. Este tipo derecuperación sólo está presente en nuestro framework y seguramente es la propuesta más innovadora queincluimos en esta versión.

La implementación de un �More Like This� es soportada por Compass y HS, pero sólo nuestro frameworkadmite una consulta polimór�ca con el objeto para el cual se quiere buscar otros similares.

Por último, existe una pequeña controversia en cuanto a la hidratación de objetos. La proposición 9nos indica que la hidratación es responsabilidad del ORM, lo cual tanto HS como nuestro frameworkrespetan a rajatabla. Por otro lado, Compass está orientado a recuperar los objetos desde el índice,lo cual explicamos que no es la mejor solución. Sin embargo, si bien por defecto Compass efectúa lahidratación desde los índices, también permite obtener la clave del objeto para una hidratación desde elORM.

Modelos de Information Retrieval Tanto Hibernate Search como Compass dejan en manos deLucene la implementación de los modelos de IR, por lo que nos corresponde analizar a éste último.

Lucene implementa una versión híbrida del modelo booleano y vectorial, utilizando el modelo booleanopara �ltrar documentos y el vectorial para priorizarlos. Si se desactiva la priorización, se obtiene unmodelo booleano.

Si bien nuestro framework implementa tanto el modelo booleano como el vectorial, a diferencia de Lucene,los implementa por separado generando implementaciones distintas de la interfaz Search.

Si bien creemos que nuestro diseño es más desacoplado y separa mejor los objetos que hacen sentido enun modelo de los del otro, no existe una razón objetiva para descartar una u otra propuesta.

En cuanto a similitud, las fórmulas de Lucene son algo más complejas que las que implementamos en estaversión de nuestro framework. Sin embargo, tuvimos especial cuidado en diseñar los índices de forma talque eventualmente permitan implementar una fórmula como la de Lucene.

En términos del modelo de IR, la mayor diferencia entre frameworks tiene que ver con el hecho de quenuestro framework adopta un modelo vectorial puro. En base a la explicación que hicimos al introducir elmodelo vectorial, donde presentamos las limitaciones del modelo booleano de conjunciones y disyunciones,creemos que nuestra elección es la adecuada.

Otra diferencia importante entre Lucene y nuestro framework tiene que ver con los factores de impulso(boost). En nuestro framework no incluimos un factor de impulso para atributos o clases. La razón porla que no incluimos los factores de impulso es porque no son completamente necesarios y no queda claroque sea la forma correcta de lograr relevancia. Dado que en nuestro framework las fórmulas de similitudson parametrizables, podemos lograr los mismos o mejores resultados sin impulsos.

Por último, la implementación de reglas duras y blandas con HS, Compass y Lucene es considerablementemás compleja de implementar en dichos frameworks. Nuestro framework está diseñado para permitir


incorporar este tipo de reglas con facilidad, accediendo a los atributos originales de los objetos indexadosy no a una representación como texto plano.

Funcionalidades Satelitales e Interacción con otros Frameworks Este punto de comparaciónre�ere a cómo se ha expandido la herramienta para cubrir distintos casos de uso e integrarse en elecosistema de herramientas que componen las aplicaciones. En este punto comparativo debemos excluir anuestra herramienta, ya que el alcance de esta primera versión sólo incluyó las funcionalidades esencialesde la recuperación de objetos.

Entre las herramientas Lucene, Compass y Hibernate, encontramos que Lucene tiene gran cantidad deadicionales en cuanto a técnicas de matching y acceso a datos, mientras que Compass es quien mejor seintegra con otros frameworks y ORMs.

Lucene posee una variedad muy amplia de analizadores (procesadores de texto), backends de almace-namiento de índices invertidos, fórmulas de similitud, etc. Además, a lo largo del tiempo se han idodesarrollando herramientas como inspectores de índices invertidos. Es decir, esta librería tiene un vastorepositorio de utilidades, siempre en el campo de IR sobre documentos.

Por el lado de Compass encontramos una amplia variedad de adicionales, entre los que se encuentra elsoporte para Spring MVC y otros ORM como TopLink o JDBC.

Aquí concluye el capítulo de experimentación. Para �nalizar este trabajo, el próximo capítulo expondrá lasconclusiones haciendo un repaso de los puntos más importantes de cada capítulo, poniendo en contrastelos avances obtenidos y agregando una sección de trabajos futuros.

Capítulo 5

Conclusiones

En este capitulo �nal presentamos nuestras conclusiones respecto de qué resultados obtuvimos a lo largode esta tesis

La primera sección presenta las conclusiones propiamente dichas, haciendo una retrospectiva desde quecomenzamos a introducir el problema en los capítulos introductorios, hasta que terminamos de validarnuestra propuesta a través de comparaciones.

La segunda y última sección consiste en proponer características adicionales que quedaron fuera delalcance de este trabajo y que con�rmarían este software como una alternativa de primer nivel.

5.1. Conclusiones

Recordando los comienzos del capítulo introductorio, vimos que existen aplicaciones cuyos objetivos denegocio parecen ser ortogonales a la recuperación de información, hasta que ésta se vuelve un mediopara lograr sus objetivos de negocio. Cuando esto ocurre, necesitamos un framework de IR que se integretransparentemente a la aplicación y se adecúe al paradigma de programación orientada a objetos y alecosistema de frameworks que componen una aplicación (por ejemplo, los ORM, los frameworks web,etc).

En base a estos requerimientos hemos delimitado un problema de IR sobre objetos, el cual llamamos �elproblema del Domain Model Search�.

Al estudiar el estado del arte encontramos herramientas que buscan resolver este problema reutilizandolibrerías de IR sobre documentos. Analizando estas herramientas, hemos desarrollado una serie de proposi-ciones que nos guíaron en cómo resolver el problema en base al aprendizaje que adquirimos estudiandoel estado del arte.

En base al estudio del campo de IR, del diseño de software y las herramientas anteriores, se analizóy diseñó un framework que se adecúa al problema del Domain Model Search. Con el análisis de quésolución debíamos construir conseguimos uno de los primeros objetivos de la tesis: delimitar el problemaen distintas actividades de IR (recuperación, indexación, etc.) encontrando las distintas variantes desolución y seleccionando las mejores alternativas.

Una vez que se diseñó e implementó un prototipo del framework fue necesario veri�carlo. Para estoseguimos un patrón de diseño de frameworks que propone escribir tres aplicaciones distintas sobre lasque probar nuestra herramienta, las cuales seleccionamos eligiendo: una estándar (PetClinic) y dos apli-caciones nuevas creadas para esta tesis (KStore y Klink), las cuales re�ejan negocios reales en la web. Laexperimentación con estas aplicaciones nos permitió iterar sobre el análisis y diseño del framework, hastaque llegamos al alcance necesario para observar los frutos en términos comparativos.

La primera comparación que hicimos permite veri�car que el rendimiento de nuestro framework semantiene en el mismo orden de magnitud que el resto de las opciones en cuanto a tiempos de indexacióny recuperación. En estas pruebas encontramos que nuestra solución no solo se mantuvo en el mismo ordende magnitud sino que mejora las marcas de rendimiento de herramientas maduras del estado del arte.

167

168 CAPÍTULO 5. CONCLUSIONES

El segundo conjunto de comparaciones lo hicimos en términos cualitativos. Estos términos cualitativosfueron escogidos con el mismo criterio con el que analizamos las herramientas del estado del arte, contra-stando cada herramienta con las proposiciones que efectuamos. Esta comparativa cualitativa mostró (a)que nuestro framework incorporó las mejores prácticas para la resolución del problema y (b) una serie decaracterísticas a implementar como continuación de este trabajo.

En terminos de la motivación que describimos en el capítulo introductorio, podemos decir que cumplimoscon el objetivo de aplicar las técnicas de IR para encontrar información almacenada en los objetos de losmodelos de dominio, determinando las actividades, componentes y alternativas de un motor de búsquedasobre objetos.

Finalmente, esta la tesis logró contribuir con una solución concreta al problema de IR sobre objetos,presentando un problema de ingeniería de software, planteando sus alternativas de solución, desarrollandoun alternativa precisa y contrastando los resultados obtenidos respecto del estado del arte.

5.2. Trabajos Futuros

En esta sección enumeramos las características que podríamos mejorar o incluir en nuestro frameworkpara con�rmar este software como una alternativa de primer nivel.

Índices

En la capa de acceso a datos proponemos agregar características y efectuar algunas mejoras sobre laimplementación actual:

La primera característica a mejorar es el plugin de índices en disco. El plugin actual se podría rediseñarutilizando un motor de acceso a archivos ad-hoc que implemente front coding, skip pointers, mergegeneracional y demás técnicas del estado del arte.

En muchas aplicaciones es conveniente contar con una implementación del índice sobre un RDBMS talde poder inspeccionar y mantener el índice utilizando herramientas estándar. Para esto proponemosdesarrollar un plugin que permita almacenar el índice en un esquema relacional.

Por último, dado que en este momento la inspección de los índices en disco requiere un desarrollo ad-hoc,deberíamos proveer una herramienta genérica de inspección que muestre cómo se indexaron los objetos.

Information Retrieval

Como indicamos oportunamente, las fórmulas de relevancia que implementamos son algo básicas, por loque uno de los puntos donde deberíamos trabajar es en validar su e�cacia sobre un corpus estándar yeventualmente iterar sobre ellas.

También relacionado con las técnicas de valoración, creemos que una futura versión debe mejorar elsoporte para el puntaje estructural del tipo HITS y PageRank, facilitando almacenar puntajes por objetoen el registro maestro.

Características Generales

Existen algunos puntos donde nuestro framework todavía es �poco amigable� y podemos mejorarlo confacilidad:

Para mejorar la usabilidad del framework deberíamos implementar una forma simple de obtener infor-mación agregada de los resultados como el número total de coincidencias e información de paginado.

La con�guración de los mapeos se debería externalizar para permitir variaciones en caliente e indexaciónde dominios sobre los que no se cuenta con el código fuente original (recordar que las anotaciones re-quieren modi�car el código fuente). Hacer esta con�guración desde archivos XML o JSON es muy simple,pero requiere desarrollar una clase que lea el XML y efectúe un trabajo similar al AnnotationCon�gura-tionMapper.

5.2. TRABAJOS FUTUROS 169

Una característica satelital soportada por algunos frameworks y que podríamos incoporar tiene que ver consoportar el resaltado de las coincidencias en el contexto original del término. Esto requiere implementarun resaltador (highlighter) y el llamado �Keyword In Context� ó KWIC (ver subsección 2.1.5).

Por último, creemos que una futura versión debería mejorar el soporte transaccional y el logging deeventos internos al framework.

Integración con Otros Frameworks

Dentro de los planes de desarrollo de este framework, quisiéramos agregar plugins para soportar la in-dexación automática desde otros ORMs como JDO, JPA, etc.

Por último, últimamente han emergido lenguajes dinámicos compilados a bytecode Java como Groovy /Grails, a los cuales podríamos darles soporte bene�ciarse de un framework de IR como el que construimos.

Aún fuera de lenguajes compilados a bytecode Java, se podría portar la herramienta para trabajar enotros lenguajes similares.

170 CAPÍTULO 5. CONCLUSIONES

Bibliografía

Ahn, L. et al. `Telling humans and computers apart automatically'. Commun. ACM, tomo 47, 2, págs.56�60, 2004. ISSN 0001-0782. doi:http://doi.acm.org/10.1145/966389.966390.

Apache. Àpache ActiveMQ', 2009a.URL http://activemq.apache.org/

Apache. Àpache Lucene', 2009b.URL http://lucene.apache.org/

Apache. ìBATIS Persistence Framework for Java', 2009c.URL http://ibatis.apache.org/

Apache. Àpache Hadoop', 2010.URL http://hadoop.apache.org/

Apache Foundation. Àpache Maven Project', 2010. Maven project management & comprehensiontool.URL http://maven.apache.org/

Austin, D. `How Google Finds Your Needle in the Web's Haystack', 2006.URL http://www.ams.org/featurecolumn/archive/pagerank.html

Baeza-Yates, R. et al. Modern Information Retrieval. ACM Press - Addison Wesley, 1999.URL http://people.ischool.berkeley.edu/~hearst/irbook/

Baeza-Yates, R. et al. `Design trade-o�s for search engine caching'. ACM Trans. Web, tomo 2, 4, págs.1�28, 2008. ISSN 1559-1131. doi:http://doi.acm.org/10.1145/1409220.1409223.

Beck, K. Test Driven Development: By Example. Addison Wesley, 2002.

Bernard, E. `Hibernate Search - cool, but is it the right approach? Year baby!' Blog, 2007a.URL http://blog.emmanuelbernard.com/2007/06/hibernate-search-cool-but-is-it-right.

html

Bernard, E. `Hibernate Search: Googling Your Java Technology-Based Persistent Domain Model'. EnJavaOne Conference. 2007b.

Compass Project. `Compass Search Engine', 2009.URL http://www.compass-project.org/

Cutting, D. et al. Òptimization for dynamic inverted index maintenance'. En SIGIR '90: Proceedingsof the 13th annual international ACM SIGIR conference on Research and development in informationretrieval, (págs. 405�411). ACM, New York, NY, USA, 1990. ISBN 0-89791-408-2. doi:http://doi.acm.org/10.1145/96749.98245.

Cutting, D. `Dynamization and Lucene', 2004a.URL http://cutting.wordpress.com/2004/11/

Cutting, D. `Lucene Talk at University of Pisa', 2004b.URL http://lucene.sourceforge.net/talks/pisa/

Dahan, U. Èmploying the Domain Model Pattern', 2009.URL http://msdn.microsoft.com/en-us/magazine/ee236415.aspx#id0400005

171

http://activemq.apache.org/

http://lucene.apache.org/

http://ibatis.apache.org/

http://hadoop.apache.org/

http://maven.apache.org/

http://www.ams.org/featurecolumn/archive/pagerank.html

http://people.ischool.berkeley.edu/~hearst/irbook/

http://blog.emmanuelbernard.com/2007/06/hibernate-search-cool-but-is-it-right.html

http://blog.emmanuelbernard.com/2007/06/hibernate-search-cool-but-is-it-right.html

http://www.compass-project.org/

http://cutting.wordpress.com/2004/11/

http://lucene.sourceforge.net/talks/pisa/

http://msdn.microsoft.com/en-us/magazine/ee236415.aspx#id0400005

172 BIBLIOGRAFÍA

Dean, J. et al. `MapReduce: Simpli�ed Data Processing on Large Clusters'. Communications of theACM, tomo 51, págs. 107�113, 2008.

Doliner, M. `Cobertura Code Coverage Tool', 2006.URL http://cobertura.sourceforge.net/

Fang, H. et al. À formal study of information retrieval heuristics'. En SIGIR '04: Proceedings ofthe 27th annual international ACM SIGIR conference on Research and development in informationretrieval, (págs. 49�56). ACM, New York, NY, USA, 2004. ISBN 1-58113-881-4. doi:http://doi.acm.org/10.1145/1008992.1009004.

Fielding, R.T. Architectural Styles and the Design of Network-based Software Architectures. TesisDoctoral, University of California, 2000.

Fowler, M. Patterns of Enterprise Application Architecture. Addison Wesley, 2002.URL http://www.martinfowler.com/books.html

Fowler, M. Ìnversion of Control Containers and the Dependency Injection pattern', 2004.URL http://martinfowler.com/articles/injection.html

Fowler, M. Ìnversion of Control', 2005.URL http://martinfowler.com/bliki/InversionOfControl.html

Galceran, C.L. `Lematización automática y diccionarios electrónicos'. En C.I.M. y Sara Gómez Seibane,ed., Lingüística Vasco-Románica, no 21 en Oihenart. Cuadernos de Lengua y Literatura, (págs. 331�343). Eusko Ikaskuntza, Donostia-San Sebastián, 2006.URL http://hedatuz.euskomedia.org/4082/

Gamma, E. et al. Design patterns: elements of reusable object-oriented software. Addison-WesleyProfessional, 1995.

Gar�eld, E. `The Permuterm Subject Index: An Autobiographical Review'. Journal of the AmericanSociety for Information Science, tomo 27, págs. 288�291, 1976.

Google. `Google Search Appliance', 2009a.URL http://www.google.com/enterprise/gsa/

Google. `Google Search Engine', 2009b.URL http://www.google.com

Grupo de Estructuras de Datos y Lingüística Computacional. `Flexionador y lematizador depalabras del español', 2006. Accedido: Enero de 2010.URL http://www.gedlc.ulpgc.es/investigacion/scogeme02/lematiza.htm

Hibernate. `Hibernate - Relational Persistence for Idiomatic Java', 2009a.URL http://core.hibernate.org/

Hibernate. `Hibernate Search', 2009b.URL http://search.hibernate.org/

HyperSQL. `HyperSQL Database Engine', 2008.URL http://hsqldb.org/

JCP. Ènterprise JavaBeans 3.0', 2006a.URL http://jcp.org/en/jsr/detail?id=220

JCP. `JavaTM Data Objects 2.0 - An Extension to the JDO speci�cation', 2006b.URL http://www.jcp.org/en/jsr/detail?id=243

Johnson, R.E. et al. `Designing Reusable Classes'. Journal of Object-Oriented Programming, tomo 1,págs. 22�35, 1988.

Klas, J. `Recuperación de Información sobre Modelos de Dominio'. 38 JAIIO AST, 2009.URL http://www.scribd.com/doc/19217222/Recuperacion-de-Informacion-sobre-Modelos-de-Dominio

http://cobertura.sourceforge.net/

http://www.martinfowler.com/books.html

http://martinfowler.com/articles/injection.html

http://martinfowler.com/bliki/InversionOfControl.html

http://hedatuz.euskomedia.org/4082/

http://www.google.com/enterprise/gsa/

http://www.google.com

http://www.gedlc.ulpgc.es/investigacion/scogeme02/lematiza.htm

http://core.hibernate.org/

http://search.hibernate.org/

http://hsqldb.org/

http://jcp.org/en/jsr/detail?id=220

http://www.jcp.org/en/jsr/detail?id=243

http://www.scribd.com/doc/19217222/Recuperacion-de-Informacion-sobre-Modelos-de-Dominio

BIBLIOGRAFÍA 173

Kleinberg, J.M. Àuthoritative Sources in a Hyperlinked Environment', 1999.

Levenshtein, V.I. `Binary codes capable of correcting spurious insertions and deletions of ones'. Prob-lems of Information Transmission, tomo 1, págs. 8�17, 1965.

Lexis Nexis Research. `LexisNexis', 2009.URL http://www.lexisnexis.com/research/

Mackinnon, T. et al. Èndo-testing: unit testing with mock objects'. (págs. 287�301), 2001.

Manning, C. et al. Introduction to Information Retrieval. Cambridge University Press, 2008.URL http://www-csli.stanford.edu/~hinrich/information-retrieval-book.html

Memcached. `Memcached', 2009.URL http://memcached.org/

Metaweb Techonologies. `Freebase', 2010.URL http://www.freebase.com/

Oracle. Òracle TopLink', 2008.URL http://www.oracle.com/technology/products/ias/toplink/index.html

Oracle. Òracle Berkeley DB Java Edition', 2009a.URL http://www.oracle.com/technology/products/berkeley-db/je/index.html

Oracle. Òracle Secure Enterprise Search', 2009b.URL http://www.oracle.com/technology/products/oses/index.html

Page, L. et al. `The PageRank Citation Ranking: Bringing Order to the Web', 1998.

PCI. `PCI Security Standards Council 2006', 2006.URL https://www.pcisecuritystandards.org/

Porter, M.F. `Snowball: A language for stemming algorithms'. Published online, 2001. Accessed11.03.2008, 15.00h.URL http://snowball.tartarus.org/texts/introduction.html

Porter, M. Àn algorithm for su�x stripping'. Program, tomo 14, 3, págs. 130�137, 1980.

Princeton. `WordNet 3.0', 2010.URL http://wordnet.princeton.edu/

RAE. Diccionario de la lengua española. Real Academia Española, 2006.

Roberts, D. et al. Èvolving Frameworks: A Pattern Language for Developing Object-Oriented Frame-works', 1996.URL http://st-www.cs.illinois.edu/users/droberts/evolve.html

Robertson, S.E. `The Probability Ranking Principle in IR'. Journal of Documentation, tomo 33, págs.294�304, 1977.

Robertson, S.E. et al. `Relevance weighting of search terms'. Journal of the American Society forInformation Science, tomo 27, págs. 129�146, 1976.

Rocchio, J.J. The SMART Retrieval System�Experiments in Automatic Document Processing, (págs.313�323). Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1971.

Salton, G. et al. À vector space model for automatic indexing'. Commun. ACM, tomo 18, 11, págs.613�620, 1975. ISSN 0001-0782. doi:http://doi.acm.org/10.1145/361219.361220.

SIGIR. `SIGIR'2006 Workshop on Faceted Search - Call for Participation', 2006.URL http://sites.google.com/site/facetedsearch/

SOX. `Sarbanes-Oxley Act of 2002', 2002.URL http://www.gpo.gov/fdsys/pkg/PLAW-107publ204/content-detail.html

http://www.lexisnexis.com/research/

http://www-csli.stanford.edu/~hinrich/information-retrieval-book.html

http://memcached.org/

http://www.freebase.com/

http://www.oracle.com/technology/products/ias/toplink/index.html

http://www.oracle.com/technology/products/berkeley-db/je/index.html

http://www.oracle.com/technology/products/oses/index.html

https://www.pcisecuritystandards.org/

http://snowball.tartarus.org/texts/introduction.html

http://wordnet.princeton.edu/

http://st-www.cs.illinois.edu/users/droberts/evolve.html

http://sites.google.com/site/facetedsearch/

http://www.gpo.gov/fdsys/pkg/PLAW-107publ204/content-detail.html

174 BIBLIOGRAFÍA

Spring. `The Spring Framework 2.5 - Reference Documentation', 2008.URL http://static.springframework.org/spring/docs/2.5.x/reference/index.html

Sun. `Java Object Serialization Speci�cation', 2004.URL http://java.sun.com/j2se/1.5.0/docs/guide/serialization/spec/serialTOC.html

Sun. `Java Platform Standard Ed. 6 Documentation', 2008.URL http://java.sun.com/javase/6/docs/api/java/io/ObjectOutputStream.html

XStream. `XStream Serialization Framework', 2009.URL http://xstream.codehaus.org/

Yahoo. `Yahoo Search Engine', 2009.URL http://www.yahoo.com

Zobel, J. et al. `Finding approximate matches in large lexicons'. Softw. Pract. Exper., tomo 25, 3, págs.331�345, 1995. ISSN 0038-0644. doi:http://dx.doi.org/10.1002/spe.4380250307.

http://static.springframework.org/spring/docs/2.5.x/reference/index.html

http://java.sun.com/j2se/1.5.0/docs/guide/serialization/spec/serialTOC.html

http://java.sun.com/javase/6/docs/api/java/io/ObjectOutputStream.html

http://xstream.codehaus.org/

http://www.yahoo.com

Apéndice A

Instalación del Software y el CódigoFuente

A.1. Instalación del Software de Pruebas

Esta tesis está acompañada de un software que permite reproducir los ensayos del capítulo 4 así comoejecutar PetClinic, Klink y KStore sobre nuestro sistema de IR.

Para ejecutar las pruebas y demostraciones en Windows o Linux se deben seguir los siguientes pasos:

1. Desde el DVD que acompaña este trabajo se debe instalar VirtualBox (se incluye una versión paraWindows y otra para Linux, en caso de no ser compatible con su sistema operativo, VirtualBox sepuede descargar desde http://www.virtualbox.org/wiki/Downloads).

2. Una vez instalado VirtualBox, se debe copiar y descomprimir el archivo que contiene la imagen dela máquina virtual (vm-tesis.rar) en una carpeta cualquiera. Esto requiere aproximadamente 6 GBde espacio libre en disco.

3. Iniciar VirtualBox y agregar la imagen de disco siguiendo la secuencia:

a) elegir el menú File

b) dentro del menú, seleccionar la primera opción: Virtual Media Manager

c) en el diálogo que se abre, seleccionar la tableta Hard Disks

d) en la parte superior del diálogo, presionar el botón Add

e) elegir la imagen de disco descomprimida en el paso 2 (archivo con extensión .vdi dentro de lasubcarpeta HardDisks) y presionar el botón Ok.

4. Crear una máquina virtual siguiendo la secuencia:

a) en la pantalla inicial de VirtualBox presionamos el botón superior New

b) ignorar la primera pantalla y presionar Next

c) ingresamos el nombre para la VM, elegimos el SO Linux, la versión Ubuntu y presionamos Next

d) en la pantalla de selección de memoria, elegir 512 MB RAM y presionar Next

e) elegir la opción Use existing hard disk, seleccionar el disco agregado en el paso 3 y presionarNext

f ) ignorar esta última pantalla y presionar Finish

5. Por último, en la pantalla principal iniciamos la máquina virtual presionando el botón Start .

6. Al iniciar la VM, Ubuntu le pedirá el password de inicio de sesión. Tanto el nombre de usuariocomo la contraseña se corresponden con la palabra tesis. Una vez que se inició la sesión, abrir elarchivo de instrucciones situado en el escritorio y seguir los pasos indicados.

175

176 APÉNDICE A. INSTALACIÓN DEL SOFTWARE Y EL CÓDIGO FUENTE

A.2. Código Fuente y Sitio Web del Proyecto

El código fuente del framework puede descargarse libremente de SourceForge y GitHub:

http://modelsearch.git.sourceforge.net/git/gitweb-index.cgi

http://github.com/jklas/ObjectSearch

Actualmente también existe una página web desde donde se puede seguir el proyecto:

https://sites.google.com/site/objectsearchframework/

Índice alfabético

índice invertido, 22

algoritmo de Rocchio, véase relevance feedbackApache Lucene, 4aplicaciones empresariales, 44

búsqueda facetada, 29búsquedas literales, 28bases de datos orientadas a objetos, 64boolean model, véase modelo booleano

caches, 34campos, 36cobertura de código, 129

desajustesde impedancia, 59de recuperación, 68de sincronización, 68estructural, 68

diccionario, 22distancia de Levenshtein, véase edit distance

edit distance, 29enterprise applications, véase aplicaciones empre-

sariales

F-measure, 11faceted search, véase búsqueda facetada�ltrado, 99, 106, 126, 165

hidratación, 34hipónimo, 32hiperónimo, 32HITS, 40holónimo, 32hubs, véase HITS

impedance mismatch, véase desajuste de impedan-cia

indexación, 9algoritmos distribuidos, 26concurrente y distribuida, 96dinámica, 27o�ine, 95online, 94por Barrido Simple en Memoria, 24por Ordenamiento en Bloques, 24semi-online, 94

information retrieval, 1accuracy, 11

corpus, 8documentos, 8léxico, 9modelo booleano, 13modelo probabilístico, 19modelo vectorial, 14modelos, 12precision, véase precisionrecall, véase Recall

inversión del control, 50inyección de dependencias, 50

Klink, 129KStore, 129

léxico, 22lematización, 31

mapeos avanzados, 103merónimo, 32modelos de dominio, 2, 46

ordenamiento, 106overstemming, 31

PageRank, 38parónimo, 32patrones

de arquitectura, 45de diseño, 45

persistencia de modelos de dominio, 53Ad-Hoc, 56Administrada, 55Binaria, 55Manual, 54Object Oriented DBMS, véase Bases de Datos

Orientadas a ObjetosORM, 58básico, 59completo, 63Hibernate, 64JDO, 64JPA, 63

XML, 58PetClinic, 129plugin, 98portabilidad, 129posting lists, 22precision, 9probabilistic model, véase modelo probabilístico

177

178 ÍNDICE ALFABÉTICO

pruebascomparativas cualitativas, 130comparativas de rendimiento, 130de calidad, 129

query log mining, véase relevance feedback

range queries, 29ranking, 11recall, 9reindexación, 97relevance feedback, 41

algoritmo de Rocchio, 42explícito, 42implícito, 42query log mining, 42

similitud, 99booleana, 13probabilística, 20vectorial, 15

sinónimo, 32snowball, 32stemming, 31

tesauro, 29, 33TF-IDF, 17

vector space model, véase modelo vectorial

zonas, 36

ii - materias.fi.uba.armaterias.fi.uba.ar/7500/klas-tesisingenieriainformatica.pdfllamamos el...

Documents