should app canister push blocks to archive canister?
or should archive canister pull blocks from app canister?
or some other ways?
IMO it depends a lot on your setup. Currently, most of the DFINITY-written ledgers push blocks to the archive. However, that decision was made before there were concrete plans to expand stable memory beyond 4GB. I heard people say that today they would simply put everything into stable memory and not worry about running over the limits of a single canister until the blocks use 100GB or so. This is also what we do with the cycles ledger, which was written when stable memory was already 100GB in size, and today it is 400GB IIRC.
Assuming simply keeping everything in stable memory is not an option for you, here’s a few points to consider:
- How do you decide to create a new archive? Which canister will create the archive? Likely the app canister needs to create the first one, so it probably should create all of them. This also aligns a bit better with pushing blocks IMO
- Pushing blocks can be done exactly when necessary. Pulling needs to happen on a timer or some other triggering mechanism, so you get more overhead work
- Pushing blocks is a bit more work for the app canister. If you worry about throughput of the app canister, pulling is likely a bit better
- Pushing blocks probably needs a more complex retry mechanism than just attempting to pull from the archive regularly
i see.. perhaps i could archive my blocks in stable storage first and worry about this later
is region still the best way to achieve this?
also should i use compacting-gc or incrementing-gc?
I usually write in Rust, so I can’t give perfect info here.
Calling region manually is quite tedious since you’ll do memory management on your own, but it works. I would go to mops.one and search for a data structure that stores data in stable memory. That will save you a lot of headaches
From what I could gather the incrementing GC is both newer, more efficient, and the default. I would suggest you stick with that