In this article, using the Raspberry Pi 3 Model B platform as an example, we consider the problem of performance of different DBMS in the process of using them to provide a single board computer as a web server. The existing studies do not reveal the database management system (DBMS) performance problems on single board computer platforms. A comparative analysis of the performance of different operations using MariaDB relational DBMS and the same operations using MongoDB NoSQL DBMS was conducted. The data for the analysis were obtained in the process of experiment, during which the performance of such operations on databases as sampling and updating was tested. The Node.js. platform was used as a testing application. Testing was carried out on a test stand that included a single board computer Raspberry Pi 3 Model B and Windows PC. Besides the DBMS, the web server performance analysis was conducted in conjunction with the file system. As a result of the testing, the real performance degradation was found to be compliant with the expected one and some interesting performance features of different DBMS were identified. As a result of the testing the conclusions were made about the possibility of using Raspberry Pi 3 Model B platform as an authentication webserver.
At the moment, among the most important requirements for hardware and technical solutions are mobility, scalability, low operating costs and the possibility of customization. These qualities have led to the spread of single-board computers in a number of areas, including the routing of network requests, management of components of the Internet of Things, the deployment of software-controlled hardware and software solutions in the field.
The study showed that up to 85% of solutions based on single board computers tend to implement monolingual paradigm, mainly based on the programming language C. The monolingual platform is understood as the management of all or almost all aspects of the platform's operation using the same programming language. For example, a one programming language can be used to control sensors and LEDs on a computer as well as to process the data from these sensors and deliver them to the IoT client, e.g. via a web server. However, the evolution of JavaScript and the development of its ecosystem create reasons for the migration to this language as the basis of the monolingual platform. Refactoring of the existing code and practical experience allowed us to identify a number of related problems.
In the previous studies, one of the authors needed to ensure the performance of the web server when working with the database to avoid problems with data transmission to the client side and their reflection. In the course of this work relational DBMS MySQL was selected. This choice was due to the convenience of using the relational data model and the wide popularity of the database. At application deployment developed during work on final qualifying work on platform Raspberry Pi the problem of absence of the official distribution kit of server MySQL has been revealed. This fact revealed the need to replace the MySQL database with another one that supports the work on a single-board computer Raspberry Pi. DBMS such as MariaDB and MongoDB were considered as possible options. In addition to comparing the results of using the DBMS, a performance comparison was made when using JSON file stored in the file system as a database. This choice was conditioned by the necessity to check the ability of the file system or hardware data storage to avoid reducing the working speed.
MariaDB relational database surpasses MySQL performance by 3-5% due to
improved query optimizer and many other performance related improvements, as well as
complete drop-in-replacement MySQL 5.5, which is a strong argument for analyzing
the performance of this particular database on the Raspberry Pi platform [
At the same time, the article A Comparison of Database Performance of MySQL and
MariaDB with OLTP Workload v3.0. states that MySQL performance is higher than
MariaDB performance when using approximately the same amount of system resources
[
There is also a question of the rationality of MongoDB use considering the
disadvantages of this DBMS in the form of a large load on the system's RAM and the need
to independently interrupt slow queries [
Since the study considers the DBMS performance on the Raspberry Pi 3 Model B
platform, the use of the classical criterion of the number of operations for a certain
period of time, such as in the article on the creation of the LinkBench benchmark [
Despite the presence of the conducted researches on the topic of comparing the
performance of relational DBMS MySQL and NoSQL DBMS MongoDB [
The following DBMS testing platforms were selected: Windows PC and Raspberry Pi 3 Model B single board computer. These platforms are widely used in various areas of application development. While the PC has the best hardware features, Raspberry Pi 3 Model B is compact, low power consumption and low cost. The need for tests on a desktop PC was due to the possibility that a single-board computer Raspberry Pi 3 Model B might not have enough performance, so that the use of single-board computers to deploy web servers within the concept of monolingual programming using the JavaScript language would be irrational. Thus, it became necessary to determine an acceptable threshold for performance degradation. For this purpose, the hardware characteristics of desktop PC and Raspberry Pi 3 Model B were compared. SSD on Windows PC and MicroSD card on Raspberry Pi 3 Model B were used as a data storage. MicroSD card used as read-only memory in Raspberry Pi 3 Model B by default. A comparison of all components of the platforms used is shown in Table 1. As a result of the comparison, it was decided to establish an acceptable threshold performance reduction of 200%. comparison. This criterion was chosen due to the need for fast data exchange between the DBMS and the server.
The process of experimenting to determine a suitable DBMS was organized as follows. Tests were developed to determine the timing of operations. In addition, data similar to the real data had to be generated. The data could be used to fill various database management systems, in two versions. In the first case, 20,000 records were used. This number is due number is due to the one of the author's previous researches, in which a database of about 20,000 unique people was used. Thus, the choice of this number allows to estimate the DBMS indicators that can be used to assess their performance in real life tasks. The second option contained 100,000 entries. The choice of such a number of records is based on the possibility of increasing the number of records in the existing database, according to experts' estimates, up to 100,000 in 3-5 years. 2.2
To test the data access performance in relational DBMS MariaDB, the samples were made by the year of birth and by the surname. Such samples allowed to test the selection as a large set of values and a less one from the volume data array. The code fragment responsible for sampling small amount of data from relational DBMS MariaDB is shown in Figure 1. Thus, in the case of small data set sampling, their filtration is performed by name, while in the case of large data set sampling the filtration is performed by the birth year. A sample code sample that selects a large amount of data is shown in Figure 2. Also, the DBMS was tested for the data alteration speed. To perform this operation, we decided to use the method of updating the data of one column, if the data of another column correspond to the value strictly specified earlier. The code fragments responsible for this part of the testing are shown in Figure 3. The NoSQL DBMS MongoDB performance testing process is in general similar to the MariyaDB relational DBMS performance testing process, except for a few points, such as no need to format the SQL query to the DBMS and different DBMS connection implementation. Thus, unlike the MariaDB client implementation, the MongoDB client implementation, due to the fact that this DBMS supports queries to databases in JavaScript language, uses built-in functions together with the built-in MongoDB functions. The code that selects a small amount of data from the database is shown in Figure 4. It follows from the code that the selection of large and small amounts of data differ slightly both in queries to MariaDB DBMS and in queries to MongoDB DBMS. The key difference between the queries to these DBMS is the use of SQL language in the case of queries to MariaDB DBMS and the use of built-in functions in the case of queries to MongoDB DBMS. The code responsible for selecting a significant amount of data from the MongoDB is shown in Figure 5. The procedure of updating data in the MongoDB DBMS differs significantly from the procedures considered earlier. Firstly, there are several methods of data updating in MongoDB first. They are given below in Table 2.
Also, one of the operators in Update operation in MongoDB - $set - is used to perform the data update request. The full list of operators and description of their behavior is given below in Table 3. Based on the above mentioned, the code was developed to update the data in the MongoDB DBMS, which is shown below in Figure 6. As a result of the code considered earlier it was possible to accumulate a large amount of data. In total, more than 25 thousand data sampling and updating operations were performed for all operations. The results of time measurements of these operations are analyzed in the next section. 3
From the data accumulated during the experiment, a simple non-repeatable sample was built consisting of 3600 records of the time spent on data sampling and updating operations in different DBMS on different platforms and operating systems. With the help of statistical transformations, various data were obtained. Thus, for example, the data on average values of the time spent on executing different operations in different DBMS are given in Table 4.
From the diagrams shown in Fig. 7 we can see that the time spent on operations with the MongoDB DBMS deployed on a Windows PC is subject to the Laplace-Gauss distribution. And in Fig. 8 it can be seen that the time spent on the same operations with Raspberry Pi 3 Model B with the Ubuntu 18.04 operating system (Bionic) is subject to the Poisson distribution.
To test the hypothesis that the performance degradation on the Raspberry Pi 3 Model B platform running Ubuntu 18.04 (Bionic) depends not so much on optimizing various DBMS for this platform as on the platform performance itself, besides the table with the average values of the time spent on executing the data sampling and updating operations, the tables with its minimum and maximum values are given below. In Table 5 the minimum testing results is shown. The maximal testing results is shown in Table 6. In the course of the study it was revealed that the problem of monolingual programming on the Raspberry Pi 3 Model B platform using the JavaScript language, associated with the lack of an official MySQL server distribution, is solved by using an alternative database management system MariaDB. At the same time, the study showed that the use of DBMS MariaDB leads to a decrease in performance by 111-216 percent. Thus, the study found that the Raspberry Pi 3 Model B platform is not an effective choice for working with databases, due to a significant decrease in database performance. At the same time, the platform can be used effectively to deploy applications that do not require high performance data storage and processing operations. For example, Raspberry Pi 3 Model B can be used as an authorization server for web-based applications or as a distributed DBMS cluster element.
The current study has revealed a number of issues that will be the subject of the upcoming research. In the future it is possible to investigate the issue of performance of different DBMS on a cluster of some Raspberry Pi platforms, this study can determine the importance of the Raspberry Pi platform for use in the development of highload web applications.