Skip to content

[Feat](TimeTravel) Time Travel for Cloud / Decoupled Mode#65431

Draft
nsivarajan wants to merge 4 commits into
apache:masterfrom
nsivarajan:time-travel-pr
Draft

[Feat](TimeTravel) Time Travel for Cloud / Decoupled Mode#65431
nsivarajan wants to merge 4 commits into
apache:masterfrom
nsivarajan:time-travel-pr

Conversation

@nsivarajan

@nsivarajan nsivarajan commented Jul 9, 2026

Copy link
Copy Markdown
Contributor

What problem does this PR solve?

Issue Number: close #65422

Related PR: #xxx

Problem Summary:

Modern analytical workloads require querying data as it existed at a specific point in time — for audit trails, data debugging, incremental pipeline recovery, and regulatory compliance.

Apache Doris cloud/decoupled mode currently has no mechanism to read historical versions of a table. Once data is compacted or overwritten, earlier states are unrecoverable from SQL.

Requested syntax:

SELECT * FROM orders FOR TIME AS OF '2024-01-15 10:00:00';

CREATE TABLE snapshot AS
    SELECT * FROM orders FOR TIME AS OF '2024-01-15 10:00:00';

Supported on all DML table models: Duplicate Key, Unique Key (MoW), and Aggregate Key.

Solution

Key design points

Per-table opt-in — zero overhead for non-TT tables:

 CREATE TABLE orders (...)
 PROPERTIES (
     "enable_time_travel"         = "true",
     "time_travel_retention_days" = "7"
 );

Two-level FDB index (cloud mode):

Level 1: sparse version index — one FDB key per commit per partition (T → V mapping)
Level 2: compaction checkpoint — pre-compaction rowset manifests written before each cumulative compaction, so historical reads survive compaction
One batch RPC resolves all partitions and fetches all manifests in a single FDB transaction — consistent snapshot across all partitions, one network round trip.

Post-compaction correctness — the critical test: a query at timestamp T returns identical results before and after compaction of the rowsets that covered T.

Outcome

MySQL [tt_test_db]> select * from tt_travel_v5;
+------+-----------+--------+
| id   | status    | amount |
+------+-----------+--------+
|    4 | shipped   | 400.00 |
|    5 | delivered | 500.00 |
|    6 | delivered | 600.00 |
|    2 | pending   | 200.00 |
|    1 | pending   | 100.00 |
|    3 | shipped   | 300.00 |
|    7 | delivered | 700.00 |
|    8 | delivered | 800.00 |
+------+-----------+--------+
8 rows in set (0.055 sec)

MySQL [tt_test_db]> SELECT * FROM tt_travel_v5 FOR TIME AS OF '2026-07-05 17:07:35' ORDER BY id;
+------+---------+--------+
| id   | status  | amount |
+------+---------+--------+
|    1 | pending | 100.00 |
|    2 | pending | 200.00 |
+------+---------+--------+
2 rows in set (0.037 sec)

MySQL [tt_test_db]>

Scope

Cloud/decoupled mode only (this PR)
Coupled/local storage mode: same architecture, separate follow-up (~40% effort)
SHOW TIME TRAVEL ON : listed as future work

Release note

None

Check List (For Author)

  • Test

    • Regression test
    • Unit Test
    • Manual test (add detailed scripts or steps below)
    • No need to test or manual test. Explain why:
      • This is a refactor/code format and no logic has been changed.
      • Previous test can cover this change.
      • No code files have been changed.
      • Other reason
  • Behavior changed:

    • No.
    • Yes.
  • Does this need documentation?

    • No.
    • Yes.

Check List (For Reviewer who merge this PR)

  • Confirm the release note
  • Confirm test cases
  • Confirm document
  • Add branch pick label

@hello-stephen

Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@nsivarajan

Copy link
Copy Markdown
Contributor Author

run buildall

@hello-stephen

Copy link
Copy Markdown
Contributor

FE UT Coverage Report

Increment line coverage 28.13% (128/455) 🎉
Increment coverage report
Complete coverage report

@hello-stephen

Copy link
Copy Markdown
Contributor
TPC-H: Total hot run time: 29695 ms
machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/tpch-tools
Tpch sf100 test result on commit a3a74b997ce2929ceb0e234049bad8f34bead14d, data reload: false

------ Round 1 ----------------------------------
============================================
q1	17679	4186	4169	4169
q2	1997	330	220	220
q3	10365	1434	844	844
q4	4683	482	341	341
q5	7484	860	606	606
q6	192	180	144	144
q7	794	852	610	610
q8	9317	1517	1579	1517
q9	5762	4406	4406	4406
q10	6794	1831	1526	1526
q11	519	351	321	321
q12	760	551	432	432
q13	18077	3390	2742	2742
q14	271	263	263	263
q15	q16	796	782	712	712
q17	987	999	1017	999
q18	7026	5900	5474	5474
q19	1362	1340	1067	1067
q20	756	656	516	516
q21	6011	2690	2484	2484
q22	445	361	302	302
Total cold run time: 102077 ms
Total hot run time: 29695 ms

----- Round 2, with runtime_filter_mode=off -----
============================================
q1	4510	4440	4496	4440
q2	315	323	235	235
q3	4666	5051	4394	4394
q4	2135	2237	1383	1383
q5	4573	4439	4381	4381
q6	248	185	134	134
q7	1799	1642	1464	1464
q8	2451	2151	2094	2094
q9	7367	7358	7394	7358
q10	4701	4640	4258	4258
q11	560	405	375	375
q12	768	756	552	552
q13	3023	3411	2735	2735
q14	278	307	267	267
q15	q16	694	711	620	620
q17	1311	1298	1297	1297
q18	7540	7033	6885	6885
q19	1092	1070	1092	1070
q20	2250	2214	1931	1931
q21	5425	4812	4636	4636
q22	557	458	407	407
Total cold run time: 56263 ms
Total hot run time: 50916 ms

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature] Time Travel: SELECT ... FOR TIME AS OF '<timestamp>' in cloud/decoupled mode

2 participants