Repository navigation
Judge each analytic query's freshness against the New-Orders the terminals were told had committed - #278
Merged
Conversation
…inals were told had committed
4 of 5 tasks
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
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.
Part of tamnd/rudb#1390 (W7), the HyBench freshness measure (Zhang et al., PVLDB 17, 2024) for the analytic streams.
The CH-benCHmark streams reported how long each query took but not how old its data was. W7's freshness gate reads that number: zero with
visibility = committed, and at most the device card's p99 sync latency withdurable(engine-v4/14-reads-stay-fast.mdsection 14.8,bench/tpc-c/09-ch-benchmark.mdsection 9.6).With
--analytic Nthe terminals now note each New-Order's order number and the time its commit returned, per district, in the newfresh::Acks. Before each query a stream begins a read transaction with the newSession::begin_snapshot(REPEATABLE READ READ ONLYon PostgreSQL, which takes a snapshot per statement otherwise), readsSELECT d_w_id, d_id, d_next_o_id FROM district, runs the query in the same transaction and commits.Acks::judgetakesd_next_o_id - 1as the newest order each district shows. The query is stale by the time from the oldest acknowledged order it missed to when the district read was sent, or zero. An order seen whose acknowledgement came after the read was answered counts as seen ahead, the second number of section 9.6. Orders seen more than 10 seconds before are let go.No new flag: judging is on whenever
--analyticis. The report addsch freshness judged= late= stale_median_ms= stale_p99_ms= stale_max_ms= ahead= ahead_orders= lead_max_ms=, andch unjudged message=if the district read fails. For examplerudb-bench-kv --mode tpcc --backend rudb --target t.db --load --warehouses 2 --terminals 4 --analytic 2.Limits: the read is sent at one instant and answered at a later one, and the snapshot falls somewhere in between, so staleness is measured from the send and lead from the answer, which errs toward zero on both. The driver does not set rudb's
visibility, so a run measures whatever the database opens with, the defaultdurable. Thecommittedside of the gate needs that set another way.Tests
fresh.rs: a snapshot is late by the oldest order it missed and ahead by the orders it saw early, including one seen before it was acknowledged at all, orders seen long ago are let go, and the district read is parsed as three numbers a row.ch.rs: thech freshnessline comes once a query was judged and is left out of the reference.