storage: use buckets in BoltDB backend #1748
Conversation
|
Moving NEO/GAS contract storage to a separate bucket also doesn't affect restore time. |
pkg/core/storage/boltdb_store.go
Outdated
| _, err = tx.CreateBucketIfNotExists(Bucket) | ||
| if err != nil { | ||
| return fmt.Errorf("could not create root bucket: %w", err) | ||
| for i := 0; i <= 255; i++ { |
There was a problem hiding this comment.
You can create less buckets, all real prefixes are well-known.
| return b.Delete(key) | ||
| k1, k2 := split(key) | ||
| b := tx.Bucket(k1) | ||
| return b.Delete(k2) | ||
| }) | ||
| } | ||
|
|
||
| // PutBatch implements the Store interface. | ||
| func (s *BoltDBStore) PutBatch(batch Batch) error { | ||
| return s.db.Batch(func(tx *bbolt.Tx) error { |
There was a problem hiding this comment.
And we can use Update here, I think.
| } | ||
| return key[:1], key | ||
| default: | ||
| return key[:1], key |
There was a problem hiding this comment.
We have very limited number of cases where key[1:] is zero-length, maybe we should try fixing them and providing proper split here. I'm not sure it'll change anything, but who knows.
pkg/core/storage/boltdb_store.go
Outdated
| if err != nil { | ||
| return err | ||
| } | ||
| _, err = tx.CreateBucketIfNotExists([]byte{byte(DataMPT), byte(i)}) |
There was a problem hiding this comment.
MPT probably is not worth splitting.
1. Splitting 1-byte prefix _seems_ to decrease restore time by about 25% under heavy workload. However this difference is actually flat 25s gained only during first persist cycle (on master branch it takes 25s, while here it takes 1s). When restoring is done from the 10-th block, running times don't differ at all. 2. Single-node benchmark performance difference is negligible.
|
OK, I've played with it a little and no matter what I do nothing really changes, it's all at the level of test tolerance. So just adding buckets doesn't magically improve performance and thus it's not worth doing. |
KeepOnlyLatestState: true.Keys in bucket aren't stripped because it is prohibited to put empty key in bucket. With stripping implementation will become more complicate and I expect no performance gains because of the need to append prefix in
Seek.Some other bucketing strategies can be discussed, however it is obvious that most of the load is due to MPT.
Stats regarding keys in DB for this bench (100 blocks, 10k tx per block, single
storage.Putfor the same contract per tx):DataMPT(stores MPT nodes) contains ~4M keys. Splitting this into another 256 buckets decreases B-tree depth from 4 to 3. The distribution is uniform because keys are hashes, so this makes sense.DataTransactionandSTStoragecontain ~1M keys.TODO: