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

181–190 of 203 posts

Re: TimescaleDB vs. Amazon Timestream

#181

Post by ryanbooz »

rubiquity wrote: post #172
overcast wrote: post #170

Earlier quoted context omitted.

STILL! 5 minutes vs 2 DAYS can't be attributed to just being replicated.

Large numbers are unintuitive. If we’re conservative and add only 1 millisecond of latency for the 3 AZ replication, on 410 million records that is about 4 and a half days of time if the client is not doing any batching.

TSBS did batch 100 metrics at a time, the max per request that Timestream allows. As we (and others) have suggested, this could easily be one of the reasons it's harder to ingest more quickly without significantly more threads. TimescaleDB (and other TSDB's) allow much higher batching values.

Re: TimescaleDB vs. Amazon Timestream

#182

Post by ryanbooz »

crb002 wrote: post #173
ryanbooz wrote: post #166

Earlier quoted context omitted.

(Post author from Timescale) For the record, in reviewing HN conversation tonight I saw this and realized it was an incorrect quote of the article. Totally honest mistake I'm sure, but I wanted to set the record straight. We spent a little over a week working at Timestream benchmarking. Trying different approaches to batching metrics for ingest, threading differently, running multiple EC2 instance, etc. to improve pe…

How was the test set up? Big difference between slamming localhost and ingesting edge inserts from IoT devices all over.

It's all detailed in the post (granted... it IS a detailed, long read ;-)

TL;DR; - TimescaleDB was tested with a cloud setup in Digital Ocean, separate client and server. We actually ran a second, unpublished, test into Timescale Forge from the same client(s) that we tested Timestream with. We did this second TimescaleDB test just to see if something was wrong with our EC2 instances or setup in other way. So, completely separate service offering with no VPC or anything - just a raw PSQL connection from client to server. The Timescale Forge instance was 1/4 the specs of the DO server from the published results (again, the intent wasn't to replicate the TimescaleDB tests all over again), and it still easily achieved 1.2 million/sec ingest from the same client computer where Timestream only achieved ~525 metrics/sec.

Re: TimescaleDB vs. Amazon Timestream

#183

Post by ryanbooz »

pezezin wrote: post #177

For me the killer feature of TimescaleDB is that you can run it on your own server. Not all of us can run our services in the cloud. In my case I'm working at a particle accelerator, which is considered a nuclear facility and thus not allowed to be directly connected to the Internet. One year ago I moved our old system to TimescaleDB, and I have been really happy since then, it's a really amazing product. Kudos to th…

Thanks for sharing! Glad to hear it's been a successful venture for you. Hope we get to hear more about it at some point!

Re: TimescaleDB vs. Amazon Timestream

#184

Post by mfreed »

pezezin wrote: post #177

For me the killer feature of TimescaleDB is that you can run it on your own server. Not all of us can run our services in the cloud. In my case I'm working at a particle accelerator, which is considered a nuclear facility and thus not allowed to be directly connected to the Internet. One year ago I moved our old system to TimescaleDB, and I have been really happy since then, it's a really amazing product. Kudos to th…

Hey pezezin - would love to hear more if you are open to it. Can you ping me at mike @ timescale.com?

Re: TimescaleDB vs. Amazon Timestream

#185

Post by manigandham »

ramraj07 wrote: post #92
zachd1_618 wrote: post #73

Earlier quoted context omitted.

I think AWS is early to offer a not-yet-matured product just to get it in front of customers and start gathering real usage feedback. I’d consider dynamo a fantastic tier 1 service, but it wasn’t always that way. This is inline with the Amazon philosophy in general. As for “making something for the sake of having it”, I believe the key reason for building their own applications is that they can build it on the same m…

Which deepdive talk are you recommending?

AWS re:Invent 2019: [REPEAT 1] Amazon Aurora storage demystified: How it all works (DAT309-R1): https://www.youtube.com/watch?v=DrtwAOND1Pc

But all of the Deep Dive talks are good for technical details: https://www.youtube.com/results?search_query=aws+reinvent+20...

Re: TimescaleDB vs. Amazon Timestream

#186

Post by manigandham »

arminiusreturns wrote: post #158
hardwaresofton wrote: post #54

Earlier quoted context omitted.

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…

I'm out of my depth here (not a db guy but curious), so forgive the interruption, but have either of you messed with either SciDB or VoltDB? I have found them to be quite interesting especially given Stonebraker himself being involved in the design. Druid and timescale have also been on my radar too, and I think these comments have finally given me the push to play around with them in my sandbox.

VoltDB is about performance by computing entirely in-memory and using a strict sharding architecture. It's unique that you interact through stored procedures that are shared by the data so each node processes completely in parallel without any side-effects. It's more akin to other streaming/SQL processing engines like Spark rather than a fully functional SQL database.

I highly recommend MemSQL (now called Singlestore) for a really polished distributed relational database that combines OLTP with OLAP columnstores.

Re: TimescaleDB vs. Amazon Timestream

#187

Post by suntruth »

CodesInChaos wrote: post #178
suntruth wrote: post #133

Earlier quoted context omitted.

Timescale web dev here. Just curious where you got that link from? It's not linked to on our website nav anymore.

Google. When I tried to figure out what products you offer.

Ah, have to check our sitemap, methinks! Thanks for the heads up.

Re: TimescaleDB vs. Amazon Timestream

#188

Post by aforwardslash »

djk447 wrote: post #163
aforwardslash wrote: post #125

Earlier quoted context omitted.

The parent post didn't have enough detail, but I'd assume the dump would be using COPY for inserts. AFAIK when using COPY, the indexes are only built at the end of the command, not on each insert.

(Just noticed this was about dump/restore, during restores you can in fact write the data and then build the index in a separate operation and that can be faster, sorry for missing context)

Still, you managed to add valuable knowledge on your reply I wasn't aware of, regarding the overall topic. thank you for that :)

Re: TimescaleDB vs. Amazon Timestream

#189

Post by hardwaresofton »

ants_a wrote: post #176
hardwaresofton wrote: post #54

Earlier quoted context omitted.

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…

I was really surprised at how well Timescales compression worked. It was pretty much comparable to best in class columnstores. Only the row-by-row query execution engine was holding it back. Perhaps something that future versions of postgres can help with. I haven't published the benchmarking results anywhere yet, but I will probably do some conference talks on it once that is a thing again. Didn't look into Druid in…

> I was really surprised at how well Timescales compression worked. It was pretty much comparable to best in class columnstores. Only the row-by-row query execution engine was holding it back. Perhaps something that future versions of postgres can help with.

I think zedstore[0] might be something that could help here. I've mentioned it in the past but one of the best things about postgres is it's extensibility, and if timescale rides that wave (and maybe contacts zedstore to get this integration started early) it could be awesome.

[0]: https://blogs.vmware.com/opensource/2020/07/14/zedstore-comp...

> Didn't look into Druid in detail, but did try out Hive. Both of them look more suitable for cases where there is significant engineering effort in developing the data ingest and structuring pipeline. I wouldn't recommend either to a small team. With a measly triple digit TB database size both seemed overkill.

Thanks for this -- I haven't tried it yet at all but will try to remember this. ClickHouse was already first on my list for hobbyist->enterprise scalability but this cements it.

Re: TimescaleDB vs. Amazon Timestream

#190

Post by valyala »

chmod775 wrote: post #159

Ah yes. The horizontal scalability endgame. Amazon designed a system that is perfectly horizontally scalable. The only issue is that they now need 33,000 machines to achieve the throughput of TimescaleDB running on a single node. I would call the results this new school of software development produces horrifying, but I already get lynched every time I tell a startup that their horrifyingly complex horizontally 'scal…

Horizontally scalable systems are usually slower than single-node solutions because of overhead on passing data between nodes. We at VictoriaMetrics clearly see this - cluster version of VictoriaMetrics needs up to 2x more CPU and RAM resources comparing to a single-node version for achieving the same performance.

Single-node VictoriaMetrics provides almost perfect vertical scalability though. Its' performance scales almost linearly from rPI to a monster with hundreds of CPU cores and terabytes of RAM. See https://valyala.medium.com/measuring-vertical-scalability-fo... and https://valyala.medium.com/billy-how-victoriametrics-deals-w... .

Post reply on HN