Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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.