4 ms·
You're not misremembering. It's just that timing matters. And GC always got less attention than compactions. My rule of thumb was: if I have a change that will
by puzzle 8y ago
You're not misremembering. It's just that timing matters. And GC always got less attention than compactions.
My rule of thumb was: if I have a change that will shrink tablets by 10% through e.g. compression and I apply it wholesale with a manual compaction of the entire table, I should assume that in the worst case the table will temporarily take up 190% of current space, until the next GC run or two. If all or most of your data is in one table, this can be a problem. Organic compactions are friendlier because they occur over the course of (typically) days, leaving the GC with plenty of time to clean up.
- londons_explore 8y agoThe real issue is that Bigtable's used to be in one big shared cell which could handle temporary 190% increases in resources. Now, to increase isolation between services, everyone is off in a partition, and each individual partition is much smaller and therefore can't withstand resource spikes without falling over. And I bet the "emergency loan" functionality for various resources still isn't automated and still has arcane requirements to meet and a delay before it kicks in. Yay - a 15 minute delay. Thats exactly what I need when my entire service is down! /s