Está en la página 1de 23

Petabytes de información:

Repensando el 
modelamiento 
de base de datos

Ernesto Quiñones Azcárate
ernestoq@apesol.org
Presidencia Apesol 2006­2008

   
Modelos de  bases de datos para todos los gustos (según la organización de los 
datos) :

Jerárquicas Relacionales

Orientadas al objeto
Multidimensional

   
A donde camina la información:

● Existen al menos 50 dbms “famosos” entre libres y privativos y 
un número al menos 4 ó 5 veces superior entre los de uso 
académico/experimental etc.
● En 2006 existían 161 Exabytes de información  (1 Exabyte = 1000 

Petas), Actualmente (2008) debe existir 330­340 Exabytes.
● En 2011 debemos tener cerca de 1,800 Exabytes de información.

● En 2007 la cantidad de información generada supero a la 

capacidad instalada mundial de contenerla, actualmente se 
calcula un déficit de 60 a 70 Exabytes de infraestructura.
● Existen 1,000 millones de dispositivos de capturas de imágenes

● El 95% de la data del mundo no tiene                                   

estructura.
● 65k filmaciones nuevas en Youtube por día.

● 60 millones de emails diarios.

● Google puede indexar 20 Petabytes en un solo día.

   
● La data esta cambiando

● La información sigue creciendo nadie va a parar eso, es 
mas va a ser peor

● Actualmente el % de usuarios que provee información a 
la red es mucho menor de los que lo usan.

●Cada vez es mas difícil catalogar la información

● Cada vez será mas difícil encontrar la información que 
uno quiere

..... y como administramos tanta data?

   
El 22 de Mayo Yahoo dio esta noticia : 

● Yahoo anuncia tener la base de datos mas grande del mundo (2 
Peta bytes) en funcionamiento.

● La base de datos de 1 año de antigüedad esta procesando 24,000 
millones de eventos diarios.

● El administrador de la data es un PostgreSQL (
http://www.postgresql.org) modificado especialmente para ellos.

● La tecnología usada es la “base de datos basada en columnas” 
donde no existen “registros”, esto hace que la grabación de datos 
sea lenta pero la lectura es muy rápida.

Noticia original:
http://tinyurl.com/68avgt
   
Que es una base de datos basa en columnas
Convencionalmente guardamos la data así :

Ahora la data la guardamos así :

Otra representación :
Dudas:
● ¿Porque hacer esto?
● ¿Donde queda la normalización?

● ¿Existen “engines” para este tipo de base 

de datos?

   
La ventaja de una base de datos basada en columnas.
El principal motivo es el tiempo de acceso al disco, la velocidad del disco suele 
ser el cuello de botella en los sistemas de almacenamiento ya que es 
notablemente mas lento que el poder de procesamiento.

   
La ventaja de una base de datos basada en columnas.
Tradicionalmente las bases de datos hacen esto para guardar la data

No No Esto es rápido para 
Páginas 8k 8k 8k operaciones de 
usada usada
escritura pero no de 
No No lectura.
8k 8k 8k 8k
usada usada

Cada página tiene una 
estructura de este tipo 
(generalmente)

   
La ventaja de una base de datos basada en columnas.
Este es un ejemplo aproximado 
de data masiva

Esta data se organizará bajo este esquema lógico

   
La ventaja de una base de datos basada en columnas.
Esta es la representación de la organización física de la data

El engine de la db tomará la data y la guardará 
en archivos llamados CellStores subdivididos en 
bloques de data comprimida de 64k (podría 
variar) en su propio sistema de archivos por 
sobre el que tiene el sistema operativo.

Por ejemplo:
Juan, Pedro, Lucho, Lima, Lima, Callao, 25,25,25
Sería convertida a :
Juan, Pedro, Lucho, Lima x 2, Callao, 25 x 3

Mientras en los dbms convencionales la data se 
guarda en varias secciones/espacios del disco, 
en las c­dbms se guarda junta y continua en el 
mismo CellStore.

   
La ventaja de una base de datos basada en columnas.

Los Querys:

Este es un ejemplo de como funciona 
Bigtable de Google
   
¿El fin de los RDBMS?
● El problema del modelo relacional es que suele ser un consumidor alto 
de recursos al momento de ejecutar transacciones, especialmente 
cuando uno tiene data masiva.
Imagines que deseamos borrar 
registros en “Cuotas” y el engine 
debe verificar que no se hagan 
modificaciones que rompan la 
relación con “Pagos”.

1,000 registros
100,000 
10,000,000 
1,000,000,000
100,000,000,000
1,000,000,000,000

   
¿El fin de los RDBMS?
● El problema del modelo relacional es que suele ser un consumidor alto 
de recursos al momento de ejecutar transacciones, especialmente 
cuando uno tiene data masiva.
Cada delete debe ejecutar un select 
en la tabla “Pagos”, ¿cuanto demora?
1,000 ­­­> 1s
100,000  ­­> 1m40s
10,000,000  ­­> 2.77h
1,000,000,000 ­­> 11.57d
100,000,000,000 ­­> 3.17a
1,000,000,000,000 ­­> 317a (y algunos 
días mas :D

Recordemos Yahoo hace 
24,000,000,000 de transacciones por 
día, en 41.6 días genera 1 billón de 
registros (como mínimo).

   
¿El fin de los RDBMS?
● Los sistemas Relacionales tienes mas de 25 años de existencia.
● Básicamente fueron pensada con una orientación de guardar data de 

negocios.
● Cuando empezó a explotarse la data masiva (hace poco mas de una 

década) el sistema relacional demostró tener problemas, se tuvo que 
mejorar/modificar para atender esta nueva necesidad.
● La data a pasado a ser no­precisa, imposible de “normalizar”.

● Los joins son lentos cuanto tienes cantidades de data monstruosa.

● Los procesos de ABC se vuelven muy costosos cuando hay muchas 

relaciones entre las tablas.

Sin embargo el fin de los RDBMS fue predicho antes; OODBMS, XML, 
etc., esta todavía lejos de ser considerada “tecnología legacy”.

   
ENGINES

BigTable (privativo – Google)

● Desarrollo y uso exclusivo de Google.
● Tiene 2 componentes esenciales: (1) Google File System (GFS) el cual 

asegura disponibilidad de los datos por medio de copias redundantes, 
mientras mas sea consultado un dato mas veces de duplicado 
asignándosele mas recursos. (2) Chubby Lock Service, el cual es un 
componente que permite la sincronización de accesos a recursos 
compartidos.
● Las tablas se subdividen en tablets con filas que llegan a medir hasta 

200mb.
● A estas filas se les aplica ademas un algoritmo de compresión secreto 

para optimizar aún mas el espacio.
● A enero 2008 existían 600 clusters, el mas grande con 2000 servers, el 

store mas grande es de 700Tbytes y atiende 100k operaciones por 
segundo.
● Se utiliza un lenguaje llamado  Sawzall.

   
ENGINES

BigTable (privativo – Google)

   
ENGINES

Hypertable http://hypertable.org/ 

● Proyecto libre que aplica “buenas practicas” en la administración de db 
de gran cantidad de datos y alto volumen de trabajo.
● La data es guardada como cadenas de bytes, las tablas que lo 

almacenan son cortadas en secciones continuas y divididas en 
diversos servidores, estos son conocidos como Range Servers, 
adicionalmente existen Master Servers que se encargan de tareas 
administrativas y supervisar los Range Servers (ambos servicios 
pueden correr en una misma pc).
● Se utiliza un lenguaje llamado Hypertable Query Language (HQL)

● Puede usar diferentes sistemas de archivos, pero se recomienda 

Hadoop Distributed File System (HDFS) http://hadoop.apache.org/

   
ENGINES

Hypertable http://hypertable.org/ 

Coordinador de 
concurrencia
(lock manager)

Administra 
data en 
memoria

Cache de 
transacciones

Aquí se encuentran 
 
las celdas de datos  
ENGINES

Hypertable http://hypertable.org/ 

Servicio que da 
la cara al cliente, 
coordina las ABC 
en los Datanodes

Guarda la 
data

La misma data
se guarda en diferentes 
Datanodes

   
ENGINES

LucidDB http://luciddb.sourceforge.net/ 

● Esta basada en EigenBase http://www.eigenbase.org/ un software base 
que permite crear sistemas administradores de datos.
● LucidDB esta pensada con el propósito de hacer data warehousing y 

business intelligence.
● Esta pensada para ser básicamente solo read­only, las actualizaciones 

crean nuevas páginas que reemplazan a las existentes y se guardan 
versiones de estas.
● Las páginas miden 32K, se maneja un buffer de 5,000 páginas con la 

información mas leida.
● Se usa una técnica de indexación conocida como “bitmap”, indices y 

data son comprimidos y se utiliza la técnica del “semijoin” para 
determinar la data que es únicamente necesaria acceder por los 
querys.
● LucidDB puede acceder directamente a repositorios externos via 

SQLMED
   
Se uso Java pensando
ENGINES en la expansión del 
producto.
LucidDB http://luciddb.sourceforge.net/ 

Acceso a 
repositorio
s de datos 
externos

Engine principal de
LucidDB

Data
   
Para leer mas:

Toda la información con la cual se a documentado esta presentación es recopilada en este 
enlace :

http://tinyurl.com/6xfwvg 

Y mas información :

http://www.eqsoft.net/wiki/doku.php?id=start 

   
Muchas Gracias!!!

Visite APESOL
http://www.apesol.org

Inscríbete en las listas de interés en
http://apesol.org/listas.php

Conversemos en vivo en
server: irc.freenode.net
sala:#apesol