Add Ravel - #1887
Open
pmoust wants to merge 1 commit into
Open
Conversation
|
|
pmoust
had a problem deploying
to
benchmark-approval
September 7, 2026 14:35 — with 
GitHub Actions
Error
GitHub Actions
Error
Ravel is an object-storage-native telemetry database queried over SQL; every durable byte lives in S3-compatible object storage and the local disk holds only the downloaded Parquet file and a read cache. Two results on c6a.4xlarge, both true cold: the server is restarted and the page cache dropped before the first run of every query, 3 runs per query. The stock entry runs the server with no performance flags. 42 of 43 queries complete; q33 exceeds the per-query memory pool the server derives on a 30 GB machine and is recorded as null rather than run with a raised limit. Its warm runs are close to its cold runs: the server holds no data on local disk, and its derived read cache (25% of memory, 8.2 GB) is smaller than this dataset (11.7 GB), so every warm run re-reads from object storage. The tuned entry passes four flags through RAVEL_TUNED_ARGS in ./start: latency-first fetch policy, fetch concurrency 256, a 12 GiB per-query pool, and a 26.3 GB read cache that the dataset fits in. All 43 queries complete. The cache flag changes the tuned totals by about 1%, because latency-first reads ranged blocks whose working set already fits the default cache; it is kept so the entry's cache behaviour does not depend on the dataset size. The entry is marked tuned and sits out of competition; the README states each flag, why the larger cache is safe under this benchmark's one-query-at-a-time protocol but is not the default, and the trade the entry accepts, about 5.3x the object-store GET requests of the stock entry for the shorter cold wall-clock. Load time is the shipped recipe at defaults and was measured separately from the query runs, since the load is not idempotent against an already loaded bucket. Signed-off-by: Panagiotis Moustafellos <pmoust@nofire.ai>
pmoust
force-pushed
the
add-ravel-20260907
branch
from
September 7, 2026 15:33
0723092 to
5ca4e3d
Compare
pmoust
requested a deployment
to
benchmark-approval
September 7, 2026 15:34 — with
GitHub Actions
Waiting
GitHub Actions
Waiting
Member
|
This makes sense. We can start with a local instance of Minio or SeaweedFS, so the setup will be comparable with other systems. Then we can extend the benchmark to support systems on real S3 (but currently it isn't supported). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ravel is an object-storage-native telemetry database queried over SQL (and other DSLs).
Every durable byte lives in S3-compatible object storage, no WAL.
Two results on c6a.4xlarge, both true cold: the server is restarted and the page cache dropped before the first run of every query, 3 runs per query. The local disk holds only the downloaded Parquet file and a read cache.
The stock entry runs the server with no performance flags. 42 of 43 queries complete; q33 exceeds the per-query memory pool the server derives on a 30 GB machine and is recorded as null rather than run with a raised limit.
The tuned entry passes three flags through RAVEL_TUNED_ARGS in ./start: latency-first fetch policy, fetch concurrency 256, and a 12 GiB per-query pool. All 43 queries complete. It is marked tuned and sits out of competition; the README states the flags and the trade they accept, about 5.3x the object-store GET requests of the stock entry for the shorter cold wall-clock.
We're working to improve the price-perf of that mode, as well as providing adaptive modes and dynamic query-cost budgets. But it's safe to say that there always going to be a "give me best latency, no matter what, in that architecture" mode. This is that mode right now.
Load time is the shipped recipe at defaults and was measured separately from the query runs, since the load is not idempotent against an already loaded bucket. It reliably measures in the same exact w/ <+-0.5% deviation with fresh buckets.
What's different with Ravel in the context of ClickBench is that it requires an S3 bucket to ingest to (and read from).
Is that something you can facilitate @alexey-milovidov?
Happy to follow any route you feel appropriate.