Yes, for now that’s what we use. We probably should define a StableBTreeSet as a syntactic sugar around this for readability.
Naturally, we are going to use wasm pages to divide different areas. The growth rates of the four types of data A, B, C, and D are different. Any suggestions on the size of the chunks(now is page size) when a new chunks is allocated to data?
Good question. I don’t have a suggestion on what the chunk size should be off the top of my head. Thinking out loud, bigger chunk sizes are likely to translate to better performance, since the canister will need less stable_read calls to read the btree’s virtual address space. On the other hand, bigger chunk sizes would cause us to potentially allocate more of the canister’s memory than we really need. The upper bound to how much memory a canister would unnecessarily allocate is S * C, where S is the number of stable structures we have, and C is the chunk size in wasm pages.
Given S * C, and thinking about how many maps we need and how much memory we’re willing to sacrifice in favor of performance, we can probably come up with a reasonable chunk size for our use-cases.
You could even imagine an adaptive chunk size. When a stable structure asks for more memory, it’s initially given small chunks, and these get progressively larger as the structure grows, but maybe I’m thinking too far ahead already 
Maybe @ulan and/or @roman-kashitsyn have more insights here.