A Study of Performance and Comparison of NoSQL Databases: MongoDB, Cassandra, and Redis Using YCSB

Abstract

Background/Objectives: Relational databases are a commonly utilized technology that allows for the storage, administration, and retrieval of various data schemas. However, for certain big databases, executing queries can become a time-consuming and inefficient procedure. Furthermore, storing enormous volumes of data necessitates servers with greater capacity and scalability. Relational databases have limits when it comes to dealing with scalability for big amounts of data. On the other hand, non-relational database systems, often known as NoSQL, were created to better fulfill the demands of key-value storing of enormous volumes of records. However, there are several NoSQL options, and the majority have not yet been extensively compared. The goal of this research is to examine different NoSQL databases and evaluate their performance in terms of typical data storage and retrieval. Methods: In this study, we use the YCSB tool to measure the performance of three NoSQL databases: MongoDB, Cassandra, and Redis. We test six different workloads with 100000, 250000, 500000, 750000, and 1000000 operations. Our test was designed with five different operations, i.e., 100000, 250000, 500000, 750000, and 1000000, with six different workloads to see which database is most suitable for applications which use a large amount of data to process. Findings: MongoDB is a superior performing NoSQL database among Cassandra and Redis. The numerous optimizations used by the designers of NoSQL solutions to improve performance, such as good cache memory operation, have a direct impact on the execution time. In all workloads except workload D, MongoDB has significantly reduced latency across all operation counts. Novelty: We also measure the average latency of different workload scenarios that include a mix of read, write, and update activities.

Construction of a rural tourism information service management system for multi-source heterogeneous data processing

“…When the chunk exceeds the set size, the background will automatically segment the piece to avoid the system crash caused by a too-large piece. Figure 2 shows the structure of sharding clusters ( Abu Kausar, Nasar & Soosaimanickam, 2022 ).…”