Upload
nosys
View
1.233
Download
3
Embed Size (px)
DESCRIPTION
Las bases de datos relacionales orientan su procesado, por lo general, a registros, con todas las columnas que contienen. Sin embargo, para procesado de grandes volúmenes de información hay otras técnicas de almacenamiento, como las orientadas a columnas, que permiten una eficiencia muy superior para determinadas operaciones y habilitan compresión transparente para reducir los requisitos de almacenamiento. Bien, pues gracias a CitusData, PostgreSQL ya tiene columnar store, y es software libre. En la charla de junio de PostgreSQL España vamos a hacer un estudio de esta solución, presentar la teoría de las bases de datos orientadas a columnas, y hacer una demo práctica :)
Citation preview
Acerca de mí
● Álvaro Hernández Tortosa <[email protected]>● Fundador y Director Técnico en NOSYS● ¿Qué hacemos en NOSYS?
✔ Formación, consultoría y desarrollo de software con PostgreSQL (y Java)✔ Partners de EnterpriseDB✔ Formación avanzada en Java con Javaspecialists.eu: Java Master Course y Java Concurrency Course✔ Partners de Amazon AWS. Formación y consultoría en AWS
● Twitter: @ahachete● LinkedIn: http://es.linkedin.com/in/alvarohernandeztortosa/
Big Data
"Big data is high Volume, high Velocity, and/or high Variety information assets that require new forms of
processing to enable enhanced decision making, insight discovery and process optimization."
Gartner, 2012
Big Data (“las 3 Vs”) hace referencia a volúmenes de información tan enormes que las técnicas o sistemas “tradicionales” de procesado de información no bastan,y es preciso adoptar nuevas técnicas.
Se considera Big Data > 100GB hasta PB - EB
¿Es PostgreSQL Big Data?
● Hay casos de bbdds PostgreSQL de TBs:➔ 6 TB: BTP (http://www.slideshare.net/nosys/proyecto-billion-detablaspgdayec2013)➔ 20 TB: Instagram (cuando fue comprada)➔ 75 TB: llamadas de Comptel en la UE➔ 200 TB: una empresa australianahttp://postgresql.1045698.n5.nabble.com/Examples-of-Large-Datasets-on-Postgres-td5773141.html
● Pero no escala horizontalmente (sol: plproxy, postgres_fdw)● No soporta query paralela (sol: Postgres-XC, -XL y pgpool)● No implementa técnicas Map-Reduce (sol: hadoopfdw)● No tiene (¡tenía!) columnar storage
Forks Big Data de PostgreSQL
https://wiki.postgresql.org/wiki/PostgreSQL_derived_databases
Almacenamiento por filas
● Las bbdds relacionales normalmente almacenan los datos por filas● Normalmente N filas se agrupan en páginas de tamaño (8Kb por defecto en PostgreSQL)
● Cuando se hace una query tipo “big data” (agregados de muchas filas, consultando un subconjunto de columnas):
➔ Se han de leer las filas completas➔ La carga de I/O es mucho mayor de la necesaria➔ Campos largos perjudican aún más➔ Contrariamente a lo que parece, externalizar campos a otras tablas (¿normalización?)puede ayudar
Almacenamiento por filas
Almacenamiento por filas:estructura de página
(c) EnterpriseDB
Almacenamiento por filas
● Supongamos una tabla de 30M registros, 700 columnas● Una query como:SELECT id, AVG(price), MAX(price) FROM items WHERE quantity > 100 AND last_stock_date < ‘2013-10-01’ GROUP BY weight;
genera 39 GB de I/O innecesarios
Input Type
Estimated Input Rate
Cost to query performance
Memory 10 GB/s 3.9 seconds
SSD 600 MB/s >60 seconds
Almacenamiento por columnas
● Como su nombre indica, se guarda cada columna de manera independiente
● Tiene como ventajas:✔ Sólo se “miran” las columnas usadas en la query✔ Dado que el tipo de datos es uniforme por columna, se puede habilitar compresión transparente✔ Si los datos están ordenados: se pueden crear índices min-max/skip lists para no leer bloques de valores filtrados por la query
● Obviamente, tienen más overhead para consultas de pocas filas o por primary key
Almacenamiento por columnas
Formatos de almacenamiento por columnas
● Record Columnar File (RCFile)✔ Facebook, OSU, y Academia China de Ciencias✔ Primero particiona horizontalmente, luego vertical
● ORC (Optimized RCFile).✔ 2ª generación.✔ Desarrollado por Hortonworks y Facebook✔ Soporta índices (ligeros) en el propio fichero✔ Y diferentes mecanismos de compresión en el mismo fichero
Formato ORC
Block 1Block 1Block 2Block 2Block 3Block 3Block 4Block 4Block 5Block 5Block 6Block 6Block 7Block 7
150K rows(configurable)
150K rows(configurable)
10K column values(configurable) per block
Foreign Data Wrappers
● Los FDWs son un mecanismo, un API de PostgreSQL para conectar a fuentes de datos externas arbitrarias.
● El procedimiento para crear un FDW es crear un SERVER y a continuación una FOREIGN TABLE por cada fuente de datos que se quiera representar como una tabla.
● La creación del FOREIGN TABLE puede llevar opciones para configurar la fuente de datos (y autenticación, por ejemplo).
● Una vez creada la tabla, funciona como una tabla “normal” y se puede gestionar con SQL, hacer JOINs, etc.
Foreign Data Wrappers
● FDWs relevantes:➔ file_fdw: para ficheros CSV (lectura)➔ json_fdw: lee ficheros JSON (soporta gzip), “aplanando” la estructura (columna “a.b.c”) y parseando dinámicamente el fichero➔ postgres_fdw: acceso (r/w) a otra base de datos PostgreSQL➔ {oracle,mysql,jdbc,odbc,mongo,redis,...}_fdw➔ twitter_fdw➔ s3_fdw➔ multicorn
http://wiki.postgresql.org/wiki/Foreign_data_wrappers
file_fdw
$ cp /etc/passwd /tmp/
psqlaht=# create extension file_fdw;
aht=# CREATE SERVER file_server FOREIGN DATA WRAPPER file_fdw;
aht=# CREATE FOREIGN TABLE passwd (username text, pass text, uid int4, gid int4, gecos text,home text, shell text) SERVER file_serverOPTIONS (format 'text', filename '/tmp/passwd', delimiter ':', null '');
file_fdw
aht=> SELECT * FROM passwd LIMIT 5;
username | pass | uid | gid | gecos | home | shell
----------+------+-----+-------+--------+-----------+-----------
root | x | 0 | 0 | root | /root | /bin/bash
daemon | x | 1 | 1 | daemon | /usr/sbin | /bin/sh
bin | x | 2 | 2 | bin | /bin | /bin/sh
sys | x | 3 | 3 | sys | /dev | /bin/sh
sync | x | 4 | 65534 | sync | /bin | /bin/sync
(5 rows)
CitusData cstore
● Es un FDW para almacenamiento columnar
● Basado en el formato de fichero ORC
● Soporta compresión (LZ), recolección de estadísticas y skip indexes (min/max para grupos de 10K registros)
● Lanzado como software libre (Apache 2.0)
● Soporta PostgreSQL 9.3 y 9.4
● https://github.com/citusdata/cstore_fdw
CitusData cstore: compilación e instalación
$ sudo locale-gen es_ES.UTF-8
$ sudo apt-get install postgresql-9.3 \ postgresql-server-dev-9.3 protobuf-c-compiler \ libprotobuf-c0-dev build-essential git
$ git clone https://github.com/citusdata/cstore_fdw.git
$ cd cstore_fdw$ make$ sudo make install
CitusData cstore: benchmarks de Citus
http://www.citusdata.com/blog/76-postgresql-columnar-store-for-analytics
http://www.citusdata.com/blog/78-postgresql-columnar-store-benchmarks-on-ssds
Benchmark propio
● Se utiliza una instancia i2.2xlarge de AWS para cada tipo(8 cores, 61GB RAM, 2x800GB SSD, $1,7/h)
● Fuente de datos: Wikipedia Page Traffic Statistics(wikistats, limitados a los 15 primeros días de oct/2008)https://aws.amazon.com/datasets/2596
● Para importar los datos, se utiliza un volumen clonado del snapshot snap-753dfc1c de 320GB y 4000iops ($0,6/h).
● us-east-1 (total aprox: $4/h)
Creación tablas e importación datos
CREATE EXTENSION cstore_fdw;CREATE SERVER cstore_server FOREIGN DATA WRAPPER cstore_fdw;CREATE FOREIGN TABLE pagecount ( projectcode text, pagename text, pageviews bigint, bytes bigint, t timestamp) SERVER cstore_server OPTIONS( filename '/cstore/bigdata', compression 'pglz');CREATE TABLE pagecount2 ( projectcode text, pagename text, pageviews bigint, bytes bigint, t timestamp);
Creación tablas e importación datos
/mnt/wikistats/pagecounts$ for i in pagecounts-2008100* pagecounts-2008101[0-5]*; \do \timestamp=`echo $i | sed 's/pagecounts-\([0-9][0-9][0-9][0-9]\)\([0-9][0-9]\)\([0-9][0-9]\)-\([0-9][0-9]\)\([0-9][0-9]\)\([0-9][0-9]\).gz/\1-\2-\3 \4:\5:00/'` ; \gunzip -dc $i |recode latin1..utf8 \|awk -v t="\t$timestamp\t" ' {print $0, t}' \|psql -c "\copy pagecount from stdin with csv delimiter ' ' quote E'\t'" bigdata; \done
Tiempo de carga y uso de disco
PostgreSQL
● Carga: 7987 s
● Uso de disco: 138.499MB
PostgreSQL + cstore + LZ
● Carga: 11550 s (+31%)
● Uso de disco: 27.211MB (-80%)
Pruebas básica
select count(*) FROM pagecount count ------------ 1596072547 (1 row)
PostgreSQL
● 4m26s
PostgreSQL + cstore + LZ
● 2m8s (-52%)
Prueba de agregados
select distinct pagename, max(pageviews) from pagecount group by pagename order by 2 desc limit 10
pagename | max
--------------------------------------------------------+---------
Special:Search | 1063416
Main_Page | 434647
Spezial:Suche | 229608
Especial:Search | 163529
%E7%89%B9%E5%88%A5:Search | 152216
Special:Random | 144041
...
PostgreSQL
● 25m50s
PostgreSQL + cstore + LZ
● 23m37s (-9%)
Prueba de índices
select pagename, max(pageviews) as pageviews FROM pagecount where t between '2008-10-10' and '2008-10-11' group by pagename order by 2 desc limit 10
pagename | pageviews
--------------------------------------------------------+-----------
Special:Search | 910156
Main_Page | 376144
Spezial:Suche | 167932
Especial:Search | 131709
%E7%89%B9%E5%88%A5:Search | 111549
Special:Random | 92089
Special:Recherche | 73066
...
PostgreSQL
● 7m29s
PostgreSQL + cstore + LZ
● 1m56s (-74%)