Creación de un caso de estudio que permita comparar el

desempeño y escalabilidad de repositorios relacionales y no

relacionales en un ambiente Cloud-Computing

Proyecto de Grado presentado al

Departamento de ingeniería de sistemas y computación Por

Víctor Daniel Cadena Vallejo

Asesor Mario José Villamizar Cano

Para optar por el título de

Ingeniero de Sistemas

Ingeniería de Sistemas y Computación Universidad de los Andes

Noviembre de 2013

ABSTRACT

Debido al auge que está surgiendo sobre tecnologías Cloud-

Computing, almacenamiento No-SQL y Frameworks de

desarrollo ágil, es necesario identificar los retos, beneficios y

complejidades que se presentan en este tipo de ambientes. Lo

que busca este proyecto es evaluar por medio de un caso de

estudio en el que se usa almacenamiento de datos no

estructurados para identificar y comparar el desempeño y

escalabilidad en este tipo de aplicaciones. Lo anterior se logró

implementando una aplicación web llamada Inkognit que está

pensada como una red social que cumple con las condiciones

de datos no estructurados requeridos. De la aplicación

mencionada se realizaron dos instancias similares con distintos

tipos de repositorios, uno relacional y otro No-SQL y se

realizaron pruebas de carga sobre cada uno de los sitios con las

mismas condiciones y se compararon los resultados.

Tabla de contenidos

Contenidos 1. Objetivo general .......................................................................................................................... 4

2. Objetivos específicos ................................................................................................................... 4

3. Caso de estudio ........................................................................................................................... 4

Descripción técnica ......................................................................................................................... 4

4. Diseño .......................................................................................................................................... 5

Ruby on Rails ................................................................................................................................... 5

Casos de uso .................................................................................................................................... 6

Diagrama de casos de uso ........................................................................................................... 6

Arquitectura MVC ........................................................................................................................... 7

Modelos de datos ............................................................................................................................ 8

PostgreSQL .................................................................................................................................. 8

MongoDB................................................................................................................................... 10

Modelo de despliegue ................................................................................................................... 11

Heroku ....................................................................................................................................... 11

Diagrama de despliegue ............................................................................................................ 11

5. Pruebas sobre el sitio ................................................................................................................ 13

Definición de las pruebas .............................................................................................................. 13

Resultados ..................................................................................................................................... 14

PosgreSQL .................................................................................................................................. 14

MongoDB................................................................................................................................... 17

Conclusiones.............................................................................................................................. 20

6. Trabajo futuro ........................................................................................................................... 21

Bibliografía ........................................................................................................................................ 22

1. Objetivo general Por medio del desarrollo de un caso de estudio se pretende realizar pruebas de escalabilidad y

desempeño para así poder comparar tecnologías SQL y No-SQL y realizar conclusiones sobre los

resultados.

2. Objetivos específicos Los objetivos puntuales sobre los que se quieren hacer énfasis son los siguientes:

El aprendizaje de nuevas tecnologías que se usen en el mercado actual.

Lograr entender que las empresas necesitan un desarrollo ágil y escalable, por lo cual se

deben usar tecnologías que sean acordes con estos objetivos

Entender Cloud Computing y la implementación sobre esta plataforma

Soportarse sobre sistemas en un contexto de BigData para cumplir con las necesidades de

crecimiento y escalabilidad sobre los datos.

3. Caso de estudio Esta aplicación surgió a partir de una idea en la que se pide Feedback a los amigos. Por medio de

este aplicativo se registra un usuario y cada semana se tiene acceso a una pregunta que el

administrador del sitio formula. Esta pregunta formulada se comparte con los amigos de Facebook

que responden de manera anónima a la pregunta compartida.

Con este caso de estudio, se crea una aplicación tipo red social en donde se generan datos no

estructurados además de poder llegar a tener millones de datos.

Descripción técnica A nivel técnico de esta aplicación se decidió realizar la programación por medio de Ruby on Rails,

un Framework de desarrollo ágil que tiene como atributo de calidad la flexibilidad de la aplicación.

Una vez realizado el desarrollo, se desplegó la aplicación en Heroku (una plataforma como

servicio) que soporta distintos lenguajes de programación. Se agregaron add-ons correspondientes

al servicio de base de datos y servicio de correos.

4. Diseño En el siguiente capítulo se define el diseño de la aplicación y la razón de la decisión del Framework

de desarrollo usado.

Ruby on Rails Este es un Framework de aplicaciones web escrito en lenguaje Ruby que sigue el paradigma de

arquitectura en la cual se combina la simplicidad y la posibilidad de desarrollo de aplicaciones del

mundo real.

Los principios básicos de este Framework son:

DRY (Don’t repeat yourself): Este significa que cada pieza de conocimiento debería tener

una sola representación dentro del sistema de manera no ambigua (Cunningham &

Cunningham). Por ejemplo en ActiveRecord las definiciones de las columnas se hacen de

manera dinámica en el momento de la ejecución y no se especifican los nombres de las

mismas.

Convención sobre configuración: El programador no necesita definir configuraciones que

no sean convencionales, en el caso más común de Ruby, si se crea una clase “Usuario” su

tabla respectiva sigue la convención y se coloca en plural (O'Brien, 2008). En el caso de los

controladores se define su nombre de la siguiente manera “name_controller” de manera

convencional.

Como parte del desarrollo ágil, en Rails se encuentran un conjunto de cuatro preferencias

que favorece e una metodología como esta

o Responder al cambio de un plan determinado

o Individuos e interacciones sobre procesos y herramientas

o Software funcional sobre documentación con ejemplos}

o Colaboración del cliente sobre un contrato de negociación

Rails se basa siempre en las interacciones y los individuos. No herramientas ni

configuraciones complicadas ni procesos elaborados.

Rails no necesita documentación. Es fácil generar documentación en un HTML sobre el

código.

Rails permite la colaboración con el cliente. Debido a que las personas ven lo rápido que se

adapta el Framework, empiezan a confiar y ver lo que se requiere más no lo que se

necesita (Hartl, 2012).

Es necesario especificar que este es un lenguaje dinámico, es decir que en ejecución

resuelve muchas cosas que en otros lenguajes se da a nivel de compilación lo que permite

varias cosas:

1. Diseño de la aplicación muy corto: No hay que preocuparse de llamar jerarquías

con interfaces, declaraciones, etc… Solo se escriben las clases, se prueban y

termina el ciclo.

2. Menos código: Se reduce el volumen de código, no se poseen referencias ni

declaraciones duplicadas.

3. No se compila.

4. Facilidad de pruebas: La pequeña parte que se quería cambiar, se cambia y se

prueba.

Casos de uso

En el siguiente literal se especifican los casos de uso definidos para los actores que interactúan con

el sistema:

Diagrama de casos de uso

Diagrama 1 Diagrama de casos de uso

Arquitectura MVC

Esta arquitectura está definida por defecto para el Framework de desarrollo definido (en este caso

Ruby on Rails) en el que se separan los datos y la lógica de negocio de la interfaz y de la capa

encargada de la gestión de eventos del aplicativo. En este tipo de arquitectura se propone la

construcción de tres componentes:

Modelo: Representa la información sobre la cual se opera, gestionando el acceso a la

misma.

Controlador: Responde a eventos y realiza e invoca peticiones al modelo. Además envía

comandos a la vista presentando los cambios del modelo.

Vista: Presenta los cambios de la información y lógica de negocio en un formato para

interactuar con el usuario

Para un mejor entendimiento de este patrón, se presenta la lógica y las acciones desde la

petición del usuario hasta la respuesta (Hartl, 2012).

Diagrama 2 Diagrama MVC

En este caso el browser manda una petición que se recibe por un servidor web y se pasa a un

controlador de Rails, que se encarga de hacer el resto. En algunos casos, el controlador

renderiza una vista que es un template que se convierte en HTML y se envía al browser. En los

sitios dinámicos, el controlador interactúa con un modelo que es un objeto que representa un

elemento del sitio y se encarga de comunicarse con la base de datos. La vista usa los datos de

la interacción con este modelo y retorna la página web al browser como HTML (Hartl, 2012).

Modelos de datos En esta sección se describen los modelos de la base de datos en dos dominios diferentes. En el

primer dominio se plantea un modelo relacional en tercera forma normal (3FN) para PostgreSQL.

En el segundo, se define un modelo desnormalizado para MongoDB que se realizó basado en las

consultas.

PostgreSQL

Para una base de datos relacional como tradicionalmente se realizan las aplicaciones se plantea el

siguiente modelo:

Tablas

La nomenclatura está en inglés ya que el Framework tiene un estándar para la conversión de

modelos a tablas.

Tabla Descripción

Users Es la tabla en donde se almacena la información correspondiente a los usuarios de la aplicación como el nombre, la contraseña (encriptada), fecha de nacimiento, correo, entre otros.

Questions Es la tabla en donde se almacenan las preguntas a compartir por los usuarios de la aplicación. Cada semana se deberá subir una pregunta para que los usuarios la compartan

Shares Es la tabla que indica qué usuario ha compartido qué preguntas y un token que identifica de manera única cada registro.

Authentications Es la tabla que permite almacenar los diferentes tipos de autenticación que usa el usuario en las diferentes redes sociales.

Admin_users Es la tabla que almacena la información de los administradores del sitio

Answers Es la tabla que almacena las respuestas correspondientes a una pregunta compartida por un usuario.

Tabla 1 Descripción de tablas

Consideraciones técnicas

A continuación se describen las consideraciones básicas para el funcionamiento de manera

adecuada del sitio en términos de rendimiento de la base de datos.

1. El diseño de la base de datos está en 3FN para evitar la replicación de los datos y tener un

diseño estándar

2. Se crearon índices sobre las columnas en donde se realizan Joins o se hace búsqueda que

limita los resultados.

3. Se crearon Constraints para mantener la integridad de la base de datos de modo que por

ejemplo un e-mail sea único, solo se pueda compartir una pregunta una vez por usuario y

entre otros.

Diagrama del modelo

Diagrama 3 Modelo de datos

MongoDB

A continuación se describe el modelo en una base de datos orientada a documentos que para el

contexto en el que nos encontramos es ideal debido a que cuenta con un esquema flexible, es

decir no se necesita correr ningún Statement para alterar las tablas como en el caso relacional de

modo que favorece el desarrollo ágil.

Conceptos básicos

A continuación se definen dos conceptos que son fundamentales.

Colecciones: Es la estructura principal en la cual se guardan documentos. Cuentan con un

esquema dictado por la aplicación más no por la base de datos, de modo que si cambia la

aplicación y se introducen documentos con un esquema diferente no se produce ningún

problema.

Documentos: Son los registros que se guardan en una colección y se definen por medio de una

llave y un valor asociado a la llave.

Colecciones

A continuación se presentan las colecciones definidas para el caso:

Colección Descripción

Users Es la colección en la que se almacenan documentos correspondientes a la información de los usuarios

Shares Es la colección en la que se almacenan documentos que indican que un usuario ha compartido una pregunta

Answers Es la colección que almacena las respuestas a una pregunta compartida. Los documentos de esta colección se almacenan de forma embedida en la colección “Shares”

Questions Es la colección que almacena documentos correspondientes a las preguntas que sube el administrador del sitio

Authentications Es la colección que almacena los documentos correspondientes a los diferentes métodos de autenticación por las redes sociales de un usuario

Tabla 2 Descripción de colecciones

Consideraciones técnicas

A continuación se describen las consideraciones básicas para el funcionamiento de manera

adecuada del sitio en términos de rendimiento de la base de datos.

1. El diseño del modelo se realizó en torno a las consultas de la aplicación de modo que se

adaptara fácilmente y fuera más eficiente al momento de hacer consultas

2. Se crearon índices sobre las columnas en donde se filtran datos

3. Se crearon Constraints para mantener la integridad de la base de datos de modo que por

ejemplo un email sea único, solo se pueda compartir una pregunta una vez por usuario,

entre otros.

4. Se crearon documentos embedidos de modo que el acceso a la información fuera más

rápido

5. Se utilizó el formato BSON de modo que el almacenamiento y la velocidad de escaneo

fueran eficientes.

Diagrama del modelo

Diagrama 4 Modelo de datos

Los documentos que se encuentran dentro de otros y están anidados hacen referencia a

documentos embedidos.

Modelo de despliegue

Heroku

El despliegue se realiza sobre la nube Heroku que otorga varios servicios que usa la aplicación. En

este caso se le agregaron funcionalidades de base de datos.

Diagrama de despliegue

El despliegue de las dos aplicaciones es igual, pero solo cambió el repositorio sobre el cual se

ejecuta la aplicación:

PostgreSQL:

Diagrama 5 Modelo de despliegue

MongoDB:

Diagrama 6 Modelo de despliegue

5. Pruebas sobre el sitio

Definición de las pruebas

Se definió una URL de prueba para los dos sitios en donde se contaba con toda la información de

la base de datos. Esto se hizo con el fin de observar el rendimiento del repositorio de cada sitio por

medio de pruebas de carga sobre esta URL.

Para la realización de las pruebas al sitio se usó una herramienta externa llamada Loader.io sobre

la cual se registra el sitio y sobre ella se definieron tres (4) pruebas de carga.

Con un servidor Web (Dyno):

Para cada sitio, se tomaron 325 usuarios concurrentes

Con dos servidores Web (Dyno):

Para cada sitio, se tomaron 325 usuarios concurrentes.

Con tres servidores Web (Dyno):

Para cada sitio, se tomaron 325 usuarios concurrentes

Con cuatro servidores Web (Dyno):

Para cada sitio, se tomaron 325 usuarios concurrentes.

Las pruebas anteriores se hicieron con el fin de definir si lo que fallaba era la cola de peticiones y el

tiempo que tomaba la respuesta al Browser o la base de datos de cada sitio.

Cada una de las pruebas lanzadas tiene una duración de un (1) minuto.

Resultados

A continuación se presentan los resultados de la prueba desde la herramienta Loader.io y sobre la

herramienta New Relic que sirve para medir el performance la de aplicación desde diferentes

puntos de vista y depurados de diferente manera.

PosgreSQL

Para el sitio con esta base de datos se encontraron los siguientes resultados

Un servidor Web y 325 usuarios concurrentes:

Como se puede ver, la media de error fue de 67.86% y el tiempo promedio de respuesta fue de

3734 milisegundos. La prueba no duró el minuto propuesto debido a la cantidad de errores en las

respuestas debido a Timeout.

Dos servidores web y 325 usuarios concurrentes:

Como se puede ver, la prueba se completó satisfactoriamente, el tiempo de respuesta del sitio

bajó a un promedio de 3190 milisegundos y el porcentaje de error promedio fue de 37.41%.

Esta prueba de la misma cantidad de usuarios y otro servidor Web se hizo con el fin de reducir el

tiempo de respuesta de la aplicación en otros aspectos diferentes a la base de datos y aislar un

poco los resultados.

Aislamos el tiempo de la base de datos, y los resultados fueron los siguientes.

Como se puede ver, las pruebas se ejecutaron en orden (1 servidor con 325 usuarios, 2 servidores

con 325 usuarios y 2 servidores con 400 usuarios). El pico más alto (550) corresponde a la última

prueba con más usuarios concurrentes.

Tres servidores web y 325 usuarios concurrentes:

Como se puede ver, la prueba se completó satisfactoriamente, el tiempo de respuesta del sitio

bajó a un promedio de 3156 milisegundos y el porcentaje de error promedio fue de 31.94%.

Cuatro servidores web y 325 usuarios concurrentes:

Como se puede ver, la prueba se completó satisfactoriamente, el tiempo de respuesta del sitio

bajó a un promedio de 1826 milisegundos y el porcentaje de error promedio fue de 13.19%.

Estas pruebas de carga con aumento de servidores Web se hacen con el fin de reducir el tiempo

de respuesta de la aplicación en otros aspectos diferentes a la base de datos.

MongoDB

Para el sitio con esta base de datos se encontraron los siguientes resultados

Pruebas con uno y dos servidores

Un servidor Web y 325 usuarios concurrentes:

Como se puede ver, la media de error fue de 55.52% y el tiempo promedio de respuesta fue de

3679 milisegundos. La prueba no duró el minuto propuesto debido a la cantidad de errores en las

respuestas debido a Timeout.

Dos servidores web y 325 usuarios concurrentes:

Como se puede ver, la prueba se completó satisfactoriamente, el tiempo de respuesta del sitio

bajó a un promedio de 2906 milisegundos y el porcentaje de error promedio fue de 36.61%.

Esta prueba de la misma cantidad de usuarios y otro servidor Web se hizo con el fin de reducir el

tiempo de respuesta de la aplicación en otros aspectos diferentes a la base de datos y aislar un

poco los resultados.

Aislamos el tiempo de la base de datos, y los resultados fueron los siguientes

Como se puede ver, las pruebas se ejecutaron en orden (1 servidor con 325 usuarios, 2 servidores

con 325 usuarios y 2 servidores con 400 usuarios). El pico más alto entre 300 y 325 ms

corresponde a la primera prueba con menos usuarios concurrentes aunque la variación de la carga

fue muy poca.

Pruebas con tres y cuatro servidores

Tres servidores web y 325 usuarios concurrentes:

Como se puede ver, la prueba se completó satisfactoriamente, el tiempo de respuesta del sitio

bajó a un promedio de 1057 milisegundos y el porcentaje de error promedio fue de 0.00%.

Cuatro servidores web y 325 usuarios concurrentes:

Como se puede ver, la prueba se completó satisfactoriamente, el tiempo de respuesta del sitio

bajó a un promedio de 637 milisegundos y el porcentaje de error promedio fue de 0.00%.

Estas pruebas de carga con aumento de servidores Web se hacen con el fin de reducir el tiempo

de respuesta de la aplicación en otros aspectos diferentes a la base de datos.

Conclusiones

Como se puede apreciar en los escenarios de prueba, en una primera instancia la aplicación estaba

fallando debido a que no se alcanzaban a atender todas las solicitudes y aparecían muchos errores

por Timeout. Debido a lo anterior se incrementaron los recursos a nivel de capa de presentación.

Teniendo en cuenta que podrían existir factores externos que pudieran afectar el rendimiento

debido a que la arquitectura de este tipo de soluciones es Multi - tenant y se comparten recursos

fue necesario realizar pruebas en diferentes momentos del día para no sesgar los datos por este

factor.

Para los tiempos de los sitios Web, los resultados promedio estimados se presentan a

continuación:

Prueba/Sitio Inkognit InkognitMongo

1 Servidor Web 325 usuarios 3734 ms 3679 ms 2 Servidores Web 325 usuarios 3190 ms 2906 ms 3 Servidores Web 325 usuarios 3156 ms 1057 ms 4 Servidores Web 325 usuarios 1826 ms 637 ms

De este modo, se puede observar como la aplicación desarrollada en MongoDB escala de una

manera más fácil a medida que los recursos aumentan y a la aplicación desarrollada en repositorio

relacional le cuesta más aprovechar los recursos extra que se le proveen.

Los resultados para los diferentes repositorios se presentan a continuación:

Prueba/Repositorio PostgreSQL MongoDB

1 Servidor Web 325 usuarios 300 – 400 ms 300 – 350 ms 2 Servidores Web 325 usuarios 250 – 300 ms 200 – 250 ms 3 Servidores Web 325 usuarios 800 – 1000 ms 200 – 300 ms 4 Servidores Web 325 usuarios 500 – 600 ms 400 – 500 ms

Como se puede observar, los intervalos de tiempo para PostgreSQL varían entre 250 y 600ms y

para MongoDB entre 200 y 500ms. Lo anterior muestra varianza en el segundo repositorio es

menor y además el intervalo se encuentra por debajo de la base de datos relacional.

Lo anterior demuestra que para la muestra de datos tomada y para el contexto en el que se

encuentra la aplicación, experimentalmente es mejor MongoDB.

6. Trabajo futuro 1. Debido a la arquitectura sobre la que se despliegan las aplicaciones en la Nube cuando no se

tiene un plan pagado, se comparten recursos con otras aplicaciones y depende de la cantidad

disponible de los mismos el rendimiento de los sitios desplegados.

2. La cantidad de datos puede no ser relevante para este caso y se deberían realizar pruebas con

una carga más considerable para mostrar más a detalle las virtudes o fallas de cada uno de los

escenarios.

3. Sería clave entender como los repositorios escalan de manera horizontal en un contexto en el

que la cantidad de datos es muy grande para los diferentes tipos de tecnologías.

Bibliografía Cunningham & Cunningham, I. (s.f.). Dont Repeat Yourself. Obtenido de

http://c2.com/cgi/wiki?DontRepeatYourself

Hartl, M. (2012). Ruby on Rails Tutorial Second Edition.

O'Brien, T. (2008). Maven: The Complete Reference.