1. No category

cstore_fdw – Columnar store
for analytic workloads
Hadi Moshayedi &
Ben Redman
What is CitusDB?
•  CitusDB is a scalable analytics database
that extends PostgreSQL
–  Citus shards your data and automa/cally parallelizes your queries –  Citus isn’t a fork of PostgreSQL. Rather, it hooks onto the planner and executor for distributed query execu/on. –  Always rebased to newest PostgreSQL version –  Na/vely supports new data types and extensions master node (extended PostgreSQL) shard and shard placement metadata A
C C D
A
1 shard = 1 PostgreSQL table . . . . worker node #1 (extended PostgreSQL) worker node #2 (extended PostgreSQL) worker node #3 (extended PostgreSQL) Talk Overview
1.  Why customers want columnar stores
2.  cstore_fdw live demo
3.  cstore_fdw file layout
4.  Benchmarks
5.  Further Improvements
700 columns
Id Sz Ln Ht … … … … … … … … … … … 30M
rows
1 4 3 4 … … … … … … … … … … … 2 4 11 3 … … … … … … … … … … … 3 1 4 2 … … … … … … … … … … … 4 8 4 12 … … … … … … … … … … … … 4… … … … … … … … … … … … … … … 4… … … … … … … … … … … … … … … 4… … … … … … … … … … … … … … … Example SQL query
SELECT weight, AVG(price), MAX(price) FROM items WHERE quantity > 100 AND last_stock_date < ‘2013-­‐10-­‐01’ GROUP BY weight; Row-oriented store
Id … price … … quant … … last_stm … … … … … weight 1 … 3.90 … … 31 … … 2013-­‐… … … … … … 0.6 2 … 13 … … 70 … … 2010-­‐… … … … … … 0.8 3 … 4.25 … … 432 … … 2013-­‐… … … … … … 1 4 … 4 … … 45 … … 2013-­‐… … … … … … 6 4… … 95 … … 37 … … 2013-­‐… … … … … … 0.6 4… … 59 … … 90 … … 2012-­‐… … … … … … 1.5 … Row-oriented store
Id … price … … quant … … last_stm … … … … … weight 1 … 3.90 … … 31 … … 2013-­‐… … … … … … 0.6 2 … 13 … … 70 … … 2010-­‐… … … … … … 0.8 3 … 4.25 … … 432 … … 2013-­‐… … … … … … 1 4 … 4 … … 45 … … 2013-­‐… … … … … … 6 4… … 95 … … 37 … … 2013-­‐… … … … … … 0.6 4… … 59 … … 90 … … 2012-­‐… … … … … … 1.5 … Row-oriented store
Id … price … … quant … … last_stm … … … … … weight 1 … 3.90 … … 31 … … 2013-­‐… … … … … … 0.6 2 … 13 … … 70 … … 2010-­‐… … … … … … 0.8 3 … 4.25 … … 432 … … 2013-­‐… … … … … … 1 4 … 4 … … 45 … … 2013-­‐… … … … … … 6 4… … 95 … … 37 … … 2013-­‐… … … … … … 0.6 4… … 59 … … 90 … … 2012-­‐… … … … … … 1.5 … Row-oriented store
Id … price … … quant … … last_stm … … … … … weight 1 … 3.90 … … 31 … … 2013-­‐… … … … … … 0.6 2 … 13 … … 70 … … 2010-­‐… … … … … … 0.8 3 … 4.25 … … 432 … … 2013-­‐… … … … … … 1 4 … 4 … … 45 … … 2013-­‐… … … … … … 6 4… … 95 … … 37 … … 2013-­‐… … … … … … 0.6 4… … 59 … … 90 … … 2012-­‐… … … … … … 1.5 … Cost of row storage
•  Read 700 columns instead of 4
•  >39 GB of unnecessary I/O
Input
Type
Estimated Input Cost to query
Rate
performance
Memory
10 GB/s
3.9 seconds
SSD
600 MB/s
>60 seconds
Example SQL query
SELECT weight, AVG(price), MAX(price) FROM items WHERE quantity > 100 AND last_stock_date < ‘2013-­‐10-­‐01’ GROUP BY weight; Column-oriented store
Id sz price … … quant … … last_stm … … … … … weight 1 4 3.90 … … 31 … … 2013-­‐… … … … … … 0.6 2 3 13 … … 70 … … 2010-­‐… … … … … … 0.8 3 2 4.25 … … 432 … … 2013-­‐… … … … … … 1 4 4 4 … … 45 … … 2013-­‐… … … … … … 6 4… 19 95 … … 37 … … 2013-­‐… … … … … … 0.6 4… 2 59 … … 90 … … 2012-­‐… … … … … … 1.5 … Column-oriented store
Id sz price … … quant … … last_stm … … … … … weight 1 4 3.90 … … 31 … … 2013-­‐… … … … … … 0.6 2 3 13 … … 70 … … 2010-­‐… … … … … … 0.8 3 2 4.25 … … 432 … … 2013-­‐… … … … … … 1 4 4 4 … … 45 … … 2013-­‐… … … … … … 6 4… 19 95 … … 37 … … 2013-­‐… … … … … … 0.6 4… 2 59 … … 90 … … 2012-­‐… … … … … … 1.5 … Column-oriented store
Id sz price … … quant … … last_stm … … … … … weight 1 4 3.90 … … 31 … … 2013-­‐… … … … … … 0.6 2 3 13 … … 70 … … 2010-­‐… … … … … … 0.8 3 2 4.25 … … 432 … … 2013-­‐… … … … … … 1 4 4 4 … … 45 … … 2013-­‐… … … … … … 6 4… 19 95 … … 37 … … 2013-­‐… … … … … … 0.6 4… 2 59 … … 90 … … 2012-­‐… … … … … … 1.5 … Columnar Store Motivation
•  Read subset of columns to reduce I/O
•  Better compression
–  Less disk usage –  Less disk I/O Talk Overview
1.  Why customers want columnar stores
2.  cstore_fdw live demo
3.  cstore_fdw file layout
4.  Benchmarks
5.  Further Improvements
Talk Overview
1.  Why customers want columnar stores
2.  cstore_fdw live demo
3.  cstore_fdw file layout
4.  Benchmarks
5.  Further Improvements
Current Approaches to Columnar Stores
1.  Fork a popular database, swap in your
storage engine, and never look back
2.  Develop an open columnar store format
for the Hadoop Distributed Filesystem
(HDFS)
3.  Use PostgreSQL extension machinery for
in-memory stores / external databases
ORC File Layout benefits
1.  Columnar layout – reads columns only
related to the query
2.  Compression – groups column values
(10K) together and compresses them
3.  Skip indexes – applies predicate
filtering to skip over unrelated values
150K rows In a stripe (configurable) Block 1 Block 2 Block 3 Block 4 Block 5 Block 6 Block 7 10K column values (configurable) per block Compression
•  Current compression method is PG_LZ
from PostgreSQL core
•  Easy to add new compression methods
depending on the CPU / disk trade-off
•  cstore_fdw enables using different
compression methods at the column
block level
Table sizes normalized to 1.0
Drawbacks to ORC
•  Support for limited data types. Each data
type further needs to have a separate
code path for min/max value collection
and constraint exclusion.
•  Gathering statistics from the data and
table JOINs are an afterthought.
Talk Overview
1.  Why customers want columnar stores
2.  cstore_fdw live demo
3.  cstore_fdw file layout
4.  Benchmarks
5.  Further Improvements
Recent Benchmark Results
•  TPC-H is a standard benchmark
•  Performed in-memory, SSD, and HDD
tests on 10 GB of data
•  Used m2.2xlarge and m3.2xlarge on EC2
•  Compared vanilla PostgreSQL, cstore_fdw,
cstore_fdw with compression
10GB of uncached data on m2.2xlarge
10GB of uncached data on m3.2xlarge
Total issued disk I/O measures with iotop
10GB of cached data on m2/m3.2xlarge
Talk Overview
1.  Why customers want columnar stores
2.  cstore_fdw live demo
3.  cstore_fdw file layout
4.  Benchmarks
5.  Further Improvements
Vectorization
•  What if data fits in memory?
•  PostgreSQL’s execution model:
–  One Tuple at a Time –  High Overhead Vectorization
•  Improvement:
–  Batch of Values at a Time –  Decreases the Overhead –  Beaer U/liza/on of CPU •  Internship Project:
–  Can Güler Vectorization, Simple Aggregates
Vectorization, GROUP BY
More vectorization info
https://github.com/citusdata/
postgres_vectorization_test 1.1 Release
•  cstore_fdw is an open source project actively
in development: github.com/citusdata/
cstore_fdw
–  Improved sta/s/cs gathering –  Automa/c management of table filenames –  Management of table file data Future Work
–  Improve memory usage –  Na/ve Delete / Insert / Update support –  Improve read query performance (vectorized execu/on!) –  Different compression codecs –  Many more; contribute to the discussion on GitHub! •  cstore_fdw: Open source columnar store
fdw for PostgreSQL
•  Improves query times (1.1x-2x), reduces disk
I/O, and reduces disk utilization (3x-4x)
•  Data layout is based on ORC (indexes,
compression)
•  Uses foreign wrapper APIs – full type support,
optimization, and easy installation
•  Future perf improvements - vectorization
cstore_fdw – Columnar
Store for Analytic Workloads
Hadi Moshayedi – hadi@citusdata.com
Ben Redman – ben@citusdata.com