Ver discusiones, estadísticas y perfiles de autor de esta publicación en: https://www.researchgate.

net/publication/261079289

Una comparación de rendimiento de bases de datos SQL y NoSQL

Documento de sesión · Agosto 2013

DOI: 10.1109 / PACRIM.2013.6625441

CITACIONES LEE

63 5795

2 autores , incluso:

Yishan Li

Universidad de Auckland

1 PUBLICACIÓN 63 CITACIONES

VER EL PERFIL

Todo el contenido de esta página siguiente fue subido por Yishan Li el 21 de noviembre de 2015.

El usuario ha solicitado la mejora del archivo descargado.

 Una comparación de rendimiento de SQL y NoSQL
bases de datos
Yishan Li y Sathiamoorthy Manoharan
Departamento de Ciencias de la Computación
Universidad de Auckland
Nueva Zelanda
Abstracto -Con el énfasis actual en “Big Data”, NoSQL
bases de datos han aumentado en popularidad. Estas bases de datos son reclamados para un
mejor desempeño que las bases de datos SQL. En este trabajo se puede investigar de forma
independiente el desempeño de algunas bases de datos NoSQL y SQL a la luz de las tiendas
de valores clave. Comparamos leer, escribir, borrar y crear una instancia de operaciones
sobre tiendas de valores clave implementadas por las bases de datos NoSQL y SQL. Además,
también investigamos una operación adicional: iteración a través de todas las claves. Un
marco par clave-valor abstracto que apoya estas operaciones básicas se diseña e implementa
utilizando todas las bases de datos analizadas. Los resultados experimentales miden el
tiempo de estas operaciones y resumimos nuestros hallazgos sobre cómo las bases de datos
se apilan uno contra el otro. Nuestros resultados muestran que no todas las bases de datos
NoSQL se desempeñan mejor que las bases de datos SQL. Algunos son mucho peores. Y
para cada base de datos, el rendimiento varía con cada operación. Algunos son lentos para
crear una instancia, pero rápido de leer, escribir y borrar. Otros son rápidos para crear una
instancia pero lento en las otras operaciones. Y hay poca correlación entre el rendimiento y el
modelo de datos utiliza cada base de datos.
Palabras Clave: el rendimiento de base de datos, SQL, bases de datos NoSQL.
I. INTRODUCCIÓN
Los sistemas de bases de datos para el almacenamiento tradicionales se han basado en el
modelo relacional. Estos son ampliamente conocidos como bases de datos SQL con nombres
de la lengua que se les preguntó por [1]. En los últimos años, sin embargo, las bases de datos
no relacionales han aumentado drásticamente en popularidad. Estas bases de datos son
comúnmente conocidos como bases de datos NoSQL, marcando claramente diferentes de las
bases de datos SQL tradicionales. La mayoría de ellos se basan en el almacenamiento de
pares de valores clave simples en la premisa de que la simplicidad lleva a la velocidad.
Con el aumento de la accesibilidad de Internet y la disponibilidad de almacenamiento
barato, enormes cantidades de datos estructurados, semi-estructuradas, no
estructuradas y son capturados y almacenados para una variedad de aplicaciones. Tales
datos se refieren comúnmente como Big Data [ 2]. Procesamiento tal gran cantidad de
datos requiere velocidad, esquemas flexibles, y (es decir noncentralized) bases de datos
distribuidas. bases de datos NoSQL se convirtió en la moneda preferida para el
funcionamiento de grandes volúmenes de datos que pretenden satisfacer estos
requisitos. Esto también conduce a un aumento en el número de ofertas de bases de
datos NoSQL. Existen varias implementaciones de código abierto comercial y de bases
de datos NoSQL (tales como BigTable [3] y HBase [4]).
El gran número de ofertas NoSQL conduce a preguntas sobre las
diferencias entre estas ofertas y su idoneidad en aplicaciones particulares. Una
serie de documentos de la encuesta
15
(Tal como el de Tudorica y Bucur [5] o Han et al. [6]), por tanto, se han
publicado para abordar algunas de estas cuestiones. Además, hay varios
recursos en línea y blogs que abordan estos aspectos también.
El enfoque de nuestro trabajo es comparar las implementaciones de las tiendas de valores
clave en las bases de datos NoSQL y SQL. Mientras que las bases de datos NoSQL se diseñan
generalmente para las tiendas KEYVALUE optimizados, bases de datos SQL no lo son. Sin
embargo, nuestros hallazgos sugieren que no todas las bases de datos NoSQL se desempeñan
mejor que las bases de datos SQL. Comparamos leer, escribir, borrar y crear una instancia de
operaciones en el almacenamiento de claves-valor. Observamos que incluso dentro de las bases
de datos NoSQL existe una amplia variación en el rendimiento de estas operaciones. También se
observa poca correlación entre el rendimiento y el modelo de datos utiliza cada base de datos.
El resto del trabajo se organiza como sigue. Sección II presenta una selección
de bases de datos NoSQL. En la sección III revisiones relacionadas trabajo. En
particular, se ve en otras encuestas que comparan las ofertas NoSQL. Sección IV
se analizan nuestra configuración experimental y lo evaluamos. Sección V presenta
y discute los resultados experimentales. La última sección concluye con un
resumen.
II. norte O SQL D ATABASES
Se cree ampliamente que BigTable de Google [3] fue la primera de las bases de
datos NoSQL. BigTable se basa en tres claves: en primer lugar que es llamado la
tecla fila, segunda columna llamada la clave, y la tercera es la marca de tiempo. Esto
es efectivamente un mapa multidimensional. llaves de columna pueden ser fi
clasificarse en grupos. Un grupo se accede como una sola unidad.
El éxito de las bases de datos no relacionales propietarios tales como BigTable y
Dynamo de Amazon [7] inició una serie de otros desarrollos de código abierto y de
código cerrado de bases de datos no relacionales. Estas bases de datos NoSQL
creció en popularidad debido a la facilidad de acceso, velocidad y escalabilidad.
La mayor parte de las bases de datos NoSQL están basadas en el almacenamiento de pares
KeyValue. Es posible que los valores podrían ser un conjunto de claves secundarias que a su vez
contienen valores.
Un tipo especial de una base de datos par clave-valor es una base de datos
columnfamily. Este se compone de columnas y columnas, súper direccionable con llaves.
A grupos de columnas súper un número de columnas relacionadas y se accede como una
sola unidad.
El otro tipo especial de base de datos par clave-valor es una base de datos
documental. bases de datos orientadas a documentos ir más allá de los valores simples y
tienen la capacidad de almacenar objetos. los
978-1-4799-1501-9 / 13 / $ 31.00 © 2013 IEEE
los objetos son de alguna forma serializada tales como XML, JSON, y BSON (binario
codificado JSON).
En este trabajo nos fijamos en una selección de bases de datos NoSQL en la vista
de compararlos unos contra otros y contra Microsoft SQL. El resto de esta sección se
describen brevemente las bases de datos NoSQL que hemos seleccionado para la
comparación.
MongoDB 1 es una base de datos documental escrito en C ++ [8]. Los objetos
se almacenan serializado como BSON. Los objetos no necesitan tener la misma
estructura o fi campos y los campos comunes fi no necesita tener el mismo tipo, lo
que permite un almacenamiento esquema flexible. MongoDB soporta
auto-sharding donde se reparte las colecciones de datos y almacena las
particiones a través de servidores disponibles. Esto se traduce en una carga
dinámicamente equilibrado.
Hypertable 2 es una fuente abierta de bases de datos NoSQL basado en BigTable de
Google [3]. Se trata de una base de datos de la columna familiar y está escrito en C ++. Al
igual que MongoDB, Hypertable también soporta auto-sharding.
Apache CouchDB es una base de datos documental escrito en Erlang [9]. Los
objetos se almacenan serializado como JSON. Se accede a la base de datos a
través de un API HTTP RESTful. Por lo tanto, CouchDB se afirma que es una “base
de datos que abarca por completo la web” 3.
Apache Cassandra 4 es una base de datos de la columna familiar y fue desarrollado
originalmente por Facebook [10]. Algunas de sus características principales son las siguientes de
descentralización para reducir los fallos y replicación de datos para aumentar la tolerancia a fallos.
RavenDB 5 y Couchbase 6 son otras dos bases de datos documentoriented
consideramos [11]. Al igual que MongoDB y CouchDB, estos también ofrecen un
almacenamiento esquema flexible y el uso de JSON como formato de los objetos
serializados. También ofrecen replicación de datos y sharding.
III. R EXALTADO W TRABAJO
Mientras que las bases de datos NoSQL tienen la ventaja de velocidad y escalabilidad,
hay una serie de inconvenientes en comparación con bases de datos relacionales
tradicionales. Leavitt enumera estos desafíos [12]. Señala que las bases de datos NoSQL,
aunque rápido para tareas sencillas, requieren mucho tiempo para operaciones complejas.
Además de las consultas para operaciones complejas pueden ser difíciles de formar. El otro
inconveniente es la falta de soporte nativo para la consistencia. Leavitt también señala que
NoSQL es una tecnología que muchas organizaciones están aún por aprender y hay una
falta de apoyo y de gestión de herramientas para ayudar.
Bartolomé da una introducción de aprendizaje a la historia y las diferencias
entre las bases de datos SQL y NoSQL [13]. Sakr y col. discutir soluciones de
gestión de datos, incluyendo NoSQL, para las plataformas basadas en la nube [14].
Discuten las soluciones de gestión de datos se enfrentan a desafíos a la luz de la
nube.
1 www.mongodb.org
2 www.hypertable.com
3 couchdb.apache.org
4 cassandra.apache.org
5 ravendb.net
6 www.couchbase.com
dieciséis
Tiwari ofrece un amplio tratado sobre las bases de datos NoSQL [15]. Se cubre la
historia, lógica, capacidad de programación, arquitectura de almacenamiento y
rendimiento de ajuste de algunas de las implementaciones. También toma nota de la
siguiente como la base de la comparación de las implementaciones.
∙ escalabilidad
∙ Consistencia
∙ Soporte para modelos de datos
∙ El apoyo a las consultas y
∙ Herramientas administrativas
Del mismo modo, Indrawan-Santiago toma nota de la siguiente como la base de
comparación: modelo de datos, modelo de transacción, el apoyo a consultas ad-hoc,
indexación, shrading, y el tipo de licencia [16]. Ella compara diez implementaciones
NoSQL incluyendo Cassandra, HBase, Dynamo, MongoDB y CouchDB sobre esta
base. Ella también compara cualitativamente bases de datos relacionales de bases de
datos NoSQL, y concluye que es probable NoSQL para complementar bases de datos
relacionales y mejorar las capacidades de mejorar la gestión de bases de una
organización.
Hecht y Jablonski proporcionan una encuesta orientada caso de uso de bases de
datos NoSQL [17]. Identifican las di fi cultades en la elección de una base de datos
NoSQL para encajar un caso de uso particular y, por tanto, centran su papel para
abordar esta cuestión. Utilizan como base para su comparación del modelo de datos,
soporte para consultas, partición, replicación y controles de concurrencia. Comparan
este punto de vista catorce bases de datos NoSQL, incluyendo MongoDB, CouchDB,
Cassandra y HBase.
Boicea et al. comparar una base de datos NoSQL contra una base de datos
SQL. Ellos eligen Oracle para la aplicación SQL y MongoDB para la ejecución
NoSQL [18]. Ellos informan de que, con un gran número de registros, el tiempo de
inserción es un factor más en Oracle y actualizar y borrar los horarios son varios
los factores más en Oracle.
Yahoo! Nube Benchmark porción es una herramienta de generación de carga de trabajo de fuente
abierta para la comparación de las tiendas de valores clave [19].
Nuestra contribución en este documento es una versión práctica en la comparación de las
bases de datos. Esto está basado en algunas de las operaciones fundamentales que
llevamos a cabo en las bases de datos. Describimos estas operaciones en la siguiente
sección.
No comparamos detalles arquitectónicos como los modelos soportados de datos, la
coherencia, la tolerancia a fallos, etc. Estos detalles están bien cubiertos en otras
revisiones [15], [16], [17].
IV. mi Xperimental F ARCO
Nuestra comparación de los databasese implica cuatro operaciones fundamentales:
1) una instancia. Esto crea la instancia de un cubo de almacenamiento para los pares KeyValue.
2) Leer. Esto lee el valor correspondiente a una clave dada desde el
almacenamiento de par clave-valor. Este es el mismo que el
Leer funcionamiento del CRUD (crear, leer, actualizar, eliminar) el modelo comúnmente
utilizado para describir las operaciones de base de datos clave de bases de datos.
3). Si no se encuentra un par clave-valor dado en el almacenamiento, entonces el par se
añade a la de almacenamiento. De otra manera,
 se actualiza el valor de la clave dada en el almacenamiento. Por lo tanto,
1800

esta operación combina Crear y Actualizar

1600
operaciones del modelo CRUD.
4) Eliminar. Esto elimina el registro (es decir, par clave-valor) correspondiente a una 1400

clave dada desde el almacenamiento de par clave-valor. Este es el mismo que

1200

el Borrar funcionamiento del modelo CRUD.

tiempo ge (ms)
1000

Averag
Además de las operaciones fundamentales anteriores, hay dos operaciones 800
800

complementarias que son comúnmente usados: iteración a través de todas las claves y 600

iterar a través de todos los valores. Para activar la prueba de estos, que el tiempo una vez
400
más la operación: GetAllkeys
el cual va a buscar todas las claves de la strorage. Tenga en cuenta que, en la práctica, 200

esta operación sólo se puede devolver un número fi cado de llaves (en lugar de todos) 0
MongoDB RavenDB CouchDB Cassandra Hypertable couchbase SQL
cuando hay un gran número de pares de valores clave en el almacenamiento.
Base de datos

Fig. 2. Tiempo para instanciar cubo de base de datos (ms)

clase pública abstracta KeyValueStoreBase
{
public bool abstracta instanciar ( cuerda bucketName);
cadena pública abstracta Leer( cuerda llave); Tenga en cuenta que los tiempos se promedian en cinco carreras. Los valores de tiempo
public bool abstracta Escribir( cuerda llave, cuerda valor);
public void abstracta Borrar( cuerda llave);
absolutos no son significativos; lo que es significativo es los valores de tiempo respecto a la

otra.
pública abstracta lista < string> GetAllKeys ();
} Observamos que RavenDB, Hyertable, MongoDB ofrecen la creación más rápida de
los cubos de bases de datos. CouchDB, Couchbase y SQL Express se encuentran entre
La Fig. 1. Las operaciones de base sobre tiendas de clave-valor los más lentos para crear cubos.
Nuestro segundo experimento mide el tiempo necesario para leer los valores
Nuestros experimentos miden el desempeño de estas cinco operaciones para las bases de correspondientes a las claves dadas desde el cubo. La Tabla II resume el resultado.
datos seleccionadas. La Figura 1 resume las operaciones como una clase abstracta. Nos

especializamos esta abstracción para cada base de datos que se está probando. En las tablas, el número de operaciones se refiere al número de veces que una
operación determinada (tal como leer) se ejecuta en la prueba. Esto también es igual al
Tenga en cuenta que hay operaciones avanzadas que las bases de datos de apoyo función número de pares de valores clave (es decir, registros) en la tienda.
de su tipo (por ejemplo, un objeto o la manipulación de la columna). Nosotros no probamos

estos en este documento.

Número de operaciones
Base de datos
Base de datos Versión 10 50 100 1000 10000 100000

MongoDB 1.8.5 MongoDB 8 14 23 138 1085 10201

RavenDB 960 RavenDB 140 351 539 4730 47459 426505

CouchDB 1.2.0 CouchDB 23 101 196 1819 19508 176098

Cassandra 1.1.2 Cassandra 115 230 354 2385 19758 228096

Hypertable 0.9.6 Hypertable 60 83 103 420 3427 63036

couchbase 1.8.0 couchbase 15 22 23 86 811 7244

Microsoft SQL Server Express 10.50.1600.1 MS SQL Express 13 23 46 277 1968 17214

TABLA I TABLA II T IME DE

V Ersion DETALLE DE BASE DE DATOS IMPLEMENTACIONES LECTURA (MS)

La Tabla I ilustra el detalle versión de las implementaciones de bases de datos que se
experimentaron con en este documento. Para cada una de estas bases de datos, corremos el
funcionamiento escogida (lectura o escritura) y cinco veces hemos tomamos el tiempo
promedio.
El conjunto de datos para el experimento son pares de valores clave generados
automáticamente que son de la forma ( • •, • •) dónde • es un número de secuencia.
Ordenado por el desempeño de lectura tenemos la lista de bases de datos:
Couchbase, MongoDB, SQL Express, Hypertable, CouchDB, Cassandra y RavenDB.
De éstos Cassandra y Hypertable son bases de datos de la columna a la familia; y
Couchbase, MongoDB, CouchDB, y RavenDB son bases de datos orientadas a
documentos. No existe una correlación observable entre el modelo de datos y el
rendimiento. También vemos que el rendimiento de lectura de SQL Express es mejor
que algunos, pero no todos, de las bases de datos NoSQL.

V. R RESULTADOS Y mi VALUACIÓN

Nuestro primer experimento mide el tiempo necesario para crear instancias de un cubo de Nuestro tercer experimento mide el tiempo necesario para escribir pares
base de datos. Véase la Figura 2, que resume los resultados de este experimento. KEYVALUE a la cubeta. Si el par clave-valor ya existe en el balde, esto equivale
a la actualización del valor existente.

17
 Número de teclas para ir a buscar 10
De lo contrario, equivale a la adición de la par clave-valor para el cubo. La Base de datos
50 100 1000 10000 100000
Tabla III resume el resultado. MongoDB 4 4 5 19 98 702
RavenDB 101 113 115 116 136 591
Número de operaciones CouchDB 67 196 19 173 1063 9512
Base de datos
10 50 100 1000 10000 100000 Cassandra 47 50 55 76 237 709
MongoDB 61 75 84 387 2693 23354 Hypertable 3 3 3 5 25 159
RavenDB 570 898 1213 6939 71343 740450 MS SQL Express 4 4 4 4 11 76
CouchDB 90 374 616 6211 67216 932038
TABLA V
Cassandra 117 160 212 1200 9801 88197
T IME para traer todas las teclas (MS)
Hypertable 55 90 10938 114872 184 1035
couchbase 60 76 63 142 936 8492
MS SQL Express 30 94 129 1790 15588 216479 TABLA III T IME

para la escritura (MS)

Obtención de todos los valores podría llevar una cantidad de tiempo similar a ir a buscar todas las

claves, siempre y cuando los valores son de tamaño pequeño (es decir comparabable al tamaño de

las teclas).

Ordenado por el rendimiento de escritura tenemos la lista de bases de datos:

VI. S RESUMEN Y do CONCLUSIÓN
Couchbase, MongoDB, Cassandra, Hypertable, SQL Express, RavenDB y CouchDB.
Vemos que el rendimiento de escritura de RavenDB y CouchDB es peor que la de Este trabajo compara las implementaciones del almacén de clave y valor en las bases de

SQL Express. Pero otras bases de datos NoSQL se desempeñan mejor que SQL datos NoSQL y SQL. Mientras que las bases de datos NoSQL se optimizan generalmente para

Express. las tiendas de valor clave, bases de datos SQL no lo son. Sin embargo, se encuentra que no

Nuestro cuarto experimento mide el tiempo necesario para eliminar pares de todas las bases de datos NoSQL un mejor desempeño que la base de datos SQL que

valores clave de la cubeta. Tabla IV resume el resultado. probamos. Observamos que incluso dentro de las bases de datos NoSQL existe una amplia

variación en el rendimiento basado en el tipo de operación (por ejemplo, leer y escribir).

También se observa poca correlación entre el rendimiento y el modelo de datos utiliza cada
Número de operaciones
Base de datos base de datos.
10 50 100 1000 10000 100000

MongoDB 4 15 29 235 2115 18688

RavenDB 90 499 809 8342 87562 799409 De las bases de datos NoSQL RavenDB y CouchDB no se desempeñan bien en la
CouchDB 71 260 597 5945 67952 705684 lectura, escritura y borrado de operaciones. Casandra es lento en operaciones de
Cassandra 33 95 130 1061 9230 83694
lectura, pero es razonablemente bueno para escribir y borrar operaciones. Couchbase y
Hypertable 19 63 110 1001 10324 130858
couchbase 6 12 14 81 805 7634 MongoDB son los dos global más rápido para leer, escribir y borrar operaciones.
MS SQL Express 11 32 57 360 3571 32741 Couchbase, sin embargo, no es compatible con ir a buscar todas las teclas (o valores).
TABLA IV T IME para borrar Si iteración a través de claves y valores no se requiere para una aplicación, entonces
(MS)
Couchbase será una buena opción. De lo contrario se puede elegir MongoDB que viene
el segundo cercano a Couchbase en el de lectura, escritura y eliminación de
operaciones.
Ordenado por el rendimiento de eliminación tenemos la lista de bases de datos:
Couchbase, MongoDB, SQL Express, Cassandra, Hypertable, CouchDB y RavenDB. Tenga en cuenta que no hemos probado las bases de datos para operaciones más complejas.
Vemos que el rendimiento de eliminación de SQL Express es mejor que la de todas las Las clasificaciones de bases de datos que notamos no podrán ejercer cuando se trata de
bases de datos NoSQL pero Couchbase y MongoDB. operaciones complejas.

Al igual que cualquier software de aplicación, las implementaciones NoSQL pasan

Boicea et al. informó que, por 100000 registros, el tiempo de inserción es un
factor más en Oracle que en MongoDB y actualizar y borrar los horarios son
varios los factores más en Oracle [18]. No se observó tan grandes las diferencias
de resultados entre MongoDB 7 y SQL Express en nuestros experimentos aquí.
Nuestro experimento final mide el tiempo necesario para traer todas las claves
en el cubo. La Tabla V resume el resultado.
A excepción de CouchDB, todas las bases de datos son rápidos a buscar las llaves. SQL
Express fue el más rápido de todos. Couchbase tiene ninguna API para soportar ir a buscar
todas las llaves, por lo que este fue excluido en el experimento.
por cambios y por lo tanto mejoras de rendimiento y degradaciones son propensos a
pasar por estos cambios. En consecuencia, uno tendrá que comparar bases de datos no
sólo en la etapa de diseño de la aplicación, sino también a intervalos regulares para
permitir el cambio a la aplicación de base de datos más adecuado. los procesos de
desarrollo de software con gradas ayudarían a aislar el back-end de base de datos para
facilitar dicha conmutación cuando se considere necesario.
R EFERENCIAS

[1] K. Kline, SQL en una cáscara de nuez, 3ª ed. O'Reilly Media, noviembre de 2008. [2] P. Guardián, Glosario

Tenga en cuenta que ir a buscar todas las llaves es considerablemente más rápido que los
valores de leer uno tras otro. Esta diferencia es, obviamente, debido a la sobrecarga de conexión
de base de datos.
7 Boicea et al. no incluía las versiones de las bases de datos analizadas, y por lo tanto nosotros no
sabemos si por lo tanto, nuestra versión de MongoDB es diferente a la de ellos o no.
grande de datos. O'Reilly Media, septiembre de 2011. [3] F. Chang, J. Dean, S. Ghemawat, WC
Hsieh, DA Wallach, M. Bur-
filas, T. Chandra, A. Fikes, y RE Gruber, “Bigtable: un sistema de almacenamiento distribuido
para datos estructurados”, en Actas del Simposio USENIX séptimo en los sistemas operativos
Diseño e Implementación - Volumen
7, Ser. '06 IESO. Berkeley, CA, EE.UU.: Asociación USENIX 2006, pp 15-15.. [4] L. George, HBase:
La Guía de fi nitivo. O'Reilly Media, agosto de 2011.

18
 [5] B. Tudorica y C. Bucur, “Una comparación entre varios NoSQL
bases de datos con comentarios y notas “, en RoEduNet Conferencia Internacional (RoEduNet),
2011 10a, junio de 2011, pp. 1 -5. [6] J. Han, E. Haihong, G. Le, y J. Du, “Encuesta sobre la base de
datos NoSQL,” en
Pervasive Computing y Aplicaciones (ICPCA), 2011 6ª Conferencia Internacional sobre, oct.
2011, pp. 363 -366.
[7] G. Decandia, D. Hastorun, M. Jampani, G. Kakulapati, A. Lakshman,
A. Pilchin, S. Sivasubramanian, P. Vosshall, y W. Vogel, “Dynamo: alta disponibilidad almacén
de claves-valor del Amazonas” SIGOPS Oper. Syst. Rdo.,
vol. 41, no. 6, pp. 205-220, octubre de 2007. [8] K. Chodorow y M. Dirolf, MongoDB: De La
guía definitivo. O'Reilly
Medios de comunicación, septiembre de 2010.

[9] JC Anderson, J. Lehnardt, y N. Slater, CouchDB: la de fi nitivo

Guía. O'Reilly Media, enero de 2010. [10] E. Hewitt, Cassandra: La Guía de fi nitivo. O'Reilly
Media, noviem-
ber 2010. [11] M. Brown, Introducción a Couchbase servidor. O'Reilly Media,

Junio ​2012.
[12] N. Leavitt, “¿Será bases de datos NoSQL la altura de su promesa?” Computadora,
vol. 43, no. 2, pp. 12 -14, feb. 2010. [13] D. Bartolomé, “SQL vs NoSQL” Diario de Linux, no.
195, de julio de 2010. [14] S. Sakr, A. Liu, D. Batista, y M. Alomari, “Un estudio de gran escala

la gestión de datos en entornos de nube se acerca” Las encuestas de comunicaciones tutoriales,

IEEE, vol. 13, no. 3, pp. 311-336, 2011. [15] S. Tiwari, NoSQL profesional. Wiley / Wrox, agosto de 2011.
[16] M. Indrawan-Santiago, “la investigación de base de datos: ¿Estamos en una encrucijada?

La reflexión sobre NoSQL,”en Red basada en Sistemas de Información (NBI), 2012 15ª
Conferencia Internacional sobre, sept. 2012, pp. 45 -51. [17] R. Hecht y S. Jablonski, “evaluación
NoSQL: Un caso de uso orientada
encuesta,”en Cloud y Servicio de Informática (CSC), 2011 Conferencia Internacional sobre, dic.
2011, pp. 336 -341.
[18] A. Boicea, F. Radulescu, y LI Agapin, “MongoDB vs Oracle -
la comparación de bases de datos “, en Emergente inteligente de datos y tecnologías web (EIDWT),
2012 Tercera Conferencia Internacional sobre, sept. 2012, pp. 330 -335.

[19] BF Cooper, A. Silberstein, E. Tam, R. Ramakrishnan, y R. Sears,

“Evaluación comparativa de nube que sirve sistemas con ycsb,” en Actas de la primera Simposio
ACM sobre computación en nube, Ser. SOCC '10. ACM, 2010, pp. 143-154.

19

Ver las
estadísticas
estadísticas
de la
depublicación
publicación