WIP: Fjall DB engine #906
No reviewers
Labels
No labels
action
check-aws
action
discussion-needed
action
for-external-contributors
action
for-newcomers
action
more-info-needed
action
need-funding
action
triage-required
kind
correctness
kind
ideas
kind
improvement
kind
performance
kind
testing
kind
usability
kind
wrong-behavior
prio
critical
prio
low
scope
admin-api
scope
background-healing
scope
build
scope
documentation
scope
k8s
scope
layout
scope
metadata
scope
ops
scope
rpc
scope
s3-api
scope
security
scope
telemetry
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Deuxfleurs/garage#906
Loading…
Reference in a new issue
No description provided.
Delete branch "withings/garage:feat/fjall-db-engine"
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?
This is a draft implementation for a new meta backend based on LSM trees using fjall. A couple of things to note so far:
ITx::clear
could not be implemented (without iterating/deleting all keys) but I believe this method is never used. Since it's not the first time I encounter that issue, perhaps we could just remove that method?fjall_block_cache_size
to set the block cache size.'r
lifetimes inITx::range
andITx::range_rev
, ended up cloning the bounds to avoid conflicts with'_
.Performance so far has been pretty low on writes, there's definitely some room for improvement in this PR. Using the dashboard from #851:
In my test setup there were also some nasty crashes, which have yet to be explained... Somehow the backend messes with the integrity of the Merkle trees...
I think it would be interesting to see metrics for individual KV operations. I don't see how raw write speed should be slow or get slower, so I'm wondering if the PutObject call is (heavily) read I/O limited, and if so, why.
Also, how much data was written roughly with how much cache and memory, and how large were the resulting trees?
One obvious thing I'm noticing across the code base is that IDs are fully random; something like UUIDv7's, ULID etc. is much better for every KV store, as this will implicitly order new keys closer together, which helps with locality. If it is possible for Garage to use a time ordered ID format, I would strictly recommend it.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.