Recap: Getting Started with TimescaleDB and Defining Best Practices

Watch the webinar recording to learn more about TimescaleDB’s internals and how to leverage time-series specific features.

This week, we hosted the Getting Started with TimescaleDB and Defining Best Practices webinar. The purpose of this webinar was to cover basics such as installation, configuration, and data modeling for new users. Additionally, we share best practices gleaned from our community on how to get the best performance when inserting and querying data.

Furthermore, we discussed:

• Internals of TimescaleDB and how we leverage PostgreSQL
• Setting up TimescaleDB with the best chunk size for your use case
• Choosing the best hardware when using TimescaleDB
• Specific time-series functions and how they work
• Automated data retention, data reordering, continuous aggregates
• Different ways to deploy TimescaleDB including Timescale Cloud

Towards the end of the webinar, David shared more information on TimescaleDB native compression and how it will work. Native compression is currently in beta and will be released in version 1.5 this October. Additionally, he discussed the concept behind TimescaleDB scale-out clustering which is in currently in development.

WATCH NOW:

Throughout the webinar, we paused to take questions from attendees. Here is a selection plus some additional tidbits:

Does chunking work in clustered environments?

Yes, we do support clustering via Postgres replication. We support synchronous replicas for high availability and scaling queries. To learn more about replication, check out this blog post.

Is it better to use a wide or narrow table?

While you can use both, it’s easier to add different data types to a wider table. Additionally, a wide table will allow you to reduce JOINs by storing columns that are accessed together in the same table.

Can Timescale replace processes historians like OSIsoft Pi?

We do see a fair number of people using TimescaleDB as a replacement. Some process historians have specific ways you should model your data within their system. However, TimescaleDB has the ability to create your own relational tables so if you are willing to do the work with data modeling and tags, TimescaleDB can be a very effective replacement (or can be used in conjunction with a historian).

Gapfill is only available in the Community edition, what does this mean?

Correct, time_bucket_gapfill is in the TimescaleDB Community edition. The basic terms are that you can’t be a database as a service provider (read more here about the Timescale License). Otherwise it’s free to use. If you have more specific questions about features and licencing, please enter them in our #timescale-licensing channel in Slack.

How will native compression in TimescaleDB 1.5 compare with ZFS block compression?

At a high level, we are providing data type specific compression and we also will allow you to modify how the data is ordered on a smaller level than ZFS allows. So for a number of queries, it speeds things up quite effectively and we’ve seen that it is significantly more compressed. We are seeing between 10-30x better compression on our customers datasets compared to what it was before.

How are alarms and events handled within TimescaleDB?

In general this is handled outside the database. TimescaleDB is designed to query and store event data instead of events that trigger a reaction. We often see people using third party tools such as Grafana in conjunction with TimescaleDB for alerting. Although we’d be happy to hear more about what users are looking for and we would consider building these types of features in the future. You can always get in touch with us via our public Slack channel.

We hope you enjoyed learning more about TimescaleDB. If you have other questions, feel free to leave a comment in the section below.