cheddar

5 ms·

1.
by cheddar 4y ago
Now, for a technical "limitation" that maybe hasn't been highlighted: Druid believes that all hardware is replaceable. As a rule, Druid does not build a strong affinity between one specific piece of hardware and one specific
2.
by cheddar 4y ago
So, anyway, long pre-amble, but the specific answer is: you can think of Druid's limitations as based in targeting the needs of analytics applications instead of generic data warehousing. So, when you say "Not for joins", Dru
3.
by cheddar 4y ago
Talking about each of these a bit more. Multi-tenant: the data sources that we deal with often have a field in them that describes the end-customer tenant. Often there are other fields that describe sub-teams inside of those tenants. Ther
4.
by cheddar 4y ago
I apparently wrote a novel that HackerNews claims is too long, so let me try to break it up into parts. Hopefully HN doesn't hate me for it... As the guy who wrote the first lines of code in Druid, I can venture a description of the l
5.
by cheddar 10y ago
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...
6.
by cheddar 10y ago
What kind of ingestion numbers are you working with? The thread you link to shows that Druid can ingest ~27.5k events/sec per node, which is roughly 2.376bn events a day per node. While you can claim bias here too, we have multiple cl
7.
by cheddar 11y ago
lgsilver, it really depends on what kinds of queries you are doing. For something like "who viewed my profile" where you are likely to have a very selective where clause that matches only a few hundred rows, getting thousands of
8.
by cheddar 11y ago
I'm biased in that I had the honor of writing the first line of code of Druid, but from looking at what I could find on Pinot it looks like architecture-wise, we share a lot of similarities. At a minimum, the thought behind how to sca