Esta presentación da un inicio a las bases de datos orientadas a columnas, esta nueva generación de bases de datos muy utilizada en ambientes de miles de millones de datos como lo son los entornos de Business Intelligence e indexadores de data "sin forma" como Google y Yahoo.

1. Petabytes de información:
Repensando el
modelamiento
de base de datos
Ernesto Quiñones Azcárate
ernestoq@apesol.org
Presidencia Apesol 2006­2008

2. Modelos de bases de datos para todos los gustos (según la organización de los
datos) :
Jerárquicas Relacionales
Orientadas al objeto
Multidimensional

3. 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.

4. ● 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?

5. 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

6. 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?

7. 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.

8. 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)

9. 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

10. 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.

11. La ventaja de una base de datos basada en columnas.
Los Querys:
Este es un ejemplo de como funciona
Bigtable de Google

12. ¿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

13. ¿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).

14. ¿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”.

15. 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.

16. ENGINES
BigTable (privativo – Google)

17. 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/

18. ENGINES
Hypertable http://hypertable.org/
Coordinador de
concurrencia
(lock manager)
Administra
data en
memoria
Cache de
transacciones
Aquí se encuentran
las celdas de datos

19. 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

20. 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

21. 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

22. 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

23. 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