Looking to minimize costs or get more from your database investments? See what’s new in TimescaleDB 1.5, including how to use native compression and data tiering to significantly improve your database performance -- and tightly manage costs. During this video, you will: - See how native compression allows you to store more data in less actual storage - Understand how to use move chunks to optimize performance and cut costs - Hear how TimescaleDB users get 20x compression ratios - Learn about the resources and best practices you need to get started

1. How to Reduce Your Database
Total Cost of Ownership
with TimescaleDB
November 2019

2. Presenter
Bob Boule
Product Management

3. ● What’s New in TimescaleDB 1.5?
● Feature Deep Dive: Compression
● Feature Deep Dive: Move Chunks
● Questions
Agenda

4. THEME: Reduce Total Cost of Ownership (TCO) by optimizing use of storage
● Time-series use cases produce a LOT of data
● Users need cost effective and efficient way to store data
● Storage is usually the largest contributor to operational cost
● Users expects performant solution while delivering storage efficiencies
○ Ingestion and query performance cannot suffer
● Users need to be able to set a long term storage strategy for data
● Store data based on its access & usage pattern
What’s New in TimescaleDB 1.5?

5. What’s New in TimescaleDB 1.5?
Capability Description Availability
Native Compression Store more data with less actual storage. Community Edition
Data Tiering
(“move chunks”)
Optimizes performance + storage costs by
allowing you to map your data to the
appropriate storage technology.
Enterprise Edition

6. Reducing Total Cost of Ownership
Time-series
data
Time-series
data
STORAGE
Compression
enables you store
more time-series
data on less actual
storage.

7. Reducing Total Cost of Ownership
Time-series
data
Time-series
data
STORAGE
Compression
enables you store
more time-series
data on less actual
storage.
Time-series
data
Time-series
data
STORAGE
Time-series
data
Time-series
data
STORAGE
Data Tiering enables you
to target data to different
storage types, optimizing
cost & performance.

8. Native Compression
COMMUNITY
edition

9. Native Compression Overview
Compression reduces the overall storage footprint of your data saves $
● User can compression their data manually or by using a policy
● Compression can be applied to specific hypertables
● Once upgraded to 1.5, user can start applying compression policies to their
hypertables
NOTE: Upgrading to TSDB 1.5 does not automatically compress existing
data or start compressing new data

10. ● User drives compression policy based on:
○ Frequency of access
○ Query Characteristics (“Shallow and Wide” vs “Deep and Narrow”)
● Very adaptable:
○ Users can select “order by” and “segment by” to achieve best overall compression
Native Compression: Sample Strategy

11. Compression: How It Works
Defining how data will be organized
Use an “order by” parameter to move
“like” data closer together to enhance
compressibility and maintain
performance.
order by device_id

12. Compression: How It Works
Defining how data will be organized
Use “segment by” operator to further
group like data together.
segment by device_id

13. Using Compression: Manual
Use Case: User wants to compress chunks manually
In this use case we will identify a set of target chunks and compress them manually. Let's start by
identifying chucks more than 3 months old:
SELECT show_chunks('conditions', older_than => interval '3 days');
which will return a list of chunks. User can then compress one of these chunks using the following:
SELECT compress_chunk('_timescaledb_internal._hyper_1_2_chunk');

14. Using Compression: Policy
Use Case: User wants to compress chunks automatically based on age
In this case, as a user I have decided that I want to compress all chucks older than 60 days, without
any manual intervention.
SELECT add_compress_chunks_policy('cpu', '60d'::interval);
This command will set up a background job that will kick off every 15 minutes, looking for chunks that
are more than 60 days old and compressing them. We can see the job has been added by running:
SELECT * FROM _timescaledb_config.bgw_job WHERE job_type LIKE 'compress%';
which will return the Jobs in the system associated with compression

15. Compression
Summary
● Compression can be configured based on
user data model
● Compression strategy is driven by the user
● Real savings by reducing storage costs
without removing data
● Why is compression important:
○ Reduce total cost of ownership by
reducing storage costs
○ Allows user to retain more data
without the additional costs
COMMUNITY
edition

16. Data Tiering
(“move chunks”)
ENTERPRISE
edition

17. Move Chunks
● Reduce storage costs by leveraging more cost effective storage options
● Tier data based on usage / access pattern
● Optimize storage costs by moving infrequently used data to slower / more
cost effective storage
● Combined with compression will allow for overall reduced TCO based on
efficient use of storage

18. Move Chunks: Sample Strategy

19. Move Chunks: How It Works
First step: Create a new tablespace
Create a new tablespace, which will be backed by a new storage mount (in this example I have
mount the new storage to /mnt/postgres):
CREATE TABLESPACE tablespace_2 OWNER postgres LOCATION '/mnt/postgres';
Process of Moving the data:
SELECT move_chunk(chunk=>'_timescaledb_internal._hyper_1_2_chunk',
destination_tablespace=>'tablespace_2',
index_destination_tablespace=>'tablespace_2',
reorder_index=>'_timescaledb_internal._hyper_1_2_chunk_cluster_test_time_id
x', verbose=>TRUE);

20. Move Chunks: Use Cases

21. Data Tiering
Summary
● The ability to move data to cost effective
storage
○ As data ages and is less frequently
queried it can be moved to less
expensive storage
● Help spread the data out over multiple
arrays
● Leverages the ability to create tablespaces
in Postgres and back them with different
storage
ENTERPRISE
edition

22. Learn more
Native Compression Docs: tsdb.co/WhatsNewCompression
Move Chunks Docs: tsdb.co/WhatsNewMoveChunk
All products: tsdb.co/WhatsNewProducts
Get the latest news and join our community
● blog.timescale.com
● twitter.com/TimescaleDB
● github.com/timescale/TimescaleDB
● slack.timescale.com

23. Questions?