# AMANDA: A Middleware for Automatic Migration between Different Database Paradigms
## 4 Evaluation
### Case Study with IMDB Dataset Reviews  
Since the scenario in Section 4.1 already demonstrated that the tool works with two sources RDBMS, for the case study with IMDB, the experiments considered only the scenario Postgres \(\Rightarrow\) Dgraph. Figure 11 shows the IMDB database schema.  
To carry out the migration, we transformed Figure 11 into a graph, i.e., a set of vertices and edges. Then, AMANDA queries the source database, i.e., Postgres. Figure 12 illustrates the results for a relational schema to a graph model transformation.  
Figure 8: Query output for Q1. **Left**: Source database (Postgres). **Right**: Target database (Dgraph).  
Figure 10: Query output for Q3. **Left**: Source database (Postgres). **Right**: Target database (Dgraph).  
Figure 9: Query output for Q2. **Left**: Source database (Postgres). **Right**: Target database (Dgraph).  
Figure 11: IMDB relational schema.  
Figure 12: IMDB graph schema.  
Another important metric is the time and the computational resources (e.g., memory and CPU) used by the migration process. Table 5 summarizes such metrics, indicating that the entire migration process took 7 days to complete for Postgres. The amount of RAM used was 19.47 MB, and the CPU time was 26.25 min for migration from Postgres to Dgraph. The tools used to measure the performance was _pyinstrument_ ([[https://pynstrument.readthedocs.io/en/latest/home.html](https://pynstrument.readthedocs.io/en/latest/home.html)]([https://pynstrument.readthedocs.io/en/latest/home.html](https://pynstrument.readthedocs.io/en/latest/home.html)), accessed on 9 May 2022) for execution time, _resource_ ([[https://docs.python.org/3/library/resource.html](https://docs.python.org/3/library/resource.html)]([https://docs.python.org/3/library/resource.html](https://docs.python.org/3/library/resource.html)), accessed on 9 May 2022) for CPU usage and _guppy_ ([[https://pypi.org/project/guppy3/](https://pypi.org/project/guppy3/)]([https://pypi.org/project/guppy3/](https://pypi.org/project/guppy3/)), accessed on 9 May 2022) for memory consumption.  
Apart from the migration performance, we also evaluated query performance between databases through the six queries below:  
1. [label=**(Q1)**]
2. What are the actors/actresses of movie \"Carmencita\"?
3. What are the movies of genre \"Action\" and ended in 1960 or earlier?
4. Which movies is [PERSON] known for?
5. How many episodes has \"The Bold and the Beautiful\"?
6. What are the other names of \"The Unchanging Sea\"?
7. What title are \"tvMiniSeries\" and have the average rating 10?  
Figure 13 illustrates a query performance comparison between databases. For queries Q3, Q4, and Q5, it is worth pointing out that Dgraph outperforms RDBMS. It is reasonable to say that this happens since the relationships in a graph database are stored in its database. In contrast, for RDBMS, the relationships are always determined in the course of a query run time, with the aid of several performances degrading _joint_ operations.  
Postgres has shown the best performance when running queries Q1, Q2, and Q6, which is likely a consequence of, in this case, the Dgraph's query structure, in which, it was necessary to filter values twice. This double filtering was not necessary in Postgres. Furthermore, in Dgraph, for queries Q1, Q2 and Q6, it was needed to enforce the filter in order to only return nodes with the desired relationship. This type of operation degrades the database performance. An example of Q6 is shown below in Figure 14.