Simplify/modify/refactor Blobovniczas
#18
Labels
No labels
P0
P1
P2
P3
badger
frostfs-adm
frostfs-cli
frostfs-ir
frostfs-lens
frostfs-node
good first issue
triage
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Depends on
#81 Add benchmarks for blobstor components
TrueCloudLab/frostfs-node
#14 Add local targets
TrueCloudLab/xk6-frostfs
Reference: TrueCloudLab/frostfs-node#18
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
It becomes hard to maintain its code and it still contains some bugs (at least many
could not read object from opened blobovnicza {"path": "9/0/0", "error": "database not open"}
was found by me). No performance argumentation is remembered, no open blzs cache understanding has been kept by the devs, etc.Revise its structure (i mean the blobovniczas tree), understand if it helps to have such a nested structure and if it is much more better than the flat one. Also, does the node have to close databases? Is ~5K open files too big for a production server?
Let's first try a single bolt DB.
I'd suggest keep the ability to have more than one blobovnicza instance per shard for the case when we may hit single BBoltDB performance limit.
@realloc of course. We would like to try simple bolt db (the backend itself could be reused in write-cache, for example), see when degradation occurs with TrueCloudLab/xk6-frostfs#14 , then with this data in mind try flat structure with multiple blobovniczas.
Here's a small comparison for write workloads. The blobovnicza config is the standard one, while the flat bolt implementation is the one here, with 8 database files per substorage:
Blobovnicza:
Boltstore:
Overall, they are both rather slow for write workloads, which is confirmed by the Go benchmarks as well. This might have to do with the underlying database itself (bbolt). A LSMT-based implementation (badger, leveldb) might perform a lot better.
Here's a comparison for write workloads between blobovnicza and a single badger DB.
Test conditions:
Common config:
Blobovnicza config:
Badger config:
Request Duration:
Request count:
We have added
leaf_width
and allow to rebuild the whole tree in the runtime.Cache problems are also fixed, I am closing this.
Working on other blobstor prototypes is being done in separate tasks.