O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Re-Engineering PostgreSQL as a Time-Series Database

801 visualizações

Publicada em

Presented at All Things Open 2018
Presented by David Kohn with Timescale
10/23/18 - 11:45 AM - Databases track

Publicada em: Tecnologia
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Re-Engineering PostgreSQL as a Time-Series Database

  1. 1. TimescaleDB: Re-engineering PostgreSQL as a time-series database David Kohn R & D Engineer, Timescale david@timescale.com · github.com/timescale · Apache 2 License
  2. 2. Open Source (Apache 2.0) • github.com/timescale/timescaledb Join the Community • slack.timescale.com
  3. 3. Industrial Machines AI & ML Inferences Energy & Utilities Time-series Data is Everywhere Web/mobile Events Transportation & Logistics Financial Datacenter & DevOps
  4. 4. Of every type • Regular:  Machines and sensors • Irregular:  Web and machine events • Forward looking:  Logistics and forecasting • Derived data:  Inferences from AI/ML models
  5. 5. Time-series data is recording the change of your world
  6. 6. Time-series data is recording every datapoint as a new entry
  7. 7. Existing databases don’t work for time series Relational Databases NoSQL Databases Every other time-series database today is NoSQL Hard to scale Underperform on complex queries,
 are hard to use, and lead to data silos
  8. 8. 1 million+ downloads in <18 months
  9. 9. Empower Organizations to Analyze the Past, Understand the Present, and Predict the Future
  10. 10. Postgres 9.6.2 on Azure standard DS4 v2 (8 cores), SSD (premium LRS storage) Each row has 12 columns (1 timestamp, indexed 1 host ID, 10 metrics) Hard to scale
  11. 11. Postgres 9.6.2 on Azure standard DS4 v2 (8 cores), SSD (premium LRS storage) Each row has 12 columns (1 timestamp, indexed 1 host ID, 10 metrics) Hard to scale
  12. 12. B-tree Insert Pain 1 2010 1 10 13 24 2925 5Insert batch: 178 Memory Capacity: 2 NODES IN MEMORY WRITE TO DISK
  13. 13. B-tree Insert Pain 1 2010 1 10 13 24 2925 5Insert batch: 178 Memory Capacity: 2 NODES IN MEMORY WRITE TO DISK
  14. 14. 1 2010 1 10 13 24 2925 Insert batch: 8 5 17 B-tree Insert Pain Memory Capacity: 2 NODES IN MEMORY WRITE TO DISK
  15. 15. 10 13 B-tree Insert Pain 1 2010 1 24 2925 Insert batch: 8 5 17 Memory Capacity: 2 NODES IN MEMORY WRITE TO DISK
  16. 16. Challenge in scaling up • Indexes write to random parts of B-tree • As table grows large – Indexes no longer fit in memory – Random writes cause swapping Device: A Time: 01:01:01 Device: Z Time: 01:01:01 Device, Time DESC
  17. 17. Is there a better way?
  18. 18. • Ingest millions of datapoint per second • Scale to 100s billions of rows • Elastically scale up and out • Faster than Influx, Cassandra, Mongo, vanilla Postgres Scale & Performance • Inherits 20+ years of PostgreSQL reliability • Streaming replication, HA, backup/recovery • Data lifecycle: continuous rollups, retention, archiving • Enterprise-grade security Proven & Enterprise Ready • Zero learning curve • Zero friction: Existing tools and connectors work • Enrich understanding: JOIN against relational data • Freedom for data model, no cardinality issues SQL for time series TimescaleDB
 Scalable time-series database, full SQL Packaged as a PostgreSQL extension
  19. 19. >20x TimescaleDB vs. PostgreSQL (batch inserts) TimescaleDB 0.5, Postgres 9.6.2 on Azure standard DS4 v2 (8 cores), SSD (LRS storage) Each row has 12 columns (1 timestamp, indexed 1 host ID, 10 metrics) 1.11M METRICS / S
  20. 20. TimescaleDB vs. PostgreSQL SPEEDUP Table scans, simple column rollups ~0-20% GROUPBYs 20-200% Time-ordered GROUPBYs 400-10000x DELETEs 2000x TimescaleDB 0.5, Postgres 9.6.2 on Azure standard DS4 v2 (8 cores), SSD (LRS storage) Each row has 12 columns (1 timestamp, indexed 1 host ID, 10 metrics)
  21. 21. Enjoy the entire PostgreSQL ecosystem
  22. 22. Key-value store with indexed key lookup at high-write rates NoSQL champion: Log-Structured Merge Trees • Compressed data storage • Common approach for time series: use key <name, tags, field, time> +
  23. 23. NoSQL + LSMTs Come at a Cost • Significant memory overhead • Lack of secondary indexes / tag lock-in • Less powerful queries • Weaker consistency (no ACID) • No JOINS • Loss of SQL ecosystem +
  24. 24. Query Speedup Table scans, column rollups ~0% GROUPBYs 4-6x Time-ordered GROUPBYs 1450x Lastpoint 101xMongoDB TimescaleDB vs. MongoDB 20% Higher Inserts TimescaleDB 0.9.2, MongoDB 3.6, Azure standard D8s v3 (8 vCPU), 4 1-TB disks in raid0
  25. 25. Query Speedup Table scans, column rollups 2-44x GROUPBYs 1-3x Time-ordered GROUPBYs 1900x Lastpoint 1400x vs. Cassandra 10x Higher Inserts TimescaleDB 0.5, Cassandra 3.11.0, Azure standard DS4 v2 (8 cores), SSD (LRS storage) Each TimescaleDB row has 12 columns (1 timestamp, indexed 1 host ID, 10 metrics) Each Cassandra row has 2 columns (1 key, combo of tags + host + timestamp)
  26. 26. TimescaleDB 3 nodes Cassandra 30 nodes Ratio Write Throughput (metrics / sec) 956,910 695,294 138% Monthly Cost (Azure) $3,325 $33,251 10%
  27. 27. How?
  28. 28. Time-series workloads are different
  29. 29. Time-series • Primarily UPDATEs • Writes randomly distributed • Transactions to multiple 
 primary keys • Primarily INSERTs • Writes to recent time interval • Writes primarily associated
 with a timestamp OLTP
  30. 30. How it works
  31. 31. Time
 (older)
  32. 32. Time-space partitioning
 (for both scaling up & out) Time
 (older) Intervals 1) manually specified 2) automatically adjusted
  33. 33. Time-space partitioning
 (for both scaling up & out) Space Time
 (older) (hash partitioning) Intervals 1) manually specified 2) automatically adjusted
  34. 34. Time-space partitioning
 (for both scaling up & out) Chunk (sub-table) Space Time
 (older) (hash partitioning) Intervals 1) manually specified 2) automatically adjusted
  35. 35. Automatic Space-time Partitioning Chunks
  36. 36. Automatic Space-time Partitioning Chunks
  37. 37. But treat it like a single table Chunks • Indexes • Triggers • Constraints • Foreign keys • UPSERTs • Table mgmt Hypertable
  38. 38. TimescaleDB: Easy to Get Started CREATE TABLE conditions ( time timestamptz, temp float, humidity float, device text ); SELECT create_hypertable('conditions', 'time', ‘device', 4, chunk_time_interval => interval '1 week’); INSERT INTO conditions VALUES ('2017-10-03 10:23:54+01', 73.4, 40.7, 'sensor3'); SELECT * FROM conditions; time | temp | humidity | device ------------------------+------+----------+--------- 2017-10-03 11:23:54+02 | 73.4 | 40.7 | sensor3
  39. 39. Create partitions automatically at runtime. 
 Avoid a lot of manual work. CREATE TABLE conditions ( time timestamptz, temp float, humidity float, device text ); CREATE TABLE conditions_p1 PARTITION OF conditions FOR VALUES FROM (MINVALUE) TO ('g') PARTITION BY RANGE (time); CREATE TABLE conditions_p2 PARTITION OF conditions FOR VALUES FROM ('g') TO ('n') PARTITION BY RANGE (time); CREATE TABLE conditions_p3 PARTITION OF conditions FOR VALUES FROM ('n') TO ('t') PARTITION BY RANGE (time); CREATE TABLE conditions_p4 PARTITION OF conditions FOR VALUES FROM ('t') TO (MAXVALUE) PARTITION BY RANGE (time); -- Create time partitions for the first week in each device partition CREATE TABLE conditions_p1_y2017m10w01 PARTITION OF conditions_p1 FOR VALUES FROM ('2017-10-01') TO ('2017-10-07'); CREATE TABLE conditions_p2_y2017m10w01 PARTITION OF conditions_p2 FOR VALUES FROM ('2017-10-01') TO ('2017-10-07'); CREATE TABLE conditions_p3_y2017m10w01 PARTITION OF conditions_p3 FOR VALUES FROM ('2017-10-01') TO ('2017-10-07'); CREATE TABLE conditions_p4_y2017m10w01 PARTITION OF conditions_p4 FOR VALUES FROM ('2017-10-01') TO (‘2017-10-07'); -- Create time-device index on each leaf partition CREATE INDEX ON conditions_p1_y2017m10w01 (time); CREATE INDEX ON conditions_p2_y2017m10w01 (time); CREATE INDEX ON conditions_p3_y2017m10w01 (time); CREATE INDEX ON conditions_p4_y2017m10w01 (time); INSERT INTO conditions VALUES ('2017-10-03 10:23:54+01', 73.4, 40.7, ‘sensor3');
  40. 40. Chunking benefits
  41. 41. Chunks are “right-sized” Recent (hot) chunks fit in memory
  42. 42. Single node: Scaling up via adding disks • Faster inserts • Parallelized queries How Benefit Chunks spread across many disks (elastically!) either RAIDed or via distinct tablespaces
  43. 43. Writes Schema Changes Reads Multi-node: High availability and scaling read throughput
  44. 44. Multi-node: Scaling out across sharded primaries U nderdevelopm ent • Chunks spread across servers • Insert/query to any server • Distributed query optimizations (push-down LIMITs and aggregates, etc.)
  45. 45. Chunk-aware query optimizations
  46. 46. SELECT time, temp FROM data
 WHERE time > now() - interval ‘7 days’
 AND device_id = ‘12345’ Avoid querying chunks via constraint exclusion
  47. 47. Avoid querying chunks via constraint exclusion SELECT time, device_id, temp FROM data
 WHERE time > ‘2017-08-22 18:18:00+00’
  48. 48. Avoid querying chunks via constraint exclusion SELECT time, device_id, temp FROM data
 WHERE time > now() - interval ’24 hours’
  49. 49. Additional time-based query optimizations PG doesn’t know to use the index CREATE INDEX ON readings(time); SELECT date_trunc(‘minute’, time) as bucket, avg(cpu) FROM readings GROUP BY bucket ORDER BY bucket DESC LIMIT 10; Timescale understands time
  50. 50. Global queries but local indexes • Constraint exclusion selects chunks globally • Local indexes speed up queries on chunks – B-tree, Hash, GiST, SP-GiST, GIN and BRIN – Secondary and composite columns, UNIQUE* constraints
  51. 51. Optimized for many chunks • Faster chunk exclusion – Avoid opening / gather stats on all chunks during constraint exclusion: Decreased planning on 4000 chunks from 600ms to 36ms • Better LIMITs across chunks – Avoid requiring one+ tuple per chunk during MergeAppend / LIMIT
  52. 52. “ We've been using TimescaleDB for over a year to store all kinds of sensor and telemetry data as part of our Power Management database. We've scaled to 500 billion rows and the performance we're seeing is monstrous, almost 70% faster queries.” - Sean Wallace, Software Engineer 500B ROWS 400K ROWS / SEC 50K CHUNKS 5min INTERVALS
  53. 53. Efficient retention policies SELECT time, device_id, temp FROM data
 WHERE time > now() - interval ’24 hours’ Drop chunks, don’t delete rows avoids vacuuming
  54. 54. Is it just about performance?
  55. 55. Simplify your stack VS TimescaleDB
 (with JOINS) RDBMS NoSQL Application Application
  56. 56. Rich Time Analytics
  57. 57. Geospatial Temporal Analysis (with PostGIS)
  58. 58. Data Retention + Aggregations Granularity raw 15 min day Retention 1 week 1 month forever
  59. 59. Unlock the richness of your monitoring data TimescaleDB + PostgreSQL Prometheus Remote Storage Adapter + pg_prometheus Prometheus Grafana
  60. 60. pg_prometheus Prometheus Data Model in TimescaleDB / PostgreSQL CREATE TABLE metrics (sample prom_sample); INSERT INTO metrics VALUES (‘cpu_usage{service=“nginx”,host=“machine1”} 34.6 1494595898000’); • Scrape metrics with CURL: curl http://myservice/metrics | grep -v “^#” | psql -c “COPY metrics FROM STDIN” • New data type prom_sample: <time, name, value, labels>
  61. 61. Automate normalized storage SELECT create_prometheus_table(‘metrics’); Time 01:02:00
 01:03:00 01:04:00 01:04:00 01:04:00 Value 90 1024 70 900 70 Label {host: “h001”} {host: “h002”} {host: “1984” } {host: “super”} {host: “marshal”} Id 1 2 3 4 5 Label Id 1 1 2 2 5 Name CPU Mem CPU Mem IO Labels stored in separate host metadata table
  62. 62. Easily query auto-created view SELECT sample FROM metrics WHERE time > NOW() - interval ’10 min’ AND name = ‘cpu_usage’ AND Labels @> ‘{“service”: “nginx”}’; Columns: | sample | time | name | value | labels |
  63. 63. +
  64. 64. +
  65. 65. What’s Next?
  66. 66. 2PC Multi-node: Scaling out across sharded primaries U nderdevelopm ent Writes Reads Query planning + constraint exclusion
  67. 67. minute Continuous aggregations and hierarchical views U nderdevelopm ent Granularity raw hour
  68. 68. minute Continuous aggregations and hierarchical views U nderdevelopm ent Granularity raw hour
  69. 69. Tiered data storage and automated archiving U nderdevelopm ent SAN Time
 (older) archive_chunks (‘3 months’) move_chunks (‘1 week’, ssd, hdd)
  70. 70. Scale Full clustering Performance + ease-of-use Continuous data aggregations and intelligent hierarchical views Performance Lazy chunk management (index creation, reindex, CLUSTER) Ease-of-use Analytical features (gap filling, LOCF, fuzzy joins, etc.) Total Cost-of-Ownership Tiered data storage Automated data archiving
  71. 71. Open Source (Apache 2.0) • github.com/timescale/timescaledb Join the Community • slack.timescale.com

×