As we are moving towards mega store, which can house 10s of millions(even 100s) of ledgers, and 1000s of bookies, there can be a huge overhead on some of the operations we are performing right now.
1. Compaction/GC A deletion is just a metadata operation. Deletes the zk node. (currently it just deletes the leaf node, which can be a minor bugfix to delete entire tree if applicable). But each bookie need to get a list of existing ledgers from bookie, compare to its local storage, and identify deleted ledgers. Then go through compaction logic which is another process. But 1000s of bookies, in parallel parsing the entire zk tree, making their own list doesn't appear to be efficient scalable architecture to me. Why not introduce a opportunistic delete operation from client side, which will inform to all bookies in that ledger's metadata. We can still keep our bruit-force method but at very very low frequency, once a week? to address transient/corner case scenarios like bookie down at that time etc. Is there any big architectural correctness issue I am missing in this method? 2. Close Ledger close is also a metadata operation. I believe sending opportunistic close to bookies of the current ensemble can greatly enhance some of the use-cases where we need open-to-close consistency. Where in the data doesn't need to be persistent until the close. Any thoughts?? -- Jvrao --- First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi
