Recuperación de Noticias Ordenadas Temporalmente y Por Zonas Utilizando Funciones Combinadas de Recuperación de Información de Apache Solr

Universidad Nacional de la Patagonia San Juan Bosco
Facultad de Ingeniera
Departamento de Informtica
Sede Puerto Madryn
Recuperacin de noticias ordenadas temporalmente y

por zonas utilizando funciones combinadas de
recuperacin de informacin de Apache Solr
Indexacin de contenidos sobre bases de datos NoSQL
Tesina de Grado para
Licenciado en Informtica
Autor
Luis Ignacio Aita

Tutor
Lic. Damin Barry

Fecha
Octubre 2014
Agradecimientos
A mi esposa, quien me apoy en todo mi elstico trayecto acadmico y a mis dos hermosas
hijas.
A mi madre Ana Mara Aita, quien me dio mucho ms que el apellido en la vida.
A mi amigo y hermano de la vida Juan Pablo Martini.
A mi tutor y amigo Lic. Demian Barry, quien me apoy e insisti para finalizar mi carrera y
me acompao en el desarrollo del presente trabajo de tesina.
A mi socio, amigo y compaero acadmico Juan Manual Cortez y todos mis compaeros de
trabajo y estudio.
A todos los docentes y compaeros de estudio que he conocido a lo largo de mi carrera, con
los cuales he compartido muchos mates y buenos momentos, y en donde he encontrado
muchos buenos amigos.
Resumen
Este proyecto de tesina se aboca a investigar y mejorar las tcnicas de recuperacin de
informacin sobre una base de datos existente de noticias obtenidas de redes sociales y diarios en
lnea.
Dicha informacin ya se encuentra clasificada e indexada por diversos campos, de los cuales
vale destacar la pertenencia geogrfica de la noticia, tanto en forma semntica (teniendo en cuenta
localidad, partido, provincia, etc. en forma de rbol) como geogrfica (latitud, longitud).
El motor de indexacin utilizado para la generacin de la base de datos es Apache Solr/Lucene y
el set de datos fue generado en el marco del proyecto de extensin Georreferenciacin de
Contenidos para el proyecto Zonales, en adelante Zonales, llevado adelante por un convenio
entre la sede Puerto Madryn de la Universidad y la empresa Mediabit S.A., del cual form parte
del equipo de desarrollo. En la siguiente seccin se describe ms ampliamente este proyecto.
La seleccin del motor de bsqueda no solo se basa en el antecedente del proyecto ejecutado y la
base de datos generada, sino adems en el trabajo Distributed Search on Large NoSQL
Databases[Tinetti, Barry, Aita, Pez, PDPTA2011] co-escrito por el autor, en el cual se
comprobaron las capacidades y el rendimiento del servidor de indexacin y bsquedas Apache Solr
respecto a las caractersticas de escalabilidad y disponibilidad en ambientes heterogneos. Este
trabajo dio pie a la formacin dentro de la sede de un grupo de investigacin en el rea.
El presente trabajo pretende comprobar que es posible mejorar la combinacin de funciones de
bsqueda y recuperacin de la informacin almacenada en el ndice existente, principalmente en
relacin con la pertenencia geogrfica y la antigedad de la informacin buscada.
ndice General
1 Agradecimientos................................................................................................................................3
2 Resumen............................................................................................................................................5
3 Introduccin.......................................................................................................................................9
3.1 Motivacin del Proyecto..........................................................................................................10
3.2 Objetivos..................................................................................................................................11
3.3 Hiptesis..................................................................................................................................12
3.4 Aporte.......................................................................................................................................12
3.5 Metas........................................................................................................................................12
3.6 Metodologa.............................................................................................................................13
3.6.1 Sobre la metodologa de investigacin............................................................................13
3.6.2 Sobre la metodologa de desarrollo..................................................................................15
4 Marco Terico..................................................................................................................................17
4.1 Sistemas Distribuidos..............................................................................................................17
4.1.1 Conceptos.........................................................................................................................17
4.1.2 Propiedades......................................................................................................................18
4.1.3 Aplicaciones.....................................................................................................................20
4.1.4 Ventajas............................................................................................................................21
4.1.5 Desventajas......................................................................................................................22
4.1.6 Perspectivas......................................................................................................................22
4.2 Bases de Datos Distribuidas....................................................................................................23
4.2.1 Conceptos.........................................................................................................................23
4.2.2 Diseo y arquitecturas......................................................................................................24
4.2.3 Transacciones...................................................................................................................27
4.2.4 Control de concurrencia...................................................................................................27
4.2.5 Consultas..........................................................................................................................28
4.2.6 Clasificacin.....................................................................................................................28
4.2.7 Ventajas y desventajas......................................................................................................30
4.3 Bases de Datos NoSQL............................................................................................................31
4.3.1 Introduccin.....................................................................................................................31
4.3.2 Definicin.........................................................................................................................32
4.3.3 Tipos de bases de datos NoSQL.......................................................................................34
4.3.4 Tcnicas utilizadas por las bases de datos NoSQL..........................................................35
4.3.5 Gestores de bases de datos NoSQL..................................................................................38
4.4 Big Data...................................................................................................................................42
4.4.1 Introduccin.....................................................................................................................42
4.4.2 Definicin.........................................................................................................................43
4.4.3 Ventajas............................................................................................................................44
4.4.4 Desventajas......................................................................................................................46
4.4.5 Aplicaciones.....................................................................................................................46
4.4.6 Caractersticas..................................................................................................................46
4.4.7 Herramientas....................................................................................................................47
5 Apache Solr.....................................................................................................................................49
5.1 Introduccin.............................................................................................................................49
5.2 Componentes principales.........................................................................................................50
5.3 Lucene......................................................................................................................................51
5.3.1 Comparacin con la tecnologa de base de datos tradicional...........................................52
5.4 Indexacin................................................................................................................................52
5.4.1 Cmo Solr ve al Mundo...................................................................................................54
5.4.2 Anlisis de campos...........................................................................................................55
5.5 Bsquedas................................................................................................................................55
5.5.1 Relevancia........................................................................................................................59
5.5.2 Modalidad y sintaxis de las consultas Solr......................................................................61

6 Diseo e implementacin de la experimentacin............................................................................64
6.1 Introduccin.............................................................................................................................64
6.2 Zonales.....................................................................................................................................64
6.2.1 Por qu Zonales?............................................................................................................64
6.2.2 Objetivos..........................................................................................................................64
6.2.3 Primera etapa del proyecto...............................................................................................65
6.2.4 Segunda etapa del proyecto..............................................................................................68
6.2.5 Construccin de un motor de extraccin de informacin................................................68
6.2.6 Clasificacin de la informacin.......................................................................................71
6.2.7 Bsqueda de Informacin y Apache Solr.........................................................................71
6.2.8 Arquitectura......................................................................................................................72
6.2.9 Resultados del proyecto...................................................................................................73
6.3 Bitcora del proyecto de Tesina...............................................................................................74
6.3.1 Diseo..............................................................................................................................74
6.3.2 Pruebas.............................................................................................................................87
6.3.3 Resultados........................................................................................................................93
6.4 Infraestructura..........................................................................................................................96
7 Conclusiones....................................................................................................................................98
8 Lineas futuras................................................................................................................................100
9 Referencias....................................................................................................................................101
10 Anexos.........................................................................................................................................103
10.1 Anexo 1: Definicin de campos del esquema Solr en la etapa 1.........................................103
10.2 Anexo 2: Extensin analizador de consultas DisMax en solrconfig.xml en la etapa 1.......104
10.3 Anexo 3: Formatos estandarizados de noticias (posts)........................................................105
10.3.1 Formato XZone:...........................................................................................................105
10.3.2 Formato JZone:............................................................................................................106
10.4 Anexo 4: Definicin de campos del esquema Solr en la etapa 2.........................................106
10.5 Anexo 5: Set de datos de pruebas D1..................................................................................108
10.6 Anexo 6: Set de datos de pruebas D2..................................................................................109
10.7 Anexo 7: Resultados Esperados para los distintos escenarios de prueba.............................110
10.7.1 RE1...............................................................................................................................110
10.7.2 RE2...............................................................................................................................111
10.7.3 RE3...............................................................................................................................112
10.7.4 RE4...............................................................................................................................113
10.7.5 RE5...............................................................................................................................114
10.7.6 RE6...............................................................................................................................115
10.7.7 RE7...............................................................................................................................116
10.7.8 RE8...............................................................................................................................117
Luis Ignacio Aita
Pgina 9
Introduccin
En la actualidad existe gran cantidad de sitios web que procesan grandes volmenes de
informacin, la cual es necesario manejar eficientemente. Principalmente por las siguientes razones:
La popularidad de los sistemas de gestin de contenidos (CMS, Content Management

System) como portales en general y como plataformas de colaboracin en particular
La llamada Web 2.0 ha definido un conjunto de aplicaciones que facilitan la interaccin con
gran volumen de contenido multimedia.
Crecimiento en la produccin de informacin dentro de las organizaciones ya sea por

produccin de los sistemas o por la digitalizacin de informacin existente.
En suma se ha pasando de hablar de gigabyte de informacin a hablar con total normalidad del
orden de los petabytes. Esta situacin ha generado el desafo de mejorar las herramientas de
bsqueda en lo que se denomina information retrieval utilizando para ello diversas tcnicas.
Claramente los buscadores en Internet (Google, Yahoo, Bing, etc.) han solucionado en parte el
problema pero han introducido otro que no es menor: la supuesta informacin recuperada es
sesgada al criterio de ordenamiento de cada buscador y no precisamente resuelve la problemtica de
encontrar lo que se necesita.
Para resolver el problema de la recuperacin de la informacin es necesario conocer (en parte) el
perfil de la persona que est buscando, y la manifestacin de inters de la misma. Las redes sociales
han resuelto (tambin en parte) la problemtica del vnculo entre personas y sus temas de inters
pero sin ocuparse del contenido de la informacin.
La segmentacin de la informacin en reas geogrficas ligadas a la ubicacin de cada individuo,
permitirn a los distintos usuarios de la red encontrar informacin segn rdenes de proximidad.
Para ello es necesario contar con:
Segmentacin de la informacin mediante etiquetas: clasificacin, segmentacin, generacin

automtica de atributos.
Perfil del usuario basado en pertenencia geogrfica, identidad cultural y hbitos.
Motor de bsqueda que jerarquice la informacin analizando la clasificacin de la misma y

los hbitos del usuario.
Recuperacin de noticias ordenadas temporalmente y por zonas utilizando funciones combinadas de recuperacin de
informacin de Apache Solr
Luis Ignacio Aita
Pgina 10
En este sentido el concepto de pertenencia geogrfica es sumamente importante en el desarrollo

del presente trabajo.
3.1
Motivacin del Proyecto
En la Sede Puerto Madryn de la Universidad Nacional de la Patagonia San Juan Bosco se form
un equipo de vinculacin y transferencia tecnolgica con la finalidad de mejorar la calidad
tecnolgica de las organizaciones destinatarias, brindando cursos y realizando convenios con
empresas del ramo, como parte de la realizacin de prcticas profesionalizantes en proyectos de
extensin.
Uno de estos convenios se firm con la empresa Mediabit S.A. Esta empresa se especializa en
comunicacin, asesoramiento e integracin tecnolgica orientada a los negocios en Internet
(Internet Bussines Provider).
Dentro del marco de este convenio, el equipo trabaj dentro de un proyecto mencionado
anteriormente. Zonales es
un gestor de contenidos web (www.zonales.com) que brinda un
conjunto de servicios de informacin reunidos en un mismo lugar que poseen un factor en comn:
la georreferenciacin de la informacin y servicios desde una perspectiva local para cada
comunidad. Dentro del portal, cada usuario puede consultar y publicar contenidos relacionados con
su localidad y zonas de inters, generando informacin desde la periferia hacia el centro
La ltima versin generada de Zonales estuvo en linea aproximadamente seis meses en forma
totalmente funcional. El volumen de datos que se gener durante ese tiempo fue de
aproximadamente un milln y medio (1.500.000) de documentos.
Actualmente la informacin clasificada por zona y por fuente se recupera utilizando una
combinacin de funciones de recuperacin diseada durante el desarrollo del proyecto.
La necesidad de comprobar y mejorar este conjunto de funciones es la principal motivacin de
este proyecto, en concreto, disear, investigar y probar diversas combinaciones de funciones de
recuperacin y filtros de informacin para que los datos recuperados sean de inters para el usuario
en el marco geogrfico-temporal.
Motiva adems la realizacin de este trabajo la experiencia adquirida por el autor en la temtica
al formar parte del grupo que escribi el paper Distributed Search on Large NoSQL
Databases[Tinetti, Barry, Aita, Pez, PDPTA2011] mencionado anteriormente, el cual fue
publicado en el ao 2011 en la Conferencia Internacional sobre Tcnicas y Aplicaciones de
Luis Ignacio Aita
Pgina 11
Procesamiento Paralelo y Distribuido en Estados Unidos, material que ser utilizado como parte de
este trabajo de tesina.
Adems formo parte del grupo de investigacin sobre bases de datos NoSQL que se form en la
sede Puerto Madryn de la Universidad, dentro del cual participo del proyecto Tcnicas de
Recuperacin de Informacin en Grandes Volmenes de Datos Heterogneos con Bases de Datos
NoSQL, enfocado en la evaluacin de tcnicas existentes para recuperacin eficiente de
informacin sobre grandes volmenes de datos heterogneos.
Dichas tcnicas permitirn establecer las capacidades necesarias con las que debera contar una
base de datos de informacin masiva, tanto desde la perspectiva de almacenamiento y tcnicas de
indexacin, como de distribucin de las consultas, escalabilidad y rendimiento en ambientes
heterogneos.
El presente trabajo de tesina forma parte de los trabajos de investigacin realizados en el marco
del proyecto de investigacin mencionado. Aprovechando el gran volumen de informacin generada
en Zonales y, sumado a esto, las tcnicas ya utilizadas para la recuperacin, ordenamiento y filtro de
la informacin en forma geogrfica-temporal, aplicar y evaluar nuevas tcnicas que permitan
mejorarlas y optimizarlas.
3.2
Objetivos
Son objetivos de la tesina:
Profundizar los conocimientos tericos del autor sobre bases de datos NoSQL, funciones de
recuperacin y filtro de informacin y distribucin de los datos.
Estudiar Gestores de Bases de Datos NOSQL actuales y sus caractersticas principales.
Mejorar la recuperacin y el ordenamiento de la informacin clasificada del proyecto

Zonales.
Que el resultado de la tesina sea de utilidad para la investigacin en el campo de las bases de
datos NoSQL, especialmente en las recuperacin clasificada y ordenada de informacin en
grandes volmenes de datos.
Luis Ignacio Aita
Pgina 12
Que el resultado de la tesina sea de utilidad para el proyecto de investigacin Tcnicas de

Recuperacin de Informacin en Grandes Volmenes de Datos Heterogneos con Bases de
Datos NoSQL
Finalmente, es un objetivo inherente y principal de un proyecto de tesina el hacer de

integrador de los conceptos asimilados en la carrera, mediante el diseo y realizacin de un
trabajo final multidisciplinario, facilitando la construccin de una sntesis metodolgica para
la obtencin y/o generacin de conocimiento por parte del alumno.
3.3
Hiptesis
Tomando como base de partida el ndice existente en el proyecto Zonales, se pretende demostrar
en el presente trabajo que es posible mejorar las funciones de bsquedas utilizadas para la
recuperacin de la informacin, de tal manera que cumplan con los requerimientos del proyecto
Zonales, incorporando clasificadores como pertenencia geogrfica, variables de tiempo y
tipificacin de la informacin.
3.4
Aporte
La ejecucin del presente proyecto de tesina permitir el diseo y desarrollo de tcnicas

avanzadas de indexacin y bsqueda de informacin utilizando Apache Solr/Lucene,
transformndose en un valioso aporte tanto para el proyecto Zonales (discontinuado) como para el
Grupo de Investigacin de bases de Datos NoSQL, en particular para el proyecto Tcnicas de
Recuperacin de Informacin en Grandes Volmenes de Datos Heterogneos con Bases de Datos
NoSQL.
3.5
Metas
A continuacin se lista un conjunto de metas cuyo cumplimiento permitir el logro de los

objetivos delineados.
1. Elaborar un marco terico que de sustento al desarrollo de la tesina.
2. Relevar y analizar documentacin terica sobre clasificacin y recuperacin de informacin
utilizando Apache Solr/Lucene en combinacin con otras bases NoSQL.
3. Interiorizarse en las tecnologas y metodologas utilizadas para la recuperacin de
informacin en grandes volmenes de datos.
Luis Ignacio Aita
Pgina 13
4. Estudiar y comparar diversas combinaciones de funciones de recuperacin sobre la base de

datos de informacin existente.
5. Replicar la base de datos en un ambiente local para poder realizar y documentar todas las
pruebas necesarias para optimizar las combinaciones de funciones de recuperacin de
informacin.
6. Encontrar la combinacin ptima aplicable a la base de datos existente.
7. Adquirir un amplio conocimiento de la tecnologa implementada, a fin de tener la capacidad
de asesorar a los interesados sobre las diferentes posibilidades que ofrece el producto, de
acuerdo a cada necesidad en particular.
8. Seleccionar y probar una de las combinaciones con el fin de implementarla utilizando el
modelo de datos y servicios del proyecto Zonales.
3.6
Metodologa
3.6.1 Sobre la metodologa de investigacin

Entre los objetivos principales de la presente tesina est el fortalecimiento de los conocimientos
del autor, por lo tanto es fundamental equilibrar y adquirir los conocimientos especficos en la
materia. Para ello se prevn, dentro de las actividades, el estudio de la disciplina en forma
sistemtica.
Se utilizar el mtodo propuesto por Brbara A. Kitchenham[Kitchenham, Brereton, Budgen,
Turner, Khalil 2006] con una adaptacin para proyectos de fin de carrera propuesta por un grupo de
investigacin conjunto de la Universidad de Castilla La Mancha, Espaa y de la Universidad del
Bio Bio de Chile[Gutirrez, Ros, Calero, Fernndez, Piattini 2008]. A continuacin se detalla un
resumen del mtodo extrado de ambas publicaciones.
Dado que las disciplinas de computacin son relativamente nuevas respecto a otras disciplinas,
existen pocas metodologas que guen el desarrollo de revisiones sistemticas. Kitchenham propone
un mtodo basado en pautas desarrolladas para la investigacin mdica y que adapt para ser
utilizadas por un equipo de investigadores en el mbito de la Ingeniera de Software.
Segn la autora, una revisin sistemtica se define como la manera de evaluar e interpretar toda
la investigacin disponible relevante respecto a un interrogante de investigacin particular, en un
rea temtica o fenmeno de inters. Los estudios individuales que contribuyen a una revisin
Luis Ignacio Aita
Pgina 14
sistemtica se denominan estudios primarios, una revisin sistemtica se considera un estudio

secundario. El mtodo se divide en tres etapas fundamentales que son:
1. Planificacin de la revisin.
2. Desarrollo de la revisin.
3. Publicacin de los resultados de la revisin.
En la adaptacin propuesta se considera que en el caso de un proyecto de fin de carrera
generalmente el trabajo es realizado por un solo investigador-alumno, y la supervisin est a cargo
de un tutor o gua. A continuacin se presentan un par de tablas comparativas entre el mtodo
original y la propuesta adaptada a tesinas de fin de carrera:
Etapa 1: Planificacin de la revisin
Identificar la necesidad de la revisin

Definir un protocolo de revisin.
Validar el protocolo de revisin
Etapa 2: Desarrollo de la revisin
Identificacin de Investigaciones relevantes.

Seleccin de los estudios primarios.
Evaluacin de la calidad del estudio.
Extraccin y monitoreo de datos.
Sntesis de datos
Etapa 3: Publicacin de los resultados.
Escribir reporte de la revisin.

Validar reporte de la revisin.
Tabla 1: Metodologa de Kitchenham
Etapa 1: Planificacin de la revisin
Identificar la necesidad de la revisin

Definicin de un protocolo de bsqueda.
Definir un protocolo de revisin.
Evaluacin de la planificacin.
Etapa 2: Desarrollo de la revisin
Bsqueda de los estudios primarios.

Seleccin de los estudios primarios.
Extraccin y gestin de datos.
Sntesis de datos
Etapa 3: Publicacin de los resultados.
Escribir reporte de la revisin.

Evaluacin del reporte de revisin.
Tabla 2: Adaptacin para proyectos de fin de

carrera
La primera etapa, planificacin de la revisin, tiene como objetivo definir los principales
parmetros que se tendrn en cuenta para realizar la revisin. En sus correspondientes sub-etapas se
establecern las razones que justifican la realizacin de la revisin, se establecer la manera en que
se har la bsqueda de trabajos y la forma en que estos sern revisados, y finalmente se evaluar la
planificacin realizada.
En la segunda etapa, desarrollo de la revisin, es en donde se lleva a cabo la revisin
propiamente dicha. Esta etapa est guiada por los protocolos definidos en la etapa de planificacin,
aunque, dado que la investigacin es un proceso flexible, es posible incluir cambios que signifiquen
alguna mejora en los mtodos. Durante esta etapa se buscarn y seleccionaran los estudios
primarios de acuerdo a los criterios previamente definidos, se extraern y se organizarn para su
Luis Ignacio Aita
Pgina 15
posterior uso los datos relevantes al tema de investigacin, y finalmente se sintetizarn los mismos
de acuerdo al enfoque deseado.
En la ltima etapa, publicacin de los resultados, se escribirn los documentos necesarios para
la difusin de los resultados obtenidos, que no solo sern el informe final de la tesina, sino tambin
su comunicacin a travs de conferencias, publicaciones, etc.
3.6.2 Sobre la metodologa de desarrollo

El desarrollo gil [Kent Beck et al. 2001], es un marco de trabajo conceptual de la ingeniera de
software que promueve el uso de iteraciones a lo largo de todo el ciclo de vida del proyecto. Existen
muchos mtodos de desarrollo gil y la mayora trata de minimizar los riesgos en lapsos cortos de
tiempo.
El software desarrollado en una unidad de tiempo es llamado una iteracin, la cual debe durar de
una a cuatro semanas. Cada iteracin del ciclo de vida incluye: planificacin, anlisis de
requerimientos, diseo, codificacin, revisin y documentacin. Una iteracin no debe agregar
demasiada funcionalidad. Estos pequeos ciclos permiten comprobar resultados rpidamente,
corrigiendo o adaptando las tcnicas y metodologas utilizadas.
Las principales caractersticas del desarrollo gil son:
Proceso iterativo e incremental
Mitigacin del riesgo mediante iteraciones fijas
Mejora continua
Calidad desde el primer da
Priorizar requerimientos de acuerdo a su valor
Equipos dedicados y auto-gestionados
Colaboracin continua con los objetivos
Incorporar el cambio
Prcticas de desarrollo modernas
En particular se adoptar la metodologa Scrum [Kniberg 2007][Rising, Janoff 2000] como gua
para organizar el proyecto de desarrollo. Scrum adopta sus ideas del trabajo orientado a la pila del
Luis Ignacio Aita
Pgina 16
producto a desarrollar. No utiliza mtodos jerrquicos para la produccin de software sino que se
centra en las responsabilidades del equipo de proyecto.
La pila de producto es el corazn de Scrum, y bsicamente es una lista priorizada de requisitos, o
historias, o funcionalidades, metas que se quieren alcanzar, componentes que queremos construir,
etc., descritas usando la terminologa del usuario (llamadas historias, o a veces simplemente
elementos de la pila).
Luis Ignacio Aita
Marco Terico
4.1
Sistemas Distribuidos
Pgina 17
Desde una perspectiva histrica podemos encuadrar a los sistemas distribuidos como una de las
ltimas etapas en la evolucin de los sistemas informticos, impulsados por los grandes avances en
comunicaciones y hardware de las ltimas dcadas.
Muchas de las tecnologas y aplicaciones relacionados con el presente trabajo de tesina son o
estn soportados por sistemas distribuidos, e incluso la arquitectura de solucin del proyecto
Zonales puede considerarse como tal, debido a la posibilidad de distribuir y escalar horizontalmente
sus componentes y de utilizar tcnicas de Information Retrieval y crawling de datos sobre
aplicaciones externas aprovechando las ventajas que ofrece la red Internet.
4.1.1 Conceptos
El objetivo de un sistema distribuido es integrar recursos y servicios mediante el uso de redes de
comunicaciones para ofrecer a usuarios y aplicaciones una visin sistmica nica, ocultando su
caracterstica de distribuido, funcionando en forma transparente e independiente de la ubicacin de
cada recurso, entendindose como tal cualquier dispositivo o servicio, hardware o software capaz de
ser compartido.
En la bibliografa existen numerosas definiciones de sistemas distribuidos, citaremos dos de ellas
para el presente trabajo.
Conjunto de computadores independientes que se muestran al usuario como un sistema nico
coherente [Tanenbaum, Van Steeen, 2008]
Sistema en el cual componentes de hardware y software, localizados en computadores en red, se
comunican y coordinan acciones slo mediante paso de mensajes [Coulouris et. al., 2001]
Los protocolos de red ocultan la topologa y los atributos fsicos de la misma mientras que los
sistemas operativos ocultan las caractersticas de los equipos fsicos. Los componentes de un
sistema distribuido pueden ser heterogneos, en cuyo caso se necesita una capa de software para
proporcionar una visin nica que normalmente se denomina middleware.
Luis Ignacio Aita
Pgina 18
4.1.2 Propiedades
Un sistema distribuido debe cumplir con un conjunto de propiedades para poder funcionar
adecuadamente. A continuacin se resumen dichas caractersticas.
4.1.2.1 Transparencia
Para mostrarse ante usuarios y aplicaciones externas como un sistema nico, los sistemas
distribuidos deben ofrecer una visin transparente respecto a su ubicacin fsica de los recursos. La
transparencia puede darse en distintos aspectos del sistema:
De identificacin. La forma en que los recursos del sistema son identificados debe ser
independiente de las plataformas que soporten cada componente del mismo.
De ubicacin. Se accede a los recursos del sistema sin importar en que nodo residen o si son
locales o remotos. Esto permite adems trasladar los recursos entre nodos sin que las
aplicaciones o los usuarios lo noten.
De replicacin. El sistema gestiona la cantidad copias de cada recurso, aadiendo o

quitando copias segn sea necesario. Esto incluye los caches como un tipo de replicacin
que requiere de alguna validacin en los clientes para preservar la consistencia.
De paralelismo. El sistema distribuido puede distribuir la carga de trabajo entre los nodos
sin que la aplicacin tenga que solicitarlo explcitamente, siempre y cuando no tenga
consecuencias sobre la ejecucin de las mismas salvo las mejoras en rendimiento.
De comparticin. Un recurso debe poder ser accedido en forma concurrente desde diversas
aplicaciones del sistema sin efectos adversos sobre la ejecucin de las aplicaciones.
De rendimiento. Implementar las propiedades listadas anteriormente conlleva una merma

en el rendimiento, para la cual hay que buscar soluciones tecnolgicas que permitan
reducirla. Un ejemplo de este tipo de soluciones es el uso de caches locales para reducir el
trfico en las redes.
4.1.2.2 Consistencia
Mantener la consistencia en un sistema distribuido mediante un estado global es un problema de

gran complejidad y es el aspecto fundamental a tener en cuenta en el momento de disearlo.
Luis Ignacio Aita
Pgina 19
Cada uno de los nodos del sistema tiene su propio estado local y estn fsicamente distribuidos,
por lo tanto lograr un estado global unificado depende principalmente de los mecanismos de
comunicacin soportados por las redes.
Mantener una consistencia estricta demanda un nivel muy alto de comunicacin y sincronismo
entre nodos, lo cual afecta al rendimiento global del sistema. Encontrar un nivel aceptable entre
rendimiento y consistencia es el objetivo que debe perseguir el diseador del sistema.
4.1.2.3 Escalabilidad
A diferencia de los sistemas centralizados, en los cuales para poder mantener un nivel de
prestaciones adecuando frente a un incremento en la demanda de uso es necesario escalar en forma
vertical, es decir aumentar la capacidad de cmputo o almacenamiento en disco o memoria del
sistema, en los sistemas distribuidos es posible hacerlo aadiendo ms nodos o recursos distribuidos
de manera horizontal.
Para que esto sea posible es necesario planear cuidadosamente el crecimiento del sistema
mediante el diseo de arquitecturas adecuadas para cada caso. Por ejemplo, no se debe limitar el
espacio de nombre de manera tal que impida la incorporacin de nuevos recursos. En la misma
linea deben evitarse en general los cuellos de botella tanto en aspectos fsicos como de
programacin que incurran en fallas de rendimiento o acceso a los recursos.
4.1.2.4 Fiabilidad
Podemos definir la fiabilidad como la capacidad del sistema de cumplir en forma correcta y
durante todo el tiempo las funciones para las cuales fue implementado. Clasificaremos esta
propiedad en dos aspectos principales:
Disponibilidad: est representado por la cantidad de tiempo en que el sistema est operativo.
La disponibilidad est estrechamente ligada a la calidad de los recursos y a la replicacin de
los mismos dentro del sistema distribuido. Para aumentar la disponibilidad es necesario
mejorar alguno de dichos conceptos. En el estado tecnolgico actual normalmente es ms
econmica la replicacin. Los sistemas distribuidos proporcionan en forma natural la
replicacin de algunos recursos, por ejemplo unidades de proceso, mientras que otros que
habitualmente son compartidos pueden replicarse para aumentar la disponibilidad, como es
el caso de un sistema de archivos. La probabilidad de que un recursos no est disponible se
reduce en forma exponencial por cada replica existente del mismo.
Luis Ignacio Aita
Pgina 20
Tolerancia a fallos: es la capacidad del sistema de detectar y corregir un fallo sin que el
usuario o las aplicaciones lo noten. La distribucin y replicacin de los recursos permiten
brindar esta propiedad pero no lo garantizan por si sola. Es necesario un mecanismo de
administracin de fallo robusto.
4.1.3 Aplicaciones
Es importante diferenciar en este punto las aplicaciones paralelas de las aplicaciones distribuidas.
Una aplicacin paralela puede dividir sus tareas y ejecutarlas en forma paralela ajustndose a
determinados esquemas y el objetivo que persiguen es disminuir los tiempos de procesamiento
repartiendo la carga.
Un aplicacin distribuida tiene objetivos ms variados y se aplica a diversos entornos. Entre las
motivaciones que pueden justificar la implementacin de un sistema distribuido podemos destacar:
Alta disponibilidad: se utiliza la distribucin para brindar informacin en forma constante a

los usuarios con bajos tiempos de respuesta, utilizando muchas veces tcnicas de replicacin
que tienen en cuenta la ubicacin geogrfica de los mismos.
Alto rendimiento: una aplicacin distribuida puede ser tambin paralela, persiguiendo el
mismo objetivo de mejorar los tiempos de respuesta en los procesos de cmputo. Un
ejemplo muy extendido hoy en da es el uso de clusters de mquinas conectadas a una red de
alta velocidad sobre las cual se distribuye entre los nodos las tareas de procesamiento.
Tolerancia a fallos y consistencia: en algunas aplicaciones la integridad de la informacin

es crucial y por eso se decide distribuirla, generalmente mediante rplicas, pues el riesgo de
perder informacin por un fallo en un equipo es inaceptable.
Movilidad: la gran cantidad de dispositivos mviles existentes hoy en da hacen que un

usuario muchas veces acceda a su informacin desde dos, tres o ms dispositivos diferentes.
Este escenario plantea un desafo para los sistemas que deben desligar la informacin de los
soportes. La solucin ms habitual a este problema es la implementacin de espacios
virtuales o en la nube, donde cada dispositivo del usuario actual como una extensin de
dicho espacio, sincronizando en forma bi-direccional los cambios realizados. Ejemplos de
estas arquitecturas son Gmail o Drive de Google o Dropbox.
Ubicuidad: contemplan entornos donde los recursos estn distribuidos y los usuarios se
movilizan entre ellos. Las aplicaciones intentan generar un comportamiento inteligente en
Luis Ignacio Aita
Pgina 21
funcin de las necesidades del usuario, los tipos de recursos y la disponibilidad de los
mismos.
En cuanto a los entornos, podemos considerar a Internet como el ms generalizado, en la cual se
pueden desplegar aplicaciones distribuidas de ndole muy variada, con ciertas limitaciones de
rendimiento y seguridad. La World Wide Web (WWW) es el mximo exponente de aplicacin
distribuida sobre Internet y es la forma de acceso ms habitual a otras aplicaciones.
Si embargo muchas aplicaciones distribuidas pueden tener requisitos de seguridad o rendimiento
que hagan inviable su implementacin sobre Internet, para las cuales es necesario utilizar Intranets
o entornos ubicuos especficos.
En cuando aplicaciones comerciales, muchas veces los sistemas distribuidos reemplazan a
aplicaciones histricamente desarrolladas en ambientes centralizados, como pueden ser reservas en
cadenas hoteleras o lineas areas, sistemas bancarios, cadenas de retail con muchas sucursales, etc.
Las aplicaciones multimedia como videoconferencias, streaming de video, radios en linea,
vigilancia, etc., tambin se estn incorporando a los sistemas distribuidos debido a sus
requerimientos de velocidad y regularidad de la transmisin.
4.1.4 Ventajas
Podemos enumerar a modo de resumen alguna de las principales ventajas de los sistemas
distribuidos:
Escalabilidad horizontal o crecimiento por incrementos o a demanda. Esta es una

ventaja fundamental de los sistemas distribuidos que permiten aumentar cualquier de las
capacidades del sistema (cmputo, almacenamiento, etc.) en forma gradual y a medida que
el uso del mismo lo demande.
Confiabilidad. Debido a la distribucin de la carga de trabajo y a la replicacin de la

informacin, los sistemas distribuidos pueden estar disponibles en un porcentaje muy
cercano al 100% del tiempo.
Mayor flexibilidad. Los sistemas distribuidos ofrecen mayor amplitud de criterios a la hora
de administrar los recursos. Pueden considerarse aspectos como la demanda de uso,
ubicaciones geogrficas, costos, etc.
Luis Ignacio Aita
Pgina 22
Comunicacin. Muchas veces los sistemas distribuidos facilitan la posibilidad de compartir

informacin y recursos entre los usuarios, mejorando la comunicacin entre las personas.
4.1.5 Desventajas
Los sistemas distribuidos presentan ciertas desventajas, algunas de las cuales han provocado que
aplicaciones comerciales que estaban operando se discontinuaran o adaptaran.
Complejidad del software. Esta es la principal desventaja de los sistemas distribuidos. La

gestin de informacin y recursos compartidos en forma consistente genera mecanismos de
solucin que muchas veces causan mermas en el rendimiento que son inaceptables. Otras
veces el costo de implementar una solucin ptima a este problema puede hacerlos
inviables.
Paralelismo. La divisin de la carga de trabajo en aplicaciones tpicamente diseadas para

ejecucin secuencial muchas veces es una tarea compleja y costosa.
Concurrencia. Para lograr concurrencia se deben implementar mecanismos de control para

las condiciones de competencia, evitar los abrazos mortales o deadlocks y los ciclos de
espera circulares. Esto tambin puede resultar complejo o costoso en algunos casos o
provocar una carga adicional de trabajo no deseada en el sistema.
4.1.6 Perspectivas
Debido al auge de los dispositivos porttiles de los ltimos aos que ha dado lugar a lo que se
denomina habitualmente Informtica mvil, los equipos salen de las redes locales para descubrir
nuevos recursos y deben adaptarse a condiciones de red ms variables y deben poder funcionar en
forma offline en determinadas circunstancias. Han surgido nuevos protocolos para soportar estas
condiciones y se establecen redes ad-hoc aprovechando las ventajas de las redes inalmbricas.
Un escaln ms arriba podemos encontrar a los sistemas ubicuos, en los cuales dispositivos
mviles de gran potencia y reducido tamao se adaptan a un entorno naturalmente cambiante,
mediante aplicaciones que descubren recursos y servicios configurndose en forma dinmica,
adaptando las interfaces de usuarios en cada caso. Ejemplos de este tipo de dispositivos son los
telfonos inteligentes o smartphones, tablets, sistemas de navegacin integrados en automviles,
etc.
Luis Ignacio Aita
Pgina 23
Los sistemas ubicuos plantean numerosos retos de amplio espectro tecnolgico en mbitos de
aplicacin muy diversos tales como el hogar, comercios, salud, educacin, robtica y turismo por
citar solo algunos.
4.2
Bases de Datos Distribuidas
Cuando los datos de una organizacin son gestionados por un sistema que permite que sean
accedidos por diversos usuarios y aplicaciones en entornos distribuidos es posible afirmar que se
trata de una base de datos distribuida. Este tipos de sistemas es un subconjunto de los sistemas
distribuidos mencionados en la seccin anterior, diseados especficamente para almacenar datos e
informacin en entornos distribuidos.
4.2.1 Conceptos
Es importante diferenciar un Sistema Gestor de Bases de Datos (SGBD) centralizado al cual se
puede acceder a travs de la red de un Sistema Gestor de Bases de Datos Distribuidas (en adelante
SGBDD), en donde los datos estn fsicamente distribuidos en una serie de nodos a travs de una
red y el sistema permite gestionar los datos de manera transparente.
Tambin existen las arquitecturas multiprocesador que comparten espacios de memoria y
almacenamiento (fuertemente acopladas) o solo espacio de almacenamiento (dbilmente acoplados)
y sistemas de bases de datos que utilizan estas arquitecturas, pero no son objeto del presente trabajo.
Otra tcnica utilizada para la distribucin de datos es la denominada arquitectura con nada
compartido, o shared nothing, donde cada nodo tiene su propia memoria y almacenamiento y solo
se comunican a travs de las redes de conexin. Existe una seccin posterior dedicada a este tipo de
arquitecturas.
En esta seccin se describen especficamente los SGBDD, los cuales definiremos como una
coleccin de mltiples bases de datos interrelacionadas lgicamente, distribuidas por una red de
computadores, y gestionadas por un sistema software que maneja la base de datos distribuida en
forma transparente para el usuario[Elmasri, Navathe 2002].
Los SGBDD tambin cumplen con las propiedades de los sistemas distribuidos mencionadas en
la seccin anterior, como: transparencia, tolerancia a fallos, consistencia, alta disponibilidad y
fiabilidad, escalabilidad, etc.
Luis Ignacio Aita
Pgina 24
Vale destacar un tipo de transparencia particular de los SGBDD denominado transparencia de

fragmentacin que surge de la divisin y posterior recuperacin de los datos entre distintos nodos.
Existen dos tipos de tcnicas de fragmentacin, fragmentacin horizontal, en la cual se crean
conjuntos de registros de datos segn criterio definido previamente y se distribuyen estos conjuntos
entre los nodos del sistema distribuido y fragmentacin vertical, donde cada conjunto se forma
con columnas de la tabla original. Se profundizarn estas cuestiones de diseo en la seccin 4.2.3.
4.2.2 Diseo y arquitecturas

Los SGBDD se desarrollan e implementan en contexto cliente-servidor[Kurose, Ross 2010]. En
este tipo de arquitecturas tenemos dos componentes principales y claramente identificados en la
comunicacin:
Cliente: es quien inicia la comunicacin y generalmente demanda servicios o acceso a

recursos.
Servidor: es la parte del sistema que proporciona estos servicios a los clientes.
En lo referente a las partes que componen un SGBDD podemos agrupar los mdulos del
software en tres grupos principales:
Software de servidor: gestiona los datos locales de un nodo en forma similar a los SGBD
centralizados.
Software del cliente: se ocupa normalmente de las interfaces de usuario y de todas las
tareas inherentes a la distribucin.
Software de comunicaciones: brinda soporte para que clientes y servidores se comuniquen

y se transmitan las instrucciones y los datos entre los nodos.
Existen cuatro dimensiones a considerar a la hora de elaborar una estrategia de diseo de una
base de datos distribuidas, tres de ellas en comn con los SGBD centralizados ms una dimensin
adicional para el diseo de la distribucin.
Las tres primeras dimensiones a considerar son:
Nivel de comparticin: que puede ser inexistente, solo de datos o de datos y programas.
Acceso a los datos: estticos, si no vara con el tiempo o dinmicos si lo hacen.
Luis Ignacio Aita
Pgina 25
Nivel de conocimiento de acceso: los diseadores pueden no conocer como los usuarios
acceden a los datos, conocer parcialmente o contar con la informacin completa respecto al
modo de acceso.
En cuanto a la estrategia de distribucin, puede abordarse de dos formas distintas:
Ascendente o botton-up: partiendo de los esquemas existentes en cada nodo, se construye

un esquema conceptual global y finalmente se disea la distribucin. Se suele utilizar este
enfoque para integrar varias BD centralizas ya existentes.
Descendente o top-down: no se considera la existencia de DB previas y se parte desde cero

en el diseo y construccin del sistema, comenzando por el anlisis de requisitos, el diseo
conceptual, el diseo de la distribucin, el diseo fsico y los ajustes y monitoreo finales.
Dentro del diseo de la distribucin existen dos actividades importantes a destacar: la

fragmentacin y la asignacin.
4.2.2.1 Fragmentacin
Mediante este proceso se dividen los datos de una tabla o conjunto de tablas en unidades de
menor tamao, siendo el objetivo principal del diseo encontrar la unidad ptima para realizar la
fragmentacin.
Es posible enumerar una serie de ventajas de la fragmentacin, entre las que se destacan:
Ventajas de uso, aprovechando las vistas que generan las aplicaciones y que normalmente
constituyen un subconjunto de datos. Pueden considerarse a estos conjuntos como unidades
de distribucin.
Si se almacenan los subconjuntos de datos en lugares cercanos a donde ms se utilizan,

puede aumentarse el nivel de eficiencia. Por ejemplo, se pueden dividir los datos por
departamento o sucursales de una organizacin y ponerlos a disposicin en el lugar fsico de
mayor conveniencia. Esta ventaja toma relevancia en SGBDD distribuidos geogrficamente,
donde servidores y clientes muchas veces estn conectados por canales de comunicacin de
velocidad media o lenta.
Es posible paralelizar una transaccin entre los fragmentos, aumentando los niveles de
concurrencia.
Luis Ignacio Aita
Pgina 26
Almacenando en un nodo solo los datos a los que los usuarios de ese nodo tienen acceso se
minimizan los riesgos de accesos no autorizados, mejorando la seguridad del sistema.
Existen a su vez algunas desventajas de la fragmentacin:
Si una aplicacin necesita obtener o actualizar datos distribuidos en ms de un fragmento se

ver notablemente afectado el rendimiento de estas transacciones.
Si una vista debe operar sobre mltiples fragmentos aumentarn las operacin de
verificacin de integridad y seguridad afectando tambin el rendimiento.
De acuerdo a la unidad de distribucin que se decida utilizar la fragmentacin puede clasificarse

en tres tipos diferentes:
Horizontal: se forman los subconjuntos a distribuir a partir de diversos registros o tuplas de

la tabla segn cumplan con una determinada condicin. Este tipo de fragmentacin puede
expresarse mediante consultas de seleccin.
Vertical: los conjuntos se forman agrupando atributos de la tabla y proyectando la relacin

global sobre cada grupo. Solo se considera correcta si cada atributo se mapea en al menos un
atributo del fragmento.
Mixta: se produce cuando se aplican ambos tipos de fragmentacin, pudiendo

implementarse primero en forma horizontal y luego vertical o viceversa.
4.2.2.2 Asignacin
Consiste en el proceso de distribucin de los fragmentos entre los nodos del sistema. La solucin
ptima puede disearse considerando el costo mnimo de la operacin, considerando costos de
procesamiento, comunicaciones y almacenamiento, o buscando obtener mejores mtricas de
rendimiento optimizando tiempos de respuestas y productividad.
Una vez que se asignan los datos, los fragmentos pueden replicarse para obtener mejoras en
seguridad, disponibilidad y velocidad de acceso a los datos que contienen. La replicacin puede ser
inexistente, parcial o completa, dependiendo de la estrategia de diseo elegida.
La replicacin mejora notablemente el rendimiento de las consultas penalizando las inserciones o
actualizaciones de datos, por lo cual es mayormente utilizada en aquellos fragmentos con mayor
nivel de operaciones de lectura y con menos cantidad de escrituras.
Luis Ignacio Aita
Pgina 27
4.2.3 Transacciones
La distribucin de los datos y las operaciones en un SGBDD agrega un nivel extra de
complejidad a la tarea de lograr una ejecucin consistente de las operaciones sobre los datos. Al
igual que todo SGBD se deben respetar las cuatro propiedades bsicas de toda transaccin (ACID
por sus siglas en ingls):
Atomicidad: toda transaccin es una nica unidad de operacin que debe ejecutarse
completamente o no ejecutarse.
Consistencia: una transaccin se ejecuta partiendo de un estado consistente de los datos que
debe mantenerse al finalizar su ejecucin.
Aislamiento: una transaccin no debe mostrar sus resultados hasta tanto no finalizar. Si
varias transacciones concurrentes acceden a un mismo conjunto de datos, deben ejecutarse
como si lo hicieran en serie.
Durabilidad: una vez ejecutada una transaccin sus resultados son permanentes.
La existencia de varias locaciones de datos sobre los cuales puede ejecutarse una transaccin
obliga a los SGBDD a proveer una funcionalidad de coordinacin global de las transacciones que
asegure que se respeten estas propiedades.
Es decir, el coordinador recibe el pedido de transaccin y lo divide en una secuencia de
transacciones que reparte entre los nodos involucrados, encargndose a su vez de gestionar los
resultados, confirmando o rechazando la transaccin en caso de fallos.
4.2.4 Control de concurrencia

El control de concurrencia debe garantizar, por un lado, la consistencia de los datos luego de
ejecutar transacciones y adems cada accin atmica debe completarse en un tiempo finito.
Adems de los problemas de concurrencia inherentes a todos los sistemas de bases de datos, es
decir, prdida de datos, dependencias e inconsistencias, en los SGBDD se producen problemas
especficos relacionados con mantener la consistencia en las copias mltiples (rplicas) y
fragmentacin de datos, principalmente vertical.
Para que el mtodo de control de concurrencia sea correcto, las operaciones de una transaccin
deben aparecer antes o despus de las operaciones de otras transacciones, pero no deben
entremezclarse. La ejecucin de las transacciones siempre debe ser en serie.
Luis Ignacio Aita
Pgina 28
Es necesario utilizar dos soluciones para poder implementar control de concurrencia en un

entorno de bases de datos distribuidos:
Bloqueos (locks): para garantizar la consistencia en ejecuciones concurrentes, evitando que

se produzca abrazos mortales o deathlocks.
Marcas de tiempo: que aseguren la ejecucin de transacciones en serie a nivel global.
Para ambas soluciones existen diversos protocolos que pueden utilizarse.
4.2.5 Consultas
El procesamiento de las consultas en ambientes distribuidos es mucho ms complejo que en las
bases de datos centralizadas, y es un aspecto de vital importancia en su rendimiento.
El procesador de consultas es el responsable de transformar las consultas de alto nivel recibidas
por parte de usuarios y aplicaciones en comandos de manipulacin de datos de bajo nivel,
minimizando el consumo de recursos del sistema, y en el caso de los SGBDD el lgebra relacional
no es suficiente para planificar la estrategia de ejecucin, debiendo complementarse con
optimizaciones en el intercambio de datos entre nodos.
Entre estas operaciones se destacan la eleccin del orden de las operaciones, el mejor sitio para
procesar los datos y la forma en que deben finalmente ser transformados.
Una simplificacin de la funcin de costo que el procesador de consultas de un sistema
distribuido debe minimizar es la siguiente:
Costo total = costo de I/O + costo de CPU + costo de comunicaciones.
En distintos ambientes los pesos de cada uno de los sumandos puede variar, pudiendo ser
despreciable el costo de alguno de ellos. Por ejemplo, en un sistema que utilice redes WAN el costo
de comunicacin ser dominante, en tanto que en redes de alta velocidad los tres factores se
equiparan.
4.2.6 Clasificacin
Clasificaremos a las bases de datos distribuidas en base a diversos criterios de diseo. En primer
lugar, teniendo en cuenta la forma en que los datos se almacenarn en el sistema, se pueden
clasificar en:
Luis Ignacio Aita
Pgina 29
Centralizadas: solo los clientes que acceden a la base de datos estn distribuidos, con lo
cual solo es posible obtener algn tipo de procesamiento de datos distribuido sin ninguna
otra ventaja de los SGBDD.
Replicadas: cada nodo tiene una copia completa de la base de datos, logrando un alto nivel
de fiabilidad y disponibilidad, pero penalizando notoriamente las actualizaciones de datos.
Vale la pena su utilizacin en sistemas con gran cantidad de consultas y pocas escrituras.
Particionadas: solo existe una copia de cada elemento de dato, pero la informacin se
distribuye a travs de los nodos mediante tcnicas de fragmentacin.
Hbridas: combinan fragmentacin y replicacin de datos en un diseo hbrido.
Otro criterio por el cual es posible clasificar a los SGBDD es segn el hardware y software
utilizado como base para soportarlos. Es posible identificar dos tipos de sistemas mediante este
criterio:
Homogneas: todos los nodos utilizan el mismo software de gestin de bases de datos,
hardware de prestaciones similares y conocen al resto de los nodos cooperando en conjunto
para procesar las transacciones. Tienen menor autonoma en cada nodo pero el diseo e
implementacin suele ser ms sencillo que las heterogneas.
Heterogneas: tambin denominadas multibase utilizan distintos gestores de bases de

datos siendo cada nodo esencialmente autnomo. Algunos nodos pueden no conocer la
existencia de los dems y pueden proporcionar servicios limitados para la cooperacin en la
resolucin de las transacciones.
Vale mencionar un tipo particular de bases de datos distribuidas, los Sistemas de Bases de Datos
Federados. Estn compuestos por un conjunto de sistemas de bases de datos autnomos que
funcionan en forma cooperativa.
En un sistema federado los usuarios tienen acceso a los datos a travs de una interfaz comn pero
no existe un esquema global que describa a todos los datos de las distintas bases de datos, en su
lugar hay varios esquemas unificados, cada uno describiendo porciones de bases de datos y archivos
para el uso de cierta clase de usuarios.
Luis Ignacio Aita
Pgina 30
4.2.7 Ventajas y desventajas

A continuacin se enumeran las principales ventajas y desventajas de las bases de datos
distribuidas, muchas de ellas compartidas con los sistemas distribuidos.
4.2.7.1 Ventajas
Potencia la naturaleza distribuida de las aplicaciones de este tipo.
Refleja mejor la estructura de organizaciones grandes.
Permite crecimiento modular
Economa a la hora de escalar el sistema.
Mayor autonoma
Mayor disponibilidad y fiabilidad
Mayor rendimiento, debido al acercamiento de los datos al origen de las consultas, la

reduccin del tamao de las bases de datos locales por la fragmentacin y la posibilidad de
paralelizar las consultas.
4.2.7.2 Desventajas
Mayor complejidad de diseo e implementacin. Un diseo inadecuado de la replicacin o

la fragmentacin puede convertir las ventajas en desventajas.
Menor cantidad de estndares y casos de xito.
Altos costos para lograr transparencia.
Mayor complejidad para garantizar la seguridad de acceso a los datos. Se debe realizar
control de rplicas y errores de red.
4.2.7.3 Perspectivas
Los sistemas de bases de datos han evolucionado naturalmente hacia esquemas distribuidos de la
mano de los requerimientos de las propias organizaciones que los utilizan. Muchos productos
comerciales de primera linea como Oracle, Microsoft MSSQL Server y MySQL poseen versiones
distribuidas de sus gestores de bases de datos.
En los ltimos aos han surgido un conjunto de bases de datos denominadas NoSQL como
respuesta a la necesidad de almacenamiento y recuperacin de informacin no estructurada.
Describiremos en mayor detalle este tipo de bases de datos en la siguiente seccin.
Luis Ignacio Aita
4.3
Pgina 31
Bases de Datos NoSQL
4.3.1 Introduccin
Para aproximarnos al concepto de bases de datos NoSQL y al concepto BigData primero es
necesario repasar brevemente las bases de datos basadas en SQL, que son ms conocidas por la
mayora de los usuarios en niveles muy diferentes, desde aquellos que operan diariamente con ellas
y manejan fluidamente el lenguaje, las reglas de normalizacin y las limitaciones que conlleva,
hasta aquellos que solo las utilizan.
Las bases de datos relacionales, tpicamente gestionadas con sistemas como Oracle, MySQL,
Microsoft SQL Server, PostgreSQL, etc, suponen una operativa que resulta natural: siguen reglas
ACID (Atomicity, Consistency, Isolation y Durability, o Atomicidad, Consistencia, Aislamiento y
Durabilidad), lo que permite que las instrucciones puedan ser consideradas una transaccin, y
responden a una visin sencilla, en la que un dato se almacena de una manera inequvoca y con
relaciones bien definidas, es decir, la visin de tablas con filas y columnas en las que una consulta
siempre devuelve los mismos campos.
Si extendemos el concepto podemos dar lugar a realidades cada vez ms frecuentes en la
operatoria habitual en nuestros das. No todos los datos tienen una estructura relacional, muchas
veces se dejan fuera de anlisis todo aquello que la forma de operacin de las bases de datos
tradicionales no es capaz de procesar. Las bases de datos NoSQL (Not Only SQL) suponen
flexibilizar muchas de las limitaciones inherentes a las bases de datos convencionales y a la forma
de trabajar con ellas. Colecciones de documentos con campos definidos de manera laxa, en lugar de
tablas con filas y columnas, que permiten anlisis mucho ms rpidos y eficientes y, sobre todo, no
limitados a la estructura convencional. La idea es almacenar datos de manera masiva, lo que
responde muy bien a la enorme cantidad y variedad de datos que genera el mundo actual, y
analizarlos sin seguir necesariamente estndares que no se adaptan a ellos, donde las bases de datos
relacionales resultan costosas y lentas para esta problemtica. La alternativa NoSQL aplicada a
determinados contextos organizacionales puede resultar ms eficiente y econmica para manipular
datos sin tener necesariamente que adaptarlos a una estructura rgida. Un sistema de este tipo no es
siquiera una base de datos entendida como tal, sino un sistema de almacenamiento distribuido para
gestionar datos dotados de una cierta estructura, que adems puede ser flexible.
Luis Ignacio Aita
Pgina 32
Este tipo de estructuras de datos muchas veces supone un problema para la mayora de la gente,
cuyos esquemas mentales se adaptan a un sistema rgido, con normas claras y estructuras marcadas.
Los paralelismos con los almacenes divididos en estanteras, archivadores y carpetas son algo que
nos funciona mentalmente. Sin embargo, por ejemplo, cmo podramos gestionar bsquedas
enormes en bases de datos que contienen referencias completamente heterogneas entre s y con
relaciones de todo tipo, no necesariamente nicas? En muchos casos, hablamos de sistemas que han
sido precisamente desarrollados por empresas como Google, Yahoo!, Facebook y similares para
gestionar sus propias operativas, usando casi siempre cdigo abierto, con el fin de obtener una
estructura que, con un costo y un rendimiento razonable, les permita tratar enormes cantidades de
datos con muchsimas relaciones muy complejas entre s.
Dentro de este contexto, la recuperacin de la informacin presenta varios problemas, siendo una
solucin a este inconveniente el uso de estructuras de datos que permitan ser rpidamente
consultadas. El indexado transforma los datos desde su forma original en una estructura que facilita
la bsqueda y recuperacin de los mismos en forma rpida y precisa, por ejemplo un ndice
invertido [Satnam Alag 2009], un ndice de citas, una matriz o un rbol.
El proceso de indexado generalmente requiere un anlisis y procesamiento de los documentos a
incluir en el ndice: lematizacin, tokenizacin, anlisis fontico, etc. Estos pasos introducen
problemas y desafos importantes al momento del procesamiento [Satnam Alag 2009].
4.3.2 Definicin
Debido al origen de las bases de datos NoSQL y a que es un trmino reciente existen muchas
definiciones poco formales para describirlos. Se citan a continuacin un par de definiciones para
aproximarnos al concepto.
El sitio nosql-database.org por ejemplo las describe como la Siguiente generacin de bases de
datos comnmente orientadas hacia algunos de los siguientes puntos: ser no-relacional,
distribuida, de cdigo abierto y escalable horizontalmente.
La intencin original han sido las modernas bases de datos a escala web. El movimiento
comenz a principios de 2009 y ha crecido rpidamente. A menudo se suelen considerar ms
caractersticas tales como Sin Esquemas, facilidad de replicacin, APIs simples, consistencia de
datos eventual (BASE, no ACID), grandes cantidades de datos, etc. As que el trmino engaoso
Luis Ignacio Aita
Pgina 33
NoSQL (que la comunidad actualmente traduce como Not Only SQL) debe ser considerado un alias
de las definiciones anteriores.
Citando el whitepaper [Oracle NoSQL Database 2011] podemos ampliar el concepto de bases de
datos NoSQL:
...NoSQL se caracteriza a veces por el acrnimo BASE:
Basically Available: Uso de tcnicas de replicacin y sharding para reducir la probabilidad de
falta de servicio, es decir, se dividen los datos en varios servidores de almacenamiento diferentes,
permitiendo al sistema estar siempre disponible, incluso si una parte de los datos no est
disponible por un perodo corto de tiempo.
Soft state: Mientras que los sistemas ACID asumen la consistencia como el requisito
fundamental, los sistemas NoSQL permiten que lo datos sean inconsistentes delegando esta
responsabilidad en los programadores.
Eventually consistent: aunque las aplicaciones deben tratar con coherencia instantnea, los
sistemas NoSQL aseguran que en algn momento futuro los datos tomaran un estado coherente. En
contraste con los sistemas ACID que obligar a cumplir la consistencia en cada transaccin, NoSQL
garantiza consistencia solo en un perodo futuro de tiempo no definido.
En resumen, son bases de datos pensadas para manipular grandes cantidades de datos en forma
rpida, permiten escalabilidad horizontal y ofrecen mayor flexibilidad para el almacenamiento de
datos debido a que no imponen una estructura de tablas y relaciones sino que ofrecen otros
formatos. En base a estos formatos surgen las principales clasificaciones existentes: documentales,
de grafos, clave/valor, multivalor, orientadas a objetos y tabulares.
Debido a estas definiciones bastante amplias, han surgido numerosas bases de datos que se
consideran NoSQL y existen herramientas que podran ser consideradas NoSQL aunque
normalmente no se las cita en esta forma.
Un ejemplo claro es la herramienta utilizada para crear el ndice que se utilizar en el presente
trabajo, Apache Solr, la cual no aparece catalogada como base de datos NoSQL en la mencionada
web, sin embargo es posible considerar a la herramienta como tal dado que cumple con varias de las
premisas listadas en la definicin previa. Por ejemplo, como veremos en el captulo 6, para el
proyecto Zonales se decidi almacenar informacin en formato JSON en el ndice Solr para obtener
mejoras de performance en la recuperacin.
Luis Ignacio Aita
Pgina 34
4.3.3 Tipos de bases de datos NoSQL

Cuando pensamos en bases de datos NoSQL muchas veces es difcil optar por una determinada
solucin, an cuando se tienen los requisitos esperados claramente definidos. Existen
aproximadamente 150 productos de bases de datos considerados NoSQL y ninguno de ellos ha
ganado una slida reputacin para un determinado uso como si sucede con los productos de bases
de datos relacionales.
Existen tambin diversos criterios para clasificar este tipo de bases de datos. Se mencionan a
continuacin dos de ellos:
Segn la estructura de los datos a almacenar, est es la forma ms habitual de clasificacin.
Segn el teorema CAP (Consistency, Availability, Partition Tolerance)
4.3.3.1 Clasificacin segn la estructura de datos
De clave-valor: la idea principal aqu es utilizar una tabla hash donde hay una clave nica
y un puntero a un elemento de datos en particular. El modelo clave / valor es el ms simple y
ms fcil de implementar, pero es ineficiente cuando slo est interesado en consultar o
actualizar parte de un valor, entre otras desventajas. En esta categora podemos clasificar a
DynamoDB y Redis.
Orientadas a columnas: en este tipo de bases de datos los datos se almacenan en las clulas
agrupadas en columnas de datos en lugar de filas. Las columnas estn lgicamente
agrupadas en familias de columnas. Cada familias de columnas puede contener un nmero
virtualmente ilimitado de columnas que se pueden crear en tiempo de ejecucin o en la
definicin del esquema. Leer y escribir se hace utilizando columnas en lugar de filas.
Cassandra y Hbase son bases de datos orientadas a columnas.
Orientadas a documentos: los datos se almacenan en forma similar a las bases de datos de
tipo clave-valor, pero los valores almacenados (referidos como "documentos")
proporcionan una cierta estructura y codificacin para la administracin de los datos. XML,
JSON (Java Script Object Notation) BSON (que es una codificacin binaria de objetos
JSON) son algunas de las codificaciones estndares ms comunes. MongoDB y CouchDB
son ejemplos de este tipo.
En grafo: basadas en la teora de grafos utilizan nodos y arcos para representar los datos
almacenados. Tanto los nodos como los arcos tienen algunas propiedades definidas. Son
Luis Ignacio Aita
Pgina 35
muy tiles para guardar informacin en modelos con muchas relaciones, como redes y
conexiones sociales. Ejemplos de esta categora son Neo4j y Infinite Graph.
4.3.3.2 Clasificacin segn el teorema CAP
El teorema CAP o teorema Brewer afirma que en sistemas distribuidos no es posible garantizar al
mismo tiempo consistencia, disponibilidad y tolerancia a particiones (Consistency, Availability,
Partition Tolerance).
Las bases de datos NoSQL utilizan diversos mtodos para ser escalables y distribuidas, por lo
cual cada una cumple distintos puntos del teorema CAP. Segn las condiciones que cumplen del
teorema se clasifican en:
AP: garantizan disponibilidad y tolerancia a particiones, pero no la consistencia, al menos

de forma total. Algunas de ellas consiguen una consistencia parcial a travs de la replicacin
y la verificacin.
CP: garantizan consistencia y tolerancia a particiones. Para lograr la consistencia y replicar

los datos a travs de los nodos, sacrifican la disponibilidad.
CA: garantizan consistencia y disponibilidad, pero tienen problemas con la tolerancia a

particiones. Este problema lo suelen gestionar replicando los datos
4.3.4 Tcnicas utilizadas por las bases de datos NoSQL.

Se resume a continuacin algunas de las tcnicas utilizadas en bases de datos NoSQL que son de
inters para el presente trabajo.
4.3.4.1 Particionamiento horizontal mediante shards
Se utiliza un proceso de indexado transformando los datos desde su forma original en una
estructura que facilita la bsqueda y recuperacin de los mismos en forma rpida y precisa, por
ejemplo un ndice invertido [Elmagarmid, Rusinkiewicz, Sheth 1999], un ndice de citas, una matriz
o un rbol.
Estas tcnicas facilitan la implementacin y escalabilidad en ambientes heterogneos mediante el
uso del concepto de base de datos de particin horizontal o sharding [zsu, Valduriez 1999; Taniar
et. al. 2008; Dean, Ghemawat 2004; Stonebraker 1986].
Se pueden utilizar bases de datos no convencional para almacenar el ndice de bsqueda (listas
invertidas), provee mltiples capacidades para el escalado horizontal, permitiendo dividir la carga
Luis Ignacio Aita
Pgina 36
de trabajo entre mltiples instancias lo que permite una fragmentacin horizontal de los mismos
entre mltiples servidores de ndices y documentos, a los cuales se les denomina shards.
Las bsquedas son luego redirigidas a cada shard, y finalmente una respuesta nica es construida
en base a los resultados obtenidos de cada uno. Esta tcnica es utilizada especialmente cuando se
cuenta con un gran volumen de datos sobre el cual realizar consultas.
Las bsquedas puede ser dirigida a cualquier instancia, y sta delegar la misma a los shards
especificados, y responder la consulta agregando los mltiples resultados.
Para comprender el escalonado horizontal es necesario tambin comprender la tcnica que se
describe en el siguiente punto.
4.3.4.2 Shared Nothing
Segn Michael Stonebraker: Consiste en una arquitectura distribuida en el que cada nodo es
independiente y auto-suficiente, y tiene un nico punto de contencin en todo el sistema.
El concepto de Shared Nothing parte de la independencia de los nodos, mediante la distribucin
de la informacin y de las acciones sobre dichos nodos.
Se podra decir que un Shard es un nodo Shared Nothing donde se administra un conjunto de
documentos indexados segn algn criterio y en donde se los puede someter a mecanismos de
bsqueda de informacin, jerarquizacin y ordenamiento de la informacin recuperada dependiendo
de necesidades particulares de informacin. Por ejemplo se podran realizar distribuciones:
geogrficas, temticas, ontolgicas, segmentacin segn preferencias, etc. o inclusive
combinaciones de ellas.
En todos los casos se puede combinar con tcnicas de bases de datos tradicionales, como la
replicacin y la paralelizacin mediante esquemas de Shared Disk (cluster tradicional, como por
ejemplo la implementacin de un blade con una Storage Area Network) [zsu, Valduriez 1999;
Taniar et. al. 2008; Stonebraker 1986].
En general el concepto de Shared Nothing garantiza niveles de consistencia de informacin,
pero no es ACID Compliant, esta situacin facilita la conformacin heterognea de nodos y la
independencia de procesamiento ya que cada nodo posee su propia unidad de memoria,
almacenamiento en disco y procesamiento.
Luis Ignacio Aita
Pgina 37
Cada nodo es independiente y estn conectados, no delegando responsabilidad alguna en la

coordinacin de los nodos.
Claramente la arquitectura requiere de un esfuerzo extra en la coordinacin de los nodos del
cluster de datos, para ello existen algunas soluciones:
4.3.4.3 Replicacin con balanceo de carga
Esta
arquitectura debe garantizar un conjunto de nodos con la informacin replicada y
consistente en todos los nodos. En este caso el motor de bsqueda cuenta con un pooling de nodos
de datos en los cuales buscar la informacin.
La arquitectura no paraleliza las bsquedas, simplemente distribuye la carga entre los nodos.
Como los nodos son independientes y auto-suficientes son capaces de responder consistentemente a
la consulta realizada ya que la responsabilidad de recuperacin est en el nodo de datos y la
responsabilidad de distribucin de carga en el balanceador.
La desventaja de este mtodo es que ni resuelve el problema espacial de la informacin ni
paraleliza la bsqueda [Valduriez 1992].
4.3.4.4 Scatter and Gather
El mtodo realiza un broadcast de la bsqueda de informacin requerida en sus nodos conocidos,

realizando una dispersin de la misma. Cada nodo (independiente de los dems) tiene la capacidad
de elaborar una respuesta con la informacin que contiene dicho nodo. Todas las respuestas se
concentran en el nodo que realiz la dispersin y ste es responsable de consolidar las mismas en
una nica (y consistente) respuesta a a la peticin.
Una ventaja adicional del mtodo es que a su vez los nodos de datos pueden ser dispersores en
nuevos nodos (conocidos por l). Conformando de esta forma una red de nodos independientes que
contienen informacin.
Las ventajas en este caso son el particionamiento de la informacin y la paralelizacin de las
bsquedas. La desventaja es una sobrecarga en la distribucin de la informacin, especialmente si
se desea realizar con alguna lgica de segmentacin en particular, por ejemplo geogrfica, tipo de
contenido, atributos ontolgicos, etc. En este ltimo caso se requiere conocimiento e informacin
sobre los contenidos (datos) a ser almacenados, siendo en algunos casos relativamente compleja su
resolucin, especialmente ante la aplicacin de reglas ontolgicas sobre los contenidos [ Taniar et.
al. 2008; Valduriez 1992; White 2011; Lakshman, Malik 2010].
Luis Ignacio Aita
Pgina 38
Para este caso es interesante poder aplicar la tcnica del siguiente punto.
4.3.4.5 Map / Reduce
Esta es una buena tcnica para procesar gran volumen de datos en paralelo. El modelo provee un
mecanismo de particionamiento de informacin que permite distribuir inteligentemente, de
acuerdo a reglas pre-definidas, los datos en distintos nodos auto-contenidos.
Map /reduce es una tcnica que implica paralelizar los datos que es distinto a paralelizar las
tareas. Obviamente la paralelizacin de los datos permite paralelizar el procesamiento en las
bsquedas, pero la clave de la tcnica se basa en la inteligencia de separacin de los datos. A su vez
una ventaja adicional radica en el ahorro de espacio en el resultado de las claves compartidas al
reducirlas dentro de un documento [Venner 2009; Dean, Ghemawat 2004].
4.3.5 Gestores de bases de datos NoSQL

Se listan a continuacin algunos de los productos NoSQL de mayor utilizacin. Describiremos
en mayor medida la base de datos MongoDB debido a que forma parte de la arquitectura del
proyecto Zonales.
4.3.5.1 DynamoDB
DynamoDB es una base de datos NoSQL desarrollada por Amazon y aadida al conjunto de
aplicaciones que ofrece sobre la nube. Al igual que la mayora de los servicios ofrecidos por
Amazon puede ser gestionada en unos pocos clics desde la consola de administracin de AWS
(Amazon Web Services) y se pueden aumentar o disminuir los recursos segn las necesidades
consultando las estadsticas de rendimiento.
DynamoDB no tiene un esquema fijo sino que cada elemento de datos puede tener un nmero
diferente de atributos y se identifica con una clave nica que es el nico elemento obligatorio
(clave-valor). Se pueden usar varios tipos de datos como strings, nmeros o conjuntos. Ofrece un
servicio de consultas flexible que permite consultar a travs de atributos no claves, utilizando
ndices secundarios globales o locales.
Puede
obtenerse
ms
informacin
desde
la
propia
web
de
Amazon
[http://aws.amazon.com/es/dynamodb] o consultado el paper [DeCandia et al., 2007]

4.3.5.2 Apache Cassandra
La arquitectura de Cassandra se basa en asumir que ocurren fallos en los sistemas de software y
hardware, abordando el problema mediante el empleo de un sistema distribuido peer-to-peer a
Luis Ignacio Aita
Pgina 39
travs de nodos homogneos donde los datos se distribuyen entre todos los nodos del cluster. Cada
nodo intercambia informacin con otros nodos en el cluster cada segundo. Se registra en forma
secuencial en un log todas las actividades de escritura de datos para asegurar la durabilidad de los
mismos.
Cassandra es una base de datos orientada a columnas. La arquitectura de Cassandra permite a
cualquier usuario autorizado conectarse a cualquier nodo del centro de datos y para las consultas
utiliza el lenguaje CQL, el cual posee una sintaxis similar a SQL. Desde la perspectiva CQL la base
de datos se compone de tablas. Por lo general, un cluster tiene un espacio de claves por aplicacin.
Los desarrolladores pueden acceder utilizando CQL a travs del mdulo cqlsh, o utilizando los
driver existentes para varios lenguajes de programacin.
Cuando un cliente se conecta a un nodo con una solicitud, ese nodo se desempea como
coordinador de esa operacin en particular. El coordinador acta como un proxy entre la aplicacin
cliente y los nodos que son dueos de los datos que se solicitan. El coordinador determina que
nodos en el anillo debe recibir la solicitud en funcin de cmo est configurado el cluster. Se puede
obtener mayor informacin en la web de Cassandra [http://wiki.apache.org/cassandra/].
4.3.5.3 Neo4j
Neo4j es una base de datos orientada a grafos de cdigo abierto con soporte comercial. Fue
diseada y construida desde cero para ser una base de datos optimizada para estructuras de grafos
en lugar de tablas. Su aplicacin permite aprovechar la expresividad de un grafo manteniendo la
fiabilidad que normalmente se espera de una base de datos.
Las bases de datos orientadas a grafos representan la informacin como nodos de un grafo y sus
relaciones como las aristas del mismo. De esta forma, se puede usar una teora de grafos para
recorrer la base de datos cuando puede describir atributos de los nodos (entidades) y de las aristas
(relaciones)
Este tipo de bases de datos almacenan los datos en nodos, los cuales tienen propiedades. El grafo
ms simple posible es el de un solo nodo y se le pueden asignar miles de propiedades. Por supuesto
que no tiene sentido acumular tantos propiedades en un nodo, por lo cual se distribuyen en varios
nodos, organizados con relaciones explcitas.
Luis Ignacio Aita
Pgina 40
Los nodos son organizados por las relaciones que tambin tienen propiedades. Las relaciones
permiten estructuras arbitrarias por lo cual un grafo puede parecerse a una lista, un rbol, un mapa,
o una entidad compuesta, y pueden combinarse en estructuras an ms complejas e interconectadas.
Ms informacin en la web de Neo4j [http://www.neo4j.org/].
4.3.5.4 Apache CouchDB
CouchDB es un gestor de bases de datos NoSQL de cdigo abierto cuyo foco est puesto en la
facilidad de su uso y en ser "una base de datos que asume la web de manera completa". Emplea el
formato JSON para almacenar los datos, JavaScript como lenguaje de consulta por medio de Map
Reduce y HTTP como API. CouchDB fue liberada por primera vez en 2005, transformndose en un
proyecto Apache en 2008.
Una de sus caractersticas ms peculiares es la facilidad con la que permite hacer replicaciones.
CouchDB se dise poniendo el foco en la replicacin bidireccional (o sincronizacin) y la
operacin offline. Eso significa que mltiples rplicas pueden tener cada una sus propias copias de
los mismos datos, modificarlas y luego sincronizar esos cambios en un momento posterior. Esta
caracterstica hacen que sea ideal para su uso en dispositivos mviles, donde la conexin no siempre
est disponible.
CouchDB almacena los datos como "documentos", esto es, uno o ms pares campo/valor
expresados en JSON. Los valores de los campos pueden ser datos simples como cadenas de
caracteres, nmeros o fechas. Pero tambin se pueden usar listas ordenadas y vectores asociativos.
Todos los documentos en una base de datos CouchDB tienen un identificador nico y no requieren
un esquema determinado.
Ms informacin en la web de CouchDB [http://couchdb.apache.org/]
4.3.5.5 MongoDB
MongoDB es una base de datos orientada a documentos que puede proporcionar alto
rendimiento, alta disponibilidad y facilitar la escalabilidad.
4.3.5.5.1 Caractersticas principales
MongoDB se centra en la flexibilidad, potencia, velocidad y facilidad de uso:
Flexibilidad: MongoDB almacena los datos en documentos JSON (serializados a formato

BSON). JSON ofrece un modelo de datos acoplable a los tipos de datos utilizados en los
Luis Ignacio Aita
Pgina 41
lenguajes de programacin, y el esquema dinmico hace que sea ms fcil de evolucionar su

modelo de datos que con un sistema con esquemas rgidos como en un RDBMS.
Potencia: MongoDB ofrece muchas de las caractersticas de un RDBMS tradicional como

ndices secundarios, consultas dinmicas, clasificacin, potentes mecanismos de
actualizaciones, upserts (actualizacin si el documento existe, insertar si no lo hace), y
consultas de agregacin. Esto le da una amplitud funcional similar a la de un RDBMS, con
la capacidad de flexibilidad y escalamiento que el modelo no relacional permite.
Velocidad / Scaling: Al mantener datos relacionados juntos en documentos, las consultas

pueden ser mucho ms rpidas que en una base de datos relacional donde los datos
relacionados se dividen en varias tablas y luego tienen que ser unidos. Autosharding permite
ampliar o reducir el cluster de forma lineal al aadir ms mquinas. Es posible aumentar la
capacidad sin ningn tiempo de inactividad, lo cual es muy importante en la web cuando la
carga puede aumentar de repente y derribar el sitio web por un mantenimiento prolongado
que puede costar mucho dinero.
Facilidad de uso: MongoDB es relativamente fcil de instalar, configurar, mantener y usar.

Con este fin, MongoDB ofrece pocas opciones de configuracin, y en su lugar trata de hacer
automticamente la mayor cantidad de tareas posibles. Es posible hacer funcionar
MongoDB en una modalidad out of the box y de esta manera centrarse directamente en el
desarrollo de aplicaciones, aunque en ambientes productivos requiere un mayor nivel de
conocimientos sobre su administracin y mantenimiento.
4.3.5.6 Almacenamiento de datos
Una implementacin de MongoDB puede contener un conjunto de bases de datos. Una base de
datos contiene un conjunto de colecciones. Una coleccin tiene un conjunto de documentos. Un
documento es un conjunto de pares clave-valor. Los documentos tienen esquemas dinmicos. Un
esquema dinmico implica que los documentos de la misma coleccin no necesitan tener el mismo
conjunto de campos o estructura, y los campos comunes en los documentos de una coleccin
pueden contener diferentes tipos de datos.
4.3.5.7 Consultas
Para la recuperacin de informacin MongoDB provee un conjunto de operadores de consulta

para definir de que manera el mtodo find() selecciona los documentos de una coleccin en base a
Luis Ignacio Aita
Pgina 42
un documento de especificacin de consulta que utiliza una combinacin de filtros, expresiones y

condicionales.
MongoDB permite adems realizar consultas ms complejas de dos maneras:
A travs de su Aggregation Framework. Este framework permite encadenar consultas a

travs de pipelines utilizando expresiones y operadores. Cada pipeline le pasa los resultados
al siguiente para que los procese, generando as un resultado final en forma conjunta.
Utilizando Map Reduce. Esta tcnica mencionada en la seccin anterior provee un modelo
de programacin muy potente, permitiendo pasar como parmetros en las consultas
funciones tanto de mapeo como de reduccin de los datos junto con un conjunto de opciones
adicionales.
4.3.5.8 Arquitectura de despliegue
Aunque MongoDB soporta un despliegue de una sola instancia, en ambientes productivos la

implementacin suele ser distribuida de forma predeterminada. Las rplicas proporcionan alto
rendimiento con recuperacin de fallas automtico, mientras que las tcnicas de sharding o
fragmentacin hacen posible particionar grandes conjuntos de datos en muchas mquinas de forma
transparente para los usuarios. Combinando conjuntos de rplicas y shards es posible proporcionar
altos niveles de redundancia para grandes conjuntos de datos de forma transparente para las
aplicaciones.
4.4
Big Data
4.4.1 Introduccin
Tal y como se coment en la seccin de introduccin del presente trabajo la cantidad de
informacin generada y manipulada actualmente ha crecido exponencialmente tan solo comparando
con la existente hace 20 aos atrs. Vivimos actualmente en la era de la informacin donde muchos
afirman que existen ms telfonos y dispositivos mviles conectados que personas en el planeta. El
mundo tiene ms datos que nunca pero, lo que es ms importante, genera nuevos datos a un ritmo
nunca antes conocido.
Es en este escenario donde hace muy pocos aos comenz a utilizarse el trmino Big Data para
referirse de manera, muchas veces confusa, tanto a los grandes conjuntos de datos como a las
tcnicas y herramientas para manipularlos y obtener conocimiento a partir de la informacin.
Luis Ignacio Aita
Pgina 43
Durante el ao 2012 un gran porcentaje de los artculos de opinin sobre tecnologa avanzada
utilizaban el trmino como una estrategia que no poda faltar en ninguna empresas. En muchos
casos se lo utiliz ms como marketing que sabiendo realmente de que se trataba.
4.4.2 Definicin
Desde que el MGI (McKinsey Global Institute) acu el concepto a mediados del 2011, han
surgido numerosas definiciones de Big Data, la mayora de ellas como intentos de acotar el
concepto a un rea determinada.
Una de las ms completas es la realizada por Gartner [http://www.gartner.com/it-glossary/bigdata/] Son activos de informacin caracterizados por su alto volumen, velocidad y variedad, que
demandan soluciones innovadoras y eficientes de procesado para la mejora del conocimiento y
toma de decisiones en las organizaciones.
Un estudio realizado por el IBM Institute for Business Value entre ms de mil profesionales en
IT y expertos en la materia de casi 100 pases muestra que el trmino para algunos es tan abarcativo
como Nuevos tipos de datos y anlisis mientras que otros lo vinculan solamente a las redes
sociales.
Imagen 1 Qu piensan los ejecutivos que es Big Data?
Luis Ignacio Aita
Pgina 44
Para este trabajo consideraremos el concepto Big Data simplemente como Anlisis y Tratamiento
de grandes volmenes de datos.
Ms all de la definicin lo importante del Big Data es la tendencia de avance de las tecnologas
que abren puertas para nuevos enfoques de entendimiento y toma de decisiones, ampliando el
alcance de los sistemas de bases de datos relacionales, permitiendo almacenar y procesar grandes
cantidades de datos de todos los tipos posibles (estructurados, semi-estructurados y sin estructurar)
4.4.3 Ventajas
Teniendo en cuenta principalmente la ventaja que supone el uso de tcnicas de Big Data respecto
a los modelos relacionales se listan a continuacin las ventajas ms habituales de su uso, los cuales
no tienen que ser necesariamente aplicables en cualquier organizacin, dado que cada una funciona
en diferentes contextos. Toda la lista se ha extrado de un artculo publicado en Eureka-startups por
Vauzza [Vauzza 2013].
Gestin del cambio

Bsqueda de nuevas oportunidades de negocio a travs de segmentacin mejorada y
venta cruzada de productos (mejora de la estrategia).
Mediante la aplicacin de anlisis y modelado predictivo a los datos de cuentas de
clientes e historial de transaccin, la solucin permite a los agentes llevar a cabo una
segmentacin basada en la probabilidad de que el cliente contrate servicios o productos
complementarios, o contratar servicios de mayor valor (mejora de segmentacin).
Mediante el anlisis de consumo de los servicios y productos de los clientes, la empresa
puede optimizar las estrategias de venta cruzada, afinar mensajes de marketing y
proporcionar ofertas especficas. Se puede predecir con mayor exactitud qu productos
son los ms apropiados para cada cliente (mejora de la estrategia).
Ofrecer la combinacin adecuada de servicios y productos mejora la eficacia y la
eficiencia de la fuerza de ventas de la compaa, mientras que el toque ms
personalizado ayuda a los agentes a forjar lazos ms estrechos con clientes, lo cual
mejora la lealtad (mejora de la estrategia).
Mejoras Operativas: Mayor capacidad de visibilidad del negocio a travs de informes
ms detallados.
Anlisis de navegacin web y hbitos de consumo online:
Anlisis de Redes Sociales: Determinar los crculos sociales de los clientes a partir de
interacciones telefnicas y redes sociales online genera una visin completa de los
clientes, identificando el papel que desempean en sus crculos y su grado de influencia.
Marketing Viral (marketing que explota redes sociales): Detecta clientes ms
influyentes, roles sociales para maximizar la difusin de tus productos y servicios
(mejor conocimiento de clientes y del mercado en redes sociales).
Anlisis de datos de navegacin: Analiza la navegacin Web y hbitos de consumo
online: extrae nuevas y valiosas perspectivas de los clientes. Se identifica al usuario
(localizacin, estado del terminal, servicios de acceso), se monitorean sitios y bsquedas
por palabra, URLs visitadas, tiempo de navegacin, etc. (mejor conocimiento del
Luis Ignacio Aita
Pgina 45
cliente).
Cuadro de Mandos en tiempo real, la informacin siempre est disponible sin esperas de
actualizacin de los datos (informacin en tiempo real).
Anticipacin a los problemas:
Un sistema predictivo de anlisis y cruce de datos nos permite poder anticiparnos a
posibles problemas que puede surgir en el futuro, como por ejemplo una prediccin de
riesgo de catstrofes que permitira ajustar la poltica de precios y aprovisionar fondos
para posibles pagos (utilidad para ver la veracidad de los datos ante datos imprecisos) .
Mejoras de Procesos:
Permite la simplificacin de procesos actuales y control del negocio (reduccin de
costes).
Anlisis de Seguridad. Analtica proactiva que permite la reduccin de riesgos y
prdidas frente a fraudes (reduccin de costes).
Permite detectar patrones complejos de fraude en tiempo real analizando los datos
histricos, el patrn de uso de informacin de geolocalizacin, anlisis de transacciones
y operaciones sospechosas (reduccin de costes).
Soporte a la toma de decisiones a travs de algoritmos automticos.
Una analtica sofisticada que analice todos los informes y datos, ayuda a la toma de
decisiones, reduciendo los riesgos y descubre informacin que antes podra estar oculta,
pero a la vez importante (ayuda a la toma de decisiones).
Reduccin de costos.
Reduccin de tiempos.
Desarrollo de nuevos productos.
Ofertas optimizadas y personalizadas.
Tomas de decisiones ms inteligentes que con los anteriores sistemas Business Intelligence.
Filtros inteligentes de seguridad en el negocio electrnico
Se pueden resumir todas estas ventajas como obtener ms informacin/conocimiento tanto de

las propia empresa como de los clientes y de la competencia para obtener las ventajas competitivas
que esto conlleva. Es importante aclarar que esto no implica obtener una gran cantidad de datos,
sino informacin valiosa obtenida desde una gran cantidad de datos.
Un claro ejemplo de esto son las actividades de vigilancia tecnolgica e inteligencia
competitiva. Esto es un proceso organizado, selectivo y permanente, de captar informacin del
exterior y de la propia organizacin sobre ciencia y tecnologa, seleccionarla, analizarla, difundirla
y comunicarla, para convertirla en conocimiento para tomar decisiones con menor riesgo y poder
anticiparse a los cambios. (Normas UNE 166006:2011]).
En nuestra localidad, Puerto Madryn, existe un proyecto en ejecucin para desarrollar una
oficina de Vigilancia Tecnolgica e Inteligencia Competitiva enmarcada dentro del proceso de
creacin del Parque Tecnolgico municipal.
Luis Ignacio Aita
Pgina 46
4.4.4 Desventajas
Al igual que para las ventajas es importante considerar el contexto de cada organizacin en
donde se quieran aplicar tcnicas de Big Data. El principal inconveniente es el costo, generalmente
elevado, del proceso de implementacin, principalmente en hardware, software y recursos humanos.
Otra consideracin sencilla pero no menos importante es la respuesta a la pregunta Mi empresa
realmente necesita Big Data?. Si la respuesta a dicha pregunta es SI, vale la pena el esfuerzo para
llevar adelante el proceso. Pero no vale la pena hacerlo simplemente porque est de moda o si las
ventajas que me ofrece no aplican en determinada organizacin.
Existen otros inconvenientes de menor peso como el rechazo por parte del personal, gastos de
formacin, necesidad de colaboracin de todos los sectores de la empresa, cuestiones de privacidad,
informacin desactualizada, etc.
4.4.5 Aplicaciones
El espectro de aplicaciones de las tcnicas de Big Data es muy amplio y prcticamente
inabarcable en un documento, sin embargo existe un anlisis llevado a cabo por IBM en el ao
2012[Schroeck et al. 2012] que identifica 5 orientaciones principales en las que se aplica Big Data y
se describen en la siguiente tabla.
Orientacin
Porcentaje
Resultados centrados en el cliente
49%
Optimizacin operativa
18%
Gestin financiera/de riesgos
15%
Nuevo modelo empresarial
14%
Colaboracin de los empleados
4%
Tabla 3: Aplicaciones del Big Data
4.4.6 Caractersticas
Existen muchas razones por las cuales los conceptos de Big Data son revolucionarios, pero
existen tres causas principales denominadas las 3 V del Big Data: volumen, velocidad y variedad.
4.4.6.1 Volumen
Es uno de los aspectos ms destacados pero no es el nico y muchas veces se relacionan las
tcnicas de Big Data solo con este concepto. La cantidad de datos existentes en el mundo es
Luis Ignacio Aita
Pgina 47
inmensa y ha crecido mucho en los ltimos aos, pero ms ha crecido la velocidad con la que se
generan nuevos datos.
La diversidad de fuentes de datos, el mayor intercambio de datos entre sistemas y la
proliferacin de sistemas de informacin son algunas de las causas que originan este fenmeno.
4.4.6.2 Velocidad
Este concepto est relacionado con la gran cantidad de fuentes de datos y la necesidad de utilizar
estos datos rpidamente.
Muchas fuentes de datos automatizadas y equipos generan flujos constantes de datos a procesar.
Otras fuentes como los equipos mviles generan datos a intervalos ms largos, pero la gran cantidad
de dispositivos terminan generando corrientes de datos continuas.
Por otra parte todos estos datos pierden valor aceleradamente con el paso del tiempo, por lo cual
deben convertirse lo ms rpido posible en informacin til.
4.4.6.3 Variedad
Los grandes volmenes de datos incluyen cualquier tipo de datos, estructurados y no

estructurados como texto, datos de sensores, audio, vdeo, secuencias de clic o archivos de registro,
entre otros. Al analizar estos datos juntos se encuentra informacin valiosa.
Algunos autores consideran una cuarta V de Veracidad haciendo referencia a la fiabilidad
asociada a ciertos datos y el factor de incertidumbre que estos conllevan.
Otro factor importante es la complejidad asociada al tratamiento de todas las caractersticas
nombradas con la finalidad de generar informacin de utilidad en forma eficiente.
4.4.7 Herramientas
Las tecnologas tradicionales de almacenamiento, procesamiento y visualizacin de datos han
mostrado limitaciones para algunos de los tipos de aplicaciones caractersticos del BigData,
especialmente en los casos con cantidades de datos extremadamente grandes. Por ello, han
aparecido nuevas herramientas orientadas especficamente a resolver estos problemas.
Se resumen algunas de ellas en la siguiente lista:
Sistemas basados en el paradigma map reduce. Hadoop es la implementacin ms

popular de este paradigma, que permite la ejecucin paralela de procesos de anlisis sobre
grandes cantidades de datos, usando para ello PCs convencionales de bajo coste.
Bases de Datos NoSQL. Diferentes tipos de bases de datos optimizados para tipos de
Luis Ignacio Aita
Pgina 48
aplicaciones diferentes. Ver seccin anterior.

Minera de Datos. Herramientas que permiten el descubrimiento de modelos matemticos
para los datos. Son utilizadas para disear modelos que permitan descubrir eventos inusuales
dentro de grandes volmenes de datos, que no pueden ser apreciados de otra manera.
Utilizando tcnicas de minera de datos es posible realizar modelos para, por ejemplo,
segmentacin de clientes, deteccin de patrones de comportamiento, tendencias o prediccin
de comportamientos futuros.
Visualizacin de datos. Facilita la obtencin de inteligencia a partir del big data. Este tipo
de herramientas buscan ofrecer un efectiva visualizacin de los datos, con un objetivo claro
y que sirvan a un determinado pblico objetivo.
Existen muchas herramientas y deben combinarse para obtener mejores resultados. Por ejemplo
combinando los proyectos de cdigo abierto Hadoop y Solr permitira utilizar Hadoop para manejar
el almacenamiento de los datos que son recuperados a travs de Solr, que puede ser utilizado como
un almacn de claves-valor (es decir, una base de datos NoSQL) aprovechando la potencia de su
motor de consultas.
Desde el inicio del proyecto Zonales se pens en esta combinacin aunque no lleg a
implementarse la herramienta Hadoop. Posteriormente uno de los integrantes del equipo de
desarrollo realiz su tesina de grado basada en esta herramienta. S se utiliz Apache Solr,
herramienta que se describir en detalle en la siguiente seccin.
Luis Ignacio Aita
Apache Solr
5.1
Introduccin
Pgina 49
Apache Solr es un motor de bsqueda de cdigo abierto que proporciona una capa de abstraccin
sobre las libreras Apache Lucene. Normalmente se lo menciona como la "serverizacin" de
Lucene, aunque no se limita simplemente a esto. La mayora de las caractersticas de Solr son
distintas de las de Lucene, pero cercanas en el mbito de aplicacin. La lnea entre lo que es Solr y
lo que es Lucene a veces suele ser borrosa.
Las principales caractersticas de Solr son:
Sus APIs utilizan protocolos estndares de comunicacin como HTTP y HTTPS.
Es altamente escalable
Es modular gracias a su sistema de plugins
Utiliza caches internas para acelerar las consultas.
Incluye una administracin web que permite, entre otras cosas, gestionar distintas
colecciones de datos, consultar logs, realizar consultas utilizando un formulario, ejecutar
comandos de indexacin de documentos, importar informacin, analizar el ndice,
inspeccionar el esquema, etc.
Permite aplicar funciones de anlisis de texto.
Permite la configuracin de la indexacin y recuperacin de documentos mediante ficheros

de configuracin XML.
Permite aadir libreras de analizadores de texto
Introduce el concepto de campo tipado, lo que permite indexar campos tales como fechas.
Aade mejoras a las consultas bsicas de Lucene.
Navegacin por facetas o aspectos (faceting) en las bsquedas.
Permite la manipulacin de resultados haciendo uso de funciones.
Extiende la funcionalidad de Lucene para el resaltado de resultados.
Luis Ignacio Aita
Pgina 50
Dispone de plugins de revisin gramatical en distintos idiomas (spell check) para realizar
recomendaciones de bsqueda.
Dispone de plugins de bsqueda de documentos similares.
Permite el manejo de documentos ricos (word, pdf, etc) basndose en el proyecto Apache
Tika [Mattmann, Zitting 2011].
Esta escrito en Java como aplicacin web y se puede desplegar en cualquier contenedor de
servlets.
Permite la geolocalizacin de documentos.
Incluye mltiples formatos de respuestas (XML, JSON, etc).
5.2
Componentes principales
Los componentes ms destacados de Apache Solr son:
Lucene: libreras de cdigo abierto para realizar bsquedas de texto sobre las que se
construye Solr.
Request Handlers: procesan la consultas solicitadas.

Search Components: aaden datos (de la consulta) a la respuesta.
Response Writers: Transforman la informacin al formato de respuesta solicitado.
Solr Core: conjunto de configuracin y documentos
Update Handler: Lgica de actualizacin de documentos.
Cache: Estrategia de almacenamiento de informacin intermedia.
Luis Ignacio Aita
Pgina 51
Imagen 2: Componentes de Apache Solr
5.3
Lucene
Apache Lucene es una librera de cdigo abierto de alto rendimiento para realizar bsquedas de
texto. Fue desarrollada y publicada por Doug Cutting en 2000 y ha evolucionado desde entonces
con una gran comunidad en lnea. Para utilizar Lucene directamente, es necesario escribir cdigo
para almacenar y consultar un ndice almacenado en un soporte fsico. Las principales
caractersticas de Lucene son:
Un ndice invertido de almacenamiento persistente basado en texto para la recuperacin

eficiente de los documentos segn los trminos indexados
Un amplio conjunto de analizadores de texto para transformar una cadena de texto en una
serie de trminos, que son las unidades fundamentales para indexar y buscar
Una sintaxis de la consulta con un analizador y una variedad de tipos de consulta a partir de
un simple trmino de bsqueda de coincidencias parciales.
Luis Ignacio Aita
Pgina 52
Un buen algoritmo de puntuacin basado en los principios de Recuperacin de Informacin

(RI) para determinar los resultados ms probables en primer lugar, con medios flexibles
para afectar a la puntuacin.
Una caracterstica para resaltar las palabras encontradas en el contexto
Un corrector ortogrfico de consultas basado en el contenido indexado
5.3.1 Comparacin con la tecnologa de base de datos tradicional

Un ndice Lucene es como una base de datos de una sola tabla sin ningn tipo de apoyo para las
consultas relacionales (JOIN). Es importante destacar que los ndices por lo general slo existen
para apoyar la bsqueda y no para ser la fuente principal de datos. Por lo que su base de datos puede
estar en "tercera forma normal", pero el ndice estar completamente desnormalizado y contienen
ms que nada los datos necesarios para ser registrados. Un aspecto a destacar del esquema de la
tabla nica es que los campos pueden ser multivaluados.
Otras diferencias notables son las siguientes:
Actualizaciones: se pueden eliminar y agregar de nuevo documentos completos, pero no se

actualizan.
Bsqueda de sub-cadenas vs. bsquedas de texto: Lucene hace nfasis fundamentalmente

en bsquedas en trminos. Segn el anlisis de la configuracin, esto puede significar que se
encuentren las diversas formas de la palabra incluso fonticas. Usando tcnicas avanzadas
de anlisis de n-gramas, se pueden considerar palabras parciales aunque esto es poco comn.
Resultados ranqueados y destacados: Gran parte de la fuerza de Lucene reside en su

capacidad de ordenar los resultados combinando funciones de bsqueda. Por ejemplo, si se
buscan varias palabras Lucene ordena los documentos que coinciden con los trminos con
mayor peso. Existen otros factores y es posible ajustar las ponderaciones de los diferentes
campos. Por comparacin, una base de datos tradicional no tiene este concepto para las
bsquedas de registros.
Velocidad de bsqueda: Solr est muy optimizado para realizar bsquedas rpidamente,
principalmente mediante la utilizacin de caches.
5.4
Indexacin
Luis Ignacio Aita
Pgina 53
La premisa fundamental de Solr es simple. Se le da una gran cantidad de informacin y ms

tarde se le puede preguntar a travs de consultas o querys para encontrar la informacin deseada. La
parte en que se alimenta a Solr con informacin se llama indexacin.
Se entiende por indexacin a la insercin, modificacin o eliminacin de contenidos en un ndice
Solr. Un contenido insertado en el ndice Solr es factible de ser encontrado mediante las funciones
de bsquedas.
Una manera de entender cmo funciona Solr es pensar en un libro de hojas sueltas de recetas.
Cada vez que se agrega una receta en el libro hay que actualizar el ndice en la parte posterior. Se
lista cada ingrediente y el nmero de pgina de la receta que acaba de agregar. Supongamos que se
agregan cien recetas. Utilizando el ndice, se puede encontrar muy rpidamente todas las recetas que
utilizan garbanzos, tomate, o caf como ingredientes. Utilizando el ndice es mucho ms rpido que
mirando cada una de las recetas hasta encontrar la que buscamos. Ms an si imaginamos un libro
con mil recetas o con un milln.
Un ndice Solr puede aceptar datos de diversas fuentes, incluyendo archivos XML, valores
separados por comas (CSV), los datos extrados de tablas de una base de datos y archivos en los
formatos propietarios ms comunes, como Microsoft Word o PDF.
Las tres formas ms comunes de carga de datos en un ndice Solr son:
Utilizando el framework Solr Cell construido en Apache Tika para la insercin de

archivos binarios o estructurados como Office, Word, PDF, y otros formatos propietarios.
Cargar archivos XML o JSON mediante el envo de peticiones HTTP al servidor Solr desde
cualquier entorno en el que dichas solicitudes se pueden generar. En las ltimas versiones se
pueden insertar documentos mediante HTTP desde una pantalla de administracin.
Escribir una aplicacin Java para manipular los datos a travs de la API Solr para java.
Independientemente del mtodo utilizado para la captura de informacin, hay una estructura
bsica en comn para todos los datos que se introducen en un ndice Solr: un formato de documento
que contiene mltiples campos, cada uno identificado mediante un nombre y que contiene un tipo
de dato predefinido. Uno de los campos es generalmente designado como identificador nico
(similar a una clave primaria en una base de datos), aunque su uso no es estrictamente obligatorio
en Solr.
Luis Ignacio Aita
Pgina 54
Solr le permite construir un ndice con muchos campos diferentes. Como se vio en el ejemplo de
la receta se supuso la construccin de un ndice con un solo campo: ingredientes. Es posible agregar
otros campos en el ndice para buscar las recetas como por ejemplo el tipo de cocina: oriental,
gourmet o vegana o los tiempos de preparacin. Solr puede responder a preguntas como "Qu
recetas de estilo oriental tienen naranjas como ingrediente y se pueden preparar en menos de 30
minutos?"
El esquema es el lugar donde se le indica a Solr cmo debe construir los ndices de documentos.
Este esquema define los nombres y tipos de campos que componen el ndice normalmente se
definen en el archivo de configuracin schema.xml. Para los campos definidos en este archivo se
aplicarn los pasos de anlisis asociados al mismo cuando se indexe el contenido. Los campos que
no estn definidos explcitamente en el esquema o bien se pueden ignorar o asignar mediante una
definicin de campo dinmico.
5.4.1 Cmo Solr ve al Mundo

En los prrafos anteriores se hace mencin de documentos y campos, ahora bien, que
implican estos conceptos?. En Solr la unidad bsica de informacin es el documento, que es un
conjunto de datos que describe algo. Un documento receta contendra los ingredientes, las
instrucciones, el tiempo de preparacin, el tiempo de coccin, las herramientas necesarias, etc. Un
documento sobre una persona, por ejemplo, podra contener el nombre, la biografa de la persona, el
color favorito, su peso y su altura. Un documento de un libro podra contener el ttulo, autor, ao de
publicacin, nmero de pginas, y as sucesivamente.
Los campos pueden contener diferentes tipos de datos. Un campo de nombre, por ejemplo, es un
texto (datos de caracteres). Un campo de nmero de calzado podra ser un nmero entero o de punto
flotante (depende que sistema de medida se utilice) pudiendo contener valores como 6 y 9,5.
Obviamente, la definicin de los campos es flexible (se puede definir un campo de nmero de
calzado como un campo de texto en lugar de un nmero de punto flotante, por ejemplo), pero si se
definen bien los campos, Solr ser capaz de interpretarlos correctamente y los usuarios obtendrn
mejores resultados cuando se realicen consultas.
Solr tiene muchos tipos de campos, algunos de propsito general como las cadenas de texto,
nmeros enteros o reales, fechas, valores verdadero o falso, etc., y tambin tiene campos
Luis Ignacio Aita
Pgina 55
especficos, como por ejemplo text_en, text_en_splitting o phonetic que permiten trabajar en
particular con el idioma ingls.
Como mencionamos anteriormente, se le puede decir a Solr que tipo de datos contendr un
campo mediante la configuracin del esquema. El tipo de dato le indica al motor cmo interpretar el
campo y la forma en que se puede consultar.
5.4.2 Anlisis de campos

El anlisis de un campo le dice a Solr qu hacer con los datos de entrada para ese campo en la
construccin del ndice. Un nombre ms preciso para esto sera procesamiento o
transformacin, pero el nombre oficial definido por Solr es anlisis.
Consideremos, por ejemplo, el campo biografa en un documento de persona. Cada palabra de la
biografa debe ser indexada de manera que usted puede encontrar rpidamente a las personas cuyas
vidas han tenido que ver con la qumica, la criptografa o la ingeniera de sistemas.
Sin embargo una biografa probablemente contenga un montn de palabras que no importan y no
es deseable obstruir los ndices con palabras como "el", "a", "de", etc. Por otra lado supongamos
que la biografa contiene la palabra "Qumica" al principio de una frase. Si un usuario realiza una
consulta para "qumica" desear que Solr le retorne informacin sobre la persona a pesar de que la
biografa contiene la palabra en maysculas y sin tilde en el acento.
La solucin a ambos problemas es el anlisis de campo. Para el caso de la biografa se puede
configurar Solr para que lematize las palabras, es decir que pase todas las palabras a minsculas,
ignore los tildes de los acentos, unifique terminaciones, etc.
El anlisis de campo es una parte importante de un tipo de campo. Solr posee analizadores,
tokenizers y filtros que son parte importante de la construccin de un ndice.
5.5
Bsquedas
Solr ofrece un conjunto amplio y flexible de caractersticas para la bsqueda de informacin en

sus ndices. Para comprender el alcance de esta flexibilidad, es til comenzar con una visin general
de los pasos y elementos que intervienen en una bsqueda Solr.
Cuando un usuario ejecuta una bsqueda en Solr, la misma es procesada por un controlador de
consultas o request handler. Este controlador es un plug-in de Solr que define la lgica que se
utilizar cuando Solr procesa una consulta. Solr soporta varios controladores, algunos diseados
Luis Ignacio Aita
Pgina 56
para el procesamiento simple de consultas, mientras que otros manejan tareas como la replicacin
del ndice.
Las aplicaciones de bsqueda deben seleccionar un controlador de consultas de forma
predeterminada y se pueden configurar para permitir a los usuarios modificar esta seleccin
predeterminada para reemplazar el controlador de consultas por uno distinto.
Para procesar una bsqueda, un controlador de consultas llama a un parser o analizador de
consultas, que interpreta los trminos y parmetros que contiene. Cada parser tiene una sintaxis
diferente. El parser de consultas por defecto se denomina DisMax. Solr incluye tambin un parser
legado estndar de Lucene y una versin extendida de DisMax (eDisMax). La sintaxis del parser
estndar de Lucene permite una mayor precisin en las bsquedas, pero DisMax cuenta con mayor
tolerancia y tratamiento de errores. El parser de consultas DisMax est diseado para proporcionar
una experiencia similar a la de los motores de bsqueda ms populares como Google, que rara vez
muestran los errores de sintaxis a los usuarios. El analizador de consultas DisMax extendido es una
versin mejorada de DisMax que incluye la sintaxis de consulta completa de Lucene mientras sigue
tolerando errores de sintaxis. Tambin incluye otras caractersticas adicionales.
DisMax es una abreviatura Disyuncin Max, siendo el modo de consulta ms popular en Solr y
es el que se utiliz en el proyecto Zonales. El analizador de consulta estndar legado de Lucene es
bastante limitado, permitiendo simplemente operadores booleanos AND y OR, slo se puede buscar
en un campo y es muy posible que surja una excepcin por un error en la sintaxis de la consulta.
Por esto fue necesario crear nuevos modos de consulta ms potentes y as surgi el analizador de
consultas DisMax. Est diseado para procesar palabras sencillas introducidas por el usuario (sin
sintaxis compleja) y para buscar dichas palabras a travs de varios campos utilizando diferente
ponderacin en funcin del significado de cada campo, y prcticamente nunca lanza una excepcin.
Disyuncin se refiere al hecho de que su bsqueda se ejecuta en varios campos, por ejemplo,
ttulo, cuerpo y palabras clave, con diferentes pesos de relevancia
Max quiere decir que si la palabra buscada coincide tanto con ms de un campo, por ejemplo el
ttulo y el cuerpo, se considera la puntuacin o scoring del campo de mayor relevancia
(probablemente el ttulo en este caso) y no la suma de los campos como al utilizar una operacin
OR. Esto permite un mayor control sobre el ranking de resultados.
Luis Ignacio Aita
Pgina 57
Adems, existen parmetros de consulta comunes que son aceptados por todos los parsers de
anlisis de la consulta.
Una consulta puede incluir:
Cadenas de bsqueda: esto es, trminos para buscar en el ndice
Parmetros para afinar la consulta mediante el aumento de la importancia de las cadenas o

de determinados campos, mediante la aplicacin de la lgica booleana entre los trminos de
bsqueda, o mediante la exclusin de contenidos a partir de los resultados de la bsqueda.
Parmetros para el control de la presentacin de la respuesta de la consulta, como

especificacin del orden en que los resultados han de ser presentados o limitar la respuesta a
determinados campos del esquema.
Los parmetros de bsqueda tambin pueden especificar un filtro para la consulta. Como parte
de la respuesta, un filtro de consulta ejecuta una bsqueda en todo el ndice y almacena en cach los
resultados. Debido a que Solr asigna una cach separado para consultas con filtros, el uso
estratgico de este tipo de consultas puede mejorar notablemente el rendimiento de las bsquedas. A
pesar de sus nombres similares, los filtros de consulta no estn relacionados con filtros de anlisis.
Los filtros de consulta realizan las consultas en tiempo de bsqueda con los datos que ya estn en el
ndice, mientras que los filtros de anlisis, como Tokenizers, analizan el contenido en forma previa
a la indexacin, siguiendo las normas especificadas.
Una bsqueda puede solicitar que ciertos trminos se resalten en la respuesta, es decir, los
trminos seleccionados se mostrarn en cajas de colores de modo que "resalten" en la pantalla de
resultados. Esta funcionalidad hace que sea ms fcil encontrar palabras o frases relevantes en los
documentos largos devueltos en una bsqueda. Solr incluye un amplio conjunto de parmetros de
bsqueda para controlar cmo se resaltan los trminos.
Las respuestas tambin se pueden configurar para incluir fragmentos de documentos (extractos)
como texto relevante. Los motores de bsqueda populares como Google y Yahoo! Muestran
fragmentos de texto en los resultados de las bsqueda: 3 4 lneas de texto que ofrecen una
introduccin al resultado de una bsqueda.
Para ayudar a los usuarios a encontrar el contenido que estn buscando, Solr soporta dos formas
especiales de agrupacin de resultados para facilitar la exploracin: faceting y clustering.
Luis Ignacio Aita
Pgina 58
Faceting es el agrupamiento de los resultados de las bsquedas en categoras (que se basan en

los mismos trminos indexados). Dentro de cada categora, Solr informa sobre el nmero de
documentos para una palabras determinada. Esta caracterstica hace que sea ms fcil para los
usuarios explorar los resultados de bsqueda en determinados sitios, como por ejemplo sitios de
pelculas o de reseas de productos, en los que hay muchas categoras y muchos artculos dentro de
cada categora.
La siguiente imagen muestra un ejemplo de faceting en el sitio Web CNET, que fue el primer
sitio en utilizar Solr.
Imagen 3: faceting en el sitio de CNET

Faceting hace uso de campos definidos en el esquema y que son actualizados durante la
indexacin. En el ejemplo anterior, estos campos incluyen categoras de informacin que son tiles
para describir las cmaras digitales: fabricante, resolucin y rango de zoom.
Clustering agrupa resultados por similitudes descubiertas cuando se ejecuta una bsqueda en
lugar de cuando se indexan los contenidos. Los resultados agrupados mediante clustering
normalmente carecen de la organizacin jerrquica que tienen los resultados de bsqueda con
faceting, pero de cualquier manera puede ser de utilidad. Permite revelar similitudes inesperadas
entre los resultados de la bsqueda, y puede ayudar a los usuarios a descartar contenido que no est
relacionado con lo que realmente estn buscando.
Solr tambin es compatible con una funcin llamada MoreLikeThis, que permite a los usuarios
ejecutar nuevas bsquedas basadas en determinados trminos devueltos en una consulta anterior.
Luis Ignacio Aita
Pgina 59
Esta funcin puede hacer uso de faceting o clustering para proporcionar ayuda adicional a los
usuarios.
Un componente de Solr llamado response writer (escritor de respuesta) se ocupa de la
presentacin final de los resultados de una bsqueda. Solr incluye varios escritores de respuestas,
incluyendo uno que retorna los resultados en formato XML y otro en formato JSON.
El siguiente diagrama resume algunos elementos claves en el proceso de bsqueda
Imagen 4: elementos claves en el proceso de bsqueda de Solr
5.5.1 Relevancia
La relevancia es el grado en que la respuesta a una bsqueda satisface al usuario. La pertinencia
de la respuesta a una consulta depende siempre del contexto en el que se realiza la bsqueda. Una
sola aplicacin de bsqueda puede usarse en diferentes contextos por usuarios con diferentes
necesidades y expectativas. Por ejemplo, un motor de bsqueda de datos sobre el clima podra ser
utilizado por un investigador de una universidad que estudia las tendencias del clima a largo plazo,
un agricultor interesado en el clculo de la fecha probable de la ltima helada de primavera, un
ingeniero civil interesado en los patrones de lluvia y la frecuencia de las inundaciones, y por un
estudiante universitario para planificar unas vacaciones en una regin y se pregunta qu ropa
llevar?. Debido a que las motivaciones de estos usuarios varan, la relevancia de cualquier
respuesta particular a una consulta variar tambin.
Luis Ignacio Aita
Pgina 60
Qu tan comprensibles deben ser las respuestas de una bsqueda? A igual relevancia, en
general, la respuesta a esta pregunta depende del contexto de la bsqueda. El costo de no encontrar
un documento concreto en respuesta a una consulta puede ser alto en determinados casos y muy
bajo en otros. Al configurar Solr, se debe buscar un equilibrio entre la exhaustividad de la bsqueda
y otros factores como la puntualidad y la facilidad de uso.
Los ejemplos anteriores demuestran la importancia de dos conceptos relacionados con la
relevancia:
La precisin es el porcentaje de documentos en los resultados que son relevantes.
Recall es el porcentaje de resultados relevantes devuelto sobre el total de resultados

relevantes que existen en el ndice. Se podra definir como recuperacin eficiente.
Volviendo a los ejemplos anteriores, es importante para una aplicacin de bsquedas legales
tener un porcentaje cercano al 100% de recall retornando todos los documentos que son relevantes
para una citacin. Es mucho menos importante que una aplicacin de recetas ofrezca este grado de
precisin, sin embargo es contraproducente retornar demasiados resultados abrumando al usuario.
En algunos contextos retornar menos resultados con mayor probabilidad de relevancia suele ser el
mejor enfoque.
Utilizando los conceptos de precisin y recall es posible cuantificar la relevancia entre los
distintos usuarios de un sistema y las consultas que realizan para una determinada coleccin de
documentos. Un sistema perfecto tendra 100% de precisin y un 100% de recall para cada usuario
y cada consulta. En otras palabras, equivaldra a recuperar todos los documentos relevantes y ni uno
ms. En trminos prcticos, cuando se habla de precisin y recall en los sistemas reales, lo ms
comn es centrarse en la precisin y recortar a un cierto nmero los resultados.
Utilizando las funciones de faceting, filtros de consultas y otros componentes de bsquedas, una
aplicacin Solr se puede configurar con la flexibilidad suficiente para permitir a los usuarios afinar
sus bsquedas con el fin de devolver los resultados ms relevantes. Es decir, Solr puede ser
configurado para equilibrar la precisin y el porcentaje de recall de forma tal que satisfaga las
necesidades de una comunidad de usuarios en particular.
La configuracin de una aplicacin Solr debera tener en cuenta:
Las necesidades de los diversos usuarios de la aplicacin (que pueden considerar facilidad
de uso y velocidad de respuesta, adems de las necesidades de informacin)
Luis Ignacio Aita
Pgina 61
Las categoras que sean significativas para estos usuarios en sus diferentes contextos (por
ejemplo, fechas, categoras de productos, o regiones)
Alguna relevancia intrnseca de los documentos (por ejemplo, podra tener sentido
garantizar que una descripcin oficial del producto o FAQ siempre se devuelva cerca de la
parte superior de los resultados de la bsqueda)
La edad de los documentos dado que en determinados contextos los documentos ms

recientes podran tener mayor importancia.
Teniendo todos estos factores en cuenta, a menudo es til en las etapas de planificacin de una
implementacin Solr esbozar los tipos de respuestas esperados frente a determinadas consultas de
ejemplo. Una vez que la aplicacin est funcionando, se pueden emplear una serie de metodologas
de prueba, tales como grupos de discusin, pruebas in-house, pruebas TREC y pruebas A / B para
ajustar la configuracin de la aplicacin de forma tal que satisfaga mejor las necesidades de sus
usuarios.
5.5.2 Modalidad y sintaxis de las consultas Solr

Solr soporta mltiples analizadores de consultas ofreciendo a los diseadores de las aplicaciones
que necesitan recuperar informacin flexibilidad y control en la forma en que se realizan las
consultas.
La forma ms simple y ms utilizada para realizar consultas a Solr es mediante la utilizacin de
las APIs pblicas HTTP. Una consulta se construye de la misma forma que cualquier direccin URL
sobre este protocolo. Por ejemplo, la siguiente consulta recupera todos los campos del documento
para la palabra video:
http://localhost:8983/solr/select?q=video
La URL incluye el nombre del host (localhost), el puerto (8983), el nombre de la aplicacin
(solr), el controlador de las solicitudes de consultas (select) y finalmente los parmetros de
bsqueda. (q=video).
El formato de respuesta estndar de Solr es XML y alternativamente se pueden solicitar otros
formatos tales como JSON, PHP, Ruby, etc. Los resultados se dividen en dos secciones: una seccin
denominada responseHeader con informacin sobre la propia respuesta y un seccin response con
la cantidad de documentos coincidentes con la consulta y los documentos propiamente dichos.
Luis Ignacio Aita
Pgina 62
La parte principal de la consulta es la que involucra los parmetros de consulta y es la que

permite controlar la ejecucin de la misma. Existe un conjunto de parmetros en comn para los
analizadores de consultas provistos en forma nativa por Solr Standard, DisMax & eDisMax y
adems cada uno de ellos tiene sus propios parmetros particulares.
En esta seccin se describen los principales parmetros comunes y los del analizador DisMax
utilizado para el proyecto. Para mayor informacin se puede consultar la documentacin oficial de
Solr en http://lucene.apache.org/solr/documentation.html.
Parmetro
Descripcin
sort
Ordena la respuesta a una consulta ya sea en forma ascendente o descendente. Por defecto
ordena en base a la puntuacin de la respuesta (scoring) y alternativamente por otro criterio
definido por el usuario.
start
Especifica un desplazamiento (por defecto 0) en los documentos que mostrarn la respuesta:

paginacin.
rows
Indica que cantidad de documentos se recuperarn (por defecto 10): paginacin
fq
Filter query. Aplica filtros a los resultados de la bsqueda.
debug
Retorna informacin adicional para debugging en la respuesta
wt
Writer Type. Especifica el formato de la respuesta. XML, JSON, PHP, etc.
cache=false
Por defecto Solr almacena en caches las consultas previamente realizadas. La utilizacin de
este parmetro permite indicarle a Solr que no recupere informacin de la cach.
Tabla 4: Parmetros comunes Solr
Parmetro
Descripcin
Query. Define los trminos a incluir en la bsqueda.
q.alt
Query alternative. Permite especificar una consulta para el analizador estndar que es
utilizada en la caso de que no se especifique ningn valor en el parmetro q. Tpicamente se
utiliza el valor q.alt="*.*".
qf
Query Fields. Especifica los campos a considerar en la consulta. Se les puede asignar un
factor de boosting utilizando el carcter ^para aumentar o disminuir la importancia de cada
uno de ellos. Por ejemplo qf="campoUno^2.3 campoDos campoTres^0.4"
mm
Min should match. Al procesar las consultas Solr reconoce tres tipos de clusulas:
obligatorias, prohibidas y opcionales. Por defecto Solr las trata como opcionales (parmetro
mm=0%), es decir recupera documentos aunque alguna de estas clusulas no tenga
coincidencias (Equivalente lgico OR). Mediante este parmetro se puede modificar el
nmero mnimo de coincidencias obligatorias. Puede especificarse en formato de porcentaje.
pf
Phrase boosting. Aumenta la puntuacin de los documentos en los casos en que los trminos
buscados aparezcan en una misma frase: cercana de los trminos.
tie
Tiebraker. Se especifica un valor flotante para utilizar como criterio de desempate en las
consultas. Cuando se busca un trmino en varios campos, cada campo genera una puntuacin
diferente. Con un valor 0.0 la consulta es totalmente disjunta (disjuntion max query), es decir,
solo el campo con mayor puntuacin contribuye al valor final. Por el contrario, un valor 1.0
indica que se suma la puntuacin de todos los campos. Un valor normalmente utilizado es
Luis Ignacio Aita
Pgina 63
0.1.
bq
Boost Query. Permite especificar una clusula de consulta adicional que se aadir a la
consulta principal del usuario e influir en el scoring de los documentos recuperados. Por
ejemplo, para aadir peso a los documentos ms recientes, puede utilizarse:
bq=date:[NOW/DAY-1YEAR TO NOW/DAY]^2.5
Pueden especificarse varios parmetros bq.
bf
Boost Funcions. Al igual que el anterior permite aadir clusulas adicionales a la consulta del
usuario para modificar el scoring, pero permite al usuario utilizar funciones. Se puede utilizar
cualquier funcin soportada en forma nativa por Solr, incluso en forma anidada. Por ejemplo:
recip(rord(myfield),1,2,3)^1.5.
Tabla 5: Parmatros del analizador de consultas DisMax
Luis Ignacio Aita
Pgina 64
Luis Ignacio Aita
Diseo e implementacin de la experimentacin
6.1
Introduccin
Pgina 65
La experimentacin que se describir en las secciones posteriores fue realizada en el marco de un

trabajo de extensin realizado dentro de la universidad en el proyecto Zonales. Este proyecto se
ejecut en dos etapas y se resumir en este captulo el objetivo del mismo y la evolucin en cada
etapa.
Posteriormente se describir el entorno de pruebas creado y utilizado para el presente trabajo de
tesina, explicando la labor realizada.
6.2
Zonales
6.2.1 Por qu Zonales?

Citando el documento tcnico-comercial creado oportunamente para dar marco al proyecto se
explica en los siguientes prrafos cual es la idea de la que nace el proyecto Zonales.
La proliferacin de medios masivos no se constata con una pluralidad de voces. Las empresas
mediticas comunican a una audiencia que representa una economa de escala por lo que se trata de
ofrecer productos comunicacionales lo ms abarcativos posible.
Y es en el cumplimiento de dicho objetivo que las identidades ms autctonas y regionales se
ven cercenadas. En definitiva, hoy en da los grandes medios de comunicacin nacionales no
reflejan las realidades particulares.
La gente necesita un lugar donde poder encontrar informacin local de manera simple. Porque la
comunidad esta necesitando un espacio para hacer pblicos sus propios contenidos, necesidades y
opiniones.
6.2.2 Objetivos
Generar un medio que brinde el espacio para que sus usuarios se apropien de l.
Poner nfasis en el sentimiento de pertenencia.
Reflejar las necesidades y realidades vecinales.
Insertarse en la comunidad irradiando una sensacin de mayor cercana.
Estimular y favorecer el desarrollo local y comunitario.
Luis Ignacio Aita
Pgina 66
6.2.3 Primera etapa del proyecto

La primer etapa del proyecto tuvo dos metas principales. Por un lado la organizacin del rea
tcnica y la transferencia de tecnologa respecto de gestin de proyectos mediante la modalidad de
gestin gil. Y por otro lado el desarrollo de una plataforma web que permita la gestin distribuida
geogrficamente de agencias productoras de noticias, dando un sentido de descentralizacin a la
produccin de contenidos. Como resultado de esta primer etapa se concretaron dos productos con
muy buen resultado para la firma: La plataforma de gestin de contenidos distribuidos
geogrficamente y lo que se denomin el Ecualizador de Inters, herramienta que permite a los
usuarios recuperar informacin segn sus preferencias.
En base a los objetivos propuestos para el proyecto se elabor un plan de trabajo cuyos puntos
principales eran los siguientes:
Creacin de un portal front-end para la visualizacin de los contenidos
Creacin de un back-end para la administracin del portal
Gestin de las zonas geogrficas en forma jerrquica.
Desarrollo de un Ecualizador de intereses que permitiera al usuario personalizar el uso de

la web. Adems de considerar la zona a la que pertenece el usuario, el ecualizador permite
configurar los intereses del usuario segn un conjunto predefinido de tags con los que se
clasifican las noticias.
Luis Ignacio Aita
Pgina 67
Imagen 5 Personalizacin de Zonales
Envo de notas y noticias por parte de los usuarios. Para esto se cre una seccin
denominada La voz del vecino
Funcionalidad de configuracin y extraccin de informacin de diversos medios y redes

sociales para alimentar automticamente el sitio con informacin publicada por los
principales actores de cada localidad o comuna. Este extractor de contenidos debe
considerar una herramienta que permita a un Administrador de contenidos configurar
dichas extracciones.
Para cumplir con estos objetivos se diseo una arquitectura inicial reflejada en el siguiente
grfico:
Luis Ignacio Aita
Pgina 68
Imagen 6 Arquitectura inicial de Zonales

Esta arquitectura contemplaba los siguientes componentes:
Un conjunto de herramientas de extraccin para cada tipo de fuente de informacin a

crawlear. Se prob originalmente con Apache Nutch y los plugins que la herramienta
brindaba.
Joomla! como componente CMS que permitiera gestionar los contenidos del portal y
adems ser extendido mediante su framework de desarrollo de componentes.
Un middleware denominado Middlezone que hiciera de facade entre el front y los

componentes de back.
Una base de datos Mysql para el CMS y los contenidos generados y extrados.
Se diseo un esquema especfico para estructurar los contenidos de Zonales denominado

XZone para su versin XML y JZone para la versin JSON.
Se utiliz la herramienta Apache Solr como motor de indexacin de los contenidos

almacenados en una base de datos relacional MySQL. La informacin solicitada desde el
Luis Ignacio Aita
Pgina 69
front a travs de la capa middleware era consultada mediante funciones de boosting en el

ndice Solr y recuperada desde la base de datos relacional.
Aunque no se lleg a realizar se contemplaba la posibilidad de utilizar un cluster Hadoop.
Como cierre de esta primer etapa se puso en lnea una versin inicial del sitio y los resultados del
ecualizador de inters fueron publicados en Intercom2010 en Puno, Per [Barry, Pez, Cortez
2010]. Este trabajo demostr la gran potencialidad del esquema de indexacin, bsqueda y
ordenamiento de informacin mediante el uso de las herramientas Solr-Lucene.
6.2.4 Segunda etapa del proyecto

Luego de esta primer etapa la empresa detect que el modelo de negocios pensado resultaba de
difcil implementacin pues requera de la instalacin o contratacin de agencias de noticias
distribuidas a lo largo y ancho del pas. Esta problemtica present un nuevo desafo: cmo obtener
informacin local (obtencin de informacin distribuida geogrficamente) de forma automtica y
clasificarla para utilizar la potencialidad del ecualizador de inters.
En esta segunda etapa denominada Georreferenciacin de contenidos es donde surge la
necesidad de desarrollar una herramienta de extraccin de contenido pblico de Internet (crawling),
que permita extraer informacin de redes sociales y portales para su clasificacin e indexacin,
fundamentalmente desde su perspectiva geogrfica, ya que el concepto Zonales as lo requera.
6.2.5 Construccin de un motor de extraccin de informacin

Para la extraccin de contenido pblico de Internet se desarrollo un motor (Crawler)
denominado dentro del proyecto como ZCrawler, el mismo se compone de un lenguaje de
extraccin que le permite a los usuarios mediante una especificacin comenzar a extraer
informacin siguiendo mltiples criterios y permitiendo la clasificacin de esta informacin segn a
quien se est evaluando.
6.2.5.1 Gramtica del lenguaje de extraccin
En la siguiente Imagen podemos observar la gramtica EBNF definida dentro del proyecto,
denominada zGram:
Luis Ignacio Aita
Pgina 70
Imagen 7: Gramtica de extraccin zGram

La estructura bsica de extraccin permite definir una zona geogrfica vinculada con la
informacin a extraer, esta decisin se enmarca en la necesidad de georreferenciacin de
contenidos. Luego se especifica la fuente a extraer, indicando al motor de extraccin el componente
especfico de extraccin a utilizar. Adems de la georreferenciacin se permiten utilizar otros
clasificadores mediante la utilizacin de tags. Finalmente el motor de extraccin permite configurar
la frecuencia de extraccin.
La herramienta de extraccin contempla un conjunto de utilitarios que permiten a quien realiza
las configuraciones de extraccin realizar anlisis previos de la informacin a extraer y simular
resultados de extraccin para evaluar si es lo que se desea.
A continuacin podemos observar algunos ejemplos de extraccin:
extraer para la localidad 'Puerto Madryn' mediante la fuente facebook a partir del usuario
'LU17.com' y 'Madryn TV' y de amigos del usuario 'Cultura Puerto Madryn' incluye
comentarios de los usuarios: 'Demin Barry', 'Juan Manuel Cortez'.
extraer para la localidad 'Argentina' mediante la fuente twitter asignando los tags
'poltica','actualidad' a partir del usuario '@CFKArgentina' y del usuario '@mauriciomacri' y
del usuario '@ricalfonsin' incluye comentarios y filtrando por con al menos 50 actions.
extraer para la localidad 'Crdoba' mediante la fuente twitter asignando los tags
'Deporte','futbol' a partir de las palabras crdoba, deporte, futbol, talleres y filtrando al
menos 75% de las palabras deben estar y con al menos 25 actions incluye los tags de la
fuente.
extraer
para
la
localidad
'rosario'
mediante
la
fuente
rss
ubicada
en
'www.lacapital.com.ar/rss/ultimomomento.xml' a partir de todo incluye los tags de la fuente.

Luis Ignacio Aita
Pgina 71
Imagen 8: Carga y validacin de extracciones

En la imagen 8 podemos observar el mecanismo de carga de una extraccin donde la aplicacin
permite generar una extraccin ya sea mediante su gramtica o mediante un asistente.
A continuacin en la imagen 9 se pueden observar tanto el resultado de la generacin de la
gramtica de extraccin como potenciales resultados de las mismas para que el gestor de
extracciones pueda evaluar si es lo deseado.
Imagen 9: Validacin de una gramtica de extraccin

Se desarrollaron servicios de extraccin para las redes sociales Facebook y Twitter y para medios
digitales que contaran con RSS estndar. Adems se han adaptado algunos parsers especficos para
blogs y diarios en lnea que no contaban con una implementacin estndar de RSS. En particular se
implementaron conectores para los diarios Jornada y Chubut, ambos de la provincia de Chubut.
Luis Ignacio Aita
Pgina 72
Adicionalmente para los grandes medios nacionales se adaptaron extractores ya que sus
definiciones de RSS no accedan ni a los comentarios ni a las referencias (links) externas ni a las
imgenes.
A partir de poder extraer imgenes de las noticias y comentarios se mejor la herramienta
permitiendo realizar un tratamiento comn a todo el material multimedia asociado a una
publicacin realizando una gestin uniforme tanto para Facebook, Twitter y las pginas sindicadas.
6.2.6 Clasificacin de la informacin.

El etiquetado automtico (autotagging) se incorpora al proyecto Zonales como un modo de
colaborar con la carga de contenido. El objetivo fundamental es que tanto en la carga manual de
contenidos como en su incorporacin automtica mediante medios de sindicacin (Atom, RSS, etc.)
o extraccin de redes sociales, el editor cuente con opciones de tags sugeridas por el sistema,
teniendo en cuanta aspectos de espacios semnticos que fueron previamente determinados por
expertos en distintas categoras de noticias.
La versin original sugera tags en funcin de las palabras de un contenido. Esto no es ptimo
porque las palabras no definen la temtica de un contenido. Muchas veces son frases o
construcciones complejas las que cumplen este cometido. Para esta tarea se han utilizado
caractersticas avanzadas de Solr.
6.2.7 Bsqueda de Informacin y Apache Solr

El desafo planteado de extraccin de mltiples fuentes de informacin impone otro desafo que
el proyecto deba resolver: la escalabilidad, debido al gran procesamiento de informacin extrada.
Por ello se trabaj intensamente, donde los resultados fueron publicados en el trabajo
denominado Distributed Search on Large NoSQL Databases [Tinetti et. al., PDPTA2011] donde
se puede apreciar que:
La bsqueda secuencial de cualquier tipo de informacin presenta varios problemas, siendo el
principal la falta de escalabilidad. Una solucin a este inconveniente es el uso de estructuras de
datos que permitan ser rpidamente consultadas.
El indexado transforma los datos desde su forma original en una estructura que facilita la
bsqueda y recuperacin de los mismos en forma rpida y precisa, por ejemplo un ndice invertido
Hatcher, Gospodneti 2004], un ndice de citas, una matriz o un rbol.
Luis Ignacio Aita
Pgina 73
El proceso de indexado generalmente requiere un anlisis y procesamiento de los documentos a

incluir en el ndice: lematizacin, tokenizacin, anlisis fontico, etc. Estos pasos introducen
problemas y desafos importantes al momento del procesamiento [Hatcher, Gospodneti 2004], que
no son alcance del presente trabajo.
Dentro del estudio del presente trabajo, debido a la facilidad de implementacin en un ambiente
heterogneo, se lleg a la conclusin que una solucin ptima requerira el uso del concepto de base
de datos de particin horizontal o sharding [Henderson 2006].
Apache Solr, que utiliza una base de datos no convencional para almacenar el ndice de bsqueda
(listas invertidas), provee mltiples capacidades para el escalado horizontal, permitiendo dividir la
carga de trabajo entre mltiples instancias lo que permite una fragmentacin horizontal de los
mismos entre mltiples servidores Apache Solr, a los cuales se les denomina shards. Las bsquedas
son luego redirigidas a cada shard, y finalmente una respuesta nica es construida en base a los
resultados obtenidos de cada uno. Esta tcnica es utilizada especialmente cuando se cuenta con un
gran volumen de datos sobre el cual realizar consultas.
6.2.8 Arquitectura
La siguiente imagen resumen la arquitectura del proyecto finalizada la segunda etapa
Luis Ignacio Aita
Pgina 74
Imagen 10 Arquitectura Zonales en la segunda etapa del proyecto
6.2.9 Resultados del proyecto

Si bien no se ha realizado una carga exhaustiva de fuentes para la Argentina un equipo de
especialistas en comunicacin y medios orientados a los negocios sobre Internet configur un
conjunto de extracciones sobre las principales localidades del pas, seleccionando fuentes tanto de
Facebook y Twitter como de diarios digitales con servicios de Feeds RSS.
La plataforma con esta configuracin estuvo aproximadamente seis meses en lnea generando la
base de datos de aproximadamente un milln y medio de post sobre la cual se centra el entorno de
pruebas mencionado en el presente trabajo.
Luis Ignacio Aita
Pgina 75
Desarrollado en conjunto con la empresa que recibi la transferencia tecnolgica y

complementando el proceso de extraccin se gener un portal de publicacin de noticias orientado a
la zonificacin de resultados como se puede apreciar en la siguiente imagen.
Imagen 11: Portal Zonales
6.3
Bitcora del proyecto de Tesina
El alcance del entorno de pruebas para el presente trabajo de tesina est limitado al ndice Solr
construido durante el proyecto Zonales.
6.3.1 Diseo
Al decidir la utilizacin de la herramienta Apache Solr para el indexado y la bsqueda de
informacin se tomaron dos decisiones de arquitectura claves que afectaban al resto de los
componentes de la solucin:
El diseo del esquema de documentos que se utilizara para indexar la informacin.
La configuracin de la instancia Solr y el diseo de las consultas para recuperar la

informacin buscada.
En el proyecto Zonales, el diseo del ndice y la configuracin de la instancia Solr para

almacenar la informacin se realiz en dos etapas claramente diferenciadas por la arquitectura
pensada para la solucin en cada una de ellas.
Luis Ignacio Aita
Pgina 76
En ambas etapas la unidad de informacin o documento para Zonales era el post. Un post es un
artculo re-publicado en Zonales, proveniente de una red social como Facebook o Twitter, de un
medio digital o de cualquier otra fuente que se indexaba y clasificaba para luego mostrarlo
zonificado y ecualizado segn los intereses del usuario en la web. En la segunda etapa se
comenz a considerar los comentarios de los usuarios sobre las publicaciones extradas
(crawleadas) y tambin se indexaron como posts vinculados con otro post preexistente en el ndice.
6.3.1.1 Etapa 1 - Indexacin de posts
En la primer etapa del proyecto el concepto central que guiaba el diseo la arquitectura de la
plataforma y el desarrollo de sus componentes era el del Ecualizador de Inters[Barry, Pez,
Cortez 2010].
La informacin poda ser generada de dos maneras:
Por las agencias de contenidos distribuidas en todo el pas
Por los mismos lectores del portal a travs de secciones como La voz del vecino
En ambos casos dicha informacin se registraba en la Plataforma Zonales bajo el concepto de

artculo heredado del sistema de gestin de contenidos (CMS) Joomla! que se utiliz como parte
de la arquitectura. Esta herramienta utiliza una base de datos relacional MySQL para el registro de
los datos y en particular una tabla del modelo para guardar los artculos.
Para complementar la funcionalidad brindada por el CMS y poder ecualizar la informacin se
desarroll un componente adicional utilizando el framework de desarrollo provisto por Joomla! que
permita gestionar etiquetas o tags y luego asociarlas a los artculos.
Tomando como base el modelo de datos de Joomla! CMS, en particular de la tabla que
almacenaba los artculos y las etiquetas asociadas por el componente de etiquetado se construy la
primer versin del esquema para almacenar los post de Zonales.
Para indexar la informacin desde una base de datos Solr provee herramientas de importacin
denominadas DataImportHandler. Uno de estos handlers permite indexar informacin desde bases
de datos MySQL, siendo el utilizado para tal fin, permitiendo realizar la indexacin en forma total o
incremental.
Luis Ignacio Aita
Pgina 77
La indexacin total permiti reconstruir el ndice cada vez que que el esquema era modificado
por algn motivo durante el desarrollo de la plataforma. Cuando un contenido era cargado a travs
del portal, este era indexado en Solr en forma incremental.
En la primer versin diseada del esquema Solr para Zonales, dentro de una noticia, podemos
destacar los campos (fields):
title: los ndices sobre este field tenan un peso superior en el caso de las bsquedas de
trminos.
introtext y fulltext: representaban el universo de trminos de una noticia.
tagsnames y tagsvalues: esta tupla de valores tenan un peso superlativo respecto del
ecualizador de inters. La tupla inclua la zonificacin de la noticia.
Para mayor informacin se puede ver la definicin de campos del esquema en el Anexo 1:
Definicin de campos del esquema Solr en la etapa 1.
6.3.1.2 Etapa 1 Recuperacin de posts
Complementariamente a la indexacin se trabaj fuertemente en la configuracin de Solr para la

bsqueda y recuperacin de la informacin. La plataforma, a travs del portal web, permita a los
usuarios seleccionar la zona a la cual pertenecan a travs de un mapa en el home del sistema y
ecualizar sus intereses utilizando una herramienta de configuracin a travs de bandas de categoras.
Luis Ignacio Aita
Pgina 78
Imagen 12: selector de intereses
Imagen 13: selector de zona del portal
Luis Ignacio Aita
Pgina 79
Tanto la zona como la configuracin de intereses se guardaba en un modelo de datos para los
usuarios registrados, almacenndolos en una base de datos de la plataforma, y para el caso de los
visitantes annimos se mantenan sus selecciones utilizando cookies en el navegador.
La estrategia de recuperacin de la informacin depende de cuatro factores:
La zona del usuario
Los pesos indicados en las bandas de intereses que el usuario ha configurado (manifestado)
El dato temporal del post. En la mayora de los casos una noticia pierde inters con el paso
del tiempo desde su publicacin. Estrategia utilizada fundamentalmente para el
ordenamiento de la informacin
Los trminos adicionales buscados.
Es esta primer etapa se puso mayor nfasis en los intereses del usuario a travs del etiquetado de
la informacin y a los trminos buscados. En menor medida se consider la Zona, ya que la misma
era considerara en las bsquedas como un trmino (keyword) ms.
Para la recuperacin de la informacin se realiz una configuracin denominada zonalesContent
haciendo uso del analizador de consultas DisMax (el que viene por defecto en Solr). Podemos
destacar algunas configuraciones y parametrizaciones realizadas sobre el analizador de consultas
DisMax para la recuperacin de la informacin.
Se aument la importancia de la coincidencia de trminos en determinados campos

utilizando los parmetros qf y pf de Solr. La relacin de pesos utilizada fue de 2 para los
tags, 1 para el ttulo, 0,7 para el texto de introduccin y 0,5 para el texto completo.
Se especific un valor bajo para el parmetro tie (0,01) dndole mayor importancia a los
campos con ms peso.
Se configur un valor de 0% para el parmetro mm, con lo cual todas las clusulas son
opcionales.
Se configur el parmetro q.alt=*.* para que en caso de no especificarse un trmino para la

bsqueda se consideren todos los documentos.
Luis Ignacio Aita
Pgina 80
Para utilizar el analizador de consultas extendido zonalesContent desde los servicios que
consultan el ndice Solr a travs de querys sobre el protocolo HTTP, es necesario agregar en las
consultas el parmetro qt=zonalesContent.
Para informacin sobre la funcionalidad de cada parmetro mencionado ver Modalidad y sintaxis
de las consultas Solr.
Para mayor detalle de la configuracin ver Anexo 2: Extensin analizador de consultas DisMax
en solrconfig.xml en la etapa 1.
6.3.1.3 Etapa 2 Indexacin de posts
A raz del nuevo desafo de obtener informacin distribuida geogrficamente de forma

automtica y clasificarla para utilizar la potencialidad del ecualizador de inters, se planteo en la
segunda etapa Georreferenciacin de contenidos el desarroll de una herramienta de extraccin
de contenido pblico de Internet (crawling), que extraiga informacin de redes sociales y portales
para su clasificacin e indexacin, fundamentalmente desde su perspectiva geogrfica, ya que el
concepto Zonales as lo requera.
En primera instancia para geolocalizar la informacin se utilizaron coordenadas geogrficas
asociadas a cada post, que luego permitieran trabajar con herramientas GIS (Sistemas de
Informacin Geogrfica por sus siglas en ingls) sobre la informacin generada.
Debido a que la ltima versin de Solr utilizada en ese momento (versin 1.4.1), no tena aun
capacidades de indexacin de este tipo de informacin se decidi ampliar el concepto de
georreferenciacin indexando datos de zona en forma semntica para aprovechar la potencia de Solr
en la recuperacin de la informacin a travs de este tipo de informacin. Reforzado esto ltimo a
que esta etapa del proyecto no requera una precisin de la geolocalizacin, mayor a la de un barrio
de una localidad
Para esto se ampli el esquema incorporando un campo (field) adicional denominado
zoneExtendedString que almacenaba la zona geogrfica en formato de cadena incluyendo toda la
jerarqua de la ubicacin geogrfica, desde el dato de menor escala (barrio, localidad) hasta el de
mayor escala, que se decidi en dicho momento no superar geogrficamente a la Repblica
Argentina como contenedor mximo geogrfico. Igualmente se evalu que el refactoring necesario
para ampliar el concepto no requera de un esfuerzo mayor.
Luis Ignacio Aita
Pgina 81
Asociado al desarrollo de la herramienta de extraccin y a la orientacin de la plataforma hacia

la georreferenciacin de contenidos se introdujeron muchos cambios en la arquitectura, como se
observa en la Imagen 10 de la seccin anterior, donde el almacenamiento e indexacin de la
informacin generaron varios nuevos desafos a resolver.
La extraccin de informacin heterognea de diversas fuentes y el proceso de normalizacin y
homogenizacin de la informacin para ajustarla a una estructur nica fue el mayor desafo. El
caso ms emblemtico fue el de la extraccin en informacin a partir de fuentes RSS, gran parte de
las cuales no respetaba los estndares para comentarios, enlaces (links) y contenido multimedia.
Para poder lograrlo se desarrollo una herramienta de configuracin de selectos CSS que, en
conjunto con una serie de funciones de parsing incorporadas al extractor correspondiente
permitieron normalizar esta informacin.
Este esfuerzo de homogenizacin de la informacin deriv en la creacin de dos formatos
normalizados para estructurar las noticias que permitieron contener tanto los posts extrados de las
diversas fuentes como los datos de clasificacin asociados. Se decidi utilizar los formatos
estndares XML y JSON para contener la estructura de datos diseada y se la bautiz como XZone
y JZone respectivamente.
Las estructura diseada registra la siguiente informacin:
Fuente de la noticia (source). Por ejemplo Facebook, Twitter, lanacion.com, etc.
Id nico que identificaba a la noticia. Si la fuente posea un Id se intentaba respetarlo. (id)
Autor (fromUser)
Destinatarios, en la caso que los tuviera. Comn en las redes sociales. (toUsers)
Ttulo (title)
Texto (text). Contenido de la noticia.
Enlaces a otras pginas (links)
Cantidad de cada tipo de acciones sobre la noticia (actions). Esto es comentarios, me

gusta, retweets, compartir, favoritos, etc.
Fechas de creacin y modificacin de la noticia (created, modified)
Luis Ignacio Aita
Pgina 82
Relevancia de la noticia, calculada a partir de los actions o modificada desde el portal

Zonales (relevance). Hace ms homogneos los pesos de las noticias de distintas fuentes
heterogneas.
Zona (zone).
Etiquetas (tags) que permite clasificar la noticia.
verbatim. La noticia en formato JZone almacenada en Solr para mayor velocidad de

recuperacin.
Para ver las estructura completas se puede consultar el Anexo 3: Formatos estandarizados de
noticias (posts).
El diseo del esquema para la construccin del ndice Solr surgi en forma directa de estas
estructuras de datos. Salvando algn trabajo de aplanamiento de datos y de configuracin de las
herramientas de lematizacin, tokenizers, etc. la estructura se mantuvo intacta. El esquema
resultante puede consultarse en Anexo 4: Definicin de campos del esquema Solr en la etapa 2.
6.3.1.4 Etapa 2 - Proceso de extraccin
El proceso de extraccin de la informacin para almacenar en el ndice se divide en dos etapas

claramente diferenciadas: configuracin y extraccin.
Luis Ignacio Aita
Pgina 83
Imagen 14: proceso de extraccin e indexacin de la informacin

Para la etapa de configuracin se dise la gramtica mencionada en la seccin anterior
conjuntamente con un conjunto de herramientas que hacan uso de la misma y permitan almacenar
y ejecutar las configuraciones:
CMUtils: portal web que permite generar y compilar la gramtica a travs de una interfaz
web, testear la extraccin y establecer la periodicidad de ejecucin de la misma en el
scheduler, entre otras utilidades adicionales.
Luis Ignacio Aita
Pgina 84
ZParser: servlet Java que recibe la gramtica en formato de cadena de texto, la compila y
retorna el resultado de la compilacin.
ZScheduler: segn la periodicidad configurada recupera la gramtica almacenada, ejecuta

la extraccin a travs de las distintas herramientas de extraccin y almacena los resultados
en el ndice Solr.
Extractores: cada fuente de informacin tiene sus propias APIs o procedimientos de

obtencin de informacin. Para eso se crean los extractores, por el momento para Facebook,
Twitter y Feeds RSS.
Una decisin relevante aunque no necesariamente correcta fue la de prescindir de la base de

datos relacional MySQL para guardar los posts y guardarlos directamente en el ndice Solr mediante
un campo verbatim configurado como stored. Un campo configurado de esta forma en Solr
permite persistir la informacin y recuperarla en forma directa desde el ndice. La performance
lograda es superior a tener la info en otra fuente pero la recuperacin de la misma se puede realizar
unicamente a travs de consultas Solr.
6.3.1.5 Etapa 2 Recuperacin de posts
Partiendo de la premisa de mostrar al usuario la informacin ordenada en base a su contexto

geogrfico y sus preferencias, se redise el portal web considerando cuatro aspectos principales:
Relevancia: se le permita a los lectores de zonales elevar o disminuir la relevancia de una

noticia desde la propia web. Se utiliz adems como parmetros la cantidad de me gusta,
retweets y comentarios de cada post para calcular la relevancia en base a un frmula de
peso para cada caso.
Tipo de fuente: los lectores del portal pueden seleccionar el tipo de fuente de la cual
recuperar las noticias. En principio se dividi la recuperacin en dos conceptos: En la red
para englobar las noticias de las redes sociales Facebook y Twitter, y Noticias para la
informacin recuperada desde medios digitales a travs de RSS.
Temporalidad de la noticia: considerando que para el comn de los los lectores las noticias
pierden relevancia con el paso del tiempo este es un aspecto de peso en la recuperacin de la
informacin.
Zona: el usuario deba ver principalmente noticias de su zona y aledaos.
Luis Ignacio Aita
Pgina 85
Se incorporaron un conjunto de selectores en el portal que permitieran al usuario manipular estos

aspectos.
La seleccin de zona puede realizarse escribiendo dentro de un selector alfanumrico ubicado en
la parte superior del portal o bien seleccionando la zona navegando a travs del mapa ubicado en la
seccin izquierda.
Imagen 15: Selector de zona del portal
Debajo del selector alfanumrico de zona se ubica un segundo selector que permite elegir la
fuente de informacin de las noticias.
Imagen 16: Selector de fuente de informacin
El ltimo de los selectores se centra en el orden de la informacin y permite al usuario elegir si

quiere ver las noticias ms recientes o ms relevantes. Al construir este selector notamos que al
seleccionar el orden por relevancia, existan noticias que haban logrado una relevancia muy alta
pero tena mucha antigedad. Si ninguna noticia lograba la misma relevancia continuaran al tope
de la recuperacin de informacin. Frente a este problema se decidi fragmentar la bsqueda por
relevancia en cuatro intervalos temporales: hoy, ltima semana, ltimo mes e histrico, logrando as
evitar el efecto mencionado anteriormente.
Luis Ignacio Aita
Pgina 86
Imagen 17: Selectores de temporalidad y relevancia
Una vez construidos los selectores para el portal, el primer desafo que se present fue la
construccin de la consulta Solr a partir de los valores seleccionados por el usuario.
Lo primero que advertimos fue la prdida de todos estos valores cuando el usuario recargaba la
pgina o la abandona y luego retornaba. Para evitarlo se dise un estructura para almacenar
informacin de contexto denominada ZCtx que permita gestionar estos valores y se diseo una
arquitectura que contemplaba la sincronizacin bidireccional de datos entre los clientes y el
servidor.
La estructura ZCtx contena la siguiente informacin:
filters(filtros): sub-estructura que almacena la seleccin de temporalidad, fuentes y etiquetas

(tags).
zTab: registraba la pestaa seleccionada para el tipo de fuente En la red o Noticias
selZone: la zona seleccionada por el usuario
start: relacionado con la paginacin, permita indicar a partir de que noticia se deseaba
continuar recuperando resultas (Ver mas...) utilizando los parmetros start y rows de Solr
(ms informacin en Modalidad y sintaxis de las consultas Solr).
fisrtIndexTime, firstModifiedTime: relacionado con la paginacin de noticias cuando el

criterio de orden era temporal.
maxRelevance: dem anterior cuando el criterio de orden era la relevancia.
searchKeywords: palabras buscadas
order: registraba el ltimo criterio de orden seleccionado.
En cuanto a la sincronizacin bidireccional, la misma se lograba mediante la utilizacin de websockets, en particular socket.io y el almacenamiento de datos en el navegador utilizando cookies.
Un requerimiento HTTP estndar realiza una peticin desde el cliente al servidor y espera la
respuesta. Una vez que obtiene la respuesta, el canal de comunicacin se cierra y es reabierto en
Luis Ignacio Aita
Pgina 87
caso de un nuevo requerimiento. Por el contrario, los web-sockets permiten mantener el canal de
comunicacin constantemente abierto entre los clientes y el servidor para el intercambio de datos,
facilitando al desarrollador el diseo de mecanismos de identificacin de clientes activos para luego
poder enviar mensajes broadcast mediante tcnicas de server-push[Bozdag et al., 2007].
Para la sincronizacin del contexto Zonales se desarroll una librera cliente y un servicio.
Ambos utilizan la herramienta socket.io [http://socket.io/] para la comunicacin sobre web-sockets.
Cuando el contexto cambia por alguna accin del usuario en el navegador se emite un aviso al
servidor para su actualizacin. Cuando el contexto cambiaba en el servidor, por ejemplo por la
llegada de nuevas noticias para una zona determinada, se actualizaban los contextos del lado cliente
para todos los usuarios conectados con dicha zona seleccionada a travs de mensajes broadcast.
Finalmente se resolvi la forma en la que se construye la consulta Solr. Desde los primeros
diseos la premisa siempre fue lograr, partiendo del contexto descripto anteriormente, una nica
consulta que recupere un conjunto de noticias para un cliente y se las enve en un nico mensaje
sobre el web-socket. Para ello debamos disear una consulta que contemplara todos los aspectos
mencionados dentro de sus parmetros, obteniendo toda la informacin necesaria para construirla a
partir del contexto ZCtx.
Como parte del desafo de equilibrar la zona y la temporalidad de la noticia una primer solucin
fue simplemente filtrar la recuperacin de noticias por zona a travs del campo campo zoneName y
ordenar los resultados por fecha o relevancia como se mencion anteriormente.
Analizando los resultados obtenidos y considerando los escenarios de pruebas planteados se
pudieron observar dos inconvenientes en esta solucin:
Si la zona no contena noticias el portal quedaba vaco de contenido
Un usuario de, por ejemplo, Rosario muy probablemente le interesen adems las noticias de
Santa Fe.
A partir de estos problemas surgi la ampliacin del concepto semntico de zona a travs del
campo zoneExtendedString, plasmando las jerarquas existentes en la realidad barrio, localidad,
provincia, pas en una cadena de texto, permitiendo adems considerar en las consultas conceptos
de cercana a travs de estas jerarquas.
Dentro de la jerarqua de zonas se considera como padres a las zonas que incluyen un conjunto
de hijos que tambin son zonas. Siguiendo con el ejemplo anterior, la localidad de Rosario es
Luis Ignacio Aita
Pgina 88
hija de la provincia de Santa Fe mientras que Argentina como pas es padre de la provincia de
Mendoza.
La recuperacin por tipo de fuentes fue la ms sencilla de lograr dado a que se limita a filtrar la
informacin a travs del campo source. Debido a que solamente consideramos dos posibilidades,
cuando el usuario selecciona En la red el sistema recupera las noticias cuyo valor para el campo
mencionado es Facebook o Twitter y cuando selecciona Noticias simplemente filtra por el caso
contrario, es decir, noticias que no son ni de Facebook ni de Twitter.
A continuacin se muestran a modo de ejemplo parte de las consultas Solr que contemplan este
filtro:
En la red: ...&q=docType:post+AND+source:(facebook+OR+twitter)&bf=o...
Noticias: ...&q=docType:post+AND+!source:(facebook+OR+twitter)&bf=o
...
Ordenar la noticia por relevancia o por los ms recientes tambin se logr en forma rpida
modificando un parmetro de orden de la consulta, utilizando el campo relevance o modified (fecha
y hora de ltima modificacin del post) respectivamente.
...&sort=relevance+desc&...
...&sort=modified+desc&...
Las pruebas narradas en la siguiente seccin se realizaron haciendo foco en la temporalidad y la

localizacin de la informacin, aspectos por los cuales se trabaj con las funciones de boosting de
Solr.
6.3.2 Pruebas
La bsqueda de la consulta Solr que permitiera recuperar la informacin teniendo en cuenta los
aspectos de temporalidad y zona se realiz a travs de mtodos de prueba sucesivas, refinando las
consultas en cada iteracin, analizando en cada uno de ellas los resultados obtenidos en
comparacin con los esperados y volviendo a ajustar los parmetros.
Se utilizaron para tal fin boosting querys (bq) y boosting functions (bf), parmetros que
permitieron especificar un factor que aumentara o impulsara la importancia de determinados
campos, valores o combinacin de ambos en la consulta.
Luis Ignacio Aita
Pgina 89
Debido a la problemtica planteada se decidi la utilizacin de tcnicas de TDD (Test Driven

Development o Desarrollo Guiado por Pruebas) como opcin vlida para las pruebas de
recuperacin y boosting realizadas durante el proceso, brindando una opcin repetible que
permitiera garantizar el cumplimiento del objetivo de las pruebas a alcanzar para los distintos
escenarios y sus variantes.
Para la ejecucin de las pruebas se utiliz la segunda versin del esquema diseado en la ltima
etapa del proyecto. Ver Anexo 4: Definicin de campos del esquema Solr en la etapa 2.
Se disearon distintos escenarios de prueba, cada uno de los cuales supona la ejecucin de
cambios en el contexto por parte del usuario, planteando los resultados esperados en relacin al
orden de las noticias, abarcando las combinaciones que se consideraron de mayor importancia.
Es importante considerar el razonamiento seguido para el planteo de los resultados esperados
cuando la consulta involucraba estos aspectos. Es decir, cuando un usuario deseaba ver las noticias
de su zona ordenadas desde la ms reciente a la ms antigua.
Partiendo de la suposicin de la existencia de un conjunto de datos que recibe noticias extradas
de diversas fuentes en forma constante, tanto para la zona del usuario, por ejemplo su localidad,
como para el resto de los elementos de la jerarqua geogrfica (barrios, provincia, pas, etc.), tanto
ascendente como descendente, se consider que, para un usuario de un determinada localidad,
seran de mayor relevancia las noticias de su provincia dentro de las ultimas cuarenta y ocho horas
que las de su localidad con mayor antigedad, por ejemplo de cinco das.
Siguiendo este razonamiento se dividi la temporalidad en cuatro franjas que, combinadas con
las jerarquas geogrficas, definan el siguiente orden esperado en los resultados:
1. Noticias de la zona seleccionada dentro de las 48 horas
2. Noticias de los hijos de la zona seleccionada dentro de las 48 horas
3. Noticias de los padres de la zona seleccionada dentro de las 48 horas.
4. Noticias de la zona seleccionada desde 48 horas hasta 1 semana
5. Noticias de los hijos de la zona seleccionada desde 48 horas hasta 1 semana
6. Noticias de los padres de la zona seleccionada desde 48 horas hasta 1 semana
7. Noticias de la zona seleccionada desde 1 semana hasta 1 mes
Luis Ignacio Aita
Pgina 90
8. Noticias de los hijos de la zona seleccionada desde 1 semana hasta 1 mes

9. Noticias de los padres de la zona seleccionada desde 1 semana hasta 1 mes
10. Resto de las noticias respetando la temporalidad.
Sobre el final del proyecto advertimos que en cada una de las franjas no consideramos las
noticias de zonas hermanas, es decir zonas que comparten el mismo padre. Por ejemplo, en el
caso de una localidad, tener en cuenta el resto de las localidades de la misma provincia. Para salvar
esta omisin se agreg al esquema el campo zonaPartialExtendedString cuyo valor se copiaba del
campo zoneExtendedString pero utilizaba un tipo de dato diferente. Este tipo de datos se
configur con un tokenizer que divida el texto carcter a carcter y otorgaba mayor nivel de
coincidencia en las zonas con la misma terminacin, como en el caso de localidades hermanas.
Por ejemplo, las zonas Puerto Madryn, Chubut, Argentina y Trelew, Chubut, Argentina
coinciden en su terminacin a partir de la provincia.
6.3.2.1 Escenarios
Los distintos escenarios de prueba se construyeron combinando conjuntos de datos y criterios de

bsqueda donde para cada combinacin se especificaron los resultados esperados.
Para facilitar la creacin de los conjuntos de datos, la sistematizacin de las pruebas y el anlisis
de lo resultados, se utilizaron valores descriptivos de la noticia dentro de la prueba en el campo
verbatim. Por ejemplo, para una noticia extrada de Facebook con una antigedad de tres das, una
relevancia con valor 20 para la zona Puerto Madryn en el campo verbatim se grab la siguiente
informacin: Noticia 3 das - Puerto Madryn, Chubut, Argentina Facebook R20.
El primer conjunto de datos D1 se compone de treinta y cinco noticias, organizadas en subconjuntos de cinco (5) noticias de la siguiente forma:
Sub-conjunto de noticias de barrio Centro, localidad Puerto Madryn, Chubut
Sub-conjunto de noticias de localidad Puerto Madryn, Chubut
Sub-conjunto de noticias de la provincia de Chubut
Sub-conjunto de noticias de otra localidad de la provincia (hermana): Trelew, Chubut
Sub-conjunto de noticias de una localidad de otra provincia: Rosario, Santa Fe
Sub-conjunto de noticias de otra provincia: Mendoza
Luis Ignacio Aita
Pgina 91
Sub-conjunto de noticias a nivel pas: Argentina
Cada uno de estos sub-conjuntos se compone con noticias de distinto valor temporal:
Una noticia de hoy
Una noticia de ayer
Una noticia con 3 das de antigedad
Puede examinarse el conjunto de datos completo en Anexo 5: Set de datos de pruebas D1.
Para definir los criterios de bsqueda se abarcaron distintos niveles de jerarqua geogrfica,
considerando como Nivel 1 a la zona de mayor escala, es decir Argentina. Se utilizaron los
siguientes criterios:
C1 - Recuperar las noticias de Puerto Madryn, Chubut, Argentina Nivel 3
C2 - Recuperar las noticias del barrio Centro, Puerto Madryn, Chubut, Argentina Nivel 4
C3 - Recuperar las noticias de Trelew, Chubut, Argentina Nivel 3
C4 - Recuperar las noticias de la provincia de Chubut, Argentina Nivel 2
El segundo conjunto de datos D2 contena cinco noticias adicionales, que tienen por objeto
principalmente simular la dinmica de ingreso de nueva informacin. Es decir, la extraccin de
noticias en Zonales se realiza en forma constante de acuerdo a la programacin del scheduler.
Los datos adicionales agregados son:
Una noticia de Puerto Madryn, Chubut de ahora (ms reciente)
Una noticia de Puerto Madryn, Chubut de 3 das de antigedad (ms de 48 horas)
Una noticia de Sarmiento, un barrio de Trelew, Chubut de ahora (nivel 4 en localidad

hermana, temporalidad ms reciente)
Una noticia de Comodoro Rivadavia de ahora (localidad hermana, temporalidad ms

reciente)
Una noticia de Formosa, Formosa de ahora (localidad de otra provincia, temporalidad ms

reciente)
Luis Ignacio Aita
Pgina 92
Puede examinarse el conjunto de datos completo en Anexo 6: Set de datos de pruebas D2.
La combinacin de ambos conjuntos de datos con los criterios definidos dieron origen a un total
de ocho escenarios reflejados en la siguiente tabla:
Escenario
Conjunto de Datos
Criterio
Boosting
Resul. Esperados
E1
D1
C1
RE1
E2
D1
C2
RE2
E3
D1
C3
RE3
E4
D1
C4
RE4
E5
D2
C1
RE5
E6
D2
C2
RE6
E7
D2
C3
RE7
E8
D2
C4
RE8
Tabla 6: Escenarios
Para finalizar se resume en la siguiente tabla los resultados esperados para cada uno de los
escenarios.
Escenario
Resul. Esperados Orden esperado de las noticias
E1
RE1
Se espera recuperar en primer lugar las noticias en el rango de 48 hs. para Puerto
Madryn, luego las del barrio Centro de Puerto Madryn, Chubut, Trelew y
finalmente las de Argentina y las de localidades de otras provincias.
A continuacin las noticias del rango 48hs. a 1 semana y 1 semana a 1 mes, ambos
en el mismo orden de zona descripto anteriormente.
E2
RE2
Se espera recuperar en primer lugar las noticias en el rango de 48 hs. para barrio
Centro de Puerto Madryn, luego las de Puerto Madryn, Chubut, Trelew y
E3
RE3
Se espera recuperar en primer lugar las noticias en el rango de 48 hs. para Trelew,
luego las de Chubut, Puerto Madryn, barrio Centro de Puerto Madryn y finalmente
las de Argentina y las de localidades de otras provincias.
E4
RE4
Se espera recuperar en primer lugar las noticias en el rango de 48 hs. para Chubut,
luego las de Puerto Madryn y Trelew, las del barrio centro de Puerto Madryn, y
E5
RE5
El orden esperado es el mismo del escenario E1 con las siguientes alteraciones:

Dentro del rango de 48 horas se espera recuperar en primer lugar la noticia ms
reciente de Puerto Madryn, la noticia ms reciente de barrio Sarmiento de Trelew
debe aparecer a continuacin de las de Trelew, la de Comodoro Rivadavia junto con
Luis Ignacio Aita
Pgina 93
las de otras localidades de la provincia y la de Formosa al final del rango.
La noticia insertada para Puerto Madryn de ms de 48 horas debe aparecer al
principio del rango correspondiente.
E6
RE6

Dentro del rango de 48 horas se espera recuperar la noticia ms reciente de Puerto
Madryn luego de las de barrio Centro, la noticia ms reciente de barrio Sarmiento
de Trelew debe aparecer a continuacin de las de Trelew, la de Comodoro
Rivadavia junto con las de otras localidades de la provincia y la de Formosa al final
del rango.
La noticia insertada para Puerto Madryn de ms de 48 horas debe aparecer luego de
las del barrio Centro en el rango correspondiente.
E7
RE7

Dentro del rango de 48 horas se espera recuperar la noticia ms reciente del barrio
Sarmiento de Trelew a continuacin de las de Trelew, la noticia ms reciente de
Puerto Madryn y de Comodoro Rivadavia deben aparecer a continuacin de las de
Chubut y la de Formosa al final del rango.
La noticia insertada para Puerto Madryn de ms de 48 horas debe aparecer a
continuacin de las noticias de Chubut dentro del rango correspondiente.
E8
RE8

Dentro del rango de 48 horas se espera recuperar las noticias ms recientes de
Puerto Madryn, barrio Sarmiento de Trelew y Comodoro Rivadavia a continuacin
de las noticias de Chubut y la de Formosa al final del rango.
La noticia insertada para Puerto Madryn de ms de 48 horas debe aparecer a
continuacin de las noticias de Chubut dentro del rango correspondiente.
Pueden analizarse en detalle el orden esperado de las noticias en las tablas de resultados
esperados en el Anexo 7: Resultados Esperados para los distintos escenarios de prueba.
6.3.2.2 Sistematizacin de las pruebas
Las pruebas se realizaron ejecutando las consultas en forma directa sobre la herramienta Solr a
travs de request HTTP sobre su API pblica y solicitando los resultados en formato XML.
La seccin
<results> de la respuesta a la consulta Solr fue configurada para retornar los
resultados en el siguiente formato:

<result name="response" numFound="35" start="0">
<doc>
<date name="created">2014-09-21T13:00:00Z</date>
<str name="id">p200001</str>
<date name="indexTime">2014-09-23T18:23:51.795Z</date>
<date name="modified">2014-09-21T13:00:00Z</date>
<str name="verbatim">Noticia barrio de hoy</str>
<str name="zoneExtendedString">Centro, Puerto Madryn, Chubut,
Argentina</str>
</doc>
<doc>...</doc>
...
<doc>...</doc>
</result>
Luis Ignacio Aita
Pgina 94
Se estructuraron los resultados esperados respetando este formato y en cada ciclo de prueba y
refinamiento se automatiz la comparacin de resultados utilizando herramientas de testing
mediante asertos.
6.3.3 Resultados
Luego de reiteradas modificaciones y adaptaciones sobre las funciones de boosting para lograr
obtener los resultados esperados en cada escenario se logr una funcin estable, probada mediante
la regeneracin de los datos y la repeticin de las consultas. Una vez estabilizada la funcin
objetivo se repitieron las consultas veinte veces, logrando obtener siempre los mismos resultados
para cada escenario.
La efectividad lograda en funcin de los resultados obtenidos versus resultados esperados es
cercana un 90%, aunque la misma aumenta hasta un valor cercano al 100% si se consideran solo la
primer franja temporal, es decir las noticias dentro de las 48 horas.
Para la obtencin de la funcin de boosting se cre un servicio javascript que, en funcin del
contexto, construye la URL Solr.
En particular la porcin de la URL relacionada con las pruebas y las funciones de boosting se
construy utilizando la funcin getSolrBoosting(zCtx) que se explica a continuacin.
Todas las dimensiones definidas fueron divididas en escala en funcin de la cantidad de niveles
jerrquicos de la zona geogrfica. Es decir, Nivel 1: Argentina, Nivel 2: Provincias, Nivel 3:
localidades, Nivel 4: barrios, y as sucesivamente. El campo selZone del contexto que contiene la
zona en formato extendido permite calcular este nivel.
Para el peso de las zonas en las consultas se utiliz boosting querys (bq) construidas alternando
los campos zonePartialExtendedString y zoneExtendedString con el siguiente criterio de boosting:
zonePartialExtendedString = (zona de nivel 1)^103
zoneExtendedString = (zona de nivel 1)^104
zonePartialExtendedString = (zona de nivel 2)^105
zoneExtendedString = (zona de nivel 2)^106
..
zonePartialExtendedString = (zona de nivel n)^10n+3.
Luis Ignacio Aita
Pgina 95
zoneExtendedString=(zona de nivel n)^10n+4.
Esta distribucin de peso permite dar mayor importancia a las zonas ms cercanas a las del nivel
buscado en una relacin 10n.
Las franjas temporales cobran una relevancia mayor que la zona en relacin directa al nivel. Por
ejemplo, en una bsqueda de zona nivel 4 el peso de la franja temporal debe ser mucho mayor que
para un bsqueda de una zona nivel 2.
Para el peso de las franjas temporales tambin se utiliz boosting querys (bq) construidas en base
a campo modified de la noticia y la cantidad de niveles utilizando el siguiente criterio:
modified:[NOW-48HOURS TO *]^10#nivel*4.
modified:[NOW-7DAYS TO NOW-48HOURS]^10#nivel*(4-5).
modified:[NOW-30DAYS TO NOW-7DAYS]^10#nivel*(4-10).
El factor de corrimiento utilizado en el multiplicador del exponente, definido en una escala 1, 5,

10, es el que permiti aumentar o disminuir el peso de la franja temporal en funcin de los niveles
de la zona.
Otro requisito utilizado en las consulta fue recuperar en orden de fecha las noticias dentro de una
misma franja temporal. Para lograrlo se utiliz una boosting function aplicada sobre el campo
modified y utilizando el nivel para el factor de boosting de la siguiente manera:
bf=ord(modified)^10#nivel*2.
La consultas obtenidas se construyen en funcin de los criterios. A continuacin se detalla la
query resultante para cada uno de ellos
6.3.3.1 Criterio 1, Escenarios 1 y 5
Puerto Madryn, Chubut, Argentina

/solr/select?indent=on&version=2.2&start=0&fl=*
%2Cscore&rows=40&qt=zonalesContent&sort=&wt=xml&explainOther=&hl.fl=&q=docType:p
ost&bf=ord(modified)^1000000&bq=+zoneExtendedString:"Puerto+Madryn,+Chubut,
+Argentina"^100000000+zonePartialExtendedString:"Puerto+Madryn,+Chubut,
+Argentina"^10000000+zoneExtendedString:"Chubut,
+Argentina"^1000000+zonePartialExtendedString:"Chubut,
+Argentina"^100000+zoneExtendedString:"Argentina"^10000+zonePartialExtendedStrin
Luis Ignacio Aita
Pgina 96
g:"Argentina"^1000+modified:[NOW-48HOURS+TO+*]^1000000000000+modified:[NOW7DAYS+TO+NOW-48HOURS]^10000000+modified:[NOW-30DAYS+TO+NOW-7DAYS]^100
Centro, Puerto Madryn, Chubut, Argentina

ost&bf=ord(modified)^100000000&bq=+zoneExtendedString:"Centro,+Puerto+Madryn,
+Chubut,+Argentina"^10000000000+zonePartialExtendedString:"Centro,
+Puerto+Madryn,+Chubut,+Argentina"^1000000000+zoneExtendedString:"Puerto+Madryn,
+Chubut,+Argentina"^100000000+zonePartialExtendedString:"Puerto+Madryn,+Chubut,
Trelew, Chubut, Argentina

ost&bf=ord(modified)^1000000&bq=+zoneExtendedString:"Trelew,+Chubut,
+Argentina"^100000000+zonePartialExtendedString:"Trelew,+Chubut,
Chubut, Argentina
ost&bf=ord(modified)^10000&bq=+zoneExtendedString:"Chubut,
g:"Argentina"^1000+modified:[NOW-48HOURS+TO+*]^100000000+modified:[NOW7DAYS+TO+NOW-48HOURS]^1000+modified:[NOW-30DAYS+TO+NOW-7DAYS]^0.01
Luis Ignacio Aita
Pgina 97
No se hicieron pruebas de estrs sobre este conjunto de datos pues las pruebas de escalabilidad
se realizaron en el trabajo ya mencionado Distributed Search on Large NoSQL Databases[Tinetti,
Barry, Aita, Pez, PDPTA2011].
6.4
Infraestructura
Para la ejecucin de las pruebas se replic un ambiente como el utilizado durante el desarrollo
del proyecto Zonales, limitando la instalacin de componentes de software a los necesarios para
implementar la herramienta Apache Solr y el ndice creado en la segunda etapa.
Se cre una mquina virtual destinada exclusivamente a la ejecucin de las pruebas con las
siguientes caractersticas:
Hardware
Equipo anfitrin
Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
RAM Memory 16Gb. DDR3
2 x HD 1Tb. 7200RPM SATA3
Proxmox Virtual Environment v. 3.1-3
Virtual Host
Common KVM processor 1 Core
RAM Memory 512MB/2.00GB
Virtual Disk 60Gb qcow format (qemu)
Software
Sistema operativo Linux kernel 2.6.32-358
Distribucin CentOS release 6.4 (Final) 64 bits
Servidor de aplicaciones Apache Tomcat 6.0.41
Apache Solr 1.4.1
Luis Ignacio Aita
Pgina 98
Luis Ignacio Aita
Pgina 99
Conclusiones
Es importante destacar el aporte positivo que significo para mi la participacin en un proyecto de
extensin, en donde junto con mis compaeros trabajamos en un entorno real de desarrollo, en el
cual un cliente exiga funcionalidades y resultados, un lder de proyecto o scrum master nos gui y
apuntal nuestras falencias y formar parte del equipo de trabajo, donde los roles van cambiando,
exigi tolerancia y adaptacin a los cambios.
En particular se utilizaron metodologas de desarrollo giles. Al principio del proyecto se utiliz
eXtreme Programming (XP) y avanzada la primer etapa se migr hacia SCRUM [Kniberg 2007]
[Rising, Janoff 2000]. Se logr estabilizar esta metodologa de desarrollo e incluso mantener un
mismo nivel de regularidad y productividad entre etapas del proyecto, a pesar de que dos de los
cuatro integrantes del equipo cambiaron.
Una constante durante el proyecto fue tambin el uso de tecnologas de punta como Apache Solr,
Node.js, Apache Nutch, Web-Sockets, ZK Framework, MongoDB entre otras. Muchas de ellas son
de uso muy difundido hoy en da, lo que demuestra que las elecciones tecnolgicas que se tomaron
fueron acertadas.
Junto con Juan Manuel Cortez, uno de los miembros del equipo Zonales, decidimos formar Sur
Software, spin-off universitario, formando una empresa de base tecnolgica pensada para brindar
soluciones informticas en el rea del software, manteniendo y fortaleciendo la metodologa de
desarrollo adoptada en Zonales y profundizando nuestros conocimientos en las herramientas
mencionadas.
En el mbito acadmico el proyecto Zonales impuls la formacin del grupo de investigacin en
tecnologas NoSQL dentro de la universidad, la redaccin del proyecto Tcnicas de recuperacin
de informacin en grandes volmenes de datos heterogneos con bases de datos NoSQL y la
presentacin de los papers citados en varias oportunidades en el presente trabajo [Tinetti, Barry,
Aita, Pez, PDPTA2011; Barry, Pez, Cortez 2010; Barry, Aita, Cortez 2014].
Haciendo foco en la temtica de este trabajo de tesina es grato destacar el desafo cumplido de
haber recibido por parte del cliente un exigencia concreta para el ordenamiento de las noticias y
haber podido mostrar que era posible hacerlo con las herramientas seleccionadas dentro de la
arquitectura de solucin que pensamos.
Luis Ignacio Aita
Pgina 100
Las funciones y consultas de boosting utilizadas en el presente trabajo son solo una pequea
parte de un gran conjunto de herramientas que ofrece Apache Solr para la recuperacin ordenada de
informacin. El campo de Big Data es tan amplio que incluso muchos expertos consideran a esta
poca como la era del Big Data y en este contexto dominar una herramienta como Solr que
permita indexar, clasificar y recuperar en forma ordenada gran cantidad de informacin valiosa es
un punto fuerte en mi carrera profesional.
Concretamente el proyecto Zonales signific, en lo personal, el comienzo de mi carrera como
desarrollador de software y profesional de sistemas. En forma previa solo contaba con lo aprendido
durante el curso de mis estudios y las prcticas realizadas en el marco de cada materia. Fue el
puntapi inicial que me permiti tomar la decisin de dedicarme de lleno a mi profesin y aceptar el
desafo permanente de actualizacin formativa que ello implica.
Luis Ignacio Aita
Pgina 101
Lineas futuras
Las nuevas versiones de Apache Solr ofrecen la posibilidad de indexar datos geogrficos
asociados a la informacin e incorporar nuevas herramientas de bsquedas para recuperar dicha

informacin por conceptos tales como distancias, pertenencia a una polgono geogrfico, etc., que
permitiran mejorar la solucin Zonales a tal punto que un usuario podra recuperar las noticias
ordenadas por cercana geogrfica a partir del punto donde se encuentre con niveles de precisin de
metros.
En el trabajo Distributed Search on Large NoSQL Databases [Tinetti, Barry, Aita, Pez,
PDPTA2011] se indexaron artculos de wikipedia utilizando como criterio de particionamiento
horizontal de los datos la paridad del id numrico de los documentos. Repetir la experiencia
realizada en dicho trabajo pero utilizando la informacin de zonales y tomando como mtodo de
particin de los datos el campo de zona geogrfica en su formato semntico es otro desafo de
inters y permitira incluso probar la escalabilidad utilizando las funciones de boosting del presente
trabajo.
Otro desafo es mejorar el modelo matemtico para refinar los resultados del presente trabajo de
tesina. Consideramos que las relaciones de pesos encontradas tanto para la zona como para la
temporalidad pueden mejorarse a travs de este tipo de modelos.
Luis Ignacio Aita
Pgina 102
Luis Ignacio Aita
Pgina 103
Referencias
Apache Solr Reference Guide, Covering Apache Solr 4.8. 2014

Barry Damin, Juan Manuel Cortez, Francisco Pez: Construccin de un Ecualizador de Inters
Mediante el uso de Lucene-Solr, IEEE Intercon 2010.
Barry Demian, Aita Luis Ignacio, Cortez Juan Manuel, Zcrawler: Extraccin, clasificacin y
publicacin de informacin pblica desde su perspectiva geogrfica, JAIIO 2014
Bozdag et al. A Comparison of Push and Pull Techniques for AJAX, 2007
Coulouris George, Dollimore Jean y Kindberg Tim, Sistemas Distribuidos - Conceptos y Diseo,
Tercera Edicin Addison Wesley Pearson Educacin, 2001
Dean Jeffrey and Ghemawat Sanjay: MapReduce: Simplied Data Processing on Large Clusters.
Google Inc. 2004
DeCandia et al., Dynamo: amazons highly available key-value store 2007
Elmagarmid Ahmed K. & Rusinkiewicz Marek & Sheth Amit. Management of Heterogeneous and
Autonomous Database Systems. Morgan Kaufmann Publishers, 1999
Hatcher Erik, Otis Gospodneti. Lucene in Action, 2nd. ed, Manning Publications Co. 2004.
Henderson Cal. Building Scalable Web Sites, O'Reilly Media, 2006
Kniberg Henrik, Scrum and XP from the Trenches, InfoQ 2007
Lakshman, Avinash & Malik, Prashant. Cassandra - A Decentralized Structure Storage System.
ACM SIGOPS Operating Systems Review, Volume 44 Issue 2, 2010
Mattmann Chris A. , Zitting Juka L. Tika in Action. Manning 2011
zsu M.T. & Valduriez P. . Principles of Distributed Database Systems, 2nd edition. PrenticeHall,1999. Sitio web. http://softbase.uwaterloo.ca/~tozsu/ddbook/notes.html
Rising Linda and Janoff Norman, The Scrum Software Development Process for Small Teams,
IEEE 2000
Schroeck Michael et. al., Analytics: The real-world use of big data How innovative enterprises
extract value from uncertain data. IBM 2012.
http://www-03.ibm.com/systems/hu/resources/the_real_word_use_of_big_data.pdf
Stonebraker Michael: The Case for Shared Nothing. University of California, Berkeley, Ca. 1986
Tanenbaum Andrew, Van Steen Maarten, Sistemas Distribuidos - Principios y Paradigmas 2da
Edicin, 2008
Taniar David & Leung Clement H. C. & Rahayu Wenny & Goel Sushant. High Performance
Parallel Database Processing and Grid Databases. John Wiley & Sons, 2008.
Tinetti Fernando, Damin Barry, Ignacio Aita, Franciasco Pez: Distributed Search on Large
NoSQL Databases, PDPTA2011.
Vauzza. Todo lo que necesitas saber sobre Big Data. Blog eureka-startups.com 2013.
http://www.eureka-startups.com/blog/2013/05/28/todo-lo-que-necesitas-saber-sobre-big-data/
Valduriez P. Data Management and Parallel Proessing. Chapman and Hall, 1992.
Luis Ignacio Aita
Pgina 104
Venner Jason. Pro Hadoop. Apress, 2009.

White Tom. Hadoop: The Definitive Guide, O'Reilly, 2011.
Luis Ignacio Aita
10
Pgina 105
Anexos
10.1 Anexo 1: Definicin de campos del esquema Solr en la etapa 1

<fields>
<field
<field
<field
<field
<field
<field
<field
<field
<field
<field
<field
<field
<field
<field
<field
<field
<field
<field
<field
<field
<field
<field
<field
<field
<field
<field
<field
name="id" type="integer" indexed="true" stored="true" />

name="title" type="text" indexed="true" stored="true" termVectors="true" />
name="alias" type="string" indexed="true" stored="true" />
name="title_alias" type="string" indexed="true" stored="true" />
name="introtext" type="text" indexed="true" stored="true" termVectors="true" />
name="fulltext" type="text" indexed="true" stored="true" termVectors="true" />
name="sectionid" type="integer" indexed="true" stored="true" />
name="state" type="integer" indexed="true" stored="true" />
name="catid" type="integer" indexed="true" stored="true" />
name="catalias" type="text" indexed="false" stored="true" />
name="created" type="date" indexed="true" stored="true" />
name="created_by" type="integer" indexed="true" stored="true" />
name="created_by_alias" type="string" indexed="true" stored="true" />
name="modified" type="date" indexed="true" stored="true" />
name="modified_by" type="integer" indexed="true" stored="true" />
name="checked_out" type="integer" indexed="true" stored="true" />
name="checked_out_time" type="date" indexed="true" stored="true" />
name="publish_up" type="date" indexed="true" stored="true" />
name="publish_down" type="date" indexed="true" stored="true" />
name="attribs" type="string" indexed="true" stored="true" />
name="hits" type="integer" indexed="true" stored="true" />
name="images" type="string" indexed="true" stored="true" />
name="urls" type="string" indexed="true" stored="true" />
name="ordering" type="integer" indexed="true" stored="true" />
name="metakey" type="text" indexed="true" stored="true" />
name="metadesc" type="text" indexed="true" stored="true" />
name="access" type="integer" indexed="true" stored="true" />
<field name="slug" type="string" indexed="false" stored="true" />

<field name="catslug" type="string" indexed="false" stored="true" />
<field name="readmore" type="integer" indexed="true" stored="true" />
<field name="author" type="string" indexed="true" stored="true" />
<field name="usertype" type="string" indexed="true" stored="true" />
<field name="author_email" type="string" indexed="true" stored="true" />
<field name="groups" type="string" indexed="true" stored="true" />
<field
<field
<field
<field
name="category" type="string" indexed="true" stored="true" />

name="section" type="string" indexed="true" stored="true" />
name="category_published" type="boolean" indexed="true" stored="true" />
name="section_published" type="boolean" indexed="true" stored="true" />
<field name="section_access" type="integer" indexed="true" stored="true"/>

<field name="category_access" type="integer" indexed="true" stored="true"/>

<field name="hasPublishUpDate" type="boolean" indexed="true" stored="true"/>
<field name="hasPublishDownDate" type="boolean" indexed="true" stored="true"/>
<field name="tags_names" type="text_ws" indexed="true" stored="true" multiValued="true"/>
<field name="tags_values" type="text_ws" indexed="true" stored="true" multiValued="true"/>
<field name="category_s" type="string" indexed="true" stored="false"/>
<field name="metakey_ws" type="text" indexed="true" stored="false"/>
<field name="title_f" type="text" indexed="true" stored="false"/>
<field name="introtext_f" type="text" indexed="true" stored="false"/>
<field name="fulltext_f" type="text" indexed="true" stored="false"/>

<field name="published" type="boolean" indexed="true" stored="true"/>
</fields>
Luis Ignacio Aita
Pgina 106
<uniqueKey>id</uniqueKey>
<defaultSearchField>title</defaultSearchField>
<solrQueryParser defaultOperator="OR" />
<copyField source="introtext" dest="introtext_f" />
<copyField source="fulltext" dest="fulltext_f" />
<copyField source="title" dest="title_f"/>

<copyField source="category" dest="category_s"/>
<copyField source="metakey" dest="metakey_ws"/>

<copyField source="state" dest="published" />

</schema>
10.2 Anexo 2: Extensin analizador de consultas DisMax en solrconfig.xml en

la etapa 1
<requestHandler name="zonalesContent" class="solr.SearchHandler" >
<lst name="defaults">
<str name="defType">dismax</str>
<str name="echoParams">explicit</str>
<float name="tie">0.01</float>

<str name="qf">
introtext^0.7 fulltext^0.5 title^1.0 tagsvalues^2.0
</str>
<int name="qs">1</int>

<str name="pf">
introtext^1.0 fulltext^1.0 title^1.5
</str>
<int name="ps">0</int>
<str name="fl">
introtext,fulltext,title,id,score,publish_up
</str>

<str name="mm">0%</str>

<str name="q.alt">*:*</str>
<str
<!-<str
<str
<str
name="hl">true</str>
comma separated list of fields that will be highlighted -->
name="hl.fl">introtext fulltext title</str>
name="hl.usePhraseHighlighter">true</str>
name="hl.highlightMultiTerm">true</str>
<!-<str
<!-<str
for this field, we want no fragmenting, just highlighting -->

name="f.title.hl.fragsize">0</str>
instructs Solr to return the field itself if no query terms are found -->
name="f.title.hl.alternateField">title</str>
<str
<str
<str
<str
<str
<str
name="f.intro_content.hl.fragsize">350</str>
name="f.full_content.hl.fragsize">350</str>
name="f.intro_content.hl.alternateField">introtext</str>
name="f.full_content.hl.alternateField">fulltext</str>
name="f.intro_content.hl.maxAlternateFieldLength">350</str>
name="f.full_content.hl.maxAlternateFieldLength">350</str>
Luis Ignacio Aita
Pgina 107
<str name="f.text.hl.fragmenter">regex</str> 

</lst>
</requestHandler>
10.3 Anexo 3: Formatos estandarizados de noticias (posts)

10.3.1 Formato XZone:
<posts xsi="http://www.w3.org/2001/XMLSchema-instance" noNamespaceSchemaLocation="http://200.69.225.
53:30082/XZone.xsd">
<post>
<source>Fuente</source>
<id>Post Id</id>
<fromUser>
<name>Nombre autor</name>
<category>Categora autor</category>
<id>Id Autor</id>
<url>Link al perfil del autor</url>
</fromUser>
<toUsers>
<toUser>
<name>Nombre destinatario</name>
<category>Categora destinatario</category>
<id>Id detinatario</id>
<url>Link al perfil del destinatario</url>
</toUser>
...
<toUser>
<name>Nombre destinatario</name>
<category>Categora destinatario</category>
<id>Id detinatario</id>
<url>Link al perfil del destinatario</url>
</toUser>
</toUsers>
<title>Ttulo</title>
<text>Contenido</text>
<links>
<link>
<type>link/Picture/Video/Photo/etc.</type>
<url>Link</url>
</link>
...
<link>
<type>link/Picture/Video/Photo/etc.</type>
<url>Link</url>
</link>
</links>
<actions>
<action>
<type>comment/like/retweet/share/favorite/etc.</type>
<cant>Cantidad</cant>
</action>
...
<action>
<type>comment/like/retweet/share/favorite/etc.</type>
<cant>Cantidad</cant>
</action>
</actions>
<created>Fecha creacin</created>
<modified>Fecha ltima modificacin</modified>
<relevance>Relevancia</relevance>
<zone>Localidad</zone>
<tags>
<tag>Tag</tag>
...
<tag>Tag</tag>
</tags>
<verbatim>
Post en formato JZONE
</verbatim>
Luis Ignacio Aita
Pgina 108
</post>
<post>Post</post>
<post>Post</post>
...
<post>Post</post>
</posts>
10.3.2 Formato JZone:

[
"post": {
"source": Fuente,
"id": Post Id,
"docType": Tipo de documento (post, clasificado, etc.),
"postLatitude": Latitud del post,
"postLongitude": Longitud del post,
"from": {
"name": Nombre autor,
"category": Categora autor,
"id": Id Autor,
"url": Link al perfil del autor,
"place": {
"id": Id,
"name": Nombre del place,
"type": Tipo de place
}
},
"to": [
{
"name": Nombre destinatario,
"category": Categora destinatario,
"id": Id detinatario,
"url": Link al perfil del destinatario
}
],
"title": Ttulo,
"text": Contenido,
"links": [
"link": {
"type": link/Picture/Video/Photo/etc.,
"url": Link
}
]
"actions": [
"action": {
"type": comment/like/retweet/share/favorite/etc.,
"cant": Cantidad
}
],
"created": Fecha creacin,
"modified": Fecha ltima modificacin,
"relevance": Relevancia,
"relevanceDelta": Delta de relevancia definido por usuarios,
"zone" : {
"id": Id de la zona,
"name": Nombre de la zona,
"type": Tipo de la zona
},
"tags" : [
"tag" : Tag
]
}
10.4 Anexo 4: Definicin de campos del esquema Solr en la etapa 2

<fields>
<field name="indexTime" type="date" stored="true" indexed="true" default="NOW-3HOURS"/>
<field name="docType" type="string" stored="false" indexed="true" default="post"/>
<field name="source" type="text_general" stored="false" indexed="true"/>
Luis Ignacio Aita
Pgina 109
<field name="postLatitude" type="double" stored="false" indexed="true"/>

<field name="postLongitude" type="double" stored="false" indexed="true"/>
<field name="id" type="string" stored="true" indexed="true" required="true"/>
<field name="fromUserName" type="string" stored="false" indexed="true" />
<field name="fromUserCategory" type="string" stored="false" indexed="true" />
<field name="fromUserId" type="string" stored="false" indexed="true" />
<field name="fromUserUrl" type="string" stored="false" indexed="true" />
<field name="fromUserPlaceId" type="string" stored="false" indexed="true"/>
<field name="fromUserPlaceName" type="string" stored="false" indexed="true"/>
<field name="fromUserPlaceType" type="string" stored="false" indexed="true"/>
<field name="title" type="text_general" stored="false" indexed="true"/>
<field name="text" type="text_general" stored="false" indexed="true"/>
<field name="created" type="date" stored="true" indexed="true"/>
<field name="modified" type="date" stored="true" indexed="true"/>
<field name="relevance" type="int" stored="false" indexed="true"/>
<field name="relevanceDelta" type="int" stored="false" indexed="true"/>
<field name="tags" type="string" stored="false" indexed="true" multiValued="true"/>
<field name="zone" type="string" stored="false" indexed="true" />
<field name="zoneId" type="string" stored="false" indexed="true" />
<field name="zoneName" type="string" stored="false" indexed="true" />
<field name="zoneType" type="string" stored="false" indexed="true" />
<field name="zoneExtendedString" type="string" stored="true" indexed="true"/>
<field name="extendedString" type="string" stored="false" indexed="true"/>
<field name="state" type="string" stored="false" indexed="true" default="published"/>
<field name="verbatim" type="string" stored="true" indexed="false"/>
<field name="zonePartialExtendedString" type="type_partial_extendedString" stored="false"
indexed="true"/>

<dynamicField name="*_i" type="int"
indexed="true" stored="true"/>
<dynamicField name="*_s" type="string" indexed="true" stored="true"/>
<dynamicField name="*_l" type="long"
<dynamicField name="*_t" type="text_general"
<dynamicField name="*_txt" type="text_general"
indexed="true"
stored="true"
multiValued="true"/>
<dynamicField name="*_b" type="boolean" indexed="true" stored="true"/>
<dynamicField name="*_f" type="float" indexed="true" stored="true"/>
<dynamicField name="*_d" type="double" indexed="true" stored="true"/>

<dynamicField name="*_coordinate" type="tdouble" indexed="true" stored="false"/>
<dynamicField name="*_dt" type="date"
<dynamicField name="*_p" type="location" indexed="true" stored="true"/>

<dynamicField name="*_ti" type="tint"
<dynamicField name="*_tl" type="tlong"
<dynamicField name="*_tf" type="tfloat" indexed="true" stored="true"/>
<dynamicField name="*_td" type="tdouble" indexed="true" stored="true"/>
<dynamicField name="*_tdt" type="tdate" indexed="true" stored="true"/>
<dynamicField name="*_pi"
type="pint"
indexed="true"
stored="true"/>
<dynamicField name="ignored_*" type="ignored" multiValued="true"/>

<dynamicField name="attr_*" type="text_general" indexed="true"
multiValued="true"/>
stored="true"
<dynamicField name="random_*" type="random" />



Luis Ignacio Aita
Pgina 110
</fields>
<copyField source="zoneExtendedString" dest="zonePartialExtendedString"/>

<uniqueKey>id</uniqueKey>
10.5 Anexo 5: Set de datos de pruebas D1

verbatim
Noticia barrio de hoy - Centro, Puerto Madryn, Chubut, Argentina - facebook - R0
Noticia barrio de ayer - Centro, Puerto Madryn, Chubut, Argentina - twitter - R10
Noticia barrio 3 das - Centro, Puerto Madryn, Chubut, Argentina - feed1.com - R20
Noticia barrio 5 das - Centro, Puerto Madryn, Chubut, Argentina - facebook - R30
Noticia barrio 20 das - Centro, Puerto Madryn, Chubut, Argentina - twitter - R40
Noticia localidad de hoy - Puerto Madryn, Chubut, Argentina - feed2.com - R30
Noticia localidad de ayer - Puerto Madryn, Chubut, Argentina - facebook - R10
Noticia localidad 3 das - Puerto Madryn, Chubut, Argentina - twitter - R0
Noticia localidad 5 das - Puerto Madryn, Chubut, Argentina - feed3.com - R40
Noticia localidad 20 das - Puerto Madryn, Chubut, Argentina - facebook - R20
Noticia provincia de hoy - Chubut, Argentina - twitter - R20
Noticia provincia de ayer - Chubut, Argentina - feed4.com - R40
Noticia provincia 3 das - Chubut, Argentina - facebook - R10
Noticia provincia 5 das - Chubut, Argentina - twitter - R0
Noticia provincia 20 das - Chubut, Argentina - feed5.com - R30
Noticia otra localidad de la provincia de hoy - Trelew, Chubut, Argentina - facebook - R30
Noticia otra localidad de la provincia de ayer - Trelew, Chubut, Argentina - twitter - R0
Noticia otra localidad de la provincia 3 das - Trelew, Chubut, Argentina - feed6.com - R40
Noticia otra localidad de la provincia 5 das - Trelew, Chubut, Argentina - facebook - R20
Noticia otra localidad de la provincia 20 das - Trelew, Chubut, Argentina - twitter - R10
Noticia localidad de otra provincia de hoy - Rosario, Santa Fe, Argentina - feed7.com - R10
Noticia localidad de otra provincia de ayer - Rosario, Santa Fe, Argentina - facebook - R30
Noticia localidad de otra provincia 3 das - Rosario, Santa Fe, Argentina - twitter - R40
Noticia localidad de otra provincia 5 das - Rosario, Santa Fe, Argentina - feed1.com - R0
Noticia localidad de otra provincia 20 das - Rosario, Santa Fe, Argentina - facebook - R20
Noticia otra provincia de hoy - Mendoza, Argentina - twitter - R0
Noticia otra provincia de ayer - Mendoza, Argentina - feed2.com - R20
Luis Ignacio Aita
Pgina 111
verbatim
Noticia otra provincia 3 das - Mendoza, Argentina - facebook - R30
Noticia otra provincia 5 das - Mendoza, Argentina - twitter - R40
Noticia otra provincia 20 das - Mendoza, Argentina - feed6.com - R10
Noticia pais de hoy - Argentina - facebook - R30
Noticia pais de ayer - Argentina - twitter - R10
Noticia pais 3 das - Argentina - feed2.com - R20
Noticia pais 5 das - Argentina - facebook - R0
Noticia pais 20 das - Argentina - twitter - R40
10.6 Anexo 6: Set de datos de pruebas D2

verbatim
Noticia localidad ms reciente - Puerto Madryn, Chubut, Argentina - facebook - R0
Noticia barrio de otra localidad de la provincia ms reciente - Sarmiento, Trelew, Chubut,
Argentina - feed1.com - R20
Noticia otra localidad de la provincia ms reciente - Comodoro Rivadavia, Chubut, Argentina facebook - R30
Noticia localidad de otra provincia ms reciente - Formosa, Formosa, Argentina - twitter - R40
Luis Ignacio Aita
Pgina 112
10.7 Anexo 7: Resultados Esperados para los distintos escenarios de prueba

10.7.1 RE1
verbatim
Luis Ignacio Aita
Pgina 113
10.7.2 RE2
verbatim
Luis Ignacio Aita
Pgina 114
10.7.3 RE3
verbatim
Luis Ignacio Aita
Pgina 115
10.7.4 RE4
verbatim
Luis Ignacio Aita
Pgina 116
10.7.5 RE5
verbatim
Noticia otra localidad de la provincia ms reciente - Comodoro Rivadavia, Chubut, Argentina - facebook - R30
Noticia barrio de otra localidad de la provincia ms reciente - Sarmiento, Trelew, Chubut, Argentina - feed1.com - R20
Luis Ignacio Aita
Pgina 117
10.7.6 RE6
verbatim
Luis Ignacio Aita
Pgina 118
10.7.7 RE7
verbatim
Luis Ignacio Aita
Pgina 119
10.7.8 RE8
verbatim

Recuperación de Noticias Ordenadas Temporalmente y Por Zonas Utilizando Funciones Combinadas de Recuperación de Información de Apache Solr

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Recuperación de Noticias Ordenadas Temporalmente y Por Zonas Utilizando Funciones Combinadas de Recuperación de Información de Apache Solr

Uploaded by

Copyright:

Available Formats

Universidad Nacional de la Patagonia San Juan Bosco

Recuperacin de noticias ordenadas temporalmente y

Tesina de Grado para

Luis Ignacio Aita

Lic. Damin Barry

A mi amigo y hermano de la vida Juan Pablo Martini.

5.5.2 Modalidad y sintaxis de las consultas Solr......................................................................61

Luis Ignacio Aita

La popularidad de los sistemas de gestin de contenidos (CMS, Content Management

Crecimiento en la produccin de informacin dentro de las organizaciones ya sea por

Segmentacin de la informacin mediante etiquetas: clasificacin, segmentacin, generacin

Perfil del usuario basado en pertenencia geogrfica, identidad cultural y hbitos.

Motor de bsqueda que jerarquice la informacin analizando la clasificacin de la misma y

Luis Ignacio Aita

En este sentido el concepto de pertenencia geogrfica es sumamente importante en el desarrollo

Motivacin del Proyecto

un gestor de contenidos web (www.zonales.com) que brinda un

Luis Ignacio Aita

Son objetivos de la tesina:

Estudiar Gestores de Bases de Datos NOSQL actuales y sus caractersticas principales.

Mejorar la recuperacin y el ordenamiento de la informacin clasificada del proyecto

Luis Ignacio Aita

Que el resultado de la tesina sea de utilidad para el proyecto de investigacin Tcnicas de

Finalmente, es un objetivo inherente y principal de un proyecto de tesina el hacer de

La ejecucin del presente proyecto de tesina permitir el diseo y desarrollo de tcnicas

A continuacin se lista un conjunto de metas cuyo cumplimiento permitir el logro de los

Luis Ignacio Aita

4. Estudiar y comparar diversas combinaciones de funciones de recuperacin sobre la base de

3.6.1 Sobre la metodologa de investigacin

Luis Ignacio Aita

sistemtica se denominan estudios primarios, una revisin sistemtica se considera un estudio

Etapa 1: Planificacin de la revisin

Identificar la necesidad de la revisin

Etapa 2: Desarrollo de la revisin

Identificacin de Investigaciones relevantes.

Etapa 3: Publicacin de los resultados.

Escribir reporte de la revisin.

Tabla 1: Metodologa de Kitchenham

Etapa 1: Planificacin de la revisin

Identificar la necesidad de la revisin

Etapa 2: Desarrollo de la revisin

Bsqueda de los estudios primarios.

Etapa 3: Publicacin de los resultados.

Escribir reporte de la revisin.

Tabla 2: Adaptacin para proyectos de fin de

Luis Ignacio Aita

3.6.2 Sobre la metodologa de desarrollo

Luis Ignacio Aita

Luis Ignacio Aita

Luis Ignacio Aita

De replicacin. El sistema gestiona la cantidad copias de cada recurso, aadiendo o

De rendimiento. Implementar las propiedades listadas anteriormente conlleva una merma

Mantener la consistencia en un sistema distribuido mediante un estado global es un problema de

Luis Ignacio Aita

Luis Ignacio Aita

Alta disponibilidad: se utiliza la distribucin para brindar informacin en forma constante a

Tolerancia a fallos y consistencia: en algunas aplicaciones la integridad de la informacin

Movilidad: la gran cantidad de dispositivos mviles existentes hoy en da hacen que un

Luis Ignacio Aita

Escalabilidad horizontal o crecimiento por incrementos o a demanda. Esta es una

Confiabilidad. Debido a la distribucin de la carga de trabajo y a la replicacin de la

Luis Ignacio Aita

Comunicacin. Muchas veces los sistemas distribuidos facilitan la posibilidad de compartir