Bases de Datos NoSQL
Presentado por Luis Porras / @lporras16
Software Engineer en RunaHR
Programador Web Senior
Comencemos...
DB-Engines Ranking
Conceptos
Qué Hace una Base de Datos?
- Almacenar Información
- Recuperar la Información
RDBMS
Manejador de Bases de Datos Relacionales
La Data está organizada en relaciones (tablas)
y cada relacion esta compuesta de colecciones de tuplas (filas)
Clientes
Ordenes de Compra
Modelo Entidad Relación
SQL
Structured Query Language
Un lenguaje de consultas declarativo
Imperativo
consulta Imperativa
function getSharks() {
var sharks = [];
for (var i = 0; i < animals.length; i++) {
if (animals[i].family === "Sharks") {
sharks.push(animals[i]);
}
}
return sharks;
}
select email, first_name, last_name
from customers
where city = "Quincy"
first_name | last_name | |
---|---|---|
jadams@usa.gov | Jhon | Adams |
Declarativo
customer_id | oder_date | order_amount |
---|---|---|
2 | 3/14/1760 | $78.50 |
4 | 9/03/1790 | $65.50 |
SQL JOIN
select customer_id, order_date, order_amount
from customers
join orders
on customers.customer_id = orders.customer_id
where customer_id = 3
Y cúal es el problema con las RBDMS?
Escalabilidad...
Dos formas de escalar..
Para escalar una aplicación necesitas hacer tu servidor más..
Grande
Grande
Grande
Scaling up
Escalamiento Vertical
Grande
Grande
Grande
O puedes distribuir la carga
Scaling out
Escalamiento Horizontal
#NoSQL
Not Only SQL
No hay una definición exacta de NoSQL
Pero podemos mencionar 2 cosas:
- Porqué se crearon estas nuevas tecnologías?
- Qué características tienen en común?
1. NoSQL nació de la frustración con las RDBMS
Impedance Mistmach
Tienes una estructura lógica en tu aplicación...
y cuando la vas a guardar en la DB...
queda repartida en diferentes tablas...
y esto require de capas de abstraccion intermedias, los populares ORM
Las RDBMS no son cluster friendly
es decir es díficil escalar horizontalmente
2. Características en común
Características
-
cluster friendly (La mayoría)
-
open source (La mayoría)
-
pensadas para gran aplicaciones con cantidad de datos y usuarios, Facebook, Linkedin, etc
-
Modelo de datos diferente al SQL
Modelo de Datos
- Llave valor - Key Value
- Documentos
- Columnas
- Grafos
Existen 4 diferentes tipos de Modelo de Datos NoSQL
Key-value
Key Value Store
467742
3fds-2d
Documentos
Documentos
- La base de datos está compuesta de documentos.
- Cada documento se guarda en formato JSON tipicamente
- Permiten cargar y consultar documentos via REST
- Elasticsearch, MongoDB, CouchDB, son ejemplos.
- Schema-less, no dependemos de un esquema para guardar la información.
{
"_id": "507f191e810c19729de860ea",
"nombre": "Luis Alfredo Porras Páez",
"twitter": "@lporras16",
"pais": "Colombia",
"lenguajes": ["español", "inglés"]
}
Columnas
Columnas
Column Familiy
Resaltar que:
- Key-value
- Documentos
- Column Family
Se pueden pensar como un almacen de componentes o agregados.
Aggregate Oriented Databases
Los componentes ayudan a resolver los 2 problemas que tienen las RDBMS
No Impedance Mistmach
Ahora se puede tener la misma estructura
de un componente tanto en la aplicación como en la base de datos
La DB es cluster friendly
Ahora la información de un componente o un bloque de componentes puede estar distribuida en cada nodo del cluster
Grafos
Grafos
Grafos Ejemplo
Pokemon Grafo
Pokemon Grafo
MATCH x = shortestPath((o:City)-[*]-(a:Attraction))
WHERE o.name = "Vaniville Town" AND a.name = "Pokemon Center"
WITH NODES(x) AS stops
MATCH (p:Pokemon)-[:CAUGHT_IN]->(r:Route)
WHERE r IN stops
RETURN r.name AS `Route`, COLLECT(p.name) AS `Wild Pokemon`
ORDER BY r.name
Rutas con pokemones salvajes entre el pueblo Vaniville y la ciudad o pueblo más cercano con un Centro Pokemon
Ahora...
RDBMS son ACID...
Las DB NoSQL son BASE...
A
C
I
D
tomacity - Una operación consiste en una serie de pasos en los que se ejecutan todos o ninguno
onsistency - La data pasa de un estado válido a otro
solation - Las transcacciones no se afectan entre sí.
urability - Persistencia
Basically Available
Soft State
Eventually Consistent
Básicamente disponible, Soft State, Eventual Consistency (BASE):
Es una filosofía de diseño de sistemas de datos que valora la disponibilidad sobre la consistencia de las operaciones.
BASE se desarrolló como una alternativa para producir arquitecturas de datos más escalábles.
C
A
P
onsistency - todos los nodos ven la misma información todo el tiempo
viability - toda petición recibe una respuesta sobre si fue exitosa o fallida.
artition Tolerance - el sistema sigue funcionando a pesar que algunas particiones esten desconectadas.
Teorema CAP
Consistency
Availability
Partition Tolerance
R
D
B
M
S
Teorema CAP
NoSQL
Polyglot Persistence
Persistencia Poliglota
Aplicación Grande
Sesión de Usuarios
redis
Datos Financieros
MySQL
Recomendaciones
Neo4J
Cat. Productos
MongoDB
Analíticas
Cassandra
Reportes
RDBMS + Memcached
Entonces...
- Realmente necesito utilizar una BD NoSQL?
- Modelar en cada BD es distinto
- Considera NoSQL si puedes aceptar Eventual Consistency