improve sync header map

[zhangsoledad]

What problem does this PR solve?

• Optimize the implementation of header map to improve the speed of header synchronization from 11924/s to 14377/s, about 20% improvement.
• Human-friendly configuration

What is changed and how it works?

• Asynchronous batch write to hard disk when memory limit is exceeded.
• Replace the implementation of header map bankend. Rocksdb has some drawbacks in this scenario, Rocksdb cannot give feedback on whether the key is overwritten when writing, nor can it distinguish between successful or not found when deleting, it's inefficient and looks silly to retrieve a value just to check if it exists or not.

RocksDBBackend::contains_key duration 4041 ns
RocksDBBackend::remove duration 7000 ns
RocksDBBackend::insert duration 10750 ns

Sometimes it deteriorates into the following, because of the inconvenience of implementation：
RocksDBBackend::contains_key duration 10750 ns
RocksDBBackend::remove duration 13000 ns
RocksDBBackend::insert duration 21583 ns

-----------------------------
SledBackend::contains_key duration 2666 ns
SledBackend::remove duration 2583 ns
SledBackend::insert_batch 35503541/10028 ns (3540 ns)

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code ci-runs-only: [ quick_checks,linters ]

Release note

Title Only: Include only the PR title in the release note.

[zhangsoledad]

https://gist.github.com/zhangsoledad/0605a6c98e58437d1796b7fe12638286

[doitian]

Can we remove len and is_empty from KeyValueBackend?

[zhangsoledad]

No, this is used for short-circuiting, when the count is 0 we can skip the db operation, this will be reflected in the profiling.
If you mean can we use sled::len or sled::is_empty , although I haven't actually tried it, but it shouldn't work either, performs a full O(n) scan under the hood from docs

   pub fn len(&self) -> usize {
        self.iter().count()
    }

    /// Returns `true` if the `Tree` contains no elements.
    pub fn is_empty(&self) -> bool {
        self.iter().next().is_none()
    }

   pub(crate) fn next_inner(&mut self) -> Option<<Self as Iterator>::Item> {
        let guard = pin();
        let (mut pid, mut node) = if let (true, Some((pid, node))) =
            (self.going_forward, self.cached_node.take())
        {
            (pid, node)
        } else {
            let view =
                iter_try!(self.tree.view_for_key(self.low_key(), &guard));
            (view.pid, view.deref().clone())
        };

        for _ in 0..MAX_LOOPS {
            if self.bounds_collapsed() {
                return None;
            }

            if !node.contains_upper_bound(&self.lo) {
                ...........
            } else if !node.contains_lower_bound(&self.lo, true) {
               ........
            } else {
                  ........
            }
        }
   
    }

[doitian]

Have you compared the performance difference between consecutive insertions with apply_batch?

[zhangsoledad]

apply_batch has the same problem, it can't give feedback whether a key was overwritten or written directly，Here also tried to compare with transaction，transaction performs worse because of the extra overhead required to guarantee ACID.

[doitian]

Sled has the same memory usage after exiting sync, but has higher peak memory usage during sync.

CC @quake

[driftluo]

bors r+

[bors]

Build succeeded:

• ci_benchmarks_ubuntu
• ci_cargo_deny_ubuntu
• ci_integration_tests_ubuntu
• ci_linters_ubuntu
• ci_quick_checks_ubuntu
• ci_unit_tests_ubuntu
• ci_wasm_build_ubuntu