Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TimescaleDB vs. Amazon Timestream

blog.timescale.com

Post reply on HN
Print view View original

51–60 of 203 posts

Re: TimescaleDB vs. Amazon Timestream

#51

Post by dhd415 »

mpsq wrote: post #23
rattray wrote: post #18

Earlier quoted context omitted.

Except timescaledb is open source: https://github.com/timescale/timescaledb

This GitHub repository is just the database, what about the code that holds together their cloud resources? I was not able to find it. They criticize AWS for making money on Elasticsearch for example, AWS is "taking advantage of the R&D efforts of others". So Amazon is making money on a "serverless" / cloud experience. At the same time, it is known that Amazon is contributing back to Elasticsearch [1]. To that regard…

There's no way that Elastic would accept the Open Distro features as a contribution to Elasticsearch because they include inferior versions of features already available in the commercially-licensed version of Elasticsearch and, in the case of the Search Guard code in Open Distro, code that Elastic alleges was lifted from existing commercially-licensed Elasticsearch features. AWS knows all this but offers it anyway as a PR stunt so they can say that they at least attempted to make contributions to Elasticsearch.

Re: TimescaleDB vs. Amazon Timestream

#52

Post by dannyw »

oblio wrote: post #43
rattray wrote: post #21

Full title includes a summary of benchmark results for the lazy: Timescaledb achieved 6000x higher inserts, 5-175x faster queries, 150x-220x cheaper Benchmarks open-source, methodology in post.

If I were them I wouldn't rest on my laurels. v1 from AWS is an MVP. It will keep getting improved. I'd like to see those numbers 2-3 years from now.

I'd also shout as widely as possible why their product is better to limit the traction AWS's offering gets.

Re: TimescaleDB vs. Amazon Timestream

#53

Post by ryanbooz »

crescentfresh wrote: post #31

> 224x cheaper if you’re self-managing TimescaleDB on a VM I'm having a hard time understanding the cost comparison without details of the above. Are they saying that hosting your own cluster of timescaledb nodes within EC2 still comes in cheaper than timestream? This seems impossible, depending on the instance types of course.

(Disclaimer: blog author and Timescale employee)

There are two main points here.

1. To complete this benchmark workload, it took less than an hour in two different environments (Digital Ocean self-managed & Timescale Forge fully managed) to ingest 1 billion metrics and run all 30K queries. It took us a week of work (testing, modifying code to try and make Timestream better) to get 40% of the metrics into Timestream and then query it. 1 hour vs 7 days.

2. If you look at the bill/costs, the main driver was querying. We (attempted) to run the same 30K queries on less than half the data (410 million metrics) in Timestream and somehow scanned 21TB of data. I have no idea why and there's nothing we could do to change it.

As a developer, that's going to be your biggest unknown. If you're ingesting millions or billions of metrics a day and querying it with a real application, you could really get hit with crazy query costs.

With a more traditional server architecture, at least you know your day-to-day costs and can set a known capacity to achieve the performance you need (or scale in understandable ways when you need it)

Re: TimescaleDB vs. Amazon Timestream

#54

Post by hardwaresofton »

ants_a wrote: post #46
hardwaresofton wrote: post #17

I'm very towards Postgres and resultingly Timescale for being one of it's biggest shining stars. Combine that with a cynical view that this is essentially S-tier content marketing (in the tech world), and the numbers are still bonkers. Might as well add on a bit here -- if you're into this sort of thing you might enjoy Timescale thrashing other purpose-built databases (which have since also improved so YMMV): - Times…

I did some time series data benchmarking recently. Most large data is "time series" data, but I will not digress on terminology right now. For the usecase I was looking at my results for InfluxDB did not qualitatively disagree the above blogpost. Timescale got better compression efficiency, faster query results, more constrained memory usage, but lower ingest speed at high concurrencies blocked by WAL insert locking…

I know the first thing that shocked me was how they could get so close to something that was purpose built for time series. Even being within spitting distance is really great in my opinion for an off the shelf, general tool.

> However none of the databases tested above is anywhere close to the efficiency of a column store database that can do vectorized execution over batches of rows. ClickHouse is a good example of one such database. For queries that have to shift through large amounts of data, either filtering or aggregating it, the performance difference is easily >10x. I was seeing aggregation performance above 2B rows/s and that was I/O throughput bound.

Agreed -- OLTP (in the case of Timescale) and purpose built timeseries-focused (but not necessarily analytics focused) DBs hold nothing to a proper OLAP database.

Did you write about this anywhere? would love to read it. I've never had a real need for the kind of stuff that Clickhouse does, but it looks to be the best in class for F/OSS OLAP DBs. Have you ever tried Druid?

Re: TimescaleDB vs. Amazon Timestream

#55

Post by eloff »

BenoitP wrote: post #48

Pre-reading hypothesis: TimescaleDB is declared orders of magnitude faster because the benchmark is serving results they're computing at writing time? Is it just like the ClickHouse benchmark from earlier, where they read from a `CREATE TABLE [...] ENGINE = AggregatingMergeTree`? Post-reading: "faster queries via continuous aggregates". So is this it? I couldn't find how tables / materialized views were created in th…

This comment is pretty dishonest after reading the article. The most striking part of the benchmarks was the absurdly abysmal insert rate for timestream. Honestly after seeing that, I think the team at AWS that built it should be reassigned and contractors or an A team brought in to try and salvage it. Because they've built themselves a very expensive lemon and they're trying to sell it to the world as a Cadillac.

Re: TimescaleDB vs. Amazon Timestream

#56

Post by tracker1 »

that_guy_iain wrote: post #7
jpgvm wrote: post #5

Not a surprising result at all. Timestream is another case of AMS trying to make something for the sake of having it (see here Kinesis instead of just doing Kafka and many other products) instead of just adopting something industry standard. That isn't to say they don't do some good stuff just they also ship a lot of crap, very much 2 tiers of products in the AWS catalog. I would eventually like to see comparison for…

It seems like AWS is just focusing on increasing it's vendor lock in and it makes sense not just from the AWS point of view but if you're a developer at an enterprise company that has authorised AWS the more databases the clone, poorly or badly the more choice you have without having to get authorisation and the cost doesn't matter to the developer since the enterprise company is paying for it. I suspect there are ma…

Much like Amazon themselves with breaking away from using Oracle.

Re: TimescaleDB vs. Amazon Timestream

#57

Post by eloff »

If you take one thing away from this it's do not use AWS timestream, and if you are using it, get rid of it quick. It's unfit for purpose.

That first graph tells you everything you need to know. Time to insert a billion events:

TimescaleDB: 5 min

AWS Timestream: ~2 weeks!

I think the team at AWS that built it should be reassigned and contractors or an A team brought in to try and salvage it. Because they've built themselves a very expensive lemon and they're trying to sell it to the world as a Cadillac. The fact that they did not detect this themselves before or since releasing it upon the world demonstrates to me that they're incompetent and have to be replaced.

Re: TimescaleDB vs. Amazon Timestream

#58

Post by dumbfounder »

ameyv wrote: post #28
rattray wrote: post #22

My takeaway from this is more to be wary of AWS than anything. I've also heard gcp can be a real mess. Is Azure any good yet?

Depends on what type service you trying.... We do face few hiccups now and then.. but overall okay.. Rather i would recommend to go with architecture that is not tightly coupled to certain vendor and built on open source products... We also prefer/buy services from companies who build OSS like in case of ELK, we, rather than hosting and doing it by ourselves. We are more than happy to pay bit more for hard work their…

That is not the mantra at our company. We want serverless and managed services whenever possible because getting resources to setup and maintain anything is next to impossible. We are now trying to use some competing products to AWS products that are full SaaS, so theoretically great, but because it isn't tacked on to our AWS bill it is very hard to get it approved and we are waiting around for weeks turning into months.

Re: TimescaleDB vs. Amazon Timestream

#59

Post by nautilus12 »

nkozyra wrote: post #45
LukeEF wrote: post #41

Earlier quoted context omitted.

But why do they do it so badly? Seems like they have the engineering muscle to put out a great reinvention of a document db, a time series db, a graph db... but each is relatively poor to the other services on AWS. Is it the combination of MVP-culture and lock-in?

Breadth versus depth seems to be the play outside of their absolute core offerings. It allows people to dip their toes into something with minimal commitment and by the time they realize the shortcomings they might conclude that migrating for those features just isn't worth it. So this give them a bit of lock-in. Come for the EC2, stay for the minimally viable queues, machine learning, containers, etc.

This exactly, they are just trying to get their foot in the door in literally any idea someone else is already pursuing so that if it starts to make money they can start to put the juice on the engineering for that and take their market share.

The business model is solely focused on competing with and taking out other businesses, not actually providing any value. AWS is like a pack of sharks.

Re: TimescaleDB vs. Amazon Timestream

#60

Post by nautilus12 »

It doesn't matter, look at kinesis. People are willing to use it over kafka (even though AWS has a hosted kafka solution), just because the percieved convenience and interconnectivity to other AWS services. If timescale starts to make serious money, then AWS can use this to mobilize their engineering and make it fast and take timescale out. Amazon's goal is literally to be the only kid on the block for everything forever. Normally that kind of competition would be good, but they are wiling to cut the price so low and take massive loses for really long periods of time until all the competition dies out. Which isn't honest competition.
Post reply on HN