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

Launch HN: QuestDB (YC S20) – Fast open source time series database

news.ycombinator.com

Post reply on HN
Print view View original

161–170 of 173 posts

Re: Launch HN: QuestDB (YC S20) – Fast open source time series database

#161

Post by pupdogg »

pachico wrote: post #84

I see this as a very interesting project. I use ClickHouse as OLAP and I'm very happy with it. I can tell you features that make me stick to it. If some day QuestDB offers them, I might explore the possibility to switch but never before. - very fast (I guess we're aligned here) - real time materialized views for aggregation functions (this is absolutely a killer feature that makes it quite pointless to be fast if you…

If you don’t mind sharing, what are the specs of your ClickHouse cluster including Zookeepers? Also, how large of a dataset are you working with?

Re: Launch HN: QuestDB (YC S20) – Fast open source time series database

#162

Post by nwsm »

j1897 wrote: post #159
patrickaljord wrote: post #156

Congrats on the launch! One question, there are many open source database startups that make it easy to scale on the cloud. However, when you look into the offering, the scaling part is never actually open source and you end up paying for non open source stuff just like any other proprietary database. So I guess my question is, are you planning to go open core too or will you remain open source with some SaaS offerin…

QuestDB is open source and will remain so forever. You will be able to scale with it. Our commercial product, Pulsar, uses QuestDB as a library and will offer enterprise integration and monitoring features, which are typically required for massive enterprise deployment. To answer your question, it will depend how big of a scale we are looking into. If you are a large company running questdb throughout the organizatio…

When I read Pulsar I think Apache Pulsar.

Re: Launch HN: QuestDB (YC S20) – Fast open source time series database

#163

Post by pupdogg »

j1897 wrote: post #155
massimosgrelli wrote: post #153

Impressive. Can we talk?

Sure could you join our slack ? Top right of our website www.questdb.io

Unable to join your slack here...Slack is stating: "Contact the workspace administrator for an invitation"

Re: Launch HN: QuestDB (YC S20) – Fast open source time series database

#164

Post by pupdogg »

j1897 wrote: post #142
wappa wrote: post #139

How do i join the slack group? It says to request invite from the workspace administrator?

if you click on join slack top right of our website you'll be joining our public channels!

Unable to join your slack here...Slack is stating: "Contact the workspace administrator for an invitation"

Re: Launch HN: QuestDB (YC S20) – Fast open source time series database

#165

Post by santafen »

pupdogg wrote: post #163
j1897 wrote: post #155

Earlier quoted context omitted.

Sure could you join our slack ? Top right of our website www.questdb.io

Unable to join your slack here...Slack is stating: "Contact the workspace administrator for an invitation"

Head of DevRel for QuestDB here drop me an email at davidgs(at)questdb(dot)io and I'll make sure you get invited.

Re: Launch HN: QuestDB (YC S20) – Fast open source time series database

#167

Post by bluestreak »

fredliu wrote: post #166

How do you get the best performance out of QuestDB? Does it have to be on bare metal machines? Is there any performance benchmark of QuestDB running on bare metal vs. cloud instances (e.g. EC2 with EBS volumes) etc.?

QuestDB is quite intensive on cores. For example it is not a good idea to put two threads on hyperthreded cores that share the same physical core. Also it isn't good idea to put threads on cores that belong to different physical CPUs on multi-socket server. With bare metal box you will have visibility of all of these conditions. On virtualized boxed - this will depend on your luck really. That said - if no one is hammering the same core questdb is hammering - performance will be very similar to metal box.

Re: Launch HN: QuestDB (YC S20) – Fast open source time series database

#168

Post by einpoklum »

beagle3 wrote: post #160
einpoklum wrote: post #149

Earlier quoted context omitted.

> On a non-TS oriented DBMS, this query is usually slow and hard to write. I don't see why this is hard to write: SELECT max(time) as most_recent_time, transaction_price INTO newtable FROM oldtable WHERE time > $my_datetime GROUP BY time; As for being slow - can you provide some references about this being slow in non-time-series columnar DBMSes? MonetDB, Vectorwise, Vertica?

"most recent" is min(time) where time>=$my_datetime ; I don't understand your query - max(time) .. GROUP BY time means that every record is its own group, so max(time)==time; also, you will have a result for every single point in time after the requested time. There is no way in standard SQL (without window extensions) to do this with just one clause; you need the price associated with the min(time) associated with t…

Ah yes, I should have grouped by the non-time key fields.

Re: Launch HN: QuestDB (YC S20) – Fast open source time series database

#169

Post by beagle3 »

einpoklum wrote: post #168
beagle3 wrote: post #160

Earlier quoted context omitted.

"most recent" is min(time) where time>=$my_datetime ; I don't understand your query - max(time) .. GROUP BY time means that every record is its own group, so max(time)==time; also, you will have a result for every single point in time after the requested time. There is no way in standard SQL (without window extensions) to do this with just one clause; you need the price associated with the min(time) associated with t…

Ah yes, I should have grouped by the non-time key fields.

I still don't understand how that would give the right result.

Re: Launch HN: QuestDB (YC S20) – Fast open source time series database

#170

Post by PeterCorless »

avthar wrote: post #55
shay_ker wrote: post #52

Earlier quoted context omitted.

I'm sure many folks would be really interested to see two things: 1. A blog post around a reproducible benchmark between QuestDB, TimescaleDB, and InfluxDB 2. A page, like questdb.io/quest-vs-timescale, that details the differences in side-by-side feature comparisons, kind of like this page: https://www.scylladb.com/lp/scylla-vs-cassandra/ . Understandably, in the early days, this page will update frequently, but tha…

Perhaps the QuestDB team could add it to the Time Series Benchmarking Suite [1]? It currently supports benchmarking 9 databases including TimescaleDB and InfluxDB. [1] https://github.com/timescale/tsbs

Wow! Nice. I am surprised neither Scylla nor KairosDB are on that list. I think you could run Scylla by itself (to compare with raw Cassandra) and also re-run with KairosDB running on top of Scylla and Cassandra to see what effects that has on performance. (Though of course, there are advantages to having KairosDB, too.)
Post reply on HN