# Centralized vs. Decentralized: Performance Comparison between BigchainDB and Amazon QLDB
## 6 Experimental Evaluation
### Environment  
The present experiment was designed to monitor and compare the average execution times, as well as the CPU utilization and memory usages for reading and writing for both Amazon Quantum Ledger Database (QLDB) and BigchainDB technologies. The execution time is defined as the total time it takes until the dataset provided in the request is created and stored in the database, as it is for QLDB. In contrast, in BigchainDB, the execution time is computed by measuring the time necessary for the data to be stored in all MongoDB instances inside every node (this implies that the exact measurement logic is applied for the other performance indicators). A total of four nodes have been configured, as each set of two runs in a Kubernetes cluster. Grafana is the data visualization tool that has been used, and the query interaction was done via Prometheus Query Language (PromQL), a functional query language provided by Prometheus, which is a tool for data monitoring and collecting. The interaction with BigchainDB was possible due to the Python driver supported by the official documentation. In this case, a direct query interaction is not available; nonetheless, if one wishes to query documents manually, this can be done through the nodes' MongoDB instance that they have access to.  
As there are not many direct alternatives in terms of architecture, structure and functionality to BigchainDB, one of the main reasons for using QLDB as an alternative is the similarity between what a single node of BigchainDB does and the AWS candidate. The main area of interest refers to the immutability, transparency, verifiability, and persistency of data history.  
The interaction with QLDB was ensured by using the Python driver provided by the official documentation and, essentially, by executing queries in a similar manner to traditional database, using PariQL (a SQL-compatible query access solution used by Amazon in QLDB) as an interrogation language. The focus was on two significant operations: data reading and writing.  
For both approaches, two types of functions were built: one for reading and one for writing data based on what every driver has to offer, whereas every pair of parts has been used with their specific Application Programming Interface (API) endpoints based on which the requests were made.  
In order to interact with the functions required for reading and writing the data, there is a need for a software interface (API) to be set in place. For each of the two cases, there are different APIs to facilitate communication between the distinct interfaces. As far as the QLDB solution is concerned, a more modern approach was preferred, based on the use of FastAPI, which is a relatively new Python framework for building web applications. On the other hand, in terms of the BigchainDB solution, we adopted a classical approach that uses a classic Python micro-framework named Flask. Its primary benefits are its high  
Figure 5: High-level architecture of our prototype interacting with QLDB.  
flexibility and a resilient learning curve. Below, we have presented the components of the system used for this study.  
The operating system used is Ubuntu 20.04. Some OS level dependencies need to be installed first, such as the following:  
* python3.8 and python3.8-venv (virtual environment);
* pip3 (python package management tool);
* python3-dev (header files and a static library);
* libssl-dev (SSL and TLS cryptographic protocols);
* libffi-dev (Foreign Function Interface library);
* docker engine, daemon, and docker-compose.