2018-12-18 01:26:56 +00:00
|
|
|
// Copyright (c) 2018-present, Facebook, Inc. All rights reserved.
|
2017-07-15 23:03:42 +00:00
|
|
|
// This source code is licensed under both the GPLv2 (found in the
|
|
|
|
// COPYING file in the root directory) and Apache 2.0 License
|
|
|
|
// (found in the LICENSE.Apache file in the root directory).
|
Compaction Support for Range Deletion
Summary:
This diff introduces RangeDelAggregator, which takes ownership of iterators
provided to it via AddTombstones(). The tombstones are organized in a two-level
map (snapshot stripe -> begin key -> tombstone). Tombstone creation avoids data
copy by holding Slices returned by the iterator, which remain valid thanks to pinning.
For compaction, we create a hierarchical range tombstone iterator with structure
matching the iterator over compaction input data. An aggregator based on that
iterator is used by CompactionIterator to determine which keys are covered by
range tombstones. In case of merge operand, the same aggregator is used by
MergeHelper. Upon finishing each file in the compaction, relevant range tombstones
are added to the output file's range tombstone metablock and file boundaries are
updated accordingly.
To check whether a key is covered by range tombstone, RangeDelAggregator::ShouldDelete()
considers tombstones in the key's snapshot stripe. When this function is used outside of
compaction, it also checks newer stripes, which can contain covering tombstones. Currently
the intra-stripe check involves a linear scan; however, in the future we plan to collapse ranges
within a stripe such that binary search can be used.
RangeDelAggregator::AddToBuilder() adds all range tombstones in the table's key-range
to a new table's range tombstone meta-block. Since range tombstones may fall in the gap
between files, we may need to extend some files' key-ranges. The strategy is (1) first file
extends as far left as possible and other files do not extend left, (2) all files extend right
until either the start of the next file or the end of the last range tombstone in the gap,
whichever comes first.
One other notable change is adding release/move semantics to ScopedArenaIterator
such that it can be used to transfer ownership of an arena-allocated iterator, similar to
how unique_ptr is used for malloc'd data.
Depends on D61473
Test Plan: compaction_iterator_test, mock_table, end-to-end tests in D63927
Reviewers: sdong, IslamAbdelRahman, wanning, yhchiang, lightmark
Reviewed By: lightmark
Subscribers: andrewkr, dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D62205
2016-10-18 19:04:56 +00:00
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
2018-12-18 01:26:56 +00:00
|
|
|
#include <algorithm>
|
|
|
|
#include <iterator>
|
2018-07-14 05:40:23 +00:00
|
|
|
#include <list>
|
Compaction Support for Range Deletion
Summary:
This diff introduces RangeDelAggregator, which takes ownership of iterators
provided to it via AddTombstones(). The tombstones are organized in a two-level
map (snapshot stripe -> begin key -> tombstone). Tombstone creation avoids data
copy by holding Slices returned by the iterator, which remain valid thanks to pinning.
For compaction, we create a hierarchical range tombstone iterator with structure
matching the iterator over compaction input data. An aggregator based on that
iterator is used by CompactionIterator to determine which keys are covered by
range tombstones. In case of merge operand, the same aggregator is used by
MergeHelper. Upon finishing each file in the compaction, relevant range tombstones
are added to the output file's range tombstone metablock and file boundaries are
updated accordingly.
To check whether a key is covered by range tombstone, RangeDelAggregator::ShouldDelete()
considers tombstones in the key's snapshot stripe. When this function is used outside of
compaction, it also checks newer stripes, which can contain covering tombstones. Currently
the intra-stripe check involves a linear scan; however, in the future we plan to collapse ranges
within a stripe such that binary search can be used.
RangeDelAggregator::AddToBuilder() adds all range tombstones in the table's key-range
to a new table's range tombstone meta-block. Since range tombstones may fall in the gap
between files, we may need to extend some files' key-ranges. The strategy is (1) first file
extends as far left as possible and other files do not extend left, (2) all files extend right
until either the start of the next file or the end of the last range tombstone in the gap,
whichever comes first.
One other notable change is adding release/move semantics to ScopedArenaIterator
such that it can be used to transfer ownership of an arena-allocated iterator, similar to
how unique_ptr is used for malloc'd data.
Depends on D61473
Test Plan: compaction_iterator_test, mock_table, end-to-end tests in D63927
Reviewers: sdong, IslamAbdelRahman, wanning, yhchiang, lightmark
Reviewed By: lightmark
Subscribers: andrewkr, dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D62205
2016-10-18 19:04:56 +00:00
|
|
|
#include <map>
|
2018-05-04 23:37:39 +00:00
|
|
|
#include <set>
|
Compaction Support for Range Deletion
Summary:
This diff introduces RangeDelAggregator, which takes ownership of iterators
provided to it via AddTombstones(). The tombstones are organized in a two-level
map (snapshot stripe -> begin key -> tombstone). Tombstone creation avoids data
copy by holding Slices returned by the iterator, which remain valid thanks to pinning.
For compaction, we create a hierarchical range tombstone iterator with structure
matching the iterator over compaction input data. An aggregator based on that
iterator is used by CompactionIterator to determine which keys are covered by
range tombstones. In case of merge operand, the same aggregator is used by
MergeHelper. Upon finishing each file in the compaction, relevant range tombstones
are added to the output file's range tombstone metablock and file boundaries are
updated accordingly.
To check whether a key is covered by range tombstone, RangeDelAggregator::ShouldDelete()
considers tombstones in the key's snapshot stripe. When this function is used outside of
compaction, it also checks newer stripes, which can contain covering tombstones. Currently
the intra-stripe check involves a linear scan; however, in the future we plan to collapse ranges
within a stripe such that binary search can be used.
RangeDelAggregator::AddToBuilder() adds all range tombstones in the table's key-range
to a new table's range tombstone meta-block. Since range tombstones may fall in the gap
between files, we may need to extend some files' key-ranges. The strategy is (1) first file
extends as far left as possible and other files do not extend left, (2) all files extend right
until either the start of the next file or the end of the last range tombstone in the gap,
whichever comes first.
One other notable change is adding release/move semantics to ScopedArenaIterator
such that it can be used to transfer ownership of an arena-allocated iterator, similar to
how unique_ptr is used for malloc'd data.
Depends on D61473
Test Plan: compaction_iterator_test, mock_table, end-to-end tests in D63927
Reviewers: sdong, IslamAbdelRahman, wanning, yhchiang, lightmark
Reviewed By: lightmark
Subscribers: andrewkr, dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D62205
2016-10-18 19:04:56 +00:00
|
|
|
#include <string>
|
|
|
|
#include <vector>
|
|
|
|
|
2019-05-31 18:52:59 +00:00
|
|
|
#include "db/compaction/compaction_iteration_stats.h"
|
Compaction Support for Range Deletion
Summary:
This diff introduces RangeDelAggregator, which takes ownership of iterators
provided to it via AddTombstones(). The tombstones are organized in a two-level
map (snapshot stripe -> begin key -> tombstone). Tombstone creation avoids data
copy by holding Slices returned by the iterator, which remain valid thanks to pinning.
For compaction, we create a hierarchical range tombstone iterator with structure
matching the iterator over compaction input data. An aggregator based on that
iterator is used by CompactionIterator to determine which keys are covered by
range tombstones. In case of merge operand, the same aggregator is used by
MergeHelper. Upon finishing each file in the compaction, relevant range tombstones
are added to the output file's range tombstone metablock and file boundaries are
updated accordingly.
To check whether a key is covered by range tombstone, RangeDelAggregator::ShouldDelete()
considers tombstones in the key's snapshot stripe. When this function is used outside of
compaction, it also checks newer stripes, which can contain covering tombstones. Currently
the intra-stripe check involves a linear scan; however, in the future we plan to collapse ranges
within a stripe such that binary search can be used.
RangeDelAggregator::AddToBuilder() adds all range tombstones in the table's key-range
to a new table's range tombstone meta-block. Since range tombstones may fall in the gap
between files, we may need to extend some files' key-ranges. The strategy is (1) first file
extends as far left as possible and other files do not extend left, (2) all files extend right
until either the start of the next file or the end of the last range tombstone in the gap,
whichever comes first.
One other notable change is adding release/move semantics to ScopedArenaIterator
such that it can be used to transfer ownership of an arena-allocated iterator, similar to
how unique_ptr is used for malloc'd data.
Depends on D61473
Test Plan: compaction_iterator_test, mock_table, end-to-end tests in D63927
Reviewers: sdong, IslamAbdelRahman, wanning, yhchiang, lightmark
Reviewed By: lightmark
Subscribers: andrewkr, dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D62205
2016-10-18 19:04:56 +00:00
|
|
|
#include "db/dbformat.h"
|
|
|
|
#include "db/pinned_iterators_manager.h"
|
2018-12-18 01:26:56 +00:00
|
|
|
#include "db/range_del_aggregator.h"
|
|
|
|
#include "db/range_tombstone_fragmenter.h"
|
Compaction Support for Range Deletion
Summary:
This diff introduces RangeDelAggregator, which takes ownership of iterators
provided to it via AddTombstones(). The tombstones are organized in a two-level
map (snapshot stripe -> begin key -> tombstone). Tombstone creation avoids data
copy by holding Slices returned by the iterator, which remain valid thanks to pinning.
For compaction, we create a hierarchical range tombstone iterator with structure
matching the iterator over compaction input data. An aggregator based on that
iterator is used by CompactionIterator to determine which keys are covered by
range tombstones. In case of merge operand, the same aggregator is used by
MergeHelper. Upon finishing each file in the compaction, relevant range tombstones
are added to the output file's range tombstone metablock and file boundaries are
updated accordingly.
To check whether a key is covered by range tombstone, RangeDelAggregator::ShouldDelete()
considers tombstones in the key's snapshot stripe. When this function is used outside of
compaction, it also checks newer stripes, which can contain covering tombstones. Currently
the intra-stripe check involves a linear scan; however, in the future we plan to collapse ranges
within a stripe such that binary search can be used.
RangeDelAggregator::AddToBuilder() adds all range tombstones in the table's key-range
to a new table's range tombstone meta-block. Since range tombstones may fall in the gap
between files, we may need to extend some files' key-ranges. The strategy is (1) first file
extends as far left as possible and other files do not extend left, (2) all files extend right
until either the start of the next file or the end of the last range tombstone in the gap,
whichever comes first.
One other notable change is adding release/move semantics to ScopedArenaIterator
such that it can be used to transfer ownership of an arena-allocated iterator, similar to
how unique_ptr is used for malloc'd data.
Depends on D61473
Test Plan: compaction_iterator_test, mock_table, end-to-end tests in D63927
Reviewers: sdong, IslamAbdelRahman, wanning, yhchiang, lightmark
Reviewed By: lightmark
Subscribers: andrewkr, dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D62205
2016-10-18 19:04:56 +00:00
|
|
|
#include "db/version_edit.h"
|
2020-01-22 00:11:08 +00:00
|
|
|
#include "rocksdb/comparator.h"
|
|
|
|
#include "rocksdb/types.h"
|
Compaction Support for Range Deletion
Summary:
This diff introduces RangeDelAggregator, which takes ownership of iterators
provided to it via AddTombstones(). The tombstones are organized in a two-level
map (snapshot stripe -> begin key -> tombstone). Tombstone creation avoids data
copy by holding Slices returned by the iterator, which remain valid thanks to pinning.
For compaction, we create a hierarchical range tombstone iterator with structure
matching the iterator over compaction input data. An aggregator based on that
iterator is used by CompactionIterator to determine which keys are covered by
range tombstones. In case of merge operand, the same aggregator is used by
MergeHelper. Upon finishing each file in the compaction, relevant range tombstones
are added to the output file's range tombstone metablock and file boundaries are
updated accordingly.
To check whether a key is covered by range tombstone, RangeDelAggregator::ShouldDelete()
considers tombstones in the key's snapshot stripe. When this function is used outside of
compaction, it also checks newer stripes, which can contain covering tombstones. Currently
the intra-stripe check involves a linear scan; however, in the future we plan to collapse ranges
within a stripe such that binary search can be used.
RangeDelAggregator::AddToBuilder() adds all range tombstones in the table's key-range
to a new table's range tombstone meta-block. Since range tombstones may fall in the gap
between files, we may need to extend some files' key-ranges. The strategy is (1) first file
extends as far left as possible and other files do not extend left, (2) all files extend right
until either the start of the next file or the end of the last range tombstone in the gap,
whichever comes first.
One other notable change is adding release/move semantics to ScopedArenaIterator
such that it can be used to transfer ownership of an arena-allocated iterator, similar to
how unique_ptr is used for malloc'd data.
Depends on D61473
Test Plan: compaction_iterator_test, mock_table, end-to-end tests in D63927
Reviewers: sdong, IslamAbdelRahman, wanning, yhchiang, lightmark
Reviewed By: lightmark
Subscribers: andrewkr, dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D62205
2016-10-18 19:04:56 +00:00
|
|
|
#include "table/internal_iterator.h"
|
|
|
|
#include "table/scoped_arena_iterator.h"
|
|
|
|
#include "table/table_builder.h"
|
2018-12-18 01:26:56 +00:00
|
|
|
#include "util/heap.h"
|
Compaction Support for Range Deletion
Summary:
This diff introduces RangeDelAggregator, which takes ownership of iterators
provided to it via AddTombstones(). The tombstones are organized in a two-level
map (snapshot stripe -> begin key -> tombstone). Tombstone creation avoids data
copy by holding Slices returned by the iterator, which remain valid thanks to pinning.
For compaction, we create a hierarchical range tombstone iterator with structure
matching the iterator over compaction input data. An aggregator based on that
iterator is used by CompactionIterator to determine which keys are covered by
range tombstones. In case of merge operand, the same aggregator is used by
MergeHelper. Upon finishing each file in the compaction, relevant range tombstones
are added to the output file's range tombstone metablock and file boundaries are
updated accordingly.
To check whether a key is covered by range tombstone, RangeDelAggregator::ShouldDelete()
considers tombstones in the key's snapshot stripe. When this function is used outside of
compaction, it also checks newer stripes, which can contain covering tombstones. Currently
the intra-stripe check involves a linear scan; however, in the future we plan to collapse ranges
within a stripe such that binary search can be used.
RangeDelAggregator::AddToBuilder() adds all range tombstones in the table's key-range
to a new table's range tombstone meta-block. Since range tombstones may fall in the gap
between files, we may need to extend some files' key-ranges. The strategy is (1) first file
extends as far left as possible and other files do not extend left, (2) all files extend right
until either the start of the next file or the end of the last range tombstone in the gap,
whichever comes first.
One other notable change is adding release/move semantics to ScopedArenaIterator
such that it can be used to transfer ownership of an arena-allocated iterator, similar to
how unique_ptr is used for malloc'd data.
Depends on D61473
Test Plan: compaction_iterator_test, mock_table, end-to-end tests in D63927
Reviewers: sdong, IslamAbdelRahman, wanning, yhchiang, lightmark
Reviewed By: lightmark
Subscribers: andrewkr, dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D62205
2016-10-18 19:04:56 +00:00
|
|
|
#include "util/kv_map.h"
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
namespace ROCKSDB_NAMESPACE {
|
2016-10-28 22:44:48 +00:00
|
|
|
|
2018-12-18 01:26:56 +00:00
|
|
|
class TruncatedRangeDelIterator {
|
|
|
|
public:
|
|
|
|
TruncatedRangeDelIterator(
|
|
|
|
std::unique_ptr<FragmentedRangeTombstoneIterator> iter,
|
|
|
|
const InternalKeyComparator* icmp, const InternalKey* smallest,
|
|
|
|
const InternalKey* largest);
|
|
|
|
|
|
|
|
bool Valid() const;
|
|
|
|
|
2022-08-30 02:09:29 +00:00
|
|
|
void Next() { iter_->TopNext(); }
|
|
|
|
void Prev() { iter_->TopPrev(); }
|
2018-12-18 01:26:56 +00:00
|
|
|
|
2022-08-30 02:09:29 +00:00
|
|
|
void InternalNext() { iter_->Next(); }
|
2018-12-18 01:26:56 +00:00
|
|
|
|
2021-03-26 04:17:17 +00:00
|
|
|
// Seeks to the tombstone with the highest visible sequence number that covers
|
2018-12-18 01:26:56 +00:00
|
|
|
// target (a user key). If no such tombstone exists, the position will be at
|
|
|
|
// the earliest tombstone that ends after target.
|
Skip swaths of range tombstone covered keys in merging iterator (2022 edition) (#10449)
Summary:
Delete range logic is moved from `DBIter` to `MergingIterator`, and `MergingIterator` will seek to the end of a range deletion if possible instead of scanning through each key and check with `RangeDelAggregator`.
With the invariant that a key in level L (consider memtable as the first level, each immutable and L0 as a separate level) has a larger sequence number than all keys in any level >L, a range tombstone `[start, end)` from level L covers all keys in its range in any level >L. This property motivates optimizations in iterator:
- in `Seek(target)`, if level L has a range tombstone `[start, end)` that covers `target.UserKey`, then for all levels > L, we can do Seek() on `end` instead of `target` to skip some range tombstone covered keys.
- in `Next()/Prev()`, if the current key is covered by a range tombstone `[start, end)` from level L, we can do `Seek` to `end` for all levels > L.
This PR implements the above optimizations in `MergingIterator`. As all range tombstone covered keys are now skipped in `MergingIterator`, the range tombstone logic is removed from `DBIter`. The idea in this PR is similar to https://github.com/facebook/rocksdb/issues/7317, but this PR leaves `InternalIterator` interface mostly unchanged. **Credit**: the cascading seek optimization and the sentinel key (discussed below) are inspired by [Pebble](https://github.com/cockroachdb/pebble/blob/master/merging_iter.go) and suggested by ajkr in https://github.com/facebook/rocksdb/issues/7317. The two optimizations are mostly implemented in `SeekImpl()/SeekForPrevImpl()` and `IsNextDeleted()/IsPrevDeleted()` in `merging_iterator.cc`. See comments for each method for more detail.
One notable change is that the minHeap/maxHeap used by `MergingIterator` now contains range tombstone end keys besides point key iterators. This helps to reduce the number of key comparisons. For example, for a range tombstone `[start, end)`, a `start` and an `end` `HeapItem` are inserted into the heap. When a `HeapItem` for range tombstone start key is popped from the minHeap, we know this range tombstone becomes "active" in the sense that, before the range tombstone's end key is popped from the minHeap, all the keys popped from this heap is covered by the range tombstone's internal key range `[start, end)`.
Another major change, *delete range sentinel key*, is made to `LevelIterator`. Before this PR, when all point keys in an SST file are iterated through in `MergingIterator`, a level iterator would advance to the next SST file in its level. In the case when an SST file has a range tombstone that covers keys beyond the SST file's last point key, advancing to the next SST file would lose this range tombstone. Consequently, `MergingIterator` could return keys that should have been deleted by some range tombstone. We prevent this by pretending that file boundaries in each SST file are sentinel keys. A `LevelIterator` now only advance the file iterator once the sentinel key is processed.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/10449
Test Plan:
- Added many unit tests in db_range_del_test
- Stress test: `./db_stress --readpercent=5 --prefixpercent=19 --writepercent=20 -delpercent=10 --iterpercent=44 --delrangepercent=2`
- Additional iterator stress test is added to verify against iterators against expected state: https://github.com/facebook/rocksdb/issues/10538. This is based on ajkr's previous attempt https://github.com/facebook/rocksdb/pull/5506#issuecomment-506021913.
```
python3 ./tools/db_crashtest.py blackbox --simple --write_buffer_size=524288 --target_file_size_base=524288 --max_bytes_for_level_base=2097152 --compression_type=none --max_background_compactions=8 --value_size_mult=33 --max_key=5000000 --interval=10 --duration=7200 --delrangepercent=3 --delpercent=9 --iterpercent=25 --writepercent=60 --readpercent=3 --prefixpercent=0 --num_iterations=1000 --range_deletion_width=100 --verify_iterator_with_expected_state_one_in=1
```
- Performance benchmark: I used a similar setup as in the blog [post](http://rocksdb.org/blog/2018/11/21/delete-range.html) that introduced DeleteRange, "a database with 5 million data keys, and 10000 range tombstones (ignoring those dropped during compaction) that were written in regular intervals after 4.5 million data keys were written". As expected, the performance with this PR depends on the range tombstone width.
```
# Setup:
TEST_TMPDIR=/dev/shm ./db_bench_main --benchmarks=fillrandom --writes=4500000 --num=5000000
TEST_TMPDIR=/dev/shm ./db_bench_main --benchmarks=overwrite --writes=500000 --num=5000000 --use_existing_db=true --writes_per_range_tombstone=50
# Scan entire DB
TEST_TMPDIR=/dev/shm ./db_bench_main --benchmarks=readseq[-X5] --use_existing_db=true --num=5000000 --disable_auto_compactions=true
# Short range scan (10 Next())
TEST_TMPDIR=/dev/shm/width-100/ ./db_bench_main --benchmarks=seekrandom[-X5] --use_existing_db=true --num=500000 --reads=100000 --seek_nexts=10 --disable_auto_compactions=true
# Long range scan(1000 Next())
TEST_TMPDIR=/dev/shm/width-100/ ./db_bench_main --benchmarks=seekrandom[-X5] --use_existing_db=true --num=500000 --reads=2500 --seek_nexts=1000 --disable_auto_compactions=true
```
Avg over of 10 runs (some slower tests had fews runs):
For the first column (tombstone), 0 means no range tombstone, 100-10000 means width of the 10k range tombstones, and 1 means there is a single range tombstone in the entire DB (width is 1000). The 1 tombstone case is to test regression when there's very few range tombstones in the DB, as no range tombstone is likely to take a different code path than with range tombstones.
- Scan entire DB
| tombstone width | Pre-PR ops/sec | Post-PR ops/sec | ±% |
| ------------- | ------------- | ------------- | ------------- |
| 0 range tombstone |2525600 (± 43564) |2486917 (± 33698) |-1.53% |
| 100 |1853835 (± 24736) |2073884 (± 32176) |+11.87% |
| 1000 |422415 (± 7466) |1115801 (± 22781) |+164.15% |
| 10000 |22384 (± 227) |227919 (± 6647) |+918.22% |
| 1 range tombstone |2176540 (± 39050) |2434954 (± 24563) |+11.87% |
- Short range scan
| tombstone width | Pre-PR ops/sec | Post-PR ops/sec | ±% |
| ------------- | ------------- | ------------- | ------------- |
| 0 range tombstone |35398 (± 533) |35338 (± 569) |-0.17% |
| 100 |28276 (± 664) |31684 (± 331) |+12.05% |
| 1000 |7637 (± 77) |25422 (± 277) |+232.88% |
| 10000 |1367 |28667 |+1997.07% |
| 1 range tombstone |32618 (± 581) |32748 (± 506) |+0.4% |
- Long range scan
| tombstone width | Pre-PR ops/sec | Post-PR ops/sec | ±% |
| ------------- | ------------- | ------------- | ------------- |
| 0 range tombstone |2262 (± 33) |2353 (± 20) |+4.02% |
| 100 |1696 (± 26) |1926 (± 18) |+13.56% |
| 1000 |410 (± 6) |1255 (± 29) |+206.1% |
| 10000 |25 |414 |+1556.0% |
| 1 range tombstone |1957 (± 30) |2185 (± 44) |+11.65% |
- Microbench does not show significant regression: https://gist.github.com/cbi42/59f280f85a59b678e7e5d8561e693b61
Reviewed By: ajkr
Differential Revision: D38450331
Pulled By: cbi42
fbshipit-source-id: b5ef12e8d8c289ed2e163ccdf277f5039b511fca
2022-09-02 16:51:19 +00:00
|
|
|
// REQUIRES: target is a user key.
|
2018-12-18 01:26:56 +00:00
|
|
|
void Seek(const Slice& target);
|
|
|
|
|
2021-03-26 04:17:17 +00:00
|
|
|
// Seeks to the tombstone with the highest visible sequence number that covers
|
2018-12-18 01:26:56 +00:00
|
|
|
// target (a user key). If no such tombstone exists, the position will be at
|
|
|
|
// the latest tombstone that starts before target.
|
|
|
|
void SeekForPrev(const Slice& target);
|
|
|
|
|
|
|
|
void SeekToFirst();
|
|
|
|
void SeekToLast();
|
|
|
|
|
|
|
|
ParsedInternalKey start_key() const {
|
|
|
|
return (smallest_ == nullptr ||
|
|
|
|
icmp_->Compare(*smallest_, iter_->parsed_start_key()) <= 0)
|
|
|
|
? iter_->parsed_start_key()
|
|
|
|
: *smallest_;
|
|
|
|
}
|
|
|
|
|
|
|
|
ParsedInternalKey end_key() const {
|
|
|
|
return (largest_ == nullptr ||
|
|
|
|
icmp_->Compare(iter_->parsed_end_key(), *largest_) <= 0)
|
|
|
|
? iter_->parsed_end_key()
|
|
|
|
: *largest_;
|
|
|
|
}
|
|
|
|
|
|
|
|
SequenceNumber seq() const { return iter_->seq(); }
|
|
|
|
|
|
|
|
std::map<SequenceNumber, std::unique_ptr<TruncatedRangeDelIterator>>
|
|
|
|
SplitBySnapshot(const std::vector<SequenceNumber>& snapshots);
|
|
|
|
|
|
|
|
SequenceNumber upper_bound() const { return iter_->upper_bound(); }
|
|
|
|
|
|
|
|
SequenceNumber lower_bound() const { return iter_->lower_bound(); }
|
|
|
|
|
|
|
|
private:
|
|
|
|
std::unique_ptr<FragmentedRangeTombstoneIterator> iter_;
|
|
|
|
const InternalKeyComparator* icmp_;
|
|
|
|
const ParsedInternalKey* smallest_ = nullptr;
|
|
|
|
const ParsedInternalKey* largest_ = nullptr;
|
|
|
|
std::list<ParsedInternalKey> pinned_bounds_;
|
|
|
|
|
|
|
|
const InternalKey* smallest_ikey_;
|
|
|
|
const InternalKey* largest_ikey_;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct SeqMaxComparator {
|
|
|
|
bool operator()(const TruncatedRangeDelIterator* a,
|
|
|
|
const TruncatedRangeDelIterator* b) const {
|
|
|
|
return a->seq() > b->seq();
|
|
|
|
}
|
Range deletion performance improvements + cleanup (#4014)
Summary:
This fixes the same performance issue that #3992 fixes but with much more invasive cleanup.
I'm more excited about this PR because it paves the way for fixing another problem we uncovered at Cockroach where range deletion tombstones can cause massive compactions. For example, suppose L4 contains deletions from [a, c) and [x, z) and no other keys, and L5 is entirely empty. L6, however, is full of data. When compacting L4 -> L5, we'll end up with one file that spans, massively, from [a, z). When we go to compact L5 -> L6, we'll have to rewrite all of L6! If, instead of range deletions in L4, we had keys a, b, x, y, and z, RocksDB would have been smart enough to create two files in L5: one for a and b and another for x, y, and z.
With the changes in this PR, it will be possible to adjust the compaction logic to split tombstones/start new output files when they would span too many files in the grandparent level.
ajkr please take a look when you have a minute!
Pull Request resolved: https://github.com/facebook/rocksdb/pull/4014
Differential Revision: D8773253
Pulled By: ajkr
fbshipit-source-id: ec62fa85f648fdebe1380b83ed997f9baec35677
2018-07-12 21:28:10 +00:00
|
|
|
};
|
|
|
|
|
2018-12-18 01:26:56 +00:00
|
|
|
struct StartKeyMinComparator {
|
|
|
|
explicit StartKeyMinComparator(const InternalKeyComparator* c) : icmp(c) {}
|
|
|
|
|
|
|
|
bool operator()(const TruncatedRangeDelIterator* a,
|
|
|
|
const TruncatedRangeDelIterator* b) const {
|
|
|
|
return icmp->Compare(a->start_key(), b->start_key()) > 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
const InternalKeyComparator* icmp;
|
2018-10-09 22:15:27 +00:00
|
|
|
};
|
|
|
|
|
2018-12-18 01:26:56 +00:00
|
|
|
class ForwardRangeDelIterator {
|
Range deletion performance improvements + cleanup (#4014)
Summary:
This fixes the same performance issue that #3992 fixes but with much more invasive cleanup.
I'm more excited about this PR because it paves the way for fixing another problem we uncovered at Cockroach where range deletion tombstones can cause massive compactions. For example, suppose L4 contains deletions from [a, c) and [x, z) and no other keys, and L5 is entirely empty. L6, however, is full of data. When compacting L4 -> L5, we'll end up with one file that spans, massively, from [a, z). When we go to compact L5 -> L6, we'll have to rewrite all of L6! If, instead of range deletions in L4, we had keys a, b, x, y, and z, RocksDB would have been smart enough to create two files in L5: one for a and b and another for x, y, and z.
With the changes in this PR, it will be possible to adjust the compaction logic to split tombstones/start new output files when they would span too many files in the grandparent level.
ajkr please take a look when you have a minute!
Pull Request resolved: https://github.com/facebook/rocksdb/pull/4014
Differential Revision: D8773253
Pulled By: ajkr
fbshipit-source-id: ec62fa85f648fdebe1380b83ed997f9baec35677
2018-07-12 21:28:10 +00:00
|
|
|
public:
|
2018-12-18 22:10:31 +00:00
|
|
|
explicit ForwardRangeDelIterator(const InternalKeyComparator* icmp);
|
2018-12-18 01:26:56 +00:00
|
|
|
|
|
|
|
bool ShouldDelete(const ParsedInternalKey& parsed);
|
|
|
|
void Invalidate();
|
|
|
|
|
|
|
|
void AddNewIter(TruncatedRangeDelIterator* iter,
|
|
|
|
const ParsedInternalKey& parsed) {
|
|
|
|
iter->Seek(parsed.user_key);
|
|
|
|
PushIter(iter, parsed);
|
|
|
|
assert(active_iters_.size() == active_seqnums_.size());
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t UnusedIdx() const { return unused_idx_; }
|
|
|
|
void IncUnusedIdx() { unused_idx_++; }
|
|
|
|
|
|
|
|
private:
|
|
|
|
using ActiveSeqSet =
|
|
|
|
std::multiset<TruncatedRangeDelIterator*, SeqMaxComparator>;
|
|
|
|
|
|
|
|
struct EndKeyMinComparator {
|
|
|
|
explicit EndKeyMinComparator(const InternalKeyComparator* c) : icmp(c) {}
|
|
|
|
|
|
|
|
bool operator()(const ActiveSeqSet::const_iterator& a,
|
|
|
|
const ActiveSeqSet::const_iterator& b) const {
|
|
|
|
return icmp->Compare((*a)->end_key(), (*b)->end_key()) > 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
const InternalKeyComparator* icmp;
|
|
|
|
};
|
|
|
|
|
|
|
|
void PushIter(TruncatedRangeDelIterator* iter,
|
|
|
|
const ParsedInternalKey& parsed) {
|
|
|
|
if (!iter->Valid()) {
|
|
|
|
// The iterator has been fully consumed, so we don't need to add it to
|
|
|
|
// either of the heaps.
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
int cmp = icmp_->Compare(parsed, iter->start_key());
|
|
|
|
if (cmp < 0) {
|
|
|
|
PushInactiveIter(iter);
|
|
|
|
} else {
|
|
|
|
PushActiveIter(iter);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void PushActiveIter(TruncatedRangeDelIterator* iter) {
|
|
|
|
auto seq_pos = active_seqnums_.insert(iter);
|
|
|
|
active_iters_.push(seq_pos);
|
|
|
|
}
|
|
|
|
|
|
|
|
TruncatedRangeDelIterator* PopActiveIter() {
|
|
|
|
auto active_top = active_iters_.top();
|
|
|
|
auto iter = *active_top;
|
|
|
|
active_iters_.pop();
|
|
|
|
active_seqnums_.erase(active_top);
|
|
|
|
return iter;
|
|
|
|
}
|
|
|
|
|
|
|
|
void PushInactiveIter(TruncatedRangeDelIterator* iter) {
|
|
|
|
inactive_iters_.push(iter);
|
|
|
|
}
|
|
|
|
|
|
|
|
TruncatedRangeDelIterator* PopInactiveIter() {
|
|
|
|
auto* iter = inactive_iters_.top();
|
|
|
|
inactive_iters_.pop();
|
|
|
|
return iter;
|
|
|
|
}
|
|
|
|
|
|
|
|
const InternalKeyComparator* icmp_;
|
|
|
|
size_t unused_idx_;
|
|
|
|
ActiveSeqSet active_seqnums_;
|
|
|
|
BinaryHeap<ActiveSeqSet::const_iterator, EndKeyMinComparator> active_iters_;
|
|
|
|
BinaryHeap<TruncatedRangeDelIterator*, StartKeyMinComparator> inactive_iters_;
|
Range deletion performance improvements + cleanup (#4014)
Summary:
This fixes the same performance issue that #3992 fixes but with much more invasive cleanup.
I'm more excited about this PR because it paves the way for fixing another problem we uncovered at Cockroach where range deletion tombstones can cause massive compactions. For example, suppose L4 contains deletions from [a, c) and [x, z) and no other keys, and L5 is entirely empty. L6, however, is full of data. When compacting L4 -> L5, we'll end up with one file that spans, massively, from [a, z). When we go to compact L5 -> L6, we'll have to rewrite all of L6! If, instead of range deletions in L4, we had keys a, b, x, y, and z, RocksDB would have been smart enough to create two files in L5: one for a and b and another for x, y, and z.
With the changes in this PR, it will be possible to adjust the compaction logic to split tombstones/start new output files when they would span too many files in the grandparent level.
ajkr please take a look when you have a minute!
Pull Request resolved: https://github.com/facebook/rocksdb/pull/4014
Differential Revision: D8773253
Pulled By: ajkr
fbshipit-source-id: ec62fa85f648fdebe1380b83ed997f9baec35677
2018-07-12 21:28:10 +00:00
|
|
|
};
|
|
|
|
|
2018-12-18 01:26:56 +00:00
|
|
|
class ReverseRangeDelIterator {
|
Range deletion performance improvements + cleanup (#4014)
Summary:
This fixes the same performance issue that #3992 fixes but with much more invasive cleanup.
I'm more excited about this PR because it paves the way for fixing another problem we uncovered at Cockroach where range deletion tombstones can cause massive compactions. For example, suppose L4 contains deletions from [a, c) and [x, z) and no other keys, and L5 is entirely empty. L6, however, is full of data. When compacting L4 -> L5, we'll end up with one file that spans, massively, from [a, z). When we go to compact L5 -> L6, we'll have to rewrite all of L6! If, instead of range deletions in L4, we had keys a, b, x, y, and z, RocksDB would have been smart enough to create two files in L5: one for a and b and another for x, y, and z.
With the changes in this PR, it will be possible to adjust the compaction logic to split tombstones/start new output files when they would span too many files in the grandparent level.
ajkr please take a look when you have a minute!
Pull Request resolved: https://github.com/facebook/rocksdb/pull/4014
Differential Revision: D8773253
Pulled By: ajkr
fbshipit-source-id: ec62fa85f648fdebe1380b83ed997f9baec35677
2018-07-12 21:28:10 +00:00
|
|
|
public:
|
2018-12-18 22:10:31 +00:00
|
|
|
explicit ReverseRangeDelIterator(const InternalKeyComparator* icmp);
|
Range deletion performance improvements + cleanup (#4014)
Summary:
This fixes the same performance issue that #3992 fixes but with much more invasive cleanup.
I'm more excited about this PR because it paves the way for fixing another problem we uncovered at Cockroach where range deletion tombstones can cause massive compactions. For example, suppose L4 contains deletions from [a, c) and [x, z) and no other keys, and L5 is entirely empty. L6, however, is full of data. When compacting L4 -> L5, we'll end up with one file that spans, massively, from [a, z). When we go to compact L5 -> L6, we'll have to rewrite all of L6! If, instead of range deletions in L4, we had keys a, b, x, y, and z, RocksDB would have been smart enough to create two files in L5: one for a and b and another for x, y, and z.
With the changes in this PR, it will be possible to adjust the compaction logic to split tombstones/start new output files when they would span too many files in the grandparent level.
ajkr please take a look when you have a minute!
Pull Request resolved: https://github.com/facebook/rocksdb/pull/4014
Differential Revision: D8773253
Pulled By: ajkr
fbshipit-source-id: ec62fa85f648fdebe1380b83ed997f9baec35677
2018-07-12 21:28:10 +00:00
|
|
|
|
2018-12-18 01:26:56 +00:00
|
|
|
bool ShouldDelete(const ParsedInternalKey& parsed);
|
|
|
|
void Invalidate();
|
|
|
|
|
|
|
|
void AddNewIter(TruncatedRangeDelIterator* iter,
|
|
|
|
const ParsedInternalKey& parsed) {
|
|
|
|
iter->SeekForPrev(parsed.user_key);
|
|
|
|
PushIter(iter, parsed);
|
|
|
|
assert(active_iters_.size() == active_seqnums_.size());
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t UnusedIdx() const { return unused_idx_; }
|
|
|
|
void IncUnusedIdx() { unused_idx_++; }
|
|
|
|
|
|
|
|
private:
|
|
|
|
using ActiveSeqSet =
|
|
|
|
std::multiset<TruncatedRangeDelIterator*, SeqMaxComparator>;
|
|
|
|
|
|
|
|
struct EndKeyMaxComparator {
|
|
|
|
explicit EndKeyMaxComparator(const InternalKeyComparator* c) : icmp(c) {}
|
|
|
|
|
|
|
|
bool operator()(const TruncatedRangeDelIterator* a,
|
|
|
|
const TruncatedRangeDelIterator* b) const {
|
|
|
|
return icmp->Compare(a->end_key(), b->end_key()) < 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
const InternalKeyComparator* icmp;
|
|
|
|
};
|
|
|
|
struct StartKeyMaxComparator {
|
|
|
|
explicit StartKeyMaxComparator(const InternalKeyComparator* c) : icmp(c) {}
|
|
|
|
|
|
|
|
bool operator()(const ActiveSeqSet::const_iterator& a,
|
|
|
|
const ActiveSeqSet::const_iterator& b) const {
|
|
|
|
return icmp->Compare((*a)->start_key(), (*b)->start_key()) < 0;
|
|
|
|
}
|
Range deletion performance improvements + cleanup (#4014)
Summary:
This fixes the same performance issue that #3992 fixes but with much more invasive cleanup.
I'm more excited about this PR because it paves the way for fixing another problem we uncovered at Cockroach where range deletion tombstones can cause massive compactions. For example, suppose L4 contains deletions from [a, c) and [x, z) and no other keys, and L5 is entirely empty. L6, however, is full of data. When compacting L4 -> L5, we'll end up with one file that spans, massively, from [a, z). When we go to compact L5 -> L6, we'll have to rewrite all of L6! If, instead of range deletions in L4, we had keys a, b, x, y, and z, RocksDB would have been smart enough to create two files in L5: one for a and b and another for x, y, and z.
With the changes in this PR, it will be possible to adjust the compaction logic to split tombstones/start new output files when they would span too many files in the grandparent level.
ajkr please take a look when you have a minute!
Pull Request resolved: https://github.com/facebook/rocksdb/pull/4014
Differential Revision: D8773253
Pulled By: ajkr
fbshipit-source-id: ec62fa85f648fdebe1380b83ed997f9baec35677
2018-07-12 21:28:10 +00:00
|
|
|
|
2018-12-18 01:26:56 +00:00
|
|
|
const InternalKeyComparator* icmp;
|
|
|
|
};
|
|
|
|
|
|
|
|
void PushIter(TruncatedRangeDelIterator* iter,
|
|
|
|
const ParsedInternalKey& parsed) {
|
|
|
|
if (!iter->Valid()) {
|
|
|
|
// The iterator has been fully consumed, so we don't need to add it to
|
|
|
|
// either of the heaps.
|
|
|
|
} else if (icmp_->Compare(iter->end_key(), parsed) <= 0) {
|
|
|
|
PushInactiveIter(iter);
|
|
|
|
} else {
|
|
|
|
PushActiveIter(iter);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void PushActiveIter(TruncatedRangeDelIterator* iter) {
|
|
|
|
auto seq_pos = active_seqnums_.insert(iter);
|
|
|
|
active_iters_.push(seq_pos);
|
|
|
|
}
|
|
|
|
|
|
|
|
TruncatedRangeDelIterator* PopActiveIter() {
|
|
|
|
auto active_top = active_iters_.top();
|
|
|
|
auto iter = *active_top;
|
|
|
|
active_iters_.pop();
|
|
|
|
active_seqnums_.erase(active_top);
|
|
|
|
return iter;
|
|
|
|
}
|
Range deletion performance improvements + cleanup (#4014)
Summary:
This fixes the same performance issue that #3992 fixes but with much more invasive cleanup.
I'm more excited about this PR because it paves the way for fixing another problem we uncovered at Cockroach where range deletion tombstones can cause massive compactions. For example, suppose L4 contains deletions from [a, c) and [x, z) and no other keys, and L5 is entirely empty. L6, however, is full of data. When compacting L4 -> L5, we'll end up with one file that spans, massively, from [a, z). When we go to compact L5 -> L6, we'll have to rewrite all of L6! If, instead of range deletions in L4, we had keys a, b, x, y, and z, RocksDB would have been smart enough to create two files in L5: one for a and b and another for x, y, and z.
With the changes in this PR, it will be possible to adjust the compaction logic to split tombstones/start new output files when they would span too many files in the grandparent level.
ajkr please take a look when you have a minute!
Pull Request resolved: https://github.com/facebook/rocksdb/pull/4014
Differential Revision: D8773253
Pulled By: ajkr
fbshipit-source-id: ec62fa85f648fdebe1380b83ed997f9baec35677
2018-07-12 21:28:10 +00:00
|
|
|
|
2018-12-18 01:26:56 +00:00
|
|
|
void PushInactiveIter(TruncatedRangeDelIterator* iter) {
|
|
|
|
inactive_iters_.push(iter);
|
|
|
|
}
|
|
|
|
|
|
|
|
TruncatedRangeDelIterator* PopInactiveIter() {
|
|
|
|
auto* iter = inactive_iters_.top();
|
|
|
|
inactive_iters_.pop();
|
|
|
|
return iter;
|
|
|
|
}
|
|
|
|
|
|
|
|
const InternalKeyComparator* icmp_;
|
|
|
|
size_t unused_idx_;
|
|
|
|
ActiveSeqSet active_seqnums_;
|
|
|
|
BinaryHeap<ActiveSeqSet::const_iterator, StartKeyMaxComparator> active_iters_;
|
|
|
|
BinaryHeap<TruncatedRangeDelIterator*, EndKeyMaxComparator> inactive_iters_;
|
Range deletion performance improvements + cleanup (#4014)
Summary:
This fixes the same performance issue that #3992 fixes but with much more invasive cleanup.
I'm more excited about this PR because it paves the way for fixing another problem we uncovered at Cockroach where range deletion tombstones can cause massive compactions. For example, suppose L4 contains deletions from [a, c) and [x, z) and no other keys, and L5 is entirely empty. L6, however, is full of data. When compacting L4 -> L5, we'll end up with one file that spans, massively, from [a, z). When we go to compact L5 -> L6, we'll have to rewrite all of L6! If, instead of range deletions in L4, we had keys a, b, x, y, and z, RocksDB would have been smart enough to create two files in L5: one for a and b and another for x, y, and z.
With the changes in this PR, it will be possible to adjust the compaction logic to split tombstones/start new output files when they would span too many files in the grandparent level.
ajkr please take a look when you have a minute!
Pull Request resolved: https://github.com/facebook/rocksdb/pull/4014
Differential Revision: D8773253
Pulled By: ajkr
fbshipit-source-id: ec62fa85f648fdebe1380b83ed997f9baec35677
2018-07-12 21:28:10 +00:00
|
|
|
};
|
|
|
|
|
2018-12-18 01:26:56 +00:00
|
|
|
enum class RangeDelPositioningMode { kForwardTraversal, kBackwardTraversal };
|
Compaction Support for Range Deletion
Summary:
This diff introduces RangeDelAggregator, which takes ownership of iterators
provided to it via AddTombstones(). The tombstones are organized in a two-level
map (snapshot stripe -> begin key -> tombstone). Tombstone creation avoids data
copy by holding Slices returned by the iterator, which remain valid thanks to pinning.
For compaction, we create a hierarchical range tombstone iterator with structure
matching the iterator over compaction input data. An aggregator based on that
iterator is used by CompactionIterator to determine which keys are covered by
range tombstones. In case of merge operand, the same aggregator is used by
MergeHelper. Upon finishing each file in the compaction, relevant range tombstones
are added to the output file's range tombstone metablock and file boundaries are
updated accordingly.
To check whether a key is covered by range tombstone, RangeDelAggregator::ShouldDelete()
considers tombstones in the key's snapshot stripe. When this function is used outside of
compaction, it also checks newer stripes, which can contain covering tombstones. Currently
the intra-stripe check involves a linear scan; however, in the future we plan to collapse ranges
within a stripe such that binary search can be used.
RangeDelAggregator::AddToBuilder() adds all range tombstones in the table's key-range
to a new table's range tombstone meta-block. Since range tombstones may fall in the gap
between files, we may need to extend some files' key-ranges. The strategy is (1) first file
extends as far left as possible and other files do not extend left, (2) all files extend right
until either the start of the next file or the end of the last range tombstone in the gap,
whichever comes first.
One other notable change is adding release/move semantics to ScopedArenaIterator
such that it can be used to transfer ownership of an arena-allocated iterator, similar to
how unique_ptr is used for malloc'd data.
Depends on D61473
Test Plan: compaction_iterator_test, mock_table, end-to-end tests in D63927
Reviewers: sdong, IslamAbdelRahman, wanning, yhchiang, lightmark
Reviewed By: lightmark
Subscribers: andrewkr, dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D62205
2016-10-18 19:04:56 +00:00
|
|
|
class RangeDelAggregator {
|
|
|
|
public:
|
2018-12-18 01:26:56 +00:00
|
|
|
explicit RangeDelAggregator(const InternalKeyComparator* icmp)
|
|
|
|
: icmp_(icmp) {}
|
|
|
|
virtual ~RangeDelAggregator() {}
|
|
|
|
|
|
|
|
virtual void AddTombstones(
|
|
|
|
std::unique_ptr<FragmentedRangeTombstoneIterator> input_iter,
|
|
|
|
const InternalKey* smallest = nullptr,
|
|
|
|
const InternalKey* largest = nullptr) = 0;
|
|
|
|
|
2022-08-30 02:09:29 +00:00
|
|
|
bool ShouldDelete(const Slice& ikey, RangeDelPositioningMode mode) {
|
2018-12-18 01:26:56 +00:00
|
|
|
ParsedInternalKey parsed;
|
2020-10-01 02:15:42 +00:00
|
|
|
|
2020-10-28 17:11:13 +00:00
|
|
|
Status pik_status =
|
2022-08-30 02:09:29 +00:00
|
|
|
ParseInternalKey(ikey, &parsed, false /* log_err_key */); // TODO
|
2020-10-28 17:11:13 +00:00
|
|
|
assert(pik_status.ok());
|
|
|
|
if (!pik_status.ok()) {
|
2017-09-14 22:41:19 +00:00
|
|
|
return false;
|
|
|
|
}
|
2020-10-01 02:15:42 +00:00
|
|
|
|
2018-12-18 01:26:56 +00:00
|
|
|
return ShouldDelete(parsed, mode);
|
2017-09-14 22:41:19 +00:00
|
|
|
}
|
2018-12-18 01:26:56 +00:00
|
|
|
virtual bool ShouldDelete(const ParsedInternalKey& parsed,
|
|
|
|
RangeDelPositioningMode mode) = 0;
|
|
|
|
|
|
|
|
virtual void InvalidateRangeDelMapPositions() = 0;
|
|
|
|
|
|
|
|
virtual bool IsEmpty() const = 0;
|
|
|
|
|
|
|
|
bool AddFile(uint64_t file_number) {
|
|
|
|
return files_seen_.insert(file_number).second;
|
|
|
|
}
|
|
|
|
|
|
|
|
protected:
|
|
|
|
class StripeRep {
|
|
|
|
public:
|
|
|
|
StripeRep(const InternalKeyComparator* icmp, SequenceNumber upper_bound,
|
|
|
|
SequenceNumber lower_bound)
|
|
|
|
: icmp_(icmp),
|
2018-12-18 22:10:31 +00:00
|
|
|
forward_iter_(icmp),
|
|
|
|
reverse_iter_(icmp),
|
2018-12-18 01:26:56 +00:00
|
|
|
upper_bound_(upper_bound),
|
|
|
|
lower_bound_(lower_bound) {}
|
|
|
|
|
|
|
|
void AddTombstones(std::unique_ptr<TruncatedRangeDelIterator> input_iter) {
|
|
|
|
iters_.push_back(std::move(input_iter));
|
2017-09-14 22:41:19 +00:00
|
|
|
}
|
2018-12-18 01:26:56 +00:00
|
|
|
|
|
|
|
bool IsEmpty() const { return iters_.empty(); }
|
|
|
|
|
|
|
|
bool ShouldDelete(const ParsedInternalKey& parsed,
|
|
|
|
RangeDelPositioningMode mode);
|
|
|
|
|
|
|
|
void Invalidate() {
|
2019-05-16 22:20:19 +00:00
|
|
|
if (!IsEmpty()) {
|
|
|
|
InvalidateForwardIter();
|
|
|
|
InvalidateReverseIter();
|
|
|
|
}
|
2018-12-18 01:26:56 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool IsRangeOverlapped(const Slice& start, const Slice& end);
|
|
|
|
|
|
|
|
private:
|
|
|
|
bool InStripe(SequenceNumber seq) const {
|
|
|
|
return lower_bound_ <= seq && seq <= upper_bound_;
|
|
|
|
}
|
|
|
|
|
|
|
|
void InvalidateForwardIter() { forward_iter_.Invalidate(); }
|
|
|
|
|
|
|
|
void InvalidateReverseIter() { reverse_iter_.Invalidate(); }
|
|
|
|
|
|
|
|
const InternalKeyComparator* icmp_;
|
|
|
|
std::vector<std::unique_ptr<TruncatedRangeDelIterator>> iters_;
|
|
|
|
ForwardRangeDelIterator forward_iter_;
|
|
|
|
ReverseRangeDelIterator reverse_iter_;
|
|
|
|
SequenceNumber upper_bound_;
|
|
|
|
SequenceNumber lower_bound_;
|
|
|
|
};
|
|
|
|
|
|
|
|
const InternalKeyComparator* icmp_;
|
|
|
|
|
|
|
|
private:
|
|
|
|
std::set<uint64_t> files_seen_;
|
|
|
|
};
|
|
|
|
|
2019-04-18 19:22:29 +00:00
|
|
|
class ReadRangeDelAggregator final : public RangeDelAggregator {
|
2018-12-18 01:26:56 +00:00
|
|
|
public:
|
|
|
|
ReadRangeDelAggregator(const InternalKeyComparator* icmp,
|
|
|
|
SequenceNumber upper_bound)
|
|
|
|
: RangeDelAggregator(icmp),
|
|
|
|
rep_(icmp, upper_bound, 0 /* lower_bound */) {}
|
|
|
|
~ReadRangeDelAggregator() override {}
|
|
|
|
|
|
|
|
using RangeDelAggregator::ShouldDelete;
|
|
|
|
void AddTombstones(
|
|
|
|
std::unique_ptr<FragmentedRangeTombstoneIterator> input_iter,
|
|
|
|
const InternalKey* smallest = nullptr,
|
|
|
|
const InternalKey* largest = nullptr) override;
|
|
|
|
|
|
|
|
bool ShouldDelete(const ParsedInternalKey& parsed,
|
2019-04-18 19:22:29 +00:00
|
|
|
RangeDelPositioningMode mode) final override {
|
|
|
|
if (rep_.IsEmpty()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return ShouldDeleteImpl(parsed, mode);
|
|
|
|
}
|
2018-12-18 01:26:56 +00:00
|
|
|
|
2017-11-28 19:18:42 +00:00
|
|
|
bool IsRangeOverlapped(const Slice& start, const Slice& end);
|
|
|
|
|
2018-12-18 01:26:56 +00:00
|
|
|
void InvalidateRangeDelMapPositions() override { rep_.Invalidate(); }
|
|
|
|
|
|
|
|
bool IsEmpty() const override { return rep_.IsEmpty(); }
|
Maintain position in range deletions map
Summary:
When deletion-collapsing mode is enabled (i.e., for DBIter/CompactionIterator), we maintain position in the tombstone maps across calls to ShouldDelete(). Since iterators often access keys sequentially (or reverse-sequentially), scanning forward/backward from the last position can be faster than binary-searching the map for every key.
- When Next() is invoked on an iterator, we use kForwardTraversal to scan forwards, if needed, until arriving at the range deletion containing the next key.
- Similarly for Prev(), we use kBackwardTraversal to scan backwards in the range deletion map.
- When the iterator seeks, we use kBinarySearch for repositioning
- After tombstones are added or before the first ShouldDelete() invocation, the current position is set to invalid, which forces kBinarySearch to be used.
- Non-iterator users (i.e., Get()) use kFullScan, which has the same behavior as before---scan the whole map for every key passed to ShouldDelete().
Closes https://github.com/facebook/rocksdb/pull/1701
Differential Revision: D4350318
Pulled By: ajkr
fbshipit-source-id: 5129b76
2017-01-05 18:22:46 +00:00
|
|
|
|
Range deletion performance improvements + cleanup (#4014)
Summary:
This fixes the same performance issue that #3992 fixes but with much more invasive cleanup.
I'm more excited about this PR because it paves the way for fixing another problem we uncovered at Cockroach where range deletion tombstones can cause massive compactions. For example, suppose L4 contains deletions from [a, c) and [x, z) and no other keys, and L5 is entirely empty. L6, however, is full of data. When compacting L4 -> L5, we'll end up with one file that spans, massively, from [a, z). When we go to compact L5 -> L6, we'll have to rewrite all of L6! If, instead of range deletions in L4, we had keys a, b, x, y, and z, RocksDB would have been smart enough to create two files in L5: one for a and b and another for x, y, and z.
With the changes in this PR, it will be possible to adjust the compaction logic to split tombstones/start new output files when they would span too many files in the grandparent level.
ajkr please take a look when you have a minute!
Pull Request resolved: https://github.com/facebook/rocksdb/pull/4014
Differential Revision: D8773253
Pulled By: ajkr
fbshipit-source-id: ec62fa85f648fdebe1380b83ed997f9baec35677
2018-07-12 21:28:10 +00:00
|
|
|
private:
|
2018-12-18 01:26:56 +00:00
|
|
|
StripeRep rep_;
|
2019-04-18 19:22:29 +00:00
|
|
|
|
|
|
|
bool ShouldDeleteImpl(const ParsedInternalKey& parsed,
|
|
|
|
RangeDelPositioningMode mode);
|
2018-12-18 01:26:56 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
class CompactionRangeDelAggregator : public RangeDelAggregator {
|
|
|
|
public:
|
|
|
|
CompactionRangeDelAggregator(const InternalKeyComparator* icmp,
|
|
|
|
const std::vector<SequenceNumber>& snapshots)
|
|
|
|
: RangeDelAggregator(icmp), snapshots_(&snapshots) {}
|
|
|
|
~CompactionRangeDelAggregator() override {}
|
|
|
|
|
|
|
|
void AddTombstones(
|
|
|
|
std::unique_ptr<FragmentedRangeTombstoneIterator> input_iter,
|
|
|
|
const InternalKey* smallest = nullptr,
|
|
|
|
const InternalKey* largest = nullptr) override;
|
|
|
|
|
|
|
|
using RangeDelAggregator::ShouldDelete;
|
|
|
|
bool ShouldDelete(const ParsedInternalKey& parsed,
|
|
|
|
RangeDelPositioningMode mode) override;
|
|
|
|
|
|
|
|
bool IsRangeOverlapped(const Slice& start, const Slice& end);
|
|
|
|
|
|
|
|
void InvalidateRangeDelMapPositions() override {
|
|
|
|
for (auto& rep : reps_) {
|
|
|
|
rep.second.Invalidate();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bool IsEmpty() const override {
|
|
|
|
for (const auto& rep : reps_) {
|
|
|
|
if (!rep.second.IsEmpty()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Creates an iterator over all the range tombstones in the aggregator, for
|
|
|
|
// use in compaction. Nullptr arguments indicate that the iterator range is
|
|
|
|
// unbounded.
|
|
|
|
// NOTE: the boundaries are used for optimization purposes to reduce the
|
|
|
|
// number of tombstones that are passed to the fragmenter; they do not
|
|
|
|
// guarantee that the resulting iterator only contains range tombstones that
|
|
|
|
// cover keys in the provided range. If required, these bounds must be
|
|
|
|
// enforced during iteration.
|
|
|
|
std::unique_ptr<FragmentedRangeTombstoneIterator> NewIterator(
|
|
|
|
const Slice* lower_bound = nullptr, const Slice* upper_bound = nullptr,
|
|
|
|
bool upper_bound_inclusive = false);
|
|
|
|
|
|
|
|
private:
|
|
|
|
std::vector<std::unique_ptr<TruncatedRangeDelIterator>> parent_iters_;
|
|
|
|
std::map<SequenceNumber, StripeRep> reps_;
|
|
|
|
|
|
|
|
const std::vector<SequenceNumber>* snapshots_;
|
Compaction Support for Range Deletion
Summary:
This diff introduces RangeDelAggregator, which takes ownership of iterators
provided to it via AddTombstones(). The tombstones are organized in a two-level
map (snapshot stripe -> begin key -> tombstone). Tombstone creation avoids data
copy by holding Slices returned by the iterator, which remain valid thanks to pinning.
For compaction, we create a hierarchical range tombstone iterator with structure
matching the iterator over compaction input data. An aggregator based on that
iterator is used by CompactionIterator to determine which keys are covered by
range tombstones. In case of merge operand, the same aggregator is used by
MergeHelper. Upon finishing each file in the compaction, relevant range tombstones
are added to the output file's range tombstone metablock and file boundaries are
updated accordingly.
To check whether a key is covered by range tombstone, RangeDelAggregator::ShouldDelete()
considers tombstones in the key's snapshot stripe. When this function is used outside of
compaction, it also checks newer stripes, which can contain covering tombstones. Currently
the intra-stripe check involves a linear scan; however, in the future we plan to collapse ranges
within a stripe such that binary search can be used.
RangeDelAggregator::AddToBuilder() adds all range tombstones in the table's key-range
to a new table's range tombstone meta-block. Since range tombstones may fall in the gap
between files, we may need to extend some files' key-ranges. The strategy is (1) first file
extends as far left as possible and other files do not extend left, (2) all files extend right
until either the start of the next file or the end of the last range tombstone in the gap,
whichever comes first.
One other notable change is adding release/move semantics to ScopedArenaIterator
such that it can be used to transfer ownership of an arena-allocated iterator, similar to
how unique_ptr is used for malloc'd data.
Depends on D61473
Test Plan: compaction_iterator_test, mock_table, end-to-end tests in D63927
Reviewers: sdong, IslamAbdelRahman, wanning, yhchiang, lightmark
Reviewed By: lightmark
Subscribers: andrewkr, dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D62205
2016-10-18 19:04:56 +00:00
|
|
|
};
|
2016-11-19 22:14:35 +00:00
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
} // namespace ROCKSDB_NAMESPACE
|