On a Sonatype Nexus repository server which uses an OrientDB instance as a database backend, we observe the database steadily growing despite the repository contents getting regularly deleted.
We'd expect the database size to (at least occasionally) shrink and to overall stay at roughly the same size.
How does OrientDB handle deletions? Is there a way to check if the database holds outdated information, and is it necessary / possible to regularly "purge" or "compact" an OrientDB?
It turns out that indeed, OrientDB databases seem to benefit from periodic compaction actions, in this case, an export and re-import.
The official documentation on the disk storage engine of OrientDB states (emphasis mine):
When you delete a record, the page index and record position are set to -1. So the record pointer is transformed into a "tombstone". You can think of a record id like a uuid.. It is unique and never reused.
Usually when you delete records you lose very small amount of disk space. This can be mitigated with a periodic "offline compaction", by performing a database export/import. During this process, cluster positions will be changed (tombstones will be ignored during export) and the lost space will be recovered.
As suggested by this SO q&a, other users observe a monotonic growth of the database despite big deletions going on -- this mechanism might explain this observation.
Nexus has an Audit feature that logs all scheduler activities. My orientdb database of audit had a file audit_data.pcl that is taking 18GB in size.
Just copied it to my computer and truncated it with orientdb 3.2.20. Now I will do an export/import to compact the file and copy it back to the server.
UPDATE: Nexus 3.57.0-01 seems to function ok. The audit database size of orientdb is after export/import 27MB.
