6 ms·

TimescaleDB 2.0 released, now distributed multi-node

213 points by manigandham 6y ago

robertlagrant 6y ago
Really, really interesting. I struggled to find prices for the cloud editions?
- hnmullany 6y ago
  https://www.timescale.com/cloud-pricing https://www.timescale.com/cloud-pricing
  - lights0123 6y ago
    there's also https://www.timescale.com/forge#cloud-pricing https://www.timescale.com/forge#cloud-pricing
    - robertlagrant 6y ago
      Thanks both! Could not find that!
  - johnthescott 6y ago
    getting a javascript error in brave browser on mac. says option not defined.
    - mfreed 6y ago
      Sorry about that! Can you email me any screenshots / info at mike (at) timescale? Thanks!
parhamn 6y ago
> But a lot of NoSQL adoption was a knee-jerk reaction, along the lines of, “relational databases don’t scale, so I need a NoSQL database.” I don't agree with this. If you view relational-ness as a spectrum its not so simple. I think part of this knee-jerk reaction was because we over advised things like "denomralize everything" which lead to these monstrous schema diagrams that effected everything in the application pipeline: query performance, permissions, caching, transaction isolation, realtime capabilities, understandability, schema management nightmares, and more. In fact the world proved through NoSQL that a lot of what hyper-relational models we're providing us weren't required to run a business. And you could succeed and do things quickly when taking an extreme stance against relations. I think the average app should probably revert to something in the middle. I've been building applications recently with only acyclical hierarchical relationships. Forcing that constraint up-front does tie your hands a bit but it makes EVERYTHING a ton easier once you design your models around it.
- vamega 6y ago
  Can you expand on what you mean by an acyclical hierarchal relationship?
- merb 6y ago
  actually I think the typical application should mix "NoSQL" paradigmas and relational. consider a Offer model, do I really need OfferPosition's as an own table or can I include them via something like "jsonb".
- mfreed 6y ago
  One of interesting things we’ve found is that the typical data models we’ve seen in TimescaleDB (and time-series workloads in general) is that, while having JOINs and additional tables with metadata, business info, etc. is super useful -- and missing from most other time-series databases, leading to frustrating polyglot solutions that deploy them alongside Postgres/MongoDB/whatever -- it’s much less common to see the terribly deep snowflake schema patterns that came to dominate OLAP, with levels-upon-levels of normalization. And certainly the fact that your time-series hypertable in TimescaleDB can also store JSON, given Postgres’ underlying capabilities, also helps here and thus provides developers with flexibility given their application/performance needs.
- jayd16 6y ago
  It's a weasel statement that only claims to "a lot" of user sentiment. It's not something you can easily disagree with because the claim is so vague.
- tehlike 6y ago
  Postgres is hell of a no-sql database :)
- eloff 6y ago
  I think NoSQL works for a very limited number of cases. Most of the time you just end up moving all the schema checking and integrity checking (foreign key enforcement) to the application level and then you're squarely worse off. Plus MongoDB, which is the poster child of the revolution, has been a technical pile of shit for a decade. It's slower than JSONB on Postgres, and loses data in the default configuration, was insecure in the default configuration, failed Aphyr's Jepsen distributed system consistency tests every time - in other words promised things about consistency that were lies in their documentation. They have improved a lot, but I feel so sorry for people who jumped on that bandwagon early. My interest lies in databases and database internals, and I spent 8 years building databases in my spare time. I always advise everyone that they should use a relational database unless they are very, very sure their requirements don't require it and won't ever require it. It's much easier to start with Postgres and switch to NoSQL later if you really need to go that way than to do it the other way around. Most times you find you don't need to switch to NoSQL. The imagined hordes of users never materialized to overwhelm your trusty relational database.
akulkarni 6y ago
Hi all, thanks for the reading the post. We're very excited to finally launch TimescaleDB 2.0. In fact, users have already been running multi-node TimescaleDB in continuous daily use for many months, including a 22-node cluster by a Fortune 100 tech company ingesting more than a billion rows per day. So this product is already quite robust :-D
robertlagrant 6y ago
I'll nominate myself as silly question asker. Has this been used as the persistence for an event sourcing service? Does that sound like a good/terrible idea? Does it play nicely with SQLAlchemy?
- mfreed 6y ago
  Yes, works with SQLAlchemy. (Like many ORMs there are a couple things to be aware of, but plenty StackOverflow questions about these already :) And yes, people use it for event sourcing. Often see this in various product analytics use cases.
  - ryanbooz 6y ago
    Although I can't point to a specific application that's currently using TimescaleDB for an event sourcing service (I assume you're talking about the design pattern), it would be a great use case. Change in state over time is perfect time-series scenario. As for SQLAlchemy, TimescaleDB is fully PostgreSQL compliant, so it will work out of the box. There will be a few nuances that need to be considered, particularly when writing queries that use some of our additional time-series functions like time_bucket. But day-to-day ORM CRUD patterns should work as you expect!
    - robertlagrant 6y ago
      Thank you (both of you!). Agreed - I mean the design pattern, but I was being a bit vague.
    - johnthescott 6y ago
      are pg extensions supported? -j
      - mfreed 6y ago
        Yes, TimescaleDB plays friendly with most PG extensions. And Timescale Cloud comes pre-loaded with many of them - https://kb.timescale.cloud/en/articles/2754991-supported-postgresql-extensions https://kb.timescale.cloud/en/articles/2754991-supported-pos...
gabereiser 6y ago
This is so good, the features, the licensing, all of it. I'm not going to argue the use-case or NewSQL vs NoSQL or anything but for someone who wants PostgreSQL-level knowledge transfer working with time series data (audit logs, event history, change management, etc), this is amazing! Good work!
- akulkarni 6y ago
  Thank you! Great set of use cases as well :-)
eloff 6y ago
Wow, this is a big deal. A free, distributed timescale database built on top of trusty Postgres, with column oriented, compressed storage for the time series data. Also as I've stated before on HN, I love the new license which gives you almost all the freedoms of open source software while still letting TimescaleDB create a profitable business and not get squashed by AWS - which benefits nobody. I have lot's of questions: Queries on distributed hypertables are run across the cluster, but what about regular queries to regular tables? Write transactions obviously need to happen in one server, but is there a way to split read queries across the cluster? I don't know if regular table data is duplicated across data nodes, or if it's only on the access node and joined transparently to the result set from the distributed hypertable query. There are 3 kinds of server types for the cloud offering on AWS, IO, compute, or storage optimized. These seem to imply the database storage goes on instance storage, not EBS. This performs much better than EBS, especially on the high IO NVMe instances AWS offers. It also offers more predictable performance and tail latency because there is no network involved, no distributed block storage system (and EBS has had more than it's fair share of outages.) Is this true? I know compose.io (IBM) does this for their managed PostgreSQL for similar reasons. I'd like to compare the pricing to RDS for same-sized instances + storage, with moderate workload so I can get a feel for the markup on the managed service and know at at a glance, ok, this is going to cost me 50% more than RDS but I also get all these TimescaleDB features. I'd also like to see some performance comparisons, just for regular read + write workloads on Postgres, because if I'm right about using instance storage vs EBS the same sized hardware will give more transactions per second for TimescaleDB.
- mfreed 6y ago
  Thanks for all the questions @eloff! I might try to separate responses for hopefully some threading :) The software in our architecture is actually unified: You spin up K instances of TimescaleDB, log into one of them and then call "add_data_node" to attach others and data nodes, and "create_distributed_hypertable" to make this node the access node _for that particular hypertable_. In fact, you can explicitly specify different data nodes as the "backend" for different distributed hypertables, e.g., same access node, but data nodes {A, B} for distributed hypertable 1; data nodes {C, D, E, F} are for distributed hypertable 2. You could also have different nodes play the role of access nodes for different hypertables and vice-versa. Lots of flexibility here, although we imagine most users won't need it, so by default your distributed hypertable is created across all connected data nodes. Now, because these nodes are just running TimescaleDB, if you were to create a regular table or even a regular (non-distributed) hypertable on that access node, it would be just stored locally. Then, any JOIN between the distributed hypertable data and regular table happens transparently on the access node. Now, that's what in the current release, but not surprisingly, we plan to add support for better local JOINs. For regular tables, one approach will likely be to provide an option to replicate the table on all data nodes, so that you can perform the JOINs locally (and because TimescaleDB 2.0 already supports 2PC for individual rows across data nodes to support replication factors > 1, that machinery somewhat already exists). A second approach for regular tables that are also partitioned -- particularly if using the same "space" partitioning key as your distributed hypertable -- is to collocate partitions of the regular table across the data nodes, so that JOINs on the space partition keys (e.g., server_id, user_id, etc.) can again be local.
pachico 6y ago
From what I've seen, performance is still much worse than Clickhouse, that was always distributed, open source, data warehouse like and feature rich. Why should I use timescale? I'm really asking, I'm not being rhetorical.
- hardwaresofton 6y ago
  Clickhouse and Timescale are different types of databases -- Clickhouse is a columnar store and Timescale is a row-oriented store that is specialized for time series data with some benefits of columnar stores[0]. Something like InfluxDB is a better thing to compare to TimescaleDB (and TimescaleDB does very well, though the benchmark was a bit old[1] and influx might have improved in the meantime). Database types aside, what really gets me excited about Timescale is that it's just another Postgres extension. If you're already running a Postgres cluster for your OLTP workloads (web-app-y workloads) and have just a bit of fast-moving time series data (ex. logs, audit logs, event streams, etc), Timescale is only an extension away. You get the usual time-tested battle hardened Postgres, with all it's features and also support for your time series workloads. Yeah you could set up declarative partitioning yourself (it is a postgres feature after all) but why bother when Timescale has done the heavy lifting? [EDIT] - see the response below -- the benchmark is up to date, and Timescale does even better against the purpose-built tool that is InfluxDB. > Note: This study was originally published in August 2018, updated in June 2019 and last updated on 3 August 2020. [0]: https://blog.timescale.com/blog/building-columnar-compression-in-a-row-oriented-database/ https://blog.timescale.com/blog/building-columnar-compressio... [1]: https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/ https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-...
  - mfreed 6y ago
    Thanks for thoughts here. One thing we continually hear is that the familiarity, trust, ecosystem, maturity, etc. that folks love about Postgres is a huge boon and one deciding factor for their adoption of TimescaleDB. Just to clarify: those benchmarks about InfluxDB vs. TimescaleDB were fully redone just 2 months ago (August 2020) with the latest versions of both, so should be quite up-to-date. In fact, since the ~year since our last benchmarking, TimescaleDB's performance _relative to InfluxDB_ only significantly increased. "Version: TimescaleDB version 1.7.1, community edition, with PostgreSQL 12, InfluxDB version 1.8.0 Open Source Edition (the latest non-beta releases for both databases at the time of publishing)." https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/ https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-...
hardwaresofton 6y ago
> TimescaleDB is purpose-built for time-series workloads, so that you can get orders of magnitude better performance at a fraction of the cost, along with a much better developer experience. This means massive scale (100s billions of rows and millions of inserts per second on a single server), 94%+ native compression, 10-100x faster queries than PostgreSQL, InfluxDB, Cassandra, and MongoDB – all while maintaining the reliability, ease-of-use, SQL interface, and overall goodness of PostgreSQL. WITH the links to back up their analysis/comparisons. I think I was first sold the hardest on Timescale when I read the InfluxDB post. Timescale also releasing their hard work over the last ~3 years with a very permissive, surprisingly business friendly license[0] which was previously discussed on HN[1]. This is pretty huge -- personally one of the things I'm really looking forward to is using Postgres as a backing store for Prometheus now, which timescale actually worked on[2] already. If you look really closely, there's actually a way to get all your observability data into Postgres (i.e. zipkin/jaeger, logs, and prometheus for metrics), and Timescale is going to make all of those things easier to scale and maintain. For those following along at home, postgres already has some not terrible full text search[3] and ways to integrate with elasticsearch like zombodb[4]... [EDIT] - Just to make what I'm hinting at a little clearer, I think you might be able to build a Graylog[5] type system really easily with just Postgres these days. Imagine deploying a single binary that only needs a single database to do everything it needs to do. [0]: https://blog.timescale.com/blog/building-open-source-business-in-cloud-era-v2/ https://blog.timescale.com/blog/building-open-source-busines... [1]: https://news.ycombinator.com/item?id=24579905 https://news.ycombinator.com/item?id=24579905 [2]: https://github.com/timescale/promscale https://github.com/timescale/promscale [3]: https://www.postgresql.org/docs/current/textsearch.html https://www.postgresql.org/docs/current/textsearch.html [4]: https://www.zombodb.com/ https://www.zombodb.com/ [5]: https://github.com/Graylog2/graylog2-server/ https://github.com/Graylog2/graylog2-server/
- robertlagrant 6y ago
  That is pretty awesome. I'd love to see a postgres-aware cache plugin that keeps the latest versions of data in memory, SAP HANA-style.
mkurz 6y ago
@Timescale devs, what are the differences between Timescale and Citus? When do I want to use which? AFAIK Citus scales multi-nodes long time already, your solution of hypertables reminds me of Citus distributed tables... Citus can do rebalancing long time as well... And much more. Would love to hear what you think makes you different.
- ryanbooz 6y ago
  TimescaleDB is purpose built for time-series data on Postgres. We offer native compression on this data and smart, easily adjustable partitioning, continuous and real-time analytics, automated time-series data management (retention, reordering, tiering, etc) and so forth... again, all focused on time-series data. With a few specific commands, we abstract all of the time-series partitioning for you and provide time-series specific functions to make queries more efficient and useful. Citus is a great product that primarily focused on multi-tenant SaaS analytics, where you typically shard your queries on the tenant_id, but didn't focus on time-series. So, their current documented solution for time-series uses other extensions (pg_partman), doesn't provide for compression, and all the other essential tools to make massive amounts of time-series data useful, which TimescaleDB is hyper-focused on solving.
kev009 6y ago
With my FreeBSD ports maintainer hat on, I don't see a 2.0 tag in github, was this blog premature?
- RobAtticus 6y ago
  The latest tag is 2.0.0-rc2 since it is technically a release candidate and not the final cut.
didip 6y ago
Hi Timescale folks, Can you guys publish a more detailed architecture design on how you scale the multi node? I am particularly curious how you make the Access Nodes multi-master and HA.
- mfreed 6y ago
  Our docs cover some of the data node management [0] and native replication [1] particular in more detail. Right now you can use Postgres physical replication for the access node, with one as the primary (and handling DDL/writes), while Access Node replicas can scale reads to the rest of the cluster. As alluded to in the blog post, we'll probably look to enable clients to write directly to data nodes as a form of further scaling writes (so that the AN "primary" would only be strictly required for DDL), as opposed to a multi-master approach. [0] https://docs.timescale.com/v2.0/using-timescaledb/distributed-hypertables#data-node-management https://docs.timescale.com/v2.0/using-timescaledb/distribute... [1] https://docs.timescale.com/v2.0/using-timescaledb/distributed-hypertables#native-replication https://docs.timescale.com/v2.0/using-timescaledb/distribute...
binakot 6y ago
This is the awesome news! Waiting for release and start to preparing for migration from single-node setup to distributed one. If someone just want to try distributed release candidate with simple setup (1 access node + 2 data nodes) I have the demo on my github: https://github.com/binakot/Multi-Node-TimescaleDB https://github.com/binakot/Multi-Node-TimescaleDB. You are welcome :)
valyala 6y ago
There are other time series databases worth comparison with TimescaleDB: * InfluxDB - https://www.influxdata.com/ https://www.influxdata.com/ * VictoriaMetrics - https://github.com/VictoriaMetrics/VictoriaMetrics/ https://github.com/VictoriaMetrics/VictoriaMetrics/ * M3DB - https://github.com/m3db/m3/ https://github.com/m3db/m3/

213 points by manigandham 6y ago

robertlagrant 6y ago

Really, really interesting. I struggled to find prices for the cloud editions?

hnmullany 6y ago
https://www.timescale.com/cloud-pricing https://www.timescale.com/cloud-pricing
- lights0123 6y ago
  there's also https://www.timescale.com/forge#cloud-pricing https://www.timescale.com/forge#cloud-pricing
  - robertlagrant 6y ago
    Thanks both! Could not find that!
- johnthescott 6y ago
  getting a javascript error in brave browser on mac. says option not defined.
  - mfreed 6y ago
    Sorry about that! Can you email me any screenshots / info at mike (at) timescale? Thanks!

parhamn 6y ago

> But a lot of NoSQL adoption was a knee-jerk reaction, along the lines of, “relational databases don’t scale, so I need a NoSQL database.” I don't agree with this. If you view relational-ness as a spectrum its not so simple. I think part of this knee-jerk reaction was because we over advised things like "denomralize everything" which lead to these monstrous schema diagrams that effected everything in the application pipeline: query performance, permissions, caching, transaction isolation, realtime capabilities, understandability, schema management nightmares, and more. In fact the world proved through NoSQL that a lot of what hyper-relational models we're providing us weren't required to run a business. And you could succeed and do things quickly when taking an extreme stance against relations. I think the average app should probably revert to something in the middle. I've been building applications recently with only acyclical hierarchical relationships. Forcing that constraint up-front does tie your hands a bit but it makes EVERYTHING a ton easier once you design your models around it.

vamega 6y ago
Can you expand on what you mean by an acyclical hierarchal relationship?
merb 6y ago
actually I think the typical application should mix "NoSQL" paradigmas and relational. consider a Offer model, do I really need OfferPosition's as an own table or can I include them via something like "jsonb".
mfreed 6y ago
One of interesting things we’ve found is that the typical data models we’ve seen in TimescaleDB (and time-series workloads in general) is that, while having JOINs and additional tables with metadata, business info, etc. is super useful -- and missing from most other time-series databases, leading to frustrating polyglot solutions that deploy them alongside Postgres/MongoDB/whatever -- it’s much less common to see the terribly deep snowflake schema patterns that came to dominate OLAP, with levels-upon-levels of normalization. And certainly the fact that your time-series hypertable in TimescaleDB can also store JSON, given Postgres’ underlying capabilities, also helps here and thus provides developers with flexibility given their application/performance needs.
jayd16 6y ago
It's a weasel statement that only claims to "a lot" of user sentiment. It's not something you can easily disagree with because the claim is so vague.
tehlike 6y ago
Postgres is hell of a no-sql database :)
eloff 6y ago
I think NoSQL works for a very limited number of cases. Most of the time you just end up moving all the schema checking and integrity checking (foreign key enforcement) to the application level and then you're squarely worse off. Plus MongoDB, which is the poster child of the revolution, has been a technical pile of shit for a decade. It's slower than JSONB on Postgres, and loses data in the default configuration, was insecure in the default configuration, failed Aphyr's Jepsen distributed system consistency tests every time - in other words promised things about consistency that were lies in their documentation. They have improved a lot, but I feel so sorry for people who jumped on that bandwagon early. My interest lies in databases and database internals, and I spent 8 years building databases in my spare time. I always advise everyone that they should use a relational database unless they are very, very sure their requirements don't require it and won't ever require it. It's much easier to start with Postgres and switch to NoSQL later if you really need to go that way than to do it the other way around. Most times you find you don't need to switch to NoSQL. The imagined hordes of users never materialized to overwhelm your trusty relational database.

akulkarni 6y ago

Hi all, thanks for the reading the post. We're very excited to finally launch TimescaleDB 2.0. In fact, users have already been running multi-node TimescaleDB in continuous daily use for many months, including a 22-node cluster by a Fortune 100 tech company ingesting more than a billion rows per day. So this product is already quite robust :-D

robertlagrant 6y ago

I'll nominate myself as silly question asker. Has this been used as the persistence for an event sourcing service? Does that sound like a good/terrible idea? Does it play nicely with SQLAlchemy?

mfreed 6y ago
Yes, works with SQLAlchemy. (Like many ORMs there are a couple things to be aware of, but plenty StackOverflow questions about these already :) And yes, people use it for event sourcing. Often see this in various product analytics use cases.
- ryanbooz 6y ago
  Although I can't point to a specific application that's currently using TimescaleDB for an event sourcing service (I assume you're talking about the design pattern), it would be a great use case. Change in state over time is perfect time-series scenario. As for SQLAlchemy, TimescaleDB is fully PostgreSQL compliant, so it will work out of the box. There will be a few nuances that need to be considered, particularly when writing queries that use some of our additional time-series functions like time_bucket. But day-to-day ORM CRUD patterns should work as you expect!
  - robertlagrant 6y ago
    Thank you (both of you!). Agreed - I mean the design pattern, but I was being a bit vague.
  - johnthescott 6y ago
    are pg extensions supported? -j
    - mfreed 6y ago
      Yes, TimescaleDB plays friendly with most PG extensions. And Timescale Cloud comes pre-loaded with many of them - https://kb.timescale.cloud/en/articles/2754991-supported-postgresql-extensions https://kb.timescale.cloud/en/articles/2754991-supported-pos...

gabereiser 6y ago

This is so good, the features, the licensing, all of it. I'm not going to argue the use-case or NewSQL vs NoSQL or anything but for someone who wants PostgreSQL-level knowledge transfer working with time series data (audit logs, event history, change management, etc), this is amazing! Good work!

akulkarni 6y ago
Thank you! Great set of use cases as well :-)

eloff 6y ago

Wow, this is a big deal. A free, distributed timescale database built on top of trusty Postgres, with column oriented, compressed storage for the time series data. Also as I've stated before on HN, I love the new license which gives you almost all the freedoms of open source software while still letting TimescaleDB create a profitable business and not get squashed by AWS - which benefits nobody. I have lot's of questions: Queries on distributed hypertables are run across the cluster, but what about regular queries to regular tables? Write transactions obviously need to happen in one server, but is there a way to split read queries across the cluster? I don't know if regular table data is duplicated across data nodes, or if it's only on the access node and joined transparently to the result set from the distributed hypertable query. There are 3 kinds of server types for the cloud offering on AWS, IO, compute, or storage optimized. These seem to imply the database storage goes on instance storage, not EBS. This performs much better than EBS, especially on the high IO NVMe instances AWS offers. It also offers more predictable performance and tail latency because there is no network involved, no distributed block storage system (and EBS has had more than it's fair share of outages.) Is this true? I know compose.io (IBM) does this for their managed PostgreSQL for similar reasons. I'd like to compare the pricing to RDS for same-sized instances + storage, with moderate workload so I can get a feel for the markup on the managed service and know at at a glance, ok, this is going to cost me 50% more than RDS but I also get all these TimescaleDB features. I'd also like to see some performance comparisons, just for regular read + write workloads on Postgres, because if I'm right about using instance storage vs EBS the same sized hardware will give more transactions per second for TimescaleDB.

mfreed 6y ago
Thanks for all the questions @eloff! I might try to separate responses for hopefully some threading :) The software in our architecture is actually unified: You spin up K instances of TimescaleDB, log into one of them and then call "add_data_node" to attach others and data nodes, and "create_distributed_hypertable" to make this node the access node _for that particular hypertable_. In fact, you can explicitly specify different data nodes as the "backend" for different distributed hypertables, e.g., same access node, but data nodes {A, B} for distributed hypertable 1; data nodes {C, D, E, F} are for distributed hypertable 2. You could also have different nodes play the role of access nodes for different hypertables and vice-versa. Lots of flexibility here, although we imagine most users won't need it, so by default your distributed hypertable is created across all connected data nodes. Now, because these nodes are just running TimescaleDB, if you were to create a regular table or even a regular (non-distributed) hypertable on that access node, it would be just stored locally. Then, any JOIN between the distributed hypertable data and regular table happens transparently on the access node. Now, that's what in the current release, but not surprisingly, we plan to add support for better local JOINs. For regular tables, one approach will likely be to provide an option to replicate the table on all data nodes, so that you can perform the JOINs locally (and because TimescaleDB 2.0 already supports 2PC for individual rows across data nodes to support replication factors > 1, that machinery somewhat already exists). A second approach for regular tables that are also partitioned -- particularly if using the same "space" partitioning key as your distributed hypertable -- is to collocate partitions of the regular table across the data nodes, so that JOINs on the space partition keys (e.g., server_id, user_id, etc.) can again be local.

pachico 6y ago

From what I've seen, performance is still much worse than Clickhouse, that was always distributed, open source, data warehouse like and feature rich. Why should I use timescale? I'm really asking, I'm not being rhetorical.

hardwaresofton 6y ago
Clickhouse and Timescale are different types of databases -- Clickhouse is a columnar store and Timescale is a row-oriented store that is specialized for time series data with some benefits of columnar stores[0]. Something like InfluxDB is a better thing to compare to TimescaleDB (and TimescaleDB does very well, though the benchmark was a bit old[1] and influx might have improved in the meantime). Database types aside, what really gets me excited about Timescale is that it's just another Postgres extension. If you're already running a Postgres cluster for your OLTP workloads (web-app-y workloads) and have just a bit of fast-moving time series data (ex. logs, audit logs, event streams, etc), Timescale is only an extension away. You get the usual time-tested battle hardened Postgres, with all it's features and also support for your time series workloads. Yeah you could set up declarative partitioning yourself (it is a postgres feature after all) but why bother when Timescale has done the heavy lifting? [EDIT] - see the response below -- the benchmark is up to date, and Timescale does even better against the purpose-built tool that is InfluxDB. > Note: This study was originally published in August 2018, updated in June 2019 and last updated on 3 August 2020. [0]: https://blog.timescale.com/blog/building-columnar-compression-in-a-row-oriented-database/ https://blog.timescale.com/blog/building-columnar-compressio... [1]: https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/ https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-...
- mfreed 6y ago
  Thanks for thoughts here. One thing we continually hear is that the familiarity, trust, ecosystem, maturity, etc. that folks love about Postgres is a huge boon and one deciding factor for their adoption of TimescaleDB. Just to clarify: those benchmarks about InfluxDB vs. TimescaleDB were fully redone just 2 months ago (August 2020) with the latest versions of both, so should be quite up-to-date. In fact, since the ~year since our last benchmarking, TimescaleDB's performance _relative to InfluxDB_ only significantly increased. "Version: TimescaleDB version 1.7.1, community edition, with PostgreSQL 12, InfluxDB version 1.8.0 Open Source Edition (the latest non-beta releases for both databases at the time of publishing)." https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/ https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-...

hardwaresofton 6y ago

> TimescaleDB is purpose-built for time-series workloads, so that you can get orders of magnitude better performance at a fraction of the cost, along with a much better developer experience. This means massive scale (100s billions of rows and millions of inserts per second on a single server), 94%+ native compression, 10-100x faster queries than PostgreSQL, InfluxDB, Cassandra, and MongoDB – all while maintaining the reliability, ease-of-use, SQL interface, and overall goodness of PostgreSQL. WITH the links to back up their analysis/comparisons. I think I was first sold the hardest on Timescale when I read the InfluxDB post. Timescale also releasing their hard work over the last ~3 years with a very permissive, surprisingly business friendly license[0] which was previously discussed on HN[1]. This is pretty huge -- personally one of the things I'm really looking forward to is using Postgres as a backing store for Prometheus now, which timescale actually worked on[2] already. If you look really closely, there's actually a way to get all your observability data into Postgres (i.e. zipkin/jaeger, logs, and prometheus for metrics), and Timescale is going to make all of those things easier to scale and maintain. For those following along at home, postgres already has some not terrible full text search[3] and ways to integrate with elasticsearch like zombodb[4]... [EDIT] - Just to make what I'm hinting at a little clearer, I think you might be able to build a Graylog[5] type system really easily with just Postgres these days. Imagine deploying a single binary that only needs a single database to do everything it needs to do. [0]: https://blog.timescale.com/blog/building-open-source-business-in-cloud-era-v2/ https://blog.timescale.com/blog/building-open-source-busines... [1]: https://news.ycombinator.com/item?id=24579905 https://news.ycombinator.com/item?id=24579905 [2]: https://github.com/timescale/promscale https://github.com/timescale/promscale [3]: https://www.postgresql.org/docs/current/textsearch.html https://www.postgresql.org/docs/current/textsearch.html [4]: https://www.zombodb.com/ https://www.zombodb.com/ [5]: https://github.com/Graylog2/graylog2-server/ https://github.com/Graylog2/graylog2-server/

robertlagrant 6y ago
That is pretty awesome. I'd love to see a postgres-aware cache plugin that keeps the latest versions of data in memory, SAP HANA-style.

mkurz 6y ago

@Timescale devs, what are the differences between Timescale and Citus? When do I want to use which? AFAIK Citus scales multi-nodes long time already, your solution of hypertables reminds me of Citus distributed tables... Citus can do rebalancing long time as well... And much more. Would love to hear what you think makes you different.

ryanbooz 6y ago
TimescaleDB is purpose built for time-series data on Postgres. We offer native compression on this data and smart, easily adjustable partitioning, continuous and real-time analytics, automated time-series data management (retention, reordering, tiering, etc) and so forth... again, all focused on time-series data. With a few specific commands, we abstract all of the time-series partitioning for you and provide time-series specific functions to make queries more efficient and useful. Citus is a great product that primarily focused on multi-tenant SaaS analytics, where you typically shard your queries on the tenant_id, but didn't focus on time-series. So, their current documented solution for time-series uses other extensions (pg_partman), doesn't provide for compression, and all the other essential tools to make massive amounts of time-series data useful, which TimescaleDB is hyper-focused on solving.

kev009 6y ago

With my FreeBSD ports maintainer hat on, I don't see a 2.0 tag in github, was this blog premature?

RobAtticus 6y ago
The latest tag is 2.0.0-rc2 since it is technically a release candidate and not the final cut.

didip 6y ago

Hi Timescale folks, Can you guys publish a more detailed architecture design on how you scale the multi node? I am particularly curious how you make the Access Nodes multi-master and HA.

mfreed 6y ago
Our docs cover some of the data node management [0] and native replication [1] particular in more detail. Right now you can use Postgres physical replication for the access node, with one as the primary (and handling DDL/writes), while Access Node replicas can scale reads to the rest of the cluster. As alluded to in the blog post, we'll probably look to enable clients to write directly to data nodes as a form of further scaling writes (so that the AN "primary" would only be strictly required for DDL), as opposed to a multi-master approach. [0] https://docs.timescale.com/v2.0/using-timescaledb/distributed-hypertables#data-node-management https://docs.timescale.com/v2.0/using-timescaledb/distribute... [1] https://docs.timescale.com/v2.0/using-timescaledb/distributed-hypertables#native-replication https://docs.timescale.com/v2.0/using-timescaledb/distribute...

binakot 6y ago

This is the awesome news! Waiting for release and start to preparing for migration from single-node setup to distributed one. If someone just want to try distributed release candidate with simple setup (1 access node + 2 data nodes) I have the demo on my github: https://github.com/binakot/Multi-Node-TimescaleDB https://github.com/binakot/Multi-Node-TimescaleDB. You are welcome :)

valyala 6y ago

There are other time series databases worth comparison with TimescaleDB: * InfluxDB - https://www.influxdata.com/ https://www.influxdata.com/ * VictoriaMetrics - https://github.com/VictoriaMetrics/VictoriaMetrics/ https://github.com/VictoriaMetrics/VictoriaMetrics/ * M3DB - https://github.com/m3db/m3/ https://github.com/m3db/m3/