You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## Motivation
The `BucketQueueView` allows to use queues more efficiently.
## Proposal
It is known that using Queues on Key-Value stores is kind of an
antipattern for KeyValue stores.
Grouping entries into buckets can reduce this problem.
The problem is that grouping increases the memory cost and exposes to
possible Out Of Memory. Thus we did the following:
* For `QueueView` with `BlockHeight` being the type, we use a bucket
size of 1000 since BlockHeight is just 8 bytes.
* For `QueueView` with `TimestampedBundleInInbox` we use a bucket size
of 100 since this type is essentially 4 Cryptohashes, a few number and a
channel name which can be long but not too long.
* For `QueueView` with `MessageBundle` no change is made as this type
can be very large.
It is to be pointed out that `BucketQueueView` has two differences with
`QueueView`:
* Buckets indeed.
* The `front` is no longer an async operation, which means the front is
accessible just after the `load`. On the other hand the `delete_front`
becomes an async operation.
## Test Plan
(A) The CI is the recommended way.
(B) More tests would be needed for correctness.
(C) Runtime would be helpful to gauge the gain effectively obtained.
## Release Plan
This PR changes the way that data is stored in the storage, therefore
using it on existing TestNet / DevNet is impossible.
## Links
None.
0 commit comments