# A Scalable Database for the Storage of Object-Centric Event Logs

- Type: Journal article
- URL: https://www.gyunam.com/publication/2021-icpm-demo/
- Date: 2021-04-01
- Authors: Alessandro Berti, Anahita Farhang Ghahfarokhi, Gyunam Park, Wil M. P. van der Aalst
- Venue: CoRR
- PDF: https://www.gyunam.com/publication/2021-icpm-demo/paper.pdf
- Link (URL): https://arxiv.org/abs/2202.05639
- Research lines: [Object-centric process mining](https://www.gyunam.com/research-line/object-centric-process-mining/index.md)

## Abstract

Object-centric process mining provides a set of techniques for the analysis of event data where events are associated to several objects. To store Object-Centric Event Logs (OCELs), the JSON-OCEL and JSON-XML formats have been recently proposed. However, the proposed implementations of the OCEL are file-based. This means that the entire file needs to be parsed in order to apply process mining techniques, such as the discovery of object-centric process models. In this paper, we propose a database storage for the OCEL format using the MongoDB document database. Since documents in MongoDB are equivalent to JSON objects, the current JSON implementation of the standard could be translated straightforwardly in a series of MongoDB collections.

## Practical problem

Companies that want to analyze processes involving several interacting business objects (orders, items, invoices) store their event data in the Object-Centric Event Log (OCEL) standard, which comes as JSON or XML files. Every analysis tool has to read the entire file into memory first, so logs with millions of events exceed the memory of an ordinary workstation and cannot be analyzed at all. Graph databases have been tried as an alternative but do not map directly onto the OCEL specification, and columnar stores handle only basic column types rather than the nested JSON structures OCEL uses. Analysts therefore lack a storage back end that keeps large object-centric logs queryable without loading everything at once.

## Research questions

1. How can the JSON-OCEL format be mapped onto a document database so that object-centric event logs can be stored and queried without loading the whole log into memory?
2. How does such a database back end scale in insertion time, storage size and analysis time as logs grow to hundreds of millions of events?

## Contributions

- A MongoDB schema for the OCEL standard that translates the JSON-OCEL events, objects and global sections into document collections.
- An indexing scheme (identifier, activity and a multikey index on the object map for events; identifier and type for objects) to speed up queries.
- Database-level aggregations that compute object lifecycles, event and object statistics, and object-centric directly-follows graphs without exporting the data.
- A Python tool in the `ocel-support` repository (GitHub OCEL-standard/ocel-support) that imports and exports JSON/XML-OCEL to and from MongoDB with example scripts.
- A scalability assessment on synthetic logs from 1 million to 100 million events.

## Key findings

- On a notebook with an i7-7500U CPU and 16 GB RAM, insertion plus indexing takes 79.64 s for 1 million events and 7,983.87 s for 100 million events.
- MongoDB's binary storage roughly halves the footprint (54,642 MB of JSON become 21,304 MB of BSON at 100 million events), but the indexes add a further 16,852 MB.
- Computing the object-centric directly-follows graph takes 25.50 s at 1 million events and 3,657 s at 100 million events, with RAM capped at about 6.7 GB while disk usage grows to 36,478 MB.
- The in-memory approach ran out of memory at 6.8 million events, whereas the database handled 100 million; the trade-off is markedly slower computation, and the prototype has not been used in a real-life case study.