Earlier quoted context omitted.
And those 3 are?
OneTick, Kx, and QuasarDB
Thanks!
TimescaleDB vs. Amazon Timestream
171–180 of 203 posts
Re: TimescaleDB vs. Amazon Timestream
#172Earlier quoted context omitted.
Please see below for correction... but at some point today a poster said "~2 weeks" for Timestream... but that's incorrect. We ran the data load/ingest for "~2 days" (40 hours). Just want to make sure the right numbers are being used! Thanks! (Post author @Timescale)
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.
Re: TimescaleDB vs. Amazon Timestream
#173If 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 the…
(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.
Re: TimescaleDB vs. Amazon Timestream
#174Not 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…
> ...see here Kinesis instead of just doing Kafka and many other products Kinesis was a solution to their in-house woes with metering and billing which absolutely drowned in so much data from internal services with myriad metering and billing items and rules that they had to do something about it themselves: https://gigaom.com/2014/03/20/why-amazon-built-its-data-stre... BTW, Kinesis Data Firehose is a pretty good pr…
Kinesis Data Firehose is now pretty much Flink. Flink is a pretty good product.
Re: TimescaleDB vs. Amazon Timestream
#175Not 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…
Working at AWS must be fun You basically reinvent all the stuff - from databases to all avaliable tooling normal companies dont do that, so there' an opportunity to get deep into some specific branch of applied informatics.
It’s fun if you’re the guy building the stuff. Not if you’re the guy using all reinvented tooling.
Re: TimescaleDB vs. Amazon Timestream
#176Earlier quoted context omitted.
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…
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 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.
Re: TimescaleDB vs. Amazon Timestream
#177For 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 the development team!
Re: TimescaleDB vs. Amazon Timestream
#178Earlier quoted context omitted.
The documentation still talks about buying an enterprise edition: https://docs.timescale.com/latest/getting-started/exploring-...
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.
Re: TimescaleDB vs. Amazon Timestream
#179AWS should pay a special Enterprise agreement to companies like MongoDB and Timescale so they could really host and resell the product. It would be good for users and license owners, and I guess for AWS also. GCP and Azure would soon follow.
Re: TimescaleDB vs. Amazon Timestream
#180Serious question: Why doesn't AMZ just buy TimeScaleDB instead of building their own? Time series db's in general seem to fit their vibe pretty well: it's a new hot tech, it's usually deeply embedded into infrastructure, and requires loads of bandwidth & storage.
Timescale isn't exactly huge yet, but their potential is enormous - but so is the potential in building a competing product offered as a service. Unless Amazon want to put at least 8 zeros in their offer, I can't see it happening, and at that point Amazon might as well hedge their bets and build their own offering (which is exactly what they're doing). At worst, their offering will be only _okay_, and at the same time Timescale is doing business with Amazon by hosting DaaS instances on their infrastructure, which I'm sure Amazon takes a handsome cut from.