everytime I see the name Clickhouse I think I'm reading about a CRM tool. It's the worst name for a database ever.
No, QuestDB is not Faster than ClickHouse
61–70 of 73 posts
Re: No, QuestDB is not Faster than ClickHouse
#62Earlier quoted context omitted.
Well, I don't know how QuestDB works, and I couldn't find anything in the original benchmark, but probably they already have some sort of (geo)index in place? It's really strange to search geo-data by scanning the whole surface of the Earth. The point that Clickhouse outperforms this by just sorting on one axis (and even not using any fancy 2D indices) is reasonable.
No, there are no indexes in QuestDB in the article. None. Zero. That's bold mistake in the ClickHouse article. Should be named Yes, QuestDb is Faster.
Why does the lack of indexes matter? Especially when the size on disk is so much higher? Defining a sensible index isn't an unreasonable or daunting task, and minimal effort in CH got a 4x speedup over QuestDB. "It's faster if you invest literally zero time making it efficient" doesn't offer any practical benefit to anyone.
If it was demonstrated that Quest did a better job overall in the majority of cases where an optimization would have been missed, that's one thing. But this feels awfully nitpicky.
Re: No, QuestDB is not Faster than ClickHouse
#63Earlier quoted context omitted.
No, there are no indexes in QuestDB in the article. None. Zero. That's bold mistake in the ClickHouse article. Should be named Yes, QuestDb is Faster.
Why does the lack of indexes matter? Especially when the size on disk is so much higher? Defining a sensible index isn't an unreasonable or daunting task, and minimal effort in CH got a 4x speedup over QuestDB. "It's faster if you invest literally zero time making it efficient" doesn't offer any practical benefit to anyone. If it was demonstrated that Quest did a better job overall in the majority of cases where an o…
The article is not _just adding an index_. They are embedding one of the search fields in a table _primary key_. That likely means the whole physical table layout is tailored for that single specific query.
While it can help to win this very benchmark it's questionable whether it's usable in practice. Chances are an analytical database serves queries of various shapes. If you only need to run a single query over and over again then you might be better off with a stream processing engine anyway.
Re: No, QuestDB is not Faster than ClickHouse
#64I have always felt that DB benchmarks are useless, always use your own dataset https://gauravkumar.blog/performance-benchmarks-are-useless....
I wouldn't go as far as to say that benchmarks are useless, but I agree that when looking at a benchmark, it's important to be aware of how similar its data distribution and query patterns are compared to your own.
Re: No, QuestDB is not Faster than ClickHouse
#65Our article in question can be found here: https://questdb.io/blog/2022/05/26/query-benchmark-questdb-v... The intent of the article was to showcase JIT-optimised WHERE clause and we did not use any indexes on QuestDB.
> The intent of the article was to showcase JIT-optimised WHERE clause and we did not use any indexes on QuestDB.
Does not seem like it from the title.
Re: No, QuestDB is not Faster than ClickHouse
#66Earlier quoted context omitted.
I wonder what "every effort to be fair" means ? The first thing you could have done is reach out to ClickHouse Community to ask for optimization suggestions
"fair" means that we comparing apples to apples. Ad-hoc, unindexed predicate, compiled by QuestDB into AVX2 assembly (using AsmJIT) vs same predicate complied by Clickhouse (I'm assuming by LLVM). One can perhaps view this as comparing SIMD-based scans from both databases. Perhaps we generate better assembly, which incidentally offers better IO. We all understand that creating very specific index might improve specif…
The million dollar question is, if we add the same index optimization to QuestDB, would QuestDB query faster than Clickhouse?
Re: No, QuestDB is not Faster than ClickHouse
#67This response illustrates important point - if you're expert in technology A and compare it to technology B, you're not expert in, comparison is very likely to be unfair. I very much would like to see vendors at least to follow Journalist ethics and reach out to their competition for optimization comments and suggestions before publishing it, so others are given a chance to suggest optimizations
>This response illustrates important point - if you're expert in technology A and compare it to technology B, you're not expert in, comparison is very likely to be unfair.
To have fair benchmarks, one organization can manage the test requirements and submissions while expert in a said technology can submit their best efforts to be measured and compared to others.
Like Tech Empower Benchmarks used to work.
Re: No, QuestDB is not Faster than ClickHouse
#68everytime I see the name Clickhouse I think I'm reading about a CRM tool. It's the worst name for a database ever.
I agree. I actually think it's ideal for something we need at work (basically storing a crap ton of logs) but it doesn't remotely sound like it from the name. Sounds like some kind of front-end analytics tool.
Re: No, QuestDB is not Faster than ClickHouse
#69Earlier quoted context omitted.
If your intent it to showcase the new optimization in the product it is best to compare it to your own old version
Comparison with old version is actually in the article for the patient reader. It could go to the top but I don't think it will make a difference. At the end of the day it is the article at the official QuestDB website which gives the reader a spoiler about the bias. I am intrigued what Timescale is going to publish next.
Right. The data is there but it comes with clickbait title which distracts focus from the awesome performance improvements QuestDB guys reached
Re: No, QuestDB is not Faster than ClickHouse
#70I have a ton of respect for the clickhouse team. We ran a massive cluster storing trillions of events across thousands of servers for years to serve a real-time reporting/ api use case and the tech is blazing fast and never once let us down.