# On Kubernetes-aided Federated Database Systems ††thanks: This research is
supported in part by startup funding from Queen’s University Belfast.

Zheng Li  School of EEECS
Queen’s University Belfast
Belfast, UK
ORCID: 0000-0002-9704-7651  Nicolás Saldías-Vallejos, María Andrea Rodríguez
Department of Computer Science
Universidad de Concepción
Concepción, Chile
Email<EMAIL_ADDRESS><EMAIL_ADDRESS>Austen Rainer  School of EEECS
Queen’s University Belfast
Belfast, UK
Email<EMAIL_ADDRESS>
###### Abstract

Cloud computing has made federated database systems (FDBS) significantly more
practical to implement than in the past. As part of a recent Web-based
Geographic Information System (WebGIS) project, we are employing cloud-native
technologies (from the container ecosystem) to develop a federated database
(DB) infrastructure, to help manage and utilise the distributed and various
geospatial data. Unfortunately, there seem to be inherent challenges and
complexity of applying the container and Kubernetes technologies to building
and running DB systems. Considering that most of the geospatial and theme data
are pre-obtained and fixed in our WebGIS project, we decided to focus on the
read-only user queries and still resort to Kubernetes to implement an FDBS
instance to use. Unlike the de facto practices (e.g., using the StatefulSets
mechanism, extending Kuberentes APIs, or employing KubeFed), our solution for
Kubernetes-aided FDBS simplifies the tech stack by investigating the fractal
object of federated data management, inclusively containerising DB instances,
and using the lightweight Deployment mechanism to handle stateless DB
containers. Overall, this research not only reveals an easy-to-implement
approach to constructing read-only components in a fully-fledged FDBS, but
also proposes and demonstrates a novel methodology for FDBS investigations.

###### Index Terms:

container, database federation, federated database system, geospatial data,
Kubernetes

##  I Introduction

Database (DB) federation has widely been considered as an ideal solution to
the chaos of DB technology sprawl and isolated data islands in large
businesses. Unfortunately, due to the various complexities of federated DB
systems (FDBS), it was the centralised data warehouse that acted as the
superior choice for the vast majority of use cases, until cloud computing
emerged as a game changer [1]. By “disaggregating storage and compute”, the
cloud paradigm (especially benefiting from the fast in-cloud network
communication) breaks the previously tight coupling between data storing and
query processing, which relaxes almost all the challenges associated with
query federation and data virtualisation, and thus makes FDBS implementations
significantly more practical than in the past.

Driven by a recent Web-based Geographic Information System (WebGIS)
project,111An early proposal project can be found at
https://github.com/RodrigoH2Garrido/RodrigoMTV2 we are also employing cloud-
native technologies to implement a federated DB infrastructure, to facilitate
the management and utilisation of diverse geospatial datasets. In particular,
we try to containerise different DB instances and use Kubernetes to manage the
containerised and distributed DB instances, when constructing FDBS blocks.
Nevertheless, we met surprisingly many challenges and constraints along this
technical path. For example, in addition to the native and tedious
configurations (e.g., the Dockerfile and YAML files), the third-party tools
may also be required (e.g., the Operators that extend Kubernetes APIs), which
often results in a heavy tech stack in practice. There are even dissenting
voices against this technical path, such as (i) DB containers should not be
used for production [2] and (ii) it is not ready yet to run DBs in Kubernetes
[3].

Based on our successful prototyping work on enabling container-native read-
only DB for production [4], we decided to keep emphasising read-only queries
and still implement a Kubernetes-aided FDBS to use. From the application’s
perspective, most of the geospatial and theme data (e.g., postal code) are
pre-obtained and fixed in our WebGIS project. In fact, more than half of the
data used by real-world applications are read-only [5]. From the technological
perspective, our container-native read-only DB solution significantly
simplifies the tech stack for building a Kubernetes-aided FDBS. On the one
hand, the container-native feature strictly guarantees the shared-nothing
architecture of an FDBS, and then enjoys the architectural advantages (e.g.,
the increased scalability and the reduced blast radius of failures). On the
other hand, the read-only feature naturally avoids the complexity and overhead
of handling stateful services in Kubernetes.

By identifying the fractal pattern of, and by analysing the fractal object of
data management in FDBS, this paper explains our system design together with
demos and prototypes of the relevant technical implementations. Those demos
and prototypes in turn validate the system design.222We share the
documentation about a demo component system of our proposed Kubernetes-aided
FDBS at https://zenodo.org/record/6991105. Correspondingly, this research
makes a twofold contribution:

  * •

For practitioners, our work offers a handy tutorial for implementing
Kubernetes-aided FDBS. Although this solution is only applicable for read-only
user queries, it can be a lightweight and solid cornerstone to support read-
only components in a fully-fledged FDBS.

  * •

For researchers, our work reveals a novel methodology for FDBS investigations,
i.e. studying the fractal pattern and the fractal object of FDBS. This
approach further opens new research opportunities, e.g., calculating the
fractal dimension to measure complexity and perform comparison between
different FDBS instances.

The remainder of this paper is organised as follows. Section II briefly
introduces the background of FDBS and particularly highlights the current
practices of applying Kubernetes to building federated systems. Section III
describes the motivation project of this research. By focusing on the
identified fractal object, Section IV specifies the design and initial
implementation of our Kubernetes-aided FDBS. Finally, we discuss the threat to
validity, draw conclusions and give our future work plans in Section V.

##  II Background and Related Work

As a special type of multi-DB systems, FDBS are characterised by the
hierarchical management of autonomous component DB systems [6]. The
hierarchical and autonomous DB management has become more and more valuable
and necessary for modern applications, because of the increasingly involved
heterogeneous datasets with diverse models, ownership, and storage
technologies [7]. A typical example is the GIS domain where various geospatial
data may be acquired and utilised by different organisations via different
acquisition schemes and channels [8]. Thus, partial and controlled data
sharing across those organisations would be more practical than building up a
centralised data lake. An advantage of GIS applications in this case is that
the standard geographical coordinates can naturally act as universal foreign
keys to facilitate the geospatial data sharing and integration. This also
motives our research described in this paper (see Section III).

###  II-A Kubernetes Federation

Kubernetes is the de facto open-source platform for automatically deploying,
scaling, and managing containerised applications. Benefiting from the
convenient and automated Kubernetes mechanism of arranging applications within
a single cluster, Kubernetes Cluster Federation (a.k.a. KubeFed) was developed
to coordinate and manage multiple clusters. Although still at a developing
stage, KubeFed has been employed to study pioneer solutions for distributing
application components and for balancing workloads in the modern computing
paradigms [9]. Meanwhile, more research interests can be found in improving
KubeFed. For example, a policy-based scheduling architecture is proposed as a
supplement to KubeFed for determining the appropriate federated clusters [10];
whereas some other researchers argue to replace the KubeFed control plane with
a decentralised control plane for the federation of Kubernetes clusters [11].

In contrast with KubeFed, we claim two significant differences in this
research. Firstly, KubeFed is a top-down strategy to orchestrate the federated
infrastructure composed of known clusters, while our research is a bottom-up
approach to growing a federated (DB) system without necessarily knowing its
eventual size. When using KubeFed, a configuration template needs to be
generated in a host cluster and will be propagated to the pre-determined
member clusters. As mentioned in [11], this strategy weakens the autonomy of
the federation components and inevitably leads to a single point of failure.
In our research, each component system is supposed to autonomously manage its
own infrastructure and configuration (e.g., load-balancing policies), and to
stay unaware of its involvement in any upper federated system(s).

Secondly and more importantly, KubeFed targets the application federation,
while our work focuses on the DB federation. Considering that the application
containerisation in the production environments does not containerise DBs
(instead, fully managed cloud DB services are used [12]), the Kubernetes-based
application federation does not guarantee the existence of an underlying FDBS.
Consequently, scaling an application within the federated Kubernetes clusters
could cause performance bottlenecks or require extra/external DB service
adjustments, due to the mismatch between the data accessing points (at the DB
level) and the data processing points (in the containerised modules).

Given these differences, we further argue that this research and KubeFed would
reinforce each other and eventually be able to be combined together. Following
the layered software architecture, KubeFed’s top-down strategy can still be
suitable for globally optimising the deployment of given applications, while
our bottom-up approach may be particularly used for integrating the diverse
and unpredictable datasets.

###  II-B Running Databases in Kubernetes

As mentioned above, when containerising and managing an application that
involves DBs, the common practice in production is to host and maintain the
DBs independently outside of Kubernetes [13, 14]. Google engineers confirm
that it is still far from running a DB in Kubernetes in a practical sense, and
we have to wait for the further evolution of relevant technologies and tools
[3].

Despite those majority opinions, the growing container ecosystem keeps
fostering interests in running DBs in Kubernetes, and we have observed two
study paths:

  * •

The first path advocates the StatefulSets mechanism of Kubernetes to enable
the state management for DBs, by automatically provisioning persistent volumes
on a per pod basis [15]. However, using external volumes for data persistence
could encounter dangling volume issues [12] and will introduce disk I/O
performance bottlenecks [16].

  * •

To address the limits of StatefulSets, the second path employs third-party
Operators to extend Kubernetes APIs, by creating custom resources and
controllers [14]. However, the current Operators are immature and unsuitable
for mission-critical workloads [13], not to mention that the extended tech
stack may even worsen the complications of running DBs in Kubernetes.

Different from both of the study paths, our research argues to simplify the
tech stack, by employing a container-native data persistence solution, and
then using the straightforward Deployment mechanism to run read-only DBs in
Kubernetes. The simplified tech stack not only enables Kubernetes to
inclusively handle read-only DB clusters, but also encourages us to work
further on Kubernete-aided FDBS in production, at least for stateless
applications at this current stage. To our best knowledge, this is the first
study that employs Kubernetes to investigate and implement FDBS.

##  III The Motivation Project

The motivation of this research is a recent WebGIS project of ours. This
WebGIS project aims to build up an efficient DB infrastructure, to facilitate
offering online GIS services. By enabling collecting, storing, managing,
analyzing, and displaying geospatial data, GIS has become an indispensable
software tool for studying the scientific discipline Geography [17].
Benefiting from the significant development of the Internet, modern GIS
implementations are increasingly embracing the web technologies to provide
low-cost and platform-independent services [18]. Then, users can conveniently
consume the online services that are comparable to those of desktop GIS [19],
without necessarily installing any GIS software or maintaining the
geographical data.

However, the service response speed has been identified as a performance
bottleneck that may harm the user experience of WebGIS. In addition to the
possibly heavy communication overhead over the Internet [20], the major
problem is essentially the monolithic software infrastructure, which “leads to
the inefficiency of GIS software in the face of data intensity and computation
complexity” [21]. It should be noted that the widely discussed client/browser-
server architecture and the multi-layer system design do not guarantee a
monolith-free implementation of WebGIS. For example, the bottom layer will
still be monolithic if a single spatial DB is used to support the whole system
[22]. In practice, multiple simultaneous clients may request different parts
of a large geographic dataset to be rendered with different analysis functions
[23].

Therefore, we advocate the federated architecture for breaking the monolith of
WebGIS implementations. In particular, many geospatial and theme data (e.g.,
postal code) we plan to use are fixed in advance, not to mention the
historical data that are not allowed to change in general. For the historical
data, different periods of time series may also be stored and processed
separately, to facilitate the data management and visualisation. For example,
the PRISM Climate Group333PRISM Climate Data: https://prism.oregonstate.edu/
distinguishes between Recent Years and Historical Past when offering
temperature and precipitation data at multiple spatial/temporal resolutions
[24]. Thus, we naturally recall the read-only DB container solution [4] to
develop a Kubernetes-aided FDBS for our WebGIS project.

##  IV The Design and Initial Implementation of Kubernetes-aided Federated
Database Systems Based on a Fractal Pattern

Given the definition of FDBS, we identify a fractal pattern from the data
management’s perspective: An FDBS is composed of a set of autonomous
components, and each component consists of multiple autonomous sub-components
also in the federated way, which repeats until all the leaf components are
single DB instances. By emphasising the basic data management activities, we
clarify the self similarity of the fractal to be the combination of data
storing, data retrieving, and (optional) data distilling. Particularly, data
storing may also come with data partitioning and/or data cloning. As such, the
fractal object of data management can represent either a constituent DB, a
component DB system, or an FDBS at any scale, as illustrated in Fig. 1.

Figure 1: The fractal object of data management in federated database systems.

Using our motivation project as the context, we elaborate this fractal object
by explaining the involved data management activities in the following
subsections.

###  IV-A Data Distilling

To maximise the alignment with the literature, we use the term “data
distilling” instead of “data analytics” to indicate all kinds of
operations/methods that make sense of the retrieved data, ranging from
redundancy reduction [25] to information/knowledge extraction [26]. From a
single DB’s perspective, data distilling can be distinguished from the back-
end DB system and merged into upper-layer business logic implementations. When
it comes to concurrently distributed DBs, the DB integration technologies also
emphasise data usage (distilling) at an abstract level, via standard user
interfaces and uniform data access [27, 28]. However, data distilling is not
separable from the fractal object of FDBS, even though it can be optionally
implemented or ignored by different component systems. Driven by the
distinctive feature (namely autonomy) of federated architecture, the component
systems of an FDBS should be completely self-sustained and functional, i.e. a
component can not only respond to the upstream retrieval requests, but can
also support its own self-sufficient data distilling tasks.

Our WebGIS project follows the distillation use case of [25] to synthesise and
visualise the geospatial data. A typical functionality is to group and/or
identify neighbours of the United States’ postcodes on a map at different zoom
levels. Ideally, the United States’ postcode visualisation system can be
supported by distributed DBs belonging to the individual states, while each
state may customise a standalone visualisation system based on its own data
for the local usage. Meanwhile, the distributed DB system of the United States
can also contribute the national data to a world-wide postcode system for the
global usage.

In practice, for the convenience of implementation and demonstration, we take
advantage of the characteristics of postcodes and divide them into ten DBs
according to their first digits (i.e. zero, one, …, nine). The grouping rules
and the neighbour identification strategy are implemented into a serverless
function with Amazon Web Services (AWS) Lambda,444At the time of writing, we
are migrating the AWS Lambda function to a microservice based on Amazon
Elastic Kubernetes Service (Amazon EKS), in order to take advantage of the
catalog of Kubernetes services of distributed DBs (see Section IV-B). as shown
in Algorithm 1. The user interface source files (e.g., the HTML pages, self-
defined marker images, etc.) are deployed to the Amazon Simple Storage Service
(Amazon S3). It should be noted that the Lambda function and the interface are
independent from the back-end DBs, and thus they can be used both for the
whole DB system and for any component DB. For example, Fig. 2 demonstrates the
usage of a single DB to support visualising the distribution of the United
State’s postcodes starting from “4” only.

Input: Zoom level zoom, the optional inputs address $=(0,0)$ and its
neighbors’ number $k=-1$.
Output: A set of geographic locations (i.e. centroids or the closest $k$ ones
to the address) to be visualised.

Algorithm 1 Identifying Geographic Locations

1:$\triangleright$ Grouping postcodes based on zoom levels on the map.

2:Groups $\leftarrow\emptyset$

3:switch zoom do

4: case 1, 2, 3, 4:

5: Groups $\leftarrow$ group postcodes by the first digit.

6: case 5, 6:

7: Groups $\leftarrow$ group postcodes by the first two digits.

8: case 7, 8:

9: Groups $\leftarrow$ group postcodes by the first three digits.

10: case 9, 10:

11: Groups $\leftarrow$ group postcodes by the first four digits.

12: case others:

13: Groups $\leftarrow$ group postcodes by the all five digits.
$\triangleright$ No grouping.

14:Centroids $\leftarrow\emptyset$

15:Centroids $\leftarrow\\{\text{Centroid coordinates
of~{}}\textit{group}\mid\textit{group}\in\textit{Groups}\\}$

16:if $k<0$ then

17: $\triangleright$ If address and $k$ are not specified, the functionality
is grouping.

18: return Centroids

19:end if

20:$\triangleright$ Calculate distances between address and the centroids.

21:Distances$\leftarrow\emptyset$

22:Distances
$\leftarrow\\{(\textit{centroid},|\textit{centroid}-\textit{address}|)\mid\textit{centroid}\in\textit{Centroids}\\}$

23:$\triangleright$ Select $k$ centroids that are the $k$ nearest neighbours
of address.

24:Neighbours$\leftarrow\emptyset$

25:Neighbours
$\leftarrow\operatorname*{argmin}_{D\subset\textit{Distances},|D|=k}\sum_{c\in
D.\textit{centroids}}D[c]$

26:return Neighbours.centroids $\triangleright$
$\\{c\mid(c,\textit{Distances}[c])\in\textit{Neighbours}\\}$

Figure 2: The distribution of the United State’s postcodes starting from “4”.

###  IV-B Data Retrieving

Data retrieving and storing correspond to a pair of opposite basic DB
operations, i.e. reading and writing data. In generic scenarios, these two
operations coexist when satisfying user requests. In our WebGIS project, we
decouple these two operations by constraining user requests to be data
retrieving only, while leaving data storing to the role of DB administrators
(see Section IV-C). This is both to reflect the characteristics of our current
GIS datasets and to match the features of FDBS. As mentioned previously, many
GIS-related data barely change and are maintained by different stakeholders
rather than by the end users. For example, the postcodes in a country must be
allocated by the government or by the government-authorised entities, and once
allocated they can only be used but not changed by the residents. The
requirement of managing such datasets further justifies the suitability of
FDBS for our WebGIS project, as an FDBS accepts different ownership of its
individual components instead of using centralised control [29].

Figure 3: The essential parts and architecture for data retrieving
implementation.

When it comes to employing Kubernetes technologies to implement data
retrieving, we highlight the essential parts and our implementation
architecture by demonstrating a single DB scenario, as portrayed in Fig. 3 and
explained below.

  * •

Self-contained DB container. Considering that there is no data input from the
end users, we have developed an inclusively containerised read-only DB
solution (see more details in Section IV-C). Although we only used MySQL for
the demonstration [4], the containerisation is not limited to any DB product,
not to mention the publicly accessible cloud DB services. In other words, our
solution is compatible with the design autonomy of FDBS that allows the
component systems to freely choose DB technologies, query languages, and data
models [30].

  * •

Data access API container. Given the heterogeneity in DBs (that is also the
nature of FDBS), we supplement a containerised data access layer and use
RESTful APIs to hide those connection routines and query mechanisms. Note that
this data access layer does not violate the aforementioned design autonomy,
because RESTful APIs can also be realised using flexible languages and
frameworks (e.g., Node.js and Flask). On the contrary, this data access layer
facilitates realising the execution autonomy of constituent DBs, by exposing
suitable APIs to control the operations from external requests.

  * •

Pod. A pod is the smallest deployable and manageable unit in Kubernetes. We
define the DB container and the corresponding API container to be co-located
in a single pod. Thus, the tight coupling guarantees any deployed DB and its
data access layer to either work along or be gone together. Pods have to run
on one or multiple nodes that may be virtual or physical machines. For the
purpose of conciseness, we intentionally omit the environmental element (where
the Kubernetes concept Node exists) from the illustration (see Fig. 3).

  * •

Service. Despite the data access layer that has provided APIs, we still need a
Kubernetes service layer for data retrieval, for two reasons:

    1. 1.

The pods have an ephemeral nature as well as the containers at runtime.
Although Kubernetes can recreate new ones if any pods are lost, the addresses
of the pods (or the hosts of APIs) will unavoidably change. Therefore, an
abstract service with a fixed IP address will be needed to reconcile the
uncertainty, by automatically selecting the pods (including newly created
ones) with predefined labels.

    2. 2.

Kubernetes services enable a unified connection mechanism between an FDBS and
its components, and also between the components. A service can not only
abstract the definition and the access policy of pods, but can also abstract
other kinds of back-end
endpoints.555https://kubernetes.io/docs/concepts/services-
networking/service/#services-without-selectors For example, given a standalone
query engine (see Query engine below) that offer single query capabilities for
a federated component system, we can manually create an Endpoints object for
it and map its network address to a standard Kubernetes service. Note that the
behaviours of such an engine service will have no difference to the basic DB
services.

  * •

Centralised catalog of services. Once an aforementioned service is exposed, it
is ready to be used to retrieve data from its back-end DB(s). In other words,
the service can be viewed as an equivalent representation of its back-end
DB(s). Recall the definition that an FDBS is a heterogeneous collection of DBs
[7]. In this case, the FDBS may also be considered as a service collection. To
drive multiple and distributed services to co-work as an autonomous entity, a
prerequisite is to make them conveniently discover-able, and we advocate to
use a centralised catalog of services. The catalog includes not only the
service addresses and callable APIs, but also the respective metadata about
the data sources that can facilitate the service usage.

  * •

Query engine. Based on an available and centralised catalog of DB services, we
need a query engine to interpret, optimise, and break external requests into
internally serviceable queries. Since the underlying data access is based on
APIs and the data models have been reflected (or constrained) by the API paths
and parameters, we summarise the knowledge of the service catalog and further
design abstract APIs to act as the query engine, instead of resorting to a
traditional SQL engine (that is also inappropriate here). Furthermore and
optionally, by sticking to the fractal point of view, the centralised catalog
and the query engine can be similarly implemented as a DB and its access
layer. Then, it will be convenient to follow the same routine to respectively
containerise them, tightly couple them into a pod, and expose the pod via a
Kubernetes service.

###  IV-C Data Storing

Before being able to retrieve data, there must be data already stored
persistently in accessible repositories. Similar to Section IV-B, we start
explaining our data storing mechanism also from a single DB’s perspective.
Since our project only focuses on the reading requests from users, we have
employed a container-native read-only DB solution [4] for storing the spatial
datasets we need. Unlike the conventional DB containerisation solution that
relies on external volumes for data persistence, this container-native
solution pre-bakes the necessary data into DB images. Given the immutable
nature of image, the pre-baked data will be unchangeable for use at runtime.
When the involved datasets need to be updated, the administrator who is in
charge of the data source can rebuild DB images to replace the old ones. In
practice, a local DB may be maintained to generate DB dumps to facilitate the
image building. Based on new images, when data cloning is implemented (see
Section IV-C2), the rolling update techniques [31] can further be employed to
update a cluster of DB containers smoothly and directly in the production
environment.

In addition to satisfying the read-only needs, the container-native approach
to data persistence can bring various benefits, ranging from avoiding the
issue of dangling volumes to improving the performance of data retrieval.
However, this DB container solution is not encouraged to cater large-size
datasets, because the oversized images will significantly reduce the
portability and increase the deployment latency of the corresponding
containers. Therefore, a practical strategy of dealing with a large dataset is
to break the dataset into small subsets and store them via multiple DB
containers. It is noteworthy that this strategy well matches a foundational
idea of FDBS, i.e. enabling the divide-and-conquer management and organisation
of data.

(a) The data partitioning scenario.  (b) The data cloning scenario.  (c) The
mixed scenario including both data partitioning and cloning.

Figure 4: Three multi-database scenarios for data storing.

Correspondingly, after fixing the mechanism for storing data with respect to a
single DB, we move on to the discussion about data storing in the multi-DB
scenarios. In detail, we distinguish between three scenarios, namely data
partitioning, data cloning, and a mixed scenario that involves the both, as
abstractly illustrated in Fig. 4. Particularly, since data cloning can be
implemented at both the pod level and the service level in Kubernetes (see
Section IV-C2), we highlight only these two Kubernetes parts in the
illustration, and using different (or the same) geometric shapes to
respectively represent different data (or the identical clones) that are
stored in DB containers and are retrievable via services.

####  IV-C1 The Data Partitioning Scenario

Despite having different motives, data partitioning is the inherent
requirement of both FDBS and our container-native DB solution. Here we
consider the originally distributed datasets as the result from data
partitioning by nature, while the distributed datasets may need further splits
for non-functional purposes. For example, the Open Geospatial Consortium (OGC)
standards666OGC Standards: https://www.ogc.org/docs/is define the most
fundamental GIS modules as simple features who provide a common way to store
and access geographical feature data. Thus, it is natural to associate a whole
feature dataset with a simple feature implementation. When the simple feature
involves a large amount of data, we advocate to divide the whole dataset into
suitable subsets to balance, and to take advantage of, the DB containers’
portability (see Fig. 4a).

We have proposed a cuboid partitioning approach to help identify suitable sub
datasets, as illustrated in Fig. 5. On the one hand, given the two-dimensional
representation of the Earth’s surface, it is convenient and flexible to slice
the Earth map into different sizes of pieces, especially for the situation
when the geographical data are sparse or unevenly distributed. On the other
hand, we regulate that different themes of data must be separated and stored
in different DBs. The data themes can be either from nature (e.g., climate,
forest biomass, underground resources, etc.) or from the human world (e.g.,
postcode, power grid, traffic flow, etc.). The effects of this cuboid
partitioning approach has already been reflected by the aforementioned demo of
data distilling (see Fig. 2).

Figure 5: Partitioning spatial data according both to their geographic
coordinates and to their themes.

####  IV-C2 The Data Cloning Scenario

To address the throughput bottleneck of DB or network (e.g., due to request
floods), increasing data/DB redundancy is a common tactic to improve the
performance and reliability of DB systems. Thus, it is worth considering to
create and separately store data clones after the data partitioning is done.
When employing the Kubernetes technologies to conduct data cloning and manage
the data clones, we distinguish between the implementation of parallel DB
services and the implementation of a DB pod cluster, as represented
respectively by the left two services and by the rightmost service in Fig. 4b.

As the name suggests, a DB pod cluster clones the stored data by replicating
the pods. Considering that read-only DBs are carefree about the state
information, our two-container pod (see Section IV-B) can be viewed as hosting
a stateless application. In the stateless situation, Kubernetes can use a
declarative Deployment object to create and automatically manage a set of pod
replicas. To avoid repeating the official documentation, we do not re-explain
the technical details of Kubernetes Deployment mechanism here.

Since the abstraction of a DB pod cluster is still a single DB service, the
parallel DB services can in turn be viewed as a set of DB pod clusters, which
is essentially a special instance of the multi-cluster deployment architecture
[32]. Compared with a single cluster of pods handled by Kubernetes, the multi-
cluster deployment would need extra and inter-cluster load-balancing
techniques. This, however, gives us more flexibility and controllability to
improve the performance of a multi-cluster system. For example, we have
investigated the effectiveness and efficiency of intra-query parallelism
against the cloned data, i.e. decomposing a single query into smaller tasks
and executing them concurrently [33]. By using the benchmark dataset of
Amazon’s spot service price history,777https://doi.org/10.5281/zenodo.4583507
we demonstrate the performance measurement and comparison between the single-
query data reading and the two-thread intra-query parallelism, as shown in
Fig. 6. As can be seen in this case, it would be worth breaking a single query
evenly into two sub-queries, when the data to be retrieved have roughly more
than 3000 records. Note that our measurement has included the time consumed
for pre-counting the needed data records (by using a pre-query with the SQL
statement starting from SELECT COUNT()).

Figure 6: Linear regression modeling analysis and performance comparison of
the intra-query parallelism in two threads against single-query data reading.

This demo proves that we can take advantage of the pre-knowledge of both the
cloned data and their storage architecture (e.g., empirically building an
intra-query parallelism lookup table with respect to the concurrency level and
workload size), to actively improve the data retrieval performance, rather
than passively rely on the built-in load balancing of Kubernetes. Ideally, the
evaluation and optimisation of a sizeable read-only query can be implemented
similar to the peer-to-peer data sharing [34] (from a single node’s
perspective), i.e. concurrently reading different data segments from many peer
and identical DB instances in an FDBS.

####  IV-C3 The Mixed Scenario Including both Data Partitioning and Cloning

In practice, we would need to have data partitioning and cloning mixed
together for a real-world FDBS and its standalone component systems, to
support multi-feature applications. Thus, this scenario represents the generic
situation of, and the two-dimensional space of data storage scaling. For
example, a component system may involve multiple Kubernetes services for
different DB instances, while each service umbrellas a set of Kubernetes pods
that are clones of a specific DB instance, as illustrated in Fig. 4c.
Correspondingly, this scenario also indicates the needs and opportunities of a
global optimisation, e.g., taking into account the DB containers’ portability,
the data availability/reliability, and the overall query performance, as
explained in the previous scenarios.

##  V Discussion and Conclusions

###  V-A Threat to Validity

The major threat to validity of our FDBS solution is its application
constraint, i.e. it does not allow the end users to input or modify any data.
Therefore, we remind readers to do an applicability analysis before employing
this FDBS solution.

On the other hand, we argue that the constraint has been naturally relaxed to
some extent, for the existence of read-only data everywhere in our normal
life, e.g., the catalog of product types and the customers’ shopping history
in a supermarket [35]. Some applications can completely be based on the read-
only datasets, e.g., the online dictionary888https://dictionary.cambridge.org/
and the postal code lookup wizard999https://website-uat.correos.cl/codigo-
postal. More specifically, by analysing the standard benchmarks for embedded
systems, it is estimated that up to 62% of all the data used by applications
are read-only [5].

Moreover, we can expect further benefits by setting a database to the read-
only mode for read-only data. From the perspective of database administrators,
the overhead and issues concerning transactions and concurrency control such
as locking [36] and multi-version [37] will be avoided, as no locks are needed
for any query from a read-only database. From the perspective of programmers,
the multi-process data access will be simplified, without necessarily
concerning about message passing or shared memory programming [38].

###  V-B Conclusions and Future Work

As part of a recent WebGIS project, we are designing and developing a
federated DB infrastructure to facilitate managing and utilising various and
distributed geospatial data. Given our successful prototyping work, we are
confident to conclude that it is feasible and practical to employ Kubernetes
in FDBS implementations for read-only user queries. It should be noted that
our conclusion does not deny the consensus about the current technical limits
of Kubernetes [3]. We acknowledge that our solution essentially bypasses,
rather than fixes, the challenges of running DBs in Kubernetes and the
complexity of Kubernetes-based federation. However, this lightweight solution
can efficiently satisfy the needs of read-only components in a fully-fledged
FDBS, no matter how the Kubernetes technologies will evolve.

Benefiting from our current research outcomes, we are able to unfold the
future work along two directions. First of all, we will gradually finalise the
Kubernetes-aided FDBS infrastructure along with the development of our WebGIS
project. Then, based on our first-hand experience, we plan to undertake more
formal analyses of the fractal pattern and the fractal object of FDBS, aiming
to develop new theories and/or guidelines for FDBS implementations.

## References

  * [1] D. Abadi, “Data federation and data virtualization never worked in the past but now it’s different,” https://www.starburst.io/blog/data-federation-and-data-virtualization-never-worked-in-the-past-but-now-its-different/, 13 Jul. 2021.
  * [2] Vsupalov, “Should you run your database in Docker?” https://vsupalov.com/database-in-docker/, 2022.
  * [3] B. Good, “To run or not to run a database on Kubernetes: What to consider,” https://cloud.google.com/blog/products/databases/to-run-or-not-to-run-a-database-on-kubernetes-what-to-consider, 3 Jul. 2019.
  * [4] Z. Li, “Long live the image: Container-native data persistence in production,” in _Proc. ICSA-C 2021_. Stuttgart, Germany: IEEE Computer Society, 22-26 Mar. 2021, pp. 82–85.
  * [5] G. Vaumourin, D. Thomas, G. Alexandre, and D. Barthou, “Specific read only data management for memory hierarchy optimization,” _ACM SIGBED Rev._ , vol. 11, no. 4, pp. 55–60, Dec. 2014.
  * [6] A. P. Sheth and J. A. Larson, “Federated database systems for managing distributed, heterogeneous, and autonomous databases,” _ACM Comput. Surv._ , vol. 22, no. 3, pp. 183–236, Sept. 1990.
  * [7] L. G. Azevedo, E. F. de Souza Soares, R. Souza, and M. F. Moreno, “Modern federated database systems: An overview,” in _Proc. ICEIS 2020_. Prague, Czech Republic: SciTePress, 5-7 May 2020, pp. 276–283.
  * [8] M. Butenuth, G. v.Gösseln, M. Tiedge, C. Heipke, U. Lipeck, and M. Sester, “Integration of heterogeneous geospatial data in a federated database,” _ISPRS J. Photogramm. Remote Sens._ , vol. 62, no. 5, pp. 328–346, Oct. 2007\.
  * [9] F. Faticanti, D. Santoro, S. Cretti, and D. Siracusa, “An application of Kubernetes cluster federation in fog computing,” in _Proc. ICIN 2021_. Paris, France: IEEE Press, 01-04 Mar. 2021, pp. 89–91.
  * [10] Y. Kim and Y. Kim, “A design of policy-based scheduling for federated multi-clusters,” in _Proc. ICTC 2021_. Jeju Island, Korea: IEEE Press, 20-22 Oct. 2021, pp. 1885–1888.
  * [11] L. Larsson, H. Gustafsson, C. Klein, and E. Elmroth, “Decentralized Kubernetes federation control plane,” in _Proc. UCC 2020_. Leicester, UK: IEEE Press, 07-10 Dec. 2020, pp. 354–359.
  * [12] A. Heddings, “Should you run a database in Docker?” https://www.cloudsavvyit.com/5414/should-you-run-a-database-in-docker/, 7 Sept. 2020.
  * [13] O. Larsson, “Running databases in a Kubernetes cluster: An evaluation,” Master’s thesis, Umeå Univ., Umeå, Sweden, 2019.
  * [14] H. C. S. Perera, T. S. D. D. Silva, W. M. D. C. Wasala, R. M. P. R. L. Rajapakshe, N. Kodagoda, U. S. S. Samaratunge, and H. H. N. C. Jayanandana, “Database scaling on Kubernetes,” in _Proc. ICAC 2021_. Colombo, Sri Lanka: IEEE Press, 09-11 Dec. 2021, pp. 258–263.
  * [15] W. Delnat, E. Truyen, A. Rafique, D. V. Landuyt, and W. Joosen, “K8-Scalar: A workbench to compare autoscalers for container-orchestrated database clusters,” in _Proc. SEAMS 2018_. Gothenburg, Sweden: ACM Press, 28-29 May 2018, pp. 33–39.
  * [16] E. Truyen, D. V. Landuyt, B. Lagaisse, and W. Joosen, “Performance overhead of container orchestration frameworks for management of multi-tenant database deployments,” in _Proc. SAC 2019_. Limassol, Cyprus: ACM Press, 8-12 Apr. 2019, pp. 156–159.
  * [17] R. Han, “Web GIS in development: From research and teaching perspectives,” in _GIScience Teaching and Learning Perspectives_ , ser. Advances in Geographic Information Science. Springer, 2019, pp. 103–122.
  * [18] Z. Li, “Pipeline WebGIS implementation,” in _Pipeline Spatial Data Modeling and Pipeline WebGIS_. Springer, Cham, 2020, ch. 5, pp. 119–144.
  * [19] V. Fast and F. Hossain, “An alternative to desktop GIS? evaluating the cartographic and analytical capabilities of WebGIS platforms for teaching,” _Cartogr. J._ , vol. 57, no. 2, pp. 175–186, Jun. 2020.
  * [20] M. A. Şahin and M. Yakar, “WebGIS technology and architectures,” _Adv. GIS J._ , vol. 1, no. 1, pp. 22–26, Sept. 2021.
  * [21] A.-X. Zhu, F.-H. Zhao, P. Liang, and C.-Z. Qin, “Next generation of GIS: must be easy,” _Ann. GIS_ , vol. 27, no. 1, pp. 71–86, 2021.
  * [22] M. Vaitis, H. Feidas, P. Symeonidis, V. Kopsachilis, D. Dalaperas, N. Koukourouvli, D. Simos, and S. Taskaris, “Development of a spatial database and web-GIS for the climate of Greece,” _Earth Sci. Inf._ , vol. 12, pp. 97–115, Mar. 2019.
  * [23] J. C. Meyer and A. C. Elster, “A load balancing strategy for computations on large, read-only data sets,” in _Applied Parallel Computing. State of the Art in Scientific Computing_ , ser. Lect. Notes Comput. Sci. Berlin, Heidelberg: Springer, 2007, vol. 4699, pp. 198–207.
  * [24] C. Daly, J. I. Smith, and K. V. Olson, “Mapping atmospheric moisture climatologies across the conterminous United States,” _PLoS ONE_ , vol. 10, no. 10, Oct. 2015, art. no. e0141140.
  * [25] M. Rios and J. Lin, “Distilling massive amounts of data into simple visualizations: Twitter case studies,” _Proc. ICWSM 2012_ , vol. 6, no. 4, pp. 22–25, Jun. 2012.
  * [26] F. Frankel and R. Reid, “Big data: Distilling meaning from data,” _Nature_ , vol. 455, p. 30, Sept. 2008.
  * [27] M. T. Özsu and P. Valduriez, “Database integration — multidatabase systems,” in _Principles of Distributed Database Systems_. Springer, Cham, 2020, pp. 281–347.
  * [28] A. Stojanović, M. Horvat, and Željko Kovačević, “An overview of data integration principles for heterogeneous databases,” in _Proc. MIPRO 2022_. Opatija, Croatia: IEEE Press, 23-27 May 2022, pp. 1111–1116.
  * [29] S. Kim and B. Moon, “Federated database system for scientific data,” in _Proc. SSDBM 2018_. Bozen-Bolzano, Italy: ACM Press, 9-11 Jul. 2018, art. no. 33.
  * [30] J. Dončević and K. Fertalj, “Database integration systems,” in _Proc. MIPRO 2020_. Opatija, Croatia: IEEE Press, 28 Sept. - 02 Oct. 2020, pp. 1617–1622.
  * [31] F. Rossi, V. Cardellini, F. L. Presti, and M. Nardelli, “Geo-distributed efficient deployment of containers with Kubernetes,” _Comput. Commun._ , vol. 159, pp. 161–174, Jun. 2020.
  * [32] S. Wickramasinghe, “Kubernetes multi-clusters: How & why to use them,” https://www.bmc.com/blogs/kubernetes-multi-clusters/, 25 Jun. 2021.
  * [33] N. Hardavellas and I. Pandis, “Intra-query parallelism,” in _Encyclopedia of Database Systems_. Boston, MA: Springer, 2009, pp. 1567–1568.
  * [34] R. Agarwal, G. Juve, and E. Deelman, “Peer-to-peer data sharing for scientific workflows on Amazon EC2,” in _Proc. 2012 SC Companion_. Salt Lake City, UT, USA: IEEE Computer Society, 10-16 Nov. 2012, pp. 82–89.
  * [35] S. Ghilardi, A. Gianola, M. Montali, and A. Rivkin, “Petri net-based object-centric processes with read-only data,” _Inf. Syst._ , 2022, in press.
  * [36] T. Kyte and D. Kuhn, “Locking and issues,” in _Oracle Database Transactions and Locking Revealed_. Berkeley, CA: Apress, Oct. 2014, pp. 7–28.
  * [37] J. M. Faleiro and D. J. Abadi, “Rethinking serializable multiversion concurrency control,” _Proc. VLDB Endow._ , vol. 8, no. 11, pp. 1190––1201, Jul. 2015.
  * [38] R. Butler and C. Pettey, “Shareable, persistent, in-memory, read-only data,” in _Proc. PDPTA 2015_. Las Vegas, NV, USA: CSREA Press, 27-30 Jul. 2015, pp. 41–47.


r\in\\{1,...,R\\}\quad\text{or}\quad{\mathcal{E}}^{\sf{A}}_{r}\subset{\sf{Sym}_{0}(3)},\quad\forall
r\in\\{1,...,R\\}.$ (5.12)

However, the presented proof extends to other problems that can be formulated
in the form of equation (5.1), such as thermoelastic or piecoelectricity
problems [69, §9]. With the goal of using CLMs as building blocks in a DMN
architecture, we are interested in whether there are particular choices of the
layering directions $\mbox{\boldmath$n$}_{r}$ and the rank $R$ of the CLM for
which the effective properties of a CLM are always non-singular, i.e., the
non-singularity condition (5.11) is satisfied. For incompressible suspensions
of rigid fibers, we study this question for CLMs with a rigid core material
$m_{1}$ and an incompressible coating material $m_{2}$.

####  A.2 Coated layered materials with incompressible coating and rigid core

For applications involving rigid inclusions in incompressible media, we
consider CLMs with an incompressible coating material $m_{2}$ and a rigid core
material $m_{1}$. Therefore, the spaces
${\mathcal{E}}^{\sf{A}}_{r}\subset{\sf{Sym}_{0}(3)}$ have the form

${\mathcal{E}}^{\sf{A}}_{r}=\\{\mbox{\boldmath$B$}\in{\sf{Sym}_{0}(3)}\quad|\quad\mbox{\boldmath$B$}\cdot(\mbox{\boldmath$n$}_{r}\otimes_{\sf{s}}\mbox{\boldmath$a$})=0,\quad\forall\mbox{\boldmath$a$}\in\mathds{R}^{3}\\},$
(5.13)

with the dimensions of the spaces ${{\mathcal{E}}^{\sf{A}}_{r}}$ and
${\sf{Sym}_{0}(3)}$ given by

$\dim({\mathcal{E}}^{\sf{A}}_{r})=3,\quad\text{and}\quad\dim({\sf{Sym}_{0}(3)})=5.$
(5.14)

Because the dimension
$\dim({\mathcal{E}}^{\sf{A}}_{1}+{\mathcal{E}}^{\sf{A}}_{2})$ is bounded by
the dimension of the space ${\sf{Sym}_{0}(3)}$, such that

$\dim({\mathcal{E}}^{\sf{A}}_{1}+{\mathcal{E}}^{\sf{A}}_{2})\leq 5,$ (5.15)

it follows from the dimension of the intersection of the two spaces
${\mathcal{E}}^{\sf{A}}_{1}$ and ${\mathcal{E}}^{\sf{A}}_{2}$

$\dim({\mathcal{E}}^{\sf{A}}_{1}\cap{\mathcal{E}}^{\sf{A}}_{2})=\dim({\mathcal{E}}^{\sf{A}}_{1})+\dim({\mathcal{E}}^{\sf{A}}_{2})-\dim({\mathcal{E}}^{\sf{A}}_{1}+{\mathcal{E}}^{\sf{A}}_{2}),$
(5.16)

that

$\dim({\mathcal{E}}^{\sf{A}}_{1}\cap{\mathcal{E}}^{\sf{A}}_{2})\geq 3+3-5=1.$
(5.17)

In other words, the intersection of the spaces ${\mathcal{E}}^{\sf{A}}_{1}$
and ${\mathcal{E}}^{\sf{A}}_{2}$ is at least one dimensional. Consequently,
two layering directions are not sufficient to satisfy the condition (5.11)
Besides the required number of layerings, we are also interested in whether
there are restrictions on the angles between the layering directions. Suppose
that one layering direction is orthogonal to the other two. We discuss the
case that the direction $\mbox{\boldmath$n$}_{3}$ is orthogonal to the normals
$\mbox{\boldmath$n$}_{1}$ and $\mbox{\boldmath$n$}_{2}$. The other cases work
similarly via permuting the indices. Then it holds that

$\mbox{\boldmath$n$}_{3}\cdot\mbox{\boldmath$n$}_{1}=0,\quad\text{and}\quad\mbox{\boldmath$n$}_{3}\cdot\mbox{\boldmath$n$}_{2}=0,$
(5.18)

and the intersection
${\mathcal{E}}^{\sf{A}}_{1}\cap{\mathcal{E}}^{\sf{A}}_{2}\cap{\mathcal{E}}^{\sf{A}}_{3}$
does not only contain the zero element $0$. Hence, the condition (5.11) is
violated. To show this, we consider the alternative description of the spaces
${\mathcal{E}}^{\sf{A}}_{r}$

${\mathcal{E}}^{\sf{A}}_{r}=\left\\{\mbox{\boldmath$B$}\in{\sf{Sym}_{0}(3)}\quad|\quad\mbox{\boldmath$B$}\mbox{\boldmath$n$}_{r}=\alpha\mbox{\boldmath$n$}_{r}\quad\text{for
some}\quad\alpha\in\mathds{R}\right\\}$ (5.19)

which is equivalent to equation (5.13) and characterizes the space
${\mathcal{E}}^{\sf{A}}_{r}$ via all tensors
$\mbox{\boldmath$B$}\in{\mathcal{E}}^{\sf{A}}_{r}$ that have the layering
direction $\mbox{\boldmath$n$}_{r}$ as an eigenvector. Then the tensor

$\mbox{\boldmath$B$}=\mbox{\boldmath$n$}_{1}\otimes\mbox{\boldmath$n$}_{1}+\mbox{\boldmath$m$}_{2}\otimes\mbox{\boldmath$m$}_{2}-2\mbox{\boldmath$n$}_{3}\otimes\mbox{\boldmath$n$}_{3},$
(5.20)

where the layering direction $\mbox{\boldmath$m$}_{2}$ is constructed by
orthogonalization, such that

$\mbox{\boldmath$m$}_{2}=\mbox{\boldmath$n$}_{2}-(\mbox{\boldmath$n$}_{1}\cdot\mbox{\boldmath$n$}_{2})\mbox{\boldmath$n$}_{1},$
(5.21)

is an element of the intersection
${\mathcal{E}}^{\sf{A}}_{1}\cap{\mathcal{E}}^{\sf{A}}_{2}\cap{\mathcal{E}}^{\sf{A}}_{3}$.
This is true because it holds that

$\tr(\mbox{\boldmath$B$})=0,\quad\mbox{\boldmath$B$}\mbox{\boldmath$n$}_{1}=\mbox{\boldmath$n$}_{1},\quad\mbox{\boldmath$B$}\mbox{\boldmath$n$}_{2}=\mbox{\boldmath$n$}_{2},\quad\mbox{\boldmath$B$}\mbox{\boldmath$n$}_{3}=\mbox{\boldmath$n$}_{3},$
(5.22)

and therefore condition (5.11) is violated. In other words, the effective
properties $\bar{{\mathbb{A}}}$ of a rank-$3$ CLM with incompressible coating
and rigid core, where one layering direction $\mbox{\boldmath$n$}_{3}$ is
orthogonal to the other two layering directions $\mbox{\boldmath$n$}_{1}$ and
$\mbox{\boldmath$n$}_{2}$, is always singular. Particularly, if all three
layering directions are mutually orthogonal, the effective properties
$\bar{{\mathbb{A}}}$ of a rank-$3$ CLM are singular.

In contrast, let the three layering directions be mutually non-orthogonal and
mutually non-collinear, i.e.,

$0<|\mbox{\boldmath$n$}_{1}\cdot\mbox{\boldmath$n$}_{2}|<1,\quad
0<|\mbox{\boldmath$n$}_{1}\cdot\mbox{\boldmath$n$}_{3}|<1,\quad
0<|\mbox{\boldmath$n$}_{2}\cdot\mbox{\boldmath$n$}_{3}|<1.$ (5.23)

We consider an element $B$ in the intersection
${\mathcal{E}}^{\sf{A}}_{1}\cap{\mathcal{E}}^{\sf{A}}_{2}\cap{\mathcal{E}}^{\sf{A}}_{3}$
and wish to show that the tensor $B$ vanishes, such that the non-singularity
condition (5.11) is satisfied. Because the tensor $B$ is symmetric, its
eigenvectors corresponding to distinct eigenvalues are orthogonal. Thus, if
the eigenvalues were distinct, the layering directions would need to be
orthogonal. However, this contradicts our assumption (5.23). Therefore, the
tensor $B$ has a single eigenvalue $\alpha$ with the corresponding eigenspace
$\mathds{R}^{3}$, i.e., the tensor $B$ attains the form

$\mbox{\boldmath$B$}=\alpha\mbox{\boldmath$I$},\quad\alpha\in\mathds{R}.$
(5.24)

Additionally, because the trace of the tensor $B$ vanishes, i.e.,
$\tr(\mbox{\boldmath$B$})=0$, it follows that the eigenvalue $\alpha$ is zero.
Consequently, the tensor $B$ must vanish, the non-singularity condition (5.11)
is satisfied, and the effective properties $\bar{{\mathbb{A}}}$ of a rank-$3$
CLM with an incompressible coating material $m_{2}$ and a rigid core material
$m_{1}$ are non-singular, if the three layering directions are mutually non-
orthogonal and non-collinear.

## References

  * [1] Y. Swolfs, “Perspective for fibre-hybrid composites in wind energy applications,” Materials, vol. 10, no. 11, p. 1281, 2017.
  * [2] A. Wazeer, A. Das, C. Abeykoon, A. Sinha, and A. Karmakar, “Composites for electric vehicles and automotive sector: A review,” Green Energy and Intelligent Transportation, vol. 2, no. 1, p. 100043, 2023.
  * [3] D. M. Botín-Sanabria, A.-S. Mihaita, R. E. Peimbert-García, M. A. Ramírez-Moreno, R. A. Ramírez-Mendoza, and J. d. J. Lozoya-Santos, “Digital twin technology challenges and applications: A comprehensive review,” Remote Sensing, vol. 14, no. 6, p. 1335, 2022.
  * [4] F. Henning, L. Kärger, D. Dörr, F. J. Schirmaier, J. Seuffert, and A. Bernath, “Fast processing and continuous simulation of automotive structural composite components,” Composites Science and Technology, vol. 171, pp. 261–279, 2019.
  * [5] J. Görthofer, N. Meyer, T. D. Pallicity, L. Schöttl, A. Trauth, M. Schemmann, M. Hohberg, P. Pinter, P. Elsner, F. Henning, A. Hrymak, T. Seelig, K. Weidenmann, L. Kärger, and T. Böhlke, “Virtual process chain of sheet molding compound: Development, validation and perspectives,” Composites Part B: Engineering, vol. 169, pp. 133–147, 2019.
  * [6] N. Meyer, S. Gajek, J. Görthofer, A. Hrymak, L. Kärger, F. Henning, M. Schneider, and T. Böhlke, “A probabilistic virtual process chain to quantify process-induced uncertainties in sheet molding compounds,” Composites Part B: Engineering, vol. 249, p. 110380, 2023.
  * [7] J. Castro and G. Tomlinson, “Predicting molding forces in SMC compression molding,” Polymer Engineering & Science, vol. 30, no. 24, pp. 1568–1573, 1990.
  * [8] V. Goodship, ARBURG practical guide to injection moulding.  Shawbury, United Kingdom: Smithers Rapra, 2017.
  * [9] H.-C. Tseng, R.-Y. Chang, and C.-H. Hsu, “Predictions of fiber concentration in injection molding simulation of fiber-reinforced composites,” Journal of Thermoplastic Composite Materials, vol. 31, no. 11, pp. 1529–1544, 2018.
  * [10] T. Karl, D. Gatti, T. Böhlke, and B. Frohnapfel, “Coupled simulation of flow-induced viscous and elastic anisotropy of short-fiber reinforced composites,” Acta Mechanica, vol. 232, no. 6, pp. 2249–2268, 2021.
  * [11] S. Mortazavian and A. Fatemi, “Effects of fiber orientation and anisotropy on tensile strength and elastic modulus of short fiber reinforced polymer composites,” Composites part B: engineering, vol. 72, pp. 116–129, 2015\.
  * [12] T. Böhlke, F. Henning, A. N. Hrymak, L. Kärger, K. Weidenmann, and J. T. Wood, Continuous–Discontinuous Fiber-Reinforced Polymers: An Integrated Engineering Approach.  Carl Hanser Verlag GmbH Co KG, 2019.
  * [13] T. Karl and T. Böhlke, “Unified mean-field modeling of viscous short-fiber suspensions and solid short-fiber reinforced composites,” Archive of Applied Mechanics, vol. 92, no. 12, pp. 3695–3727, 2022.
  * [14] M. Sepehr, P. J. Carreau, M. Moan, and G. Ausias, “Rheological properties of short fiber model suspensions,” Journal of Rheology, vol. 48, no. 5, pp. 1023–1048, 2004.
  * [15] S. M. Dinh and R. C. Armstrong, “A rheological equation of state for semiconcentrated fiber suspensions,” Journal of Rheology, vol. 28, no. 3, pp. 207–227, 1984.
  * [16] M. M. Cross, “Rheology of Non-Newtonian fluids: a new flow equation for pseudoplastic systems,” Journal of Colloid Science, vol. 20, no. 5, pp. 417–437, 1965.
  * [17] B. Sterr, D. Wicht, A. Hrymak, M. Schneider, and T. Böhlke, “Homogenizing the viscosity of shear-thinning fiber suspensions with an FFT-based computational method,” Journal of Non-Newtonian Fluid Mechanics, vol. 321, p. 105101, 2023.
  * [18] M. L. Williams, R. F. Landel, and J. D. Ferry, “The temperature dependence of relaxation mechanisms in amorphous polymers and other glass-forming liquids,” Journal of the American Chemical society, vol. 77, no. 14, pp. 3701–3707, 1955.
  * [19] R. B. Pipes, J. Hearle, A. Beaussart, A. Sastry, and R. Okine, “A constitutive relation for the viscous flow of an oriented fiber assembly,” Journal of Composite Materials, vol. 25, no. 9, pp. 1204–1217, 1991.
  * [20] J. D. Goddard, “Tensile stress contribution of flow-oriented slender particles in Non-Newtonian fluids,” Journal of Non-Newtonian Fluid Mechanics, vol. 1, no. 1, pp. 1–17, 1976.
  * [21] J. Goddard, “The stress field of slender particles oriented by a Non-Newtonian extensional flow,” Journal of Fluid Mechanics, vol. 78, no. 1, pp. 177–206, 1976.
  * [22] B. Souloumiac and M. Vincent, “Steady shear viscosity of short fibre suspensions in thermoplastics,” Rheologica Acta, vol. 37, no. 3, pp. 289–298, 1998.
  * [23] C. Mobuchon, P. J. Carreau, M.-C. Heuzey, M. Sepehr, and G. Ausias, “Shear and extensional properties of short glass fiber reinforced polypropylene,” Polymer Composites, vol. 26, no. 3, pp. 247–264, 2005.
  * [24] J. Férec, E. Bertevas, B. C. Khoo, G. Ausias, and N. Phan-Thien, “The effect of shear-thinning behaviour on rod orientation in filled fluids,” Journal of Fluid Mechanics, vol. 798, pp. 350–370, 2016.
  * [25] J. Ericksen, “Transversely isotropic fluids,” Colloid and Polymer Science, vol. 173, pp. 117–122, 1960.
  * [26] C. L. Tucker III, “Flow regimes for fiber suspensions in narrow gaps,” Journal of Non-Newtonian fluid mechanics, vol. 39, no. 3, pp. 239–268, 1991\.
  * [27] R. B. Pipes, “Anisotropic viscosities of an oriented fiber composite with a power-law matrix,” Journal of Composite Materials, vol. 26, no. 10, pp. 1536–1552, 1992.
  * [28] D. Cofffin and R. B. Pipes, “Constitutive relationships for aligned discontinuous fibre composites,” Composites Manufacturing, vol. 2, no. 3-4, pp. 141–146, 1991.
  * [29] R. B. Pipes, D. W. Coffin, S. F. Shuler, and P. Šimáček, “Non-Newtonian constitutive relationships for hyperconcentrated fiber suspensions,” Journal of Composite Materials, vol. 28, no. 4, pp. 343–351, 1994.
  * [30] D. Binding, “Capillary and contraction flow of long-(glass) fibre filled polypropylene,” Composites Manufacturing, vol. 2, no. 3-4, pp. 243–252, 1991.
  * [31] A. J. Favaloro, H.-C. Tseng, and R. B. Pipes, “A new anisotropic viscous constitutive model for composites molding simulation,” Composites Part A: Applied Science and Manufacturing, vol. 115, pp. 112–122, 2018.
  * [32] H.-C. Tseng, “A constitutive equation for fiber suspensions in viscoelastic media,” Physics of Fluids, vol. 33, no. 7, p. 071702, 2021.
  * [33] M. Khan, R. V. More, and A. M. Ardekani, “A constitutive model for sheared dense fiber suspensions,” Physics of Fluids, vol. 35, no. 1, 2023.
  * [34] C. Schelleis, A. Hrymak, and F. Henning, “Optimizing processing parameters for glass fiber reinforced polycarbonate lft-d composites,” Society for the Advancement of Material and Process Engineering Europe Conference, 2023\.
  * [35] A. R. Eschbach, “Dynamic shear rheometer and method,” Dec. 21 1993.  US Patent 5,271,266.
  * [36] O. Švec, J. Skoček, H. Stang, M. R. Geiker, and N. Roussel, “Free surface flow of a suspension of rigid particles in a non-Newtonian fluid: A lattice Boltzmann approach,” Journal of Non-Newtonian Fluid Mechanics, vol. 179, pp. 32–42, 2012.
  * [37] J. Domurath, G. Ausias, J. Férec, and M. Saphiannikova, “Numerical investigation of dilute suspensions of rigid rods in power-law fluids,” Journal of Non-Newtonian Fluid Mechanics, vol. 280, p. 104280, 2020.
  * [38] R. Bertóti, D. Wicht, A. Hrymak, M. Schneider, and T. Böhlke, “A computational investigation of the effective viscosity of short-fiber reinforced thermoplastics by an FFT-based method,” European Journal of Mechanics-B/Fluids, vol. 90, pp. 99–113, 2021.
  * [39] M. Schneider, “A review of nonlinear FFT-based computational homogenization methods,” Acta Mechanica, vol. 232, no. 6, pp. 2051–2100, 2021.
  * [40] T. Kanit, S. Forest, I. Galliet, V. Mounoury, and D. Jeulin, “Determination of the size of the representative volume element for random composites: statistical and numerical approach,” International Journal of solids and structures, vol. 40, no. 13-14, pp. 3647–3679, 2003.
  * [41] J. Renard and M. Marmonier, “Etude de l’initiation de l’endommagement dans la matrice d’un matériau composite par une méthode d’homogénéisation,” La Recherche aérospatiale, no. 6, pp. 43–51, 1987.
  * [42] F. Feyel, “A multilevel finite element method (fe2) to describe the response of highly non-linear structures using generalized continua,” Computer Methods in Applied Mechanics and Engineering, vol. 192, no. 28-30, pp. 3233–3244, 2003.
  * [43] J. Spahn, H. Andrä, M. Kabel, and R. Müller, “A multiscale approach for modeling progressive damage of composite materials using fast Fourier transforms,” Computer Methods in Applied Mechanics and Engineering, vol. 268, pp. 871–883, 2014.
  * [44] J. Kochmann, S. Wulfinghoff, S. Reese, J. R. Mianroodi, and B. Svendsen, “Two-scale FE–FFT-and phase-field-based computational modeling of bulk microstructural evolution and macroscopic material behavior,” Computer Methods in Applied Mechanics and Engineering, vol. 305, pp. 89–110, 2016.
  * [45] J. Kochmann, L. Ehle, S. Wulfinghoff, J. Mayer, B. Svendsen, and S. Reese, “Efficient multiscale FE-FFT-based modeling and simulation of macroscopic deformation processes with non-linear heterogeneous microstructures,” Multiscale Modeling of Heterogeneous Structures, pp. 129–146, 2018.
  * [46] S. Gajek, M. Schneider, and T. Böhlke, “An FE–DMN method for the multiscale analysis of short fiber reinforced plastic components,” Computer Methods in Applied Mechanics and Engineering, vol. 384, p. 113952, 2021.
  * [47] N. R. Ashwin, Z. Cao, N. Muralidhar, D. Tafti, and A. Karpatne, “Deep learning methods for predicting fluid forces in dense particle suspensions,” Powder Technology, vol. 401, p. 117303, 2022.
  * [48] N. R. Ashwin, D. Tafti, N. Muralidhar, and Z. Cao, “Physics informed deep learning for flow and force predictions in dense ellipsoidal particle suspensions,” Powder Technology, p. 119684, 2024.
  * [49] O. Ronneberger, P. Fischer, and T. Brox, “U-net: Convolutional networks for biomedical image segmentation,” in Medical image computing and computer-assisted intervention–MICCAI 2015: 18th international conference, Munich, Germany, October 5-9, 2015, proceedings, part III 18, pp. 234–241, Springer, 2015.
  * [50] M. Boodaghidizaji, M. Khan, and A. M. Ardekani, “Multi-fidelity modeling to predict the rheological properties of a suspension of fibers using neural networks and Gaussian processes,” Physics of Fluids, vol. 34, no. 5, 2022\.
  * [51] Sterr, Benedikt and Hrymak, Andrew and Schneider, Matti and Böhlke, Thomas, “Machine learning assisted discovery of effective viscous material laws for shear-thinning fiber suspensions,” Computational Mechanics, pp. 1–19, 2024.
  * [52] Z. Liu, C. Wu, and M. Koishi, “A deep material network for multiscale topology learning and accelerated nonlinear modeling of heterogeneous materials,” Computer Methods in Applied Mechanics and Engineering, vol. 345, pp. 1138–1168, 2019.
  * [53] Z. Liu and C. Wu, “Exploring the 3D architectures of deep material network in data-driven multiscale mechanics,” Journal of the Mechanics and Physics of Solids, vol. 127, pp. 20–46, 2019.
  * [54] S. Gajek, M. Schneider, and T. Böhlke, “On the micromechanics of deep material networks,” Journal of the Mechanics and Physics of Solids, vol. 142, p. 103984, 2020.
  * [55] J. Köbler, M. Schneider, F. Ospald, H. Andrä, and R. Müller, “Fiber orientation interpolation for the multiscale analysis of short fiber reinforced composite parts,” Computational Mechanics, vol. 61, pp. 729–750, 2018.
  * [56] Z. Liu, C. Wu, and M. Koishi, “Transfer learning of deep material network for seamless structure–property predictions,” Computational Mechanics, vol. 64, no. 2, pp. 451–465, 2019.
  * [57] T. Huang, Z. Liu, C. Wu, and W. Chen, “Microstructure-guided deep material network for rapid nonlinear material modeling and uncertainty quantification,” Computer Methods in Applied Mechanics and Engineering, vol. 398, p. 115197, 2022.
  * [58] T. Li, “Micromechanics-informed parametric deep material network for physics behavior prediction of heterogeneous materials with a varying morphology,” Computer Methods in Applied Mechanics and Engineering, vol. 419, p. 116687, 2024.
  * [59] S. Gajek, M. Schneider, and T. Böhlke, “An FE-DMN method for the multiscale analysis of thermomechanical composites,” Computational Mechanics, vol. 69, no. 5, pp. 1087–1113, 2022.
  * [60] D. Shin, R. Alberdi, R. A. Lebensohn, and R. Dingreville, “A deep material network approach for predicting the thermomechanical response of composites,” Composites Part B: Engineering, vol. 272, p. 111177, 2024\.
  * [61] A. P. Dey, F. Welschinger, M. Schneider, S. Gajek, and T. Böhlke, “Training deep material networks to reproduce creep loading of short fiber-reinforced thermoplastics with an inelastically-informed strategy,” Archive of Applied Mechanics, vol. 92, no. 9, pp. 2733–2755, 2022.
  * [62] A. P. Dey, F. Welschinger, M. Schneider, S. Gajek, and T. Böhlke, “Rapid inverse calibration of a multiscale model for the viscoplastic and creep behavior of short fiber-reinforced thermoplastics based on Deep Material Networks,” International Journal of Plasticity, vol. 160, p. 103484, 2023\.
  * [63] A. P. Dey, F. Welschinger, M. Schneider, J. Köbler, and T. Böhlke, “On the effectiveness of deep material networks for the multi-scale virtual characterization of short fiber-reinforced thermoplastics under highly nonlinear load cases,” Archive of Applied Mechanics, pp. 1–26, 2024.
  * [64] Z. Liu, “Deep material network with cohesive layers: Multi-stage training and interfacial failure analysis,” Computer Methods in Applied Mechanics and Engineering, vol. 363, p. 112913, 2020.
  * [65] Z. Liu, “Cell division in deep material networks applied to multiscale strain localization modeling,” Computer Methods in Applied Mechanics and Engineering, vol. 384, p. 113914, 2021.
  * [66] L. Wu, L. Adam, and L. Noels, “Micro-mechanics and data-driven based reduced order models for multi-scale analyses of woven composites,” Composite Structures, vol. 270, p. 114058, 2021.
  * [67] V. D. Nguyen and L. Noels, “Interaction-based material network: A general framework for (porous) microstructured materials,” Computer Methods in Applied Mechanics and Engineering, vol. 389, p. 114300, 2022.
  * [68] V. D. Nguyen and L. Noels, “Micromechanics-based material networks revisited from the interaction viewpoint; robust and efficient implementation for multi-phase composites,” European Journal of Mechanics-A/Solids, vol. 91, p. 104384, 2022.
  * [69] G. W. Milton, The Theory of Composites.  SIAM, 2002.
  * [70] M. Kabel, F. Ospald, and M. Schneider, “A model order reduction method for computational homogenization at finite strains on regular grids using hyperelastic laminates to approximate interfaces,” Computer Methods in Applied Mechanics and Engineering, vol. 309, pp. 476–496, 2016.
  * [71] D. G. Edelen, “On the existence of symmetry relations and dissipation potentials,” Archive for Rational Mechanics and Analysis, vol. 51, pp. 218–227, 1973.
  * [72] R. Hill, “Elastic properties of reinforced solids: some theoretical principles,” Journal of the Mechanics and Physics of Solids, vol. 11, no. 5, pp. 357–372, 1963.
  * [73] J. Mandel, “Contribution théorique à l’étude de l’écrouissage et des lois de l’écoulement plastique,” in Applied Mechanics: Proceedings of the Eleventh International Congress of Applied Mechanics Munich (Germany) 1964, pp. 502–509, Springer, 1966.
  * [74] A. B. Owen, “Scrambling Sobol’and Niederreiter–Xing Points,” Journal of Complexity, vol. 14, no. 4, pp. 466–489, 1998.
  * [75] I. Sobol’, “On the distribution of points in a cube and the approximate evaluation of integrals,” USSR Computational Mathematics and Mathematical Physics, vol. 7, no. 4, pp. 86–112, 1967.
  * [76] A. Paszke, S. Gross, F. Massa, A. Lerer, J. Bradbury, G. Chanan, T. Killeen, Z. Lin, N. Gimelshein, L. Antiga, A. Desmaison, A. Kopf, E. Yang, Z. DeVito, M. Raison, A. Tejani, S. Chilamkurthy, B. Steiner, L. Fang, J. Bai, and S. Chintala, “PyTorch: An Imperative Style, High-Performance Deep Learning Library,” in Advances in Neural Information Processing Systems 32, pp. 8024–8035, Curran Associates, Inc., 2019.
  * [77] L. Liu, H. Jiang, P. He, W. Chen, X. Liu, J. Gao, and J. Han, “On the variance of the adaptive learning rate and beyond,” arXiv preprint arXiv:1908.03265, 2019.
  * [78] A. Neumaier, “Solving ill-conditioned and singular linear systems: A tutorial on regularization,” SIAM Review, vol. 40, no. 3, pp. 636–666, 1998.
  * [79] P. Kennedy and R. Zheng, Flow Analysis of Injection Molds.  Munich, Germany: Carl Hanser Verlag GmbH Co KG, 2013.
  * [80] M.-L. Wang, R.-Y. Chang, and C.-H. D. Hsu, Molding simulation: Theory and practice.  Carl Hanser Verlag GmbH Co KG, 2018.
  * [81] K. Kanatani, “Distribution of directional data and fabric tensors,” International Journal of Engineering Science, vol. 22, no. 2, pp. 149–164, 1984\.
  * [82] S. G. Advani and C. L. Tucker III, “The use of tensors to describe and predict fiber orientation in short fiber composites,” Journal of Rheology, vol. 31, no. 8, pp. 751–784, 1987.
  * [83] J. S. Cintra Jr and C. L. Tucker III, “Orthotropic closure approximations for flow-induced fiber orientation,” Journal of Rheology, vol. 39, no. 6, pp. 1095–1122, 1995.
  * [84] J. K. Bauer and T. Böhlke, “Variety of fiber orientation tensors,” Mathematics and Mechanics of Solids, vol. 27, no. 7, pp. 1185–1211, 2022.
  * [85] J. K. Bauer, M. Schneider, and T. Böhlke, “On the phase space of fourth-order fiber-orientation tensors,” Journal of Elasticity, vol. 153, no. 2, pp. 161–184, 2023.
  * [86] M. Schneider, “The sequential addition and migration method to generate representative volume elements for the homogenization of short fiber reinforced plastics,” Computational Mechanics, vol. 59, no. 2, pp. 247–263, 2017.
  * [87] “Ultramid®B3K Polyamide 6 Material data.” https://www.campusplastics.com/campus/de/datasheet/Ultramid%C2%AE+B3K/BASF/20/3a22f000.  Accessed: 2020-09-26.
  * [88] F. H. Harlow and J. E. Welch, “Numerical calculation of time-dependent viscous incompressible flow of fluid with free surface,” The Physics of Fluids, vol. 8, no. 12, pp. 2182–2189, 1965.
  * [89] L. N. Smith and N. Topin, “Super-convergence: Very fast training of neural networks using large learning rates,” in Artificial Intelligence and Machine Learning for Multi-Domain Operations Applications, vol. 11006, pp. 369–386, SPIE, 2019.
  * [90] C. Darken and J. Moody, “Note on learning rate schedules for stochastic optimization,” Advances in Neural Information Processing Systems, vol. 3, 1990.
  * [91] C. Darken, J. Chang, and J. Moody, “Learning rate schedules for faster stochastic gradient search,” in Neural Networks For Signal Processing, vol. 2, pp. 3–12, Citeseer, 1992.
  * [92] S. F. Shuler, D. M. Binding, and R. Byron Pipes, “Rheological behavior of two-and three-phase fiber suspensions,” Polymer Composites, vol. 15, no. 6, pp. 427–435, 1994.
  * [93] H. Cui and J. R. Grace, “Flow of pulp fibre suspension and slurries: A review,” International Journal of Multiphase Flow, vol. 33, no. 9, pp. 921–934, 2007.
  * [94] S. Reich, “A limit theorem for projections,” Linear and Multilinear Algebra, vol. 13, no. 3, pp. 281–290, 1983.