Source
tof•

I was wondering about this, thank you for the link !

1
m_user_name•

Is timescaledb a fork of postgresql?

1
RobAtticusOP•

Nope, it's an extension to PostgreSQL. You can have non-TimescaleDB databases (and tables) side by side with ones using TimescaleDB.

1
m_user_name•

I read the article, but I don't guess I really understand what is so cool about timescale vs a regular postgresql install (but I'm not exactly trying to run a data farm either).

2
RobAtticusOP•

Well TimescaleDB is specifically designed for time series workloads. We can take assumptions about time series workloads (e.g. mostly INSERTs with little/no UPDATEs, data being written is recent in time, etc) and apply optimizations to make writing and querying fast while still giving users the power of full SQL/relational data models. Since it is a PostgreSQL extension, it also allows you to store time series and metadata in a single database which helps people simplify their stack, i.e., not using PostgreSQL for metadata and a NoSQL solution for time series. And on top of that we're adding time series specific features/functions (e.g. time_bucket which allows arbitrary sized time groupings) to make it -- we think -- the best solution for time series needs.

There are a couple other posts on the blog that explains various ways we solve some of these issues and provide performance numbers if you're curious. Though, as you said, maybe it doesn't fit your workload, which is okay too :)

2
NihilCredo•

Hmm. I'm currently developing an event-sourced Postgres database. The event table isn't really the kind of time-series data you're targeting, since it hardly if ever gets queried in the aggregate, but it is an append-only table that might eventually scale up to millions-to-billions of rows.

Would using TimescaleDB offer meaningful advantages over Postgres 10's native partitioning (which is what I'm currently using), or would I be opening myself up to unnecessary surprises? Like, from skimming your docs, create_hypertable(chunk_time_interval => whatever) seems a much nicer UX than manually creating the individual chunk partitions, even if I never use anything else.

1
its_never_lupus•

What are the options for storing irregular timeseries data in TimescaleDB, i.e. for monitoring a piece of equipment over several years where various sensors are added and removed over it's lifetime?

1
RobAtticusOP•

That should work fine. We support adding and removing columns to the schema like a regular table. Or if you mean devices being decommissioned or added that should also be fine. We are working on adaptive chunking so that as the number of data inflow increases or decreases the chunks dynamically size to keep things performant, but otherwise things should work well.

1
its_never_lupus•

I should have said, I'm thinking of storage efficiency.

Suppose 500 different sensors are connected at some point over the lifetime of the project - this could be stored by making 500 columns in the table, with null values allowed. But only a few are in use at any one time so typically >95% of cells would be empty. Is this horribly inefficient or would the engine handle this case?

1
ants_a•

The batch size = 1000 graph is a bit cheeky. The number of partitions axis does not start from 1, presumably because it would show the insert overhead.

1