HackerTrans
TopNewTrendsCommentsPastAskShowJobs

apurvamehta

no profile record

Submissions

OpenData – Open-Source and Object Store Native Databases

opendata.dev
1 points·by apurvamehta·17 giorni fa·0 comments

Kafka's Broken Promise: There Is No Goldilocks Log

opendata.dev
6 points·by apurvamehta·21 giorni fa·0 comments

Our first customers were the exception

apurvamehta.com
3 points·by apurvamehta·mese scorso·0 comments

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

opendata.dev
18 points·by apurvamehta·2 mesi fa·3 comments

OpenData Vector: MIT-Licensed Vector Search on Object Storage

opendata.dev
48 points·by apurvamehta·2 mesi fa·5 comments

OpenData Buffer: HA pipelines without Kafka

opendata.dev
13 points·by apurvamehta·2 mesi fa·1 comments

OpenData Timeseries: Prometheus-compatible metrics on object storage

opendata.dev
18 points·by apurvamehta·3 mesi fa·15 comments

Sorted string tables (SST) from first principles

bitsxpages.com
71 points·by apurvamehta·6 mesi fa·11 comments

comments

apurvamehta
·mese scorso·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
·2 mesi fa·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
·3 mesi fa·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
·3 mesi fa·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
·3 mesi fa·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
·3 mesi fa·discuss
Good call out, updated the intro with a summary of the cost benefit. Thanks for the feedback!