clp-s: Add support for decompression in ascending timestamp order. #440
Conversation
This file contains 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
wraymo
reviewed
Jun 13, 2024
| decompression_options.add_options()( | ||
| "ordered", | ||
| po::bool_switch(&m_ordered_decompression), | ||
| "Enable in-order decompression for this archive" |
There was a problem hiding this comment.
Do we want to make it clear that "order" is based on timestamp?
There was a problem hiding this comment.
Yeah, I had some vague idea that we'd transparently use timestamp or MOT depending on what was available in the archive, but being explicit is best for now.
| */ | ||
| epochtime_t get_next_timestamp() const { return m_get_timestamp(); } | ||
|
|
||
| bool done() const { return m_cur_message >= m_num_messages; } |
There was a problem hiding this comment.
Do we want to add a description for this method?
| auto& schema_reader | ||
| = create_schema_reader(schema_id, should_extract_timestamp, should_marshal_records); | ||
| create_schema_reader( | ||
| m_schema_reader, |
There was a problem hiding this comment.
Do you want to rename it to initialize_schema_reader?
| return m_schema_reader; | ||
| } | ||
|
|
||
| std::vector<std::shared_ptr<SchemaReader>> ArchiveReader::load_all_tables() { |
There was a problem hiding this comment.
Do you want to rename it to read_all_tables (we have read_table above)?
| @@ -49,8 +51,11 @@ class JsonConstructor { | |||
| void store(); | |||
|
|
|||
| private: | |||
| void construct_in_order(FileWriter& writer); | |||
There was a problem hiding this comment.
Can you add a description for this method?
Co-authored-by: wraymo <37269683+wraymo@users.noreply.github.com>
wraymo
reviewed
Jun 14, 2024
gibber9809
changed the title
wraymo
approved these changes
Jun 14, 2024
gibber9809
changed the title
jackluo923
pushed a commit
to jackluo923/clp
that referenced
this pull request
Dec 4, 2024
…-scope#440) Co-authored-by: wraymo <37269683+wraymo@users.noreply.github.com>
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.
Description
This PR adds support to decompress a clp-s archive in timestamp order with the
--orderedcommand line option. This is implemented by loading all tables into memory, putting them into a min-heap ordered by the timestamp of the next record in each table, and popping from the heap until all records have been decompressed. The timestamp is pulled from the authoritative timestamp column specified at compression time, and if a table does not contain such a column the timestamp is 0 for ordering purposes.Note: we don't sort by timestamp within each table, so the logs can end up slightly out of timestamp order (this is probably preferred anyway, since it brings us closer to log order).
This seems to add minimal decompression speed overhead (about 2.5%) for fairly typical archives, though would likely have higher overhead for large archives or archives with many tables (due to extra memory allocations compared to decompressing one table at a time). Similarly there can be significant memory overhead, particularly for large archives.
Validation performed