use segregated hmap to boost the freelist allocate and release performace

[WIZARD-CXY]

In this pr, I use segregated bitmap to replace the original freeids allocating and releasing approach.
It is much faster than the original version, especially when the db size is large or the fragmentation in the db is large, we can gain 1000x faster performance.

[WIZARD-CXY]

@xiang90 ptal

[WIZARD-CXY]

@benbjohnson

[mitake]

@WIZARD-CXY Interesting! Could you share how you measure the performance improvement?

[xiang90]

do we really need to add this special case handling?

[WIZARD-CXY]

yeah, common use case we don't request a 0-size page, this is only wanted by unit test in allocating

f.allocate(1, 0)
	if x := f.free_count(); x != 2 {
		t.Fatalf("exp=2; got=%v", x)
	}

[WIZARD-CXY]

@mitake we use bboltdb in etcd. In the original approach, when we have a very large db(~50GB), and do the put op(~5000op/s), we find the db spill time is very large(~8s), the put latency is incredibly large too. We look into the code, add some debugging info and find that freelist allocation is the bottleneck.It is because when the freelist size is large and its inner fragmentation is very common. The original algorithm in allocate tries so hard to get a start page id while in my approach we use a hash map to hold the same size of starting pgids. So the allocation is super fast(nearly O(1)) and the release performance is also boosted too(O(1), removed the original page id sort operation)

[WIZARD-CXY]

@mitake boltdb/bolt#640 this is the same case

[xiang90]

@WIZARD-CXY Let us make this an option instead of entirely replacing the array based freelist implementation.

Probably add an option called FreelistType: (array/seglist)

[xiang90]

/cc @jpbetz

The original freelist is managed by an array. Both allocate/release operation can be O(N). After a bulk deletion (in etcd case, a compaction), the key put can take up to 8 seconds when the freelist size reaches O(1,000,000).

This PR uses a seglist approach to solve the problem like traditional memory allocator does.

[WIZARD-CXY]

@WIZARD-CXY Let us make this an option instead of entirely replacing the array based freelist implementation.Probably add an option called FreelistType: (array/seglist)

working on it

[WIZARD-CXY]

@mitake @xiang90 @hormes petal add a commit to add an option of using the new approach.

[xiang90]

@WIZARD-CXY Can you create a new PR? It can be cleaner.

[mitake]

@WIZARD-CXY thanks for sharing the detail and sorry for my delayed reply. It's really interesting. Do you mean you already have etcd cluster with 50GB of data? Then are you seeing availability problem comes from the large snapshot?
I'm asking for understanding your use case and for curious: I heard alibaba has very large clusters. Is this related that?

[WIZARD-CXY]

@mitake yeah, we stored many data in etcd since we have large clusters