-
Notifications
You must be signed in to change notification settings - Fork 467
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
overlap: use overlapcache #3639
base: master
Are you sure you want to change the base?
Conversation
This commit implements a new overlap cache data structure which will be embedded into `FileMetadata`. The cache works by remembering a handful of data regions and whether the spaces in-between are known to be empty. The goal is to make repeated overlap checks in the same area of a file much cheaper. This will make it feasible to have an optimistic overlap check that can be repeated on a slightly changed version without redoing most of the work.
We embed an overlap cache in `FileMetadata` and use it with the overlap checker. When we have to open a table, we now try to find a maximal empty region and the two surrounding data regions so that we can populate the cache with this information. The cache will be very useful for optimistic overlap checks which happen without blocking compactions, and might need to be retried.
c6fb4b6
to
b0b33cb
Compare
Friendly ping. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the memory overhead of maintaining per-FileMetadata cache sustainable? It's not uncommon to have ~500k-1m sstables in a LSM version
Reviewable status: 0 of 8 files reviewed, all discussions resolved (waiting on @itsbilal and @sumeerbhola)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the memory overhead of maintaining per-FileMetadata cache sustainable? It's not uncommon to have ~500k-1m sstables in a LSM version
In the common case of mostly points, we will have at most 6 keys per FileMetadata. I assumed that's not a huge problem given that we have ~4 keys already for the smallest/largest point/range keys. I can reduce the cache to 4 and it should still be very beneficial.
Or maybe I should at moving towards a separate LRU cache for a limited number of tables?
Reviewable status: 0 of 8 files reviewed, all discussions resolved (waiting on @itsbilal and @sumeerbhola)
We can also greatly reduce the |
Some higher level thoughts from a discussion with @sumeerbhola - I might hold off on this and get more data to establish how effective/necessary this cache is. |
overlap: add overlapcache subpackage
This commit implements a new overlap cache data structure which will
be embedded into
FileMetadata
.The cache works by remembering a handful of data regions and whether
the spaces in-between are known to be empty. The goal is to make
repeated overlap checks in the same area of a file much cheaper. This
will make it feasible to have an optimistic overlap check that can be
repeated on a slightly changed version without redoing most of the
work.
overlap: use overlapcache
We embed an overlap cache in
FileMetadata
and use it with theoverlap checker.
When we have to open a table, we now try to find a maximal empty
region and the two surrounding data regions so that we can populate
the cache with this information.
The cache will be very useful for optimistic overlap checks which
happen without blocking compactions, and might need to be retried.