HackerTrans
TopNewTrendsCommentsPastAskShowJobs

apurvamehta

no profile record

Submissions

OpenData – Open-Source and Object Store Native Databases

opendata.dev
1 points·by apurvamehta·vor 17 Tagen·0 comments

Kafka's Broken Promise: There Is No Goldilocks Log

opendata.dev
6 points·by apurvamehta·vor 21 Tagen·0 comments

Our first customers were the exception

apurvamehta.com
3 points·by apurvamehta·letzten Monat·0 comments

Ingesting 1Gbps of logs into ClickHouse for $180/month

opendata.dev
18 points·by apurvamehta·vor 2 Monaten·3 comments

OpenData Vector: MIT-Licensed Vector Search on Object Storage

opendata.dev
48 points·by apurvamehta·vor 2 Monaten·5 comments

OpenData Buffer: HA pipelines without Kafka

opendata.dev
13 points·by apurvamehta·vor 2 Monaten·1 comments

OpenData Timeseries: Prometheus-compatible metrics on object storage

opendata.dev
18 points·by apurvamehta·vor 3 Monaten·15 comments

Sorted string tables (SST) from first principles

bitsxpages.com
71 points·by apurvamehta·vor 6 Monaten·11 comments

comments

apurvamehta
·letzten Monat·discuss
It's a demonstration. Kafka is a very popular input for Clickhouse. So are data lakes. The point is neither need Kafka at all.
apurvamehta
·vor 2 Monaten·discuss
Thanks! opendata contributor here.

We're heavily inspired by Turbopuffer. I'd say we are comparable to them when they launched in terms of perf and scale. But they've obviously invested heavily since then, so we're not going to match them on raw perf at scale right now. Our goal is to be a pretty competitive OSS offering over the long term though.

The next biggest lift for us to get much closer is quantization. If we squeeze more signal into fewer bits, we will improve performance end to end.
apurvamehta
·vor 3 Monaten·discuss
+1 to what @agavra said. It's awesome to see you here @valyala. Your writing and talks about timeseries databases were a great inspriratino for us. I recall one of your earlier talks about the data layout design of VM. Opendata Timeseries has emulated a lot of it.
apurvamehta
·vor 3 Monaten·discuss
yes. this is current issue. there are two solutions:

1. the reason it's slow as you select more series over longer periods of time is that the series has to be pulled for each time bucket in the range, and then the samples have to be pulled for each bucket. By compacting older buckets and merging samples together, historical queries should be pretty comparable to 'more recent' cold queries. 2. We don't pre-cache all the metadata today. If we did that, then we could parallelize sample loads much more efficiently, lowering latency. 3. There is a lot of room to do better batching and tune the parallelism of cold reads.

We've only been at this for a couple of months. THe techniques to improve latency on object storage are well known, we just have to implement them.

Another benefit is this: all the data is on S3, so spinning up more optimized readers to transform older data to do more detailed analysis is also an option with this architecture.
apurvamehta
·vor 3 Monaten·discuss
Agreed. VictoriaMetrics is indeed a very compelling offering. The disk-less approach is significantly simpler to operate, which I think is the biggest difference. Running opendata's version yourself has fewer moving pieces, and standard operations become trivial because no single service retains permanent state.

It's a meaningful change in calculation of running yourself vs paying someone to do it for you IMO.
apurvamehta
·vor 3 Monaten·discuss
Good call out, updated the intro with a summary of the cost benefit. Thanks for the feedback!