PostgreSQL Big Data

PostgreSQL y Big Data, Big Data y PostgreSQL. PostgreSQL y almacenamiento por columnas (columnar store). 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.

Transcript

1. PostgreSQL Big Data Álvaro Hernández Tortosa <aht@Nosys.es>
2. Acerca de mí • Álvaro Hernández Tortosa <aht@Nosys.es> • 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/
3. 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
4. ¿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 australiana http://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
5. Forks Big Data de PostgreSQL https://wiki.postgresql.org/wiki/PostgreSQL_derived_databases
6. 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
7. Almacenamiento por filas
8. Almacenamiento por filas: estructura de página (c) EnterpriseDB
9. 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
10. 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
11. Almacenamiento por columnas
12. 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
13. Formato ORC Block 1 Block 1 Block 2 Block 2 Block 3 Block 3 Block 4 Block 4 Block 5 Block 5 Block 6 Block 6 Block 7 Block 7 150K rows (configurable) 150K rows (configurable) 10K column values (configurable) per block
14. 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.
15. 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
16. file_fdw $ cp /etc/passwd /tmp/ psql aht=# 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_server OPTIONS (format 'text', filename '/tmp/passwd', delimiter ':', null '');
17. 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)
18. 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
19. 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
20. 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
21. 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)
22. 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 );
23. 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
24. 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%)
25. Pruebas básica select count(*) FROM pagecount count ------------ 1596072547 (1 row) PostgreSQL • 4m26s PostgreSQL + cstore + LZ • 2m8s (-52%)
26. 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%)
27. 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%)
28. PostgreSQL Big Data Álvaro Hernández Tortosa <aht@Nosys.es>