# Evaluating NoSQL Databases for OLAP Workloads: A Benchmarking Study of
MongoDB, Redis, Kudu and ArangoDB

Rishi Kesav Mohan<EMAIL_ADDRESS>,  Risheek Rakshit Sukumar Kanmani
<EMAIL_ADDRESS>,  Krishna Anandan Ganesan<EMAIL_ADDRESS>and  Nisha
Ramasubramanian<EMAIL_ADDRESS>
###### Abstract.

In the era of big data, conventional RDBMS models have become impractical for
handling colossal workloads. Consequently, NoSQL databases have emerged as the
preferred storage solutions for executing processing-intensive Online
Analytical Processing (OLAP) tasks. Within the realm of NoSQL databases,
various classifications exist based on their data storage mechanisms, making
it challenging to select the most suitable one for a given OLAP workload.
While each NoSQL database boasts distinct advantages, inherent scalability,
adaptability to diverse data formats, and high data availability are
universally recognized benefits crucial for managing OLAP workloads
effectively. Existing research predominantly evaluates individual databases
within custom data pipeline setups, lacking a standardized approach for
comparative analysis across different databases to identify the optimal data
pipeline for OLAP workloads. In this paper, we present our experimental
insights into how various NoSQL databases handle OLAP workloads within a
standardized data processing pipeline. Our experimental pipeline comprises
Apache Spark for large-scale transformations, data cleansing, and schema
normalization, diverse NoSQL databases as data stores, and a Business
Intelligence tool for data analysis and visualization.

The wide-ranging classifications of NoSQL databases include document-oriented,
key-value stores, columnar databases, and graph databases. For our
experiments, we selected MongoDB, Redis, Apache Kudu, and ArangoDB, each
representing a distinct family of NoSQL databases. Leveraging a standardized
pipeline, we assessed the performance of these databases using Koalabench, a
popular NoSQL benchmarking dataset collection. Each pipeline we setup has a
unique NoSQL database and the performance of each pipeline has been evaluated
for data loading time and query execution time. We have also compared the
performance of a standard SQL solution (PostgreSQL) against the different
NoSQL alternatives. Koalabench generated datasets of varying sizes in our
desired data model and we conducted a series of experiments using data
belonging to two different data models - flat and snow. The insights gleaned
from these experiments will facilitate the establishment of an optimal OLAP
data pipeline, pairing the ideal NoSQL database as the data warehousing
solution.

##  1\. Introduction

Modern day data engineering has seen numerous enhancements. Every last ounce
of data is being considered as a feature. With data having immense
significance in the modern world, the way in which we handle and process data
should also evolve with requirements and time. To develop a holistic data
engineering pipeline, there are three crucial components:

  * •

Data Loading and Processing

  * •

Data Store

  * •

Data Analysis

###  1.1. Data Loading and Processing

Data loading and processing consists of the seamless ingestion,
transformation, and preparation of data sourced from various accessible
outlets. Given the enormous volume of data to be managed, it requires
underlying systems with enhanced processing capabilities to facilitate
efficient handling. Apache’s Hadoop Distributed File System (HDFS) (Apache,
2006) emerges as one of the prominent solutions built for large-scale data
storage. HDFS offers high-throughput access to application data and is ideal
for batch processing operations.

With HDFS taking care of large storage, we would have to implement a solution
to handle data processing.Data processing is a key aspect of any data pipeline
and it governs the process of converting the raw data into a database
compatible format before loading it into the database. Apache Spark (Apache,
2014) stands out as a prime choice for swift and efficient data processing.
Its seamless integration with HDFS enables the seamless transfer of data from
HDFS to Spark for processing or streaming to subsequent components within the
pipeline. Employing these two tools in tandem establishes an optimal platform
for transforming data, rendering it ready for import into the designated data
store.

###  1.2. Data Store

Once the voluminous data has been stored and processed, we would require a
solution for storing the processed data. Ideally, this component would be a
database, which helps in storing data in a structured format and it can be
accessed using query languages specific to the chosen database. The
traditional relational database management system (RDBMS) (M., [n.d.]) can
store structured data effectively based on a predefined schema. RDBMS also
requires complex query operations such as joins in the event of requiring data
from more than one table and these complex query operations are generally
resource intensive.

With the rise of semi-structured data, there is scope for exploring the
possibility of OLAP workloads. NoSQL databases have been adept at leveraging
semi-structured data formats such as CSV and JSON which has allowed for the
incorporation of a flexible data schema, ease of scalability and support for
heterogenous datatypes. NoSQL databases promote flexibility in schema and
their data storage mechanism allows for easy access of different data features
without the need for executing complex joins to derive insights.

Despite the benefits of NoSQL over SQL, prevailing architectures have
predominantly relied on SQL databases as their primary data store. There
exists a significant disparity in evaluating the performance of NoSQL
databases within an OLAP-intensive pipeline.

##  2\. Related Work

The literature survey undertaken centered on evaluating prior research within
the realms of data processing and databases. These domains were identified as
primary areas of interest for assessing the overarching structure of our
envisioned pipeline.

###  2.1. HDFS and Spark for OLAP

On the the topic of data processing, we looked far and wide to understand the
depth of research that had been performed in order to gauge the progress from
the perspective of data engineering pipelines. One of the key ideas, HDFS
(Shvachko et al., 2010) has paved the way for storing large datasets and also
provides an invaluable framework for carrying out analysis and transformation
operations on the large data using the MapReduce (Dean and Ghemawat, 2004)
algorithm. HDFS has paved the way for several database and data streaming
solutions to be built on top it. One such data streaming service that has
become widely popular is Apache Spark (Zaharia, 2016). Apache Spark helps in
the streaming and processing of voluminous data from HDFS. HDFS and Spark in
tandem can handle the load of data processing on any industry-level data
engineering pipeline.

Research done based on leveraging HDFS and Spark for OLAP workloads is rather
insignificant in the context of NoSQL databases. The standalone research of
OLAP pipelines was limited in the previous years, however certain hybrid ideas
were proposed. One such idea called Hybrid Transaction/Analytical Processing
(HTAP) (Özcan et al., 2017) proposed for a unified storage for both OLTP and
OLAP workloads. While this may seem feasible considering the flexibility of
use that systems like HDFS and Spark provide in connecting with different
database solutions, this idea does not account for the data rigidity that
exists in transactional and analytical processing. RDBMS solutions require a
rigid schema and lack support for heterogeneous datatypes whereas NoSQL
addresses both concerns. Hence, having a common store and unifying OLTP and
OLAP is a little far-fetched for now.

Wildfire by IBM (Barber, 2017) leveraged a HTAP like solution using HDFS and
Spark to perform data analysis and was one of the first solutions to implement
a data processing component in their pipeline. This work had stressed on the
importance of having distributed data store and distributed data processing to
make OLAP more effective. However, Wildfire was based on Spark SQL which is
more similar to RDBMS. Stream processing (Shaikh and Kitagawa, 2020) became a
popular research interest post HDFS and Spark as many ideas revolved around
bringing together Spark and OLAP through the metaphorical ’cube’. This process
involved transforming raw data using Spark into an OLAP friendly format via a
process called cubification. The resultant OLAP cube, contained the features
extracted from the provided data, in the form of a cube on top of which data
analysis could be performed to gather insights. When distributed processing is
employed, the use of OLAP cubes becomes restricted to gathering insights from
the processed data and does not aid in determining a scalable strategy for
processed data ingestion into the database.

###  2.2. Benchmarking for NoSQL-OLAP

The second broad topic we researched on is the availability of literature for
NoSQL databases being used in OLAP/OLTP workloads. This exploration was an
effort to understand whether there was a possibility to use NoSQL databases
for OLAP. Based on the NoSQL OLAP literature we identified, we also looked for
previous benchmarking experiments performed for NoSQL OLAP works. One of the
premier works in the NoSQL-OLAP domain involved the creation of OLAP cubes
using distributed processing without the need of RDBMS (Dehdouh, 2016). Using
the MC-Cube operator developed in this paper, the idea is to perform
transformations on the data stored in columnar NoSQL databases and the data
features get bundled into ”cubes” which can then be used for analytical
insights. This idea came up short because of the use of just a columnar NoSQL
database as other NoSQL databases were not tested in their experiments.
Another idea on the contrary (Davardoost et al., 2020) used a document-
oriented NoSQL database as the data store solution but employed a series of
techniques such as shingling, chunck, minhashing, and locality-sensitive
hashing MapReduce. These techniques do serve the purpose of extracting
features from the available data but fall short when the data scales.

Whilst the initial literature stresses more on the usage of NoSQL databases
for OLAP workloads, there has been some research done on benchmarking NoSQL
databases purely from a query processing perspective for OLAP. The current
evaluations of NoSQL databases have primarily focused on simplistic metrics,
such as the loading time when used as a data warehouse. However, these
comparisons fail to capture the nuanced performance differences within a
processing pipeline. Extensive research (Chevalier et al., 2015a, b) has
delved into NoSQL benchmarks, yet these studies often prove inadequate for
comprehensive NoSQL database comparisons in a processing context. They
emphasize the stark disparities between new benchmarks and traditional
Relational benchmarks, illustrating the superiority of the former. For
instance, Chevalier et al.’s (Chevalier et al., 2015a) introduction of
KoalaBench — a versatile benchmarking tool—enables the analysis of both
relational and NoSQL databases, thereby addressing this gap. Numerous studies
explore different aspects of NoSQL databases or compare various NoSQL
solutions. For instance, (Dominguez-Sal et al., 2010) highlights the
significance of Graph Databases in data analysis, while (Chevalier et al.,
2015b) provides a comparative analysis of three popular NoSQL databases in the
context of Big Data and Cloud Computing. Moreover, (Dehdouh et al., 2014)
details the evaluation of Columnar stores, particularly focusing on HBase and
utilizing the Star schema as a metric. Additionally, (Dominguez-Sal et al.,
2010) conducts a comparative study between HBase and MongoDB using a star
schema setup, further enriching our understanding of these database systems.

##  3\. The Generic Pipeline

The generic pipeline that we envisioned consists of three broad components -
data processing, the data store and the data analytics solution. By feeding
data to the data processor, we transform the data into a usable format for the
data store. All the pipelines we have created uses a different type of NoSQL
database as its data store. Finally, all the pipelines culminate with a data
analytics solution that reads off the processed data stored in the database to
create analytical insights. The pipeline can be further explained in the
following sections:

###  3.1. Data Processing

The data processor section consists of two major components - Apache HDFS and
Apache Spark. All the data files required for the pipeline are first loaded on
to HDFS. Thanks to the distributed storage and distributed processing
capabilities of using HDFS and Spark in tandem, we were able to load data from
HDFS and utilize PySpark to load the transformed data into the database.

The raw data we load into HDFS is provided to us by Koalabench (El Malki,
2022). Koalabench can be broadly defined as a decision support benchmark for
Big Data requirements. It is derived from the TPC-H benchmark, the reference
benchmark in research and industry for decision support systems. It has been
adapted to support Big Data technologies such as NoSQL databases and HDFS. It
can generate data in different data formats and in different data models.
There are four primary data logical models supported by Koalabench, out of
which the two data models that we have used are the following :

Figure 1. Schema of the dataset based off the Snow Logical Data Model
generated by Koalabench

####  3.1.1. Snowflake Data Model

This data model is very close to the one used in the TPC- H benchmark with
small modifications.In a classic snowflake data model, there are three major
components. Fact Tables are the prominent tables based on which most of the
data querying is performed - ideally they are the centre of attraction in a
snowflake data model. Component Tables are supporting tables to the fact table
in the sense that they contain most of the required data attributes to know
more about the fact table records. Relationship tables are used when multiple
component tables need to be linked to create a compound component table that
aids in providing more information about the fact table records.

As per Figure 1, the element in green, Lineitem would be the only fact table
for our data model. All tables except PartSupplier will be component tables
which aid in providing attributes to Lineitem via simple relationships.
PartSupplier is a relationship table composed of attributes from Part and
Supplier component tables.

####  3.1.2. Flat Data Model

This is the simplest data model of all the supported ones. As per Figure 2,
Lineitem carries over as the premier entity based on which all the data
features are developed on. In the flat data model, the significant data
parameters from component tables is included within the Lineitem fact table.
All relationship tables removed as the flat data model promotes a simpler way
of storing data without the need for establishing complex relationships.

Figure 2. Schema of the dataset based off the Flat Logical Data Model
generated by Koalabench

The common file format used by all the pipelines for their raw data is CSV and
we have utilized the datasets generated using the flat logical data model for
the NoSQL databases and the dataset based on the Snowflake logical data model
has been used in the PostgreSQL pipeline. This helps us evaluate the
performance of the databases with the way in which they handle scalable data
upon data ingestion.

The data from HDFS is pushed to Spark for performing data transformations. As
our test environment had limited hardware resources to play with, we resorted
to utilizing the num_partitions feature of Spark. In Apache Spark,
num_partitions refers to the parameter used to specify the number of
partitions to divide an Resilient Distributed Dataset (RDD) or dataframe into
during processing. Properly setting num_partitions can optimize performance by
balancing data distribution across the available computing resources. It is
essential to choose an appropriate value for num_partitions to ensure
efficient parallel processing and avoid resource contention in Spark
applications.

###  3.2. Data Store

Once the processsed data is ready from Spark, we begin the process of
inserting the records into the data store component. For simplicity, we have
taken up different NoSQL databases to act as the data store for the processed
data from Spark. Spark supports interactions with multiple popular SQL and
NoSQL databases which has allowed us to use four different NoSQL databases
based on the four broad classifications of NoSQL databases. They are as
follows:

####  3.2.1. MongoDB

MongoDB (Eliot Horowitz, 2009) is a popular NoSQL database known for its
flexible document-oriented data model, which stores data in BSON (Binary JSON)
format. It offers scalability and high performance, with features like
sharding and replication for handling large-scale deployments. MongoDB’s
expressive query language and rich ecosystem of tools make it well-suited for
a wide range of applications, from web development to analytics.

####  3.2.2. ArangoDB

ArangoDB (Weinberger and Celle, 2015) is a multi-model database system
supporting document, key/value, and graph data models in a single database
core. It offers a versatile query language, AQL (ArangoDB Query Language), and
boasts features like distributed graph processing and geo-spatial indexing.
With its flexible data model and powerful querying capabilities, ArangoDB is
suitable for diverse use cases including social networks, recommendation
engines, and real-time analytics. For the purposes of our experiments, we have
leveraged the graph data models of ArangoDB owing to the Graph databases
family of NoSQL solutions.

####  3.2.3. Apache Kudu

Apache Kudu (Apache, 2022) is an open-source columnar storage engine designed
for fast analytics on rapidly changing data. It combines the performance of
traditional columnar databases with the ease of use of Hadoop. With features
like automatic partitioning and fault tolerance, Apache Kudu is ideal for
real-time data ingestion and interactive analytics applications.

####  3.2.4. Redis

Redis (Sanfilippo, 2009) is an in-memory data store known for its high
performance and versatility in caching, session management, and real-time
analytics. It supports various data structures like strings, hashes, lists,
sets, and sorted sets, making it suitable for a wide range of use cases.

Apart from the mentioned NoSQL databases, we have performed one additional
experiment using PostgreSQL (Stonebreaker, 1996) as the RDBMS solution for the
data store. This experiment has helped us compare and contrast the performance
of SQL and NoSQL databases in the generic pipeline. The processed data has
been saved on the respective databases thanks to the versatility provided by
PySpark in developing seamless interaction modules between Spark and the
databases.

Once the data has been loaded, we have executed a subset of the queries
belonging to the TPC-H benchmark. As Koalabench derives its existence from
TPC-H, it has allowed us to reuse the same template of the documented
benchmark queries. However, based on how the data is stored in the different
databases, we have come up with equivalent queries for each of the NoSQL
databases and executed them on the databases respectively.

##  4\. Architecture

For the evaluation of each proposed data pipeline as part of our benchmarking
process, we plan to execute datasets of varying scale factors generated from
the Koalabench suite. These datasets will be run through each pipeline within
our standardized local testing environment, which consists of a system running
MacOS Sonoma 14.4.1, powered by an Apple M2 chip with 8GB of RAM and 128GB of
storage. To support distributed data processing capabilities for Hadoop and
Spark, we intend to create a dockerized environment within the local system.
This environment will comprise a master-worker setup facilitating the
execution of distributed tasks.

Figure 3. Dockerized experimental setup consisting of one master and three
worker nodes

The architecture shown in Figure 3 consists of one master node concurrently
acting as a worker, along with three dedicated worker nodes. The master node
maintains bidirectional communication routes with each worker node, enabling
seamless coordination for distributed processing across HDFS and Spark
clusters. The dockerized environment is built on Debian Linux v11 across all
nodes. To facilitate distributed data processing capabilities, each node is
equipped with Hadoop-3.3.6 and Spark-3.4.1.

We have incorporated the latest docker images for all the databases under
evaluation, including Postgres-alpine-3.19, MongoDB-7.0.8, ArangoDB-3.12.0,
Redis-7.2.4, and Apache Kudu-1.17. These database images have been
instantiated within the same docker network as the experiment nodes, enabling
efficient measurement of time-based metrics without introducing potential
biases stemming from network latency. The data analysis component of our
pipeline will leverage a Business Intelligence (BI) tool connected to the
respective database docker image for accessing and analyzing stored data. The
tentative BI tools identified for this purpose are Metabase v0.49.3 and
Tableau 2024.1. The BI container will reside within the same docker network as
the experimental setup to ensure seamless integration and communication.

##  5\. Experiments

The following section elaborates on the dataset that we have used to evaluate
the performance of the various pipelines and documents the findings from the
individual experiments we have carried out in each data pipeline we developed.

###  5.1. Dataset

To evaluate our pipelines across varying data scales, we have used different
datasets generated from Koalabench using the flat data model based on varying
scale factor(sf). The primary objective of utilizing different sf values is to
maximize the dataset size, enabling comprehensive testing of our pipelines’
performance and scalability across a broad range of data volumes. We have
conducted experiments on all the pipelines using sf1, sf2, sf3, sf4 and sf5
datasets with the data format set as CSV for all datasets. The minimum size of
the collection belongs to the sf1 dataset at 2.38 GB and the maximum size of
the collections belongs to sf5 which scales up to approximately 11GB. For the
PostgreSQL pipeline, we have leveraged the snow data model to generate
datasets ranging from sf1 to sf5 in the CSV format. The least size is with sf1
at 1.4GB and the maximum size is with sf5 at approximately 6GB.

###  5.2. Data Loading Time

Table 1 portrays the load times for different datasets across the five
different databases.

Table 1. Data Loading times for all databases across the five datasets (time in seconds) Databases | SF1 | SF2 | SF3 | SF4 | SF5
---|---|---|---|---|---
PostgreSQL | 37s | 375s | 857s | 1089s | 1481s
MongoDB | 90s | 1250s | 1701s | 2275s | 2810s
ArangoDB | 295s | 2249s | 3964s | 12169s | 15162s
Redis | 1495s | 3245s | 5023s | 7748s | 10289s
Apache Kudu | 42s | 95s | 146s | 192s | 240s

Apache Kudu has shown the smallest load times across all five datasets. One of
the primary reasons for this observation is the columnar-storage mechanism
that Apache Kudu employs coupled with its superior in-memory management that
flushes out records as and when the threshold is reached. This allows Kudu to
handle scaling data efficiently and keep the overall loading time to agreeable
levels.

MongoDB seems to have progressively higher data ingestion times. MongoDB’s
document-oriented storage model and lack of native sharding capabilities may
lead to increased data ingestion times due to increased indexing and write
operations overhead. Additionally, as the dataset size grows, MongoDB’s
reliance on memory-mapped files for storage may result in slower write
performance and increased disk I/O operations.

Redis displays the poorest performance on all 5 datasets. The very high data
loading times observed in Redis can be attributed primarily to the schema we
used for the processed data. In order to keep the schema uniform across all
NoSQL databases, we opted for having the linenumber_id as the only key and all
the remaining data features were aggregated into a single list and attributed
to the corresponding linenumber_id. In general, we ended up creating a record
that had a single key and 40 values. Additionally, redis being a single
threaded solution meant that for every insertion operation had two call
operations to make. With data scaling, this would increase exponentially and
in the end be double of what an ideal PostgreSQL implementation would execute.

ArangoDB was implemented using its document model and its data insertion times
are exorbitant owing to the document model that was implemented. ArangoDB is
definitely not an ideal solution should the data scale as for sf5, the data
insertion time is almost 50x what it was for sf1.

PostgreSQL shows a gradual increase in data insertion times from sf1 all the
way upto sf5. It is able to handle scaling data much more efficiently has
compared to some of its NoSQL counterparts.

Based on this experiment, it is clear that with a NoSQL database as your data
store, it is preferrable to choose a columnar storage solution in case the
pipeline has to be robust enough to handle scaling data.

###  5.3. Query Processing Time

As Koalabench is based off the TPC-H benchmark, we selected five out of the
seventeen benchmark queries that TPC-H has to offer. The TPC-H benchmark is
meant for running benchmark experiments on RDBMS solutions. Hence, the queries
can be directly applied to the PostgreSQL data pipeline as the schema is same
as the one proposed by TPC-H. For all NoSQL data pipelines that leverage the
flat data model, we prepared queries in the native querying language of the
NoSQL database present in the pipeline.

The five queries we selected were different from one another based on the
significant operation that was being performed by the query. For context,
Query 1 was aggregation intensive in which almost eight out of the ten values
that were being fetched were based off aggregation. Query 2 had a good balance
of aggregation and join operations. Query 3 had an aggregation along with a
sub-query based filter. Query 4 had five join operations and Query 5 was the
simplest query off them all with just a single aggregation operation.

Figure 4. Query Execution time (in seconds) for PostgreSQL across the five
datasets

####  5.3.1. PostgreSQL

Figure 4 shows a graph depicting the query execution times for the PostgreSQL
data pipeline. Across the five datasets and for the five queries, we see a
steady increase by a factor of 2x for almost all queries except Queries 3 and
4. The reason for the observation of exponential rise in query execution times
for those two queries alone is because of the inherently costly join
operations of RDBMS solutions which tend to compare every row of the two
tables. For filtering and aggregation queries, the increase in query execution
time is 0.33x for every 2x scale in data which is pretty commendable.

####  5.3.2. MongoDB

Figure 5. Query Execution time (in seconds) for MongoDB across the five
datasets

Figure 5 shows a graph displaying the query execution times for the MongoDB
pipeline for the five selected benchmark queries across the five datasets.
MongoDB uses the translated version of the benchmark queries and the major
change between the original and translated versions are that all join related
operations become filter related operations. This is because of the non-
availability of support for joins in NoSQL databases.

MongoDB handles most of the queries easily with scaling data with a maximum
increase in execution times by about 0.8x for every 2x increase in data. This
can be attributed to MongoDB’s inbuilt sharding capabilities, that promote
horizontal scaling approach that allows it to handle larger data sets and
provide high throughput operations by distributing data across multiple
shards. One aspect where MongoDB struggles is with intense aggregation queries
such as Query 1. With data scaling, MongoDB is forced to look up multiple
document objects and perform compute operations on them which are CPU
intensive and tend to consume more time than rest of the query operations.

Figure 6. Query Execution time (in seconds) for ArangoDB across the five
datasets

####  5.3.3. ArangoDB

Figure 6 shows a graph displaying the query execution times for the ArangoDB
pipeline for the five selected benchmark queries across the five datasets.
ArangoDB uses the Arango Query Language (AQL) version of the benchmark
queries. ArangoDB sees a 1.5x scale in query execution times for every 2x
scale in data size. Whilst ArangoDB does not selectively outperform other data
pipelines in certain scenarios, it does show a steady increase in query
execution time with scaling data. This can be attributed to the dynamic query
optimizer that selects the perfect query execution plan depending on the query
being executed. ArangoDB employs efficient memory management techniques to
minimize disk I/O and maximize query performance. It utilizes memory caches
for frequently accessed data and implements buffer management strategies to
optimize disk access.

Figure 7. Query Execution time (in seconds) for Redis across the five datasets

####  5.3.4. Redis

Figure 7 portrays a graph containing information on the query execution times
of the five benchmark queries across the five datasets on Redis. Irrespective
of the size of data, Redis takes longer than all the other databases to
execute the queries. For sf1, the smallest dataset, Redis displays a best case
of 3x increase in terms of query execution times. Redis suffers primarily from
the data schema we had selected for the flat data model. By assigning all
features to a single key, linenumber_id, a single row of record becomes huge
for redis to retrieve from memory. By default, redis is an in-memory intensive
data store and hence, holding such a big record in memory is bound to make the
query execution slow and CPU intensive.

Figure 8. Query Execution time (in seconds) for Apache Kudu across the five
datasets

####  5.3.5. Apache Kudu

Figure 8 shows the recorded query execution times for the five benchmark
queries across the five datasets. Based on these readings, it is clear that
Apache Kudu performs the best amongst all the selected databases in terms of
query execution. Kudu stores data in a columnar format and this is highly
efficient for analytical workloads because it allows queries to read only the
columns needed for the query, minimizing I/O operations and improving query
performance. This can be visibly seen from the very minimal increase in query
execution times across datasets for queries 2 to 5. Even when data scales at
2x, query execution times have tended to stay flat and do not see a
proportional or exponential increase like the rest of the databases. The
reason why query 2 sees an exponential increase with scaling data is related
to a potentially incorrect time measurement on behalf of Apache Kudu. When
fetching data records based on given filter conditions, Kudu tends to write
the retrieved records onto the impala shell. The write operation time is also
included in the overall execution time of the query and thus it seems beefed
up with scaling data compared to the rest of the queires.

##  6\. Conclusion

Through this paper, we envisioned our idea of building the ideal data
engineering pipeline, that would be take care of data processing and data
store. We experimented with datasets of varying scale from the Koalabench
dataset where data was generated in two different data models. Our experiments
measured the query execution times for 5 benchmark queries and recorded the
data ingestion time for all databases. The effect of the data schema was
evident in the varied data ingestion times. Certain databases did not handle
the scaling levels of data and ended up seeing exponential increase in the
query execution times of complex queries. A definitive finding from our
experiments is the prominence of Columnar data storage options in future OLAP
research. Columnar storages tend to load data 2x faster than other SQL and
NoSQL options and the same goes for query execution as well.

These experiments also highlight the immense scaling and distributed
processing capabilities that modern-day NoSQL solutions have and how these can
be put to use to solve complex data analytical problems. We believe this idea
would be a pioneer towards the adoption of more NoSQL-based data store
solutions for evaluating OLAP workloads. As part of future work, we do
recommend the integration of a data analysis tool to commensurate the data
pipeline. Research can be extended across various columnar storage options to
identify the ideal columnar storage option to evaluate OLAP workloads.

## References

  * (1)
  * Apache (2006) Apache. 2006.  Hadoop Distributed File System.  (2006).  https://hadoop.apache.org/
  * Apache (2014) Apache. 2014.  Apache Spark.  (2014).  https://spark.apache.org/
  * Apache (2022) Apache. 2022.  Apache Kudu.  (2022).  https://kudu.apache.org
  * Barber (2017) Ronald Barber, et.al. 2017.  Evolving Databases for New-Gen Big Data Applications.
  * Bicevska and Oditis (2017) Zane Bicevska and Ivo Oditis. 2017.  Towards NoSQL-based Data Warehouse Solutions.  _Procedia Computer Science_ 104, 104–111.  https://doi.org/10.1016/j.procs.2017.01.080 ICTE 2016, Riga Technical University, Latvia.
  * Chevalier et al. (2015a) Max Chevalier, Mohammed El Malki, Arlind Kopliku, Olivier Teste, and Ronan Tournier. 2015a.  Benchmark for OLAP on NoSQL technologies comparing NoSQL multidimensional data warehousing solutions. In _2015 IEEE 9th International Conference on Research Challenges in Information Science (RCIS)_. 480–485.  https://doi.org/10.1109/RCIS.2015.7128909
  * Chevalier et al. (2015b) Max Chevalier, Mohammed El malki, Arlind Kopliku, Olivier Teste, and Ronan Tournier. 2015b.  Implementing Multidimensional Data Warehouses into NoSQL.  _ICEIS 2015 - 17th International Conference on Enterprise Information Systems, Proceedings_ 1\.  https://doi.org/10.5220/0005379801720183
  * Davardoost et al. (2020) Farnaz Davardoost, Amin Babazadeh Sangar, and Kambiz Majidzadeh. 2020.  Extracting OLAP Cubes From Document-Oriented NoSQL Database Based on Parallel Similarity Algorithms.  _Canadian Journal of Electrical and Computer Engineering_ 43, 2 (2020), 111–118.
  * de Carvalho Scabora et al. (2016) Lucas de Carvalho Scabora, Jaqueline Joice Brito, Ricardo Rodrigues Ciferri, and Cristina Dutra de Aguiar Ciferri. 2016.  Physical Data Warehouse Design on NoSQL Databases - OLAP Query Processing over HBase. In _International Conference on Enterprise Information Systems_.  https://api.semanticscholar.org/CorpusID:2636732
  * Dean and Ghemawat (2004) Jeffrey Dean and Sanjay Ghemawat. 2004.  MapReduce: Simplified Data Processing on Large Clusters.
  * Dehdouh (2016) Khaled Dehdouh. 2016.  Building OLAP Cubes from Columnar NoSQL Data Warehouses. In _Model and Data Engineering_ , Ladjel Bellatreche, Óscar Pastor, Jesús M. Almendros Jiménez, and Yamine Aït-Ameur (Eds.).
  * Dehdouh et al. (2014) Khaled Dehdouh, Omar Boussaid, and Fadila Bentayeb. 2014.  Columnar NoSQL Star Schema Benchmark. In _Model and Data Engineering_ , Yamine Ait Ameur, Ladjel Bellatreche, and George A. Papadopoulos (Eds.). Cham.
  * Dominguez-Sal et al. (2010) David Dominguez-Sal, Norbert Martinez-Bazan, Victor Muntes-Mulero, Pere Baleta, and Josep Lluis Larriba-Pey. 2010.  A discussion on the design of graph database benchmarks. In _Technology Conference on Performance Evaluation and Benchmarking_. Springer, 25–40.
  * El Malki (2022) Mohammed El Malki, et al. 2022.  Benchmarking Big Data OLAP NoSQL Databases. In _Ubiquitous Networking, 2018, pp. 82–94_.
  * Eliot Horowitz (2009) Kevin P. Ryan Eliot Horowitz, Dwight Merriman. 2009.  MongoDB.  (2009).  https://www.mongodb.com/
  * Khalil and Belaissaoui (2023) Abdelhak Khalil and Mustapha Belaissaoui. 2023.  An Approach for Implementing Online Analytical Processing Systems under Column-Family Databases.  _IAENG International Journal of Applied Mathematics_ 53, 1 (2023).
  * M. ([n.d.]) Astrahan M., et. al. [n.d.].  System R: Relational Approach to Database Management.
  * Özcan et al. (2017) Fatma Özcan, Yuanyuan Tian, and Pinar Tözün. 2017.  Hybrid Transactional/Analytical Processing: A Survey. In _Proceedings of the 2017 ACM International Conference on Management of Data_ _(SIGMOD ’17)_. Association for Computing Machinery, 1771–1775.  https://doi.org/10.1145/3035918.3054784
  * Sanfilippo (2009) Salvatore Sanfilippo. 2009.  Redis.  (2009).  https://redis.io/
  * Seghier and Kazar (2021) Nadia Ben Seghier and Okba Kazar. 2021.  Performance benchmarking and comparison of NoSQL databases: Redis vs mongodb vs Cassandra using YCSB tool. In _2021 International Conference on Recent Advances in Mathematics and Informatics (ICRAMI)_. IEEE, 1–6.
  * Shaikh and Kitagawa (2020) Salman Ahmed Shaikh and Hiroyuki Kitagawa. 2020.  StreamingCube: Seamless Integration of Stream Processing and OLAP Analysis.  _IEEE Access_ 8 (2020), 104632–104649.  https://doi.org/10.1109/ACCESS.2020.2999572
  * Shvachko et al. (2010) Konstantin Shvachko, Hairong Kuang, Sanjay Radia, and Robert Chansler. 2010.  The Hadoop Distributed File System. In _2010 IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST)_. 1–10.  https://doi.org/10.1109/MSST.2010.5496972
  * Stonebreaker (1996) Michael Stonebreaker. 1996.  PostgreSQL.  (1996).  https://www.postgresql.org/
  * Weinberger and Celle (2015) Claudius Weinberger and Frank Celle. 2015.  ArangoDB.  (2015).  https://arangodb.com/
  * Zaharia (2016) Matei Zaharia, et al. 2016.  Apache Spark.  _Communications of the ACM, vol. 59, no. 11, 28 Oct. 2016, pp. 56–65_.


# On the Bell experiments; an epistemological approach

Inge S. Helland<EMAIL_ADDRESS>Department of Mathematics, University of
Oslo
P.O.Box 1053 Blindern, N-0316 Oslo, Norway
Orcid: 0000-0002-7136-873X

###### Abstract

The Nobel prize in physics for 2022 was given for performing Bell experiments
with varying degree of sophistication. The interpretation of this experiment
is discussed by first recalling Bell’s simple argument behind his
inequalities, in particular the CHSH inequality. It is argued that any
independent observer must have a limitation: He is not able to keep all
relevant variables in his mind at the same time when trying to model the
experiment. This is contrasted to the solution proposed by Tim Maudlin, where
nonlocality is crucial.Maudlin criticizes the Nobel price committee, but this
critique is countered. Finally, a related new approach to the foundation of
quantum mechanics is briefly sketched, giving references to the relevant
literature.

Keywords: Bell experiment; epistemological interpretation; hidden variables;
nonlocality; quantum foundation

##  I Introduction

The Nobel prize in physics for 2022 has been given to three experimental
physicists for having performed, with various degrees of sophistication, a so-
called Bell experiment. This experiment has showed beyond any doubt that what
is called the CHSH inequality, one special among several Bell inequalities,
may be violated in practice. This agrees with the predictions of quantum
mechanics but is not in agreement with what may be called a simple common-
sense argument, an argument given originally by the theoretical physicist John
Bell, whose fundamental works in the 1960’s raised questions that have led to
many different articles since then in the physical literature. Indeed, several
physicists and philosophers have tried to understand the experimental result
that now has been made 100 % clear. My own understanding is given in the
recent article [1]. It is based upon a simple model of an observer’s mind, a
model from which essential elements of quantum mechanics may be deduced [2,3].
This whole approach implies a totally new way of looking upon quantum theory,
perhaps a way which may be of some interest now in connection to the results
of the Bell experiments.

Other researchers have other ways of understanding the results of the Bell
experiment. I can for instance refer to the recent article by the philosopher
Tim Maudlin [4]. Maudlin claims that the Physics Nobel Prize is misunderstood
even by the Nobel prize committee itself. I must disagree with Maudlin here.
Of course, he is right in much of which he says in his article, but in my
opinion the Nobel prize committee was also right in what it said. To explain
my points of view, I must take as a point of departure, first the original
Bell arguments around his inequalities, as modified to the CHSH inequality,
then my own simple model of an observer’s (or in fact any person’s) mind.

##  II The Bell argument

Here are the arguments essentially due to John Bell: Assume that a person C is
trying to make sense of the Bell experiment, and in his mind, he focuses on
just one run of the experiment, an experiment where particles with spin are
sent to two actors Alice and Bob. Here Alice makes a choice between two
settings of for measuring a spin component: a (giving response, say A) or a’
(response A’). Similarly, Bob makes a choice between settings b (hypothetical
response B) or b’ (hypothetical response B’). Without loss of generality, the
responses can be taken to be +1 or -1 (spin up or down, or left or right, or
whatever).

Call this person Charlie. Assume that - and that is the crucial assumption -
in the process of making sense of the experiment and trying to find a model to
describe it, he can keep in his mind at the same time all the variables
$A,A^{\prime},B,$ and $B^{\prime}$. Then, to him, by a simple arithmetic
argument, he first finds that the combination of variables
$AB+A^{\prime}B+AB^{\prime}-A^{\prime}B^{\prime}=A(B+B^{\prime})-A^{\prime}(B-B^{\prime})$
must take one of the values -2 or +2. ($B$ and $B\textquoteright$ are either
equal or opposite. In the first case $B-B\textquoteright$ is zero, in the
second case$B+B\textquoteright$ is zero. In both cases the remaining
parenthesis is either -2 or +2. So, the whole expression is either -2 or +2.)

If Charlie is a mathematician or a statistician, he might try a joint
probability model, and conclude from this and the observation above that the
expectations E of the random variables satisfy
$E(AB)+E(A^{\prime}B)-E(AB^{\prime})-E(A^{\prime}B^{\prime})\leq 2$. This is
the most famous one of Bell’s inequalities, the CHSH inequality. It can be
violated by quantum mechanics, and all these experiments have shown that it
also can be violated in the real world.

So, what is wrong with the simple argument above? I can see only one solution:
Charlie is simply not able to all these 4 variables in his mind at the same
time during his modeling efforts. Note that Charlie can be any person. In my
recent article [1] I have elaborated on such thoughts. The conclusions agree
with the results of the Bell experiments, but they are not quite in agreement
with what Tim Maudlin says.

Note that a hypothetical joint probability model for $A,A^{\prime},B$ and
$B^{\prime}$ assumes that these are variables on some probability space, which
in effect implies a hidden variable. I would say that in this sense the Nobel
prize committee was right: The existence of such a hidden variable is excluded
by the experimental result.

##  III Nonlocality and hidden varables?

Tim Maudlin says that non-locality is the heart of the matter. Maybe so. But I
have some difficulties in seeing this non-locality as so fundamental. Firstly,
no real information can be passed from Bob to Alice. Secondly, it is always an
assumption that the two particles had been in contact at some point of time in
the past. If there were only one possible choice of measurement at each end,
then this whole thing could have been understood by a version of what John
Bell called a Bertlmann’s sock’s argument: Suppose that Bob always has two
different socks, one red and one green. Suppose further that he at some point
of time puts one of his socks in one box, the other in another box, and then
sends a random box to Alice, who is far away. When then Alice opens her box
and finds a red sock, she will immediately conclude that Bob has kept a green
sock, and vice versa.

The strange thing by the Bell experiment, is that we may have a ‘common sense’
argument violated when both Alice and Bob have two possible maximal
measurements, both socks and gloves at the same time in a way, the states of
which are unknown both to Alice and to an independent observer Charlie.

Tim Maudlin refers to the theory of David Bohm in his arguments. I agree that
this is a sort of hidden variable theory, and that it was well known to John
Bell. However, as I read the press release of the Nobel prize committee, when
they talk about hidden variables, they only mean this in the simple sense that
I have mentioned above

##  IV A new approach towards quantum foundation

. The observer Charlie may be any person, and his context may in general be a
measurement process, a process related to an experiment, a model building
process, or a process of trying to understand another person’s model. In
short, any process during which he must make decisions.

I rely on the philosophy of the physicist Hervé Zwirn [5]. Zwirn says that
every description of the world must be relative to the mind of an observer. I
my discussions with Zwirn, I have claimed that also groups of communicating
observers may have a joint description.

In my own last papers, I have tried to make Hervé’ Zwirn’s philosophy concrete
by proposing a simple model of our minds: Let us have variables
$\theta,\eta,\xi,...$ in our minds at some fixed time in some fixed context.
Some of these may be accessible, that is, it is in principle possible to find
values for them later by doing measurements or experiments. An accessible
variable $\theta$ is called maximal if it cannot be extended to another
accessible variable. And here is my main model assumption: There exists
somehow an inaccessible variable $\phi$ such that all the accessible ones can
be seen as functions of $\phi$.

Here are two important physical examples: 1) $\phi$ might be the vector
(position, momentum) of a particle. 2) $\phi$ might be a spin vector of an
electron. In other situations, the existence of a $\phi$ may be somewhat
hypothetical. Combining this simple model of the mind with some mathematically
formulated symmetry-assumptions, I arrive at very interesting results. In [3]
I derive very essential elements of quantum mechanics in this way. This is
backed by arguments in the book [2]. Altogether, the whole of quantum
mechanics can be derived from what I would call rather simple postulates.

This is a new and unfamiliar way of approaching quantum mechanics, but its
basic postulates are not as formalistic as in the traditional approach.
Results of the Bell experiment can be understood using my approach. Well-known
paradoxes can by understood [3] using my approach. And the postulates can in
principle be explained to any scientist with some mathematical background.
Thus, the communication across scientific borders may be facilitated.

References

[1] Helland, I.S. (2022a). The Bell experiment and the limitations of actors.
Foundations of Physics 52, 55.

[2] Helland, I.S. (2021). Epistemic Processes. A Basis for Statistics and
Quantum Theory. Springer, Berlin.

[3] Helland, I.S. (2022b). On reconstructing parts of quantum theory from two
related maximal conceptual variables. International Journal of Theoretical
Physics 61, 69.

[4] Maudlin, T. (2022). What the Nobel prize gets wrong about quantum
mechanics. IAI news 6th October 2022.

[5] Zwirn, H. (2020). Nonlocality versus modified realism. Foundations of
Physics 50, 1.