3 ms·
It's interesting to me, because we [I work at StarTree, based on Apache Pinot] come at the issue from the entirely opposite end of the scales — when Elasticsear
by PeterCorless 3y ago
It's interesting to me, because we [I work at StarTree, based on Apache Pinot] come at the issue from the entirely opposite end of the scales — when Elasticsearch doesn't scale to certain very large data sets, and especially where you are looking for aggregations and low latency query results.
So there are some workloads that are small enough you can use a different an alternate to Elasticsearch (and where performance is not paramount), and other workloads that are sort of too big for Elasticsearch (and where performance is paramount).
- potamic 3y agoInteresting comparison. I wouldn't have compared them together because Pinot is for OLAP use cases and elastic for full text search.
- PeterCorless 3y agoYou are correct that it's apples and oranges. However, a lot of people use whatever technology is familiar and to-hand to solve problems that turns out to be a bad fit. I am literally in the process of writing up a case study of a customer that used Google Cloud BigTable for analytics until costs and complexity drove them to search for a replacement — for which StarTree was perfect. I'm not calling out Elastic or Google Cloud BigTable per se. For their core features, and their design-for-purpose both are wonderful products. They just weren't designed for real-time OLAP. The same with Postgres. Or MongoDB. It tends to happen that we take what we know and we throw it at whatever the problem-of-the-day happens to be. Over time, we discover design-for-purpose solutions and move appropriate use cases to it.