Implementación de un software web CRUD bajo una base de ...
Transcript of Implementación de un software web CRUD bajo una base de ...
Implementación de un software web CRUD bajo una base de datos no
relacional.
Ing. Carlos Andrés Tafur Delgadillo.
Grupo 1.
Noviembre 2017.
Universidad Francisco José de Caldas.
Especialización en Ingeniería de Software.
Bogotá
Implementación de un software web CRUD bajo una base de datos no
relacional.
Ing. Carlos Andrés Tafur Delgadillo.
Noviembre 2017.
Director:
Edgar Jacinto Rincón Rojas
Revisor:
Jorge Mario Calvo Londoño
Universidad Francisco José de Caldas.
Especialización en Ingeniería de Software.
Bogotá.
ii Tabla de Contenidos
1. INTRODUCCIÓN .................................................................................................................. 1 1. Título de la investigación ....................................................................................................... 1 1.1 Introducción .......................................................................................................................... 1
2. CONTEXTUALIZACIÓN DE LA INVESTIGACIÓN ............................................................ 2 2.1 Planteamiento del problema .............................................................................................. 2
2.2 Formulación del problema ................................................................................................ 4 2.3 Sistematización del problema ........................................................................................... 4
3. Objetivos ................................................................................................................................. 4 3.1 Objetivo general ................................................................................................................ 4
3.2 Objetivos específicos ........................................................................................................ 5 4. Justificación ............................................................................................................................ 5
4.1 Justificación práctica ......................................................................................................... 5 5 Hipótesis de trabajo.................................................................................................................. 6
6 Marco de referencia ................................................................................................................. 6
6.1 Marco teórico ........................................................................................................................ 6 6.2 Bases de datos relacionales y no relacionales ................................................................... 6
6. 3 Marco Conceptual ................................................................................................................ 9 6.3.1 Tipos de bases de datos no relacionales ......................................................................... 9 6.3.2 Sistemas de bases de datos no relacionales.................................................................. 14
6.3.3 Las más populares ........................................................................................................ 14
6.3.3 Documentales ............................................................................................................... 14 6.3.4 Bases de datos para grafos ........................................................................................... 15 6.3.5 ¿Qué es MongoDB? ..................................................................................................... 15
6.3.6 Características de Mongodb ......................................................................................... 15 6.3.7 Métodos para implementación CRUD ......................................................................... 16
7. ASPECTOS METODOLÓGICOS ....................................................................................... 20 7.1 Tipo de estudio ................................................................................................................ 20 7.2 Método de investigación ................................................................................................. 20
7.3 Fuentes y técnicas para la recolección de la información ............................................... 21 7.4 Tratamiento de la información ........................................................................................ 21
8. ALCANCES, LIMITACIONES Y RESULTADOS ESPERADOS .................................... 21 8.1 Alcances .......................................................................................................................... 21
8.2 Limitaciones .................................................................................................................... 22 8.3 Resultados esperados ...................................................................................................... 22
2. DESARROLLO DE LA INVESTIGACIÓN ........................................................................... 23 2.1 Análisis y Diseño ................................................................................................................ 23
2.1.1 Requerimientos funcionales ......................................................................................... 23
2.1.2 Requerimientos no funcionales .................................................................................... 26 2.2 Fase de planeación .............................................................................................................. 28
2.2.1 Capa de negocio ........................................................................................................... 28 2.2.2 Capa de aplicación ....................................................................................................... 28 2.2.3 Capa de infraestructura ................................................................................................ 30 2.2.4 Capa de motivación...................................................................................................... 31
2.2.5 Conclusión del proceso de arquitectura empresarial ................................................... 31
iii 2.3 Fase de desarrollo ............................................................................................................ 32
2.3.1 Framework web ........................................................................................................... 32
2.3.2 Fuente de datos ............................................................................................................ 33 2.3.3 Importación de datos .................................................................................................... 37 2.3.4 Categorización de datos ............................................................................................... 38
2.4 Fase de ejecución ................................................................................................................ 39 2.4.1 Interfaz de inicio .......................................................................................................... 39
2.4.2 Interfaz web para generación de reporte ...................................................................... 40 2.4.3 Interfaz para generación de reporte a través de consola .............................................. 41 2.4.3 Interfaz de lista de reportes .......................................................................................... 44 2.4.4 Interfaz de detalle de reporte........................................................................................ 45
2.5 Pruebas de rendimiento ....................................................................................................... 48 2.5.1 Metodología ................................................................................................................. 48 2.5.2 Herramienta de medición ............................................................................................. 49 2.5.3. Resultados obtenidos .................................................................................................. 50
2.5.4 Conclusiones de pruebas .............................................................................................. 50
3. Cierre de la investigación...................................................................................................... 51 3.1 Resultados alcanzados .................................................................................................... 51
3.2 Conclusiones ................................................................................................................... 51 3.3 Trabajos de investigación futuros ................................................................................... 52
ANEXOS ...................................................................................................................................... 52
Formato seguimiento proyecto ................................................................................................. 52
Oficio de advertencia soft ......................................................................................................... 52 Formato de aprobación de proyecto .......................................................................................... 52 Artículo de proyecto de grado................................................................................................... 52
Bibliografía ................................................................................................................................... 53
iv Lista de figuras
Ilustración 1 .................................................................................................................................... 8 Ilustración 2 .................................................................................................................................... 9 Ilustración 3 .................................................................................................................................. 10 Ilustración 4 .................................................................................................................................. 11 Ilustración 5 .................................................................................................................................. 13
Ilustración 6 .................................................................................................................................. 14 Ilustración 7 .................................................................................................................................. 14 Ilustración 8 .................................................................................................................................. 15 Ilustración 9 .................................................................................................................................. 28
Ilustración 10 ................................................................................................................................ 29 Ilustración 11 ................................................................................................................................ 30 Ilustración 12 ................................................................................................................................ 31 Ilustración 13 ................................................................................................................................ 32
Ilustración 14 ................................................................................................................................ 32
Ilustración 15 ................................................................................................................................ 33 Ilustración 16 ................................................................................................................................ 33
Ilustración 17 ................................................................................................................................ 36 Ilustración 18 ................................................................................................................................ 38 Ilustración 19 ................................................................................................................................ 39
Ilustración 20 ................................................................................................................................ 40
Ilustración 21 ................................................................................................................................ 40 Ilustración 22 ................................................................................................................................ 40 Ilustración 23 ................................................................................................................................ 41
Ilustración 24 ................................................................................................................................ 41 Ilustración 25 ................................................................................................................................ 41
Ilustración 26 ................................................................................................................................ 42 Ilustración 27 ................................................................................................................................ 42 Ilustración 28 ................................................................................................................................ 42
Ilustración 29 ................................................................................................................................ 42 Ilustración 30 ................................................................................................................................ 43
Ilustración 31 ................................................................................................................................ 43 Ilustración 32 ................................................................................................................................ 43
Ilustración 33 ................................................................................................................................ 44 Ilustración 34 ................................................................................................................................ 44 Ilustración 35 ................................................................................................................................ 44 Ilustración 36 ................................................................................................................................ 45 Ilustración 37 ................................................................................................................................ 45
Ilustración 38 ................................................................................................................................ 45 Ilustración 39 ................................................................................................................................ 46 Ilustración 40 ................................................................................................................................ 46 Ilustración 41 ................................................................................................................................ 47 Ilustración 42 ................................................................................................................................ 49
1
1. INTRODUCCIÓN
1. Título de la investigación
“Implementación de un software CRUD bajo base de datos no relacional”
1.1 Introducción
A pesar de los tropiezos que conlleva realizar un proyecto de desarrollo de software,
bien sea por falta de tiempo, mala planeación, falta de recursos o lo que es común falta de
entrar al detalle de lo que se necesita. Los sistemas de información han sido una solución
a todos los problemas cotidianos de una empresa o una persona, cuando la información no
era tan crucial e importante como lo es ahora, el almacenamiento de los datos los cuales
han sido bajo organizados en gestores de base de datos relacionales los cuales cuentan con
una estructura que debe definirse antes del desarrollo del software bajo un modelo de datos
dado.
Esto ha sido así, desde los años 60, al día de hoy no sólo las cosas han cambiado,
sino que el volumen de información que se maneja es abrumador y eso requiere no sólo
más recursos físicos, sino que las aplicaciones respondan de forma oportuna cuando se
solicite información.
En esta investigación se describe el revolucionario concepto que se ha venido
gestando hace algunos años para guardar la información de una forma nueva y novedosa
llamado “bases de datos no relaciones”. Veremos su definición, características, sus tipos y
cómo podemos integrarla en un proyecto de desarrollo de software.
2
2. CONTEXTUALIZACIÓN DE LA INVESTIGACIÓN
2.1 Planteamiento del problema
Una base de datos relacional es aquella que cumple a cabalidad con el modelo
relacional, garantizando la unicidad, integridad y normalización de los registros. Estas
bases de datos usan un lenguaje llamado SQL, que permite la manipulación y control de la
información. Desde comienzos de la popularización de Internet a mediados de los 90,
muchas empresas y personas comenzaron no sólo acceder, sino a ofrecer servicios a través
de la red.
Esto ha llevado un crecimiento vertiginoso en el volumen de información, la cual
ha sido almacenada de una forma tradicional, guardando datos de forma centralizada, es
decir, en una base de datos única con posibilidades de crecimiento vertical. Esto último
significa que, aunque es escalable conlleva costos de mantenimiento, soporte y futuras
actualizaciones. Lo que ha venido ocurriendo es que la información dejó de estar en un
sólo origen a tener múltiples fuentes de datos y vienen desde muchas partes y en formas
diferentes (texto plano, motores de base de datos, software), lo cual el concepto de
centralización pasó a la descentralización.
La descentralización es sólo una parte del problema, la otra parte está relacionada
con el volumen de la información, hoy por hoy empresas como la WDCC (World Data
Centre for Climate) que cuenta con alrededor de 220 Terabytes de información (Software,
3
2016) y seguirá en aumento. Estos grandes bancos de datos son de alto valor si se utiliza y
gestiona de la mejor manera, brindándole a la compañía un apoyo en sus operaciones
diarias.
Es entonces, cuando comienza a aparecer el concepto de bases de datos
documentales o no relacionales. Este tipo de base de datos, no obedece a un modelo
relacional y no requieren estructuras de datos fijas y su crecimiento es horizontal. Las
grandes ventajas de este tipo de base de datos es que el lenguaje no tiene por qué ser SQL,
son sistemas distribuidos y escalables horizontalmente. Todo esto dando como resultado
principal, la eficiencia, agilidad y facilidad de obtener resultados a partir de millones de
datos almacenados que en una base de datos relacional tardarían mucho en retornar
información, debido a la generación de grandes sentencias SQL.
Cuando una empresa planea desarrollar un software que permita no sólo el
almacenamiento de información, sino que retorne resultados de forma oportuna en el
momento que se requiera. Siempre se piensa en la creación de un modelo relacional, que
supla estos requerimientos, abandonando por defecto la integración de una base de datos
documental.
Para una compañía un software que permita obtener información de forma más
rápida, bien sea generando informes para el apoyo a la toma de decisiones o en el
almacenamiento de la información de sus procesos, será un valor agregado que se verá
reflejado en sus procesos de negocios.
4
2.2 Formulación del problema
¿Cómo un software bajo base de datos no relacional puede convertirse en una herramienta
que brinde información útil a una compañía de forma rápida y eficiente, demostrando estar
en un nivel superior al software con base de datos relacional?
2.3 Sistematización del problema
Los problemas comienzan a suceder con el transcurso del tiempo, donde la
información que ha sido almacenada se requiere ahora para generar informes que apoyen
en la toma de decisiones Inteligencia de Negocios, por ejemplo. Entonces,
¿Por qué no desarrollar un software que cuente con un sistema de base de datos
documental, que permita la gestión eficiente de la información a mediano y largo plazo?
¿Es posible demostrar desde la práctica, la fiabilidad y agilidad en las funciones
principales CRUD?
¿Cómo diseñar un modelo para una base de datos no relacional?
¿Qué tipo de gestores de bases hay en el mercado y cúal será el mejor candidato
que podemos usar en un software?
3. Objetivos
3.1 Objetivo general
5
Implementar un software para demostrar la fiabilidad y rendimiento de las
funciones CRUD en una base de datos no relacional en grandes volúmenes de información
a partir de información pública
3.2 Objetivos específicos
Diseñar un modelo de datos a partir de la lógica del negocio que permitan visualizar
la estructura de una base de datos no relacional.
Integrar el modelo de datos usando MongoDB como gestor de base de datos
documental para el almacenamiento de datos del software.
Demostrar el rendimiento y la fiabilidad de la aplicación web, realizando pruebas a
las funciones CRUD de la base de datos para demostrar su rendimiento.
4. Justificación
4.1 Justificación práctica
Las bases de datos desde la década de los 60, viene determinado por el uso que
estos sistemas han hecho las principales compañías de internet como Amazon, Google,
Twitter y Facebook. Estas compañías tenían que enfrentarse a nuevos desafíos en el
tratamiento de los datos motivados por el enorme crecimiento de la Web donde se requería
dar respuesta a la necesidad de proporcionar información procesada a partir de grandes
volúmenes de datos. Estas compañías se dieron cuenta de que el rendimiento y sus
necesidades de tiempo real eran más importantes que la consistencia de los datos, aspecto
6
este último al que las bases de datos relacionales tradicionales dedicaban una gran cantidad
de tiempo de proceso.
5 Hipótesis de trabajo
El desarrollo de un software utilizando una base de datos no relacional, permitirá
demostrar las ventajas que tienen para el manejo de grandes volúmenes de información. Al
no existir una estructura definida para el almacenamiento de información, permitirá
almacenar, consultar información mucho más rápido y de forma eficiente.
6 Marco de referencia
6.1 Marco teórico
Se deben tener en cuenta algunos conceptos claves para comprender en que se fundamenta
esta investigación.
6.2 Bases de datos relacionales y no relacionales
Las bases de datos relacionales han sido la única solución para el almacenamiento de datos
en todos los proyectos de software. Sin embargo, no todo lo que brilla es oro y muchos de
estos proyectos con el pasar del tiempo la información que van almacenando no sólo se
torna externa sino compleja sobre todo en el momento de consultar y presentarla al usuario.
Cuando esto comienza suceder la disponibilidad es lo primero que comienza a verse
7
afectado, el retorno de la información se vuelve demorado y la experiencia del usuario
comienza a decaer por dicha razón.
En las bases de datos relacionales funcionan a partir de un conjunto de propiedades
definidas como ACID que por sus siglas en inglés traduce como “Atomicidad, consistencia,
aislamiento y durabilidad. Según (Amazon Web Services, 15), respecto al término anterior
Atomicidad sería en términos coloquiales sería como “la transacción funciona o no
funciona”, ya que si en una sentencia SQL hay algo erróneo bien sea mal escrito o una
columna mal escrita dicha sentencia no será ejecutada y por ende será un error a corregir.
Según (Sullivan, 2015) la consistencia indica que una vez ejecutada esta sentencia
los datos deben acoplarse al esquema o estructura de nuestra base de datos. El aislamiento,
significa que esta y otras sentencias deben ser ejecutadas por separado. La durabilidad es
la capacidad de recuperarse de un error del sistema.
Los modelos de datos para las bases de datos no relacionales se normalizan en
tablas, las cuales tienen filas, columnas, índices, relaciones y otros elementos. Las bases
de datos no relaciones no suelen contener un esquema. Se suele utilizar una clave para
recuperar valores, conjuntos de columnas o documentos JSON semiestructurados y estos a
su vez traen otros documentos que contienen atributos de elementos relacionados.
Según el libro (Pramod J. Sadalage, 2013) las relaciones proporciona cierta
elegancia y simplicidad, pero también introduce limitaciones. En particular, los valores de
una tupla relacional tienen que ser simples: no pueden contener ninguna estructura, como
un registro anidado o una lista.
8
Que pueden tener estructuras mucho más ricas que las relaciones. Como resultado, si desea
utilizar una estructura de datos de información más rica, tiene que traducirla a una
representación relacional para almacenarla en disco.
De ahí la incompatibilidad de impedancia-dos representaciones diferentes que requieren
traducción, ver ilustración 1
Ilustración 1
Una orden de compra puede generarse a partir de la relación entre diferentes tablas de la base de
datos. - Autoría propia
Tabla órdenes
Datos de la orden
Cliente
Orden de compra
Tabla Clientes
Tabla ítems ordenes
Llave
v v
9
6. 3 Marco Conceptual
6.3.1 Tipos de bases de datos no relacionales
Llave - valor
Este tipo es la razón de existencia de las bases de datos NOSQL. Ya que la llave es
el identificador único y puede ser alfanumérico. El valor es lo que se almacenará. Las bases
de datos de valores clave se basan en principios mínimos para almacenar y recuperar datos.
Ilustración 2
Autoría propia
Según (Pramod J. Sadalage, 2013), A diferencia de las bases de datos relacionales,
no hay tablas, por lo que no hay características asociadas con tablas, como columnas y
restricciones en columnas. No hay necesidad de unirse en bases de datos de valor clave,
por lo que no hay claves foráneas. Las bases de datos de valores clave no admiten un
lenguaje de consulta enriquecido, como SQL.
Documental
Colección 1
Llave valor valor
Llave valor valor
Llave valor valor
Colección 2
Llave valor valor
Llave valor valor
Llave valor valor
10
Este tipo de base de datos almacena texto semiestructurado, puede ser JSON o
XML que cuentan con un esquema libre.
Una colección en formato JSON contiene la siguiente estructura:
{nombrecliente: “Nombre1”, apellidocliente: “Apellido”, numerocedula”, “12345”}
Una colección de tipo documental tendría como ejemplo los siguientes datos:
Empleado 1 Empleado 2
{
nombre: “Nombre1”,
apellido: “Apellido2”,
historialaboral:
[{
cargo: “Practicante”,
fechaInicio:“1-Feb-2016”,
fechatermino:“30-Jun-2016”
}]
}
{
nombre: “Nombre2”,
apellido: “Apellido2”,
ciudadreside: “Bogotá”
telefono: “4102019302,
historialaboral:
[{
cargo: “Practicante”,
fechaInicio:“1-Jul-2016”,
fechatermino:“30-Dic-2016”
}{
cargo: “Ingeniero de Sistemas”,
StartDate:“1-Feb-2016”,
endDate:“30-Jun-2016”
}]}
Ilustración 3
Autoría propia
11
Como podemos observar el cliente dos, cuenta con más datos que el cliente uno.
Esto desde la base de datos no supone un problema, ya que los desarrolladores pueden
añadir tantos datos adicionales como sean necesarios. Sin embargo, si son responsables de
manejarlos y validar que entre cada cliente tengan información en común.
Columnares
Estas permiten múltiples atributos por llave y su característica principal es el
almacenamiento en columnas y no filas como es usual.
Ilustración 4
Autoría propia
Esto resulta bastante útil cuando queremos almacenar análisis y predicción de
datos, inteligencia de negocios puede ser una opción.
Diferencias entre columnares y bases de datos relacionales
Una cosa que hace falta en las bases de datos es la compatibilidad para unir tablas.
Las tablas en las bases de datos relacionales tienen una estructura, y el sistema de gestión
Fila 1
Fila 2
nombres apellidos ciudad
John Smith Alemania
John Smith Alemania
12
de base de datos relacional se puede aprovechar esto sin embargo, en noSQL las
columnares puede variar de una fila a otra
Orientado a grafos
Este tipo permite representar la información como nodos y aristas que modelan la
relación que tienen entre ellos. A diferencia de los demás tipos que usan columnas y filas,
este tipo define en términos formales vértices y aristas. En (Sullivan, 2015), Un nodo es
una representación de un objeto que tiene un identificador y un conjunto de atributos. Y
una arista es una conexión entre dos nodos que contienen atributos de esa relación.
Un ejemplo de lo anterior, sería una red social donde una persona puede tener una
amista con más personas. El cual se representaría en el siguiente grafo.
13
Ilustración 5
Autoría propia
En la figura anterior están las personas que son los nodos y sus aristas que pueden
estar en cualquier orden y estas indican entre que personas tienen una amistad.
Según (Pramod J. Sadalage, 2013), Las bases de datos gráficas permiten una consulta más
eficiente cuando las rutas a través de los nodos están involucradas. Muchas áreas de
aplicación se modelan eficientemente como gráficos y, en base de datos de gráficos puede
simplificar el desarrollo de aplicaciones y minimizar la cantidad de código que debe
realizarse.
Pedro
Juan
Camilo
Victoria
Sarah
14
6.3.2 Sistemas de bases de datos no relacionales
En la página principal NoSQL (Nosql Database, 2017), dicen que hay más de 225
tipos de bases de datos no relacionales. Las bases de datos no relacionales se pueden
clasificar de acuerdo a los tipos anteriores.
6.3.3 Las más populares
Base de datos Versión actual Licencia
MongoDB 3.4 MongoDB inc
Cassandra 3.1 Apache
CouchDB 2.0 Apache
Redis 3.2 Redislabs
Ilustración 6
Información actualizada hasta la fecha de esta investigación.
Tomado de (DBig Cloud, 2017)
6.3.3 Documentales
Base de datos
CouchDB
HBase
Accumulo
Hypertable
Ilustración 7
Tomado de (Kovacs, 2017)
15
6.3.4 Bases de datos para grafos
Base de datos
OrientDB
Neo4j
Ilustración 8
Tomado de (Kovacs, 2017)
6.3.5 ¿Qué es MongoDB?
Según (Chodorow, 2013), Es una base de datos orientada a documentos, no de tipo
relacional. La razón principal para alejarse del modelo relacional es hacer que la escala sea
más fácil, pero hay otras ventajas también. Una base de datos orientada a documentos
reemplaza el concepto de "fila" por el "documento". Al permitir que los documentos
incrustados y arrays, al ser orientado a documentos permiten representar relaciones
jerárquicas complejas con un único registro.
6.3.6 Características de Mongodb
En el libro de (Chodorow, 2013) nos presenta cinco características principales:
Un documento es la unidad básica de datos para MongoDB y es aproximadamente
equivalente a una fila en un sistema de gestión de base de datos relacional (pero mucho
más expresivo).
Una colección puede ser pensada como una tabla con un esquema dinámico
Una sola instancia de MongoDB puede alojar múltiples bases de datos que puede tener
sus propias colecciones.
16
Cada documento tiene una clave especial, "_id", que es única dentro de una colección.
MongoDB viene con una consola que es útil para la administración de instancias de
MongoDB y manipulación de datos.
6.3.7 Métodos para implementación CRUD
De acuerdo con la documentación de MongoDB (Inc, 2017), la siguiente
información permite implementar las acciones básicas tales como el CRUD.
Método insertOne()
Este método permite insertar un solo registro.
db.productos.insertOne( { item: "celular", valor: 850.000 } );
El resultado será:
{"acknowledged" : true, "insertedId" : ObjectId("56fc40f9d735c28df206d078")}
Método insertMany()
Este método permite insertar múltiples registros en una sóla sentencia
db.productos.insertMany( [
{ item: "celular 1", valor: 850.000 },
{ item: "celular 1", qty: 1.200.000 },
{ item: "celular 1" , qty: 3.000.000 }
] );
El resultado será:
{ "acknowledged" : true,
17
"insertedIds" : [
ObjectId("562a94d381cb9f1cd6eb0e1a"),
ObjectId("562a94d381cb9f1cd6eb0e1b"),
ObjectId("562a94d381cb9f1cd6eb0e1c")
]}
Para los métodos de inserción, podemos defnir nuestros propios identificadores.
Sólo debemos añadir “_Id”, por ejemplo:
db.products.insert( { _id: 10, item: "box", qty: 20 } )
El resultado será:
{ "_id" : 10, "item" : "box", "qty" : 20 }
Método find()
Este método nos permite seleccionar un elemento en una colección y devuelve un
cursor a dichos elementos. Si queremos seleccionar el elemento con identificador
2, debemos hacer lo siguiente:
db.productos.find( { _id: 2 } )
El resultado será:
db. productos.find({ _id: { $in: [ 2, ObjectId("507c35dd8fada716c89d0013") ] }
})
Método updateOne()
Permite modificar un o más elementos de una colección. Este método puede
modificar campos específicos de una colección existente o modificarlo
completamente.
18
db.clientes.update(
{ name: "Charlie" },
{
nombre: "McLister",
cedula: 12345,
edad: 32
},
{ upsert: true })
Método updateMany()
Este método nos permite actualizar múltiples elementos de la colección a partir del
filtro
db.clientes.updateMany(
{ id: { 4 } }, { $set: { "Categoria" : “Platinum”} } );
El resultado sería:
{ "acknowledged" : true, "matchedCount" : 1, "modifiedCount" : 1 }
Donde nos indica que la actualización afectó a un elemento.
Método replaceOne()
Reemplaza un elemento en la colección basada en el filtro. Vamos a reemplazar,
por ejemplo, un nombre mal escrito.
db.restaurant.replaceOne(
19
{ "name" : "Carro modlo 2017" },
{ "name" : "Carro Modelo 2017" }
);
El resultado será:
{ "acknowledged" : true, "matchedCount" : 1, "modifiedCount" : 1 }
Indicando que ha encontrado un elemento con ese criterio y ha sido modificado.
Método deleteOne()
Este método no permite borrar un elemento en particular:
db.productos.deleteOne( { "_id" : 2 } );
El resultado nos indica que el identificador fue borrado:
{ "acknowledged" : true, "deletedCount" : 1 }
Método deleteMany()
Este método nos permite borrar múltiples registros a partir de un criterio
db.ordenes.deleteMany( { "cliente" : "Hoteles Estelar." } );
El resultado nos indica cuantos registros fueron borrados:
{ "acknowledged" : true, "deletedCount" : 31 }
Para los métodos anteriores es importante tener en cuenta lo siguiente:
Manejo de errores
En dado caso que algo falle debemos encerrar nuestras sentencias en un “try –
catch”, el cual nos permite obtener información si nuestra base de datos tuvo algún
problema.
Por ejemplo:
20
try {
sentencia_nosql
}catch (e){
print (e);
}
Evitar la duplicidad
Para evitar que MongoDB inserte el mismo documento más de una vez, debemos
crear un índice único en el campo de nombre. Con un índice único, si varias
aplicaciones emiten la misma actualización con upsert: true, el método”update”,
insertará correctamente un nuevo elemento.
7. ASPECTOS METODOLÓGICOS
7.1 Tipo de estudio
El tipo de estudio planteado para esta investigación es interactivo; ya que se
propiciará el uso de bases de datos no relacionales en el desarrollo de software.
7.2 Método de investigación
Se realizará un método de análisis inductivo, donde se demuestra todas las
características de una base de datos relacional y cómo puede ser un gran aliado en un
desarrollo de software. Explicando desde el origen de bases de datos no relacionales,
seleccionar un gestor de base de datos y describiendo los métodos disponibles para crear
software con ellos.
21
7.3 Fuentes y técnicas para la recolección de la información
Actualmente la información sobre NoSQL es escasa, pero existen dos libros
principales; No SQL Distilled de Pramod J. Sadalage - Martin Fowler y NoSQL For Mere
Mortals de Dan Sullivan, los cuales son muy descriptivos en la teoría que permite
demostrar al lector de forma fácil todo lo relacionado con el tema.
7.4 Tratamiento de la información
Una vez la información obtenida sea consolidada, se procederá a organizarse para
estudiar su aplicación en esta investigación. La información puede otorgar una
profundización de términos posiblemente desconocidos y que hagan falta revisar o probar.
8. ALCANCES, LIMITACIONES Y RESULTADOS ESPERADOS
8.1 Alcances
El alcance del proyecto será el desarrollo de software orientado a la web, donde se
permita visualizar el proceso CRUD en una base de datos no relacional. Este alcancé tendrá
las siguientes características:
1. Software orientado a la web.
2. Implementación el gestor de base de datos Mongo DB en su versión más reciente hasta la
fecha de este documento.
3. Importación de datos públicos abiertos.
4. Visualización de información de una forma más simple y fácil de entender.
22
8.2 Limitaciones
Una limitación principal será el no contar con un tamaño de información
considerable, para demostrar el rendimiento de las bases de datos no relacionales a la hora
de retornar información.
8.3 Resultados esperados
Se espera que esta investigación demuestre la fiabilidad, rendimiento y potencial
del desarrollo de un software bajo bases de datos no relacionales.
23
2. DESARROLLO DE LA INVESTIGACIÓN
2.1 Análisis y Diseño
2.1.1 Requerimientos funcionales
Número RE_1 Versión 1.0 Tipo de requerimiento Funcional
Nombre Página de inicio/principal
ESPECIFICACIÓN DEL REQUERIMIENTO
Origen La primera página del software, debe contar con información
relacionada al software y un enlace a la lista de reportes.
Descripción La información a visualizar debe ser la siguiente:
Título de proyecto
Información de autor
Link a módulo de reportes.
Condiciones de aceptación Ninguna
Prioridad Alta
Información externa Ninguna.
Número RE_2 Versión 1.0 Tipo de requerimiento Funcional
Nombre Módulo de reportes – Importación de datos
ESPECIFICACIÓN DEL REQUERIMIENTO
Origen Permitir la importación de datos a partir de una fuente externa,
para poder registrar dicha información en el software.
Descripción Mediante un formulario web, se debe ingresar los siguientes
datos para importar información:
Nombre de reporte.
Número de datos
Fuente de datos
Condiciones de aceptación La fuente de datos debe ser JSON.
Prioridad Alta
Información externa Ninguna.
24
Número RE_3 Versión 1.0 Tipo de requerimiento Funcional
Nombre Módulo de reportes – Importación de datos
Motivo de la Versión Creación del requerimiento
ESPECIFICACIÓN DEL REQUERIMIENTO
Origen del Requerimiento Optimizar la carga de datos para grandes volúmenes de
información.
Descripción En el formulario debe existir un campo que indique el
número máximo de datos por grupo o lote al momento de
realizar la importación de datos.
Condiciones de aceptación RE_2
Prioridad Alta
Información externa Ninguna.
Número RE_5 Versión 1.0 Tipo de requerimiento Funcional
Nombre Módulo de reportes – Importación de datos
Motivo de la Versión Creación del requerimiento
ESPECIFICACIÓN DEL REQUERIMIENTO
Origen del Requerimiento Información de ejecución y rendimiento. Todas las
importaciones deben contar con la siguiente información
para efectos de análisis y control:
Tiempo de ejecución
Tiempo transcurrido
Descripción El tiempo de ejecución permitirá indicar cuanto tiempo llevó
realizar la importación, clasificación y registro de datos
únicamente.
El tiempo transcurrido indica cuanto tiempo llevó realizar la
tarea de importación.
Condiciones de aceptación RE_2
Prioridad Alta
25
Número RE_6 Versión 1.0 Tipo de requerimiento Funcional
Nombre Módulo de reportes – Importación de datos
Motivo de la Versión Creación del requerimiento
ESPECIFICACIÓN DEL REQUERIMIENTO
Origen del Requerimiento Clasificación de la fuente de información
Descripción Al momento de importar los datos, debe detectar cuales
categorías o tipos de información se repiten para clasificar
los grupos mediante categorías.
Condiciones de aceptación RE_2, RE_3, RE_4
Prioridad Alta
Número RE_7 Versión 1.0 Tipo de requerimiento Funcional
Nombre Módulo de reportes – Visualización de datos
Motivo de la Versión Creación del requerimiento
ESPECIFICACIÓN DEL REQUERIMIENTO
Origen del Requerimiento Visualización de información
Descripción Una vez importada la información, deberá poder ser
visualizada mediante tablas que permitan su rápida
interpretación.
Condiciones de aceptación RE_6
Prioridad Alta
26
Número RE_8 Versión 1.0 Tipo de requerimiento Funcional
Nombre Módulo de reportes – Borrado
Motivo de la Versión Creación del requerimiento
ESPECIFICACIÓN DEL REQUERIMIENTO
Origen del Requerimiento Permitir el borrado de reportes.
Descripción Los reportes pueden ser borrados por el usuario.
Condiciones de aceptación Ninguna
Prioridad Alta
2.1.2 Requerimientos no funcionales
Número RE_1 Versión 1.0 Tipo de requerimiento No Funcional
Nombre Adaptable en diferentes dispositivos.
Motivo de la Versión Creación del requerimiento
ESPECIFICACIÓN DEL REQUERIMIENTO
Origen del Requerimiento Responsive
Descripción La aplicación debe visualizarse correctamente en
dispositivos móviles.
Condiciones de aceptación Ninguna
Prioridad Baja
27
Número RE_2 Versión 1.0 Tipo de requerimiento No Funcional
Nombre Imagen de aplicativo
Motivo de la Versión Creación del requerimiento
ESPECIFICACIÓN DEL REQUERIMIENTO
Origen del Requerimiento Logo de la aplicación.
Descripción La aplicación debe contar con el logo de la universidad.
Condiciones de aceptación Ninguna
Prioridad Baja
Número RE_3 Versión 1.0 Tipo de requerimiento No Funcional
Nombre Botones de la interfaz
Motivo de la Versión Creación del requerimiento
ESPECIFICACIÓN DEL REQUERIMIENTO
Origen del Requerimiento Botones intuitivos
Descripción La aplicación debe contar con botones llamativos que
permitan identificar de forma fácil su acción relacionada.
Condiciones de aceptación Ninguna
Prioridad Baja
28
2.2 Fase de planeación
2.2.1 Capa de negocio
Según (Slagter , Doest, Lacob, Lankhorst, & Leeuwen, 2004), este punto de vista
se usa para mostrar la estructura y la composición de alto nivel de uno o más procesos
comerciales.
Ilustración 9
Autoría propia
En la imagen anterior, se indica que el proceso en el cual se apoyará el software es
la importación de datos y generación de reportes. En la parte inferior se describen los
procesos que conlleva realizar esto.
2.2.2 Capa de aplicación
Este punto de vista es útil para diseñar o comprender la estructura principal de
aplicaciones o componentes y los datos asociados, p. para crear un primer paso de trabajo.
(Slagter , Doest, Lacob, Lankhorst, & Leeuwen, 2004).
29
Ilustración 10
Autoría propia
En este punto de vista, se puede observar las funciones y módulos planteados para
el desarrollo de software.
Función aplicación web:
o Habrá dos formas de importar información externa a la página web, las
cuales son las siguientes:
Formulario web
Este formulario resulta el idóneo para volúmenes de información
bajos.
Consola de importación.
Esta interfaz permite importar grandes volúmenes de información
sin producir fallos como falta de memoria en el servidor.
Función datos públicos abiertos
o Una aplicación externa, que cuenta con un servicio web para la consulta de
información.
o Al servicio se accede mediante autenticación de datos.
o Esta función retorna la información necesaria para el software.
30
Interfaz reporte
o El resultado del proceso, que permite visualizar de forma clara la
información importada.
2.2.3 Capa de infraestructura
Este punto de vista permite visualizar el hardware y software de los cuales depende
la capa de aplicación.
Ilustración 11
Autoría propia
En primer lugar, se debe contar con un servidor web, el cual permita la correcta
ejecución de la aplicación web y el motor de base de datos. Las características con las
cuales debe contar son:
31
Sistema operativo Linux o Windows.
Servidor Apache.
Motor de base de datos MongoDB en su versión más reciente.
Composer, para manejo de dependencias.
Firewall con configuración de seguridades mínimas que eviten posibles intrusiones al
sistema.
Más arriba, tendremos un navegador web el cual estará instalado en el dispositivo del
usuario. Para que de esta manera pueda interactuar con el software.
2.2.4 Capa de motivación
Esta capa se fundamenta en presentar una visión completa o parcial sobre cuál es
la motivación de los stakeholders frente a sus objetivos principales y principios.
Ilustración 12
Autoría propia
En el punto de vista motivacional, al usuario tiene como objetivo importar altos
volúmenes de información pública con el fin de evaluar el rendimiento y cómo se comporta
la base de datos no relacional MongoDB. Una vez logrado esto, espera poder visualizar
todo el detalle de la información cargada.
2.2.5 Conclusión del proceso de arquitectura empresarial
32
Una vez realizada la arquitectura empresarial, se pudo comprender mejor alguno
de los procesos claves de lo que debe ser la aplicación web. También se identificaron los
aspectos más relevantes de la aplicación, los cuales son:
1. Datos públicos:
a. La fuente de datos de externa, debe permitir mediante autenticación la
obtención de diferentes volúmenes de información.
2. Carga de información
a. Debe contar con un formato de datos aceptable, para que pueda ser
interpretada al momento de realizar la importación.
3. Visualización de información:
a. Una vez cumplido lo anterior, la información debe visualizarse de forma
clara al usuario.
2.3 Fase de desarrollo
2.3.1 Framework web
Symfony es un framework orientado a objetos, desarrollado en lenguaje PHP. Será
usado como base en la cual se sustentará este proyecto. Tiene una ventaja importante frente
a otros, ya que, aunque deberá instalarse cuenta con el componente necesario para trabajar
aplicaciones bajo bases de datos MongoDB.
La implementación de un proyecto Symfony, es sencilla y se describe a
continuación.
1. Descargar el instalador Symfony.
Ilustración 13
Autoría propia
2. Sobre nuestro directorio, ejecutamos el siguiente comando:
Ilustración 14
Autoría propia
33
3. Una vez haya culminado el proceso anterior, nos movemos a la carpeta con nombre
“miproyecto”
Ilustración 15
Autoría propia
4. A partir de este momento, ya podemos ejecutar el comando “bin console” el cual
son comandos para poder ejecutar más acciones del symfony y comenzar el
desarrollo de la aplicación.
Ilustración 16
Autoría propia
2.3.2 Fuente de datos
Teniendo como objetivo el encontrar altos volúmenes registros de información
además de ser confiable, se estableció que el lugar adecuado para cumplir lo anterior sería
a partir del uso de la plataforma Open Data la cual está enfocada en ofrecer datos públicos
de diferentes entidades y que están disponibles para cualquier usuario.
Como resultado de la búsqueda se encuentran las siguientes posibles opciones para
usar en la aplicación, las cuáles son:
1. 311 Services Requests – New York
Número de registros: 1.6.2 millones.
2. 311 Services Requests – Miami
Número de registros: 1.39 millones.
La opción seleccionada será la uno “311 Services Requests”, este grupo de datos
contiene todas las solicitudes de servicio a la línea 311 en Nueva York, desde el 2010 hasta
la fecha y cuya actualización e inserción de nuevos datos se realiza de forma diaria.
34
Este grupo de datos contiene la siguiente estructura e información disponible:
Column Name Description Type
Unique Key Unique identifier of a Service Request (SR) in the open
data set Plain Text
Created Date Date SR was created Date & Time
Closed Date Date SR was closed by responding agency Date & Time
Agency Acronym of responding City Government Agency Plain Text
Agency Name
This is the fist level of a hierarchy identifying the topic of
the incident or condition. Complaint Type may have a
corresponding Descriptor (below) or may stand alone.
Plain Text
Complaint Type Full Agency name of responding City Government Agency Plain Text
Descriptor
This is associated to the Complaint Type, and provides
further detail on the incident or condition. Descriptor values
are dependent on the Complaint Type, and are not always
required in SR.
Plain Text
Location Type Describes the type of location used in the address
information Plain Text
Incident Zip Incident location zip code, provided by geo validation. Plain Text
Incident Address House number of incident address provided by submitter. Plain Text
Street Name Street name of incident address provided by the submitter Plain Text
Cross Street 1 First Cross street based on the geo validated incident
location Plain Text
Cross Street 2 Second Cross Street based on the geo validated incident
location Plain Text
Intersection
Street 1
First intersecting street based on geo validated incident
location Plain Text
Intersection
Street 2
Second intersecting street based on geo validated incident
location Plain Text
Address Type Type of incident location information available. Plain Text
City City of the incident location provided by geovalidation. Plain Text
Landmark If the incident location is identified as a Landmark the
name of the landmark will display here Plain Text
Facility Type If available, this field describes the type of city facility
associated to the SR Plain Text
Status Status of SR submitted Plain Text
35
Column Name Description Type
Due Date
Date when responding agency is expected to update the SR.
This is based on the Complaint Type and internal Service
Level Agreements (SLAs).
Date & Time
Resolution
Description
Describes the last action taken on the SR by the responding
agency. May describe next or future steps. Plain Text
Resolution
Action Updated
Date
Date when responding agency last updated the SR. Date & Time
Community
Board Provided by geovalidation. Plain Text
Borough Provided by the submitter and confirmed by geovalidation. Plain Text
X Coordinate
(State Plane) Geo validated, X coordinate of the incident location. Number
Y Coordinate
(State Plane) Geo validated, Y coordinate of the incident location. Number
Park Facility
Name
If the incident location is a Parks Dept facility, the Name of
the facility will appear here Plain Text
Park Borough The borough of incident if it is a Parks Dept facility Plain Text
School Name
If the incident location is a Dept of Education school, the
name of the school will appear in this field. If the incident
is a Parks Dept facility its name will appear here.
Plain Text
School Number
If the incident location is a Dept of Education school, the
Number of the school will appear in this field. This field is
also used for Parks Dept Facilities.
Plain Text
School Region If the incident location is a Dept of Education School, the
school region number will be appear in this field. Plain Text
School Code If the incident location is a Dept of Education School, the
school code number will be appear in this field. Plain Text
School Phone
Number
If the facility = Dept for the Aging or Parks Dept, the
phone number will appear here. (note - Dept of Education
facilities do not display phone number)
Plain Text
School Address
Address of facility of incident location, if the facility is
associated with Dept of Education, Dept for the Aging or
Parks Dept
Plain Text
School City
City of facilities incident location, if the facility is
associated with Dept of Education, Dept for the Aging or
Parks Dept
Plain Text
36
Column Name Description Type
School State
State of facility incident location, if the facility is
associated with Dept of Education, Dept for the Aging or
Parks Dept
Plain Text
School Zip Zip of facility incident location, if the facility is associated
with Dept of Education, Dept for the Aging or Parks Dept Plain Text
School Not
Found Y' in this field indicates the facility was not found Plain Text
School or
Citywide
Complaint
If the incident is about a Dept of Education facility, this
field will indicate if the complaint is about a particualr
school or a citywide issue.
Plain Text
Vehicle Type If the incident is a taxi, this field describes the type of TLC
vehicle. Plain Text
Taxi Company
Borough
If the incident is identified as a taxi, this field will display
the borough of the taxi company. Plain Text
Taxi Pick Up
Location
If the incident is identified as a taxi, this field displays the
taxi pick up location Plain Text
Bridge Highway
Name
If the incident is identified as a Bridge/Highway, the name
will be displayed here. Plain Text
Bridge Highway
Direction
If the incident is identified as a Bridge/Highway, the
direction where the issue took place would be displayed
here.
Plain Text
Road Ramp If the incident location was Bridge/Highway this column
differentiates if the issue was on the Road or the Ramp. Plain Text
Bridge Highway
Segment
Additional information on the section of the
Bridge/Highway were the incident took place. Plain Text
Garage Lot
Name
Related to DOT Parking Meter SR, this field shows what
garage lot the meter is located in Plain Text
Ferry Direction Used when the incident location is within a Ferry, this field
indicates the direction of ferry Plain Text
Ferry Terminal
Name
Used when the incident location is Ferry, this field
indicates the ferry terminal where the incident took place. Plain Text
Latitude Geo based Lat of the incident location Number
Longitude Geo based Long of the incident location Number
Location Combination of the geo based lat & long of the incident
location Location
Ilustración 17
37
Tomado de (OpenData, 2017)
2.3.3 Importación de datos
Teniendo clara que información se va utilizar, Open Data permite el consumo de
información a través de un servicio API, la url para descargar la información es a través de
“https://data.cityofnewyork.us/resource/fhrw-4uyv.json”, esta url permite una serie usar
ciertos parámetros que permiten organizar u obtener la información de un modo similar a
sentencias SQL, algunas de ellas son:
2.3.3.1 Filtrado de información
El parámetro “$where”, nos permite seleccionar sólo ciertos tipos de datos.
Ejemplo
https://data.cityofnewyork.us/resource/fhrw-
4uyv.json?$where=complaint_type=%27Rodent%27
2.3.3.2 Paginación de datos
El parámetro “$limit”, nos permite establecer un número máximo de datos:
https://data.cityofnewyork.us/resource/fhrw-4uyv.json?$limit=1
El parámetro “$limit”, nos permite establecer un número máximo de datos:
https://data.cityofnewyork.us/resource/fhrw-4uyv.json?$limit=50&$offset=150
2.3.3.3 Organización de información
El parámetro $order, nos permite fijar un orden sea ascendente o descendente.
https://data.cityofnewyork.us/resource/fhrw-
4uyv.json?$limit=5&$order=complaint_type%20ASC
38
2.3.4 Categorización de datos
El aspecto más importante de este software es la detección de categorías comunes
y su agrupación para poder ser interpretada de mejor manera. Esta categoría funciona de
la siguiente manera:
Ilustración 18
Autoría propia
Consulta
•Envío de parámetros al API.
Descarga
•Obtención de datos.
Categorización
•Registro de categorías únicas.
•Si la categorías ya está registrada la omite.
Registro de información
•Asignación de categoría.
Registro de reporte
•Visualización de información organizada y clasificada.
39
2.4 Fase de ejecución
2.4.1 Interfaz de inicio
De acuerdo al requerimiento RE_1, se coloca toda la información relacionada al
proyecto de grado, autor, información de la carrera y de la universidad.
Ilustración 19
Autoría propia
40
2.4.2 Interfaz web para generación de reporte
Damos clic en el botón “Agregar nuevo”, allí aparecerá un formulario web con la
siguiente información:
Ilustración 20
Autoría propia
Nombre de reporte:
El nombre el cual podremos consultar el reporte desde la aplicación web.
Ilustración 21
Autoría propia
Datos a importar:
Número de información que deseamos registrar.
Ilustración 22
Autoría propia
41
Agrupación de datos:
Este parámetro nos permite segmentar la información a descargar, ya que
existen muchas probabilidades que al traer toda la información de una vez
el servidor se quede sin recursos de memoria.
Ilustración 23
Autoría propia
Url del archivo JSON:
Es la ruta donde se encuentra la fuente de información, es importante que
tenga forma JSON.
Ilustración 24
Autoría propia
2.4.3 Interfaz para generación de reporte a través de consola
A través del comando “bin/console cargadatosmongo”, se llama la función que
permite importar los datos en segundo plano.
Ilustración 25
Autoría propia
42
Luego de ejecutar el comando, la aplicación nos solicitará ingresar los siguientes
datos.
Url del archivo JSON:
Ilustración 26
Autoría propia
Datos a importar:
Ilustración 27
Autoría propia
Agrupación de datos:
Ilustración 28
Autoría propia
Nombre de reporte:
Ilustración 29
Autoría propia
Una vez hecho lo anterior, la aplicación comenzará a importar y registrar los datos.
43
Ilustración 30
Autoría propia
Cuando el proceso haya terminado, nos mostrará a modo ilustrativo un reporte de
carga, con información de procesamiento de los datos y tiempo de ejecución en
milisegundos.
Ilustración 31
Autoría propia
A partir de este momento ya podremos visualizar el reporte desde la interfaz web:
Ilustración 32
Autoría propia
44
2.4.3 Interfaz de lista de reportes
Esta interfaz, permite visualizar todos los reportes generados a través del
software.
Ilustración 33
Autoría propia
Cuenta con algunas opciones que permiten gestionar esta información, por ejemplo:
Borrado individual o masivo de reportes:
Ilustración 34
Autoría propia
Paginación de resultados:
Ilustración 35
Autoría propia
45
Agregar nuevo reporte:
Ilustración 36
Autoría propia
Filtrado de información
Ilustración 37
Autoría propia
2.4.4 Interfaz de detalle de reporte
Detalle de tipos de solicitudes más realizadas:
Ilustración 38
Autoría propia
46
Ubicación geográfica de de solicitudes realizadas
Ilustración 39
Autoría propia
Mapa de calor de áreas donde más se realizan solicitudes
Ilustración 40
Autoría propia
47
Organización de información mediante tablas
Ilustración 41
Autoría propia
48
2.5 Pruebas de rendimiento
2.5.1 Metodología
Se realizan diferentes pruebas de estrés al servidor invocando una función que
permitía realizar el registro de información desde OpenData hacia a un documento en
MongoDB.
Esta prueba de estrés se compone de lo siguiente:
Creación de API, la cual va registrar grupos de información definidos
previamente en el código.
Llamado de API individual, simulando aplicaciones externas enviando la
solicitud de registro.
Llamado de API simultáneo, simulando aplicaciones externas enviando
solicitudes de registro al mismo tiempo.
Se realizarán las siguientes pruebas, basados en los siguientes datos:
Datos: El número de datos que serán registrados en la base de datos
MongoDB.
Peticiones: Simula el número de dispositivos a los cuales se está invocando el
API.
Concurrencia: Simula conexiones de dispositivos enviando datos
simultáneamente.
Datos Peticiones Concurrencia Tiempo
5000 1 1
5000 5 2
5000 10 4
5000 30 10
5000 50 20
10000 1 1
10000 5 2
10000 10 4
10000 30 10
10000 50 20
30000 1 1
30000 5 2
30000 10 4
30000 30 10
30000 50 20
Ilustración 42
Autoría propia
49
2.5.2 Herramienta de medición
Para realizar la prueba de estrés se utilizó la “Apache JMeter”, el cual es un
componente puede ser descargado en la página apache.
Esta herramienta permite la creación de planes de pruebas añadiendo varias
posibilidades, alguna de ellas descritas a continuación que fueron necesarias para hacer
las pruebas:
Thread Group: Permite definir los usuarios y el ciclo de concurrencia.
HTTP Request Defaults: Parámetros básicos de la url donde está el API.
HTTP Request: Definición completa del método que vamos a invocar en el API.
Listeners, View Results in Table: Permite visualizar los resultados en una tabla
Ilustración 43
Autoría Propia
50
2.5.3. Resultados obtenidos
Ilustración 44
Autoría propia
2.5.4 Conclusiones de pruebas
Durante las pruebas de rendimiento vemos un incremento progresivo y sostenido
en el tiempo de atención de las peticiones el cual es aún mayor cuando existe un alto
nivel de concurrencia.
Se debe tener en cuenta el ambiente en el cual se ejecutaron las pruebas, ya que la
configuración con la cual se cuenta es de un equipo de uso cotidiano y no tiene las
características de un servidor web de alta concurrencia. De acuerdo con lo anterior, los
datos en un ambiente real pueden ser aún más bajos.
Datos Peticiones Concurrencia Tiempo
5000 1 1 29.136
5000 5 2 32.265
5000 10 4 34.075
5000 30 10 44.506
5000 50 20 51.816
10000 1 1 60.537
10000 5 2 59.699
10000 10 4 69.568
10000 30 10 123.63
10000 50 20 176.489
30000 1 1 178.085
30000 5 2 248.084
30000 10 4 267.658
30000 30 10 390.365
30000 50 20 433.353
51
3. Cierre de la investigación
3.1 Resultados alcanzados
Terminada la fase de ejecución y cumplir con los requerimientos funcionales y no
funcionales planteados en la fase de análisis y diseño, se listan los siguientes aspectos que
fueron resultados de llevar a cabo el desarrollo del software planteado:
1. El utilizar la información de datos públicos abiertos, permitió demostrar la
fiabilidad de una aplicación web al momento de procesar un alto volumen de
información.
2. Cuando son más de 300 mil datos el sistema en el cual se encuentra alojada la
aplicación puede comenzar a fallar por falta de memoria para procesar la
aplicación. Al encontrarse con esto, se añadió la posibilidad de importar datos a
través de consola y el resultado es la importación de más de 1 millón de datos.
3. Respecto al punto anterior, es importante contar con los recursos de máquina
suficientes que permitan el procesamiento de un mayor número de datos.
4. La importación de registros mediante la agrupación, permite a la aplicación
realizar consultas segmentadas para la obtención de datos optimizando un mejor
aprovechamiento de los recursos.
5. MongoDB como gestor de base de datos noSQL, es robusto y muy estable para
gestionar los CRUD de una aplicación web.
6. Una de las grandes ventajas de la base de datos, es que nos permite añadir
diferentes longitudes de información según se requiera en cada registro realizado.
3.2 Conclusiones
Los datos públicos abiertos son un recurso importante para utilizar en diferentes
ámbitos como la inteligencia de negocios o medición de comportamiento de personas o
solicitudes de servicio por ubicaciones, zonas y tipos más comunes.
Al organizar y catalogar la información en tablas y elementos gráficos permiten un
análisis más claro y detallado. Los datos que se presentan inicialmente como texto puro e
inicialmente sin sentido. Se puede llegar a toda esta información, para tomar decisiones o
generar estrategias sociales.
El objetivo general fue cumplido en su totalidad, al demostrarse que es posible
desarrollar un software web CRUD para el análisis y gestión de altos volúmenes de
información sin generar altos costos de infraestructura para su procesamiento y
almacenamiento.
52
3.3 Trabajos de investigación futuros
Esta investigación puede profundizarse un poco más, desde uno de los siguientes
aspectos: 1. Comparativa funcional entre bases de datos relacionales y no relacionales.
2. Niveles de rendimiento entre base de datos relacionales y no relacionales.
3. Permitir generar reportes de análisis de información desde una fuente de datos con
origen diferente al formato JSON inicial.
Cualquiera de los anteriores puntos, puede llevar a cabo un mejor entendimiento
del rendimiento y alcance de un motor de base de datos no relacional, frente a uno
relacional.
ANEXOS
Formato seguimiento proyecto
Oficio de advertencia Software
Formato de aprobación de proyecto
Artículo de proyecto de grado
53
Bibliografía
Amazon Web Services. (2017 de Abril de 15). Obtenido de
https://aws.amazon.com/es/nosql/
Chodorow, K. (2013). Mongo DB The Definitive Guide. New York: O'Reilly Media.
DBig Cloud. (15 de Abril de 2017). Obtenido de Daniel Romero Sanchez:
http://www.dbigcloud.com/bigdata/75-bases-de-datos-nosql.html
Inc, M. (15 de Abril de 2017). Obtenido de
https://docs.mongodb.com/manual/reference/database-references/
Kovacs, K. (14 de Abril de 2017). Obtenido de https://kkovacs.eu/cassandra-vs-
mongodb-vs-couchdb-vs-redis
Nosql Database. (14 de Abril de 2017). Obtenido de http://nosql-database.org/
OpenData, N. (30 de 09 de 2017). NYC OpenData. Obtenido de NYC OpenData:
https://nycopendata.socrata.com/Social-Services/311-Service-Requests-from-
2010-to-Present/erm2-nwe9
Pramod J. Sadalage, M. F. (2013). NoSQL Distilled. Indiana: Pearson Education, Inc.
Slagter , R., Doest, H., Lacob, M.-E., Lankhorst, M., & Leeuwen, D. (2004). Viewpoints
Functionality and Examples. Portugal.
Software, E. (17 de Enero de 2016). Evaluando Software. Obtenido de Evaluando
Software: http://www.evaluandosoftware.com/ranking-bases-datos-las-10-mas-
grandes/
Sullivan, D. (2015). No SQL For Mere Mortals. Michigan: Pearson Education, Inc.