petabytes de informacion repensando el modelamiento de datos
DESCRIPTION
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.TRANSCRIPT
Petabytes de información:Repensando el modelamiento
de base de datos
Ernesto Quiñones Azcá[email protected]
Presidencia Apesol 20062008
Modelos de bases de datos para todos los gustos (según la organización de los datos) :
Jerárquicas Relacionales
MultidimensionalOrientadas al objeto
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 330340 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
Páginas 8kNo
usadaNo
usadaNo
usada8k
8k 8kNo
usada
8k
Nousada8k 8k
Esto es rápido para operaciones de escritura pero no de lectura.
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,25Serí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 cdbms 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 registros100,000 10,000,000 1,000,000,000100,000,000,0001,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 > 1s100,000 > 1m40s10,000,000 > 2.77h1,000,000,000 > 11.57d100,000,000,000 > 3.17a1,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 noprecisa, 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 datase 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 readonly, 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
ENGINES
LucidDB http://luciddb.sourceforge.net/
Engine principal deLucidDB
Se uso Java pensandoen la expansión del producto.
Acceso a repositorios de datos externos
Data
Para leer mas: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 APESOLhttp://www.apesol.org
Inscríbete en las listas de interés enhttp://apesol.org/listas.php
Conversemos en vivo enserver: irc.freenode.net
sala:#apesol