| Ah, cool, I chased down what you are doing and figured out that you are doing an apples to oranges comparison. As described in your benchmark description: https://gist.github.com/sacreman/b77eb561270e19ca973dd505527... You are running 200 agents emitting 6000 metrics a piece using Haggar to generate load, which is at https://github.com/dalmatinerdb/haggar The specific thing of interest is how you are generating your data, which looks like you have a single set of dimensions and 6000 metrics dangling off of it. The loop that populates all of the "metrics" are: https://github.com/dalmatinerdb/haggar/blob/master/main.go#L... And the thing that actually populates the bytes are at: https://github.com/dalmatinerdb/haggar/blob/master/util.go#L... So, if we take this to an apples-to-apples comparison, you have 200 agents sending a single event every second with 6000 metrics in it. That means that you are successfully ingesting 200 events per second in the way that we would measure event ingestion for Druid. Note, also, that the thread you link to is ingesting 17 independent dimensions with each and every event that flows in. From the Daltaminer docs, it looks like you put all dimension data into postgres and you don't expect any large-scale deployment to ever need more than a single postgres node: https://gist.github.com/sacreman/9015bf466b4fa2a654486cd79b7... Look under "Setup Postgres". We routinely have billions of unique combinations of dimension values per day flowing into our system. Delegating the finding of the right keys to a relational database for such operations is going to be very cost-prohibitive, not to mention, you are going to have to materialize hundreds of millions of keys in order to do a simple aggregate over the day. So, I guess this is just another case where you should never trust benchmarks that you didn't do yourself or that don't follow a standard pattern like TPC-H. It's too easy for the same words to be used with different meanings. |
Expanding the benchmark to cover cardinality and other aspects would indeed be comparing apples to oranges.
In terms of benchmarking DalmatinerDB with billions of unique combinations indexed in Postgres.. I think we know what will happen there :) That's what it's designed for. We can also shard in the query engine, or use any of the multi master Postgres options, but I doubt that would even be necessary.