# Performance Evaluation of NoSQL Document Databases: Couchbase, CouchDB, and MongoDB
## 5 Experimental Results
### MongoDB  
Table 6 presents the MongoDB runtime for all workloads with all the records used and with three threads. Due to the lack of space, the runtime results with one and six threads are available at: [[https://github.com/isofiaC/Performance-Evaluation-of-NoSQL-Document-Databases](https://github.com/isofiaC/Performance-Evaluation-of-NoSQL-Document-Databases)]([https://github.com/isofiaC/Performance-Evaluation-of-NoSQL-Document-Databases](https://github.com/isofiaC/Performance-Evaluation-of-NoSQL-Document-Databases)) (accessed on 5 January 2023). In MongoDB, workload E has the worst runtime result, considering all the records used. This workload is mainly composed of scan operations, and since MongoDB performs many disk accesses, this causes an increase in runtime. On the other hand, with 100,000 records, workload C has the best runtime because this workload is composed only of read operations. However, with 1,000,000 records, and \begin{table}
\begin{tabular}{c c c c} \hline \hline
**MongoDB** & **100,000 Records** & **1,000,000 Records** & **10,000,000 Records** \\ \hline Workload A & 10.65 s & 297.41 s & 4950.83 s \\ Workload B & 7.15 s & 122.37 s & 2564.01 s \\ Workload C & 6.61 s & 111.58 s & 2305.59 s \\ Workload D & 7.31 s & 81.03 s & 1427.47 s \\ Workload E & 78.82 s & 4491.09 s & 126,310.74 s \\ Workload F & 13.52 s & 296.36 s & 4756.72 s \\ Workload G & 12.22 s & 541.20 s & 6765.96 s \\ Workload H & 12.22 s & 463.96 s & 7034.36 s \\ \hline \multirow{2}{*}{Total} & 137.85 s & 6107.59 s & 151,164.85 s \\  & (2.30 min) & (101.79 min) & (2519.41 min) \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Runtime of MongoDB with 3 threads. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**CouchDB** & **100,000 Records** & **1,000,000 Records** & **10,000,000 Records** \\ \hline
1 Thread & 742.38 s & 12,233.93 s & 222,046.97 s \\
3 Threads & 314.27 s & 7097.16 s & 132,570.91 s \\
6 Threads & 243.09 s & 3937.96 s & 66,041.70 s \\ \hline \multirow{2}{*}{Total} & 1299.74 s & 23,269.05 s & 420,659.55 s \\  & (20.50 min) & (387.82 min) & (7010.99 min) \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Runtime of CouchDB. 10,000,000 records, workload D had the best runtime results. This workload is composed of 95% read operations, and just 5% insert operations. The workloads B, C, and D are mainly composed of read operations, which are faster than the other operations. This makes workloads B, C, and D show better runtime, even varying the number of records. Table 7 shows the runtime results for all the workloads used in MongoDB. From these results, it was possible to conclude that:  
* Considering 100,000 records, we verify that the runtime decreases more than halved when increasing from one to three threads. The same does not happen when increasing from three to six threads, as it drops only 20% of the runtime, representing poor scaling-up. This 20% can also be explained by the fact that the computer used only supports six threads and uses them for other processes that run simultaneously;
* Considering 1,000,000 records, we verify that the runtime was reduced by 50% when it switches from one to three threads. When it was changed from three to six threads, the decrease in runtime was even worse, decreasing by only 10%. This can happen because there is much processing, thus using the disk more frequently, which slows down the runtime;
* Considering 10,000,000 records, we verify that, once again, its performance has worsened. This is because it has more data to process and consumes more computer resources. When increasing from one to three threads, the runtime only decreases by 30%. It is worse when it goes from three to six threads, in which it only decreases by 10%. These results show that MongoDB scales up poorly when using more threads;
* When moving from 100,000 records to 1,000,000 records, the runtime was expected to increase by 10 times; however, there was a 37.4 times increase. This increment is much higher than Couchbase and CouchDB, with an increase of 18.3 times and 17.9 times, respectively.