We can check the snapshot of the partition size after RDP into the node. Below is an example of one the Partition folder (E.g.: a16a1c07-1468-4664-bf4f-483436dcbda0) size before Calling DeleteActorMethod:
After Calling DeleteActorMethod: Disk space remains same:
Points to Note:
Actual usage on disk depends on numerous factors from the underlying store and we don’t see immediate reduction of disk usage right after Actor deletion.
Deleting data does not shrink the physical size of the DB down; it only shrinks the logical size (the size of the data) of the DB. However, the remaining space is reused when more data is added.
For example, imagine the execution of the following operations:
Inserting 10GB of data.
Deleting 7GB of data.
Inserting 3GB of data.
The physical size of the DB remains to be 10GB after the occurrence of all the above operations. This is because of physical size not going down after the data is deleted as stated above. However, during step 3, the existing available space is reused instead of creating additional physical space.
If we are interested in bringing the physical size of the db down, we can perform compaction. Shrinking of db file size is not supported proactively as it impacts write latency.
The recommended way is to test on workloads with real data which is having huge size. Disk space is rarely a bottleneck is general workloads.
For compacting the partitions, we have added settings under LocalEseStoreSettings: