The document discusses NoSQL databases and polyglot applications. It begins with a brief history of databases and defines key aspects of NoSQL databases, including that they do not require predefined schemas or support SQL queries. It then describes four main types of NoSQL databases - key-value stores, document databases, graph databases, and column-oriented databases - listing popular examples of each. The document advocates for polyglot applications that use multiple database types to address different data and query needs. It provides an example using Redis to implement a cache for part of an application to improve performance.

1. Bases
de
Datos
NoSQL
Y
Aplicaciones
Poliglotas
Agus%n
Magaña
Falconi

3. AGENDA
• Un
poco
de
historia
• Definición
de
NoSQL
• Tipos
de
NoSQL
• ¿Porqué
Aplicaciones
Poliglotas?
• Ejemplo
usando
REDIS

4. Edgar
Frank
"Ted"
Codd

5. 1980’s

6. Tendencia:
Menos
uniformidad

7. Datos
dispersos:
BD
Relacionales

8. Tendencia:
Crecimiento
exponencial
de
datos

9. Not
Only
SQL

10. Not
Only
SQL
• No
usan
SQL
como
lenguaje
principal
de
consultas
• No
se
requieren
estructuras
fijas
como
tablas
• No
JOINsa
• No
se
garanAza
ACID
• Escalan
bien
horizontalmente

11. Tipos
de
Bases
de
Datos
NoSQL
• Key/Value
stores
• Document
Databases
• Graph
Databases
• Column
Oriented
Databases

12. Key/Value
Stores
• Apache
Cassandra
• BigTable
de
Google
• Dynamo
de
Amazon
• Voldemort
de
LinkedIn
• Memcached
• Oracle
NoSQL
Database
• Redis

13. Graph
Databases
• Neo4j
• DEX
• AlegroGraph
• OrientDB
• InfiniteGraph
• InfoGraph
• HyperGraphDB

14. Document
Databases
• MongoDB
• CouchDB
• BaseX
• Djondb
• SimpleDB
• Terrastore

15. Column
Oriented
Databases
• Cassandra
• BigTable
• Hbase
• Hypertable

16. ¿Aplicaciones
Políglotas?

17. Food To Go Architecture
RESTAURANT
CONSUMER
OWNER
Order Restaurant
taking Management
MySQL
Database

18. Limitaciones
de
las
Bases
de
Datos
Relacionales
• Escalabilidad
• Distribución
• Modifición
del
schema
• O/R
impedance
mismatch
• Manejor
de
datos
semi-­‐estructurados

19. Solución:
Gastar
mucho
dinero

20. Solución:
Usar
NoSQL
Beneficios
Desventajas
• Alto
performance
• Limitaciones
en
transacciones
• Alta
escalabilidad
• Limitaciones
en
queries
• Rico
modelo
de
datos
• Consistencia
no
• Schema-­‐less
garanAzada
• Datos
sin
constrains

21. Redis
• Almacenamiento
key-­‐value
avanzado
• Muy
rápida
(100K
reqs/seg)
• Persistencia
opcional
• Transacciones
con
bloqueo
opAmista
• Replicación
de
información
Master/Slave

22. Sorted sets
Value
Key
a b
myset
5.0 10.
Members are Score
sorted by score

23. Adding members to a sorted set
Redis Server
Key Score Value
a
zadd myset 5.0 a myset
5.0

24. Adding members to a sorted set
Redis Server
a b
zadd myset 10.0 b myset
5.0 10.

25. Adding members to a sorted set
Redis Server
c a b
zadd myset 1.0 c myset
1.0 5.0 10.

26. Retrieving members by index range
Start End
Key
Index Index Redis Server
zrange myset 0 1
c a b
myset
1.0 5.0 10.
c a

27. Retrieving members by score
Min Max
Key
value value Redis Server
zrangebyscore myset 1 6
c a b
myset
1.0 5.0 10.
c a

28. Redis
es
bueno
pero
]ene
desventajas
• Búsquedas
solo
por
PK
• Modelo
de
transacciones
limitado:
• Lee
primero
y
ejecuta
updates
como
batch.
•
Los
datos
deben
de
caber
en
memoria
• Le
faltan
funcionalidad
de
controles
de
acceso

29. Caching with Redis
RESTAURANT
CONSUMER
OWNER
Order Restaurant
taking Management
Redis MySQL
First Second
Cache Database

31. Domain object to key-value
mapping?
Restaurant
K1 V1
TimeRange MenuItem K2 V2
TimeRange MenuItem
... ...
ServiceArea

32. Finding available restaurants
Available restaurants =
Serve the zip code of the delivery address
AND
Are open at the delivery time
public interface AvailableRestaurantRepository {
List<AvailableRestaurant>
! findAvailableRestaurants(Address deliveryAddress, Date deliveryTime);
...
}

33. Food to Go – Domain model (partial)
class Restaurant { class TimeRange {
long id; long id;
String name; int dayOfWeek;
Set<String> serviceArea; int openTime;
Set<TimeRange> openingHours; int closeTime;
List<MenuItem> menuItems;
}
}
class MenuItem {
String name;
double price;
}

34. Database schema
ID Name …
RESTAURANT table
1 Ajanta
2 Montclair Eggshop
Restaurant_id zipcode
RESTAURANT_ZIPCODE table
1 94707
1 94619
2 94611
2 94619
RESTAURANT_TIME_RANGE table
Restaurant_id dayOfWeek openTime closeTime
1 Monday 1130 1430
1 Monday 1730 2130
2 Tuesday 1130 …

35. Finding available restaurants on Monday, 6.15pm
for 94619 zipcode
Straightforward three-way join
select r.*
from restaurant r
inner join restaurant_time_range tr
on r.id =tr.restaurant_id
inner join restaurant_zipcode sa
on r.id = sa.restaurant_id
where ’94619’ = sa.zip_code
and tr.day_of_week=’monday’
and tr.openingtime <= 1815
and 1815 <= tr.closingtime

36. BUT how to implement findAvailableRestaurants()
with Redis?!
?
select r.*
from restaurant r K1 V1
inner join restaurant_time_range tr
on r.id =tr.restaurant_id
inner join restaurant_zipcode sa
on r.id = sa.restaurant_id
K2 V2
where ’94619’ = sa.zip_code
and tr.day_of_week=’monday’
and tr.openingtime <= 1815 ... ...
and 1815 <= tr.closingtime

37. Where we need to be
ZRANGEBYSCORE myset 1 6
=
sorted_set
select value,score key value score
from sorted_set
where key = ‘myset’
and score >= 1
and score <= 6

38. We need to denormalize
Think materialized view

39. Simplification #1:
Denormalization
Restaurant_id Day_of_week Open_time Close_time Zip_code
1 Monday 1130 1430 94707
1 Monday 1130 1430 94619
1 Monday 1730 2130 94707
1 Monday 1730 2130 94619
2 Monday 0700 1430 94619
…
SELECT restaurant_id
FROM time_range_zip_code
WHERE day_of_week = ‘Monday’ Simpler query:
 No joins
AND zip_code = 94619  Two = and two <
AND 1815 < close_time
AND open_time < 1815

40. Simplification #2: Application
filtering
SELECT restaurant_id, open_time
FROM time_range_zip_code
WHERE day_of_week = ‘Monday’ Even simpler query
• No joins
AND zip_code = 94619
• Two = and one <
AND 1815 < close_time
AND open_time < 1815

41. Simplification #3: Eliminate multiple =’s with
concatenation
Restaurant_id Zip_dow Open_time Close_time
1 94707:Monday 1130 1430
1 94619:Monday 1130 1430
1 94707:Monday 1730 2130
1 94619:Monday 1730 2130
2 94619:Monday 0700 1430
…
SELECT restaurant_id, open_time
FROM time_range_zip_code
WHERE zip_code_day_of_week = ‘94619:Monday’
AND 1815 < close_time
key
range

42. Simplification #4: Eliminate multiple RETURN
VALUES with concatenation
zip_dow open_time_restaurant_id close_time
94707:Monday 1130_1 1430
94619:Monday 1130_1 1430
94707:Monday 1730_1 2130
94619:Monday 1730_1 2130
94619:Monday 0700_2 1430
...
SELECT open_time_restaurant_id,
FROM time_range_zip_code
WHERE zip_code_day_of_week = ‘94619:Monday’
AND 1815 < close_time
✔

43. Using a Redis sorted set as an index
zip_dow open_time_restaurant_id close_time
94707:Monday 1130_1 1430
94619:Monday 1130_1 1430
94707:Monday 1730_1 2130
94619:Monday 1730_1 2130
94619:Monday 0700_2 1430
...
Key Sorted Set [ Entry:Score, …]
94619:Monday [0700_2:1430, 1130_1:1430, 1730_1:2130]
94707:Monday [1130_1:1430, 1730_1:2130]

44. Querying with ZRANGEBYSCORE
Key Sorted Set [ Entry:Score, …]
94619:Monday [0700_2:1430, 1130_1:1430, 1730_1:2130]
94707:Monday [1130_1:1430, 1730_1:2130]
Delivery zip and day Delivery time
ZRANGEBYSCORE 94619:Monday 1815 2359

{1730_1}
1730 is before 1815  Ajanta is open

45. Sorry
Ted


46. The future is polyglot
e.g. Netflix
• RDBMS
• SimpleDB
• Cassandra
• Hadoop/Hbase
IEEE Software Sept/October 2010 - Debasish Ghosh / Twitter @debasishg

47. Algunos
usarios
NoSQL

48. Gracias
