Yes, this is pretty close. In our case each new layer has 10 elements and there's no overlaps, so something like this:
ABCDEFGHIJ KLMNOPQRST
+ +
| |
+-+-+-+-+++-+-+-+-+ +-+-+-+-+++-+-+-+-+
| | | | | | | | | | | | | | | | | | | |
+ + + + + + + + + + + + + + + + + + + +
A B C D E F G H I J K L M N O P Q R S T
And yes, it comes at a cost of increased storage requirements. This is still pretty efficient though as we found out.
Behind the scenes we're using BadgerDB which is a key-value db that handles all the disk operations. All of the data structures we use (segment tries, tries and call trees) are at some point serialized and flushed to disk. For example, here is the trie serialization code https://github.com/pyroscope-io/pyroscope/blob/main/pkg/stor...
Behind the scenes we're using BadgerDB which is a key-value db that handles all the disk operations. All of the data structures we use (segment tries, tries and call trees) are at some point serialized and flushed to disk. For example, here is the trie serialization code https://github.com/pyroscope-io/pyroscope/blob/main/pkg/stor...