UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGIA

DIRECCIÓN DE POSGRADO

“USO DE MÚLTIPLES BASES DE DATOS

NOSQL PARA SISTEMAS DE GRAN
DEMANDA”

TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO

DE DIPLOMADO EXPERTO EN DESARROLLO DE APLICACIONES
EMPRESARIALES VERSIÓN II

POSTULANTE : DANIEL VILLEGAS VELIZ

TUTOR : MSc. JUAN MARCELO CLAURE SALINAS

Cochabamba – Bolivia
2019
 Dedicatoria

A Dios por bendecirme la vida, por guiarme a lo largo

de mi existencia, ser el apoyo fortaleza en aquellos

momentos de dificultad y debilidad.

A mis Padres Jose Dario y Juanita Fernanda por ser

los principales promotores de mi sueño, por confiar y

creer en mis expectativas, por los consejos, valores y

principios que me inculcaron.

II
 ÍNDICE DE CONTENIDO

RESUMEN 6

INTRODUCCIÓN 7

1 GENERALIDADES 8

1.1 Antecedentes Generales 8

1.2 Antecedentes Específicos 8

2 METODOLOGÍA 9

3 TEOREMA CAP 9

3.1 Consistencia 9

3.2 Disponibilidad 9

3.3 Tolerancia al particionado de red 10

4 BASE DE DATOS A GRAN ESCALA (BIG DATA) 10

5 BASE DE DATOS NOSQL 11

5.1 Redis 14

5.1.1 Comandos clave y valor 15

5.1.2 Estructura de datos 16

5.1.2.1 Cadenas de Texto 16

5.1.2.2 Hashes 17

5.1.2.3 Listas 18
 5.1.2.4 Conjuntos 19

5.1.2.5 Conjuntos Ordenados 20

5.2 MongoDB 20

5.2.1 Base De Datos De Documentos 21

5.2.2 Características clave de MongoDB 22

5.2.2.1 Alto Rendimiento 22

5.2.2.2 Lenguaje de consulta enriquecido 22

5.2.2.3 Escalabilidad Horizontal 22

5.2.3 Estructura y Modelado de MongoDB 23

5.2.3.1 Esquema Flexible 23

5.2.3.2 Estructura del Documento 23

5.2.3.3 Datos incrustados 23

5.2.3.4 Referencias 24

5.2.3.5 Atomicidad de Documento único 25

5.2.3.6 Transacciones Multi-Documento 25

5.2.3.7 Uso de datos y rendimiento 25

5.2.3.8 Relaciones 26

5.3 Cassandra 29

5.3.1 No hay ni un solo punto de fallo 30

5.3.2 Un Hashing distribuido 30

4
 5.3.3 Interfaz de cliente relativamente fácil de usar 30

5.3.4 Otras características de disponibilidad 30

5.3.4.1 Consistencia 31

5.3.4.2 Acciones de lectura/escritura 31

5.3.5 Modelo de datos Cassandra 31

5.3.4 Base de datos distribuida 31

6 CONCLUSIONES 35

7 BIBLIOGRAFÍA 37

5
RESUMEN

En el pasado, se utilizaron bases de datos relacionales debido a su rico conjunto de

características, capacidades de consulta y gestión de transacciones en muchas aplicaciones. Sin
embargo, no son capaces de almacenar y procesar datos de gran eficacia y no son muy eficientes
para realizar transacciones y unirse a las operaciones. Recientemente, emerge un nuevo
paradigma, bases de datos NoSQL, para superar algunos de estos problemas, que son más
convenientes para el uso en entornos web.

Debido a la tendencia actual del uso masivo de internet, los datos de almacenamiento fueron
creciendo exponencialmente, las bases de datos relacionales experimentaron problemas, que
impiden el buen funcionamiento de los sistemas de algunas de las empresas más importantes de
Internet. Estos datos que son masivamente generados reciben el nombre: BigData,

Palabras clave: Base de datos, Repositorio, SQL, NoSQL, Redis, MongoDB, Cassandra.

6
INTRODUCCIÓN

Las bases de datos NoSQL surgen como una necesidad para el manejo y procesamiento de datos
con una escalabilidad horizontal en las aplicaciones, es decir, la necesidad de mejorar el
rendimiento mediante la adición de nuevos nodos computacionales a los ya existentes, para las
cuales, son útiles cuando se trabaja con una gran cantidad de datos, cuando la naturaleza de los
datos no requiere un modelo relacional.

Al principio del nuevo milenio, los desarrolladores comenzaron a darse cuenta de que sus datos
no encajaban en el modelo relacional y algunos de ellos comenzaron a desarrollar otras
arquitecturas para almacenar grandes cantidades de datos, por lo cual, a la hora de elegir una
base de datos hoy en día, el problema más complejo, es decidir la mejor arquitectura para el
almacenamiento de datos y recuperación de datos.

En la actualidad existen muchos sistemas que poseen inmensas cantidades de datos con
millones de transacciones al día contra la base de datos, por lo cual, si hablamos de bases de
datos NoSQL, existen gran variedad de estas que se clasifican según su forma de almacenar los
datos, y comprenden categorías como clave-valor, base de datos documentales, y bases de datos
orientados a grafos.

Pero el problema principal que encontramos hoy en día, es que, aunque todas se denominan
NoSQL, no sabemos cuál escoger para crear una aplicación adecuada que cumpla con las
expectativas de los clientes.

Por lo tanto, el propósito de este estudio es usar Redis para el manejo de sesión ya que Redis
es una base de datos en memoria. Es mucho más rápido acceder a la información en memoria
que en disco, MongoDB para el manejo de catálogos ya que MongoDB trabaja con información
que no tiene una estructura definida y los datos son cambiantes, Cassandra para hacer data
analytics ya que Apache Cassandra no tiene un punto de fallo, siempre está en funcionamiento
si un nodo falla otro nodo lo reemplaza. Más adelante realizare la explicación de cada una de
estos BDMS.

7
1 GENERALIDADES

1.1 Antecedentes Generales

No todas las aplicaciones necesitan almacenar y procesar datos de la misma manera, la

arquitectura de almacenamiento debería pensarse de forma acorde a las necesidades.

Si se pretende desarrollar una aplicación que requiera la lectura/escritura de millones de datos y

pueda brindar servicios a millones de usuarios sin perder rendimiento (escalabilidad), entonces
debe plantearse el uso de bases de datos NoSQL. El termino NoSQL se refiere al procesamiento
de información en bases de datos que intentan solventar las limitaciones que el modelo relacional
encuentra en entornos de almacenamiento masivo de datos, y concretamente al momento de
escalar, donde es necesario disponer de servidores de alto performance y de balanceo de carga
(Soumendra, Madhu, & Harsha, pág. 14).

1.2 Antecedentes Específicos

El problema de la escalabilidad de SQL fue reconocido por empresas Web 2.0. con grandes
necesidades de datos e infraestructura, como Google, Amazon y Facebook.

Ellos solos tuvieron que buscar soluciones propias a este problema, con tecnologías como
BigTable, DynamoDB, y Cassandra.

El interés creciente dio lugar a una serie de sistemas de gestión de base de datos NoSQL
(DBMS), con un enfoque en el rendimiento, la fiabilidad y la coherencia. Se reutilizaron y
mejoraron varias estructuras de indexación existentes con el propósito de mejorar la búsqueda y
el rendimiento de lectura.

En primer lugar, había tipos de bases de datos NoSQL (de origen cerrado), desarrolladas por
grandes empresas para satisfacer sus necesidades específicas, como BigTable de Google, que
se cree es el primer sistema NoSQL y DynamoDB de Amazon.

El existo de estos sistemas patentados, inicio el desarrollo de bases de datos de código abierto
y de propietarios similares siendo los más populares Hypertable, Cassandra, MongoDB, HBase,
Redis.

8
2 METODOLOGÍA

Para el presente trabajo se utilizarán los siguientes métodos de investigación:

 Método Bibliográfico, debido a que se realizara la lectura y compilación de libros

relacionados al tema de estudio.
 Método Analítico, debido a que se procederá a revisar y analizar ordenadamente
documentos relacionados al tema de estudio, para la redacción del presente trabajo.

3 TEOREMA CAP

El teorema CAP aplica en ambientes altamente distribuidos, el primero en referenciarlo fue el

profesor Eric A. Brewer, quien en el año 2000 en un simposio del ACM sobre principios de la
computación distribuida, explico que cuando se trata de diseñar y despliegue de aplicaciones en
entornos distribuidos solo podremos garantizar 2 de los siguientes 3 requerimientos:

3.1 Consistencia

Todos los nodos deben garantizar la misma información al mismo tiempo, si insertamos datos
(todos los nodos deben insertar los mismos datos), si actualizamos datos (todos los nodos deben
aplicar la misma actualización a todos los nodos) y si consultamos datos (todos los nodos
devolverán los mismos datos).

Para tal efecto la comunicación entre los nodos debe ser de suma importancia, podríamos, por
ejemplo, emitir confirmación de inserción de un dato, una vez dicho dato se grabó en todos los
nodos de nuestra replica.

3.2 Disponibilidad

Independientemente si uno de los nodos se ha caído o dejado de emitir respuestas, el sistema

debe seguir en funcionamiento y aceptar peticiones tanto de escritura como lectura. Una vez se
pierde comunicación con un nodo, el sistema automáticamente debe tener la capacidad de seguir
operando mientras este se restablece y una vez lo hace, se debe sincronizar con los demás
nodos.

9
3.3 Tolerancia al particionado de red

El sistema debe estar disponible así existan problemas de comunicación entre los nodos, cortes
de red que dificulten su comunicación o cualquier otro aspecto que genere su particionamiento.
Por lo general los ambientes distribuidos están divididos geográficamente, donde es normal que
existan cortes de comunicación entre algunos nodos, por lo cual el sistema debe permitir seguir
funcionando, aunque existan fallas que dividan el sistema.

Lo que dice el teorema es que solo puedes garantizar dos de estos tres requerimientos.

CP (Consistencia y Tolerancia al particionamiento)

Esto quiere decir que no se garantiza la disponibilidad, hay clientes que requieren que el sistema
esté disponible 100% del tiempo o muy cerca, con bases de datos que cumplan con CP no es
posible garantizar esto, no quiero decir que no se pueda lograr en cierto nivel, pero el sistema
está enfocado en aplicar los cambios de forma consistente, aunque se pierda comunicación entre
nodos.

AP (Disponibilidad y Tolerancia al particionamiento)

En este caso no se garantiza que los datos sean iguales en todos los nodos todo el tiempo, en
este caso el sistema siempre estará disponible para las peticiones, aunque se pierda la
comunicación entre los nodos.

CA (Consistencia y Disponibilidad)

En este caso no se puede permitir el particionado de los datos, porque se garantiza que los datos
siempre son iguales y el sistema estará disponible respondiendo todas las peticiones.

4 BASE DE DATOS A GRAN ESCALA (BIG DATA)

La definición de Big Data varía según las características de las empresas. Para unas empresas
prima el volumen, para otras la velocidad, para otras la variabilidad de las fuentes. Las empresas
con mucho volumen van a estar interesadas en capturar la información, guardarla, actualizarla e
incorporarlo en sus procesos de negocios; pero hay empresas que, aunque tengan mucho
volumen, no necesitan almacenar, sino trabaja en tiempo real y a gran velocidad.

Una base de datos a gran escala o también llamada “masiva”, permite el almacenamiento y
manipulación de un orden alcanzable a petabytes de cualquier tipo de información diaria. El
crecimiento exponencial de información es directamente aplicable a estas bases de datos.
10
Por ejemplo, la consolidación de las redes sociales sumado a su utilización de forma diaria y
masiva por parte de sus millones de usuarios, llevan a tener que realizar modificaciones que
faciliten la administración de datos. (Soumendra, Madhu. Harsha).

5 BASE DE DATOS NOSQL

Pese a la no existencia de una definición formal, cuando hablamos de base de datos NoSQL,
también conocidas como “No Solo SQL”, nos referimos a una amplia clase de sistemas de gestión
de datos (mecanismos para el almacenamiento y recuperación de datos) que difieren, en
aspectos importantes, del mundo clásico de relaciones entre entidades (o tablas) existentes en
los sistemas de gestión de bases de datos relacionales, siendo el más destacado el que no usan
SQL como lenguaje principal de consulta.

Aunque son conocidas desde la década de los 60 del pasado siglo, su auge actual viene
determinado por el uso que, de 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
requería dar respuestas a la necesidad de proporcionar información procesada a partir de
grandes volúmenes de datos con unas estructuras horizontales, más o menos, similares y con
aplicaciones Web que debían dar respuesta a las peticiones de un número elevado e
indeterminado de usuarios en el menor tiempo posible. 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 este último al que las bases de datos relacionales tradicionales dedicaban una
gran cantidad de tiempo de proceso.

Las características comunes entre todas las implementaciones de bases de datos NoSQL suelen
ser las siguientes:

 Consistencia Eventual: A diferencia de las bases de datos relacionales tradicionales, en

la mayoría de sistemas NoSQL, no se implementan mecanismos rígidos de consistencia
que garanticen que cualquier cambio llevado a cabo en el sistema distribuido sea visto, al
mismo tiempo por todos los nodos y asegurando, también la no violación de posibles
restricciones de integridad de los datos u otras reglas definidas. En su lugar y para obtener
un mayor rendimiento, se ofrece el concepto de “consistencia eventual”, en el que los

11
 cambios realizados “con el tiempo” serán propagados a todos los nodos por lo que, una
consulta podría no devolver los últimos datos disponibles o proporcionar datos inexactos,
problema conocido como lecturas sucias u obsoletas. Asimismo, en algunos sistemas
NoSQL se pueden presentar perdidas de datos en escritura. Esto se conoce también
como BASE (Basically Available Soft-state Eventual Consistency), en contraposición a
ACID (Atomicity, Consistency, Isolation, Durability), su analogía en las bases de datos
relacionales.

 Flexibilidad en el esquema: En la mayoría de base de datos NoSQL, los esquemas de

datos son dinámicos; es decir, a diferencia de las bases de datos relacionales en las que,
la escritura de los datos debe adaptarse a unas estructuras(o tablas, compuestas a su vez
por filas y columnas) y tipos de datos pre-definidos, en los sistemas NoSQL, cada registro
(o documento, como se les suele llamar en estos casos) puede contener una información
con diferente forma cada vez, pudiendo así almacenar sólo los atributos que interesen en
cada uno de ellos, facilitando el polimorfismo de datos bajo una misma colección de
información. También se pueden almacenar estructuras complejas de datos en un sólo
documento, como por ejemplo almacenar la información sobre una publicación de un blog
(título, cuerpo de texto, autor, etc.) junto a los comentarios y etiquetas vertidos sobre el
mismo, todo en un único registro.

 Escalabilidad horizontal: Por escalabilidad horizontal se entiende la posibilidad de

incrementar el rendimiento del sistema añadiendo, simplemente, más nodos (servidores)
e indicando al sistema cuáles son los nodos disponibles.

 Estructura distribuida: Generalmente los datos se distribuyen, entre los diferentes nodos
que componen el sistema. Hay dos estilos de distribución de datos:
 Particionado (ó Sharding): El particionado distribuye los datos entre múltiples
servidores de forma que, cada servidor, actúe como única fuente de
un subconjunto de datos. Normalmente, a la hora de realizar esta distribución, se
utilizan mecanismos de tablas de hash distribuidas (DHT).
 Réplica: La réplica copia los datos entre múltiples servidores, de forma que cada
bit de datos pueda ser encontrado en múltiples lugares. Esta réplica puede
realizarse de dos maneras:

12
 o Réplica maestro-esclavo en la que un servidor gestiona la escritura de la
copia autorizada mientras que los esclavos se sincronizan con este
servidor maestro y sólo gestionan las lecturas.

o Réplica peer-to-peer en la que se permiten escrituras a cualquier nodo y

ellos se coordinan entre sí para sincronizar sus copias de los datos.

 Tolerancia a fallos y Redundancia: Pese a lo que cualquiera pueda pensar cuando se

habla de NoSQL, no todas las tecnologías existentes bajo este paraguas usan el mismo
modelo de datos ya que, al ser sistemas altamente especializados, la idoneidad particular
de una base de datos NoSQL dependerá del problema a resolver. Así a todo, podemos
agrupar los diferentes modelos de datos usados en sistemas NoSQL en cuatro grandes
categorías:

1. Base de datos de Documentos: Este tipo de base de datos almacena la información

como un documento, usando habitualmente para ello una estructura simple como JSON,
BSON o XML y donde se utiliza una clave única para cada registro. Este tipo de
implementación permite, además de realizar búsquedas por clave–valor, realizar
consultas más avanzadas sobre el contenido del documento. Son las bases de datos
NoSQL más versátiles.

2. Almacenamiento Clave-Valor: Son el modelo de base de datos NoSQL más

popular, además de ser la más sencilla en cuanto a funcionalidad. En este tipo de sistema,
cada elemento está identificado por una clave única, lo que permite la recuperación de la
información de forma muy rápida, información que suele almacenarse como un objeto
binario. Se caracterizan por ser muy eficientes tanto para las lecturas como para las
escrituras.

3. Bases de datos de grafos: Usadas para aquellos datos cuyas relaciones se pueden
representar adecuadamente mediante un grafo. Los datos se almacenan en estructuras
grafo con nodos (entidades), propiedades (información entre entidades) y líneas
(conexiones entre las entidades).

13
 4. Base de datos Columnar (o Columna ancha): En vez de “tablas”, en las bases de datos
de columna tenemos familias de columnas que, son los contenedores de las filas. A
diferencia de los RDBMS, no necesita conocer de antemano todas las columnas, cada fila
no tiene por qué tener el mismo número de columnas. Este tipo de bases de datos se
adecuan mejor a operaciones analíticas sobre grandes conjuntos de datos.

Pese a todas las opciones proporcionadas por el auge de las bases de datos NoSQL, esto no
significa la desaparición de las bases de datos de RDBMS ya que son tecnologías
complementarias. Estamos entrando en una era de persistencia políglota, una técnica que utiliza
diferentes tecnologías de almacenamiento de datos para manejar las diversas necesidades de
almacenamiento de datos.

5.1 Redis

Redis se describe a menudo como un almacén de calve-valor persistente en la memoria. No creo

que sea una descripción precisa. Redis mantiene todos los datos en la memoria (más sobre esto
en un momento), y los escribe en el disco para la persistencia, pero es mucho más que un simple
almacén de clave-valor. Es importante ir más allá de esta idea falsa, su perspectiva de Redis y
los problemas que solucione serán demasiados estrechos. La realidad es que Redis expone cinco
estructuras de datos diferentes, solo una de las cuales es una típica estructura de clave-valor.

Comprender estas cinco estructuras de datos, como funcionan, que métodos exponen y con que
se puede modelar.

La clave para entender a Redis. Si tuviéramos que aplicar este concepto de estructura de datos
al mundo relacional, podríamos decir que las bases de datos exponen una solo estructura de
datos tablas. Las mesas son complejas y flexibles. No hay mucho que no puedas modelar,
almacenar o manipular con mesas, sin embargo, su naturaleza genérica no esta extensa de
inconvenientes.

Específicamente, no todo es tan simple, o tan rápido, como debe ser. ¿Qué pasaría si, en lugar
de tener una estructura única para todos, utilizaríamos estructuras más especializadas? Ahí
podrían ser algunas cosas que podemos hacer (o almenos no podemos hacer muy bien), pero
seguramente ganaríamos en simplicidad y velocidad.

14
¿Usando estructuras de datos específicas para problemas específicos? ¿No es así como
codificamos? No usas una tabla hash (Estructura de datos) para cada pieza de datos, tampoco
utiliza una variable escalar. Para mí, eso define el enfoque de Redis. Si se trata de escalares,
listas, hashes, o sets, ¿Por qué no almacenarlo como escalares, listas, hashes y sets? Por qué
puede comprobar la existencia de uno, el valor puede ser más complejo que la llamada existente
(clave) o más lento que O (1) (búsqueda de tiempo constante que no se ralentizara)
independientemente de cuantos artículos hay.

Redis tiene el mismo concepto básico de una base de datos con la que ya está familiarizado. Una
base de datos contiene un conjunto de datos, el caso de uso típico de una base de datos es
agrupar todos los datos de una aplicación y mantenerlos separados de otras aplicaciones.

En Redis las bases de datos se identifican simplemente con un número siendo la base de datos
predeterminada.

5.1.1 Comandos clave y valor

Aunque Redis es más que un simple almacén de conjuntos clave-valor, en su núcleo, cada una
de las cinco estructuras de datos de Redis tiene al menos una clave y un valor. Es indispensable
que entendamos los conceptos de clave valor antes de continuar con el resto de elementos de
información.

Las claves son lo que vamos a utilizar para identificar conjuntos de datos. Vamos a tratar mucho
con claves, pero por ahora es suficiente con saber que una clave tiene un aspecto similar a
users:leto. Uno podría esperar razonablemente que una clave como esta contuviese información
sobre un usuario llamado leto. La coma no tiene ningún significado es especial, pero en lo relativo
a Redis, es utilizado como un separador común para organizar las claves.

Los valores representan los datos que se encuentran relacionados con la clave. Pueden ser
cualquier cosa. A veces almacenaras cadenas de texto, a veces numero enteros, a veces
almacenaras objetos serializados (como JSON, XML o cualquier otro formato). La mayor parte
de las veces Redis tratará los valores como arrays de bytes y no se preocupará de su tipo. Hay
que tener en cuenta que los distintos controladores gestionan la serialización de modos distintos
(algunos te dejaran a ti) de tal modo que solo hablaremos de cadenas de texto, numero enteros
y objetos JSON.

15
Ejemplo.

set users:leto “{name: leto, planet: dune, likes: [spice]}”

Esta es la anatomía básica de un comando Redis. En primer lugar, tenemos el comando a utilizar,
en este caso set. Después tenemos sus parámetros. El comando set recibe dos parámetros. La
clase sobre la cual establecemos el valor, el valor que estamos estableciendo. Muchos
comandos, aunque no todos reciben una clave (cuando lo hacen, es a menudo el primer
parámetro).

Recuperación de un valor: get users: leto

5.1.2 Estructura de datos

Los únicos elementos que hemos visto hasta ahora son comandos, claves y valores. Hasta ahora
no hemos concentrado nada acerca de la estructura de datos. Cuando empleábamos el comando
set, como sabia Redis que tipo de datos debería usar, cada comando es específico para cada
estructura de datos. Por ejemplo, cuando utilizas el comando set estas almacenando el valor en
una estructura de cadenas de texto. Cuando utilizas hset lo estas almacenando en una tabla
hash. Dado el pequeño tamaño del vocabulario de Redis, es muy manejable.

5.1.2.1 Cadenas de Texto

Las cadenas de texto son las estructuras de datos más básicas disponibles en Redis. Cuando
piensas en un par clave-valor estás pensando en cadenas de texto. Independientemente al
nombre de la clave, el valor puede ser cualquier cosa. Prefiero llamarlos “escalares”.

Ya hemos visto un caso de uso común de empleo de cadenas de texto, almacenando instancias
de objetos por clave.

Adicionalmente, Redis te permite realizar algunas operaciones comunes. Por ejemplo, se puede
utilizar strlen <key> para calcular la longitud del valor de la clave; getrange <key> <start> <end>
devuelve la subcadena de texto en el rango indicado; append <key> <value> añade el alor al final
del valor existente (o crea uno si no existe ninguno todavía). Probamos.

16
 Figura 1, Probando Redis

Fuente: (The Little Redis Book, by Karl Seguin)

No es importante entender cómo funciona los mapas de bits, o como Spool los utiliza, si no
entender que las cadenas de texto de Redis son más potentes de lo que pueden parecer a simple
vista. Una vez más, los casos de uso más comunes son los que comentamos anteriormente: el
almacenamiento de objetos y los contadores. Además, puesto que recuperar un valor a través de
su clave es tan rápido.

5.1.2.2 Hashes

los hashes son un buen ejemplo de por qué no es acertado decir que Redis es un almacén de
clave-valor. Como posiblemente sepas, en cierta manera, los hashes son como las cadenas de
texto. La diferencia más importante es que los hashes incluyen un nivel extra de indireccion: un
campo.

En este caso, los equivalentes en hash de set y get son:

Podemos dar valor a varios campos a la vez, obtener varios campos a la vez, recuperar todos los
campos y sus valores, mostrar todos los campos o borrar un campo especifico.

17
Como puedes ver los hashes nos dan algo más de control de lo que nos daban las cadenas de
texto. En lugar de almacenar un usuario como un valor serializado podemos almacenar un hash
con una representación más acertada. El beneficio que se obtiene de ellos es el poder acceder y
actualizar/borrar trozos concretos de datos sin tener que recuperar o escribir el valor entero.

Mirando los hashes desde la perspectiva de objetos bien definidos, como usuario, es primordial
entender cómo funcionan. Y es cierto que, por motivos de rendimiento, puede ser útil un control
con un grano más fino.

5.1.2.3 Listas

Las listas permiten almacenar y manipular un conjunto de valores dada una clave concreta. Puede
añadir a la lista, recuperar el primer o el ultimo valor y manipular valores de una posición concreta.
Las listas mantienen un orden y son eficientes al realizar operaciones basadas en su índice.
Podemos tener una lista llamada newusers en la que guardar los usuarios registrados más
recientemente en nuestra web.

En primer lugar, colocamos un nuevo usuario en el comienzo de la lista, después la truncamos

para que solo contenga los últimos 50 usuarios. Este patrón común. Ltrim es una operación con
una complejidad O(N), donde N es el número de valores que estamos eliminando. En este caso,
en el estamos truncando tras insertar un único elemento, se obtiene un rendimiento constante de
O (1) (porque N es siempre igual a 1).

Esta es además la primera vez que vamos a ver el valor de una clave referenciando el valor de
otra. Si queremos recuperar los detalles de los últimos 10 usuarios, podemos hacer la siguiente
combinación:

18
Por supuesto las listas son buenas únicamente para almacenar referencias a otras claves. Los
valores pueden ser cualquier cosa. Puedes usar listas para almacenar trazas de log o registrar el
camino que está siguiendo un usuario a través de una aplicación. Si estas construyendo un juego
puedes usarlo para registrar las acciones que realiza un usuario.

5.1.2.4 Conjuntos

Los conjuntos se emplean para almacenar valores únicos y facilitan un número de operaciones
útiles para tratar con ellos, como las uniones. Los conjuntos no mantienen orden, pero brindan
operaciones eficientes basándose en los valores. Una lista de amigos es el ejemplo clásico de
uso de conjuntos.

Independientemente de cuantos amigos tenga un usuario, podemos decidir eficientemente (O

(1)) cuando un usuario X es amigo de usuario Y o no.

Es más, podemos saber cuándo dos o más personas tienen los mismos amigos:

E incluso almacenar el resultado en una nueva clave:

Los conjuntos son muy buenos para etiquetar o registrar propiedades de un valor para los cuales
los duplicados no tengan sentido (o para aquellos escenarios en los que queramos realizar
operaciones como intersecciones o uniones).

19
5.1.2.5 Conjuntos Ordenados

La última y más poderosa estructura de datos son los conjuntos ordenados. Si los hashes son
como las cadenas de texto, pero con campos, entonces los conjuntos ordenados son como los
conjuntos, pero con una puntuación. La puntuación facilita la ordenación y la capacidad de
establecer un ranking. Si queremos tener una lista de amigos con ranking, podemos hacer:

¿Cómo encontramos cuantos amigos tiene duncan con una puntuación de 90 o más?

¿Cómo podemos saber cuál es el ranking de chani?

Utilizamos zrevrank en lugar de zrank porque la ordenación por defecto de Redis ordena de
menor a mayor valor (pero, en este caso, queremos ordenar de mayor a menor valor). El caso de
uso más obvio para los conjuntos ordenados son los sistemas de clasificación. En realidad,
cualquier cosa que quieras ordenar en base a un valor entero, que sea capaz de ser manipulable
eficientemente en base a su puntuación, puede encajar bien en un conjunto ordenado.

5.2 MongoDB

MongoDB (de la palabra en inglés “humongous” que significa enorme, gigantesco) es un sistema
de base de datos NoSQL orientado a documentos, desarrollado bajo el concepto de código
abierto.

MongoDB forma parte de la nueva familia de sistemas de base de datos NoSQL. En vez de
guardar los datos en tablas como lo hacen las bases de datos relacionales, MongoDB guarda
estructuras de datos en documentos tipo JSON con un esquema dinámico (MongoDB llama ese
formato BSON), haciendo que la integración de los datos en ciertas aplicaciones sea más fácil y
rápida.

MongoDB es un sistema de base de datos multiplataforma orientado a documentos, de esquema

libre, esto significa que cada entrada o registro tendrá un esquema de datos diferente, con
atributos o “columnas” que no tendrán que repetirse de un registro a otro. Está escrito en C++, lo
que confiere cierta cercanía a recursos de hardware de la máquina, de modo que es bastante
rápido a la hora de ejecutar sus tareas. Además, está licenciado como GNUAGPL 3.0, de modo

20
que se trata de un software de licencia libre. Funciona en sistemas operativos Windows, Linux,
OS X y Solaris.

MongoDB es un almacén de datos potente, flexible y escalable. Combina la habilidad de escalar

con muchas de las características más útiles de las bases de datos relacionales, como los índices
secundarios, consultas de rango y ordenación.

5.2.1 Base De Datos De Documentos

Un registro en MongoDB es un documento, que es una estructura de datos compuesta por pares
de campos y valores. Los documentos de MongoDB son similares a los objetos JSON. Los
valores de los campos pueden incluir otros documentos, matrices y matrices de documentos.

Figura 2, Documento BSON

Fuente: https://docs.mongodb.com/

Las ventajas de utilizar documentos son:

o Los documentos corresponden a tipos de datos nativos en muchos lenguajes de

programación.
o Los documentos y matrices incrustados reducen la necesidad de uniones costosas.
o El esquema dinámico soporta polimorfismo.

21
5.2.2 Características clave de MongoDB

5.2.2.1 Alto Rendimiento

MongoDB proporciona una persistencia de datos de alto rendimiento.

 La compatibilidad con los modelos de datos integrados reduce la actividad de
entrada y salida en el sistema de base de datos.
 Los índices admiten consultas más rápidas y pueden incluir claves de documentos
y matrices incrustadas.

5.2.2.2 Lenguaje de consulta enriquecido

Admite un rico lenguaje de consulta para realizar operaciones de lectura y escritura

(CRUD), así como:

 Agregación de datos
 Búsqueda de textos y consultas geoespaciales.

5.2.2.3 Escalabilidad Horizontal

Proporciona escalabilidad horizontal como parte de su funcionalidad principal:

 Sharding, distribuye datos a través de un grupo de maquinas
 A partir de la versión 3.4, admite la creación de zonas de datos basados en la clave
de fragmentos. En un grupo equilibrado, también dirige las lecturas y escrituras
cubiertas por una zona solo a aquellos fragmentos dentro de la zona.

Figura 3, Compartir datos entre fragmentos

Fuente: https://docs.mongodb.com/manual/
22
5.2.3 Estructura y Modelado de MongoDB

El desafío clave en el modelado de datos es equilibrar las necesidades de la aplicación, las

características de rendimiento del motor de bases de datos y los patrones de recuperación de
datos. Al añadir modelos de datos, siempre considere el uso de la aplicación de los datos (es
decir consultas, actualizaciones y procesamiento de los datos), así como la estructura inherente
de los mismos datos.

5.2.3.1 Esquema Flexible

A diferencia de las bases de datos SQL, donde se debe determinar y declarar el esquema de una
tabla antes de insertar los datos, las colecciones de MongoDB no requieren que sus documentos
tengan el mismo esquema, es decir:

 Los documentos en una sola colección no necesitan tener el mismo conjunto de campos
y el tipo de datos para un campo, puede diferir entre los documentos dentro de una
colección
 Para cambiar la estructura de los documentos en una colección, como agregar nuevos
campos, eliminar campos existentes o cambiar valores de los campos a un nuevo tipo los
Actualiza los documentos a la nueva estructura.

Esta flexibilidad facilita la asignación de documentos a una entidad o un objeto. Cada documento
puede coincidir con los campos de datos de la entidad representada, incluso si el documento
tiene una variación sustancial de otros documentos.

Sin embargo, en la práctica los documentos de una colección comparten una estructura similar y
pueden aplicar reglas de validación de documentos para una colección durante las operaciones
de actualización e inserción.

5.2.3.2 Estructura del Documento

La decisión clave en el diseño de modelos de datos para aplicaciones MongoDB gira en torno a
la estructura de los documentos y como la aplicación representa las relaciones entre los datos.
MongoDB permite incrustar datos relacionados en un solo documento.

5.2.3.3 Datos incrustados

Los documentos incrustados capturan las relaciones entre los datos almacenando los datos
relacionados en una única estructura de documento. Los documentos de MongoDB permiten
incrustar estructuras de documentos en un campo o matriz dentro de un documento. Estos

23
modelos de datos desnormalizados permiten que las aplicaciones recuperen y manipulen datos
relacionados en una sola operación de base de datos.

Figura 4, Ejemplo de datos incrustados

Fuente: https://docs.mongodb.com/manual/

Para muchos casos de uso en MongoDB, el modelado de datos desnormalizados es óptimo.

5.2.3.4 Referencias

Las referencias almacenan las relaciones entre los datos al incluir enlaces o referencias de un
documento a otro. Las aplicaciones pueden resolver estas referencias para acceder a los datos
relacionados. En general estos son modelos de datos normalizados.

Figura 5, Referencia entre Documentos

Fuente: https://docs.mongodb.com/manual/
24
5.2.3.5 Atomicidad de Documento único

En MongoDB una operación de escritura es atómica en el nivel de un solo documento, incluso si

la operación modifica varios documentos incrustados dentro de un solo documento

Un modelo de datos desnormalizado con datos incrustados combina todos los datos relacionados
en un solo documento en lugar de normalizarse en múltiples documentos y colecciones. Este
modelo de datos facilita las operaciones atómicas.

Cuando una sola operación de escritura (por ejemplo, db.collection.updateMany()) modifica varios
documentos, la modificación de cada documento es atómica, pero la operación en su conjunto
no es atómica.

Al realizar operaciones de escritura de varios documentos, ya sea a través de una sola operación
de escritura o múltiples operaciones de escritura, otras operaciones pueden intercalarse.

A partir de la versión 4.0, para situaciones que requieren atomicidad para las actualizaciones de
múltiples documentos o la coherencia entre las lecturas de múltiples documentos, MongoDB
proporciona transacciones de múltiples documentos para conjuntos de réplicas.

5.2.3.6 Transacciones Multi-Documento

En la mayoría de los casos, la transacción de múltiples documentos incurre en un mayor costo

de rendimiento en las escrituras de un solo documento y la disponibilidad de la transacción de
documentos múltiples no debe reemplazar al diseño de esquema efectivo. Para muchos
escenarios, el modelo de datos desnormalizados (documentos incrustados y matrices) continuara
siendo óptimo para sus datos y casos de uso. Es decir, para muchos escenarios, modelar sus
datos apropiadamente minimizará la necesidad de transacciones de documentos múltiples.

5.2.3.7 Uso de datos y rendimiento

Al diseñar un modelo de datos, considere como las aplicaciones utilizaran su base de datos. Por
ejemplo, si su aplicación solo utiliza documentos recientemente insertados, considere usar
colecciones limitadas. O si las necesidades de su aplicación son principalmente operaciones de
lectura a una colección, agregar índices para admitir consultas comunes puede mejorar el
rendimiento.

25
5.2.3.8 Relaciones

Las relaciones en MongoDB se entiende como la información que se puede encontrar asociada
a un mismo documento o referenciada.

En MongoDB existen relaciones 1 a 1, 1 a N (Muchos). Si bien se pueden modelar relaciones N

a N (Muchos a Muchos).

a) Relaciones 1 a 1
Estas relaciones se utilizan cuando tenemos relacionada un conjunto de información que
corresponde a una entidad de datos. Dicha entidad de datos puede ser relacionada o
embebida según (MongoDB). Es decir que podemos representar de dos maneras
relaciones 1 a 1 representadas en los siguientes ejemplos.

Figura 6, Relaciones 1 a 1

Fuente: https://docs.mongodb.com/manual

26
En este ejemplo se muestra que para acceder al nombre que se encuentra en el primer
documento, se debe acceder a “patrón_id” y luego acceder al primer documento para acceder al
nombre. La desventaja que tiene se debe realizar una consulta adicional para obtener una
información que es propia de una misma entidad.

Figura 7, Relaciones 1 a 1 embebido

Fuente: https://docs.mongodb.com/manual

En este ejemplo la información que corresponde a una entidad se encuentra en un mismo

documento (Información Embebida). Se puede obtener toda la información de una misma entidad
en una misma consulta.

b) Relaciones 1 a N (Muchos)
Estas relaciones se utilizan cuando se relaciona un documento que posee referencias a
más de un documento. Se muestran los siguientes ejemplos que muestra la manera de
representar estos tipos de relaciones.

27
 Figura 8, Relación 1 a N (Muchos)

Fuente: https://docs.mongodb.com/manual

Este ejemplo representa un modelo normalizado que los documentos “address” contienen
referencias al documento “patrón”. En este caso en particular, necesitamos al menos dos
consultas para obtener todos los datos completos relacionados.

En el caso de documentos embebidos (desnormalizados), con una consulta podemos obtener

toda la información necesaria. El ejemplo quedaría de la siguiente forma:

28
 Figura 9, Relación 1 a N (Embebido)

Fuente: https://docs.mongodb.com/manual

5.3 Cassandra

Cassandra es un sistema de gestión de bases de datos desarrollado por Facebook, cuyo objetivo
era crear un DBMS sin fallos y que proporcione la máxima disponibilidad.

Cassandra es principalmente una base de datos de almacenes de columnas. Algunos estudios

se refieren a Cassandra como un sistema híbrido, inspirado en BigTable de Google, (base de
datos de almacén de columnas), y en DynamoDB de Amazon, (base de datos de clave-valor).

29
Esto se consigue proporcionando un sistema de clave valor. Pero la clave de Cassandra apuntan
a un conjunto de familias de columnas, dependiendo del sistema de archivos distribuido
“BigTable” de Google y de las características de disponibilidad de DynamoDB (tabla hash
distribuida).

Cassandra está diseñado para almacenar enormes cantidades de datos distribuidos a través de
diferentes nodos. Cassandra es un DBMS diseñado para manejar cantidades masivas de datos,
repartidos entre muchos servidores, mientras que proporciona un servicio altamente disponible
sin un solo punto de fallo, lo cual es esencial para un gran servicio como Facebook.

Las principales características de Cassandra incluyen:

5.3.1 No hay ni un solo punto de fallo

Para que esto se consiga, Cassandra debe funcionar como un racimo de nodos. Eso no significa
que los datos de cada clúster serán los mismos, sin embargo, si debe serlo el software de gestión.
Cuando ocurre un fallo en uno de los nodos, los datos en ese nodo serán inaccesibles. Sin
embargo, otros nodos seguirán siendo accesibles.

5.3.2 Un Hashing distribuido

Es un esquema que proporciona la funcionalidad de tabla hash (Estructura de datos), de manera

que la adición o supresión de una ranura no cambia significativamente la asignación de claves a
dichas ranuras. Esto proporciona la capacidad de distribuir la carga a los servidores o nodos
según su capacidad, a su vez minimiza el tiempo de inactividad.

5.3.3 Interfaz de cliente relativamente fácil de usar

Cassandra utiliza Apache Thrift para su interfaz de cliente. Apache Thrift ofrece un cliente RPC
en varios idiomas, pero la mayoría de los desarrolladores prefieren alternativas de código abierto
construidas sobre Apple Thrift, como Hector.

5.3.4 Otras características de disponibilidad

Una de las características de Cassandra es la replicación de datos. Básicamente, refleja datos a

otros nodos del clúster. La replicación puede ser aleatoria o específica para maximizar la
30
protección de datos, colocándola por ejemplo en un nodo en un centro de datos diferente. Otra
característica que se encuentra en Cassandra es la política de partición. La directiva de partición,
decide en qué nodo se va a colocar la clave. Esto también puede ser aleatorio u ordenado. Al
utilizar ambos tipos de políticas de partición, Cassandra puede lograr un equilibrio entre el
equilibrio de carga y la optimización del rendimiento de las consultas.

5.3.4.1 Consistencia

Funciones como la replicación, hacen que la consistencia sea un desafío. Esto se debe al hecho
de que todos los nodos deben estar actualizados en cualquier punto en el tiempo con los valores
más recientes. Sin embargo, Cassandra intenta mantener un equilibrio entre las acciones de
replicación y las acciones de lectura/escritura proporcionando esta personalización al
desarrollador.

5.3.4.2 Acciones de lectura/escritura

El cliente envía una solicitud a un único nodo de Cassandra. El nodo, de acuerdo con la
política de replicación, almacena los datos en el clúster. Cada nodo realiza primero el cambio
de datos en el registro de confirmación, a continuación, actualiza la estructura de la tabla con
el cambio, ambos realizados de forma sincrónica. La operación de lectura es también muy
similar, una petición de lectura se envía a un solo nodo y ese único nodo es el que determina
qué nodo contiene los datos, de acuerdo con la política de partición/ ubicación.

5.3.5 Modelo de datos Cassandra

Como ya hemos comentado las bases de datos NoSQL no existe un modelo de datos fijo, sino
que es flexible y dinámico y como no iba a ser de otra forma, ocurre lo mismo con Apache
Cassandra. Conlleva que la estructura creada por una base de datos depende del tipo de
consultas que se vayan a realizar. A Cassandra podemos catalogarlo como una base de datos
clave-valor, por ello utiliza los siguientes conceptos:

 Column: Es el nivel más bajo que hay, se trata de una estructura con 3 campos, que son:
el nombre de la columna, el valor que tiene y el timestamp. El timestamp contiene el
momento (fecha, hora en milisegundos) en la cual se ha realizado la inserción.

5.3.4 Base de datos distribuida

Por naturaleza, Cassandra es una base de datos distribuida. Eso significa que fue diseñada para
ejecutarse en una red de nodos de computadoras, funcionando como un servidor que tiene
31
diferentes partes que se ejecutan en diferentes maquinas sin ningún hardware o software
específico para gestionar o coordinar. Toda la coordinación de los nodos y la distribución de los
datos están dentro de su propia arquitectura. Esta es una de las razones por las que una red de
Cassandra es más barata y fácil de escalar de forma horizontal. La topología típica de Cassandra,
está compuesta por un clúster de nodos, también llamado anillo de Cassandra, que se ejecuta
en diferentes direcciones de red que están ubicadas en servidores físicos diferentes.

Figura 10, Clúster de nodos de Cassandra en diferentes nodos

Fuente: http://www.datastax.com/

Esta función incrementa la disponibilidad de la red en caso de fallo de un nodo. Cada nodo puede
coordinar la solicitud de un cliente sin un nodo maestro, para que no haya un punto único de fallo.
También le permite establecer diferentes estrategias de configuración para que los datos sean
consistentes de las diferentes ubicaciones de los nodos, por lo tanto, incrementa aún más la
disponibilidad del sistema.

32
Análisis de Datos

El análisis de datos (Data Analytics, o DA) es la ciencia que examina los datos en bruto con el
propósito de sacar conclusiones sobre la información. El análisis de datos es usado en varias
industrias para permitir que las compañías y las organizaciones tomen mejores decisiones
empresariales y también es usado en las ciencias para verificar o reprobar modelos o teorías
existentes. El análisis de datos se distingue de la extracción de datos por su alcance, su propósito
y su enfoque sobre el análisis. Los extractores de datos clasifican inmensos conjuntos de datos
usando software sofisticado para identificar patrones no descubiertos y establecer relaciones
escondidas. El análisis de datos se centra en la inferencia, el proceso de derivar una conclusión
basándose solamente en lo que conoce el investigador.

La ciencia generalmente se divide en análisis exploratorio de datos (EDA), donde se descubren

nuevas características en los datos, y en análisis confirmatorio de datos (CDA), donde se prueba
si las hipótesis existentes son verdaderas o falsas. El análisis cuantitativo (QDA) es usado en la
ciencia sociales para sacar conclusiones de datos no numéricos, como palabras, fotografías o
videos. En la tecnología de la información, el termino tiene un significado especial en el contexto
de las auditorias informáticas, cuando se examinan los sistemas, operaciones y controles de los
sistemas de la información de una organización. El análisis de datos se usa para determinar si el
sistema existente protege datos efectivamente, opera eficientemente y cumple con las metas de
la organización.

El término “análisis “ha sido usado por varios proveedores de software de inteligencia de negocios
como una palabra de moda que describe varias funciones. El análisis de datos se usa para
describirlo todo, desde el procesamiento analítico en línea (OLAP, por sus siglas en inglés) hasta
el análisis CRM en centros de llamadas. Los bancos y las compañías de tarjetas de crédito, por
ejemplo, analizan los retiros y los patrones de gasto para prevenir el fraude o robo de identidad.
Las compañías de comercio electrónico (Ecommerce) examinan el tráfico en el sitio web o los
patrones de navegación para determinar que clientes son más o menos propensos a comprar un
cierto producto o servicio, basándose en compras previas o patrones de visualización. El análisis
de datos moderno normalmente usa tableros de información que se basan en flujos de datos en
tiempo real. El llamado análisis en tiempo real implica análisis e informes dinámicos basados en
los datos que introducimos en un sistema un minuto antes del tiempo actual de uso.

33
Si bien cada empresa tiene sus propios requisitos y objetivos al recopilar y analizar datos, hay
pasos que se mantienen consistentes en todas las organizaciones y sus procesos para explotar
la información que queremos compartirte.

Determina los objetivos de los equipos de ciencia de datos para desarrollar una forma
cuantificable de determinar si el negocio está avanzando hacia sus objetivos, identificar las
métricas o los indicadores de desempeño temprano.

Identifica las posibilidades comerciales y las métricas al inicio de los proyectos de análisis de
datos para dar alcance y enfoque. Esto significa que la empresa debe estar dispuesta a realizar
cambio para mejorar sus métricas clave y alcanzar sus objetivos también.

Haz siempre una limpieza de toda la información recopilada. Mejora la calidad de los datos para
generar resultados correctos y evitar sacar conclusiones incorrectas. Hay que automatizar el
proceso e involucrar a los empleados para supervisar la limpieza y garantizar la precisión de los
datos.

34
6 CONCLUSIONES

La presente monografía se ha dedicado a la investigación y análisis de las bases de datos

NoSQL: Redis para las sesiones de los usuarios.

En una plataforma web que acceden miles de usuarios registrados por hora. Cada vez que un
usuario visita una página de la plataforma, tiene que hacer varias consultas a la base de datos
para saber si ese usuario con esa cookie está registrado y está autorizado para ver esa página.
Si por ejemplo tenemos 10.000 usuarios por hora y cada usuario navega por la plataforma unas
50 veces, querrá decir que tendremos que hacer medio millón de consultas a la base de datos
por hora, conectarte, mandarle los datos, esperar a que responda, procesar la información y
devolverla al usuario.

Esto con Redis no pasaría ya que, si se “cachea” la primera vez los datos del usuario,
ahorraríamos 490.000 consultas de verificación por hora. Al final de día ahorraríamos más de 11
millones de peticiones a la base de datos para ver si el usuario esta autentificado. Redis es una
base de datos en RAM que gracias a que nos permite ahorrarnos millones de conexiones con la
base de datos principal conseguimos que nuestra plataforma sea muchísimo más rápida.

MongoDB para el modelo de negocio, ya que MongoDB plantea un modelo de datos orientado a
documentos, utilizando BSON como formato de almacenamiento. BSON no es más que JSON
codificado de manera binaria. JSON tiene estructuras afines en muchos lenguajes de
programación (C, JAVA, JAVASCRIPT, ….) pero no depende de ninguno de ellos.

En MongoDB los documentos se agrupan en colecciones. Podemos decir que los documentos
juegan un papel similar al que juegan los registros de las bases de datos relacional. Las
colecciones son parecidas a las tablas de las bases de datos relacionales, aunque no imponen
una estructura fija a los documentos que contienen, ni siquiera al tipo de cada campo.

En MongoDB la estructura de los datos, es implícita, flexible y dinámica, implícita porque lo normal
es que los documentos de una colección compartan estructura, y esta no se declara de manera
explícita antes de introducir documentos, flexible porque esa estructura no se impone a ningún
documento, dinámica por que la estructura puede cambiar.

En MongoDB no tenemos que crear ni modificar. Podemos almacenar los nuevos documentos,
posiblemente con una estructura distinta a los anteriores, en la misma colección, o en una nueva.
En el primer caso no tenemos que modificar la estructura de la colección, puesto que esto no
existe. Y en el segundo caso no tenemos que crear la colección, puesto que esta se crea de

35
manera automática cuando introducimos el primer documento. Así que no va hacer ningún tipo
de comprobación sobre la estructura de un documento, ni sobre la validez o tipo de campos que
lo componen. Si queremos hacer esto, tendremos que hacerlo en la propia aplicación. Esta
flexibilidad a la hora de trabajar con información que varía, es muy útil en fases iniciales de
proyectos, durante las cuales las especificaciones cambian a menudo. O trabajamos con
información que no cuenta con una estructura fija.

MongoDB está recibiendo soporte para transacciones ACID de múltiples documentos

(atomicidad, consistencia, aislamiento, durabilidad). Las transacciones en MongoDB se sentirán
como transacciones que los desarrolladores esta familiarizados con las bases de datos
relacionales. Serán declaraciones múltiples, con sintaxis similar (por ejemplo, start_transaction y
commint_transaction), haciéndola familiares para cualquier persona con experiencia previa en
transacciones.

Cassandra, para data analytics, actualmente usado por grandes corporaciones para sus
aplicaciones, como es el caso de Apple, con 75000 nodos que guardan más de 10 PB de datos,
Netflix con 2500 nodos y almacena 420TB, o eBay con 100 nodos almacena 250 TB.

Cassandra no tiene puntos de fallos, maneja datos estructurados como no estructurados,

gestiona altos volúmenes de datos, los nodos pueden crecer o decrecer en forma masiva, tiene
una disponibilidad continua, para datos y nodos lo que permite que el sistema siempre esté en
funcionamiento, todos los nodos tienen la capacidad de leer y escribir, maneja diferentes modelos
de datos: relacionales como no relacionales sus datos son protegidos por un sistema de log de
transacciones, y un sistema incluido de respaldo y restauración.

Aunque la captura, almacenamiento, búsqueda y análisis de extensos conjuntos de datos son

elementos imprescindibles en cualquier proceso de análisis de datos, el valor diferencial de un
análisis de datos se encuentra fundamentalmente en los siguientes procesos clave:

Análisis exploratorio de datos: estos identifican las tendencias, gráficos, histogramas,

clasificación de grupos.

Modelado y algoritmos: Basados en informaciones estadísticos; medias, modas, desviaciones,

máximos, mínimos, regresiones, pruebas-t, pruebas-z y otras técnicas aplicables a la empresa.
Basados en algoritmos heurísticos o en lógica de negocio, basados en inteligencia artificial.

Informes y visualización de datos: la información puede ser entregada para ser comprendida
mediante informes y gráficos que se manejan desde Excel, PowerBI, Reporting Service,
aplicaciones a medida, QlikView, PeriscopeData, Tableau, Google Data Studio.
36
7 BIBLIOGRAFÍA

Karl Seguin, (2017). The Little Redis Book

Schönberger, V. M. (2013). Big data: la revolución de los datos masivos. Turner.

Soumendra, M., Madhu, J., & Harsha, S. (2013). Big Data Imperatives: Enterprise ‘Big Data’
Warehouse, ‘BI’ Implementations and Analytics. Apress.

Teorema CAP, Fecha de consulta: mayo de 2019. Recuperado de:

https://sebmaldo.com/2015/11/24/el-teorema-cap-sistemas-distribuidos/

Jhon Alexander ,(30 de junio de 2016), Teorema CAP, Fecha de consulta: mayo de 2019.
Recuperado de: http://blog.jacagudelo.com/teorema-cap/

Teorema CAP, Fecha de consulta: mayo de 2019. Recuperado de: https://platzi.com/blog/que-

es-el-teorema-cap-y-como-elegir-la-base-de-datos-para-tu-proyecto/

Base de Datos NoSQL, Fecha de consulta: mayo de 2019. Recuperado de:

https://blog.pandorafms.org/es/bases-de-datos-nosql/

Base de Datos NoSQL, Fecha de consulta: mayo de 2019. Recuperado de:

https://blogs.oracle.com/spain/qu-es-una-base-de-datos-nosql

Redis, (2019). Redis. Fecha de consulta: mayo de 2019. Recuperado de:

https://redis.io/documentation

Redis, (2019). Redis. Fecha de consulta: mayo de 2019. Recuperado de:

https://aws.amazon.com/es/redis/

Redis, (2019). Who's using Redis?. Fecha de consulta: mayo de 2019. Recuperado de:
https://redis.io/topics/whos-using-redis

Redis, (2019). Do You Really Know Redis?. Fecha de consulta: junio de 2019. Recuperado de:
https://redislabs.com/docs/really-know-redis/

MongoDB, (2019). Consideraciones sobre Modelado de Datos en MongoDB. Fecha de Consulta:

mayo de 2019. Recuperado de: https://unpocodejava.com/2013/08/05/consideraciones-sobre-
modelado-de-datos-en-mongodb/

Cassandra, (2019). Apache Cassandra. Fecha de consulta: junio de 2019. Recuperado de:
https://pandorafms.com/blog/es/bases-de-datos-nosql/

37
Cassandra, (2019). Patterns of Successful Cassandra Data Modelling. Fecha de consulta: junio
de 2019. Recuperado de: https://opencredo.com/blogs/cassandra-data-modelling-patterns/

Cassandra y MongoDB. (2019). Cuando Usar Cassandra, Cuando Usar MongoDB. Fecha de
consulta: junio de 2019. Recuperado de:
http://www.solocodigoweb.com/blog/2018/05/18/cuando-usar-cassandra-cuando-usar-mongodb/

Cassandra, (2017). Que es la base de datos Cassandra Big Data. Fecha de consulta junio de
2019. Recuperado de: https://itsoftware.com.co/content/que-es-la-base-de-datos-apache-
cassandra/

Data Analitycs, Fecha de consulta: junio de 2019. Recuperado de:

https://searchdatacenter.techtarget.com/es/definicion/Analisis-de-Datos

Paul Lara, (2 de julio de 2018), Que es data analitycs y para qué sirve. Fecha de consulta: junio
de 2019. Recuperado de: https://telcelempresas.com/que-es-la-data-analytics-y-para-que-sirve/

38