POC: Zeebe db cache #12677
Closed
POC: Zeebe db cache #12677
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
Not that easy since we have several different key types, and in the ZeebeDB mostly they are generic, so we can align on a common sense which is the byte array or introduce some method to the DbKey interface, to identify the key like hashcode etc. It would be easier if we refactor the API to allow direct types/objects see #12595 In POC i tried it with using long hashcode LRU Cache from agrona not that useful, used later the Cache impl (which is a map with capacity etc.) Run again into the issue of reusing objects, especially values. The cache was corrupted by this, when storing just the values at somepoint all values have changed to the same value with different keys…. Caching is not that straightforward and lot of traps to fall into Two layer caches, one for the current transaction and one for committed data? Dont forget to delete data from cache…
This reverts commit 3ad3dad.
only useful for inside transaction - i guess this is enough. Other solutions makes it too complicated and needs more caches (for each CF)
This was referenced May 5, 2023
|
Closing for now, branch will stay to apply if we need it. |
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
Idea was to cache key-value pairs during a transaction, so if requesting again some values we get them faster. This was straight forward to implement in the ZeebeTransaction itself.
Far more complicated would be a cache which exists over transactions bounds, since we need multiple layers of caches since transactions can be rolled back etc. The first iteration/commits goes into that direction but was far more complicated. Especially we need to make sure to make copies of the key-value pairs, otherwise we run into issues, since key and value instances are reused and changed during runtime. This can be overcome via a new API #12595.
JMH Benchmark doesn't show a significant impact, only in respect of the error rate.
Based on profiling we see that consistency check is the dominator of bad performance, which our cache can overcome, since we mostly request keys which doesn't exist yet (and in consequence are not in the cache).
Even with disabled consistency checks we can see that the gain is not much
Again here we have a better error rate as without cache.
Related issues
closes #
Definition of Done
Not all items need to be done depending on the issue and the pull request.
Code changes:
backport stable/1.3) to the PR, in case that fails you need to create backports manually.Testing:
Documentation:
Other teams:
If the change impacts another team an issue has been created for this team, explaining what they need to do to support this change.
Please refer to our review guidelines.