How to Reduce Your Database Total Cost of Ownership with TimescaleDB
The document discusses how TimescaleDB 1.5 can reduce the total cost of ownership for databases by optimizing storage through features like native compression and data tiering. It highlights the importance of efficiently managing time-series data, allowing users to store more data while maintaining performance and reducing operational costs. Additionally, it provides use cases for manual and automatic compression policies, as well as strategies for moving data to cost-effective storage as it ages.
● What’s Newin TimescaleDB 1.5?
● Feature Deep Dive: Compression
● Feature Deep Dive: Move Chunks
● Questions
Agenda
4.
THEME: Reduce TotalCost 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 inTimescaleDB 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 Costof Ownership
Time-series
data
Time-series
data
STORAGE
Compression
enables you store
more time-series
data on less actual
storage.
7.
Reducing Total Costof 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.
Native Compression Overview
Compressionreduces 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 drivescompression 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 ItWorks
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 ItWorks
Defining how data will be organized
Use “segment by” operator to further
group like data together.
segment by device_id
13.
Using Compression: Manual
UseCase: 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
UseCase: 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 canbe 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
Move Chunks
● Reducestorage 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
Move Chunks: HowIt 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);
Data Tiering
Summary
● Theability 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 CompressionDocs: 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