<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Towards Automated Schema Optimization?</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Andre Conrad</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Sebastian Gartner</string-name>
          <email>sebastian.gaertner@accso.de</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Uta Storl</string-name>
          <email>uta.stoerl@fernuni-hagen.de</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Accso Accelerated Solutions GmbH</institution>
          ,
          <addr-line>Darmstadt</addr-line>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>University of Hagen</institution>
          ,
          <country country="DE">Germany</country>
        </aff>
      </contrib-group>
      <fpage>37</fpage>
      <lpage>42</lpage>
      <abstract>
        <p>Non-relational systems are essential to manage large amounts of semi- and/or unstructured data. To use the optimal data storage at a given time, it may be necessary to change the data model during the lifetime of an application. This paper o ers a visionary approach providing an automated schema migration and optimization between di erent NoSQL data stores. By means of data and query analyses, optimizations of all existing cardinalities can be achieved with respect to good query performances with minimal redundancy. First performance measurements prove the increase in performance.</p>
      </abstract>
      <kwd-group>
        <kwd>Schema Migration</kwd>
        <kwd>Schema Optimization</kwd>
        <kwd>Data Migration</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Introduction</title>
      <p>Due to the steady development and appearance of new database technologies as
well as the further development of existing applications and the consequential
changed requirements to a database system used at a given time, it can be
necessary to migrate data between di erent, heterogeneous database systems. If
the data of the source system are migrated without optimizing the schema with
respect to the target system, performance may be a ected.</p>
      <p>For example, missing or restricted join operations in NoSQL systems lead to
performance losses. Otherwise changes in the database schema (e.g. embedding)
can help to improve the performance.</p>
      <p>This paper introduces the concept of a exible migration architecture between
di erent database systems with various data models. Our approach includes an
automated optimization process based on data metrics and query analysis that
allows the identi cation of the best way to embed or reference the data.</p>
      <p>At rst a migration from relational to document stores is presented. This
approach uses an automatic optimization process where the transformation rules
can be modi ed and extended. The contributions of the paper are:
{ A comparison of existing approaches to migrate schema and data between
di erent database models.
{ The proof of concept of a exible migration architecture with an automated
optimization of the schema transformation.
{ First performance analyses to investigate the increase in performance through
optimization.</p>
      <p>This paper is organized as follows: Section 2 presents related work on migration
and optimization processes between di erent database systems. Section 3
describes rst approaches to a concept on the way to an automated and exible
migration process. Section 4 shows performance improvements based on rst
measurements regarding a migration from the relational database system MariaDB
to the document-oriented system of MongoDB. Finally, Section 5 provides the
conclusions as well as an outlook on our further work.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Related Work</title>
      <p>This chapter presents the state of the art on migration and optimization
processes between di erent database systems. After a short introduction of the
di erent approaches a summarizing comparison is given at the end of the chapter
(cf. Table 1).</p>
      <p>
        [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ] describes an algorithm that outputs the order in which related tables can
be aggregated into one large \NoSQL-table" with regard to the optimization of
read queries in a migration from relational to document stores. [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] presents a
process that takes conceptual UML class diagrams and transforms them into
physical models of di erent NoSQL stores using transformation rules and a platform
independent meta model. [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ] describes a semi-autonomous rule-based process
by which a conceptional UML class diagram can be transformed into various
platform speci c models. The class diagram can be edited manually in order to
divide it into multiple regions which describe several physically separated models.
[
        <xref ref-type="bibr" rid="ref6">6</xref>
        ] shows a concept of data and schema migration from relational to document
and column-oriented NoSQL stores that has exible optimization possibilities.
The core is a platform independent meta model that additionally describes data
and query characteristics of the source system. Di erent strategies are provided
to optimize the model with respect to di erent target systems. [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ] describes
the migration of data from relational systems to the document-oriented model
of MongoDB in detail. This includes a semi-autonomous optimization process
against the target model. Note that many-to-many relationships are always
referenced. In [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ] an optimization process is described where several target models
based on transformation heuristics are generated.
      </p>
      <p>Finally, Table 1 summarizes the works considered and o ers a comparison
between di erent properties regarding automated data and schema migration
including optimization processes.</p>
      <p>
        [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ] is one of the few works that o ers a detailed description of the migration
process including schema optimizations. However, they do not provide
optimizations for many-to-many relationships. Therefore, our approach provides exible
and extensible transformation rules regarding di erent target models. We perform
an in-depth analysis of performance critical queries by using multiple quantitative
metrics of existing data. One-into-many and many-into-many embeddings are
also considered.
3
      </p>
    </sec>
    <sec id="sec-3">
      <title>Concept</title>
      <p>
        Our concept is based on the use of a platform independent meta model. We o er
a exible and extensible process for an automated schema and data migration
between all kinds of data stores. A further important goal is the automated
optimization of the schema with respect to the target system using di erent
strategy rules as presented in [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ] as well as the previously collected data metrics
and analysis of the queries in the form of a so-called dependency graph. Fig. 1
shows an overview of the design described.
      </p>
      <p>
        At rst an automatic migration and schema optimization, from relational
to document-oriented stores is considered. The optimization of the schema is
achieved through de-normalization, i.e. embedding certain relationships. In order
to determine the best direction of embedding among many-to-many relationships
as well as the rule-based decision process whether to embed or reference, further
data metrics must be considered, compared to [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ]. Based on these metrics as well
as the cardinalities of concerning relationships, the dependency graph is generated
from the queries. This has the advantage that all previously analyzed queries can
be involved in a later optimization step concerning target system speci c rules.
      </p>
      <p>
        To provide a high degree of exibility and extensibility, the strategy rules can
be described on two levels following the concept from [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ]. On the one hand, those
that are applicable to certain data models, such as the document model and {
on the other hand rules { for speci c systems like MongoDB.
      </p>
      <p>
        Schema extraction and meta model: The step of extracting the physical
data structure from the source database to a platform independent meta model
is an important base for the migration architecture [
        <xref ref-type="bibr" rid="ref4 ref5 ref8">4, 5, 8</xref>
        ]. The description or
      </p>
      <sec id="sec-3-1">
        <title>Queries src DB</title>
      </sec>
      <sec id="sec-3-2">
        <title>Strategy</title>
      </sec>
      <sec id="sec-3-3">
        <title>Rules</title>
      </sec>
      <sec id="sec-3-4">
        <title>Meta Model</title>
        <p>(Schema)</p>
      </sec>
      <sec id="sec-3-5">
        <title>Data</title>
      </sec>
      <sec id="sec-3-6">
        <title>Metrics</title>
      </sec>
      <sec id="sec-3-7">
        <title>Dependency</title>
      </sec>
      <sec id="sec-3-8">
        <title>Graph</title>
      </sec>
      <sec id="sec-3-9">
        <title>Optimized</title>
      </sec>
      <sec id="sec-3-10">
        <title>Schema target DB</title>
        <p>development of a suitable meta model would, however, go beyond the scope of
this paper.</p>
        <p>Data metrics and query analysis: An important point of the schema
optimization are the metrics that are collected in the form of a data analysis, referred
to the source database. The following metrics are used here:
{ avgEntitySize: Average size of entities within an entity type.
{ entityCount: Number of entities within an entity type.
{ rCountfMin,Max,Avgg: Concerning the relationships between two entity
types, the minimal, maximal and average number of \connections".
The goal of the analysis of queries is to generate the dependency graph to show
the dependencies between the entity types involved in the queries. Algorithm 1
illustrates the process for generating this graph. Note that currently no queries
can be optimized that have joins over more than two entity types while at the
same time more than one entity type is a ected by lter operations.</p>
        <p>Algorithm 1: Generation of the dependency graph.</p>
        <p>Input : Set of queries Q; Data metrics M ; Schema S
0utput : Set of digraphs G; dependency graph DG
Strategy rules: The structure of the physically target model is nally de ned
by rules related to speci c target systems. These make use of the data metrics,
user de ned thresholds of those metrics, the cardinalities of the relationships,
and the dependency graph to describe the transformations of the schema for an
optimal performance. In the following the early approaches of transformation
rules for a migration to the document-oriented model of MongoDB are shown:
{ R1 (doc): 8 relationships r 2 S : r 2= DG ! REF
{ R2 (doc): 8 relationships r 2 S : r 2 DG ! EMBED
{ R3 (mongo): 8 edges 2 DG : direction is one-into-x ! EMBED
{ R4 (mongo): 8 edges 2 DG : direction is many-into-x !
if mCond = true EMBED else ! REF
with mCond : (rCountMax(ej) &lt; rCountMaxthold) ^
(rCountMax(ej) avgEntitySize(ej) &lt; rCountMaxthold avgEntitySizethold)
Note that the database system speci c rules R3 and R4 are preferred to the
general rule R2.
4</p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>First Evaluations</title>
      <p>
        First measurements were performed to prove an increase in performance with
the example of a migration from MariaDB to MongoDB. Therefore, a part of the
data model of the multi-model benchmark UniBench [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ] and the three provided
data sets1 with di erent scale factors (SF1, SF10 and SF30 ) were used. As a
rst example, optimizations have been made for following SQL query:
SELECT c.firstName, c.lastName, f.feedback FROM customer c, feedback f, product p
WHERE c.id = f.customerId AND f.asin = p.asin AND p.title = Katadyn TRK Drip Ceradyn... ;
1 https://github.com/HY-UDBMS/UniBench/releases
102
)
g
o
l,
sm101
(
e
m
i
      </p>
      <p>T100
a b c</p>
      <p>SF1
a b c</p>
      <p>SF10</p>
    </sec>
    <sec id="sec-5">
      <title>Conclusion and Outlook</title>
      <p>
        This paper presents a visionary approach to a exible and extensible concept
towards schema and data migration between di erent heterogeneous database
systems, including automated optimization processes. We rst describe strategy
rules using an example for a migration from relational to document-oriented
stores. In contrast to previous work like [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ], the optimization process presented
in this paper considers one-into-many and many-into-many embeddings.
      </p>
      <p>The rst measurements taken show a performance improvement in comparison
to a non-optimized migration.</p>
      <p>
        Our future work aims at the extension and in-depth evaluation of our
automated schema optimization approach to all NoSQL data models, including
multi-model systems [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ].
      </p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Abdelhedi</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          , et al.:
          <article-title>UMLtoNoSQL: Automatic transformation of conceptual schema to NoSQL databases</article-title>
          .
          <source>In: AICCSA'17</source>
          .
          <string-name>
            <surname>IEEE</surname>
          </string-name>
          (
          <year>2017</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Daniel</surname>
          </string-name>
          , G.,
          <string-name>
            <surname>Gomez</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Cabot</surname>
          </string-name>
          , J.: UMLto[no]
          <article-title>SQL: Mapping conceptual schemas to heterogeneous datastores</article-title>
          .
          <source>In: RCIS'19</source>
          .
          <string-name>
            <surname>IEEE</surname>
          </string-name>
          (
          <year>2019</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Jia</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Zhao</surname>
            ,
            <given-names>X.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wang</surname>
            ,
            <given-names>Z.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gong</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ding</surname>
          </string-name>
          , G.:
          <article-title>Model Transformation and Data Migration from Relational Database to MongoDB</article-title>
          . In: Big Data'
          <fpage>16</fpage>
          .
          <string-name>
            <surname>IEEE</surname>
          </string-name>
          (
          <year>2016</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Klettke</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          , Storl, U.,
          <string-name>
            <surname>Scherzinger</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Schema Extraction and Structural Outlier Detection for JSON-based NoSQL Data Stores</article-title>
          . In: BTW'
          <fpage>15</fpage>
          .
          <string-name>
            <surname>GI</surname>
          </string-name>
          (
          <year>2015</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Klettke</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          , Storl, U.,
          <string-name>
            <surname>Shenavai</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Scherzinger</surname>
            ,
            <given-names>S.:</given-names>
          </string-name>
          <article-title>NoSQL schema evolution and big data migration at scale</article-title>
          .
          <source>In: SCDM'16</source>
          .
          <string-name>
            <surname>IEEE</surname>
          </string-name>
          (
          <year>2016</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Liang</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lin</surname>
            ,
            <given-names>Y.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ding</surname>
          </string-name>
          , G.:
          <article-title>Mid-model Design Used in Model Transition and Data Migration between Relational Databases and NoSQL Databases</article-title>
          . In: SmartCity'
          <fpage>15</fpage>
          .
          <string-name>
            <surname>IEEE</surname>
          </string-name>
          (
          <year>2015</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Lu</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Holubova</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          <article-title>: Multi-model Databases: A New Journey to Handle the Variety of Data</article-title>
          .
          <source>ACM Comput. Surv</source>
          . (
          <year>2019</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Mali</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Atigui</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Azough</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Travers</surname>
          </string-name>
          , N.:
          <article-title>ModelDrivenGuide: An Approach for Implementing NoSQL Schemas</article-title>
          .
          <source>In: DEXA'20</source>
          . Springer (
          <year>2020</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Zhang</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lu</surname>
          </string-name>
          , J.:
          <article-title>Holistic evaluation in multi-model databases benchmarking</article-title>
          .
          <source>Distributed and Parallel Databases</source>
          (
          <year>2019</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Zhao</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lin</surname>
            ,
            <given-names>Q.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Li</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Li</surname>
            ,
            <given-names>Z.</given-names>
          </string-name>
          :
          <article-title>Schema Conversion Model of SQL Database to NoSQL</article-title>
          . In: P2P, Parallel, Grid, Cloud and Internet Computing'
          <fpage>14</fpage>
          .
          <string-name>
            <surname>IEEE</surname>
          </string-name>
          (
          <year>2014</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>