I have a database called 'decision' on Google Cloud Spanner.
I have exported this 'decision' database to a Google Cloud Storage bucket.
I have then imported the exported database to a new Spanner database called 'decision_backup'.
I have also imported the previously exported 'decision' database back into the original 'decision' database, it has simply overwritten the data.
I performed row counts and table counts to check for data loss, the row counts and table counts matched as expected, suggesting no data loss has occured.
However, I noticed that the sizes of the databases differed even though they are from the same snapshot time.
The 'decision' database was 1.74TB and the 'decision_backup' database was 177GB last week.
Over the course of the week the 'decision' database has reduced in size incrementally and is now 184GB.
The 'decision_backup' database has also reduced, though not as drastically, to a size of 122GB.
If the data within the databases is the same or identical, what is the reason this significant size difference? And what is the reason for the incremental reduction in both database sizes?
Cloud Spanner is MVCC database. Past values for a key are still accessible within a certain window of time.
I have then imported the exported database to a new Spanner database called 'decision_backup'.
The exported data does not store past values so the size you saw should be close to the actual size of the data. During the restore, it is possible that Cloud Spanner performs load-based or size-based splitting and moving the splits around, which could incur some temporary overhead due to data may exist in both src/dst. The cleanup is not immediate, and it spreads across the whole database both in time and space (i.e. each split has its own schedule).
I have also imported the previously exported 'decision' database back into the original 'decision' database, it has simply overwritten the data.
Since you are overwriting the data, past values are still kept (by default the time window is 1 hour. Theoretically the size could be twice the actual size (with each key storing both the old and new values). But if your database have a longer retention period, or have more frequent updates, the size could be even bigger.
The same load-based/size-based splitting could also happen. And the "overhead" could be even more because there is just more data to be moved when splitting happens.
Eventually if nothing new was written to both databases, their size should converge.