Impact analysis and measurement of
reliability and time in the migration of SQL databases to Nosql.
Patricio
Navas Moya.[1], Tatiana Mayorga Soria.[2],
Santiago Viteri Arias.[3] & Carlos Casa Guayta
[4]=
The present investigation shows a previous analysi=
s to
the migration of data between relational database engines and a No SQL. To
carry out this article, a financial application was developed as a scenario=
in
which migration would be more notable to investigate the limitations and
advantages of a comparative way in the basic operations of a database. The
impact analysis will focus on the actual financial application since it han=
dles
large amounts of data using a relational database, migrating it to a
non-relational database; additionally, the impact produced in terms of
administration capacity, instruction execution times and execution in machi=
nes
with few resources will be analyzed.
The application is developed in Visual Studio, the
relational database used will be MySql and the
migration will be done in Apache Cassandra, as far as measurements are
concerned, the help of Visual Studio instructions will be used to capture t=
he
execution time, at the end, identifying advantages and disadvantages of the
same application with a relational and non-relational database; it will be
possible to determine the best option in terms of database for a financial
application with large amounts of data.
Keywords: Migration, D=
atabases, Sql, Nosql
La presente investigación muestr=
a un
análisis previo a la migración de datos entre motores de bases de datos
relacional y un No SQL. Para llevar a cabo este artículo se desarrolló una
aplicación financiera como escenario en el cual la migración sería más nota=
ble
para investigar las limitaciones y ventajas de una manera comparativa en las
operaciones básicas de una base de datos. Se enfocará el análisis de impact=
o en
la aplicación financiera real ya que maneja grandes cantidades de datos
utilizando una base de datos relacional, migrándola hacia una base de datos=
no
relacional; adicionalmente se analizará el impacto producido en cuanto a la
capacidad de administración, tiempos de ejecución de instrucciones y ejecuc=
ión
en máquinas con pocos recursos.
La aplicación es desarrollada en
Visual Studio, la base de datos relacional utilizada será MySql
y la migración se la realizará en Apache Cassandra,
en lo que respecta a las mediciones se utilizará la ayuda de las instruccio=
nes
de Visual Studio para capturar el tiempo de ejecución, al finalizar,
identificando ventajas y desventajas de la misma aplicación con base de dat=
os
relacional y no relacional; se logrará determinar la mejor opción en cuanto=
a
base de datos para una aplicación financiera con grandes cantidades de dato=
s.
Palabras Claves=
: Migración, Bases De Datos, Sql, Nosql
Introducción .
El bien más importante que tiene
toda organización es la información, y para esto se debe tener actualizado
donde se lo va a almacenar para garantizar la integridad de la misma, para
lograr este objetivo se requiere procesar y almacenar grandes cantidades de
datos de forma rápida y eficiente por lo que las bases de datos necesitan e=
star
en constante evolución. [1]La demanda de alto rendimiento e=
n la
lectura y escritura, hace que las bases de datos relacionales enfrenten muc=
hos
nuevos desafíos. Utilizar la base de datos relacional para almacenar y
consultar datos de usuario dinámicas ha resultado ser insuficiente.<=
!--[if supportFields]>ADDIN CSL_CITATION
{"citationItems":[{"id":"ITEM-1","itemDa=
ta":{"ISBN":"9788560031368","author":[{&=
quot;dropping-particle":"","family":"Ag"=
,"given":"Siemens","non-dropping-particle":&q=
uot;","parse-names":false,"suffix":""}],=
"container-title":"Micro","id":"ITEM-1&q=
uot;,"issued":{"date-parts":[["2009"]]},"=
;page":"17-28","title":"Sistemas
para","type":"article-journal","volume":=
"13"},"uris":["http://www.mendeley.com/documents/?=
uuid=3D7d22f779-ce53-4f80-a693-43ccb39810a6"]}],"mendeley":{=
"formattedCitation":"[1]","plainTextFormattedCitat=
ion":"[1]","previouslyFormattedCitation":"[1]=
"},"properties":{"noteIndex":0},"schema"=
:"https://github.com/citation-style-language/schema/raw/master/csl-cit=
ation.json"}[1]
El almacenamiento de históricos =
se
ha realizado desde tiempo atrás, fundamentalmente con tecnologías de bases =
de
datos relacionales, sin embargo, el modelo relacional introduce limitantes
derivadas de su propia concepción que coadyuvan a un comportamiento inefici=
ente
cuando los sistemas crecen, que se manifiesta con la reducción significativa
del rendimiento y la disponibilidad para la gestión de series de tiempo. [2]
Los sistemas que manejan grandes
cantidades de datos deben seguir características como escalabilidad,
fiabilidad, durabilidad, tiempo de respuesta, interfaz de consulta, estruct=
ura
de los datos almacenados (o carencia de la misma) y esquemas de
particionamiento de datos.[2]
La demanda de los usuarios y la
llegada de nuevas tecnologías que impulsan el uso de las tecnologías NoSQL;=
con
millones de usuarios requiriendo sistemas completos, pero sobre todo veloce=
s,
que principalmente realizan en almacenamientos y búsqueda de la información,
hace necesario un paradigma de bases de datos orientado a la velocidad.[3][4]
Una base de datos es un conjunto=
de
información estructurada en registros y almacenada es un soporte electrónico
legible desde un ordenador. Cada registro constituye una unidad autónoma de
información que puede estar a su vez estructurada en diferentes campos o ti=
pos
de datos que se recogen en dicha base de datos. [5][6]
El almacenamiento de datos se ha
venido desarrollando de manera convencional por bases de datos relacionales
desde 1970 Edgar Fram Codd, las bases de datos
relacionales son una colección de datos almacenados en forma de tablas
relacionadas.[7]
Modelo
relacional.
Es un modelo de organización y
gestión de bases de datos el cual tiene como premisa el almacenamiento de d=
atos
en tablas compuestas por filas y columnas tipo hojas de cálculos, las filas=
que
son conocidas como tuplas y las columnas o campos. [5]
Se distingue de otros modelos por
ser más comprensible que cualquier otro, se basa en la lógica de predicados
para establecer relaciones entre distintos datos, en la actualidad es una
solución para la creciente variedad de los datos. [5][8]
MySql.
Es un sistema gestor de bases de
datos relacional (RDBMS, Sistemas Gestores de Bases de Datos Relacional) de
código abierto, el cual su base fundamental es el lenguaje de consultas
estructurado (SQL). Entre las características más importantes es que se eje=
cuta
en todas las plataformas incluyendo Windows, Linux y Unix, tiene muchas
cualidades, a las que suman la facilidad para desarrollo de aplicaciones de
escritorio, pero lo más relevante son las aplicaciones web, en la cual se
potencia con herramientas como Apache que es el servidor web.[3][9]
Originalmente Mysql
fue desarrollado en la compańía sueca MySQL AB, pero en el ańo 2008 fue
adquirida por Oracle, sin embargo, los desarrolladores pueden seguir utiliz=
ando
el MySQL bajo la Licencia Pública General (GPL),[3] pero las empresas deben adquiri=
r la
licencia comercial a Oracle.[10] Una vez que el código de MySQL =
es
privativo aparecieron los conocidos hijos o llamados también como FORKS, en=
los
que se incluyen a Drizzle cuyo código abierto s=
e baso en MySQL 6.0. MariaDB que es
el considerado reemplazo popular drop-in
desarrollado en la comunidad MySQL el mismo que utiliza las API y los comandos de MySQL.[9]
EL Percona<=
/span>
Server XtraDB que es una versión mejorada de My=
SQL
conocido por su escalabilidad horizontal.
Modelo
no relacional o Bases de datos NoSQL.
Son bases de datos no relacional=
es
para información o datos sin esquemas y que por sus características su
desempeńo es escalable, particularmente son conocidas por la facilidad en el
desarrollo baja latencia y su alta fiabilidad. Utilizan una variedad de mod=
elos
de datos, como los almacenes de valor clave en memorias de gráficos de
documentos y columnas en fin todo lo que tiene que ver con datos documental=
es. [7][11][12]
Los sistemas de bases de datos de
este tipo son las más comunes en aplicaciones web y para app móviles que
requieren de gran almacenamiento y que sean eficientes a la respuesta, son =
más
fáciles de escalar que una base de datos SQL.[3]
Cassandra.
Es una b=
ase
de datos NoSQL de alto rendimiento, tolerante a fallos y escalable, tiene la
característica denominada Column-Family. Cassandra combina los beneficios de Google Bigtable y Amazon Dynamo =
que esto
no ocurre en las bases de datos relacionales.[3][10]
Este Mot=
or
de bases de datos se lo puede encontrar en algunas empresas tales como: Cis=
co, Rackspace, Netflix, Twitter, Urban Airship,
entre otras.[4]
Características.
Esta diseńada para el almacenamiento=
de
una gran cantidad de datos estructurados y esta albergado dentro del
licenciamiento de Apache. Tiene la propiedad de escalar tanto linealmente c=
omo
elásticamente. El mejor rendimiento se obtiene conforme se aumentan los nod=
os
en los clusters. Como cualquier base de datos s=
oporta
la propiedad ACID(Atomicidad, Aislamiento,
Consistencia, Aislamiento, Durabilidad) y tiene una velocidad de ingreso de
información altamente rápido. Soporta una fácil de distribución de datos
mediante replicado a través de varios centros de datos. Fue desarrollado en
Java, el cluster más grande que se tiene en
estadística tiene 300TB de datos distribuidos en unas 400 máquinas.<=
!--[if supportFields]>ADDIN CSL_CITATION {"citationItems":[{=
"id":"ITEM-1","itemData":{"DOI":&qu=
ot;10.1109/SSPS.2017.8071648","ISBN":"9781509049295&quo=
t;,"author":[{"dropping-particle":"","fa=
mily":"Giridhara
Gopalan","given":"M.","non-dropping-particle&=
quot;:"","parse-names":false,"suffix":"&=
quot;},{"dropping-particle":"","family":"=
;Prasanna","given":"C.","non-dropping-particl=
e":"","parse-names":false,"suffix":"=
;"},{"dropping-particle":"","family":&qu=
ot;Srihari
Krishna","given":"Y.","non-dropping-particle&=
quot;:"","parse-names":false,"suffix":"&=
quot;},{"dropping-particle":"","family":"=
;Shanthini","given":"B.","non-dropping-partic=
le":"","parse-names":false,"suffix":&quo=
t;"},{"dropping-particle":"","family":&q=
uot;Arulkumar","given":"A.","non-dropping-par=
ticle":"","parse-names":false,"suffix":&=
quot;"}],"container-title":"Proceedings
of 2017 3rd IEEE International Conference on Sensing, Signal Processing and
Security, ICSSS
2017","id":"ITEM-1","issued":{"date=
-parts":[["2017"]]},"page":"503-508",&qu=
ot;title":"MYSQL
to cassandra conversion
engine","type":"article-journal"},"uris"=
:["http://www.mendeley.com/documents/?uuid=3D8a271a29-dd65-4b66-9fa5-2=
2d60f6a8875"]}],"mendeley":{"formattedCitation":&q=
uot;[3]","plainTextFormattedCitation":"[3]","=
previouslyFormattedCitation":"[3]"},"properties":{=
"noteIndex":0},"schema":"https://github.com/citati=
on-style-language/schema/raw/master/csl-citation.json"}[3][4]
Relacional vs. NoSQL.El modelo relacional permite tener una gran cantidad de ta=
blas
y poder interrelacionar entre ellas de tal manera que puedan acceder a la
información mucho más rápido, mientras que en las NoSQL no se puede hacer ya
que es solo un documento.
El modelo
NoSQL permita una escalabilidad horizontal y elástica mientras que en el
relacional esto es más rígido ya que crece en registros y serian de forma
vertical.
Para una adecuada interpretación de resultados se
plantea una serie de pruebas de rendimiento entre los dos motores de bases =
de
datos y como estos pueden responder a las operaciones previo a la migración=
de
la información. Se desarrollo dos aplicaciones en Visual Studio, con la
finalidad de medir el tiempo de respuesta en cada una de las bases de datos=
, de
igual manera se planteo 3 veces para un distinto
tamańo.
Se propone la inserción y con=
sukta
de de un conjunto de datos que fueron en este o=
rden
500, 1000, y 1500 registros que para el caso de Cassan=
dra
se lo tomo como columnas/documentos, y se midió el promedio del tiempo de
ejecución para cada caso plateado.
Para la realización de las operaciones de consulta=
en
las bases de datos de MySQL se tomo en cuenta l=
os
siguientes campos:
Id_cliente,
id_direccion, numer_cuenta, id_estado, id_tipo_cuenta, id_transaccion,
id_tipo_transaccion.
Para la base de datos de Cass=
andra
se tomó en cuenta los siguientes atributos:
Ids
y los índices: tipotransaccion e idcuenta
para la tabla de controltransaccion.
Primero prueba se realizó la =
inserccion
de datos, para la cual se tomó un conjunto de 500, 1.000 y 5.000
columnas/documentos, después se utilizó un comando apropiado para insertar =
en
una base de datos vacía, después se tomó el tiempo de cuanto se demoró la
operación, estas operaciones se repitieron 3 veces y al final se promediaron
los 3 tiempos resultantes.
Para la prueba en Mysql, se
utilizó en siguiente comando para insertar datos:
|
INSERT INTO (`cliente` (`ID_CLIENTE`,
`CEDULA_CLIENTE`, `ID_DIRECCION`, `NOMBRES_CLIENTE`, `APELLIDOS_CLIENTE`)
VALUES (1, '1693042073999', 34, 'Anne', 'Gilmo=
re'),(..),(..),
.,(..); |
Tabla 1. Resultados de la operación de inserción en Mys=
ql
|
Tiempo en Segundos |
||||
|
Registros |
Prueba
1 |
Prueba
2 |
Prueba
3 |
Promedio |
|
500 |
6.324 |
5.969 |
6.112 |
6,135 |
|
1000 |
12.158 |
11.947 |
11.785 |
11,963 |
|
5000 |
45.857 |
43.941 |
46.194 |
45,336 |
Elaborado
por: Grupo de Investigación.
La
tabla 1 muestra el tiempo resultante en segundos de las 3 pruebas, incluyen=
do
el promedio final de la operación de insertar registros en MySQL.
Figura 1. Pantalla de inserción de datos en Mysql
Elaborado
por: Grupo de Investigación.
Para
el ingreso de información en la base de datos de Mysql=
se realizó un front end en
Visual Studio el cual ayudo en medir los tiempos en milisegundos ya que la
propia base de datos no tenía esa propiedad.
Para
la prueba en Cassandra se debió ejecutar el com=
ando
de inserción uno por uno, se utilizó el siguiente comando para insertar dat=
os
ejecutados desde la aplicación:
|
=
=
session.Execute("INSERT
INTO controlcuenta (idcuenta, estadocuenta,tipocuenta=
,idcliente,saldocuenta,detallecuenta)
VALUES(200, true, 'debito', 199, 1.74, 'ultrices. Vivamus rhoncus. Donec
est.); |
Tabla 2. Resultados de la operación inserción en Cassandra.
|
Tiempo en Segundos |
||||
|
Registros |
Prueba
1 |
Prueba
2 |
Prueba
3 |
Promedio |
|
500 |
2.005 |
2.010 |
2.047 |
2.05 |
|
1000 |
4.265 |
4.456 |
4.624 |
4.448 |
|
5000 |
23.534 |
23.113 |
22.846 |
23.164 |
Elaborado
por: Grupo de Investigación.
En
la tabla 2 se obtuvo el tiempo resultante en segundos de las 3 pruebas
planteadas incluyendo el promedio final de la operación de insertar en Cassandra.
=
Figura 2=
.
Comandos para consultas de inserción en Cassandra.
Elaborado
por: Grupo de Investigación.
En
la figura anterior muestra la secuencia de ingreso de datos en la consola d=
e Cassandra, para cumplir con lo propuesto dentro de la
investigación planteada-
Para
las operaciones de inserción los resultados se muestran en la Figura 1. Exi=
ste
una gran diferencia en tiempos promedio entre las dos bases de datos, por lo
tanto, los resultados obtenidos favorecieron a Cassand=
ra.
=
Figura 3=
.
Resultado de las pruebas de inserción
Elaborado
por: Grupo de Investigación.
En
la segunda prueba se realizó la función de consultar, para la cual se tomar=
on
los mismos datos ya insertados en la primera prueba.
Para
la prueba en Mysql, se utilizó en siguiente com=
ando
para consultar datos:
|
SELECT C.ID_CLIENTE,C.CEDULA_CLIENTE, CONCAT( C=
ONCAT(C.NOMBRES_CLIENTE,'
'), C.APELLIDOS_CLIENTE) AS CLIENTE, CONCAT( C=
ONCAT(D.CIUDAD_DIRECCION,'
- '), D.PROVINCIA_DIRECCION) AS DIRECCION,D.TELEFONO1_DIRECCION AS
TELEFONO1,D.TELEFONO2_DIRECCION AS TELEFONO2 FROM
CLIENTE C,DIRECCION D WHERE
C.ID_DIRECCION=3DD.ID_DIRECCION
order by C.ID_CLIENTE; |
Tabla 3. Resultados de la operación de MySQL
|
=
Registros |
|
|
<=
b>500 |
<=
span
lang=3DES-US style=3D'font-size:12.0pt;line-height:115%;font-family:"Time=
s New Roman",serif;
mso-fareast-font-family:Calibri;mso-fareast-theme-font:minor-latin;
mso-ansi-language:ES-US;mso-fareast-language:EN-US'>0.0035 |
|
|
0.0048 |
|
<=
b>5000 |
<=
span
lang=3DES-US style=3D'font-size:12.0pt;line-height:115%;font-family:"Time=
s New Roman",serif;
mso-fareast-font-family:Calibri;mso-fareast-theme-font:minor-latin;
mso-ansi-language:ES-US;mso-fareast-language:EN-US'>0.0080 |
Elaborado
por: Grupo de Investigación.
En
la tabla 3 se puede observar la consulta de los registros que para este caso
los tiempos estuvieron dados en milisegundos, por lo que se requiere de una
alternativa de medición.
Para
la prueba en Cassandra, se utilizó en siguiente
comando para consultar datos:
|
RowS=
et
result =3D session.Execute("select * from controlprin limit 500"=
;); |
Usando =
este
código con la cláusula (limit ) la base de datos únicamente nos devuelve el limite de resultados establecidos Tabla 4=
.
Resultados de la operación consultar en Cassandra Registros Tiempo 500 0.001=
5 1000 0.0015 5000 0.006=
3 Elaborado
por: Grupo de Investigación. En la t=
able
anterior muestra los tiempos que muestra el motor de C=
assandra
que de igual manera esta dado en milisegundos notándose que son mucho más b=
ajos
que con los de MySQL lo que sugiere mayor y mejor eficiencia. . Elaborado
por: Grupo de Investigación. Como
se puede observar en la figura anterior los tiempos son muy eficientes, pero
siempre la base de datos NoSQL son mucho mejores por lo que se puede conclu=
ir
que siempre serán mejores que las relacionales. En
la tercera prueba se realizó la función de consultar en la tabla de
transacciones que es la que contiene más campos, para la cual se tomaron los
mismos datos ya insertados en la primera prueba. Es decir que tendremos 5000
registros originalmente, pero para el caso del experimento vamos a proceder=
en el
mismo orden de inserción lo que concluirá con 500, 1000 y 5000 registros en
MySQL y los mismos valores, pero con columnas/documentos en Cassandra
se realizó una consulta. Para
la prueba en Mysql, se utilizó en siguiente com=
ando
para actualizar datos: SELECT * FROM TRANSACCION; Tabla
5.
Resultados de la operación consulta transacciones en MySQL Registros Tiempo 500 0.0060 1000 0.0120 5000 0.0376 Elaborado
por: Grupo de Investigación. La
tabla anterior muestra los tiempos resultantes en segundos en la operación =
de
verificar todos los registros que fueron ingresados, y que son bajos para e=
l número
de atributos que tienen y el tipo de datos del mismo. Para
la prueba en Cassandra, se utilizó en siguiente
comando para actualizar datos: RowS=
et
result =3D session.Execute("select * from controltransaccion limit
500"); =
Tabla 6=
. Resultados de la operación consulta de transacci=
ones
en Cassandra Registros Tiempo 500 0.0015 1000 0.0020 5000 0.0070 Elaborado
por: Grupo de Investigación. Los
resultados al igual que en las operaciones anteriores muestran ser muy bajos
pero lo que más llama la atención es que guarda relación de acuerdo al núme=
ro
de registros que se tienen dentro de las bases de datos. =
Figura 5.
Resultados de la consulta de transacciones Elaborado
por: Grupo de Investigación. Para las
operaciones de consulta de las transacciones los resultados se muestran en =
la
Figura anterior. Existe una gran diferencia en tiempos promedio entre las d=
os
bases de datos, por lo tanto, los resultados obtenidos favorecieron a Cassandra. De
forma general los resultados de todas las operaciones planteadas previa a u=
na
migración sugieren que Cassandra es más rápido =
que Mysql, tanto para consultas de inserción y consulta de
datos. Estos resultados fueron razonables, ya que estas pruebas se realizac=
ión
en un computador sin mayor prestación como un servidor, se tomó en cuenta a=
un
computador de escritorio Core i7 con 8Gb de memoria RAM y un disco duro de =
1Tb . Conclusiones.<=
o:p> ˇ&nb=
sp;
En este trabajo se analizó la diferencia de respue=
sta
que ofrece una base de datos Sql a una noSql =
,
cuando se las usa en una aplicación, debido a que comúnmente las aplicacion=
es
se las realiza únicamente con bases d=
e dato=
s Sql. ˇ&nb=
sp;
En las consultas realizadas, los tiempos de respue=
sta
hacia la aplicación que se registraron demuestran claramente que Cassandra(noSql) al tener=
un
código más simplificado realiza las consultas mucho más rápido que Mysql(=
Sql). ˇ&nb=
sp;
En el caso de codificación en la aplicación,
igualmente Cassandra presenta un código menor
respecto al código necesario para poder conectar la aplicación con la base =
de
datos. ˇ&nb=
sp;
En conclusión, Cassandra
demostró que una base de datos noSql es más efi=
ciente
con respecto a tiempos de respuesta y líneas de código en una aplicación, a
diferencia de una base de datos Sql. Referencias
bibliográficas. S. Ag, Sistemas para, Micro, vol. 13, pp. 1728,
2009. A.
C. Romero, J. S. G. Sanabria, and M. C. Cuervo, Utilidad y funcionamiento =
de
las bases de datos NoSQL, Rev. Fac. Ing. UPTC, vol. 21, no. 33, pp. 2132, 201=
2. M. Giridhara Gopalan, C. Prasanna=
, Y.
Srihari Krishna, B. Shanthini, and A. Arulkumar, MYSQL to cassandra conver=
sion
engine, Proc. 2017 3rd IEEE Int. Conf. Sensing, Signal Process. Secur.
ICSSS 2017, pp. 503508, 2017. D. J. Dean, P. Wang, X. Gu, W. En=
ck,
and G. Jin, Automatic server hang bug diagnosis: Feasible reality or pipe
dream?, Proc. - IEEE Int. Conf. Auton. Comput. ICAC 2015, pp. 1271=
32,
2015. M. Franklin, A. Halevy, and D. Ma=
ier,
From Databases to Dataspaces: A New Abstraction for Information Management=
, ACM
SIGMOD Rec., vol. 34, no. 4, pp. 2733, 2005. D. Ramakanth and K. Vinod, SQL
Injection - Database Attack Revolution And Prevention, J. Int. Commer. =
Law
Technol., vol. 6, no. 4, pp. 224231, 2011. Y. Li and S. Manoharan, A
performance comparison of SQL and NoSQL databases, IEEE Pacific RIM Con=
f. Commun. Comput. Signal Process. - Proc., no. August 2013, pp. 1519, 2013. C.
A. L. Pena, Análisis De Las Bases De Datos Nosql Como Alternativa a Las Ba=
ses
De Datos Sql, p. 58, 2012. D. J. Dean, H. Nguyen, P. Wang, X.
Gu, A. Sailer, and A. Kochut, PerfCompass: Online Performance Anomaly Fault
Localization and Inference in Infrastructure-as-a-Service Clouds, IEEE
Trans. Parallel Distrib. Syst., vol. 27, no. 6, pp. 17421755, 2016. T. D. Le et al., EPC
information services with No-SQL datastore for the Internet of hings, 2=
014
IEEE Int. Conf. RFID, IEEE RFID
2014, pp. 4754, 2014. A.
Rodríguez Pérez, D. Rodríguez Hernández, and E. Elizabeth Martínez, Selecc=
ión
de base de datos NoSQL para almacenamiento de históricos en sistemas de
supervisión, Rev. Cuba. Ciencias Informáticas, vol. 10, no. 3, pp.
8597, 2016. A.
C. M. Antańo, J. M. M. Castro, and R. E. C. Valencia, Migracion de Bases de
Datos SQL a NoSQL, Rev. Tlamati, vol. Especial 3, no. February 2015,
pp. 144148, 2014. =
Para
citar el artículo indexado. Navas P., Mayo=
rga
T., Viteri S. & Casa C. . (2018).
Análisis de impacto y medición de confiabilidad y tiempo en la migra=
ción
de bases de datos Sql a No=
sql.
Revista electrónica Ciencia Digital=
2(3),
74-87. Recuperado desde: http://cienciadigital.org/revistacienciadigita=
l2/index.php/CienciaDigital/article/view/138/123 El
artículo que se publica es de exclusiva responsabilidad de los autores y no
necesariamente reflejan el pensamiento de la Revista Ciencia Digital. El
articulo queda en propiedad de la revista y, por tanto, su publicación parc=
ial
y/o total en otro medio tiene que ser autorizado por el director de la Revista Ciencia Digital.
[1]
Universidad de las Fuerzas Armadas ESPE, Cotopaxi, Ecuador,
mpnavas@espe.edu.ec
[2]
Universidad de las Fuerzas Armadas ESPE, Cotopaxi, Ecuador,
ptmayorga@espe.edu.ec
[3]
Universidad de las Fuerzas Armadas ESPE, Cotopaxi , Ecuador,
csviteri1@espe.edu.ec
www.cienciadigital.org
Vol. 2, N°3, p. 74=
-87,
Julio - Septiembre, 2018