recuperación de noticias ordenadas temporalmente y por zonas utilizando funciones combinadas de...

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 SolrIndexacin 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

1 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.

2 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 General1 Agradecimientos................................................................................................................................32 Resumen............................................................................................................................................53 Introduccin.......................................................................................................................................9

3.1 Motivacin del Proyecto..........................................................................................................103.2 Objetivos..................................................................................................................................113.3 Hiptesis..................................................................................................................................123.4 Aporte.......................................................................................................................................123.5 Metas........................................................................................................................................123.6 Metodologa.............................................................................................................................13

3.6.1 Sobre la metodologa de investigacin............................................................................133.6.2 Sobre la metodologa de desarrollo..................................................................................15

4 Marco Terico..................................................................................................................................174.1 Sistemas Distribuidos..............................................................................................................17

4.1.1 Conceptos.........................................................................................................................174.1.2 Propiedades......................................................................................................................184.1.3 Aplicaciones.....................................................................................................................204.1.4 Ventajas............................................................................................................................214.1.5 Desventajas......................................................................................................................224.1.6 Perspectivas......................................................................................................................22

4.2 Bases de Datos Distribuidas....................................................................................................234.2.1 Conceptos.........................................................................................................................234.2.2 Diseo y arquitecturas......................................................................................................244.2.3 Transacciones...................................................................................................................274.2.4 Control de concurrencia...................................................................................................274.2.5 Consultas..........................................................................................................................284.2.6 Clasificacin.....................................................................................................................284.2.7 Ventajas y desventajas......................................................................................................30

4.3 Bases de Datos NoSQL............................................................................................................314.3.1 Introduccin.....................................................................................................................314.3.2 Definicin.........................................................................................................................324.3.3 Tipos de bases de datos NoSQL.......................................................................................344.3.4 Tcnicas utilizadas por las bases de datos NoSQL..........................................................354.3.5 Gestores de bases de datos NoSQL..................................................................................38

4.4 Big Data...................................................................................................................................424.4.1 Introduccin.....................................................................................................................424.4.2 Definicin.........................................................................................................................434.4.3 Ventajas............................................................................................................................444.4.4 Desventajas......................................................................................................................464.4.5 Aplicaciones.....................................................................................................................464.4.6 Caractersticas..................................................................................................................464.4.7 Herramientas....................................................................................................................47

5 Apache Solr.....................................................................................................................................495.1 Introduccin.............................................................................................................................495.2 Componentes principales.........................................................................................................505.3 Lucene......................................................................................................................................51

5.3.1 Comparacin con la tecnologa de base de datos tradicional...........................................525.4 Indexacin................................................................................................................................52

5.4.1 Cmo Solr ve al Mundo...................................................................................................545.4.2 Anlisis de campos...........................................................................................................55

5.5 Bsquedas................................................................................................................................555.5.1 Relevancia........................................................................................................................59

5.5.2 Modalidad y sintaxis de las consultas Solr......................................................................616 Diseo e implementacin de la experimentacin............................................................................64

6.1 Introduccin.............................................................................................................................646.2 Zonales.....................................................................................................................................64

6.2.1 Por qu Zonales?............................................................................................................646.2.2 Objetivos..........................................................................................................................646.2.3 Primera etapa del proyecto...............................................................................................656.2.4 Segunda etapa del proyecto..............................................................................................686.2.5 Construccin de un motor de extraccin de informacin................................................686.2.6 Clasificacin de la informacin.......................................................................................716.2.7 Bsqueda de Informacin y Apache Solr.........................................................................716.2.8 Arquitectura......................................................................................................................726.2.9 Resultados del proyecto...................................................................................................73

6.3 Bitcora del proyecto de Tesina...............................................................................................746.3.1 Diseo..............................................................................................................................746.3.2 Pruebas.............................................................................................................................876.3.3 Resultados........................................................................................................................93

6.4 Infraestructura..........................................................................................................................967 Conclusiones....................................................................................................................................988 Lineas futuras................................................................................................................................1009 Referencias....................................................................................................................................10110 Anexos.........................................................................................................................................103

10.1 Anexo 1: Definicin de campos del esquema Solr en la etapa 1.........................................10310.2 Anexo 2: Extensin analizador de consultas DisMax en solrconfig.xml en la etapa 1.......10410.3 Anexo 3: Formatos estandarizados de noticias (posts)........................................................105

10.3.1 Formato XZone:...........................................................................................................10510.3.2 Formato JZone:............................................................................................................106

10.4 Anexo 4: Definicin de campos del esquema Solr en la etapa 2.........................................10610.5 Anexo 5: Set de datos de pruebas D1..................................................................................10810.6 Anexo 6: Set de datos de pruebas D2..................................................................................10910.7 Anexo 7: Resultados Esperados para los distintos escenarios de prueba.............................110

10.7.1 RE1...............................................................................................................................11010.7.2 RE2...............................................................................................................................11110.7.3 RE3...............................................................................................................................11210.7.4 RE4...............................................................................................................................11310.7.5 RE5...............................................................................................................................11410.7.6 RE6...............................................................................................................................11510.7.7 RE7...............................................................................................................................11610.7.8 RE8...............................................................................................................................117

Luis Ignacio Aita Pgina 9

3 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 deinformacin de Apache Solr


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



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.



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.



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



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 decarrera

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



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



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).



4 Marco Terico

4.1 Sistemas Distribuidos

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.



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 TransparenciaPara 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 ConsistenciaMantener 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.



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 EscalabilidadA 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 FiabilidadPodemos 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.



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



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.



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.



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.



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.



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 FragmentacinMediante 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.



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 AsignacinConsiste 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.



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.



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:



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.



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 PerspectivasLos 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.



4.3 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.



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



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.



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



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 CAPEl 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 shardsSe 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



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 NothingSegn 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.



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 cargaEsta 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 GatherEl 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].



Para este caso es interesante poder aplicar la tcnica del siguiente punto.

4.3.4.5 Map / ReduceEsta 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 DynamoDBDynamoDB 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 CassandraLa 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


http://aws.amazon.com/es/dynamodb


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

recuperación de noticias ordenadas temporalmente y por zonas utilizando funciones combinadas de...

Documents