Brice Chardin

Henri Bauer

Michael Richard

Abir

Amna

Anh Anaïs

Chourouk, Fatma, Houssameddine, Ibrahim, Ishaq, Issam Khe- Didja Toan

Abril, Gad, Gledys Anita Laura

Amin Abdallah Khelil

Jorge Mesmoudi

Ladjel Galicia

Bellatreche

Exgraf

Many thanks to everyone for all the shared moments in which we exchanged ideas of our academic works and for the diverse conversations

Table of Contents

Introduction Context

Nowadays, we live in a hyper-connected world in which large amounts of data and knowledge are issued from several providers such as social media, mobile devices, e-commerce, sensors, the Internet of Things, and many others. Much of this data is produced and available on the Internet. To date, the Web holds more than 1.8 billion websites 1 and its size is steadily expanding. The data on the Web is characterized, among others, by its volume (e.g., 4PB of data created by Facebook daily), variety of sources with different formats (e.g., text, tables, blog posts, tweets, pictures, videos, etc.), veracity, where the following issues have to be dealt: data origin, authenticity, uncertainly, imprecision, completeness, data quality, ambiguity, etc. and velocity (the fast generation of data must correspond to the speed of its processing). The information and knowledge associated to this data, if well prepared, can be valuable to consumers (companies, governments, private users, etc.) who can obtain relevant knowledge and eventually useful wisdom. However, the availability of the data on the Web does not imply its direct and straightforward exploitation. Tim Berners-Lee, the inventor of the World Wide Web, was aware of this since the mid-1990s. His vision was that computers could manipulate and, more importantly, interpret the information published on the Web. The concept flourished in the following years and the Semantic Web emerged from this vision. It seeks to organize the Web, composed of hyperlinked documents and resources, based on semantic annotators described and formalized in ontologies. The presence of ontologies offers reasoning capabilities over this data. These annotations let different actors such as scientific communities, companies, governments, end-users, etc. to link, exchange, and share data on the Web.

To satisfy these noble objectives, the data on the Web must be represented and queryable in an intuitive and clear way. With this motivation in mind, the World Wide Web Consortium (W3C) led many efforts to specify, develop and deploy guidelines, data models, and languages that lay the foundations for the semantic interconnection of Web data. Among the set of guidelines, the W3C published a recommendation [W3C04] presenting some principles, constraints, and good practices for the core design components on the Web. In this document, the W3C established how to identify Web resources using a single global identifier: the URI (Unique Resource Identifier). URIs, whose generalization in IRIs (International Resource Identifiers) was defined later in [W3C08], are the base component of the Semantic Web architecture [START_REF]Representing knowledge in the semantic web[END_REF]. When it comes to data models for the Semantic Web, the W3C proposed and largely promoted the Resource Description Framework (RDF) [START_REF] Lanthaler | RDF 1.1 concepts and abstract syntax[END_REF] to express information about resources. This data model is the cornerstone of other W3C's models and languages such as (i) RDF Schema (RDFS) [START_REF] Guha | RDF schema 1.1[END_REF] providing classes and vocabularies to describe groups of related resources and their relationships, (ii) SKOS (Simple Knowledge Organization System) [START_REF] Bechhofer | Skos simple knowledge organization system[END_REF] model to represent knowledge systems like taxonomies and classification schemas, and (iii) the Web Ontology Language (OWL) [START_REF]OWL 2 web ontology language[END_REF] giving means to define and represent ontologies.

All the previous models and languages are built using RDF triples. A triple is the smallest unit of data in RDF. A triple models a single statement about resources with the following structure ⟨subject, predicate, object⟩. It indicates that a relationship identified by the predicate (also known as property) holds between the subject and the object depicting Web resources (things, documents, concepts, numbers, strings, etc.).

Example 1. The statement "Airbus builds aircrafts" can be represented by a triple as ⟨Airbus, builds, Aircraf t⟩ 2 . This triple can be represented logically as a graph where two nodes (subject and object) are joined with a directed arc (predicate) as shown in Figure 1a.

Besides, the interconnection characteristic gives RDF the ability to link triples from different datasets via their IRIs. The result of merging triples constitutes a Knowledge Graph (KG). For instance, our triple ⟨Airbus , builds, Aircraf t⟩ can be easily linked to ⟨Guillaume, works in, Airbus⟩ 3 through the predicate works in (Figure 1a).

To query KGs and RDF datasets, the W3C defined SPARQL [START_REF] Seaborne | SPARQL 1.1 overview[END_REF] as the standard query language for RDF. SPARQL allows expressing queries across diverse datasets. The simpler SPARQL queries are those formed as a conjunction of triple patterns (known as Basic Graph Patterns BGP ). Triple patterns are similar to RDF triples except that the subject, predicate, or object may be a variable.

Example 2. The query in Figure 1b asks for all the engineers working at the Airbus company. The solution of this query is a subgraph of the queried graph(s) in which the variable terms are mapped to the values of the resulting subgraph. Processing a SPARQL query can be viewed as a subgraph matching problem. The results for the previous query are the mappings of ?x → <http://example.org/Guillaume> and ?y → <http:// example.org/Engineer>.

The popularity of RDF is due to its flexibility, simplicity, and availability of a query language. Therefore, several organizations and governments spent a lot of effort to publish their data on the Web in RDF. This phenomenon is known as the Linked Open Data (LOD). The LOD cloud is one of the most well-known initiatives that allows available data sets on the Web to be referenced. The number of datasets in the LOD cloud has increased rapidly. Currently, it counts more than 1260 datasets, where a large subset of them contains several billions of triples4 as shown in Figure 2. These datasets are accessed via SPARQL endpoints (RESTful web services to expose RDF data queried with SPARQL) or downloading the data as data dumps.

Furthermore, the spread of RDF and SPARQL is evidenced by their usage to process and query recent valuable data to increase the decision power and crisis management. For example, with the recent Covid-19 pandemic, different organisms, local health authorities, press structures, research laboratories, etc. generated large amounts of data on a daily basis. The U.S. Government's open data portal published daily stats in RDF format to facilitate their integration 5 . Another example is the work developed by the INRIA research team Wimmics 6 . They developed a Knowledge Graph named Covid-on-the-Web [START_REF]Covid-on-the-web dataset[END_REF] merging academic articles from the COVID-19 Open Research Datasets. The graph counts more than 674 million triples describing parts of scientific publications (title, abstract, and body), and information that is enriched by annotations obtained from other sources like DBpedia.

reach high-value [START_REF] Berkani | A modelagnostic recommendation explanation system based on knowledge graph[END_REF]. In Question-Answering Systems, KGs are used in several phases of their life cycle [SRB + 18]. In [START_REF] Bouarroudj | Welink: A named entity disambiguation approach for a QAS over knowledge bases[END_REF], they are used for handling ambiguity problems of Natural Language queries.

The Ecosystem of Knowledge Graphs

The above presentation shows the complexity of the environment of the KG. From research and learning perspectives, it has become urgent to deeply understand this environment in order to identify its different elements. Making explicit these elements contributes in understanding some research issues. The main elements of a KG are: actors, requirements, constraints, services, storage and deployment infrastructures. In Figure 3, we propose a detailed ecosystem of a KG using the Entity-Relationship Diagram.

The following comments this diagram: A KG is the entry point of our diagram. It has a name (KG Name) and a nature (certain/uncertain like NELL [CBK + 10] and Knowledge Vault [DGH + 14]). A KG concerns one or several domains/topics (Medicine, Environment, Education, etc.), and it is built from one or several data sources. It is defined and designed by one or multiple creators. A creator owns the intellectual property of the KG. It can be any organization or user. A creator has a name (Creator Name) and a type (academic/ industrial). A KG is administered by a manager that can be different from its creator. The manager is in charge of implementing internal (e.g., storage, loading, maintenance, archive, security) and external (e.g., access, availability, extraction) services. Each service has a name (Service Name) and a means to manipulate and reach this data (using either a SPARQL endpoint or data dump in the case of external services). The KG is stored in a Storage Infrastructure (Triple Store). It has a name (Store Name) and information about its internal storage (native, non-native). This store is deployed in a given platform that may be either centralized, distributed, or parallel. Finally, a KG is designed to be exploited by consumers using the external services that extract fragments/views of the referred KG. The extracted data can be materialized at the consumer Figure 4 gives an instantiation of our model for the Yago's KG, where we assume that the LIAS Laboratory is one of its consumers.

Triple Stores with some numbers The storage infrastructure that includes triple stores is an important element of the KG ecosystem, since it has to provide the following services:

• A scalable storage of the Web data deluge (e.g., Academic KG: Yago2 → 284 million triples, DBLP → 207 million triples, DBPediaEN → 538 million triples, Commercial KG: eBay product KG → 1 billion triples, Google's KG → 500 billion triples),

• A quick response time of SPARQL queries to meet consumer requirements,

• A high availability of this data and services (e.g., DBpedia SPARQL endpoint receives more than 177k queries per day) [VHM + 14].

The Race for Efficient Triple Stores

As suggested in the above sections, it is important to notice that the Triple Store is at the heart of the KG' ecosystem. This situation motivates and pushes researchers from the Core Databases, Semantic Web, and the Infrastructure for Information Systems to develop triple stores that can be classified into two main groups: non-native and native as illustrated in Figure 5.

Triple Stores

Non-native Native

Centralized Distributed any SPARQL query is translated to SQL. This strategy generates multiple self-joins (one for each triple pattern) of the single table that significantly degrades the system's performance. To reduce the number of self-joins induced by this type of approach, Jena [START_REF] Wilkinson | Jena property table implementation[END_REF] proposed a new storage of the traditional triple as a flat table (called property table) including the subject and all predicates as attributes. This storage strategy generates the problem of NULL values and stresses to represent multi-valued properties.

To overcome the above drawbacks, other systems used one of the oldest optimization techniques known under the name of data partitioning. SW-Store [START_REF] Daniel | Sw-store: a vertically partitioned DBMS for semantic web data management[END_REF] is one of these systems. It vertically partitions the above-cited property table into L fragments (where L represents the number of predicates). Each fragment is associated to one predicate and composed of two columns (subject, object), known as Binary Tables. This strategy solved the storage problems caused by NULL values, but suffered overhead costs when many predicates were involved in a single SPARQL query. The emerging schemas generated by a strategy proposed in [START_REF] Pham | Deriving an emergent relational schema from RDF data[END_REF] are the result of splitting the triple table into several three-column tables according to induced predicate's sets.

Summary Non-native systems are considered as naive solutions to store RDF data thanks to different services offered by RDBMSs in terms of storage, optimization, maintenance, etc. Due to the limited schema in a triple (having only three attributes), indexing techniques were widely used to speed up SPARQL queries. Despite this, few attempts were proposed to vertically partition the triple table. This partitioning is performed in the structure of triples and surprisingly ignores the graph structure of the KG that represents its logical schema.

Native systems The managers of these systems do not rely on existing RDBMSs and build the infrastructure of RDF stores from scratch. Two main storage strategies are used in these systems: table-and graph-driven strategies. Systems using table-driven strategies store triples in tables. Contrary to non-native storage systems, the data in native systems is encoded and eventually compressed. RDF-3X [START_REF] Neumann | RDF-3X: a risc-style engine for RDF[END_REF] is the most representative system in this category. It stores triples in three-column tables in compressed clustered B+trees. For performance issues, intensive indexes are built considering all the permutations of the columns (e.g., SPO, OPS, PSO) and more others. Systems following graph-driven strategies, like gStore [Z ÖC + 14] use physical implementations of graphs such as adjacency lists. The optimizations of these systems are strongly dependent on the graph implementation structures (e.g., V*-tree indexes in gStore). platforms to develop scalable stores. Unfortunately, this opportunity was not available in the golden age of Relational Databases. In the following, a short introduction is given for distributed and parallel triple stores.

Distributed and Parallel Triple Stores

For scalability issues, a large panoply of distributed and parallel triples stores exists. The life cycle of developing such a store can be easily inspired by the one used for designing traditional distributed and parallel databases [START_REF] Benkrid | A global paradigm for designing parallel relational data warehouses in distributed environments[END_REF]. It has the following steps: (1) choosing the hardware architecture, (2) partitioning the target KG (that we call the fragmenter), (3) allocating the so-generated fragments over available nodes (called allocator), (4) replicating these fragments for efficiency purposes, [START_REF]Triple stores classification[END_REF] defining efficient query processing strategies, (6) defining efficient load balancing strategies, and (7) monitoring and detecting changes. Data partitioning is a precondition to ensure the deployment, efficiency, scalability, and fault tolerance of these systems [ ÖV11]. The sensitivity of RDF data partitioning and its impact on the performance of RDF stores has been recently discussed in a paper presented in a SIGMOD Workshop in 2020 [START_REF] Janke | Data placement strategies that speed-up distributed graph query processing[END_REF].

Data partitioning has to be transparent for the consumers of triple stores, in the sense that they should not care about how the data was partitioned. In contrast, for the managers, data partitioning is not transparent. This is because they have to define, evaluate, and tune different data partitioning techniques that fit their data. By analyzing the major distributed and parallel triple stores, we propose to classify them into two main categories based on the degree of transparency granted to the designers of these systems: transparent7 and opaque systems. In transparent systems, the data partitioning is delegated to the host (like a cloud provider) offering services to manage the triple store. For instance, the Cliquesquare system [GKM + 15] is built on top of the Hadoop framework who is in charge of performing the data partitioning. In these systems, the RDF data partitioning is hidden from local managers. In contrast, in opaque systems, all elements of the data partitioning environment are mastered by the managers. The different partitioning modes of RDF data are part of this environment (e.g., Hashing, Graph partitioning, and Semantic hashing [START_REF] Janke | Data placement strategies that speed-up distributed graph query processing[END_REF]). These systems are usually deployed in a master/slave architecture in which a fragment of triples is distributed on each slave (e.g., RDF-3X). At the query runtime, the master node (which has a catalog of the data) sends queries to each slave and if necessary, combines the results to produce the final answer.

From the above presentation including centralized, distributed, and parallel triple stores, three main lessons are learned:

1. A strong demand from managers and consumers for developing triple stores by exploiting the technological opportunity in terms of software and hardware is noticed. More concretely, the DB-Engine website8 ranks 19 RDF stores in October 2020. These stores span centralized and parallel triple store systems.

2. Any initiative to use data partitioning in triple stores should benefit from the large experience of academia, commercial DBMSs editors, and Open Source developers (e.g., the case of PostgreSQL that supports nicely data partitioning) in defining and using data partitioning in the context of traditional databases. This experience has to be capitalized to augment the reuse and reproducibility of the findings of data partitioning in RDF data. This capitalization is done by an exploitation process of the whole environment of data partitioning.

3. The necessity for developing an RDF data partitioning framework for managers willing to design centralized and parallel triple stores. To explicit the different elements of RDF data partitioning, let us overview data partitioning in the context of traditional databases in order to reuse its success stories. Data partitioning has been first considered as a logical technique for designing relational databases and then as a physical optimization after the amplification of physical design motivated by the arrival of the data warehousing technology [START_REF] Agrawal | Integrating vertical and horizontal partitioning into automated physical database design[END_REF]. It is used either in centralized and distributed/parallel databases. Three main types of data partitioning exist (vertical, horizontal, and hybrid). These types will be largely discussed in Chapter 1. Several partitioning modes have been proposed and evolved after each generation of databases. Two types of modes exist single (range, list, and hash partitioning) and composite (combining the single ones) modes. Figure 6 shows the spectacular adoption and services offered by editors of DBMSs such as Oracle. Native data definition language support is available for horizontal data partitioning (e.g., CREATE TABLE ... PARTITION BY RANGE(...)). The decision of partitioning a table is delegated to the database administrator. The main characteristic of data partitioning is its ability to be combined with some redundant optimization techniques such as indexes and materialized views. This implies that the declaration of the partitions of a table is performed before deploying a given database. Two versions of horizontal partitioning are available [START_REF] Ceri | Horizontal data partitioning in database design[END_REF]: primary and derived horizontal partitioning. Primary horizontal partitioning is performed to a single table T using simple predicates defined on T . A simple predicate has the following form: Attr θ value, where Attr is an attribute of T , θ ∈ {<, >, =, ≤, ≥} and value ∈ domain(Attr). It can be performed using the different fragmentation modes above cited. Derived horizontal partitioning is the result of the propagation of a partitioning schema of a table T on a table R. The derived horizontal partitioning is feasible if a parent-child relationship exists between T and R. Due to the difficulty of selecting an optimal data partitioning scheme for a given database, several algorithms with different strategies (including affinity-based [START_REF] Shamkant | Vertical partitioning algorithms for database design[END_REF], graph-based [START_REF] Shamkant | Vertical partitioning for database design: A graphical algorithm[END_REF], minterm-based [ ÖV11], cost model-based [START_REF] Rao | Automating physical database design in a parallel database[END_REF]) have been proposed to satisfy a set of non-functional requirements such as query performance, network transfer cost, number of final fragments, etc. Two main classes of these algorithms are distinguished:

(i) Query-driven algorithms: that require an a priori knowledge of a representative workload as an input [START_REF] Tamer | Principles of distributed database systems[END_REF][START_REF] Shamkant | Vertical partitioning for database design: A graphical algorithm[END_REF];

(ii) Data-driven algorithms: which are independent of the representative query workload.

Due to the complexity of performing data partitioning, several academia and DBMS editors have proposed wizards for assisting designers (database administrators) in their day-to-day tasks when managing partitions. The most important advisors are shown in Table 1. From this table we can figure out that data partitioning and indexes are available in all mentioned advisors. This is due to their quality in improving queries.

Introduction Name Type

Supported optimizations

P a I b MV c C d

SQL Database Tuning Advisor (DTA) Commercial

✓ ✓ ✓ Oracle SQL Access Advisor ✓ ✓ ✓ DB2 Index Advisor tool [START_REF] Rao | Automating physical database design in a parallel database[END_REF] ✓ ✓ ✓ ✓ Parinda [MDA + 10] Academic ✓ ✓ SimulPh.D [START_REF] Bellatreche | d.: A physical design simulator tool[END_REF] ✓ ✓ a Partitioning, b Indexes, c Materialized views, d Clustering Table 1: Partitioning advisors in [START_REF] Bellatreche | Optimization and tuning in data warehouses[END_REF] The abundance and the popularity (in terms of research and education) of data partitioning in traditional databases allow us to propose its environment described in an Entity-Relationship diagram in Figure 7 that is commented as follows: Data Partitioning (DP ) is the entry point of our diagram. A DP has a name (Part Name), a type (Part Type, i.e. horizontal, vertical or hybrid), a version (i.e. primary or derived) and an inventor described by either the title of her/his published paper(s) describing this method or the name of the system implementing it. A DP strategy is applied to one or many Entities. An Entity is identified by a schema (e.g., table, class) and an extension (e.g., tuples in a table, instances of a class) stored in a given Entity Store (e.g., DBMS) that is deployed in a platform. A DP strategy is designed to meet one or many Objective functions measured by mathematical cost models [START_REF] Ouared | Qosmos: Qos metrics management tool suite[END_REF]. Each Cost Model has a Name (Cost Name) and a Metric corresponding, for instance, to CPU, Inputs/Outputs, and Transfer costs. A DP strategy has to satisfy one or several Constraints and must be implemented by a set of algorithms. An Algorithm has a name (Algo Name) and a type (Algo Type, i.e. Data-driven or Query-driven). Finally, a DP strategy has one or many partitioning modes (Mode). A Mode has a name (Mode Name) and a type (Mode Type, i.e. simple or composite). Figure 8 gives an excerpt instantiation of our model for the Horizontal Partitioning method defined in [START_REF] Bellatreche | Referential horizontal partitioning selection problem in data warehouses: Hardness study and selection algorithms[END_REF]. The authors in this paper proposed primary and derived horizontal partitioning schemes for a relational data warehouse schema stored in a centralized RDBMS. A cost-driven algorithm is given to generate a number final fragments of a fact table (which must not exceed a threshold fixed by the data warehouse administrator). The obtained fragments have to minimize the number of inputs-outputs (I/Os) when processing a set of OLAP queries known in advance. The traditional modes (range, list, and hash) are applied to the obtained final fragments of fact and dimension tables. Figure 8: Horizontal partitioning in [START_REF] Bellatreche | Referential horizontal partitioning selection problem in data warehouses: Hardness study and selection algorithms[END_REF] The Reuse of Data Partitioning in Relational Databases in other Generations

The lessons of relational databases served as basis for many other data models that came after. Let us take for example the object-oriented model whose partitioning (of classes) was initially explored by [START_REF] Cook | Partition selection policies in object database garbage collection[END_REF] and then implemented in [START_REF] Karlapalem | Partitioning schemes for object oriented databases[END_REF][START_REF] Karlapalem | A framework for class partitioning in objectoriented databases[END_REF]. Later, horizontal and vertical partitioning methods for classes were proposed in the literature by [START_REF] Bellatreche | Horizontal class partitioning in object-oriented databases[END_REF] (referential horizontal partitioning [START_REF] Bellatreche | Derived horizontal class partitioning in oodbs: Design strategies, analytical model and evaluation[END_REF]) and [START_REF] Fung | Cost-driven vertical class partitioning for methods in object oriented databases[END_REF] respectively. Similar examples can be mentioned in data warehouses (e.g., horizontal fragmentation of the fact table in a star schema [START_REF] Stöhr | Multi-dimensional database allocation for parallel data warehouses[END_REF] and the use of referential partitioning in the dimensional data model [START_REF] Bellatreche | Referential horizontal partitioning selection problem in data warehouses: Hardness study and selection algorithms[END_REF]) and semi-structured models like XML (e.g., [START_REF] Bordawekar | Parallelization of XPath queries using multi-core processors: challenges and experiences[END_REF]). So, we wonder, why this type of approach has not been seen so far in RDF databases? Because without a doubt, data partitioning is currently at the center of the debate regarding its great influence on the performance of triple stores. Making a partitioning environment explicit for triple store managers can help not only to understand current strategies but also to set the grounds for future extensions. The Entity-Relationship diagram shown in Figure 7 does not have any component related to the physical storage structure of the data. Indeed, DP strategies are performed to the entities that logically represent the data. The manager of a relational database should not worry about how exactly the data are physically represented on the disk. In fact, the physical storage structures are proper to each RDBMS. The key of data partitioning in these models is their logical layer. This layer allowed the definitions of algorithms, cost models, constraints, etc. that are independent of particular system implementation. In the following, we address how this layer could be introduced for RDF datasets. model a lot of flexibility, but it certainly complicates the reuse of data partitioning techniques as it has been done in other models. In RDF, the data are partitioned with merely physical strategies using the triple as fragmentation unit. This does not mean that RDF triples do not have any schema. This schema exists, but contrary to the models illustrated in Figures 9a,9b, and 9c, it is implicit. This implicit schema can be identified with various techniques based on the hierarchy of classes and ontologies (using the RDFS and OWL schemas for example) of the predicates, or relying only on the structure of the data. So, if logical entities can be detected, why not using/adapting them to propose partitioning techniques inspired by the relational model so widely studied?

This motivates us to provide triple store's designers with a framework to partition RDF data from a logical level first. We do not seek to change the features that made RDF flourish but to incorporate a common logical layer to the design process of RDF partitions. The logical layer will allow designers to work on structures with a higher level of abstraction than that offered by the triples. To regroup the triples, we propose two strategies: by instances and attributes. These structures are defined in Chapter 3 of this thesis. The first strategy analyzes each node of the RDF graph and its outgoing edges. The set of predicates of a subject node characterize it [START_REF] Neumann | Characteristic sets: Accurate cardinality estimation for RDF queries with multiple joins[END_REF]. In the example of Figure 9d, the Airbus node is characterized by the predicates has_name, has_product and industry. We refer to a node and its outgoing triples as a forward data star. Making an analogy with the object-oriented model, a forward data star is an instance of some class. To identify to which high-level entity a forward data star belongs, we can apply two types of techniques that use structural or semantic clustering. The groups of forward data stars form a forward graph fragment and they harmonize with the notion of horizontal partitions. Vertical partitions on the other side are identified by grouping the nodes with their ingoing edges in backward data stars. The backward stars are further grouped in Backward graph fragments. These structures allow defining an explicit schema for RDF data. They are the baseline of our framework allowing triple store managers to partition RDF graphs based on logical structures. Our framework allows managers (designers) to partition in an informed way, considering the inherent graph structure of the data, their connectivity, and other constraints related to the partitioning environment (e.g., system's constraints). In the following sections, we describe the components of this partitioning framework.

Introduction

Knowledge Graph Universe

Data Partitioning in Relational Databases Universe

Thesis Vision

In this thesis, we position ourselves as a manager of a triple store to satisfy the creator needs described in a manifest (Figure 11). This manifest contains the KG, nonfunctional requirements, constraints, and offered services imposed by the creator. We favor the usage of data partitioning in designing triple stores by reusing its strong points identified in the traditional databases. Our RDF data partitioning is proposed to be used either in new triple stores (the case of our RDF -QDAG store currently developed in our LIAS Laboratory) or in already designed ones (such as gStoreD).

We claim that the implementation of our vision passes through the following tasks:

1. A deep understanding of data partitioning proposed in the context of centralized/parallel/distributed traditional databases.

2. The reuse of its strong points in terms of techniques and tools. To reach this objective, an establishment of a concise and complete survey of data partitioning is required followed by a reproduction of its principles and strong aspects to RDF data. Figure 10 shows the connection between data partitioning and KG environments.

The objectives that we set in our thesis are:

(i) The definition of a common framework for centralized and parallel triple stores with comprehensive components implementing our vision.

(ii) The proposal of efficient data-driven partitioning algorithms defined on logical structures of RDF as in relational databases.

(iii) The instantiation of our framework in the centralized and parallel triple stores by taking into account the requirements of consumers in terms of constraints and nonfunctional requirements such as the performance of SPARQL queries.

(iv) Making tools available for designers including a fragment manipulation language and a wizard (an advisor) to assist them in their tasks. Both are based on the logical fragments that we previously defined.

Contributions

The main contributions of our work are:

• With the motivation of increasing the reproduction and the reuse of important findings of the data partitioning in the of traditional centralized and parallel databases in mind, we propose a complete survey of this problem covering the important generations of the database world.

• The definition of a Framework, called RDFPartSuite illustrated in Figure 11. It supports our vision in designing centralized and parallel triple stores. RDFPartSuite can be personalized to the type of the platform. One of the main characteristics of our RDFPartSuite is that it follows the paradigm outside a DBMS [START_REF] Ordonez | Can we analyze big data inside a dbms?[END_REF], in which all technical efforts are performed externally from the triple stores. Based on the type of the platform two scenarios are possible:

1. If the platform is centralized, our framework activates the module fragmenter in charge of partitioning triples based on their logical representation. The definition of these fragments is sent to the target triple store. After that, triples of the creator KG are loaded in this store (in our case RDF QDAG).

2. When the platform is distributed or parallel, the fragmenter sends the obtained fragmentation schema to the allocator component. This latter role is to assign the different fragments to nodes of the target platform. This allocation is performed based on a data-driven approach (i.e. considering the inherent connectivity between fragments).

Once the allocation schema is obtained, the dispatcher component sends the detailed description of this schema to different nodes and then loads the triples according to their definitions.

3. Assistance tools are proposed to help managers in their tasks. These tools take into account the expertise level of the manager. If she/he is an expert in the studied problems, she/he can easily perform different tasks offered by the framework. For that she/he needs a language to describe and define the different schemes (fragmentation/allocation/dispatcher). In the case, she/he is not an expert, we propose her/him an advisor as in traditional DBMS editors.

• The definition of a set of logical entities (named graph fragments) used to perform the fragmentation of RDF datasets at a logical level in centralized and parallel environments. This is a step forward with respect to the current strategies used by the triple stores that use merely physical fragmentation strategies that depend on the specific storage structure used to represent the triples.

• The deployment of this framework to the loading module of a centralized system (RDF -QDAG) and of a distributed triple store (gStoreD). [PZ Ö+ 16]).

Thesis Outline

The reminder of our manuscript is composed of two main parts as illustrated in Figure 12.

First part: State-of-the-art and Objectives

The first part presents our state of the art and background concepts revolving around two chapters. In Chapter 1, we develop a complete survey of data partitioning. We conduct a comprehensive review of the literature on the data partitioning problem with the aim of letting the reader get a complete overview of the problem in terms of definitions, variants, and constraints. We define the data partitioning foundations along with ten dimensions to classify the spectrum of works related to this manner. It sets the reader in the whole history of the evolution of the data-partitioning concept. Then, Chapter 2 starts giving a general overview of the graph data model. We detail its logical and storage structures, query processing strategies, and languages. Next, to better delimit our work, we focus on the many existent RDF systems. We start by giving some background concepts about RDF storage, processing, and partitioning strategies. We classify the existent systems according to their fragmentation, allocation, and replication strategies. We conclude this section by comparing the partitioning strategies seen in Chapter 1 and those of RDF systems discussed in Chapter 2. This comparison serves as the basis for setting out the objectives of our contributions.

Second Part: Contributions

We detail in this section our two main contributions.

In Chapter 3, we describe the fragmenter and allocator components of our framework. We start by formally defining the logical entities used to partition a KG. We detail the algorithms to generate them from raw RDF datasets. Then, we defined the allocation problem of the fragments identified previously. We showed that the connectivity of graph fragments can be expressed in a graph. Thereby, we proposed some heuristics to partition the fragments based on graph-partitioning techniques.

In Chapter 4, we implement our framework in a centralized and parallel triple store. We integrate first our findings into the loading module of a graph-based centralized triple store. This system, RDF QDAG [KMG + 20], stores the triples using the logical structures defined in the previous chapter. We start by giving an overview of this system describing its storage, optimization, and processing modules. Then, we evaluate RDF QDAG in three main stages: data loading, fragmentation, and allocation. We compared its loading costs and query performance with respect to other representative systems of the state of the art. We use real and synthetic datasets with variable sizes to test the system's scalability. Then, we show the integration process of our framework to the loading stage of the data to gStoreD [PZ Ö+ 16]. Finally, we describe the present Assistance tools as extensions to our Framework. These tools include a Data Definition Language and an RDF partitioning advisor.

Last Part: Conclusions and Perspectives

This chapter concludes the thesis by providing a summary and an evaluation of the presented work. Lastly, this chapter discusses several opportunities for future works.

Summary

In our Introduction, we have discussed the importance of describing in detail the partitioning environment for designing opaque systems. In this chapter we conduct a comprehensive survey of the literature regarding the partitioning problem in relational databases. We look at the fundamentals of the problem and its evolution over all the database generations. Our aim is to give a complete overview of how the problem was treated in these systems identifying its main elements and strong points. The chapter is organized as follows. We start in Section 1.2 citing the works that led to the explicit definition of partitioning stating the data partitioning foundations. Then, in Section 1.3 we define the problem and its main dimensions that are ergo used to classify the surveyed works. Next, Section 1.4 organizes the works according to these dimensions giving a high-level comparison and classification of existing partitioning approaches. We introduce the partitioning approaches in the most recent large-scale platforms in Section 1.5. Finally in Section 1.6 we give insights to open problems and compare the approaches presented in this chapter.

Introduction

Within the most studied optimization techniques in databases, data partitioning occupies a very important spot not only for its effectiveness to improve the performance of the database, but also because in modern large-scale parallel and distributed architectures it is a mandatory stride. Data partitioning notions were introduced in the seventies in [START_REF] Hoffer | The use of cluster analysis in physical data base design[END_REF] shortly after the definition of database indexes. Along with materialized views and indexes, data partitioning was at an early stage part of the same pool of optimization strategies sketched during the physical design phase [LGS + 79]. These strategies seek to improve the speed of retrieval operations reducing the data transferred in the network in a distributed database, or between primary and secondary storage in a centralized system. In relational databases, partitioning refers to splitting what is logically one large table into smaller physical pieces. Similar to indexes, the data partitioning problem has been covered in all generations of databases from deductive [START_REF] Spyratos | The partition model: A deductive database model[END_REF][START_REF] Neumann | Partitioning algorithms for a distributed deductive databases[END_REF], objected-oriented [START_REF] Bellatreche | Horizontal class partitioning in object-oriented databases[END_REF] to data warehouses [START_REF] Stöhr | Multi-dimensional database allocation for parallel data warehouses[END_REF]. Still, contrarily to other optimization strategies and before the introduction of dynamic partitioning techniques, partitions are created during the declaration of the database tables. This feature distinguishes data partitioning from other optimization techniques that can be created on-demand while the database is running. Recreating partitions after its definition is costly and unpractical. Numerous tools have been developed to facilitate the creation of partitions, for instance physical design advisors (e.g [START_REF] Rao | Automating physical database design in a parallel database[END_REF], DB2 advisor [ZRL + 04]) and data definition languages offered by some Database Management Systems (e.g., Oracle, PostreSQL, MySQL).

For example, let us consider the table Airplane in Figure 1.1 which will be used throughout this chapter. This In this statement, the table Airplane is partitioned listing the key values for each partition creating two groups based on the airplane's developer (Dev ): Airbus and Boeing. The PARTITION statement in this DDL should not be confused with the SQL operator PARTITION BY used in OLAP window functions. Although declaring partitions can be done very simply, choosing the attribute(s) and the partitioning method that optimizes the performance and the efficiency at query runtime is a very complex problem due to the large number of variables and possible solutions to consider. We characterized the partitioning problem according to its:

ID

• Maturity: the problem has existed almost since the definition of the first database systems and has been largely explored,

• Coverage: it has been implemented for all generations of databases,

• Evolution: it has been adapted to the different architectures, needs and constraints, and

• Complexity: finding an optimal partition scheme needs to consider several alternatives and sometimes mutually exclusive objective functions.

The research devoted to this topic has been very rich and extensive. Some surveys exist in the literature devoted to specific partitioning types. For example, [START_REF] Ghandeharizadeh | A performance analysis of alternative multi-attribute declustering strategies[END_REF][START_REF] Moon | Scalability analysis of declustering methods for multidimensional range queries[END_REF] are devoted to certain partitioning strategies whose main objective is called declustering.

In this chapter we conduct a comprehensive review of the literature of the partitioning problem with the aim of letting the reader get a complete overview of the problem. We start in Section 1.2 citing the works that led to the explicit definition of partitioning stating the data partitioning foundations. Then, in Section 1.3 we define the problem and its main dimensions that are ergo used to classify the surveyed works. Next, Section 1.4 organizes the works according to these dimensions giving a high-level comparison and classification of existing partitioning approaches. We introduce the partitioning approaches in the most recent large-scale platforms in Section 1.5. Finally in Section 1.6 we give insights to open problems and compare the approaches presented in this chapter.

Data Partitioning Fundamentals

In this section we recall the main features and characteristics of the partitioning problem to unify the terminology used throughout the thesis. We first mention the works that led to the definition of what we called the core partitioning problem. Then we give definitions and examples of the different variants of partitioning in relational databases. Each variant is motivated highlighting its performance impact at query runtime. Finally, we explain the dimensions used to classify the partitioning algorithms.

The database community strives to provide systems that store, update, administrate and retrieve information ensuring the integrity, consistency and security of the stored data and transactions offering a reasonable performance. Performance optimization strategies for database systems have been largely studied especially the ones applied during the database design stage. Three optimization strategies for centralized systems were clearly distinguished already in 1976 in [START_REF] Eisner | Mathematical techniques for efficient record segmentation in large shared databases[END_REF]:

1. Hardware: physically increase the speed at which data are transferred between primary and secondary memory, 2. Encoding: improve data encoding strategies to increase logically the information content transferred to main memory, 3. Physical design: selectively transfer only those physical records or data attributes which are actually required by the application.

Even if originally these strategies targeted centralized database systems, they fit to the parallel and distributed contexts when the network constraint is considered as well at each point. The last category of techniques (Physical design) comprises indexes, materialized views and partitions all being part of the physical design process conceived by the database designer. Partitioning was defined as an optimization stage that evolved into a mandatory design step in distributed and parallel systems. Next, we introduce the definition and evolution of the partitioning problem.

Partitioning definition and development overview

Let us define the partitioning process in general as the action or state of dividing or being divided into parts1 . In the database context the data are divided to form partitions. The earliest partitioning studies in information systems dealt with the optimal distribution of entire files to nodes on a computer network. These works (e.g., [START_REF] Chu | Optimal file allocation in a multiple computer system[END_REF][START_REF] Kapali | Placement of records in a file and file allocation in a computer[END_REF]) solve the problem which arises in the design of distributed information systems where the data files are shared by a number of users in remote locations. Partitioning in relational databases was introduced later disclosing how partitioning a relation contributes to improve the system's performance and implicitly describing how partitions are built. In 1975 an article by Jeffrey Hoffer and Denis Severance [START_REF] Hoffer | The use of cluster analysis in physical data base design[END_REF] motivated data partitioning as a technique to reduce the query execution time and implicitly introduced two types of partitioning configurations. These configurations use clustering notions to distribute the data in subfiles. They showed that the query response time in a centralized database is minimized if each relation is partitioned either at the attribute or at the record level, presenting the first notions of horizontal and vertical partitions. Their main motivation is the awareness that the query's retrieval time is dominated by the time spent to transport data from the disk to main memory before processing. They formalized their ideas and proposed an algorithm clustering the attributes of a relation in a centralized database system. This first formal definition to a partition is shown in Definition 1.1.

Definition 1.1 Partition [HS75] Given a set of attributes A of a relation R, consider the collection of subfiles S = {(A i , R i )} and A i ⊆ A, R i ⊆ R,
specifying the attributes and entities represented in a subfile i. S clusters the data in two basic forms:

1. By attributes in which R i = R and ⋃ n i=1 A i = A for i = 1...n.

By records in which

A i = A and ⋃ n i=1 R i = R for i = 1...n.

A cluster S in which A

i ∩ A j = ∅(R i ∩ R j = ∅)
for all i ̸ = j is named an attribute (record) partition for the database.

The same team of researchers extended its work proposing an integer programming formulation for the problem considering the case when the database is shared by a group of users [START_REF] Hoffer | An integer programming formulation of computer data base design problems[END_REF][START_REF] Eisner | Mathematical techniques for efficient record segmentation in large shared databases[END_REF][START_REF] March | A mathematical modeling approach to the automatic selection of database designs[END_REF]. The terms horizontal and vertical partitions were adopted by the database community to define partitions performed at the record and attribute level of a relation respectively. The works of Eisner M., Hoffer J. and Severance D. described previously were the first efforts towards creating partitioning algorithms for centralized database systems.

The previous findings work for both centralized and distributed database systems. In both cases the main objective is to benefit data locality by clustering the records or attributes according to a defined degree of togetherness. Centralized and distributed partitioning strategies promote data locality, a strategy in which related records/attributes are often stored in close proximity to minimize performance overhead in access path navigation. In centralized systems, attribute and record clustering are used to gather in main memory the most frequently accessed records or records subsets to reduce the number of input/output (I/O's) to the primary storage. In a distributed database system, the objective is as well to cluster attributes or records but with the aim of decreasing the number of distributed transactions considering that for these systems the network traffic is the bottleneck of query processing.

A special kind of distributed database systems that exploit the parallelism to deliver highperformance and highly available systems was introduced not long after the boom of distributed databases in the eighties. This kind of database system, named parallel is formed by a set of processing units connected by a very fast network to process large databases efficiently. Three Horizontal De-clustering forms of parallelism are exploited in these systems: i)inter-query parallelism which enables the parallel execution of multiple queries, ii)intra-query parallelism making the parallel execution of independent operations in a single query and iii)intra-operation parallelism in which the same operation is executed as many sub-operations [ ÖV96]. Contrarily to distributed databases, localizing the query execution in a single node is not the preferred solution. In this case, the performance might be degraded due to excessive queuing delays at the node and the parallelism will not be exploited. Data partitioning for parallel databases implements the so-called declustering, a strategy which spreads the data among the processing nodes to ensure parallelism and load balance. The declustering term was introduced in 1986 in [START_REF] Fang | The idea of de-clustering and its applications[END_REF] to solve the multidisk data allocation problem. This term was later used in the early parallel database systems (e.g., Gamma [DGG + 86] ) that horizontally partitioned and distributed the data across multiple processing nodes. Still, in many situations the system is really a hybrid between parallel and distributed, specially in shared-nothing architectures. As mentioned in [ ÖV96], the exact differences between parallel and distributed database systems are somewhat unclear. In this thesis we distinguish the partitioning strategies in both systems, but as seen in the next sections, it is the main objective of the system which guides the choice for the best distribution strategy. Table 1.1 organizes the information formerly described. In the following section we explain the evolution of the problem and the dimensions that we applied to describe the partitioning environment.

Partitioning concept evolution

Partitioning a relational database implies dividing tables into parts (or partitions). As we previously mentioned, the partitions are subsets of the relation at the attribute or record levels. The core definition of the problem has not changed over time, however, the problem has evolved with the consideration of additional constraints, different platforms and ergo new objectives. The first notions of data partitioning are related to the distribution of entire files in a centralized or distributed system. Then, as a result of the work of [START_REF] Hoffer | The use of cluster analysis in physical data base design[END_REF], the notion of partition as a subset of a relation starts being considered. Formerly, partitioning was used as a strategy to optimize the system in the same way as indexes in a non-mandatory process. With the introduction of parallel systems, the partitioning main objective changed and therefore the partitioning algorithms were adapted to this type of systems. In this section we detail the works leading to the definition of partition and its types. We mention as well the first algorithms for each partitioning type.

File allocation

Partitioning has its origins in file allocation models performed on the basis of entire files. Distributed computer systems were introduced before the relational databases entered the market. Optimal file allocation models seek to minimize the overall operating costs of storage and transmission of distributed files across the nodes of a computer network. In 1969 W. Chu modelized file allocation in a computer network as an integer programming problem [START_REF] Chu | Optimal file allocation in a multiple computer system[END_REF], his work was later enriched by K. P. Eswaran in [START_REF] Kapali | Placement of records in a file and file allocation in a computer[END_REF]. These works, along with others, served as bases to develop the very early works on partitioning algorithms for relational databases.

Implicit partitioning definition

The work of J. Hoffer and D. Severance published in 1975 [START_REF] Hoffer | The use of cluster analysis in physical data base design[END_REF] was the first work that intuitively showed that subdividing the relation in sub-files (at the attribute or at record levels) minimized the retrieval, storage and maintenance costs of data in a centralized database. They developed a method to cluster the relation's attributes and vertically partition the relation, but no method was established to generate sub-files at the record level (i.e. horizontal fragments). The problem was mathematically formalized by J. Hoffer the next year in [START_REF] Hoffer | An integer programming formulation of computer data base design problems[END_REF]. The approach modeled the allocation of subsets of a relation on different physical areas of the system (i.e. primary and secondary memory) using a weighted combination of operational costs for secondary storage, read-only and update requests summed across memory areas. M. Eisner and D. Severance published in 1976 an article [START_REF] Eisner | Mathematical techniques for efficient record segmentation in large shared databases[END_REF] with a model using a network graphical representation of the user's interactions reducing the retrieval cost in a database shared by multiple users. The work was extended in [START_REF] March | The determination of efficient record segmentations and blocking factors for shared data files[END_REF] and a complete mathematical approach of the automatic selection of database design was presented by the same authors in [START_REF] March | A mathematical modeling approach to the automatic selection of database designs[END_REF].

Explicit partitioning definition

Fragments were explicitly defined as the sub-relations used as distribution units among the nodes of a distributed database system in 1977 in the technical report describing the distributed system SDD-1 [START_REF] Rothnie | An overview of the preliminary design of SDD-1: A system for distributed databases[END_REF]. The term was reused by Stonebraker et al. [START_REF] Epstein | Distributed query processing in a relational data base system[END_REF] in 1978 to describe the partitioning stage in the distributed version of INGRES. In the same year a database design workshop [LGS + 79] reunited many database researchers to discuss important issues and future research problems. The terms horizontal and vertical partitions were established at this workshop, defining them as the clustering (or fragmentation using the term introduced in [JG77]) strategies to perform data partitioning and placement. Horizontal partitions refer to record partitioning while vertical partitions refer to partitions at the attribute level. It is important to remark that the term fragmentation was used in distributed database systems to separate the processes of partition creation for a relation and the allocation process of physical files to nodes. The separation of the data partitioning process in fragmentation and allocation stages is still carried out in distributed systems [START_REF] Tamer | Principles of distributed database systems[END_REF][START_REF] Ramakrishnan | Database management systems[END_REF].

Former partitioning algorithms

We briefly recall the first algorithms proposed to create vertical and horizontal partitions. Vertical partitioning algorithms were introduced sooner than algorithms to partition the database at the record level. The first algorithm using a similarity measure to group attributes according to their togetherness was proposed by J. Hoffer et al. [START_REF] Hoffer | The use of cluster analysis in physical data base design[END_REF] in 1975. The algorithm measured the attribute's affinity using the bond energy algorithm BEA developed in [START_REF] Mccormick | Problem decomposition and data reorganization by a clustering technique[END_REF]. Based on [HS75]'s findings, S. Navathe et al. published in 1984 [START_REF] Shamkant | Vertical partitioning algorithms for database design[END_REF], a two phase approach for vertical partitioning. Their algorithm was extended by Cornell and Yu in [START_REF] Cornell | A vertical partitioning algorithm for relational databases[END_REF]. The detailed list of vertical partitioning algorithm is found in Section 1.4.1.1 of our work. Here we present only the works that served as the fundamentals for other approaches.

Horizontal partitioning algorithms were introduced a few years after the definition of horizontal fragments in 1978. In 1982, S. Ceri et al. published their work [START_REF] Ceri | Horizontal data partitioning in database design[END_REF] presenting a horizontal partitioning algorithm based on the min-term predicates defined in their paper. Given a relation R with n attributes represented as R(A 1 , .., A n ), a simple predicate p j is defined as p j : A j θ V alue where θ ∈ {=, ̸ =, <, ≤, >, ≥} and the V alue is chosen from the domain of A j . A min-term predicate is a conjunction of simple predicates (or its negation) describing a horizontal partition (or fragment as called in distributed databases) of the relation R. In general, the algorithm consists on finding the minimal set of min-term predicates describing the queries of a . Before [START_REF] Ceri | Horizontal data partitioning in database design[END_REF], several works were published concerning file allocation (a complete survey is found in [START_REF] Surveyors | comments on "comparative models of the file assignment problem[END_REF]) but none of them proposed a characterization of the access patterns defining a horizontal partition. The complete list of horizontal partitioning approaches is presented in Section 1.4.1.2.

Declustering algorithms

In parallel to the works handling horizontal and vertical partitioning in centralized and distributed databases, approaches dealing with the organization and distribution of data on multiple-disk systems started its development from the seventies. These works served subsequently as starting point to the development of partitioning approaches for parallel database systems. Parallel databases exploit hardware architectures in multiprocessor environments. In general, individual database servers are connected with a fast network connection exploiting parallelism (especially in I/O) by distributing database files across multiple processors and/or disks. The partitioning problem in parallel systems exhibits similarities with centralized and distributed database systems. An evident one is that a relation is divided as well into parts to increase the performance. However, on the contrary of distributed and centralized systems that privilege data locality, data are rather spread among the nodes to process in parallel avoiding execution skewness. As it was formalized by Sacca D. and Wiederhold G. in [START_REF] Saccà | Database partitioning in a cluster of processors[END_REF] and mentioned by [ ÖV11] the partitioning problem in these systems is much more complex. Before describing partitioning strategies for multiple-disks systems let us first mention some multi-attribute file organizations whose fundaments were used to establish the partitioning strategies for parallel database systems. These file organizations contributed to the development of Cartesian product files to which several partitioning heuristics were devoted. Rothnie et al. introduced in 1974 [JL74], a file organization strategy hashing multiple keys for a record. In 1976, J.H et al. [START_REF] Liou | Multi-dimensional clustering for data base organizations[END_REF] proposed a multi-dimensional file structure together with multidimensional attribute's indexes to reduce the retrieval, update and storage costs of data in which the record address is determined by multiple keys. Their proposal combines a multidimensional directory (MDD) and a single key index to find efficiently the solutions for a partial match-queries in a files with attributes having discrete domains. Let us consider for example a file storing records like (A 1 , .., A d ) with d attributes. A partial match query defined on this file is query q

: A i = a i ∧ A j = a j ∧ • • • ∧ A k = a k .
The best strategies of some multi-attribute file organizations were unified in the specification of Cartesian product files in 1978 [START_REF] Lin | Common properties of some multiattribute file systems[END_REF].

A Cartesian product file, as defined in [START_REF] Moon | Scalability analysis of declustering methods for multidimensional range queries[END_REF], stores records as an ordered d-tuple (a 1 , .., a d ) of values where each attribute a i has a finite domain. Let us define D i as the domain of the i-th attribute. A d-attribute file is a subset of D 1 ×D 2 ו • •×D d . When this file is stored on disk, the records are partitioned into buckets or pages. The file is called a Cartesian product file if when each attribute's domain is partitioned into m subsets, the records in D 1m 1 ו • •×D 1m d are stored in a single bucket. When a multi-attribute query is defined on the file, the buckets containing records qualified by the query are retrieved from the secondary storage. The query cost depends then on the number of buckets retrieved from the disk. To improve the performance, a Cartesian product file is stored on multiple disks, and since each disk is assumed to be independently accessible, the time to respond a query correspond to the maximum number of blocks retrieved by a disk of the system instead of the total amount of blocks retrieved. The problem of distributing files across multiple disks is called declustering. The term was introduced in 1986 in [START_REF] Fang | The idea of de-clustering and its applications[END_REF] although parallel systems like Gamma [DGG + 86] already used declustering strategies in their first versions. A more detailed description of the declustering strategies will be given in Section 1.3.3.

It took around 10 years to establish the bases of the partitioning problem. The works leading to its definition are organized in Figure 1.2 in which we show the structure of the works we previously described. In the following section we detail the dimensions used to describe the partitioning features used to organize the partitioning approaches described in Section 1.4.

Partitioning dimensions

We modeled the partitioning environment using a star-schema diagram shown in Figure 1.3. The dimensions with a double border in this Figure correspond to ones defining the core partitioning problem. We organize the partitioning approaches in the following sections by the means of the ten dimensions detailed below that are used as diversification criteria.

Type

This dimension describes the alternative ways of dividing a table into smaller ones. Two alternatives are clearly noticeable: dividing it horizontally or vertically. In brief, logical entities are represented as relations in the relational model. Each relation groups sets of tuples that are instances of a logical entity which are depicted by a set of attributes. For example, the entity Aircraft in Figure 1.1 is defined by the attributes: model, developer, length (in m), cost (im M$) and an identifier. The table is divided as shown in Figures The primary key is replicated on each partition in Figure 1.4b to enable the reconstruction of the original table if necessary. This condition is known as the reconstruction rule. More details about the correctness fragmentation rules are found in [ ÖV11, RG00, SKS + 97] . Horizontal partitioning has been explored more widely by commercial DBMSs and there are many versions of it. First, we distinguish horizontal partitions performed in a single table named single horizontal partitioning. This strategy is supported by most of commercial database systems in their latest versions. The single-level partitioned methodologies are:

• Range: as stated in [START_REF] Bellatreche | Referential horizontal partitioning selection problem in data warehouses: Hardness study and selection algorithms[END_REF], range partitioning is defined by a tuple (c, V ), where c is a column type and V is an ordered sequence of values from the domain of c. A relation is then split according to a range of values for a given set of columns.

• Hash: this mode decomposes the data applying a hashing function that is provided by the system to the partitioning columns.

• List: this mode splits a table according to a list of discrete values for the partitioning key of a column.

Another horizontal type combining the above single-level partitioning modes is named composite horizontal partitioning. In this strategy, a table is partitioned by one data distribution method and then each partition is subdivided into sub-partitions applying a secondary distribution method. This strategy comprises the following strategies Range-Hash, Range-List, List-Hash, Range-Range, and all possible combination of the single level methods. For example, the Aircraft table of our example could be partitioned by Developer first (list partitioning) and then apply a range partitioned on the Length attribute.

The referential horizontal partitioning allows to partition a table by leveraging an existing parent-child relationship [START_REF] Bellatreche | Referential horizontal partitioning selection problem in data warehouses: Hardness study and selection algorithms[END_REF] established according to a foreign key between two relations named the member and owner. It was introduced by Ceri et al. at the beginning of the eighties [START_REF] Ceri | Distribution design of logical database schemas[END_REF][START_REF] Ceri | Horizontal data partitioning in database design[END_REF] to optimize equi-join queries between the member and owner relations. The drawback of this partitioning mode is the fact that member tables may only be partitioned using a unique owner, even if its values reference to more than one owner tables. More details about this strategy are given in Section 1.4.1.2.

The list of partitioning types in this section is not exhaustive, however the missing strategies are variations of the types already presented. In the Table 1.2 we show the supported partitioning types in the most popular DBMSs. The hybrid partitioning column refers to a virtual column-based partitioning that allows the partitioning key to be an expression built on the row partitioning and it is efficient for storing columns individually in partitions. A third partitioning type named hybrid is a combination of the previous partitioning techniques. The hybrid partitioning process can be represented as a tree structure, as seen in [ ÖV11] in which vertical partitioning is followed by an horizontal fragmentation or vice-versa. This partitioning strategy creates much finer partitioning files and are a good fit for some applications needing the information at a lower granularity. A hybrid partitioning applied to the Aircraft table and its partition tree are shown in Figures 1.5a and 1.5b respectively. This partitioning strategy is supported by systems like Teradata as described in [START_REF] Al-Kateb | Hybrid row-column partitioning in teradata[END_REF].

ID

Main objective

The problem of optimally partitioning data over a centralized, distributed or parallel database system could at a first glance seem like the same. Even though if the expected output is a set of horizontal or vertical partitions, the main objective to create each partition is quite different according to the system's requirements. For example, let us consider a partitioning strategy in a distributed database replicating most of the tables in all sites to ensure a good performance in terms of retrieval query time. This strategy would produce a very poor result if the partitioning objective was to partition the system to improve its performance in terms of storage efficiency. We categorize the partitioning objectives as: • Response-time: the main objective consists to reduce the query access costs. This is measured as an average response time to solve a workload (queries and frequencies). We distinguish approaches that seek to minimize time in the most frequent queries, and others that look for covering the greatest spectrum of queries with acceptable performances.

• Concurrency: this objective deals with executing the maximum number of transactions in the minimum time. It is measured in terms of the system's throughput.

• Maintenance: The storage and update criteria are included in this category. This objective seeks to maximize the efficiency in terms of the utilization of resources like the hard-drive, network or primary memory. It also considers for example, the cost reduction of idle machines in a distributed systems.

• Combined: This objective considers the minimization of custom cost models (e.g., weighted combinations) of the operational costs and measures of the query response time. They provide a much more balanced solution but to the cost of complexity.

Mechanism

This dimension refers to the means used by partitioning techniques to accomplish the previously mentioned objectives. It is comprised of two alternatives:

• Clustering: Partitioning in centralized database systems seeks to minimize the transfer costs between the primary and secondary memory retrieving the records or attributes that are pertinent to the user's request. In distributed database systems the main goal is to avoid costly network communications by localizing the executions at the distributed system nodes where the data resides. In both cases, the data is clustered to form groups of tuples or attributes that are usually retrieved together. For centralized systems the record or attribute clusters are created in such way that ideally only the clusters containing the data requested by the user are loaded to main memory avoiding unnecessary disk access. In distributed systems, the data clusters are created in such a way that distributed transactions are averted.

• Declustering: In parallel database systems there is no need to maximize local processing at each node. This strategy could, on the contrary, be self-defeating to the system's load balance making one node to perform all the work while all the others remain idle. Data partitioning in parallel systems come to a trade-off between maximizing the response time for each individual query but at the cost of execution skewness or maximizing the intra-query2 and inter-query3 parallelism by means of partitioning. The partitioning strategy for these systems is called full partitioning or declustering as its main objective. Declustering strategies partition each relation across all the nodes of the system letting parallel database systems to exploit the I/O bandwidth of multiple disks by reading and writing them in parallel [START_REF] Dewitt | Parallel database systems: The future of high performance database systems[END_REF].

Algorithm

Finding the right set of partitions has been shown to be a very complex problem. The horizontal partitioning problem was proven to be NP hard [START_REF] Saccà | Database partitioning in a cluster of processors[END_REF][START_REF] Saccà | Database partitioning in a cluster of processors[END_REF], likewise the problem of finding vertical partitions applying an affinity graph [START_REF] Lin | A graph based cluster approach for vertical partitioning in database design[END_REF]. Horizontal and vertical partitioning were mathematically formalized and posed as optimization problems whereof solution does not scale properly without the use of heuristics. We categorize the solution algorithms with the following classes:

• Exact solutions: integer programming formulations for the partitioning problem. Firstly introduced to create vertical partitions using attribute clusters measuring their pairwise affinity [START_REF] Eisner | Mathematical techniques for efficient record segmentation in large shared databases[END_REF]. Then other mathematical techniques for record partitioning were proposed.

All of these formulations served as basis for heuristics used to prune alternative solutions and boost the algorithms' scalability. The objective function and constraints for these algorithms belong to the categories detailed in Sections 1.3.5 and 1.3.6 respectively.

• Heuristic solutions: these approaches do not guarantee to be optimal but find an approximate solution in a reasonable time.

-Cost based: These algorithms use heuristics to prune the solution space of alternatives to evaluate in a cost model as detailed in Section 1.3.5. Some alternatives use the query optimizer cost model to rank solutions to their performance.

-Sophisticated: these methods adapt heuristics from other domains to solve the data partitioning problem. For instance, graph partitioning heuristics are used by some partitioning algorithms to create fragments of attributes or records.

Cost Model

To objectively asses if a partitioning strategy improves the performance of the database system a set of metrics are established to define the criteria that determine a performant system. After all, without a well-defined metric it is impossible to decide which partitioning alternative is better than another one. Also, cost models are essential when predicting the real execution costs of a query a priori, without actually evaluating it. Cost models provide a simplified vision of a system, and are related to the objectives described above in the main objective dimension. We categorize the cost models as:

• Response-time: these cost models use the query response time to measure the system's performance based on the query access costs. The query response time is usually measured as the weighted average response time to solve a workload. The response time can be directly measured or estimated as a linear combination of the processing, I/O and network costs as shown in the equation [START_REF] Rao | Automating physical database design in a parallel database[END_REF]:

Cost(Q) = α • Cost CP U + β • Cost I/O + γ • Cost N etwork
This equation assumes that there is some overlap among the three components. To calculate the costs, the number of rows are estimated based on statistics. Among them we found the table cardinality, distinct values per column, number of pages in a table, and more data collected from histograms. For centralized systems the response time is dominated by the I/O costs that are estimated by the number of loaded disk blocks. The communication costs (i.e. Cost N etwork ) are the bottle neck in distributed database systems. For parallel database systems, the performance is dominated by the slowest machine of the cluster.

For a given workload, the costs are calculated for each of the queries and the global cost is given by:

Cost(w) = ∑ q∈W w(q) * Cost(q)
The w(q) corresponds to the weight of each query in the workload which can be for example the frequency.

• Throughput: the traditional database problem is to maximize throughput subject to constraints on response time. As claimed by [START_REF] Ganguly | Query optimization for parallel execution[END_REF], the problem could be also formulated as minimizing the response time subject to the constraints of the throughput. In this context, a sheer use of resources to reduce only the response time can lead to penalize the overall system's performance. To limit this phenomenon, some models have been proposed to limit the resources devoted to reduce the response time. Similarly, [START_REF] Rabl | Query centric partitioning and allocation for partially replicated database systems[END_REF] proposed the following relation to be minimized between the assigned and relative performance of the sites (B):

assignedLoad(B) load(B)
• Maintenance-based: the storage and update costs are included in this category. These cost models will penalize replication and measure how efficient in terms of the utilization of resources like the hard-drive, network or primary memory.

• Global-system: these cost models are weighted combinations of the operational costs for secondary and primary storage and a measure of the query response time. They provide a much more balanced solution but to the cost of complexity. Let us consider for example the cost model in [START_REF] Pavlo | Skew-aware automatic database partitioning in shared-nothing, parallel OLTP systems[END_REF]:

Cost(D, W) = (α × CoordinationCost(D, W)) + (β × SkewF actor(D, W)) α + β
In this case, the coordination cost is combined with a factor measuring the skewness of the partitioning strategy.

Constraints

The partitioning algorithms seek to optimize an objective function with respect to some variables in the presence of constraints. The following list summarizes the most common constraints:

• Partition size: this constraint is related to the limit in space, or processing resources.

• Partition number : this value is associated to the number of sites in the distributed or parallel architectures that will store the final data.

• Redundancy: whether the system allows to have multiple copies of the data to improve the query performance or ensure fault tolerance.

• Workload : this constraint refers to whether a predefined workload is known a priori to design the partitions.

Platform

This dimension considers the three types of database architectures:

• Centralized : only the interactions between the processor, primary and secondary memory are considered.

• Distributed : this dimensions include the Peer-to-Peer, Client/Server and Multi -Database Systems.

• Parallel : sub-divided in shared nothing, shared memory, shared disk and hybrid architectures.

System Element

In this dimension we consider whether the hardware element targeted by the partitioning approach. Among the components we can mention: primary & secondary memory, local area network, internet, cache and the processor.

Adaptability

This dimension classifies partitioning strategies into static and dynamic. The difference depends on whether the partitioning describes the procedure that is performed when declaring the database and it never changes, or if it includes describes strategies carried out after executing several workloads and the system is able to adapt its partitioning. The details of both strategies are given below.

• Offline: the database designer decides at the creation of the database how the data will be partitioned. This is achieved thanks to a requirement analysis phase in which the needs of the final users and the available resources are gathered. Most recently, automatic physical design advisors automatically select the proper partitioning configuration for a given workload. These advisors are supported by many commercial and academic database systems to help non-expert designers to select the most adequate partitions, indexes and materialized views. As mentioned in the introduction of this chapter, recreating partitions can be very expensive since the database needs to be disrupted and this is not always possible.

• Online: approaches following this strategy monitor and periodically adapt the database to fit the observed workload/incoming data. Ideally the system is able to adapt to changing workloads and data maintaining the database up-to-date at a reasonable performance.

Data model

In this section we classify the partitioning strategies according to the data model used to logically represent the data. We include in this category the relational model and the models directly derived from this. We include then:

• Relational: introduced in the early seventies by Edgar Codd in [START_REF] Codd | A relational model of data for large shared data banks[END_REF] where the data are represented as tuples grouped in relations. Most of relational database systems use the SQL definition query language providing a declarative method for specifying data and declaring queries. The entity relationship (ER) data model introduced by Peter Chen in [START_REF] Peter | The entity-relationship model -toward a unified view of data[END_REF] is well suited to represent relational data. Its components are readily translated to relations. ER modelling is based on two concepts:

-Entities: defined as tables that hold information and,

• Object-oriented: in this data model information is represented as objects, as it is done in object-oriented programming. This data model, introduced since the early eighties, is a hybrid of both the relational and object-oriented programming.

• Deductive: the deductive data model involves the application of formal logic to the problems of data definition, manipulation and integrity. The model provides the possibility to retrieve not only explicitly stored data but logically inferred data as well. The model was introduced in 1984 in the work of [START_REF] Reiter | Towards a logical reconstruction of relational database theory[END_REF] which gave the declarative semantics of deductive databases. The query and declaration language used for this model is based on the declarative programming language Datalog, a subset of the logic programming language Prolog. Among the query language we have the language ESQL introduced by Galdarin and Valduriez in [START_REF] Gardarin | ESQL: an extended SQL with object and deductive capabilities[END_REF].

• Dimensional: it is the model embraced in the data warehouse design. Introduced by Ralph Kimball in [START_REF] Kimball | Why decision support fails and how to fix it[END_REF] as a solution to decision support systems and business intelligence in contrast the entity relationship data modeling already established in the nineties. In this work, the author claimed that Entity-Relation modelling works fine for Online Transaction Processing (OLTP) workloads but fails to solve analytical queries. As described in [START_REF] Golfarelli | The dimensional fact model: A conceptual model for data warehouses[END_REF], the dimensional data model consists of a set of fact schemes whose basic elements are facts, measures, dimensions and hierarchies. Facts model an event occurring in the company (e.g., a sale), measures are typically numerically valued attributes describing a fact and dimensions are hierarchically organized discrete values to facts.

Partitioning approaches

This section focuses on describing partitioning approaches organized with the partitioning dimensions described in Section 1. The schema of this section is given in Figure 1.7. We start explaining the the vertical partitioning algorithms in distributed and centralized systems. Then we detail horizontal approaches in distributed and centralized architectures. Finally we discuss horizontal declustering strategies in parallel platforms. We highlight whether the approach is a heuristic or exact algorithm.

Platform • Centralized • Distributed • Parallel Main objective • Response-time • Concurrency • Maintenance • Combined System element • Disk • Memory • Network Data model • Relatinal • Object-oriented • Deductive • Dimensional Problem Constraints • Partition size • Partition number • Redundancy • Workload Type • Horizontal • Vertical • Hybrid Mechanism • Clustering • Declustering Algorithm • Exact • Heuristics Adaptability • Offline • Online Solution Cost model • Response-time • Throughput • Maintenance-based • Global
In what follows we use the words fragment and partition indistinctly to denote each of the sub-relations obtained after a partitioning process.

Vertical

This partitioning strategy divides a relation on its attributes. Specifically, given a relation R vertical partitioning produces the subrelations R 1 ...R v such that each R i contains a subset of R's attributes and its primary key attribute. Formally, consider C(R) = {c * 1 , • • • , c n } as the set of R's attributes and c * 1 as the primary key attribute. For simplicity we consider only single attribute primary key, if there are more keys the c * 1 contains the set of primary key attributes. The set of sub-tables of R is {g 1 , ..., g k } such that each g contains a disjoint subset of the non-primary key attributes as well as the primary key of R [ ÖV11, ANY04] and g 1 ▷◁ g 2 • • • ▷◁ g k = R. The primary key in each g is used to be able to rebuild the original table. This partitioning strategy is more complex than horizontal fragmentation because of the bigger number of available choices [ ÖV11]. It is useful when the application queries access only to a small subsets of columns in a table reducing the amount of data to be scanned to answer the query [START_REF] Agrawal | Integrating vertical and horizontal partitioning into automated physical database design[END_REF].

Approaches to create vertical partitions exist since the seventies when Hoffer and Severance [START_REF] Hoffer | The use of cluster analysis in physical data base design[END_REF] measured the affinity between pairs of attributes to cluster them according to their pairwise affinity. They found the attribute's clusters using a heuristic based on the bond energy algorithm. Their motivation is to allow queries to deal with smaller relations, loading sub-relations with only the necessary attributes in main memory when a memory hierarchy is supported. This approach served later as basis to the algorithm detailed in [ ÖV11] and the work of [START_REF] Mehta | Differential bond energy algorithm for optimal vertical fragmentation of distributed databases[END_REF]. Their work was modeled later as an integer programming problem in [START_REF] Hoffer | An integer programming formulation of computer data base design problems[END_REF]. The exact algorithm presented in this paper does not use any heuristic to be solved and consequently does not scale for bigger relations. Eisner and Severance proposed in [START_REF] Eisner | Mathematical techniques for efficient record segmentation in large shared databases[END_REF] a heuristic technique using a network representation of the interactions of the users with the attributes of each record. The complexity of the problem was studied by Niamir in 1978 in [START_REF] Niamir | Attribute partitioning in a self-adaptive relational database system[END_REF] which proved that the number of partitions equals to the B(m) (m th Bell number). For instance, a relation of 10 attributes, can be partitioned in more than 115,000 ways.

Niamir B. and Hammer M. proposed in [START_REF] Hammer | A heuristic approach to attribute partitioning[END_REF] a system to automatically select attribute partitions using the hill-climbing heuristic to select the candidate partition whose evaluation cost is minimal. The candidates are obtained using a pairwise grouping-attribute regrouping heuristic, named grouping (also known as bottom-up approaches), which starts assigning each attribute to one fragment and at each step joins some of the fragments to the initial one if the cost is minimal. Similar to this work, thirty years later the work named HillClimb [START_REF] Hankins | Data morphing: An adaptive, cacheconscious storage technique[END_REF] focused on data layouts proceeds as follows: it starts finding two partitions (initially single attributes) which, when merged, provide the best improvement in terms of expected query costs. The algorithm stops iterating when there is no improvement in expected query costs.

Similarly, [START_REF] Saccà | Database partitioning in a cluster of processors[END_REF] propose grouping heuristics for centralized and distributed databases respectively. A most recent modeling was proposed in [START_REF] Rasmus Resen | Vertical partitioning of relational OLTP databases using integer programming[END_REF] in which the costs in terms of read, written and transferred bytes are estimated with a cost model given a database schema and a workload. The proposed cost model is extended to handle load balancing as well instead of just minimizing the sum of transfer/access costs. The author showed that finding the minimum cost model is an NP-hard problem and proposed two solution strategies: quadratic programming and simulated annealing. Their experiments performed using the H-Store database showed the feasibility and effectiveness of the cost model.

The results of the teams of Hoffer and Severance were extended by Navathe et al. in 1984 in [START_REF] Shamkant | Vertical partitioning algorithms for database design[END_REF]. In this work the authors propose a two-phase approach to obtain vertical partitions. The method performs clustering using an affinity matrix of attributes as the one shown in Figure 1.8. The numbers on the table represent the number of transactions in which both attributes appear together, for example the attributes ID and Model appear together in 15 transactions of an assumed workload. Then, with this result, the method uses a binary partitioning technique on the clustered attributes to determine the partitions. The work is used as basis in [START_REF] Cornell | A vertical partitioning algorithm for relational databases[END_REF] where it is adapted to relational databases and later in [START_REF] Ceri | Optimization problems and solution methods in the design of data distribution[END_REF] the work was extended decomposing the design process into several sub-design problems. These heuristic algorithms, named splitting (also known as top-down) heuristics, start in general with a relation and partitions it at each step based on some objective function. Most recently, the grouping approach detailed in [START_REF] Bobrov | Workload-independent data-driven vertical partitioning[END_REF] proposes an algorithm that independently of the workload and using only the database logical scheme derives functional dependencies between the attributes with TANE -a popular functional dependency extraction algorithm.

More sophisticated approaches to create vertical partitions using graphical algorithms are found in the works of Navathe et al. in [START_REF] Shamkant | Vertical partitioning for database design: A graphical algorithm[END_REF]. In their work the authors mapped the affinity matrix to a graph with weighted edges that is partitioned using a technique expanding the graph's spanning tree. Similar techniques are applied in [START_REF] Lin | A new graphical method of vertical partitioning in database design[END_REF]. Most recently, more heuristics have been considered to obtain vertical fragments. A genetic algorithm was used in [START_REF] Du | Genetic algorithms based approach to database vertical partition[END_REF] to explore the set of candidate solutions. Besides association rules from data mining have been used to create clusters of partitions in [START_REF] Rozenberg | Association rules mining in vertically partitioned databases[END_REF] for instance. All of the approaches described above seek to minimize the response time by clustering the attributes according to a workload. A more recent approach [DPP + 19] consider the feasibility of a general machine learning techniques, specifically deep reinforcement learning, to find the right vertical partitioning scheme matching a workload. Some works present automatic database attribute clustering for single and distributed computers. For example, [START_REF] Li | Autonomous database partitioning using data mining on single computers and cluster computers[END_REF] proposed an algorithm called AutoClust to automatically vertically partition a database. Their algorithm is based on closed item sets mined from queries of the workload and their attributes using rule mining. It can be divided in five steps: 1. Attribute usage matrix generation. 2. Attributes mining. 3. Primary key addition to the proposed partitions. 4. Generate execution tree, with a candidate attribute clustering in the leafs. 5. Submit solutions to the query optimizer to select the optimal vertical partitioning schema. Their algorithm is optimizer-integrated, meaning that it uses the query optimizer as a black box to perform the optimization using what-if calls.

A complete experimental survey of some of the work mentioned in this section was done in [START_REF] Jindal | A comparison of knives for bread slicing[END_REF]. This work discusses six vertical partitioning algorithms under the same experimental setting. They concluded that the HillClimb algorithm presented in [START_REF] Hankins | Data morphing: An adaptive, cacheconscious storage technique[END_REF] is the best one in terms of the criteria defined in their paper. Some of the partitioning techniques in this study are presented in the sections 1.4.3 and 1.5 where we detail online partitioning algorithms and partitioning in recent large-scale platforms. The results of this section are summarized in Table 1.4. Grouping Complexity study [START_REF] Rasmus Resen | Vertical partitioning of relational OLTP databases using integer programming[END_REF] Grouping Global cost model [START_REF] Hoffer | The use of cluster analysis in physical data base design[END_REF] Heuristic Splitting Bond energy algorithm (BEA) [START_REF] Eisner | Mathematical techniques for efficient record segmentation in large shared databases[END_REF] Network representation [START_REF] Shamkant | Vertical partitioning algorithms for database design[END_REF] Affinity matrix [START_REF] Shamkant | Vertical partitioning for database design: A graphical algorithm[END_REF] Graph partitioning [START_REF] Lin | A new graphical method of vertical partitioning in database design[END_REF] Graph partitioning [START_REF] Bobrov | Workload-independent data-driven vertical partitioning[END_REF] Functional dependency [START_REF] Hammer | A heuristic approach to attribute partitioning[END_REF] Grouping Hill-climbing [START_REF] Hankins | Data morphing: An adaptive, cacheconscious storage technique[END_REF] Hill-climbing [START_REF] Du | Genetic algorithms based approach to database vertical partition[END_REF] Genetic algorithm [START_REF] Rozenberg | Association rules mining in vertically partitioned databases[END_REF] Association rule mining [START_REF] Li | Autonomous database partitioning using data mining on single computers and cluster computers[END_REF] Association rule mining [DPP + 19] Deep reinforcement learning

1.4.1.

Horizontal

Horizontal partitioning splits a relation along its tuples, it was explicitly defined shortly after vertical partitioning in 1978. However, contrarily to the works describing vertical partitions, the algorithms to partition the data horizontally were introduced a few years later.

Centralized and distributed platforms The efforts towards the characterization of horizontal fragments started with Ceri et al. in 1982 in [START_REF] Ceri | Horizontal data partitioning in database design[END_REF] with the introduction of the min-term predicates. A min-term predicate is the combination of simple predicates whose definition is given in Definition 1.2. A minterm predicate m j is the conjunction of simple predicates in their natural or negated form (i.e. ¬p j ) such that m j does not contain contradicting simple predicates.

Definition 1.2 (Simple predicate) [ ÖV11] Given a relation R and one of its attributes c i , a simple predicate p j is defined on R as p j : c i θ V where θ ∈ {=, ̸ =, <, >, ≤, ≥, } and V is any value chosen from the domain of c i .

The horizontal partitioning process of a relation R is described as the set of tuple groups

G = {g 1 , • • • , g k } such that each group g ∈ G is defined by a set M = {m 1 , • • • , m k } of min-term predicates. Each g i corresponds to a partition of the relation R if ⋃ g i ∈G g i = R and ⋂ g i ∈G g i = ∅.
The previous conditions are known as completeness and reconstruction fragmentation rules respectively. Ideally the partition groups are balanced and they correspond to the application groups queried by the application, however the selection of the optimal minterm predicates has been showed to be an NP hard [START_REF] Saccà | Database partitioning in a cluster of processors[END_REF] problem.

The min-term predicates algorithm was complemented by Özsu and Valduriez in [ ÖV11] where the COM MIN and PHORIZONTAL algorithms are described. In simple words, the main steps of the algorithm are:

1. Generation of min-term predicates (COM MIN algorithm), 2. Simplification of min-terms eliminating redundant and useless terms (PHORIZONTAL algorithm), and 3. Generation of partitions (or fragments).

Following the example of Figure 1.4a, the predicates σ Dev= ′ Airbus ′ and σ Dev= ′ Boeing ′ are the min-predicates of the partitions shown in the Figure . To avoid redundancy, in this section we discuss only the generalities of horizontal partitioning approaches. Specific horizontal strategies are discussed in Section 1.4.2 to avoid redundancy.

Parallel platforms In parallel processing systems there is no need to localize the query execution in a single node. The objective of parallel systems is to use partitioning for parallelizing and load balancing query executions across the nodes of the cluster as a mean to improve the database performance when answering a workload. The problem was firstly formalized by Sacca D. and Wiederhold G. in [START_REF] Saccà | Database partitioning in a cluster of processors[END_REF]. In this work, the differences between parallel and distributed system were clearly stated. The authors proved that finding a feasible and optimal solution for the partitioning problem in a parallel environment is NP-hard. An important trade-off should be considered when only a few tuples satisfy the selection operator of a query. Ideally in this situation, the partitioning strategy should localize the tuples that satisfy the query across only a few processors minimizing the communication overhead associated with the synchronization and scheduling. Conversely, for complex queries a full declustering may seem like the most interesting strategy. This compromise makes partitioning in parallel systems much more complex [ ÖV11]. We distinguish clearly two main horizontal partitioning strategies in parallel platforms: single-attribute and multi-attribute declustering. The first high performance DBMS multiprocessor databases introduced in the eighties comprise systems like Gamma [DGG + 86], Bubba [START_REF] Wilkinson | KEV -A kernel for bubba[END_REF] and Volcano [START_REF] Graefe | Volcano -an extensible and parallel query evaluation system[END_REF]. In such systems, relations are generally horizontally partitioned across multiple processors. When the entire relation is distributed among all the nodes of the cluster the mechanism is called declustering as we previously mentioned. The most widely single-attribute declustering strategies are the following [DG92]:

• Round-robin: this strategy sequentially sends the i th tuple to the (i mod n) partition.

• Range: distributes the tuples according to intervals of some attribute.

• Hashing: a hashing function specifying the placement of a tuple in a particular disk is applied to a tuple's attribute.

The decision on which hashing function to apply or which range to use in a specific key are left to the database designer's criteria. The strengths and drawbacks of each strategy are summarized in Table 1.5.

A major drawback of the hashing and range strategies supported by parallel systems is that neither can de-cluster a relation on more than one attribute. Several multi-attribute strategies were proposed to overcome this issue. We classify these approaches based on their objectives as presented in [START_REF] Ghandeharizadeh | High performance parallel database management systems[END_REF]. They are organized in Table 1.6, we give an overview of each of the approaches. Optimize processing of join operators.

DYOP [OO85] Multi-attribute partitioning [HL90]

Let us start with the strategies striving to localize to a few nodes the execution of a query referencing a partitioning attribute. This group of strategies is appropriate for systems that suffer from the overhead to coordinate multi-site queries. We describe two of the main works: the Multi-Attribute GrId deClustering (MAGIC) [START_REF] Ghandeharizadeh | MAGIC: A multiattribute declustering mechanism for multiprocessor database machines[END_REF] and Bubba's Extended Range Declustering (BERD) [BAC + 90]. MAGIC is an extension of the Hybrid-Range partitioning strategy published in [START_REF] Ghandeharizadeh | Hybrid-range partitioning strategy: A new declustering strategy for multiprocessor database machines[END_REF] that strikes a compromise between the sequential execution paradigm of range declustering and the intra-query parallelism achieved with hash and round-robin.

MAGIC builds a grid directory on a relation such that each entry in the two-dimensional grid represents a relation's fragment. To determine which attributes and ranges should be used to build the grid, MAGIC uses the frequencies of queries containing individual attributes and the average resource requirements (e.g., disk accesses, network). An example of such grid is shown in Figure 1.9 where each entry of the grid represents a fragment of the relation. Each partition would be assigned to a single processor if to enhance the system's throughput.

Developer

Boeing Airbus

Cost 0-150 1 2 150-300 3 4 300-450 5 6

Figure 1.9: MAGIC grid example BERD [BAC + 90] fully partitions a relation across the nodes of the cluster using the primary partitioning attribute value in the first place. Then for each of the secondary attributes an auxiliary relation is formed from the attribute's values with their respective identifiers and location. The tuples on these relations are range partitioned over multiple locations and the partitions at each location are indexed in the form of a B-tree index. When a query is submitted to the system, if it involves the primary attribute it is directed to the relevant location. For any other attribute, the system uses first the auxiliary relation to determine the appropriate location of the tuples. A study comparing both BERD and MAGIC is presented in [START_REF] Ghandeharizadeh | A performance analysis of alternative multi-attribute declustering strategies[END_REF] in which the superiority of MAGIC over BEARD is manifested.

The second type of approaches is appropriate for workloads in which the overheads due to parallelism are shaded by the performance gain of splitting the work on different nodes. This approaches include: Disk Modulo (DM) [START_REF] David | Disk allocation for cartesian product files on multiple-disk systems[END_REF], Fieldwise Xor (FX) [START_REF] Kim | Optimal file distribution for partial match retrieval[END_REF], Error Correcting Codes (ECC) [START_REF] Faloutsos | Disk allocation methods using error correcting codes[END_REF] and the Hilbert Curve Allocation Method (HCAM) [START_REF] Faloutsos | Declustering using fractals[END_REF]. They are clearly described in [START_REF] Moon | Scalability analysis of declustering methods for multidimensional range queries[END_REF] using Cartesian product files, a multi-attribute file structure for partial match and best match queries very similar to the grid files presented before.

Let us start with the Disk Modulo method, which assigns a bucket [i 1 , i 2 , ..., i d ] to a disk unit as:

i 1 + i 2 + ... + i d mod M
where M is the number of available disks. This strategy is optimal for partial match range queries. For the matrix of Figure 1.9, before adding up the values of each i, the values (or range) are mapped to an integer. The XOR declustering is optimal when the number of disks and the size of each field is a power of two. The assignment formula of this approach applies the bitwise XOR operator ⊗ to the binary values of the bucket coordinates [i 1 , i 2 , ..., i d ] as:

i 1 ⊕ i 2 ⊕ ... ⊕ i d mod M
where M is the number of available disks.

The vector-based declustering generates a pair of integer vetors for a given number of disks and allignts the buckets in a Cartesian product file with the vectors. The Hilbert Curve Allocation (HCAM) uses the Hilbert space-filling curve to impose a linear ordering on the buckets in the Cartesian product files. Then it traverses the buckets in the order assigning each bucket to a disk unit in a round-robin way. As shown in [START_REF] Moon | Scalability analysis of declustering methods for multidimensional range queries[END_REF], this strategy outpeforms the previous strategies for small range queries and large number of disks.

Finally we mention the group of strategies striving to optimize the processing of the join operator. The DYOP technique [START_REF] Ozkarahan | Dynamic and order preserving data partitioning for database machines[END_REF] partitions the data by repeatedly sub-dividing the tuple space of multiple attribute's domains. In order to execute a hash-join query efficiently, the size of each partition equals the aggregate memory of the processors in the system, the tuple's order is preserved as well. [START_REF] Kien | An adaptive data placement scheme for parallel database computer systems[END_REF] builds a grid file on the attributes used to join the partitioned relation with others. For example, let us consider the relations R(A, B, C), S(B, D) and T (C, E). Building a grid-file on the B and C attributes to partition R would minimize the number of tuples of R that are redistributed when it is joined with either S or T .

A simulation study of data placement issues in a shared-nothing system is presented in [START_REF] Mehta | Data placement in shared-nothing parallel database systems[END_REF]. They performed experiments in a simulation written in CSIM/C++ that was configured to simulate a SN database of 128 nodes. The drawback of their model is that the cost to shuffle data on the network is disregarded. They performed experiments to establish the optimal degree of Declustering (number of partitions). They presented results of declustering, response time for joins, indexes, skewness and different CPU configurations for parallel and sequential systems. They concluded that full declustering is a viable strategy for placing relations in a SN parallel database system. The evaluation is done using the average response time as metric.

Referential horizontal partitioning This strategy uses the database schema, specifically the member-owner relation between tables to generate partitions. The member-owner relation is illustrated in Figure 1 is defined between the two tables using the primary key of the owner relation and an attribute in the member relation (e.g c 1 o and c 1 m in Figure 1.10 respectively). It was first described by Ceri et al. in [START_REF] Ceri | Distribution design of logical database schemas[END_REF]. In this partitioning method, the owner relation is initially partitioned and the partitions of the member relation are obtained with a semi-join operation.

Formally let us consider two linked relations O, M being the owner and member relations respectively. If O is partitioned and {o 1 , • • • , o w } are the partitions, the horizontal partitioning of M is defined as M j = M ⋉ O j , 1 ≤ j ≤ w. When the member table has foreign keys pointing to more than one relation, the choice of the attribute used to partition the member relation is done according to: i) the attribute that would maximize performance for most applications and ii) the attribute that minimizes the joins costs between both relations [ ÖV11].

This partitioning strategy is supported by the commercial DBMS Oracle since its 11gR1 version. Its implementation is described in [ECS + 08] which highlights the key concepts of referential partitioning, the implementation challenges and an experimental study showing the performance gain sand other benefits of this partitioning strategy. They also explained how referential partitioning could be used to simulate vertical partitioning by breaking a table into two or more smaller tables with less columns in a parent-child relationship.

Hybrid

As described previously, this partitioning also known as nested occurs when a table is vertically partitioned and it is then partitioned horizontally (or vice versa). As mentioned in [ ÖV11], the number of levels of nesting can be large but it stops when each fragment consists only of a single tuple.

The only commercial DBMS supporting this partitioning strategy is Teradata. Their strategy detailed in [START_REF] Al-Kateb | Hybrid row-column partitioning in teradata[END_REF] relies on the file system storage layer which handles either row, column or combined partitions in the same internal way. Contrarily to the horizontal or vertical systems which are row or column-based respectively, Teradata file system is row-id based. A row-id identifies a row or parts of it, and at runtime the data are searched using this id. In this way, the file system is agnostic to the partitioning scheme. When a row is inserted in a table, a row-id is generated based on a hash value of the primary index columns.

Partitioning by data model

In this section we present the most relevant approaches by data model. We start chronologically with the relational data model, presenting the approaches applied to centralized and distributed platforms since the parallel approaches were described in the previous section. Then we move to object-oriented and deductive models and finally the dimensional data model.

Relational data model

Here we detail the most recent horizontal partitioning algorithms. We do not include vertical approaches in this section to avoid redundancy since they were fully discussed in Section 1. 4 For horizontal partitioning, we have already discussed the basic approaches in which the main concepts and algorithms are introduced. Let us start describing the approaches to deal with systems characterized by numerous short on-line transactions, in which partitioning seeks generally to increment the system's throughput. This is achieved mostly by reducing the number of distributed transactions. The approaches presented in this section are summarized in Table 1.7 in which we highlight the main strategy, its inputs and main objectives.

A very influent workload-aware partitioning approach named Schism was proposed by Curino et al. in [START_REF] Curino | Schism: a workload-driven approach to database replication and partitioning[END_REF]. Their system partitions the database using graph partitioning techniques and decision trees. They first considered an OLTP workload containing read and update queries and map the database to a graph. In their model, a node corresponds to a tuple and the edges connect tuples that are used within the same query. The nodes' weights correspond to the number of times the tuple is called in the workload or their size in bytes. This is exemplified in Figure 1.11. The interactions between the tuples 1 to 4 are shown in the inverted table showing the ID of the tuples and the queries they are part of (Figure 1.11a). The edges weights represent the number of times in the workload both nodes are connected. They expanded the graph to consider replication by adding n more copies to each node, where n is the number of edges connected to the node. When a partition is created, if two nodes of the same tuple are in the same partition, they are clearly not replicated. Contrarily, if two nodes of the same tuple are found in two different partitions then the tuples are replicated to ensure data locality. Using this graph, a partitioning heuristic (e.g., METIS) is applied and the data are divided in partitions. A decision tree is used to explain the obtained partitions, and to recreate a path leading to the final partitions using simple predicates. The red dotted line of Figure 1.11b represents the partitions after applying the graph partitioning heuristic. They evaluated their work using TPC-E and other databases taken from social networks.

In [START_REF] Pavlo | Skew-aware automatic database partitioning in shared-nothing, parallel OLTP systems[END_REF] Pavlo et al. presented an approach named Horticulture to automatically create horizontal partitions. Its main objective is to optimize throughput minimizing the number of distributed transactions and minimizing the access skew across servers. Their workload-aware partitioning algorithm is based on an adaptation of the large neighborhood search technique in which a cost model is used to estimate the coordination cost and load distribution for a simple workload. Their method starts with an initial best solution, obtained using measures from the workload and access patterns. It generates a set of neighbor solutions (called relaxing the initial solution) that are evaluated against the cost model (composed of the coordination and skewness cost). If they improve then the cost model then the solution is considered as best and it continues iterating.

Consens M. et al. presented divergent designs in [START_REF] Consens | Divergent physical design tuning for replicated databases[END_REF]. A divergent design installs a different physical configuration (e.g., indexes and materialized views) with each database replica, specializing replicas for different subsets of the workload. Queries are routed to the most suitable replica at runtime. They formalized the problem representing the cost of evaluating the workload and then using this cost formula to decide the best solution. In their experiments they used the DB2 Design Advisor to generate candidate solutions, and later each one was evaluated using the total cost formula that considers the trade off between load balance and specialized replicas. They presented a pruning strategy that was tested with two TPC workloads.

The system HOPE presented in [START_REF] Cao | HOPE: iterative and interactive database partitioning for OLTP workloads[END_REF] applies an hyper-graph clustering algorithm to generate partitions of a database considering a transactional workload. In their work, they generated tuple groups using the min-term predicates. These groups of tuples are the nodes of the hyper-graph, weighted with two values: the size of the tuple group and the number of transactions in the workload accessing the group. Each transaction in the workload is mapped to a weighted hyper-edge of the graph. HOPE partitions the hyper-graph using the hMetis4 package. The skewness of the partitions was regulated by a skewness factor.

Tran K. et al. proposed a Join Extension, Code-Based Approach in [START_REF] Khai | JECB: a join-extension, code-based approach to OLTP data partitioning[END_REF]. Their method examines the workload and the database schema to derive a partitioning strategy. It is called Code-Based since it inspect the SQL code of stored procedure to define join paths used to partition. The algorithm leverages partitioning by foreign key relationships to automatically identify the best way to partition tables using the attributes. After it combines the solution for each transaction in the workload to find the best global partitioning solution.

Zamanian et al. presented in [START_REF] Zamanian | Locality-aware partitioning in parallel database systems[END_REF] a partitioning scheme called predicate-based reference partition (PREF) that allows co-partition sets of tables. Their method is a modified version of the referenced horizontal partition, but it ensures full data locality replicating tuples in different partitions. Besides, they presented two partitioning algorithms (one schema-driven and other workload-aware) that incorporate PREF to find automatically the best partitioning scheme for a database. In the schema-driven algorithm they modeled the given database schema as an undirected graph, having as edges the referential constraints of the schema. Based on this graph, they decide which relations will be initially partitioned (using a hashing function for instance), and the other relations that will be partitioned following the same schema. They maximize data locality, trying to reduce the data replication.

In [DLL + 17], the authors present an approach to partition data and exploit the fact that in many recent database systems, data is replicated to increase the robustness and availability. Their method replicates data but each replica has a different partition structure. They start calculating the distance between queries of the workload based on the shared attributes. They later used a k -medoids to cluster the workload and generate a partitioning plan for each cluster and organize replicas with these plans. They assumed that the number of cluster is equal to the number of replicas.

Rabl and Jacobsen presented in [START_REF] Rabl | Query centric partitioning and allocation for partially replicated database systems[END_REF] an allocation strategy in shared-nothing data clusters. Their model allows replication to improve the performance of read only queries but it balances it to avoid low performances in update queries. Their model seeks to maximize the throughput while secondarily minimizing update and disk consumption overhead due to replication. For this, each query is run in a single node and replication of data between nodes is needed. Their model starts classifying the update or read queries of the workload according to the data they access. Each class is a different type of data fragment (e.g., horizontal or vertical fragment). Based on this classification, each group of queries is assigned to one or more data nodes. The allocation is calculated using heuristics to solve a linear programming problem balancing the load of query classes across the nodes and reducing the overall data replication.

Most recently, authors in [GLL + 20] proposed a general strategy named AlCo (AlCo, Allocate fragments based on Cost) for allocating fragments in a distributed database. AlCo evaluates multiple candidate allocation plans based on a cost model, which is realized by a modified genetic algorithm employed by PostgreSQL. Their cost model synthetically considers various factors to enable a generalization ability. Also, to reduce the risks caused by randomization of the genetic algorithm, AlCo provides an upper bound computed through current heuristic methods to improve the algorithm's robustness.

Object-oriented data model

The partitioning concept was smoothly adapted to this kind of databases in which an entity corresponds to a class instead of a relation. The partitioning strategies were explored firstly explored by Cook J. et al. in [START_REF] Cook | Partition selection policies in object database garbage collection[END_REF] investigating methods to improve the performance of the garbage collector, in which a subset of the entire database is collected independently from the rest.

A framework for class partitioning in OODB was proposed by Karlapalem K. and Li Q. in [START_REF] Karlapalem | Partitioning schemes for object oriented databases[END_REF][START_REF] Karlapalem | A framework for class partitioning in objectoriented databases[END_REF]. Their framework devises partitioning schemes based on different types of methods and their classification. The horizontal fragmentation process in OODB is defined as a process for reducing the number of disk entries to execute a query reducing the number of irrelevant objects accessed. Vertical fragmentation strives to reduce the irrelevant attributes accessed when querying a class.

Horizontal class partitioning: It was pioneered by Bellatreche et al. in [START_REF] Bellatreche | Horizontal class partitioning in object-oriented databases[END_REF] and extended in [START_REF] Bellatreche | Algorithms and support for horizontal class partitioning in object-oriented databases[END_REF]. In these works the authors presented horizontal fragmentation based on a set of queries and develop strategies for primary horizontal partitioning. In [START_REF] Bellatreche | Derived horizontal class partitioning in oodbs: Design strategies, analytical model and evaluation[END_REF], the problem of derived class data partitioning has also been studied.

Vertical class partitioning:

A cost-driven approach to study the effectiveness of data partitioning in OODBs in terms of reducing the number of disk accesses when executing a query was proposed by Fung C. et al. in [START_REF] Fung | Cost-driven vertical class partitioning for methods in object oriented databases[END_REF]. [START_REF] Gajanan | Method transformations for vertical partitioning in parallel and distributed object databases[END_REF] proposes a unified view of the vertical partitioning problem and a set of transformation rules for various vertical partitioning methods.

Deductive data model

The partitioning problem in deductive database was covered by Mohania M. et al. in [START_REF] Mukesh | Some issues in design of distributed deductive databases[END_REF]. Deductive database addresses the design of distribution of both the database and the rules. In this work the authors considered the minimization of data communication cost as the primary rules from allocation. The problem is modeled as a directed acyclic graph, where nodes represent rules or relations and arcs represent dependencies or usage of relations by rules. A heuristic is then proposed based on successively combining adjacent nodes.

Another approach was presented by Neumann K. et al. in [START_REF] Neumann | Partitioning algorithms for a distributed deductive databases[END_REF]. This paper presents the algorithms necessary to partition a deductive database represented as an Extended Predicate connection Graph (EPCG). The objectives that the system seeks to attain are the equalization of storage and processing costs, distributing the base relation nodes in an effective manner and preserving the locality.

Dimensional data model

As it was mentioned in Section 1.3.10 this data model is embraced by data-warehouses. This data model illustrated in Figure 1.12 in which a fact table (Maintenance table) is surrounded by the dimension tables (Aircraft, Developer, Date and Procedure) in a star-schema. Data warehouses had its boom in the nineties and it was at the end of this decade that the first partitioning strategy for parallel data-warehouses was proposed by Stöhr T. et al. in [SMR00]. In their work, the authors presented an allocation that considers relational data warehouses based on a star schema and utilizing bitmap index structures. Their experiments were developed in a "Shared Disk" architecture. They proposed a multi-dimensional hierarchical fragmentation of the fact table based on multiple dimension attributes. To fragment, they used a technique called "point fragmentations" that creates one horizontal fragment per value of the dimension. If it is done with for example two dimensions, having m and n as number of different values respectively, the maximum number of fragments is n * m. Bitmap indexes are fragmented using 1.12: Star-schema example the same logic as the fact table. A simple round robin allocation of fact fragments to the disks is used.

In parallel, [START_REF] Bellatreche | What can partitioning do for your data warehouses and data marts?[END_REF] presented an algorithm for fragmenting the tables of a star schema (e.g., Figure 1.12). They mentioned that during the fragmentation process, the choice of the dimension tables used to fragment the fact table plays an important role in the overall performance. They develop a greedy algorithm to choose "best" dimension tables to perform the partitioning of the fact table.

Bellatreche et al.

[BBM07] followed Stöhr's direction focusing on horizontal partitioning and bitmap join indexes in the context of centralized data warehouses. They proposed an algorithm to select simultaneously these structures in order to reduce the query processing cost. The algorithm uses the horizontal partitioning schema injected to a genetic algorithm to prune the search space when selecting the bitmap join indexes. Also, they proposed a greedy algorithm to select bitmap join indexes under a storage bound.

In [START_REF] Bellatreche | Referential horizontal partitioning selection problem in data warehouses: Hardness study and selection algorithms[END_REF] the referential horizontal partitioning was formalized for the dimensional data model. In this study, the authors gave a formalization of the referential fragmentation schema selection problem in the data warehouses studying its hardness to select an optimal solution. They proposed as well two heuristics to the selection problem: hill climbing and simulated annealing with several variants to select a near optimal partitioning schema.

The work of [START_REF] Alexandre | Adaptive virtual partitioning for OLAP query processing in a database cluster[END_REF] introduces a fined grained virtual partitioner which dynamically adapts partition sizes, without any knowledge about the database and the DBMS. Their proposal is to have an initial number of virtual partitions greater than the number of participating nodes. In this way each cluster node processes a set of small, light-weight sub-queries. In their algorithm, each node in the shared-nothing cluster contains a copy of the database. The idea is to partition each query (e.g., by range) on each node, such that each node is in charge of processing one specific query range. In this way, at query runtime many sub queries of the original query are produced per node. The goal is to achieve intra-query parallelism in OLAP query processing. To ensure good performance, there must be a clustered index associated to the partitioning attribute and also a uniform value distribution on the partitioning attribute.

Finally, a more recent work [START_REF] Yoon-Min | A graph-based database partitioning method for parallel OLAP query processing[END_REF] proposed a novel graph-based database partitioning

I b M c C d S e DB2 Index Advisor [RZML02] ✓ ✓ ✓ ✓ Parallel DB2 Index Advisor [ZRL + 04] ✓ Microsoft SQL Server [ANY04] ✓ ✓ ✓ AutoPart [PA04] ✓ Parallel Microsoft SQL Server [NB11] ✓ ✓ Parinda [MDA + 10] ✓ ✓ Oracle 11g ✓ ✓ ✓ ✓ SOAP [CZC15] ✓ Deep Reinforcement Learning [HBR19] ✓ a Partitioning, b Index, c Materialized views, d
Clustering, e Storage management method called GPT that improves query performance with lower data redundancy. The authors claim that existing partitioning methods, specifically PREF [START_REF] Zamanian | Locality-aware partitioning in parallel database systems[END_REF], have a few major drawbacks such as a large amount of data redundancy and not supporting join processing without shuffle in many cases despite their large data redundancy. They pointed that this partitioning strategy is not optimal to treat analytic queries (OLAP) and that GPT is more suited for star and snowflake schemas in data-warehouses. They elucidate that the drawbacks arise from the tree-based partitioning schemes in PREF.

Partitioning by adaptability

We enumerate the offline and online partitioning strategies. We start with the offline partitioning strategies, specifically the available design advisors to initially partition a relational database.

Partitioning wizards are a complement of the strategies previously presented. Then we depict dynamic partitioning, or on-line data reorganization as called in [SKS + 97].

Partitioning advisors

Due to the complexity of the problem of selecting the optimal partitioning design for a database, a number of commercial and academic tools have been proposed to assist administrators and non-expert users in the task of choosing the most adequate partitioning schema for a workload.

As it was mentioned in Section 1.2.1 data partitioning is not the only optimization technique to enhance the system's performance. Indexes and materialized views are suggested as well by some advisors considering the impact of the interaction and dependencies between these optimization strategies. The cited works are summarized in Table 1.8 in which we mention for each advisor the optimization strategies that it proposes. As it is shown in the table, the partitioning technique is the only optimization technique supported by all advisors. The first automatic selection of table partitioning in parallel shared-nothing database systems was presented by Rao J. et al. in [START_REF] Rao | Automating physical database design in a parallel database[END_REF]. They presented a solution that given a workload and their frequency of occurrence, determines the most optimal partitioning using an integrated solution with the query optimizer of the DB2 DBMS. In contrast to what was previously proposed, they built a partition advisor to automate the process of partition selection exploring the cost model of the query optimizer itself. To do this, they added two additional modes to the query optimizer: the recommend partition and evaluate partition modes. In the first mode, the optimizer will generate candidate partitions for each table involved in a query of the workload. The candidate set of partitions is not limited to this set, in recommend mode the optimizer generates candidate partitions considering replication, and combinations of individual columns in the tables involved in a query. After, the query optimizer generates a plan based on these candidate partitions and it stores the plan in a table. The cost of each partition is evaluated by the optimizer using two different strategies: sampling and deriving. Both strategies adjust the value obtained when applying the cost function to the original statistics of the database. The evaluate partition mode performs a Rank-based enumeration of the whole set of partitioning configurations proposed in the candidate partitions table. Then using a customized cost function proposed the best partitioning model. They explored other ways of combining the models like genetic and other search algorithms but their results worked better in rank-based enumerations.

The DB2 advisor presented in [ZRL + 04] was the first tool recommending indexes, materialized views and partitions by considering their interactions. The authors identified two types of dependencies between indexes, materialized query tables, data partitioning, and multidimensional clustering: weak and strong. A technique t i is "strongly" dependent on technique t j , if a change in selection of t j often results in a change in that of t i . Otherwise, we say t i "weakly" depends on t j . They showed that a weak dependency exists between data partitioning, indexes and multi-dimensional clustering. In contrast to the strong dependency between data partitioning and materialized query tables, knowing this interaction allows coupling data partitioning and other optimization techniques. For instance, in the case, when data partitioning cannot optimize all queries (due to the constraint representing the number of final fragments generated by a data partitioning algorithm), it will be then augmented by other techniques.

The work in Fractured Mirrors by Ramamurthy R. et al. detailed in [START_REF] Ramamurthy | A case for fractured mirrors[END_REF] is not specifically a partitioning advisors. However, their work was used later in the advisor proposed in [START_REF] Agrawal | Integrating vertical and horizontal partitioning into automated physical database design[END_REF]. The Fractured Mirrors paper presents a partitioning model that takes advantage of redundant storage used in some database systems to provide tolerance to disk failures. They considered two disks in a mirror being logically identical but physically different. In particular, one copy of each table is stored using the Decomposition Storage Model (or vertical), and one is stored in a N-ary Storage Model (or horizontal). In their work they first revisited some performance problems associated with the vertical model. After they propose an indexing strategy to overcome the drawbacks presented in last section, specially the reconstruction algorithms. Their strategy based on a B-Tree showed a dramatic increase of performance over the naive implementation. that considered both horizontal and vertical partitions.

Agrawal S. et al. proposed a workload-aware solution to the problem of automating physical design in a single node in [START_REF] Agrawal | Integrating vertical and horizontal partitioning into automated physical database design[END_REF]. Their solution takes both performance and manageability into account. In their paper they presented an integrated approach to automate physical design, considering horizontal and vertical partitioning, indexes and materialized views. They presented the complexity proof of the problem and the need to apply pruning techniques to reduce the large search space of solutions. They defined the physical design problem and presented the interactions arising from inclusion of horizontal and vertical partitioning. Their system architecture is composed of 4 main modules: 1) Column group restriction, 2) Candidate selection, 3) Merging, and 4) Enumeration. In the column group restriction step, the system selects column groups that are relevant for the workload (a column is relevant if it can be used to answer one or more queries in the workload). This step eliminates columns that will never help to optimize the workload. The candidate selection step uses a Greedy (m,k) algorithm to select for each query a relative optimal configuration. In the merging step, new physical structures are added to the set of candidates. This new physical structures are generated merging vertical partitions that are output of Candidate Selection. Next for each vertical partition, they merged all indexes and materialized views relevant for that vertical partition taking horizontal partitioning into account. The idea is to avoid over-specialized physical design structures and to build structures that benefit the entire workload. The Enumeration step takes as input the candidates and produces the final solution.

Nehme R. et Bruno N. proposed in [START_REF] Rimma | Automated partitioning design in parallel database systems[END_REF] a partitioning advisor for parallel database systems that recommends the best partitioning design for an expected workload. Their tool recommends which tables should be replicated, and which ones should be distributed according to specific columns. The developed techniques are deeply integrated with the parallel query optimizer, having a much more accurate recommendation in a shorter time. They assumed that when a table is partitioned it is hash-partitioned in a single column and also that the database statistics for cost estimation are always available. They claim that similar approaches do not use the query optimizers as they do, since previous works consider it as a black box and only use it to perform what if analysis (e.g., Rank-Based and Genetic algorithms to generate possible solutions to be evaluated by the optimizer). In their solution the query optimizer is an active part of the recommender, they use the physical and logical trees produced for each query to generate a data structure containing the candidate tables to be replicated and partitioned using the interesting columns (defined also on the paper).

Parinda [MDA + 10] is a partitioning advisor for an open source DBMS (PostgreSQL). As the previously mentioned advisors, it uses the query optimizer to estimate the benefit of the design structure simulating the design features efficiently. Their algorithm uses the work of AutoPart [START_REF] Papadomanolakis | AutoPart: Automating schema design for large scientific databases using data partitioning[END_REF], an algorithm that automatically partitions the database tables to optimize sequential access assuming prior knowledge of a representative workload. The simulations are achieved not achieving by writing the actual optimization features to disk but rather modifying the statistics used by the optimizer to solve a query. The advisor proposes both partitions and indexes to the database administrator.

From Oracle 11g a Partition Advisor5 is part of the SQL Access Advisor recommending a partitioning strategy for a table based on a supplied workload of SQL statements.

Most recently, the work of [HBR19] introduced a learned partitioning advisor for analytical OLAP workloads based on Deep Reinforcement Learning (DRL). The main idea is that a DRL agent learns based on experience by monitoring the behavior of different workloads and partitioning schemes. Their experiments showed that their advisor is able to adapt to different deployments and it outperforms existing automatic partitioning approaches.

Online partitioning

The dynamic partitioning approaches treat the problem that the load on the DBMS does not remain static fluctuating constantly according to the change on the user's needs. The changes come either from the workload or from new data that is being added and that should be assigned to a specific partition. Next, we present partitioning strategies that allow the creation of elastic systems automatically re-organizing the data depending on the load or data changes. The approaches are summarized in Table 1.9.

Let us start with the work of [START_REF] Alexandre | Adaptive virtual partitioning for OLAP query processing in a database cluster[END_REF] previously detailed in Section 1.4.2.4. This work depicts a virtual partitioner to efficient OLAP query processing tuning the partition sizes without requiring any knowledge from the database or the DBMS.

A dynamic partitioning method was proposed by [START_REF] Jindal | Relax and let the database do the partitioning online[END_REF]. In their work the authors proposed AutoStore, a system that monitors the current workload and partitions automatically the data at checkpoints time intervals. They create the partitions based on the data obtained from an affinity matrix of attributes calculated for each query of the workload. They considered changes in the workload but no changes in the data. The cost model denote the execution cost of workload estimated by a cost-based optimizer.

In [LAP + 13], the Liroz-Gistau et al. proposed DynPart (introduced in [LAP + 12]) and DynPartGroup, two dynamic partition algorithms for continuously growing datasets. In their paper the authors formalized the partitioning problem, defining and imbalance factor to leave some flexibility to the size of each partition. Their partitioning method is workload-aware defining an operation that based on the relevant fragment for a query, calculates the efficiency of a partitioning for that respective query. Their defined efficiency is intuitively the ratio between the minimum number of relevant fragments of the query and the number of fragments that are actually accessed under the given partitioning. The second method groups the data to be added before hand. Contrarily to Clay, the workload remains static while the data is added constantly to the original dataset. They proposed a measure to calculate the affinity between the data added and the fragments. The approach named SOAP, a system framework for scheduling online database repartitioning for OLTP workloads, was presented in [START_REF] Chen | Online data partitioning in distributed database systems[END_REF]. This system looks to minimize the time frame of executing the repartition operations while guaranteeing the performance of the current transactions running in the system. The repartitioner determines at which moment the database should be repartitioned extracting periodically the frequency of transactions and the partitions accessed by them. A cost-based repartition is triggered if the system's throughput estimated with the previous information is under a predefined threshold. A repartitioning task could be to move individual or groups of tuples (based on ranges for instance). To enable the database to continue running while a data are being moved, the system relies on replication. To this end, the system generates three types of repartitioning operators: replica creation, replica deletion and objects migration. Their prototype is built on top of PostgreSQL and conducted an experimental study on Amazon EC2 to validate SOAP's significant performance advantages.

Cumulus [START_REF] Fetai | Workload-driven adaptive data partitioning and distribution -the cumulus approach[END_REF], an adaptive data partitioning approach which is able to identify characteristic access patterns of transactions and use them to initially partition and dynamically repartition if these access patterns change. This strategy is specifically tailored for applications that need strong consistency guarantees with OLTP workloads. Partitions in this strategy are created with the objective to reduce distributed transactions and at the same time distribute the load across sites. First, Cumulus collects data from the current workload and uses the exponential moving average (time series prediction technique) to anticipate future access patterns. Then, a filter is applied to only preserve the most frequent access patterns that are organized in a weighted graph. The graph is partitioned using the METIS [START_REF] Karypis | A fast and high quality multilevel scheme for partitioning irregular graphs[END_REF] heuristic and finally a cost model is presented to decide if it is worth to repartition based on the gain between the cost to repartition and the reduced number of distributed transactions.

The online partitioning system called Clay is presented in [STE + 16]. This system dynamically creates blocks of tuples to migrate among servers during repartitioning. It does not consider replication. The system identifies and groups in clumps the tuples that they called hot tuples.

These are the tuples that the DBMS wants to migrate to another partition. The clump is enlarged with the frequently accessed tuples of the hot tuple, and finally it moves the clump to other node.

Most recently [DPP + 18] presented a preliminary work in an online self-managing partitioning and layout selection system based on reinforcement learning. Their goal isto build a general solution capable of leveraging experience and mimicking specialized methods. The paper presents the agents, environments and actions but since it is at an early stage, they do not offer a prototype or comprehensive evaluations.

Partitioning by constraints

In this section we summarize all of the previously described partitioning techniques by constraint. The complete list is organized in Table 1.10 in which the main dimensions of the partitioning problem are mentioned. The approaches whose constraint column is marked with a ✓mean that they consider the workload, the number of replicas (higher than 1) or the database schema as part of the problem's inputs. The schema constraint referes to the database schema, or the platform schema indicating for instance the number of replicas desired.

✓ ✓ ✓ ✓ ✓ ✓ [Nia78] ✓ ✓ ✓ [Nia78] ✓ ✓ ✓ ✓ ✓ [HN79] ✓ ✓ ✓ ✓ ✓ [NCWD84] ✓ ✓ ✓ ✓ ✓ [CY87] ✓ ✓ ✓ ✓ ✓ [CPW89] ✓ ✓ ✓ ✓ ✓ [NR89] ✓ ✓ ✓ ✓ ✓ [LZ93] ✓ ✓ ✓ ✓ ✓ [RG06] ✓ ✓ ✓ ✓ ✓ [DPP + 19] ✓ ✓ ✓ ✓ ✓ [Amo10] ✓ ✓ ✓ ✓ ✓ ✓ [BCN17] ✓ ✓ ✓ ✓ ✓ Object oriented [FKL03] ✓ ✓ ✓ ✓ ✓ [CG97] ✓ ✓ ✓ ✓ ✓ Hybrid [ASAB16] ✓ ✓ ✓ ✓ ✓ Advisors [RZML02] ✓ ✓ ✓ ✓ ✓ [ZRL + 04] ✓ ✓ ✓ ✓ ✓ [RDS02] ✓ ✓ ✓ ✓ ✓ ✓ ✓ [ANY04] ✓ ✓ ✓ ✓ ✓ ✓ ✓ [NB11] ✓ ✓ ✓ ✓ ✓ ✓ ✓ [MDA + 10] ✓ ✓ ✓ ✓ ✓ [HBR19] ✓ ✓ ✓ ✓ ✓ Workload-
Horizontal Relational • Parallel [SW83] ✓ ✓ ✓ ✓ ✓ ✓ [DG92] ✓ ✓ ✓ ✓ ✓ ✓ [GD94] ✓ ✓ ✓ ✓ ✓ ✓ [BAC + 90] ✓ ✓ ✓ ✓ ✓ [DS82] ✓ ✓ ✓ ✓ ✓ [KP88] ✓ ✓ ✓ ✓ ✓ [FM91] ✓ ✓ ✓ ✓ ✓ [FB93] ✓ ✓ ✓ ✓ ✓ [OO85] ✓ ✓ ✓ ✓ ✓ [HL90] ✓ ✓ ✓ ✓ ✓ • Centr. & Distr. [CNP82] ✓ ✓ ✓ ✓ ✓ ✓ [CNW83] ✓ ✓ ✓ ✓ [ECS + 08] ✓ ✓ ✓ ✓ [CZJM10] ✓ ✓ ✓ ✓ ✓ ✓ ✓ [PCZ12] ✓ ✓ ✓ ✓ ✓ ✓ [CILP12] ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ [CGZT14] ✓ ✓ ✓ ✓ ✓ ✓ [TNST14] ✓ ✓ ✓ ✓ ✓ ✓ [ZBS15] ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ [DLL + 17] ✓ ✓ ✓ ✓ ✓ ✓ ✓ [RJ17] ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ [JD11] ✓ ✓ ✓ ✓ ✓ [CZC15] ✓ ✓ ✓ ✓ ✓ ✓ [FMS15] ✓ ✓ ✓ ✓ ✓ [STE + 16] ✓ ✓ ✓ ✓ ✓ ✓ [DPP + 18] ✓ ✓ ✓ ✓ ✓ [GLL + 20] ✓ ✓ ✓ ✓ ✓ Object oriented [CWZ94] ✓ ✓ ✓ ✓ ✓ [KL95] ✓ ✓ ✓ ✓ ✓ [BKS00] ✓ ✓ ✓ ✓ ✓ [BKL98] ✓ ✓ ✓ ✓ ✓ Deductive [MS94] ✓ ✓ ✓ ✓ ✓ [NH94] ✓ ✓ ✓ ✓ ✓ Dimensional [SMR00] ✓ ✓ ✓ ✓ ✓ [BKMS00] ✓ ✓ ✓ ✓ ✓ [BBM07] ✓ ✓ ✓ ✓ ✓ [BBRW09] ✓ ✓ ✓ ✓ ✓ [LMV10] ✓ ✓ ✓ ✓ ✓ ✓ [NKH18] ✓ ✓ ✓ ✓ ✓ [LAP + 13] ✓ ✓ ✓ ✓ ✓ ✓

Partitioning in large-scale platforms

Back in the early 2000s, the need to incorporate, store and query large amounts of data from the Web, with different sources, formats and at the lowest cost, contributed to the development of new kinds of data management tools. Systems based on the relational model, especially parallel databases, scale and can cope with vast volumes of data as demonstrated in [PPR + 09].

However, the relational model is too rigid to adapt to the variability of sources and formats of current data. Also, since the data schema is rarely available beforehand, it is impossible to perform the conceptual design stage which is essential when building a relational database. Therefore, systems applying a schema-later strategy have been largely accepted. These systems store initially the data in its raw format and parse it at runtime. The pioneer presenting a novel scalable data management tool was Google, introducing the Google File System [START_REF] Ghemawat | The Google file system[END_REF] and the processing model MapReduce [START_REF] Dean | Mapreduce: Simplified data processing on large clusters[END_REF]. Their works served as base to Hadoop, one of the most popular large-scale data framework until today. In this section, we start giving a brief overview of Hadoop focusing on the partitioning strategy applied by this framework. Then, we explain and detail the most relevant systems built on top of Hadoop and describe their partitioning strategies.

Hadoop ecosystem

As defined in [Had], the Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across shared-nothing clusters of computers using simple programming models. Inspired by the Google File System and Map reduce papers, it is designed to scale up from single servers to thousands of machines not relying in main memory to execute computations. Additionally, the framework runs programs while ensuring fault-tolerance frequently encountered in distributed environments. Hadoop consists of two main modules: i) The Hadoop Distributed File System (HDFS) is a distributed data storage system based on a master-slave architecture (the nodes are called Name and Data nodes for master and slaves respectively). HDFS is designed to store structured and unstructured data in a scalable, highly available, and fault tolerant way. Files are split into blocks of a configurable size (128MB by default) which are distributed and stored among the data nodes. To ensure fault tolerance and load balancing, data blocks of the same file are replicated and stored on different nodes. The name node (master) manages the file system and regulates the access from file blocks to locations using the file's metadata.

Input data

Input Map

Input Map

Input Map

Input Map

Results

Tuples ⟨k, v⟩ Reduce

Tuples ⟨k, v⟩ Reduce Tuples ⟨k, v⟩ Reduce Data partitioning When a file is imported into HDFS, it is sequentially split into small blocks of a fixed storage size. Each block is replicated in a customisable fixed number of copies and a hash function is used to distribute the data to the nodes. This strategy is quite simple and allows to distribute the data controlling its balance. However it does not consider the schema of the data and it may produce some network overheads at retrieval.

Data processing layer

Since Hadoop version 2, the processing layer is divided in two main components: MapReduce and YARN. Both are designed to manage job scheduling, resources and the cluster. However in version 1 MapReduce provided both resource management and data processing. In Hadoop 2, the resources of the cluster are managed by YARN to eand the data processing models, including MapReduce, lean on YARN. In this way, YARN can be used with different processing models while taking advantage of HDFS functionalities.

MapReduce It is a programming framework following a master-slave architecture to process in a parallel, reliable and fault-tolerant manner data on large clusters. The programmer designs a job that must specify custom-built Map and Reduce functions. When the job is executed, the parallelization of resources and data are transparent to the user. First the Map function splits some input data into independent chunks that constitute key-values. These results are processed by the Mapper component in charge of distributing the chunks to the processing nodes, collecting the intermediate key-value pairs, sorting and grouping them by key before sending them as input to the Reducer. Next, the Reduce function aggregates the values associated to a key according to the predefined program. This procedure is illustrated in Figure 1.14. The first version of MapReduce was based on two components: i) Job Tracker (master) performing the resource managing and job scheduling, and ii) the Task Tracker (slave) supervising the execution of the Map and Reduce functions. In the latest version (called YARN), the Job Tracker was split into two separate daemons: i) A global Resource Manager and ii) a per-application Application Manager.

YARN Its name stands for Yet Another Resource Negotiator. The purpose of this resource management and task scheduling technology is to allocate the system's resources to the different applications running in a Hadoop cluster. Before adding YARN, Hadoop could only run MapReduce applications, adding YARN greatly increased the potential use of the framework. It separates the resource management and planning of the MapReduce data processing component enabling Hadoop to support more applications and different types of processing. In concrete, the JobTracker of Hadoop 1 is separated into two separate daemons: 1) ResourceManager that allocates and manages resources across the cluster, and 2) Application Master designed to schedule tasks, to match them with TaskTrackers and to monitor their progress.

Data querying layer

Several projects were built on top of the Hadoop architecture to avoid the implementation of MapReduce programs to query and analyze data stored in HDFS. If at the beginning MapReduce sought to be an alternative to relational databases, little by little notions of relational databases have been incorporated into the framework. For instance, SQL-like languages have been created to avoid the constraint of programming Map and Reduce functions. Also, other systems built on top of Hadoop incorporate some of the ACID (Atomicity, Consistency, Isolation, Durability) properties. In this section we give an overview of some of the most relevant projects, Apache Hive and Apache Pig, focusing on the partitioning strategy applied by these approaches.

Hive6 it is a datawarehouse built on top of Hadoop that facilitates reading, writing, and managing large datasets using a SQL-like declarative language (HiveQL). At execution time, queries are translated as MapReduce jobs sent to the Job Tracker in a Hadoop cluster. Tables and databases are declared with a Data Definition Language (DDL) and then the data are loaded into the specified location. Tables in Hive are either internal or external, the first type owns its data, meaning that the data are deleted when the table is dropped. Hive supports only horizontal fragmentation of the data. To partition, it creates subdirectories in the HDFS reflecting the partitioning structure. For example, horizontally partitioning the Aircraft Data in Hive are therefore only fragmented since allocation is controlled by the distributed file system. The HDFS splits and replicates the files on each directory into blocks that are distributed among the nodes of the cluster. Partitions are declared in a static (at the creation of the table) or dynamically (when inserting the data).

Pig!7 : it is an alternative for the use of Hive, introducing an ETL-like language (named Pig Latin) rather than a query language like HiveQL. Pig Latin statements are transparently transformed into MapReduce jobs to perform the desired transformations to the data. Pig does not allow to create partitions on the working files. Still, it allows to read only the relevant sections for a given job if the data are stored in the HDFS partitioned with a tool like HCatalog8 (a table and storage management layer built on top of Hive and incorporates Hive's DDL).

Apache Spark

Spark 9 is an unified analytics engine for large-scale data processing. It is based in a master-slave architecture with three main components, the driver program and cluster manager (master) and the worker nodes. Contrarily to Hadoop, Spark is based on in-memory strategies to improve performance. The main Spark's abstraction is a resilient distributed dataset (RDD), which is an immutable collection of elements partitioned across the nodes of the cluster that can be operated on in parallel. RDDs are created gathering information from a distributed system, in general HDFS, hence data partitioning is not controlled by Spark directly. When the data is already in main memory, an RDD can be partitioned and repartitioned using different methods, such as hash, range, and custom partitioning. As Hadoop, the Spark project consists of a core version and several components were developed on top. The main components are:

Spark SQL This module is specialized for working with structured data. It allows to use custom SQL commands to query external data sets with complex analytics. Concretely, users can run queries over both imported data from external sources (e.g., Hive Tables) and data stored in existing RDDs.

MLlib It is Spark's machine learning (ML) library providing already implemented classification, regression, clustering and other machine learning algorithms. Quite similar to Mahout10 for Hadoop.

GraphX Library for manipulating graphs and executing graph-parallel computations offering already implemented graph operators (e.g., subgraph and mapVertices and graph algorithms (e.g., PageRank).

Streaming This component provides automatic parallelization, as well as scalable and faulttolerant streaming processing in Spark.

NoSQL stores

As mentioned in the introduction of this section, the increase of the data collected from the web, social networks, mobile and connected devices motivated the need for other data management systems. These systems sought to achieve horizontal scalability, high availability fault tolerance and database schema maintainability. However, achieving all of the above requirements through the traditional relational database systems is not a simple task and building newer systems with a different paradigm was necessary. The need was then to create systems that could cope to the evolution of schemas being able to handle at the lowest cost the massive data volumes. Some of the above requirements are mutually exclusive, and for some applications one may be ready to make trade-offs giving up one objective for another. This resulted in the emergence of NoSQL stores, some built on top of Apache Hadoop, which offer flexibility and relax some of the traditional RDBMs to boost the performance another(s). The following classification is taken from the work of [START_REF] Davoudian | A survey on NoSQL stores[END_REF].

Key-value

In this systems the data are represented as (key,value) pairs stored in highly efficient lookup data structures. They guarantee very fast lookups and are suitable for applications using as single key to access the data. Data partitioning in these systems is performed in general by hashing the key.

Redis

Column-family

In this type of systems the data are represented as rows and a fixed number of column families.

A column-family is a number of attributes (columns) logically related to each other and that are mostly accessed together. They are inspired from another Google project, the Bigtable system [CDG + 08]. Data partitioning in these systems is done either horizontally and vertically (by column families). We describe one of the most popular column-stores: HBase.

HBase12 : it is a distributed and scalable data store in which data are stored with key-value pair structures. The key is the row identifier and the value contains the row's attributes. The row's attributes are further organized into column families, which are physically stored together in a single file in the distributed file system. Also, HBase keeps a customizable number of versions of the attribute's values of each row. HBase uses HDFS as storage layer but other distributed file systems could be used. Data are fragmented applying a hybrid approach. Firstly, horizontal fragments (called regions) are performed on the keys. These fragments are used as balancing unit by HBase. Then, the row's attributes are vertically partitioned in terms of column families, storing each family in a different file. An example of the data organization of HBase is illustrated in Figure 1.15.

Document stores

These systems are more complex key-value tores in which the value is represented in a structure named a document encoded instandard semi-structured formats such as XML or JSON.

MongoDB 13 This system is the most popular document store which provides a powerful query language that allows to filter and sort by any document's field. As key-value stores it partitions the data based on their key. It uses the key associated to the collection to partition the data into chunks. A chunk consists of a subset of sharded data and each chunk has a inclusive lower and exclusive upper range based on the key.

Graph stores

These systems store datasets represented as graphs in an efficient manner providing effective operations for their querying and analysis. These stores represent a graph as a set of vertices representing entities and edges representing relationships between them. They are divided in native and non-native graph stores according to whether they are built on top of a non-graph data store (e.g., relational database, document store, key-value store). The most popular native system is Neo4j [START_REF] Webber | A programmatic introduction to neo4j[END_REF] which is a highly scalable native graph database, purpose-built to leverage not only data but also data relationships. More details about graph-storage will be given in Chapter 2.

Hybrid architectures

In a traditional relational database management system, a triple is retrieved sending a query request to the database. The query is forwarded to the file system (controlled by the database) which retrieves the corresponding disk blocks and sends them back to the system. The DBMS has a much more direct control over the location and the way the data are partitioned among the disk(s). In the previous approaches, the file system (HDFS) and the query engine (e.g., MapReduce, HBase, Spark) do not form a single unit, and even if some approaches fragment the data on distinct files, the data allocation and replication tasks are left to the distributed file system. In this section we overview some hybrid architectures that place the data intentionally in specific nodes of the distributed file system or another type of storage layer. HadoopDB [ABA + 09] is another hybrid architecture that uses an existing RDBMS to store the data in each worker, instead of the HDFS which is used by Hive. This allows to exploit partitioning, indexing, buffering and compression capabilities offered by DBMSs. Partitioning the data is done using the horizontal approaches presented in last section.

The approach in [ET Ö+ 11] named CoHadoop, locates data intentionally on specific data nodes. This is achieved extending the HDFS with a file-level property (locator) in such a way that all files with the same locator are placed on the same set of Data Nodes. The NameNode is augmented with an index (i.e. location table) specifying where the data must be placed. Partitioning is then decided by the user (using the workload for example). Their approach is similar to [DQJ + 10], Hadoop++ supporting as well data copartition.

The Trojan Data Layouts were proposed in [START_REF] Jindal | Trojan data layouts: right shoes for a running elephant[END_REF]. This approach internally organizes data blocks into attribute groups according to the workload in order to improve data access times. Their system fully preserves the fault tolerance properties of MapReduce, since they kept the blocks of replicated data but only adapted the way each block organizes data internally. Their algorithm applies first a column grouping method to cluster queries in a workload according to access patterns. Then they map each resulting query group to one data block replica as to compute the Trojan layout for such replica.

Other approaches have proposed improvements to the Hadoop framework based on the physical data layouts in the HDFS. Data in HDFS are usually organized using a row-oriented layout since a pure column store has severe drawbacks as the data for different columns may reside on different nodes leading to high network costs [START_REF] Dittrich | Efficient big data processing in hadoop mapreduce[END_REF]. Still, some systems proposed to store the data as columns. Llama [LAC + 11] store the data as columnar files. Its performance is comparable to databases, in which the performance if better in queries involving small number of attributes. This system was outperformed by [START_REF] Chen | Cheetah: A high performance, custom data warehouse on top of mapreduce[END_REF], which also employs a columnar format to store the data but implements a partition the partitions attributes across (PAX [START_REF] Ailamaki | Weaving relations for cache performance[END_REF]) layout, in which all data belong to a record are stored in the same block.

In [START_REF] Romero | Tuning small analytics on big data: Data partitioning and secondary indexes in the hadoop ecosystem[END_REF], Romero et al. proposed a system to solve analytic queries with a cost-based approach. Their system is implemented in a three level architecture running HDFS at the lowest level, HBase as the storage manager and MapReduce as the query execution engine. In their approach, the records were indexed and partitioned in HBase.

Conclusion

With the data deluge and the explosion of deployment architectures, the data partitioning has become the sole technique that database actors (designers, administrators, architects, analysts, students, researchers) have to know in detail. At the same time, data partitioning has been studied from the arrival of databases evolving with its generations. In this chapter we sought to give a historic overview of the data partitioning problem, its history, evolution, constraints and how it behaves after the arrival of each new data representation and deployment architecture. To do so, we proposed a data partitioning foundation that includes: implicit and explicit definitions and types, as well as data partitioning dimensions comprising: (1) partitioning type, (2) algorithm, (3) main objective, (4) adaptability, (5) mechanism, (6) cost model, (7) system element, (8) platform, (9) constraints and (10) data model. These dimensions offer a graphical representation (a star-schema like) of data partitioning. For each dimension, we described its characteristics and depicted its elements and labels.

We have focused on presenting the state-of-the-art of data partitioning in relational databases and other close models in centralized, distributed and parallel architectures. We cited the works that led to an explicit definition of the partitioning problem and showed the gradual development of the main data partitioning forms. Subsequently, we exposed the algorithms, strategies and heuristics introduced to partition the database according to a set of formerly defined dimensions. We offer a comprehensive review on data partitioning and can be used as a torchlight for readers and actors to work in this exciting and durable problem. Finally, we show how the problem has evolved in the current cloud platforms and how it adapted to cope with large-scale data. In the following chapter we show how the problem has been treated specifically for treating graphs.

Chapter 2

Graph Data : Representation and Processing Summary In the previous chapter we surveyed the partitioning problem in relational databases. Our goal is to provide a partitioning environment to managers of Knowledge Graphs. To do this, we cannot disregard how the Knowledge Graphs have been treated in the literature. In this chapter, we start giving a general overview of the graph data model. In Section 2.2, we detail the logical and storage structures for graphs , describing the query processing strategies and languages (Sect. 2.2.1 -Sect. 2.2.4), and reporting some of the most relevant currently available systems. We dedicate also Section 2.7 to describe the graph partitioning algorithms used by some parallel systems. Next, in Section 2.3, we focus on the Resource Description Framework (RDF). We start by giving some background concepts (Sect. 2.3.1), and similarly to what we did with the pure graph systems, we describe RDF storage (Sect. 2.3.2), processing (Sect. 2.3.3) and its partitioning strategies (Sect. 2.3.4). We conclude summarizing the presented works and comparing the strengths of both worlds (relational and graphs).

Introduction

In the previous chapter we detailed the partitioning problem in relational databases. We showed its evolution and how it was adapted to the object oriented, deductive and multi-dimensional data models. We explained the development of large-scale platforms and how they adapted to the recent need to efficiently deal with big data volumes. However, the data models discussed derive directly from the relational design so widely studied. In this chapter we detail a data model that allows describing more complex relationships. Specifically, graph-oriented models representing the data as graphs whose manipulation is expressed as graph-oriented operations. They have gain momentum in the past years with the development of the Semantic Web, Social Networks, and with the increase in the ability to capture data from different disciplines like Biological and Transportation networks. In these applications, the interconnectivity of the data is a key feature and it is as important as the data itself. Modeling the data as a graph allows a more natural way of handling these applications. In graph-based systems, queries refer directly to the original graph structure and graph operations like finding the shortest path can be directly expressed with specific query languages. In this chapter we start giving more insights about the graph data model in general (Section 2.2), discussing their storage, processing and partitioning. Then, in Section 2.3, we focus on the RDF model introduced to represent the data in the Semantic Web giving some main definitions and describing the most relevant storage and processing approaches.

Graph database models

The research around graph database models is not new, actually it had a peak in the late eighties/early nineties but it was eclipsed by the development of tree-based structures like XML modeling in the first generation websites. The use of graphs in computer science dates back to the beginning of relational databases in the mid-1970s in which graph models were proposed to expand the information stored in databases with semantic networks (firstly defined in [START_REF] Robert | Semantic networks: their computation and use for understanding English sentences[END_REF]). Also, graphs were used by the legacy data models (hierarchical and network models) to depict the navigation of its records. The historically influential network data model [START_REF] Taylor | CODASYL data-base management systems[END_REF] represents data as physical records that are navigated using a graph-based structure (a network). This model, also known as CODASYL, browses through the record's parents (owners) and children (members) remaining tied to the physical implementation of the data. In what follows we give a brief overview of the former graph database approaches. The list of approaches is not exhaustive, we mention only a few of them to give a general idea of the concept evolution. A complete survey is found in [START_REF] Angles | Survey of graph database models[END_REF]. In chronological order and according to the system in which they collaborate, the first graph database models appeared in the following systems:

Semantic networks The work of [START_REF] Roussopoulos | Using semantic networks for database management[END_REF] proposed the use of a semantic network extending the original Codd's model to represent knowledge about the database. The semantic network defines the meaning of the data in a labeled directed graph (described in Section 2.2.1) where both nodes and edges are labeled. This network contributes to the generation of the relational schema and to the definition of semantic operators. Similarly, a semantic network was used by [START_REF] Shipman | The functional data model and the data language DAPLEX[END_REF] to describe the database schema in their functional data model and language named DAPLEX. DAPLEX's basic components are entities and functions, in the graph structure the nodes correspond to entity types and the arrows depict functions. The work of [START_REF] Gabriel | A new approach to database logic[END_REF] used a directed graph to represent the database structure before defining a logic and an algebraic query language generalizing the relational, hierarchical and network data models. In this line, the system G-Base [START_REF] Kunii | DBMS with graph data model for knowledge handling[END_REF] represented the database in terms of knowledge structures using a labeled directed graph introducing as well a data manipulation language for the stored graph.

Object-oriented As it was mentioned in the previous chapter, object-oriented databases (OODBs) had its boom in the late eighties. Graph-oriented models for OODBs were proposed in the systems O 2 and GOOD described in [START_REF] Lécluse | O2, an object-oriented data model[END_REF] and [START_REF] Gyssens | A graph-oriented object database model[END_REF] respectively. A directed graph is used in both systems to represent the objects and relationships between them. GOOD (graphoriented object database) is a theoretical support for systems in which the data representation and its manipulation are graph-based. GOOD introduces basic operations and a language based on pattern matching to manipulate graph-shaped object bases. This work served as basis to several research projects, for example G-Log [PPT95] introducing a declarative query language for graphs.

Former graph models The GraphDB system [START_REF] Hartmut | Graphdb: Modeling and querying graphs in databases[END_REF] proposed a data model and a query language for graphs in a standard database environment. Their goal is to smoothly integrate graph notions into the popular database systems of the time (object-oriented specifically). To achieve this, they defined a graph database and a query language on top of classes and hierarchies derived from OODBs. In parallel, the work of [START_REF] Gutiérrez | Database graph views: A practical model to manage persistent graphs[END_REF] presented at the same conference, introduced Graph Views to define and manipulate graphs independently of the system used to persist the data (e.g., relational, object-oriented and file systems). To manipulate the graphs, they proposed derivation operators defining new graph views upon existing ones. Other works used hyper-graphs to represent the data in a much more general model, for example Hy + [CM93] provides a user-interface to formulate queries to a set of graph patterns.

The beginning of the 1990s marked the emergence of the best known aspect of the Internet today: the Web as a set of pages in HTML format incorporating text, links and images, addressable via a URL and accessible using the HTTP protocol. The Internet boom undoubtedly diverted the efforts devoted to graph-based models to semi-structured models originally used to publish data on the Web. The success and exponential growth of Web content forced the creation of standards that allowed to order and exploit the information available on the Internet. The World Wide Web Consortium (W3C) founded in 1994 is in charge of developing and maintaining these standards within which we find HTML, XML, RDF and SPARQL. The Web is naturally modeled as a graph, Web pages are connected nodes interconnected via hyperlinks. The famous PageRank search algorithm used by Google apply this modeling to measure the importance of webpages in its search engine. Web data integration standards (e.g., RDF) also use a graph to model the interconnection of resources on the Web. More recently, the massive use of social networks and the possibility to recover data from many domains pushed the return and development of graph models. In the following section, we explain the logical graph structures used to represent graphs.

Logical graph data structures

As it was previously mentioned, graph data models represent the data as graphs providing efficient traversal operations to query and analyze them. Graphs are composed of entities representing something that exists as a single or composed unit, and relations establishing connections between two or more entities. In this section we describe the data structures used to model entities and relations in the graph data model. These structures are not mutually exclusive, some structures are a combination of some of them. A few of the structures are illustrated in • Labeled graphs In this type of structure vertices and/or edges are tagged with labels representing their respective roles, types or some metadata. A particular type of labeled graphs, named edge-labeled graphs, in which labeled directed edges indicate the different type of relationships is shown in Figure 2.1c. This amalgam is the one embraced by the Resource Description Framework described in Section 2.3.

• Multigraph These graphs allow multiple edges between the same vertices and self-loops.

• Attributed graphs In this structure, the nodes and edges have properties expressed as variable list of key-value pairs. An attributed, directed, labeled multigraph named property graph is given in Figure 2.1d. The property graph model is implemented by many graphbased systems and is used as reference model for several research. An in-depth description of property graphs is given in [START_REF] Bonifati | Querying Graphs[END_REF].

• Hypergraphs This model is said to be a generalization of a graph in which an edge can join any number of vertices instead of only one. The set of nodes connected with the same edge is called an hyperedge, when the hyperedge is directed, the set of nodes is ordered. A simple hypergraph with 3 hyperedges is shown in Figure 2.1e.

Data storage

Whether the system was built specifically to treat graphs or if it was built on top of another platform, each of the structures described previously is stored according to the strategies described in this section.

• Adjacency matrix This matrix is a 2-dimensional array whose size equals the n × n where n is the number of vertices in the graph. The matrix stores a 1-bit in cell m i,j if it exists a relationship between a vertex i to vertex j and a 0-bit otherwise. It is the representation with the simplest implementation, however it suffers from space overheads even for sparse graphs. An example of this structure is given in Figure 2.2a. The figure shows a variation of the adjacency matrix in which the edge's ids between two nodes are indicated directly in the cell.

• Adjacency list This representation stores the graph as a set of lists. Each row of the array corresponds to a vertex paired with a list of its neighboring nodes. Usually, it stores a node with its out-neighbors, however some systems enable replication storing both (in/out)-neighbors for a node. Efficient index structures over vertices and edges are created so that random access to single elements is fast. This storage scheme is ideal for graph systems built on top of key-value stores and systems prioritizing online transaction processing workloads (OLTP) [START_REF] Davoudian | A survey on NoSQL stores[END_REF]. An outward adjacency list is illustrated in Figure 2.2b for the directed graph.

• Edge list Contrarily to the adjacency list, this storage structure represents a graph as a list of edges indicating for each edge its corresponding incident vertices. This structure in which all the information associated to an edge is clustered is useful to the representation of hypergraphs in which an edge is associated with a set of edges. Some recent popular graph stores, like Neo4j [START_REF] Webber | A programmatic introduction to neo4j[END_REF] use this representation. This representation is also preferred by some RDF processing systems. An example of such structure is given in Figure 2.2c.

• Compressed sparse row (CSR) It is one of the most widely used storing structures for its efficient lookup structure. To store a graph it uses two arrays of integers. More arrays could be added to encode more information about a node and edges (e.g weights), this is the representation used by the Metis [START_REF] Karypis | A fast and high quality multilevel scheme for partitioning irregular graphs[END_REF] graph partitioner discussed in Section 2.2.5.

The first array (named array of edges) stores the adjacency lists of all vertices together storing all edges continuously. The size of the array of edges is therefore the total number of edges in the graph. The second array, named vertex array, is an index to the previous array mapping a vertex ID into the ID of the first outgoing edge. Let us consider the example in Figure 2.2d, in which the nodes and edges labels are encoded before appending them to the edge and vertices array. In this example, the CSR represents the directed labeled graph of Figure 2.1c.

• Complex indexes: This category comprises more sophisticated index structure than a regular adjacency list. We can mention for instance the compressed bitmap indexes used in the system DEX [MMG + 07] used to efficiently combine multiple adjacency lists with bit operations.

Query and manipulation languages

Among graph data models there are several works on query languages. These works present collections of operators and inference rules to manipulate and query the graph data structure.

Considering the vast number of approaches available and the scope of this thesis, in this section we describe only the most recent and popular graph query languages. An in-depth analysis of query languages for graph databases is given in [AAB + 17]. We start describing the main types of query workloads and then giving an overview of the query languages.

Query workloads

Similar to relational databases, the workloads can be divided in transactional and analytical. In the first type of queries, small fractions of the graph are explored and a quick response time is needed. They can be classified in:

• Path queries: This type seeks to determine whether a vertex v can be reached from another vertex w given a set of conditions. A path query has the form P = x α -→ y where α specifies the path conditions and x and y can be variables or specific nodes. For example, satisfying a regular expression over the set of node's or edge's labels or finding a shortest path between both nodes. A path query using regular expressions are known as regular path queries.

• Navigational/Pattern matching queries: These queries are more complex structures than the previous ones since their objective is to find sub-graphs in data graph that are a b c e f g h a 0 1 0 0 0 0 0 b 0 0 2 0 0 0 0 c 0 0 0 3 4 0 0 e 0 0 0 0 0 5 6 f 0 0 0 0 0 0 0 g 0 0 0 0 0 0 0 h 0 0 0 0 0 0 0 The other type of graph queries express analytical graph computations, where a significant fraction of the vertices and edges of the graph are accessed. Similar to SQL in the relational databases some languages offer aggregation operators offering the possibility to group values and compute statistics over these groups.

Query languages

In this section we give for the most popular modern query languages their main characteristics, strengths and drawbacks. All of the languages presented here share the graph pattern matching operations.

• SPARQL [SH13a]: This language was standardized by the W3C in 2008 to query RDF graphs. Its basic graph structure are triple patterns, which are RDF triples composed of a subject, a predicate and an object that may be bounded values or variables. Triple patterns can be combined using conjunctions to form basic graph patterns. Additional to the evaluation of graph matching queries, it offers graph creating functionality with the CONSTRUCT operator. The language does not allow query composition (i.e. use the output of a query as the input of another query without persisting the result). An example query for the query represented in Figure 2.3a is:

SELECT ?c ?f WHERE { ?c p3 ?e . ?c p4 ?f . ?e p5 ?g . }

• Cypher [FGG + 18]: This language developed by the developing team of the Neo4j graph system to query property graphs using patterns as its main building block. Patterns are expressed giving a graphical intuition to encode nodes and edges with arrows between them. The MATCH clause specifies the basic graph pattern, nodes and edges expressed inside parenthesis and brackets respectively. Specific values for properties are specified inside a node within braces and nodes' labels are separated with a ":" symbol or can also be expressed in the WHERE clause. The RETURN clause expresses the projected output variables. The language supports selection, projection, grouping, aggregation and ordering. The Cypher query for the property graph query shown in Figure 2.3b is expressed as:

MATCH (x1) -[:knows] -> (id:2 {name:"Lisa"}) MATCH (id:2) -[:knows] -> (x3) RETURN x1.name AS name1, x3.name AS name2
• Gremlin [Pro19]: This language is part of the Apache TinkerPop31 graph computing framework. It is originally specified to query property graphs but it is quite different to the previous languages. Instead of having SQL-like operators forming a declarative language, it provides a much more programming-like interface focusing on graph traversal operators. For example in the following query using the property graph of Figure 2.3, the call G.V() returns the set of all nodes in the graph, then sequences of selections are applied on the set of nodes. The command out retrieves all nodes that can be reached with the label knows.

G.V().has('name','Gabriel').out('knows')

.has('name','Lisa').out('knows').has('name','Thomas') • G-Core [AAB + 18]:it is a practical language developed by a industry and academia consortium with the aim of providing a natural syntax to express the most important graph query features. It allows not only to query but to create and compose new graphs. For example, a nested query combining a constructed graph pattern of Figure 2.1d is shown here:

SELECT id(m), m2 MATCH (id:2)-[:knows]->(h), (h) -[:knows]-> (m) ON ( CONSTRUCT (h) -[:friendOf] -> (m2), (m2)-[:knows] -> (m) )

Query processing

The query processing strategies depend on the type of graph query targeted by the application. These strategies can be as simple as finding the direct neighbors of a node or finding isomorphic graphs given a query pattern, or more complex traversal paths used in algorithms like PageRank. In this section, we give an overview of graph processing strategies used in the subgraph matching queries which are the core of several query languages. Understanding how this type of query is solved serves as a base to understand how more complex graph queries are processed. A detailed description of each algorithm and more complex strategies dealing with reachability is found in [START_REF] Bonifati | Querying Graphs[END_REF].

Let us give some background concepts that will be used throughout this section. Given a direct labeled graph G = (V, E), a conjunctive query CQ allows to identify substructures/patterns in G. It asks for all the subgraphs in G matching a given CQ pattern.

Definition 2.1 (Conjunctive query) [START_REF] Bonifati | Querying Graphs[END_REF] Let V be a set of vertex variables. A conjunctive query graph is the expression:

(z 1 , ..., z m ) ← a 1 (x 1 , y 1 ), ..., a n (x n , y n ) such that: • x 1 y 1 , ..., x n y n ∈ V • a 1 ...a n ∈ L (set of labels).
• ∀z i ∈ {x 1 , y 1 , ..., x n , y n } Now, let us define the mapping function that as indicated by its name maps nodes and edges in a query to nodes and edges in the graph. More formally:

Definition 2.2 (Mapping) [BFVY18] A mapping is a function µ : V ↦ → V such that ∀ 1≤i≤n ∃e i ∈ E
where for each e i = (µ(x i ), µ(y i )) and a i are labels of e i . Evaluating a conjunctive query r over a graph G is expressed as:

r G = {(µ(z 1 ), ..., µ(z m ))|µ is mapping of r on G} Two graphs K = (V k , E k ) and H = (V h , E h ) are isomorphic if there is a mapping µ : V k ↦ → V h such that (x, y) ∈ E k ⇐⇒ (µ(x), µ(y)) ∈ E h .
In this case, µ maps edges in K to edges in H and non-edges in K to non-edges in H. On the other side, non-edges mappings are not enforce in homomorphic mappings such that (x, y)

∈ E k ⇒ (µ(x), µ(y)) ∈ E h .
Let us consider the graph given in Figure 2.1c and the following conjunctive query: q = (?c, ?f, ?g) ← p 3 (?c, e), p 4 (?c, ?f ), p 5 (?e, ?g). The evaluation of the query on the given graph (named G) is q G = {(?c, c), (?e, e), (?f, f ), (?g, g)}. Subgraph matching The process of finding all subgraphs of a given graph G that are iso(homo)morphic to a given conjunctive query r is called subgraph matching. In this case, each subgraph is encoded by a mapping µ of nodes/edges from r to G. In general, the sugraph matching process consists in combining partial mappings obtained first in order to obtain the final subgraph match. A partial mapping is formally defined as follows:

Definition 2.3 (Partial mapping) [BFVY18] Given a graph G, a graph pattern r[z 1 , ..., z m ]
and a mapping µ of r on G, a partial mapping is a sequence of pairs

⟨(v 1 , µ(v 1 )), ..., (v k , µ(v k ))⟩ such that v 1 ...v k is a sequence of distinct vertices of r.
Subgraph matching algorithms are based on depth-first search (DFS) or breadth-first search (BFS) techniques which are described in the following section.

Depth-first search (DFS)

DFS-based algorithms for subgraph matching are based on the backtracking principle. This principle is illustrated in Figure 2.4a in which starting from an arbitrary node as the root, the algorithm explores as far as possible along each branch before backtracking. Its implementation is usually based on recursion, but this implementation fails to treat large graphs in a reasonable time. Therefore, the implementation is emulated using an iterative graph search based on states. The searching is guided by a plan, which is an ordered list of vertices indicating the sequence of query nodes assigned to graph vertices while exploring.

An example of such algorithm is the matrix-based subgraph matching which models the query and data graph as adjacency matrices and solves a conjunctive query using matrix operations. For a given query and data adjacency matrices, it defines a permutation matrix P to express the assignment of query vertices to graph vertices. In this matrix, each row i contains exactly one cell p ij equal to 1 (indicating a mapping between the variable node i and the data node j) while other entries are equal to 0. A permutation matrix for the graph and queries of Figures 2.1c and 2.3a respectively is shown in Figure 2.5a.

Even if for the previous query there is only a single valid permutation matrix, this is not the general case since a single query might have multiple valid permutation matrices. To check that the permutation matrix encodes an isomorphic mapping, the following expression must hold:

A Q = P A G P T
where A Q and A G represent the query and graph adjacency matrices respectively. The algorithm to find all possible mappings relies on filling P progressively given that the isomorphic condition a b c e f g h ?c 0 0 1 0 0 0 0 ?e 0 0 0 1 0 0 0 ?f 0 0 0 0 1 0 0 ?g 0 0 0 0 0 1 0

(a) Permutation matrix ▷◁ G 1 .node A = G2.node A ▷◁ G1.node A = G2.node A σ G 2 .Edge=p 3 σ G 1 .Edge=p 4 σ G 3 .Edge=p 5 G 1 G 2 G 3 Π G1.node A ,

Graph partitioning

Over the past years, the data stored as graphs has increased considerably. For example, the size of the Facebook data graph counts with a billion nodes and about two hundred billion edges [START_REF] Lenharth | Parallel graph analytics[END_REF]. Distributed and parallel solutions emerged to cope with the demand of efficient graph storage and processing. In these systems, cutting the graph into smaller pieces is a fundamental step to enable parallelism. Graph partitioning must find a balance between the following objectives:

• Minimize communication overhead : The communication between hosts dominates the query execution on large scale systems, optimizing this factor is key to optimize the performance. In general, this objective is mapped to the minimization of the total edge cuts (i.e. crossing edges having nodes in different partitions).

• Maximize load balance: this objective refers to avoid data and execution skewness, concentrating most of the data in just a few sites.

The problem described previously is also known as the edge-cut partitioning problem in which the vertices of a graph are divided into disjoint clusters such that each cluster has almost the same size whereas the number of edges sharing vertices in two partitions is minimized. A different approach named node-cut consists in dividing the edges into equal size clusters such that both vertices of an edge are always assigned to the same cluster. However, in this approach the vertices are not unique since they might be replicated due to the distribution of the node's edges across distinct partitions. In this case, the goal is to: i) Balance the partitions in terms of number of edges and ii)minimize the number of replicated vertices. Both problems are illustrated in Figure 2.6. The graph partitioning problem has been proven to be NP-complete [START_REF] Garey | Some simplified npcomplete graph problems[END_REF] and finding a reasonable solution to the balanced partitioning is very hard to estimate. In this section we give an overview of the most recent and essential works in graph partitioning. The mathematical foundations and a in-depth description of each approach is given in the following survey [BMS + 16].

Algorithms

In this section we describe the most relevant graph-partitioning algorithms. We divide them into two groups, the first one considers an initial partitioning of the graph as input, these algorithms are known as graph growing methods. On the other hand, global partitioning algorithms start with the entire original graph and directly compute the partitions. This classification presents a summary of the one presented in [BMS + 16]. A schema of the classification of the approaches described briefly in this section is shown in Figure 2.7.

Global partitioning algorithms As it was previously mentioned, these algorithms start with an entire graph and compute a solution directly. They are mainly used to partition small graphs due to its complexity. In fact, some of the approaches are used to produce the initial partitioning required in graph growing algorithms. We describe first exact approaches finding the optimal solution to the graph partitioning problem using exhaustive enumeration techniques (e.g., branch and bound). Due to its complexity, most of the methods are dedicated to bi-partition the graph, still they can be generalized to a k-way partitioning by recursion. Most of the exact algorithms use branch and bound to list the candidate solutions. To estimate the bounds of the optimal solution, the graph partitioning has been modeled as a linear program [START_REF] Brunetta | A branch-and-cut algorithm for the equicut problem[END_REF] or quadratic program [START_REF] Hendrickson | Graph partitioning models for parallel computing[END_REF] just to name a few.

All of the previous methods are able to find the optimal partitions for graphs with very limited size. To speed-up the running time, some heuristics are proposed to find solutions that approximate the optimal graph partitioning. These solutions comprise:

• Spectral partitioning: This strategy is applied to split a graph in two groups, for this it analyzes the spectrum of a matrix representing the graph. The spectrum is the set of eigenvectors order by their magnitude and their corresponding eigenvalues. The strategy finds the Laplacian matrix of the graph and calculates the second smallest eigenvector which is proven to be a solution for a simplified version of the graph partitioning problem.

Exact Heuristics

• Spectral

• Graph growing

• Flows • Geometric • Streaming

Heuristics

• Binary node swapping

• K-way swapping

• Tabu search • K-Flows • Bubble • Random walks • Diffusion • Multi-level

Global

Graph partitioning algorithms Graph growing They were introduced in the seventies in [START_REF] William | Algorithms for partitioning of graphs and computer logic based on eigenvectors of connection matrices[END_REF] and later improved in works like [START_REF] Barnard | A fast multilevel implementation of recursive spectral bisection for partitioning unstructured problems[END_REF] for example.

• Graph growing: The algorithms in this category (e.g., [START_REF] George | Computer Solution of Large Sparse Positive Definite Systems[END_REF]) and explore the graph using a breath first search (BFS) assigning each visited node to the same group. The process stops when half of the original node weights are assigned to one partition and the remaining nodes are assigned to another.

• Flows: This type uses max-flow min-cut theorem to compute the partitions. The work of [START_REF] Nguyen Bui | Graph bisection algorithms with good average case behavior[END_REF] for instance calculates the maximum flow between the nodes of the same partition but it ignores the load balance constraint.

• Geometric partitioning: The approaches under this category use the coordinates of the graph in the space. In these approaches nodes geometrically close are mapped to the same partition with the aim of reducing the global edge-cut. They comprise for example the well known space-filling curves [START_REF] John R Pilkington | Partitioning with space filling curves[END_REF].

• Steaming partitioning: This strategy has gain importance in the past year with the development of large-scale streaming applications. These strategies grant more flexibility in terms of solution's quality to increase the partitioning speed. Among these strategies we find [START_REF] Nishimura | Restreaming graph partitioning: simple versatile algorithms for advanced balancing[END_REF] and FENNEL [START_REF] Tsourakakis | FENNEL: streaming graph partitioning for massive scale graphs[END_REF].

Graph growing algorithms This algorithms iteratively improve starting partitioning solutions. Most of current solvers use this type of heuristics. They can be classified as:

• Binary node swapping: This strategy iterates over a set of nodes and its neighbors and swaps nodes from each partition. With this action the total number of cuts decreases. The solution was first presented by Kernighan and Lin in [START_REF] Kernighan | An efficient heuristic procedure for partitioning graphs[END_REF] and later improved by many other authors.

• K-way swapping: These approaches are a workaround to the recursive application of the bisection methods. They propose to directly partition the graph in k parts by using priority queues [START_REF] Sanchis | Multiple-way network partitioning with different cost functions[END_REF] or a global priority queue [START_REF] Karypis | A fast and high quality multilevel scheme for partitioning irregular graphs[END_REF] to control the number of swaps between nodes. • Tabu search: As its name indicates, these strategies use tabu search to explore the set of solutions (e.g., [START_REF] Galinier | An efficient memetic algorithm for the graph partitioning problem[END_REF]). Their calculation is more expensive than the previous k-way swapping.

• K-Flows: this method presented in [START_REF] Sanders | Engineering multilevel graph partitioning algorithms[END_REF] improves a given bipartition by growing the area around the boundary nodes/cut edges.

• Bubble: This method presented in [START_REF] Diekmann | Shapeoptimized mesh partitioning and load balancing for parallel adaptive FEM[END_REF] is quite similar to k-means, the method randomly select k seed nodes that are evenly distributed over the graphs. Then, it uses BFS to grow each of the k-nodes, the seeds are then recalculated. The algorithm stops when it is impossible to no more improvement partition is found for more than 10 iterations or if the seed nodes does not change. A schema of this strategy is shown in Figure 2.8a.

• Random walks and diffusion: these approaches start at a node and choose randomly from its neighbors another node to visit using a probabilistic transition matrix. The idea of the approach is to detect dense graph regions based on the intuition that if a region is dense, it is quite difficult to leave the region after several steps. These intuition is described in [START_REF] Satu | Graph clustering[END_REF].

• Multi-level : The implementation of this partitioning approach (METIS [START_REF] Karypis | A fast and high quality multilevel scheme for partitioning irregular graphs[END_REF] is until today, one of the most successful and most applied graph partitioning technique. This technique splits the graph partitioning process in three stages. In the first phase it coarsens the original graph G to form a condensed representative graph of G. Then it applies a partitioning algorithm (K-way swapping for instance) to the compressed graph. Finally, the coarsed graph is goes back to its initial shape and the partitions are refined. A schema of this procedure is shown in Figure 2.8b. In current large-scale graphs, the previous methods are unable to produce partitions in a reasonable time. Some efforts were maid towards parallelizing some of them, for example the distributed version ParMETIS [START_REF] Karypis | A parallel algorithm for multilevel graph partitioning and sparse matrix ordering[END_REF]. It exists other partitioning strategies highly efficient in terms of loading times and low memory costs, however they do not consider the edge-cut and load balance constraints. These approaches are mainly based on hashing, like for example the 2D-hash strategy of the GraphX framework [GXD + 14].

The approach named Ja-Be-Ja was introduced in [RPG + 15] claiming that it outperforms METIS for large graphs. The algorithm uses local search and simulated annealing to partition the graph using an edge-cut or vertex-cut strategy (both illustrated in Figure 2.6). The algorithm does not need to know the entire graph to generate the partitions since it is based on operations at the vertex level. Each node has information about its neighbors and it is initially assigned with a color (partition). At each step, a node's color can change according to the most prevalent color from its neighborhood.

Another similar scalable graph partitioning algorithm named Spinner was presented in [START_REF] Martella | Spinner: Scalable graph partitioning in the cloud[END_REF]. It is based on the Label Propagation Algorithm on top of the large-scale graph platform Apache Giraph [START_REF]Apache Giraph[END_REF] (described in Section 2.2.6). If k partitions should be formed, it starts assigning each vertex to a k i partition randomly. Then, it iterates over a modified k-way balanced label propagation algorithm to assign the vertices' labels to its neighbors until it converges. Whenever data are added or removed from the graph, Spinner reiterates to find the converging assignment. This type of approaches considering changing workloads or variations to the original graph are named Dynamic algorithms and are described in the following section.

Dynamic algorithms Current graph-based applications deal with data which is not only large, but it is also updated. Additionally, the user's needs may also change leaving the initial workload out of date. Re-partition the graph is complex and expensive, hence partitioning the graph from scratch is not always an option. There have been some works in dynamic partitioning of graphs. The list is not exhaustive, more details on other dynamic algorithms is given in [START_REF] Davoudian | A survey on NoSQL stores[END_REF]. All of the works presented in this section are summarized in Table 2.1.

The same creators of METIS introduced in [SKK97] a repatritioning technique for changing graphs based on diffusion. The works presented previosly on streaming techniques are also dynamic approaches. In these works the changes occur in the graph and not in the workload. The work of Tüfekçi and Özturan in [T Ö15], introduces a framework for changing workload using access patterns. The proposed system partitions a graph database and provides a fully functional distributed graph database system. The dynamic replicated algorithm Sedge (Self Evolving Distributed Graph Management Environment) proposed in [START_REF] Yang | Towards effective partition management for large graphs[END_REF] creates new partitions or replicates to cope with variations on the workload. It proposes a two-level graph partitioning architecture with complimentary primary partitions and dynamic secondary partitions. The starting point is an initial partitioning, then based on the query workload it creates secondary partitions (as replicas) reducing the original cross partition edges. The secondary replicas are either full replicas of the initial partitions or replicas of the cross-partition hotpots. These replicas are either complimentary created to the initial partitioning or they are created on-demand. It is build to work specially in the in-memory computation model of Pregel. An illustration of the partitioning strategies presented in Sedge is shown in Figure 2.9.

In [START_REF] Vaquero | xdgp: A dynamic graph processing system with adaptive partitioning[END_REF] the authors introduced xDGP, a system that dynamically repartitions massive graphs to adapt to structural changes in the graph inside a system based on Pregel. The system adopts an iterative vertex migration algorithm that relies on local information only, making complex coordination unnecessary. It starts hash partitioning the graph and defining a capacity constraint to avoid skewness. It uses a greedy vertex migration strategy that buffers the nodes that should be moved based on local information available to the vertex whose goal is to reduce the global edge-cut.

Another approach considering evolving graphs is Hermes [START_REF] Nicoara | Hermes: Dynamic partitioning for distributed social network graph databases[END_REF] which is built on top of the Neo4j platform. This approach repartitions dynamically and on the fly on multiple servers the existent partitions of data. Their algorithm is based on the number of neighbors measure to decide whether a vertex should be moved.

The approach named Leopard [START_REF] Huang | LEOPARD: lightweight edge-oriented partitioning and replication for dynamic graphs[END_REF] is lightweight a dynamic graph partitioning approach which simultaneously considers a replication mechanism to reduce edge-cut. The intuition behind the proposed method is to assign a vertex to the partition containing most of its neighbors, penalizing large partitions when they are too large. It continuously revisits vertices and edges that have already been assigned to keep vertices close to its neighbors.

In [START_REF] Firth | TAPER: query-aware, partition-enhancement for large, heterogenous graphs[END_REF], Firth and Missier present TAPER, a graph partitioning system that is sensitive to evolving workloads. Their system takes as input any given initial partitioning and iterates to adjust the partitioning taking the workload into account. For this, it uses the intuition of stability used in community detection. When a partition is stable, a random walk inside that partition should remain in the same partition for a long time.

In IOGP [START_REF] Dai | IOGP: an incremental online graph partitioning algorithm for distributed graph databases[END_REF], the authors presented a partitioning algorithm optimized for transactional workloads. Its methodology is divided in three stages: quiet, vertex reasoning and edge splitting stage. In the quiet stage, the vertices are placed using a hashing function. In the vertex reasoning phase, checks as more vertex are inserted how connected they are to other vertices to re-assign them if necessary. The last stage named edge-splitting splits edges of high degree into multiple servers to enable parallelism.

More recently, [FLT + 20] proposed to incrementalize current batch partitioners instead of developing yet another dynamic graph partitioning method. In their work, they formalized the incremental graph partitioning problem adding an objective to the ones presented at the beginning of this section: minimizing the changes considering that a full repartition is expensive. They managed to increment some edge-cut and streaming partitioners and their experiments verified the effectiveness of their approach.

Graph databases

In the previous sections we characterized the following dimensions of the graph database model: i) Logical data structure, ii) Data storage, iii) Query and manipulation languages, iv) Query processing strategies, and v) Graph partitioning. In this section we use these dimensions to classify some of the most popular graph stores. Our list is not exhaustive, we considered only the most relevant approaches to show the evolution of the available graph-oriented technologies. Systems built to manage RDF data will be treated in detail in Section 2.3, hence we will not describe them in this section to avoid redundancy.

We classify the approaches in two major groups: native and non-native. The first group consists in systems specifically designed to store and query data represented as graphs. In contrast, non-native approaches are built on top of existent platforms like relational databases, key-value stores and other cloud systems. In this section we describe the most relevant systems from both categories by platform (centralized or parallel). A summary of all the presented systems is given in Table 2.2.

Centralized systems

These systems perform the graph computation only in one machine. The early graph-based systems described in the introduction of this section enter in this category (e.g., [START_REF] Hartmut | Graphdb: Modeling and querying graphs in databases[END_REF]). We find here the leading graph database system that made the property graph data model popular, Neo4j [START_REF] Webber | A programmatic introduction to neo4j[END_REF]. Neo4j is a Java based system in which property graphs are represented through edge lists. Each edge has an entry composed of two linked lists, one for the source s and another for the destination d vertex, storing the previous and next edges connected to s and d respectively. The system allows to query the data directly with the Cypher language or via REST, Java, Javascript or Python APIs.

Before Neo4j a big number of RDF systems had already been developed. The system DEX introduced in [MMG + 07] is an in-memory graph database allowing to query multiple sources. It was written in C++ (although an API is proposed to facilitate the access to data) and efficiently process graph operations using bitmaps. Another in-memory system, HypergraphDB [START_REF] Iordanov | Hypergraphdb: A generalized graph database[END_REF], proposed to model the data as hypergraphs. Its structures are stored as adjacency lists in the BerkleyDB key-value store [START_REF] Michael | Proceedings of the FREENIX Track: 1999 USENIX Annual Technical Conference[END_REF]. Queries are defined as traversal operations using iterator APIs.

More recently, the system GraphChi-DB [START_REF] Kyrola | Graphchi-db: Simple design for a scalable graph database system -on just a PC[END_REF] proposed an efficient data structure which is basically an immutable flat array named Parallel Adjacency Lists to manage and analyze graphs with billions of edges in a single machine. The data are stored in a CSR structure which is partitioned in P intervals such that a single partition P i could fit into main memory. Each partition partitioned by destination vertices ID's and its ordered by source vertex ID. This strategy guarantees an efficient lookup of vertices when querying with Cypher or SPARQL query languages.

Parallel systems

The systems in this category can handle extremely large graphs with billions of edges on a cluster of machines by partitioning the graph so that each machine stores a part of the graph to process it in parallel.

Non-native

The systems in this category are built on top of cloud platforms that avoid building systems from scratch simplifying the storage and processing. In these systems, the graph is stored using the specific data structures and operators of the cloud system. Microsoft Trinity [START_REF] Shao | Trinity: a distributed graph engine on a memory cloud[END_REF] for instance is built on top of an existent shared-memory key-value store. Trinity represents the graph in adjacency lists that are fully processed in-memory achieving low latency to solve queries. Similarly, Titan [START_REF] Datastax | TITAN: Distributed graph database[END_REF] is built on top of HBase and Cassandra a key-value store and a wide-column system respectively. The system TAO [BAC + 13] The source code of Pregel was not public, however many systems followed the execution model described in detail in the Pregel paper. Systems following this BSP are called synchronous. Apache Giraph [START_REF]Apache Giraph[END_REF] is an open source Java implementation of Pregel. It stores the data as vertex adjacency lists in the Hadoop Distributed File System HDFS and the operations are run as map jobs. Several approaches have been built on top of Giraph, some extensions are for instance Giraph++ [TBC + 13]. This system proposes a graph-centric paradigm in which the messages are propagated faster inside a graph close neighbors. An experimental survey about these systems is found in [HDA + 14].

Asynchronous systems claim to be faster than the previous approaches but they are much more complex [CEK + 15]. Graphlab [LGK + 12], a system developed in C++ for shared-memory architectures, belongs to this category. The computation of this system is done through shared state instead of shared messages. A vertex is therefore read/updated from its own data or that of its neighbors instead of using messages.

Commercial graph databases

The commercial offer of systems able to store and query graphs has considerably increased in the past years. The most popular graph database system is Neo4j4 which offers a graph processing compliant with ACID transactions. It offers a reasonable performance for Cypher and traversal queries in a centralized environment. Distributed solutions comprise systems like DGraph5 introducing a json-based query interface (GraphQL). Also, other distributed graph systems like Virtuoso6 and Stardog7 support RDF queries in SPARQL. Besides, several systems are part of multi-model databases built on top of recent cloud platforms, like for example: CosmosDB8 (Microsoft Azure), Amazon Neptune9 (AWS), OrientDB10 (SAP), ArangoDB 11 . So far we have not discussed the systems specifically designed to store and query Web data standardized as a graph. In the following section we give an overview of this standard and detail the systems conceived to treat specifically this data model.

Resource Description Framework

The Resource Description Framework (RDF) [START_REF] Lanthaler | RDF 1.1 concepts and abstract syntax[END_REF] has been widely accepted as the standard data model for data interchange in the Web. RDF is flexible enough to facilitate the integration of data with different schemas. The model uses triples consisting of a subject, a predicate and an object (s, p, o) as the core abstract data structure to represent information. A set of such triples forms a directed labeled graph (described in section 2.2.1) called an RDF graph. The nodes represent IRIs (international resource identifiers), blank nodes (unspecified resources) or literals. Edges on the other side characterize a resource by linking subject and object nodes by a predicate edge. An RDF graph is shown in Figure 2.10a. We formalize the previous concepts in Section 2.3.1, then we present the storage models in Section 2.3.2. The storage models described are used in centralized and distributed RDF system. Then, in Section 2.3.3 we classify RDF systems by processing strategy. Finally, in Section 2.3.4 we describe some of the distributed systems that scale to massive RDF datasets, highlighting the partitioning strategies applied by these systems. The purpose of this entire section is to give an overview of RDF, focusing on the storage and partitioning techniques. Our goal is not to describe in detail each of the current RDF processing systems since there are several surveys dedicated to this (e.g., [KM15, Özs16, AHKK17, WHCS18, ASYNN20]). In this section, we mention only some of the most relevant systems.

Background

An RDF statement is a triple representing a relationship between the subject and object. It is defined as follows:

Definition 2.4 RDF Triple [KM15] A triple (s, p, o) is a tuple from (U ∪B)×U ×(U ∪L∪B)
where s is known as the subject, o the object and p is a relationship between s and o known as the predicate. U, B, L are the sets of IRIs, blank nodes and literals respectively.

As it was previously mentioned, IRIs are the identifiers of Web resources which can be reused in other datasets to represent the same resource and avoid redundancy. We will not delve further into its construction, more details are given in [W3C08]. Blank nodes represent anonymous resources in the subject or object position of the triple. Its syntax is not regulated by the RDF standard, its identification varies according to specific datasets. Literals are values like strings, numbers and dates. A literal is composed of a lexical form, a datatype IRI and a language tag even though some syntaxes may support simple literals with just the lexical form. The IRI's of the nodes of the RDF graph shown in Figure 2.10a where simplified by adding a ":" representing the complete IRI. Also, the datatypes were omitted in the literal nodes. For example, the triple (:Airplane1,has_length,"75.4") is actually:

(http://example.org#Airplane1,http://example.org#has_length>,"75.4"^^xs:decimal).

A set of RDF triples forms an RDF graph defined in [ Özs16] as follows:

Definition 2.5 RDF Graph [ Özs16] An RDF graph is a six-tuple G = ⟨V, L V , f V , E, L E , f E ⟩ such that:
• V and L V are the set of vertices and their labels respectively. V corresponds to all subjects and objects in the data.

• E and L E are the collection of directed edges connecting subjects and objects and their corresponding labels respectively. The label of an edge corresponds to the property connecting a subject and object in the data.

• f V : V → L V and f E : E → L E are bijective functions assigning vertices and edges with their respective label.

An RDF graph is encoded in a document using concrete syntaxes such as N-Triples, Turtle, TriG and JSON-LD. The most basic syntax is N-Triples representing one triple per line as shown in Figure 2.10b.

The RDF data model was extended with annotators like the RDF Schema (RDFS)[DB14] and OWL [START_REF]OWL 2 web ontology language[END_REF]. The RDFS language allows to define more precisely the schema of RDF data inspired in object-oriented programming models. It provides a vocabulary to describe resources with classes, class hierarchies and properties, adding semantics that enable reasoning over the data. Resources are divided in groups called classes, the members of a class are known as class' instances. Classes are themselves resources represented as triples which can be seen as a graph. The principal built-in class definitions are rdfs:Class, rdfs:subClassOf, rdfs:domain and rdfs:range. An example of RDFS annotations to the data of Figure 2.10a is given in Figure 2.11. If a more complete schema is needed, ontology languages offering more expresiveness like OWL [START_REF]OWL 2 web ontology language[END_REF] could be a good solution.

The standard language to query RDF is SPARQL [START_REF] Seaborne | SPARQL 1.1 query language[END_REF] which supports to query required and optional graph patterns, using conjunctions, disjunctions, subqueries and aggregations. An example of a SPARQL query and its representation as a query graph is given in Section 2.2.3.2. SPARQL is based on graph pattern matching. The Basic Graph Patterns (BGP) queries are the most commonly used. A BGP query is a set of triple patterns (s, p, o) of the form

(U ∪ B ∪ V) × (U ∪ V) × (U ∪ L ∪ B ∪ V)
where V is a set of variables. A sequence of triple patterns, with optional filters comprises a BGP query, its syntax (not considering FILTER constraints) is expressed in [START_REF] Kaoudi | RDF in the clouds: a survey[END_REF] as :

SELECT ?v 1 ... ?v m WHERE {t 1 ... t n }
where {t 1 , ..., t n } is a set of triple patterns and ?v 1 ...?v m is the set of variables occurring in {t 1 ...t n }.

An example SPARQL query for the RDF graph of Figure 2.10a finding the airplanes whose length is greater than 65.0 meters is specified as follows:

SELECT ?a ?m ?l WHERE { ?a :type :Airliner . ?a :has_length ?l . ?a :has_model ?m . FILTER (?l > 65.0) }

In this query, the first tree lines in the WHERE clause consist of three triple patterns having variables such as ?a, ?l, ?m. The FILTER clause restricts the solutions matching the triple pattern based on numeric values or strings (with regular expressions). The formal definition of a SPARQL query match is given in Definition 2.6. Definition 2.6 (SPARQL match) [ Özs16] Considering an RDF graph G and a SPARQL query Q having {v 1 , ..., v n } distinct subjects and objects. The set {u 1 , ..., u n } ∈ G is called a match of Q if there exists a bijective function µ : G(U ∪B∪L) → Q(B∪V) where v i = µ(u i )∀ 1≤i≤n and ∀ v i the following conditions are fulfilled:

• Literals/IRIs: if v i is a literal or an IRI → u i has the same value in G.

• Variables: if v i is a variable vertex → u i must satisfy the filter constraint (if any) over the parameter v i .

• Edges: all edges and edge's labels in Q must have a corresponding mapping in G, ∀(v i , v j ) ∈ Q → (u i , u j ) ∈ G. Also, the edge label must satisfy the filter constraint if any.

SPARQL supports more complex operators (e.g., OPTIONAL, ASK, UNION, ORDER BY, LIMIT) that are not considered in this chapter but whose details are found in [START_REF] Seaborne | SPARQL 1.1 query language[END_REF]. We focus our work on the core Basic Graph patterns supported by most of the state of the art systems described in the next section.

Storage models

In contrast to relational databases in which the storage layout is easily represented in a table, in RDF the storage structure depends on the system and the strategy used to further process the data. Let us recall the most popular relational databases storage layouts: i) Row-wise or traditional layout scheme (N-ary storage model NSM), ii) Columnar or decomposition storage model (DSM) [START_REF] Copeland | A decomposition storage model[END_REF], and iii) partitioning attributes across (PAX) [START_REF] Ailamaki | Data page layouts for relational databases on deep memory hierarchies[END_REF]. All of the previous layouts derive directly from the core data structure of the relational model, the table. They store the table's data row by row (NSM), column by column (DSM), or store first row by row and finally partition by attributes (PAX). The storage model of early RDF systems is based on the relational model. Such approaches rely on relational database techniques to efficiently solve SPARQL queries translated to SQL. These storage approaches are described in Section 2.3.2.1. More recently, some systems represent directly the data as a graph, not using an intermediate representation like a table. These approaches are detailed in Section 2.3.2.2.

Relational-based

This storage model stores triples (s, p, o) in relational database tables using one of the following strategies:

• Triple table: this approach initially embraced by Sesame [START_REF] Broekstra | Sesame: A generic architecture for storing and querying RDF and RDF schema[END_REF] stores the data in a single table of three columns (subject, predicate, object). An example of this storage is illustrated in Figure 2.12a. In terms of space complexity it equals the size of the graph and without indexes lookups require scanning the whole table. This is in fact its major drawback, the processing of self-joins turns quite expensive when SPARQL queries become more complex. To improve performance, triple tables are lexicographically ordered in several optimization strategies have been proposed, for example:

-Indexing: establishing a lexicographical order of the [START_REF] Vincent | Multi-attribute retrieval with combined indexes[END_REF][START_REF] Shneiderman | Recuced combined indexes for efficient multiple attribute retrieval[END_REF]. This techinque avoids a full scan of the table for any single query pattern. Also, the index could be built only on a subset of the columns (e.g., SP, PO). This strategy, named projection indexes, allows to solve queries using only merge joins. The most popular system using a combination of both strategies (exhaustive and projected indexes) is RDF-3X [START_REF] Neumann | RDF-3X: a risc-style engine for RDF[END_REF] which indexes all the permutations of the table's attributes and some of its projections. More recently, RDFox [NPM + 15] uses only three index columns and three secondary projection indexes.

-Dictionaries & encoding: to reduce the size of a triple table, which can become very large due to redundancy, several compression techniques are proposed to improve the reading efficiency. Using dictionary tables mapping each individual value to a dense domain of positive integers reduces considerably the lookup time, reducing it to a logarithmic search instead of a full scan. Deeper encoding techniques based on byte encoding reduce even more the space of the encoded data storing only the increment (delta) of one row to another. For example, in the triple table of Figure 2.12a, the subject of the first row will be encoded, while a 0 byte will be assigned to encode the subject of the second row since it is the same as the first one. The byte delta encoding technique is embraced by the RDF-3X [NW08] system. partitioning it. Each partition gathers the data sharing a similar schema. The idea is that although RDF data does not define an explicit schema, its schema is implicit in the data and can be found with diverse approaches. An example of a property table partitioned using emerging schemas is shown in Figure 2.13a. Some of the most relevant approaches to find emergent schemas are: * The clustering strategy for RDBMS described by Chu et al. named hidden schemas in [START_REF] Chu | The case for a widetable approach to manage sparse relational data sets[END_REF] can be very useful to find emerging schemas. In their work, the authors mapped the table's attributes to a weighted graph and then used the k-nearest neighbor partitioning algorithm to create the sub-relations along with the Jaccard similarity to measure the strength of co-occurrence between the two attributes. * The term emergent schema for RDF was introduced in [START_REF] Pham | Deriving an emergent relational schema from RDF data[END_REF]. In this work, the authors used the characteristic sets cs defined in [START_REF] Neumann | Characteristic sets: Accurate cardinality estimation for RDF queries with multiple joins[END_REF] and formally described in Definition 2.7 to cluster triples and create the implicit schema tables. The characteristic sets for the entire table are merged based on a semantic and structural scores. The structural score identifies discriminating properties on each cs using an adapted TF/IDF similarity score. The distributed RDF system EAGRE [START_REF] Zhang | EAGRE: towards scalable I/O efficient SPARQL query evaluation on the cloud[END_REF] used as well the characteristic sets to distinguish entities and store the data of similar entities together. * More recently, the approach Cinderella [START_REF] Herrmann | Cinderella -adaptive online partitioning of irregularly structured data[END_REF] proposed a strategy to partition partitioned incoming data on the fly based on their similarity schema and in an existent partitioning which can be obtained with either of the previously described methods. The system fix the maximum size for partitions and new entities are assigned to the closest partition.

-Hashing: This technique embraced by DB2 for RDF [BDK + 13] maps the predicate and the object of a triple to a column group using a hashing function. The number of column groups is given as a parameter, collisions are stored in new rows (named spill row) adding a flag column as shown in Figure 2.13b. A reverse primary hash could be applied by hashing the values to groups from the triple's object.

-Bit encoding: The system BitMat [START_REF] Atre | Matrix "bit" loaded: a scalable lightweight join query processor for RDF data[END_REF] propose a bit-wise matrix representation of property tables. In this matrix, each cell is either 0 or 1 representing the absence or existence of that triple. An example of this strategy is shown in Figure 2.13c. During query processing, queries are executed on the compressed data. Airplane1 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 ... Airplane2 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 ... B747 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 ...

Graph-based

This storage strategy maintains the graph structure of RDF representing the data using the structures representing the adjacency of directed graphs defined in Section 2.2.2 of this chapter. At query runtime, these approaches exploit the graph nature of RDF and SPARQL reducing the query execution to a subgraph matching problem. These structures allow efficient lookups of the neighbording vertices for a given vertex. We will not detail each of the structures again to avoid redundancy. However, we will describe some of the most relevant optimization strategies used by some of the graph-based systems:

• Encoding: Similarly to triple tables, data in adjacency structures are compressed and grouped to streamline the lookup process. In this line, ordering the vertices lexicographically should be complemented with other ordering strategies that reflect data locality (close neighbors should be placed close in the data structure). The adjacency list could be encoded with dictionaries as in the relational-based approaches, using bit compression deltas to encode neighbors [START_REF] Boldi | The webgraph framework I: compression techniques[END_REF] or more complex tree-based structures (K 2 -trees [BLN09]). GStore for example.

• Indexing: the simplest strategy indexes the keys of the adjacency lists in a B+Tree if the vertices are lexicographically sorted. More complex secondary structures concern the problem of finding all vertices that are reachable from a given vertex useful for long path and distance queries. Among these strategies we find the 2-Hop indexing scheme [START_REF] Cohen | Reachability and distance queries via 2-hop labels[END_REF] and the tree-based index FERRARI [START_REF] Seufert | FERRARI: flexible and efficient reachability range assignment for graph indexing[END_REF].

The first system that considered RDF directly as a graph was presented in [START_REF] Bönström | Storing RDF as a graph[END_REF].

This system was was built on top of an object-oriented database. Later, the system BitMap [ASH08] used an adjacency matrix. The matrix encodes the triples of an RDF graph completely in a bit matrix that is flattened in two dimensions.

Both of the optimization strategies described previously are applied in the graph-based RDF processing system gStore [Z ÖC + 14]. This system encodes the entities in adjacency lists grouping the vertex's and its adjacent edge labels into a fixed length bit string. The encoded data are stored in a VS * -tree index (height-balanced tree where each node is a bitstring that corresponds to an encoded vertex). An incoming SPARQL query is also encoded using a similar structure and the query problem is reduced to a sub-graph matching problem. Systems built on top of key-value stores also integrate this category. Trinity.RDF [ZYW + 13] is built on top of the in-memory key-value store Trinity. For each node it stores the adjacency lists of outgoing and incoming edges helping the query evaluation seen as a graph exploration process. Similarly, the commercial graph system Stardog12 supports SPARQL of data stored in the RocksDB 13 keyvalue store. The major issue confronted by these approaches is scalability to large RDF graphs [AHKK17, Özs16].

Processing strategies

Processing SPARQL queries is a complex task in which a wide variety of approaches are available. The former systems were built on top of relational databases storing triples in tables as described in the previous section and directly translating SPARQL to SQL. Later, systems built specifically to treat RDF data came to light implementing its own physical storage and operators. More recently, parallel RDF systems follow the same strategy building these systems on top of cloud platforms transforming SPARQL queries into equivalent operators of the platform (e.g., MapReduce jobs). In general, RDF systems can be divided into 2 large groups: native and non-native whose characteristics are given below:

• Native systems are specifically built to treat RDF data (e.g., RDF-3X [START_REF] Neumann | RDF-3X: a risc-style engine for RDF[END_REF], gStore [Z ÖC + 14], TriAD [START_REF] Gurajada | TriAD: a distributed shared-nothing RDF engine based on asynchronous message passing[END_REF]). These systems use custom physical layouts, native indexing strategies, efficient communication protocols and explicit replication. They could use relational-based storage layouts but their execution core is independent from a relational database. They require certainly a greater effort for development, yet they have proven to outperform the non-native strategies [START_REF] Abdelaziz | A survey and experimental comparison of distributed SPARQL engines for very large RDF data[END_REF].

• Non-native systems are built on top of existent technologies like relational databases (e.g., Virtuoso [START_REF] Erling | Virtuoso: RDF support in a native RDBMS[END_REF]), key-value stores (e.g., Trinity.RDF [ZYW + 13]), cloud platforms like MapReduce (e.g., EAGRE [START_REF] Zhang | EAGRE: towards scalable I/O efficient SPARQL query evaluation on the cloud[END_REF], SHARD [START_REF] Rohloff | Clause-iteration with mapreduce to scalably query datagraphs in the SHARD graph-store[END_REF]) and Spark14 (e.g., S2RDF

[SPSL16]) among others. As it was previously mentioned, the query processing in these systems consists to transform a SPARQL query to the known operators of the parent system. For instance, SPARQL is translated to SQL or to MapReduce jobs if the system is built on top of a relational database or a Hadoop15 distribution respectively.

Complete surveys on both type of systems exist. For example, [START_REF] Kaoudi | RDF in the clouds: a survey[END_REF] surveys all the systems built on top of different cloud platforms. An experimental comparison of both type of systems was performed in [START_REF] Abdelaziz | A survey and experimental comparison of distributed SPARQL engines for very large RDF data[END_REF]. More general surveys in which the systems are further classified according to their storage, indexing strategy, and query execution are [ Özs16, WHCS18, ASYNN20]).

Data partitioning

To cope with the increase in available RDF data and the need to process it efficiently, RDF systems resorted techniques of distribution and parallel processing extensively explored in relational databases. Within distributed RDF systems we find two groups, federated and clustered systems which are described as follows:

• Federated systems run SPARQL queries over multiple SPARQL endpoints. A SPARQL endpoint is a protocol service which allows to query data stored in RDF using the SPARQL language. Such systems require to perform data integration on-the-fly of multiple heterogeneous RDF sources. Federated systems are out of the scope of our study.

• Clustered RDF systems distribute the data among different data nodes that are part of a single RDF storage solution. For several years, a large number of distributed systems offering efficient RDF data processing have come to light. We focus our study in this type of systems.

In this section we classify these works according to the partitioning strategy applied to distribute the data. We present a scheme summarizing the process of data partitioning in RDF processing systems regardless of the execution model. We divide the process illustrated in Figure 2.14 in three phases: Fragmentation, Allocation and Replication. The dashed squares in the figure represent the optional phases of the process. We use this common framework inspired from the strategy used for distributed databases described in [ ÖV11] to guide our classification. In what follows we detail the inputs, outputs and algorithms on each one of these stages.

Fragmentation

The fragmentation process consists in setting the fragmentation unit to be allocated over the sites of the distributed system. There is no consensus regarding how RDF data should be distributed. Most of current solutions use the triple as fragmentation unit. However, it has been claimed that grouping the triples first might improve the performance by discovering implicit structures in the input RDF graph [BDK + 13, SGK + 08]. Consequently, other solutions propose to group the triples by subject, predicate or object first and use these groups as fragmentation units. Other solutions go further and group the sets of triples (grouped by subject or object) in entities identified for instance with characteristic sets [START_REF] Pham | Deriving an emergent relational schema from RDF data[END_REF][START_REF] Neumann | Characteristic sets: Accurate cardinality estimation for RDF queries with multiple joins[END_REF]. Regardless of how the data are physically represented by each system (e.g., triple table, property table), and of the execution engine (e.g., relational-based, subgraph matching), the fragmentation units shown in Figure 2.14 cover all the approaches of our state of the art.

Fusion This optional stage consists in creating broader groups of triples to be allocated over the sites of the distributed system. The fragmentation units are merged applying either of the following techniques:

• Graph partitioning: The fragmentation units are mapped to a graph to apply graph partitioning heuristics clustering the fragmentation units. The graph is built mapping the fragmentation units like triples (in H-RDF-3X [START_REF] Huang | Scalable SPARQL querying of large RDF graphs[END_REF]), or groups of triples (entities in EAGRE [START_REF] Zhang | EAGRE: towards scalable I/O efficient SPARQL query evaluation on the cloud[END_REF]) to nodes of the graph. The edges (which could be weighted) represent the connectivity within the fragmentation units. A partitioning graph heuristic, mostly METIS [START_REF] Karypis | A fast and high quality multilevel scheme for partitioning irregular graphs[END_REF] is used to generate the groups of fragmentation units.

• Workload-based : in these techniques the fragmentation units are grouped according to a given query workload. Triples that are queried together are gathered in the same fragments to optimize the query execution.

• Semantic-based : this approach gathers fragmentation units based on the semantic similarity (using ontologies for instance) of the concepts represented in the graph.

The fusion process is not applied in all the proposed systems and it is therefore an optional step (bounded by a dashed rectangle in Figure 2.14). Many systems choose to apply allocation strategies directly to the fragmentation units (e.g., triples, groups of triples by subject).

Allocation

The allocation stage consists in finding the distribution of a set of fragments {F 1 , ..., F n } (which are the output of the previous stage) to a set of sites {S 1 , ..., S m }. The distribution of fragments is done applying the following techniques:

• Hashing: a hashing function is applied to the fragmentation unit or the fragment's attributes (e.g., gStoreD [PZ Ö+ 16]).

• Round-robin: the fragments from last stage are placed on each site indistinctly. This is the case of the fragments obtained after a graph partitioning fusion.

• Cloud-platform dependent: in this case the allocation task is left to the cloud platform (e.g Hadoop, Spark) on which the RDF distributed system was built on top. Most of these platforms use distributed file systems, partitioning the data by blocks and finally sharding them to the worker nodes.

Replication

Data replication is a frequent yet not a mandatory optimization strategy applied by several clustered RDF distributed systems. The replication strategies are as follows:

• Permutation: in this strategy copies with different sort orders are maintained in systems representing the data as a single triple table. In general the copies are not exact replicas of the data, but encoded and compressed indexed versions. For example, RDF-3X [NW10] keeps 9 indexes (e.g., subject-predicate-object SPO, object-predicate-subject OPS) corresponding to the extended permutations of the triple table's attributes (subject, predicate object).

• Combine fragments: this strategy consists in gathering triples in different fragmentation units (e.g., grouping by subject, then grouping by object) and creating a copy of the data for each organization. This fragmentation strategy is embraced by the system RDF QDAG [KMG + 20]).

• K-hop guarantee: this strategy is used specifically in systems whose fragmentation units are merged with a graph partitioning strategy. For any vertex v assigned to a worker node f , all vertices up to k-hops away and their corresponding edges are replicated in f . Systems applying this strategy are H-RDF-3X [START_REF] Huang | Scalable SPARQL querying of large RDF graphs[END_REF] and SHAPE [START_REF] Lee | Scaling queries over big RDF graphs with semantic hash partitioning[END_REF].

• Cloud platform: this replication strategy takes place in systems built on top of a cloud platform, in this case the replication rules are established by the cloud platform. For example, the systems using the Hadoop Distributed File System HDFS replicate by default with a factor 3. Systems using HDFS as storage layer are Hadoop, Apache Spark or keyvalue stores like HBase16 . Distributed RDF systems in this category are HadoopRDF [START_REF] Du | HadoopRDF: A scalable semantic data analytical engine[END_REF], S2RDF [START_REF] Schätzle | S2RDF: RDF querying with SPARQL on Spark[END_REF], H2RDF[PKT + 13] just to name a few. Some efforts have also been made to build a system to benchmark partitioning strategies. The system Koral[JST17], for example, allows the integration of different RDF graph partitioning techniques to investigate their behavior.

In Table 2.3 we classify the systems of the state of the art based on the partitioning framework introduced previously. In the table we included approaches built on top of cloud platforms and also systems built specifically to deal with RDF data.

Conclusion

In this chapter, we gave first a general overview of the graph data model. We detailed its logical and storage structures, described the query processing strategies and languages, and reported some of the most relevant current available systems. In addition, we dedicated a section to describe the graph partitioning algorithms used by some parallel systems. This section allowed us to understand the number of solutions available within systems merely treating data as graphs. We saw the advantages of the model but also its limits, especially due the variability of the methods used to partition and process the data. Next, to better delimit our work we focused on one of the many existent graph-based data models. Specifically on RDF, the data model for data interchange in the Web. We start by giving some background concepts, and similarly to what we did with the graphs in general, we described RDF storage, processing and partitioning strategies. In RDF, partitioning is dependent on the physical organization of the data (i.e. stored in a triple table, property table or graph structure). We showed that RDF partitioning strategies are conditional to a system and contrarily to relational databases, there is no common logical layer covering all existing partitioning variations. We say that RDF data partitioning is system-driven, in contrast to partitioning in relational databases that we named data-driven. In relational databases, there are tools (e.g., advisors, definition languages) giving comfort the database designer to create partitions according to the structure of the tables or a partitioning scheme that meets the demands of some workload. This is not the case in RDF, the data are charged into a system which, in general, automatically partitions the data with a predefined strategy. The process is similar to what happens in cloud platforms as described in last chapter, in which the data are split in blocks and hash distributed among the working nodes.

Table 2.4: Main strenghts relational and RDF partitioning

Relational RDF -Integration of data not following the same initial schema is complex.

+ Flexible integration of new data.

+ DBMS-independent: partitioning is independent of the database management system.

-System-dependent: the execution system and the partitioning strategy are coupled.

+ Partitioning at a logical level : Independent of the physical model used to store the data (e.g., NSM, DSM).

-Dependent on the physical storage model (e.g., triple-based, graph-based).

+ Native database definition languages support to declare horizontal partitions.

-Partitioning performed transparently during the loading stage.

+ Several automatic partitioning advisors are available help the designer to create partitions.

-Data partitioning is mostly imposed by the triple store.

The partitioning strategies adopted by RDF systems also have several advantages. For example, most approaches allow for simple data integration. Indeed, one of RDF assets is its flexibility to integrate data with different underlying schemas. The relational model, on the other hand, is often too rigid to handle data without giving an upfront schema. This contributes to tailor partitioning advising tools for the designer creating partitions based on the data structure and workload needs. Some approaches in RDF tried to model RDF data in a relational database schema before storing the data in a RDBMS. However, as it is demonstrated by surveys, relational-based systems are not optimal when dealing with highly complex queries. The strengths and drawbacks (mostly mutually exclusive) of both data models are summarized in Table 2.4.

We consider necessary to provide tools for RDF system designers mimicking the comfort offered in relational database systems. This led us to fix the objective of this thesis which consists in proposing an RDF data partitioning framework that is based on implicit logical structures. The development of this framework will be covered throughout the next chapters.

Chapter 3

Logical RDF Partitioning

Summary

Based on the analysis of the literature presented in the first part of this thesis, we propose a partitioning environment for the design of opaque systems. We draw on the lessons learned in the relational model that partitions the data based on logical structures. In this chapter, we give the formal definition and detail the algorithms to create these logical entities that we named graph fragments (Gf ). These entities harmonize with the notion of partitions by instances (horizontal) and by attributes (vertical) in the relational model. We start giving an overview of this logical layer in Section 3.2, comparing our strategy to the current state of the art. Then, we formally define the logical entities in Section 3.3. This section includes the algorithms to group RDF triples in graph fragments. Next, in Section 3.4 we discuss the usage of these fragments as physical storage structures. Section 3.5 formalizes the allocation problem of these fragments in opaque systems. Section 3.6 presents an complete example of the creation and allocation algorithms described in the previous sections. Then, Section 3.7 presents strategies to deal with large logical fragments. Finally, Section 3.8 concludes this chapter.

Introduction

The Resource Description Framework (RDF) has been widely accepted as the standard data model for data interchange in the Web. Formerly, RDF intended to model exclusively information in the Web but its flexibility allowed the standard to be used in other domains (e.g., genetics, biology). Currently, collections of RDF triples are extensive sources of information. The size of many RDF datasets can exceed more than a billion triples (e.g., DBPedia: 3 billion triples1 , Bio2RDF: 5 billion triples2 ) pushing the development of scalable processing systems. To this end, several systems rely on parallel and distributed architectures partitioning the data on distinct processing workers.

Most of the distributed and parallel RDF systems (RDFDS3 ) partition the data using the triples as distribution units and apply, for example, hashing functions sharding the triples at its finest granularity. These strategies do not allow to keep the graph structure of the model or triples belonging to the same entity together, impairing the system's performance. Furthermore, most systems are dependent on a single partitioning strategy.

We draw on the lessons learned in the relational model, in which data partitioning is performed at a logical level, independent of the storage approach. In the following we introduce a logical layer to the partitioning process of opaque RDFDS. We start giving an overview of this logical layer comparing our strategy to the current state of the art. Then, we formally define the logical entities and propose the algorithms to group RDF triples in graph fragments. Next, we discuss the usage of these fragments as physical storage structures and formalize their allocation problem. Finally we present a complete example of the creation and allocation heuristics defined in this chapter.

RDF partitioning design process

The design of a distributed system entails the distribution of data and programs to the sites of the computer network in which the system is deployed. We focus on the problem of data distribution seeking to find and allocate the optimal distribution units. In distributed relational databases, the design process starts similarly to centralized systems with a requirements analysis specifying the data and processing needs. The requirements are the input of the conceptual design stage that maps requirements to entities, attributes and relationships. The result of this stage is the global conceptual schema which is in turn the input of the distribution design step. This step determines the distribution units and their location. Entire tables could be used as distribution units, however it is preferable to use table subsets named partitions or fragments. To make this process more understandable, the distribution design is subdivided in [ ÖV11] in two sub steps. The first one, named fragmentation, determines the distribution units and then the allocation step places them to the sites of the network. The previous process is summarized in Figure 3.1a.

The conceptual design phase explicitly declaring the high-level entities like in relational databases does not occur in RDF systems. Instead, the data are organized in a schema-free model using triples whose global structure is not explicitly stated. This characteristic gives RDF more flexibility to integrate data with different schemas but it pays the price during the physical design [A ÖD14]. Furthermore, the data related to the same high-level entity can be easily scattered through the batch of data. When it comes to the distribution of RDF data, there is no consensus about how the data should be fragmented and allocated. Currently, the partitioning strategies are highly dependent on the backend system used to store the data. For example, the systems built on top of cloud platforms delegate the partitioning choice to the distributed file system which usually hashes the data by chunks. Specialized systems use triples as distribution units and usually apply hashing functions to decide the triple's location.

There have been some efforts to explicitly add a class hierarchy schema to RDF through annotations (e.g., RDF schema and ontologies). Furthermore, as shown in [START_REF] Pham | Deriving an emergent relational schema from RDF data[END_REF], i) the entities in a single dataset can be described with multiple ontologies, ii) not all the entities in a dataset are annotated with the same metadata and, iii) not all SPARQL query patterns consider them. Using these annotations in the identification of implicit entities is not very effective.

The identification of higher-level entities in RDF has also been researched in the context of query optimization. Specifically, to collect statistics to estimate the cardinality of triple patterns. Instead of collecting statistics on the entire dataset, approaches like the characteristic set [START_REF] Neumann | Characteristic sets: Accurate cardinality estimation for RDF queries with multiple joins[END_REF] for instance, collect statistics on higher-level entities. In [START_REF] Neumann | Characteristic sets: Accurate cardinality estimation for RDF queries with multiple joins[END_REF], these entities are detected using the structure of the original dataset grouping the triples by subject first and further gathering the data according to their predicates. This strategy does not rely on the annotations (e.g RDFS) to identify entities and it allows to consider some of correlations missed by the other optimization approaches based global statistics. This technique has been reused to detect a relational schema to the data as we will see below.

Grouping the triples in higher level entities has also been explored in relational-based RDF systems. The goal of these approaches is to build a relational schema and map the triples to multiple relational tables. For example, the hidden schemas [START_REF] Chu | The case for a widetable approach to manage sparse relational data sets[END_REF] introduced in DB2RDF inferred an RDF schema to vertically partition a property table via attribute clutering. The emergent schemas approach in [START_REF] Pham | Deriving an emergent relational schema from RDF data[END_REF] combines the characteristic set with other clustering techniques to identify implicit structures within the data. More recently, [START_REF] Herrmann | Cinderella -adaptive online partitioning of irregularly structured data[END_REF] introduced Cinderella to incrementally partition bulk data inserts assigning a schema with a similarity measure between attributes. The techniques described previously could be generalized in a framework allowing the discovery of implicit entities used by optimization strategies (like indexes) or as data fragments.

Our work introduces a logical dimension to the partitioning process of RDF graphs. We draw on the lessons learned in the relational model, in which data partitioning is performed at a logical level, independently of the storage approach used to persist the data. This wise strategy has proven its success due to its great balance between conceptual and intuitive simplicity [START_REF] Ordonez | Guest editorial-dawak 2018 special issuetrends in big data analytics[END_REF]. The proposed process is illustrated in Figure 3.1b. We borrow some of the techniques in the literature used to identify higher-level entities in RDF datasets and define logical RDF fragments. Then, based on these fragments we propose allocation strategies considering the initial connectivity of the data, keeping the original graph structure and avoiding data skewness.

Graph fragments

Many studies have shown that grouping triples contributes to improve the performance of centralized (e.g., [START_REF] Chu | The case for a widetable approach to manage sparse relational data sets[END_REF][START_REF] Pham | Deriving an emergent relational schema from RDF data[END_REF]) and distributed (e.g., [START_REF] Abdelaziz | A survey and experimental comparison of distributed SPARQL engines for very large RDF data[END_REF]) RDF systems. In this section we propose to cluster the data in groups inspired from the partitions in the relational model. In relational databases, an entity (a table) is partitioned at the instance (horizontal) or attribute level (vertical). Indeed, horizontal and vertical partitions let to retrieve only relation's subsets avoiding full table scans. Considering that in RDF there is no conceptual design stage like in relational databases, our proposal looks to detect implicit entities based on the structure of the RDF graph. Such entities represent the implicit schema of an RDF graph In fact, the characteristic set (defined in Definition 2.7) of a node in an RDF graph allows to group the instances of the same high-level entity to form a partition. In the following section we define two kinds of entities, following the idea of fragmenting the entities at the instance or attribute levels, but with an actual graph connotation.

Grouping the graph by instances

To gather the triples of the same high-level entity we group in the first place the triples by its subjects. These structures defined in Definition 3.1 are named forward data stars. Let us first define the functions f s (t) → s, f p (t) → p and f o (t) → o returning the subject, predicate and object of an RDF triple t = ⟨s, p, o⟩ respectively. Both functions are applied in some of the definitions of this chapter. Definition 3.1 (Forward graph star) A forward graph star denoted as -→ Gs(s) is a subset of G in which the triples share the same subject s. Formally, -→ Gs(s) ⊆ G, such that -→ Gs(s) = {t|∀ i̸ =j (f s (t i ) = f s (t j ) = s)}. We name the subject s the head of the forward star.

A forward graph star gathers all the properties associated with a node describing a single occurrence of a certain entity. As shown in Theorem 3.1, a triple can only belong to a single forward graph star. The entities can be uniquely identified by a subset of their emitting edges [START_REF] Neumann | Characteristic sets: Accurate cardinality estimation for RDF queries with multiple joins[END_REF]. To characterize them we use the notion of characteristic set defined in Definition 2.7.

Theorem 3.1 A triple belongs to one and only one forward graph star. Let t be a triple

t ∈ G, if t ∈ -→ Gs i ⇒ ∀ i̸ =j (t / ∈ -→ Gs j ).
Proof. To prove by contradiction. Let us assume that a triple t ∈ -→ Gs i and t ∈ -→ Gs j . Let us consider two not equal triples t 1 , t 2 , both different from t, such that t 1 ∈ -→ Gs i and t 2 ∈ -→ Gs j . Based on the forward entities definition, f s (t 1 ) = f s (t) and f s (t 2 ) = f s (t). Using the transitivity of the equality,

f s (t 1 ) = f s (t 2 ) which is impossible if -→ Gs i ̸ = -→ Gs j .
A forward graph fragment formally described in Definition 3.2 gathers forward graph stars according to their characteristic set. As it was previously mentioned, we can characterize an entity by its emitting edges. A forward graph fragment is a logical structure used to gather the In general, two forward graph stars belong to the same entity if the labels of their emitting edges (i.e. the predicates) are the same. Yet, sometimes two instances belong to the same entity but their characteristic sets are not exactly the same. This is the case when two characteristic sets differ only in non-discriminating predicates. To avoid creating a great number of fragments with a very strict similarity criteria, we used a similarity score and a threshold. The similarity scores are described in Sect. 3.3.1.1. The characteristic set of a graph fragment is therefore the union of the characteristic sets of the graph stars of the fragments. To simplify the notation, the function cs( -→ Gf ) returns the characteristic set (which is the identifier) of the fragment.

Definition 3.2 (Forward graph fragment) A forward graph fragment is a set of forward graph stars -→ Gs that have similar characteristic sets according to a threshold τ . A forward graph star -→ Gs i belongs to one and only one forward graph fragment -→ Gf i . Formally,

-→ Gf = { ---→ Gs(s)|∀-→ Gs(s i )̸ = -→ Gs(s j ) ( Sim(cs(s i ), cs(s j )) ≥ τ )
, }.

Similarity scores

The similarity function Sim(cs(s i ), cs(s j )) returns a score measuring how similar both characteristic sets are. In its calculation, it can consider just the structure of the characteristic set and their relationships or more complex semantic features. Among the structural similarity functions we find:

• Supersets: this similarity strategy merges two characteristic sets if there is a larger set that contains all the properties of the smaller one. It is calculated as follows:

Sim(cs(s i ), cs(s j )) = |cs(s i ) ∩ cs(s j )| M in(|cs(s i )|, |cs(s j )|)
To ensure that only full subsets are merged with supersets, the threshold τ is fixed to 1.

• Jaccard similarity: this measure evaluates only how many predicates both sets have in common. Contrarily to the previous function, it considers not only the superset case.

Sim(cs(s

i ), cs(s j )) = |cs(s i ) ∩ cs(s j )| M ax(|cs(s i )|, |cs(s j )|)
• Tf-idf [START_REF] Pham | Deriving an emergent relational schema from RDF data[END_REF]: this criteria used in Information Retrieval expresses the frequency of a term taking into account how often the term is used in the corpus. The measure is interesting to compare characteristic sets since it could be adapted to weight the predicates according to their discriminatory power, giving less weight to predicates shared by almost all the characteristic sets of the dataset. The tf-idf measure of a predicate in a characteristic set is calculated as follows:

tf idf (p, cs) = 1 |p| • log ( #T otalCSs 1 + #countCSs(p) )
Where the tf factor is always 1 since every property occurs once per characteristic set, #T otalCSs is the total number of characteristic sets, and #countCSs(p) is the total number of characteristic sets having property p in the property list. The measure can be normalized to take into account the length of the characteristic set:

tf idf (p, cs) = ( 0.5 + 0.5 * 1 |cs| ) • log ( #T otalCSs 1 + #countCSs(p) )
Finally, the tf-idf values for each predicate are used to calculate cosine similarity as:

Sim(cs i , cs j ) = ∑ p∈(cs i ∩cs j ) tf idf (p, cs i ) × tf idf (p, cs j ) √ ∑ p i ∈cs i tf i df (p i , cs i ) 2 × √ ∑ p j ∈cs j tf i df (p j , cs j ) 2
On the other hand, if the similarity is based on semantic measures there are two alternatives:

• Same label: this strategy merges two characteristic sets if their semantic label (identified by the predicate rdfs:label) is the same. This similarity is binary, if both characteristic sets have the same label the similarity is 1 and 0 otherwise.

• Ancestor-based: This strategy checks at the hierarchy of classes in the ontology and assigns a similarity 1 if both sets share a common ancestor. However, the similarity score weights whether the common ancestor is too general in the ontology. Given a common ancestor, the similarity is calculated as follows:

Sim(cs i , cs j ) = log ( #T otalInstO #InstC )
Where #T otalInstO is the total number of instances covered by the ontology and #InstC is the total number of instances covered by the ancestor.

Both of the previous similarities are calculated only if a common ontology exists between both cs, otherwise the structural similarity is preferred.

To assign a forward graph star -→ Gs(s) to a forward graph fragment, a pairwise similarity is calculated between the characteristic sets of the forward star and the fragments already assigned to Gf . The graph star is assigned to the fragment with the highest similarity only if its similarity score is higher than the given threshold τ . Let us consider for example a forward graph star -→ Gs(s i ) and the set of forward fragments

-→ Gf = { -→ Gf j , --→ Gf k }.
To calculate the similarity one can encounter the following cases:

(i) If Sim ( cs(s i ), cs( -→ Gf j ) ) > Sim ( cs(s i ), cs( -→ Gf k ) ) > τ then Gs i ∈ -→ Gf j .
(ii) If both scores have the same value, Sim

( cs(s i ), cs( -→ Gf j ) ) = Sim ( cs(s i ), cs( -→ Gf k ) ) > τ , then -→ Gs i is assigned to either of the sets -→ Gf j or --→ Gf k .
(iii) If the forward graph star has not a similarity score greater than the threshold with any of the graph fragments, formally expressed as:

∀ i̸ =j ( Sim ( cs(s i ), cs( -→ Gf j ) ) ) < τ )
then the the forward star -→ Gs forms a forward graph fragment on its own ( -→ Gf = -→ Gs i ).

Forward fragmentation algorithm

The generation of forward graph fragments is described in Algorithm 1. The inputs of the algorithm are an RDF file in SPO order and a similarity threshold τ . We consider an ordered file since many triple stores employ bulk loading techniques that efficiently encode and organize the data. The algorithm starts initializing an empty graph star, a variable storing the subject of the first triple and an empty map structure mapping characteristic sets to graph fragments. Then it makes a single pass through the triples of the dataset (Step 2). The loop creates a graph star set until it detects a change in the subject of the current triple (Step 3). At this point, it generates a key combining the set of ID's of the predicates that co-occur in a graph star with a hashing function (Step 6). If the key is already in the map of characteristic sets, it assigns the star directly to the fragment and appends it to the set of graph fragments with the function appendGf (Step 9). If there is no key in the map with the star's key then it uses the function updateGf which applies the similarity functions to decide to which fragment the star should be appended (Step 11). The functions appendGf and updateGf are described in Algorithms 2 and 3 respectively. The algorithm returns the set of graph fragments, the map of characteristic sets and fragments, and a map assigning a subject with the corresponding graph fragment (Step 18).

Algorithm 1 Generation of forward graph fragments

Input: RDF file D of {t 1 , ..., t n } triples t = ⟨s, p, o⟩ in SP O order, threshold similarity τ Output: Set of fragments

-→ Gf = { -→ Gf 1 , ..., -→ Gf p }, characteristic set map CSM ⟨key, -→ Gf k ⟩, subject map SM ⟨s i-1 , -→ Gf k ⟩ 1: Initialize -→ Gs = ∅, s i-1 = f s (t 1 ), CSM ⟨key, -→ Gf k ⟩ = ∅,SM ⟨s i-1 , -→ Gf k ⟩ = ∅ 2: for each t i in D do 3: if s i-1 = f s (t i ) then 4: -→ Gs(s i-1 ) = -→ Gs(s i-1 ) ∪ {t i } 5:
else 6: key = Hash(cs(s i-1 ))

7:

if key ∈ CSM.keySet() then 8:

-→ Gf k = CSM.get(key) 9:

-

→ Gf = appendGf ( -→ Gs(s i-1 ), -→ Gf k , -→ Gf ) 10:
else 11:

( -→ Gf , CSM, -→ Gf k ) = updateGf ( -→ Gs(s i-1 ), -→ Gf , τ, CSM ) 12: end if 13:
-→ Gs(s i-1 ) = {t i } 14:

SM.put(s

i-1 , -→ Gf k ) 15:
end if 16:

s i-1 = f s (t i ) 17: end for 18: return -→ Gf , CSM ,SM
The appendGf (Alg.2) function takes a given graph star, and appends it to the indicated graph fragment (Step 1). Finally it updates the global set of graph fragments (Steps 2 -3). The updateGf function (Alg. 3) uses the similarity functions described in Section 3.3.1.1 to decide whether to append the graph star to a given fragment or to create a new one. The algorithm considers the case in which two similarity functions are prioritized. For example, using a semantic similarity (which is a binary similarity) first and if it does not find any match, apply a structural similarity. The algorithm makes a single pass through the already assigned graph fragments (Step 2). It uses the first similarity measure and, if it finds a graph fragment whose similarity is 1, it assigns the graph star to the fragment and stops the search (Steps 3 -5). The second similarity measure is used the case in which the first measure did not find any match (Steps 7 -9). If after going through all the assigned fragments it still does not find any match, it creates a new graph fragment (Steps 13 -15). It returns the set of updated graph fragments, the updated characteristic set map and the fragment assigned to the graph star (Step 20).

Algorithm 2 appendGf function

Input: A graph star -→ Gs(s), a graph fragment -→ Gf k ∈ -→ Gf , a set of graph fragments -→ Gf Output: Updated set of graph fragments -→ Gf 1: -→ Gf k = -→ Gf k ∪ -→ Gs(s) 2: -→ Gf = -→ Gf - -→ Gf k 3: -→ Gf = -→ Gf ∪ -→ Gf k 4: return -→ Gf Algorithm 3 updateGf function Input: A graph star -→ Gs(s), a set of graph fragments -→ Gf , a similarity threshold τ , Map of graph fragment keys CSM ⟨key, -→ Gf k ⟩ Output: ( -→ Gf , CSM ⟨key, -→ Gf k ⟩, -→ Gf tmp ) 1: Initialize max = 0, -→ Gf tmp = ∅, key = Hash(cs(s i )) 2: for each -→ Gf i in -→ Gf do 3: if Sim A (cs(s), cs( -→ Gf i )) = 1 then 4: -→ Gf tmp = -→ Gf i 5: break 6: else 7: if Sim B (cs(s), cs( -→ Gf i )) > τ AND Sim B (cs(s), cs( -→ Gf i )) > max then 8: max = Sim B (cs(s), cs( -→ Gf i )) 9:
-→ Gf tmp = -→ Gf i 10:

end if -

→ Gf tmp = - → G s(s) 15: -→ Gf = -→ Gf ∪ -→ Gf tmp 16: else 17: -→ Gf = appendGf ( -→ Gs(s), -→ Gf tmp , -→ Gf ) 18: end if 19: CSM.put(key, -→ Gf tmp ) 20: return ( -→ Gf , CSM, -→ Gf tmp )

Forward fragments as allocation units

In this section we prove that the set of forward graph fragments -→ Gf partitions an RDF graph in a correct set of partitions. This is depicted in Theorem 3.2.

Theorem 3.2 The set

-→ Gf = { -→ Gf 1 , ..., -→ Gf l } of all forward graph fragments for the graph G is a correct4 partition set of the graph G.

Proof. We will show that the three correctness fragmentation rules mentioned in [ ÖV11] are enforced.

• Completeness: If t ∈ G ⇒ ∃ -→ Gs i such that t ∈ -→ Gs i , -→ Gs i ∈ -→ Gf i , and -→ Gf i ∈ - → C . By contradiction, if ∀ -→ Gs i , t / ∈ -→
Gs i then the triple's t subject f s (t) does not equal any of the subjects of the forward stars -→ Gs. Since the forward stars -→ Gs are built by grouping first all triples of the graph G by subject, the triple t's subject is not equal to the subject of any triple in G, therefore t / ∈ G.

• Reconstruction: It is possible to define an operator

∇ such that G = ∇ -→ Gf i , ∀ -→ Gf i ∈ - → C .
For the forward fragment classes, the operator ∇ equals the union operator ∪. In other words,

⋃ l i=1 -→ Gf i = G. By contradiction, if ∃t ∈ -→ Gf i such that t /
∈ G, then the subject of any triple in -→ Gf i does not belong to G. This is impossible because by definition, the forward stars are created grouping all triples from the initial graph G by subject. This would be possible only if t / ∈ -→ Gf i and therefore the set of forward entities would not be complete.

• Disjointness:

∀ i̸ =j ( -→ Gf i ∩ -→ Gf j = ∅). By contradiction, if ∃( -→ Gf i ∩ -→ Gf j = {t}) then t ∈ -→ Gs i and t ∈ -→ Gs j ( -→ E i ∈ -→ Gf i , -→ Gs j ∈ -→ Gf j )
, which is impossible unless the same triple had two different subjects.

Grouping the graph by attributes

The organization of an RDF graph in forward graph fragments identifies the set of instances for implicit entities in the graph using characteristic sets. The fragments created with this strategy resemble the tuple groups generated when horizontally partitioning a relational database. As in the relational model, fragmenting a graph in forward fragments is useful for a certain type of queries. For example, if the workload is composed of star-shaped queries, this type of organization is ideal. However, this single fragmentation strategy does not optimize all query spectra. Partitioning an entity by its attributes in the relational model, known as vertical partitioning, optimizes other types of queries that involve a small number of attributes. Several RDF processing systems use a similar strategy, where a fragment is created to each property (e.g., SW-Store [AMMH09], S2RDF [START_REF] Schätzle | S2RDF: RDF querying with SPARQL on Spark[END_REF]). In relational-based systems, the strategy stores triples in different tables per property. This strategy is efficient when solving queries with a few attributes but suffers overheads when several predicates are joined in one query.

In this section we describe the creation of fragments by regrouping the nodes by their properties. Instead of strictly regrouping each property in a different fragment, we use the notion of characteristic sets to group the attributes affecting the same node. We name these structures backward graph fragments, whose construction is very similar to the fragments described in the previous section. We start defining a backward graph star which groups a node and its incoming edges. This structure allows to identify properties that affect the same node to later cluster them. It is formally defined in Definition 3.

← - Gs ⊆ G such that ← - Gs = {t|∀ i̸ =j (f o (t i ) = f o (t j ))}.
We name the object o the head of the backward star.

f o (t 1 ) = f o (t 2 ) which is impossible if ← - G s i ̸ = ← - G s j .
The backward graphs stars are grouped using characteristic sets. We extend in Definition 3.4 the definition given in Chapter 2 to consider the characteristic set of objects. A backward graph fragment is therefore a group of backward graph stars whose heads (objects) share a similar characteristic set. This structure allows to gather the predicates that point to the same type of objects, creating broader groups than the ones obtained when splitting the dataset by predicates. We can retrieve the characteristic set of a backward fragment with the function cs( ← -Gf ). The backward graph fragments are illustrated in Figure 3.3a. Similarly, they could be physically stored in tables (Figure 3.3b) or adjacency lists (Figure 3.3c). They are formally defined in Definition 3.5. ← -Gs with similar characteristic sets according to a threshold τ . Formally,

← - Gf = { ← - Gs(o)|∀← - Gs(s i )̸ = ← - Gs(s j ) Sim(cs(o i ), cs(o j })) ≥ τ }.
The similarity functions used to group characteristic sets are the same functions described in Section 3.3.1.1, although structural functions are mainly used to form backward fragments.

Backward fragmentation algorithm

The generation of backward graph fragments is described in Algorithm 4. The inputs of the algorithm are the same as for Alg. 1 except that the input file must be in OPS (object, predicate, subject) order. This input file facilitates the creation of backward stars and fragments. The algorithm starts initializing an empty graph star, a variable storing the object of the first triple and an empty map structure mapping characteristic sets to graph fragments. Then it makes a single pass through the triples of the dataset (Step 2). The loop creates a graph star set until it detects a change in the object of the current triple (Step 3). At this point, it generates a key combining the set of ID's of the predicates that co-occur in a graph star with a hashing function (Step 6). If the key is already in the map of characteristic sets, it assigns the star directly to the fragment and appends it to the set of graph fragments with the function appendGf (Step 9). If there is no key in the map with the star's key then it uses the function updateGf which applies the similarity function to decide to which fragment the star should be appended (Step 11). The function appendGf is not detailed in an algorithm, since the steps are the same as in 2 but for backward fragments. The function updateGb is described in Algorithm 3. The algorithm returns the set of graph fragments, the map of characteristic sets and graph fragments, and a map of objects with their corresponding backward fragment (Step 11).

Algorithm 4 Generation of backward graph fragments

Input: RDF file D of {t 1 , ..., t n } triples t = ⟨s, p, o⟩ in OP S order, threshold similarity τ Output: Set of fragments

← - Gf = { ← - Gf 1 , ..., ← - Gf p },characteristic set map CSM ⟨key, ← - Gf k ⟩, object map OM ⟨o, ← - Gf ⟩ 1: Initialize ← - Gs = ∅, o i-1 = f o (t 1 ), CSM ⟨key, ← - Gf k ⟩ = ∅ 2: for each t i in D do 3: if s i-1 = f s (t i ) then 4: ← - Gs(o i-1 ) = ← - Gs(o i-1 ) ∪ {t i } 5:
else 6: key = Hash(cs(o i-1 ))

7:

if key ∈ CSM.keySet() then 8:

← -Gf k = CSM.get(key)

9: ← - Gf = appendGf ( ← - Gs(o i-1 ), ← - Gf k , ← - Gf ) 10: else 11: ( ← - Gf , M ap, ← - Gf k ) = updateGb( ← - Gs(o i-1 ), ← - Gf , τ, CSM ) 12: end if 13: ← - Gs(o i-1 ) = {t i } 14: OM.put(o i-1 , ← - Gf k ) 15:
end if 16:

o i-1 = f o (t i ) 17: end for 18: return ← - Gf , CSM , OM
The updateGf function is described in Alg. 5. The algorithm makes a single pass through the already assigned graph fragments (Step 2). Based on a similarity measure in the characteristic set, it searches for the most similar already assigned graph fragment(Steps 3 -5). If after going through all the assigned fragments it still does not find any match, it creates a new graph fragment (Steps 8 -10). It returns the updated set of backward fragments, the updated characteristic set map and the graph fragment assigned to the input graph star (Step 15).

The set of backward graph fragments forms also a partitioning set of the RDF graph as shown in Theorem 3.4.

Theorem 3.4 The set ← - Gf = { ← - Gf 1 , ..., ← -
Gf m } of all backward segments for the graph G is a correct partition set of the graph G.

The proof follows the same structure as the one for the forward graph fragments.

We have shown that the sets of forward and backward fragments ( -→ Gf , ← -Gf ) induce correct partitions (i.e. complete, disjoint and rebuildable) of the original RDF dataset G. The elements on each set correspond to fragments of the RDF graph G that become distribution units during the allocation step. The allocation problem is described and formalized in Section 3.5. in the next section we compare the creation of fragments with other techniques commonly used to persist RDF graphs.

- Gf k ⟩ Output: ( ← - Gf , CSM ⟨key, ← - Gf tmp ⟩, ← - Gf tmp ) 1: Initialize max = 0, ← - Gf tmp = ∅, key = Hash(cs(o i )) 2: for each ← - Gf i in ← - Gf do 3: if Sim B (cs(o), cs( ← - Gf i )) > τ AND Sim B (cs(o), cs( ← - Gf i )) > max then 4: max = Sim B (cs(o), cs( ← - Gf i )) 5: ← - Gf tmp = ← - Gf i 6: end if 7: end for 8: if ← - Gf tmp = ∅ then 9: ← - Gf tmp = ← - G s(o) 10: ← - Gf = ← - Gf ∪ ← - Gf tmp 11: else 12: ← - Gf = appendGf ( ← - Gs(o), ← - Gf tmp , ← - Gf ) 13: end if 14: CSM.put(key, ← - Gf tmp ) 15: return ( ← - Gf , CSM, ← - Gf tmp )

From logical fragments to physical structures

The organization of RDF data in graph fragments allows to detect implicit logical entities that are used as distribution units in RDFDS. Furthermore, using these logical fragments as physical structures could significantly improve the performance of centralized and distributed systems. The work of Pham et al. in [START_REF] Pham | Deriving an emergent relational schema from RDF data[END_REF] showed that explicitly storing the data using a relational schema automatically discovered boosts the performance of Virtuoso [EM09], a relational-based triple store. Organizing the data into forward and backward graph fragments, regardless of the structure used to persist the data (e.g., tables, indexes or adjacency lists), avoids to scan the whole dataset many times with for a single query as it is done by most of the systems storing the entire RDF graph in a single data structure. This intuition is illustrated in Figure 3.4 comparing the query execution in systems with distinct storage structures. Let us start with the execution in systems storing the data in a single triple table as shown in Figure 3.4a. In these systems, the execution is in general divided by triple patterns (TPs). The query in this figure is divided in four triple patterns. The matches for each TP are found by scanning the entire table or index storing the whole dataset. Then, the matches for each TP are joined to find the final results. Some systems have optimized this strategy by indexing the data in different orders (e.g., SPO, OPS, PSO) to join the results of triple patterns using more efficient algorithms (e.g merge-join in RDF-3X [START_REF] Neumann | RDF-3X: a risc-style engine for RDF[END_REF]). Other strategies, like the property table allow to reduce the number of joins solving star-shaped patterns with a single scan. For example, the yellow pattern shown in Fig 3 .4b composed of two single patterns is solved with a single scan of the property table.

Still, the property table must be entirely scanned to solve every star-shaped pattern which may cause overheads.

Partitioning the RDF graph in physical fragments can avoid to scan the whole dataset with each query pattern. To do this, the relevant partitions must be identified based on the information available in the query. Forward and backward fragments allow to identify the relevant partitions based on the query's predicates, which are known in most SPARQL queries. The process to solve a query in a system persisting the data with forward graph fragments is illustrated in Figure 3.4c. We assume that the data are stored in tables, but the storage structure could have been any other (e.g., indexes, adjacency lists). If the data are organized as forward fragments, the query should be grouped in forward star-shaped patterns too (denoted as -→ SQ) so that each pattern group has a candidate set of forward fragments. The candidate set contains forward fragments in which a match to the query is likely to be found. To obtain them one could apply simple rules, for example that the characteristic set of the star-shaped pattern must be contained in the characteristic sets of any of the candidate fragments. More formally, the set of candidate fragments denoted as

S p1 p2 p6 S p1 p2 p6 S p8 p9 S p8 p9 S p5 p6 S p5 p6 p7 p8 ▷◁ ▷◁ Candaidates (c) -→ Gf O p1 p2 p6 O p1 p2 p6 O p8 p9 O p8 p9 S p5 p6 S p5 p6 p7 p8 ▷◁ ▷◁ Filter Filter (d) -→ Gf , ← - Gf
C( -→ SQ) is defined as C( -→ SQ) = { -→ Gf k |cs( -→ SQ) ⊆ cs( -→ Gf k )}.
Ideally, the total number of triples read from the candidate set is much smaller than the total number of triples of the dataset. Since not all the data is read at the same time, the system's throughput is also improved. In addition, the fragments in the candidate set can be scanned in parallel, reducing the queries' response time. The order in which the triple patterns are executed plays also a very important role in the query performance. Storing the data in physical graph fragments allows to easily collect statistics about them to estimate the most efficient join order. Fragmented data also allows more efficient filtering from one pattern to another, as we will see below, using forward and backward graph fragments simultaneously allows to prune invalid scans from one triple pattern to another.

Combining forward and backward fragments The integration of horizontal and vertical partitions in the relational model has been explored by many researchers in the past. For example, the advisors of a database physical design described in [START_REF] Agrawal | Integrating vertical and horizontal partitioning into automated physical database design[END_REF] or the Fractured Mirrors [START_REF] Ramamurthy | A case for fractured mirrors[END_REF]. Meanwhile, many massive processing systems propose replication strategies not only to recover and support fault tolerance but to improve the response time of queries. The Hadoop distributed framework for example, stores the data with a default replication factor of 3. We consider an approach similar to the Fractured Mirrors [START_REF] Ramamurthy | A case for fractured mirrors[END_REF] in which a system stores two copies of the data. One copy organizes the data as forward graph fragments and another as backward graph fragments. This configuration is useful especially when the workload is unknown in the initial partitioning stage. Also, as it is shown in Figure 3.4d, considering both fragments allows to filter the data scanned at each candidate fragment considering the matches from the previous query pattern. For instance, let us consider that the execution starts finding the matches for the yellow star pattern in the Figure 3.4d. The matches found in this pattern could be used as filters to scan the rows (which are the objects) of the candidate backward fragments of the green and red patterns.

Allocation problem

The allocation of fragments is a mandatory stride in distributed systems. The problem consists in finding the optimal distribution of data fragments to the sites of a computer network. The problem was initially studied in the context of file distribution but later deepen in relational databases where it was proven to be NP-Complete [START_REF] Kapali | Placement of records in a file and file allocation in a computer[END_REF][START_REF] Saccà | Database partitioning in a cluster of processors[END_REF][START_REF] Lam | An approximation algorithm for a file-allocation problem in a hierarchical distributed system[END_REF]. In the relational model, the estimation of how optimal a distribution strategy is depends on various criteria which are evaluated on the basis of cost models. These models estimate the storage and maintenance costs along with performance metrics like the system's throughput and response time. Since the complexity of the problem does not allow to calculate exact solutions in a reasonable time, a number of different heuristics used in operational research (e.g., knapsack problem [START_REF] Ceri | Optimal file allocation in a computer network: a solution method based on the knapsack problem[END_REF]) have been applied in RDBMS. These techniques are barely used in modern distributed architectures like Hadoop, that despite being based on other execution paradigms, face the same problem of data distribution. These systems split the data by chunks and use hashing functions to distribute them among the sites of the cluster since the data lacks a defined schema.

Similarly, most of RDFDS opt for very simple distribution solutions. These solutions do not guarantee that the triples closely related to each other would be in the same site. A query that merges intermediate results which are not found in the same machine are very inefficient mainly due to the high transfer costs. As in distributed relational databases, we consider the network costs as the processing bottleneck at query runtime. Therefore, the strategies to improve the system's performance should seek to maximize data locality. This can be achieved through indexing, partitioning and replication techniques.

As it was shown in the previous section, using graph fragments as physical storage structures reduces the disk costs and enable parallelism in centralized and distributed systems. In this section, we consider the use of forward and backward graph fragments to reduce the network cost in RDFDS. We define the allocation problem and its constraints. We seek to allocate triples as close as possible to its neighbors to prune the intermediate results generated for a query locally at each site. We assume that the workload is not available, as it is the case when analyzing RDF data. We build our distribution model based on innate data connectivity.

Problem definition

Inputs Let V = {V 1 , ..., V p } be the set of forward, backward or both graph fragments

V = { --→ Gf 1 , ..., -→ Gf l } ∪ { ← -- Gf 1 ... ← -- Gf m } with cardinality p = l + m.
The sites are represented by the set S = {S 1 , ..., S q }. We assume that the size of a single graph fragment is always inferior to the maximum capacity of a site |S i | ≥ |V j |. The available space in a site S k is expressed as |S k | and the average size of a triple is expressed as |t|. An imbalance factor denoted by ϵ is used to avoid high imbalance in the number of triples between partitions.

Problem Let us consider the functions: W V : V → N + returning the number of triples per graph fragment and W F : V × V → N returning the number of triples shared by two graph fragments. The procedure to calculate the values of both functions is described in Section 3.5.1.1. The allocation function x iS k : V → {0, 1} is defined as:

x iS k = { 1 if V i is stored in site S j 0 otherwise And ⊕ : x iS k → {0, 1} is the X-OR operator.
The partitioning problem consists then in finding an allocation function X iS k : V → S that minimizes the total number of shared triples by two sites. Given a set of fragments V , sites S and an imbalance factor ϵ:

minimize ∑ i,j∈{1,...,p} k∈{1,...,q} ( (x iS k ⊕ x jS k ) • W F (V i , V j ) ) (3.1)
Subject to:

(i) Imbalance constraint:

∀ k∈{1..q} ⃓ ⃓ ⃓ ⃓ p ∑ i=1 ( x iS k • W V (V i ) ) - p ∑ j=1 ( x jS k • W V (V j ) ) ⃓ ⃓ ⃓ ⃓ i̸ =j ≤ ϵ (3.2)
(ii) Replication factor:

∀ i∈{1..p} ( q ∑ k=1 x iS k = R ) (3.3)
(iii) Available space in sites:

∀ k∈{1,...,q} p ∑ i=1 x iS k • W V (V i ) |t| ≤ |S k | (3.4)
The objective function seeks to minimize at each site the number of triples whose nodes (subject or object) belong to graph fragments located in distinct sites. The constraints are expressed in Equations 3.2, 3.3 and 3.4. They refer to the maximum imbalance allowed per site, to the number of copies of each fragment in the system (which by default is set to R = 1) and to the site's size constraint respectively.

Estimation of weights

To find the weights W V and W F it is necessary to make a second pass over the SPO (or OPS) RDF file to look up the information. The algorithm finding the weights between forward graph fragments is described in Algorithm 6. The algorithm takes as input an RDF file in SPO order, the map of characteristic sets and the map of subjects defined in Alg. 1. It iterates through the file and gets to which forward fragment the subject of the current triple belongs (Step 3). Then, it increments the map of vertex weights (Steps 4-9). Finally, it checks whether the object of the current triple is the subject of a triple in another fragment ( Step 10). If so, it increments the counter and updates the map (Steps 12-17).

The procedure to estimate the weights of backward graph fragments is quite similar to the previous one, using the respective CSM and OM maps defined in Alg. 4. If the system considers both sets of fragments simultaneously, the weights are calculated according to the cases shown on Table 3.1.

Finding exact solutions is, as it is the case in relational-based systems, computationally unfeasible and therefore heuristics producing sub-optimal results are the most convenient strategies. In the following section we present a heuristic mapping the fragments to the nodes of a graph.

Algorithm 6 Generation of weights for forward fragments

Input: RDF file D of {t 1 , ..., t n } triples t = ⟨s, p, o⟩ in SP O order, characteristic set map CSM ⟨key, -→ Gf k ⟩, subject map SM ⟨s, -→ Gf ⟩ Output: W V : ⟨( -→ Gf src , -→ Gf dest ), count⟩ W F : ⟨ -→ Gf , count(t)⟩, 1: Initialize src =null, dest =null, W V = ∅, W F = ∅, count = 0 2: for each ⟨s, p, o⟩ in D do 3: -→ Gf src = SM.get(s) 4: if -→ Gf src ∈ W V .keySet() then 5: count = W V .get( ← - Gf k ) 6: W V .put( -→ Gf src , count + 1) 7: else 8: W V .put( -→ Gf src , 1) 9:
end if 10:

if o ∈ SM.keySet() then 11:

-→ Gf dest = SM.get(o)

12: if ( -→ Gf src , -→ Gf dest ) ∈ W F .keySet() then 13: count = W F .get(( -→ Gf src , -→ Gf dest ))
14:

W F .put(( -→ Gf src , -→ Gf dest ), count + 1)
15:

else 16:

W F .put(( -→ Gf src , -→ Gf dest ), 1) 17: end if 18:
end if 19: end for 20: return W V , W F

Graph partitioning heuristic

The set of graph fragments is mapped to an undirected weighted graph, transforming the allocation problem into a graph partitioning problem. The graph partitioning problem has been proved to be a very complex and computationally expensive problem. However, many efficient heuristics have been developed as detailed in Chapter 2 (e.g., METIS [START_REF] Karypis | A fast and high quality multilevel scheme for partitioning irregular graphs[END_REF]).

Let us map the set of graph fragments Gf into a directed weighted graph represented by the quadruple G = (V, E, W V , W E ). V corresponds to the set of nodes which are the sets of forward and backward graph fragments. The node's weights are represented in the set W V , each element w(V i ) corresponds to the number of triples on each fragment. E represents the set of edges and W E the set of weights (w(E ij ) between the nodes i and j). The weights are calculated following the strategies presented in the previous section. An example graph is shown in Figure

( -→ Gf i , -→ Gf j ) object(t i ) = subject(t j ) ( ← - Gf i , ←- Gf j ) subject(t i ) = subject(t j ) ( ← - Gf i , ←- Gf j ) object(t i ) = subject(t j ) ( -→ Gf i , ←- Gf j ) subject(t i ) = subject(t j ) ( -→ Gf i , ←- Gf j ) object(t i ) = subject(t j )
a The weight of an edge W (edge) is the number of triples ti such that: ti ∈ Gi, tj ∈ Gj, and ti ∧ tj fulfill the condition in this column accordingly. 3.5. In this case the graph is split in two partitions, the goal is to minimize the cuts to implicitly diminish the data that would be transferred if the fragments are joined. Given a graph G and a given a number p ∈ N + indicating the number of partitions, the graph partitioning problem asks for blocks of nodes

--→ Gf 1 10 --→ Gf 2 2 --→ Gf 3 2 --→ Gf 4 2 ← -- Gf 3 2 ← -- Gf 2 3 ← -- Gf 4 2 ← -- Gf 1 1 ← -- Gf 5 2 ← -- Gf 6 2 ← -- Gf 7 2 ← -- Gf 8 2 2
V 1 , ..., V p such that V 1 ∪ ... ∪ V p = V and V i ∩ V j ∀i ̸ = j.
As it was defined before, a balance parameter ϵ is used to regulate the size between partitions.

Objective function

We seek a partition that minimizes the total cuts.

minimize ∑ i<j w(E ij ) (3.5)
Subject to:

∀ k̸ =j ( V i ∈ V k ∧ V j ∈ V l ) (3.6) |w(E i ) -w(E j )| ∀i̸ =j ≤ ϵ (3.7)
The first constraint refers to the fact that a graph fragment should be assigned to only one block of nodes (i.e. partition). Replication is therefore not deemed in the graph heuristic approach.

The second constraint refers to the imbalance factor between partitions. The constraint seeking not to exceed the size of a given partition defined in Eq. 3.4 is not considered by most of the graph partitioning heuristics. Accordingly, we do not explicitly declare it here. If the size of a partition exceeds the available space in a site, re-partitioning strategies should be considered. These strategies are described in Section 3.7. The following example gives an overview of our approach. Let us consider the RDF graph G illustrated in Figure 3.6. This graph is a miniature version of the graph presented in the previous chapter in Figure 2.10. We start identifying forward graph fragments. Next, we show how physically storing the data with this structure contributes at query runtime. Then, we build the backward graph fragments for this graph. Finally, considering forward and backward fragments, we show an example of our allocation heuristic.

RDF partitioning example

Forward graph fragments Let us start gathering the triples in forward graph fragments. As it was described in Section 3.3.1 we group first the triples by its subjects. We obtain 8 groups of triples (Airplane1, Airplane2, B747, A340, Airbus, Boeing, France and USA). We name each of these groups a forward graph star -→ Gs representing instances of higher-level entities (e.g., an Airplane, a Manufacturer, an Airplane Model). We observe that two instances of the same high-level entity share the same (or almost the same) set of predicates. In general, the forward graph fragments can be uniquely identified by the set of its emitting edges (i.e. characteristic set). In the example, the forward stars Airplane1 and Airplane2 share the same predicates (has_model, has_length, manufacturer, nb_motors and type). Consequently Airplane1 and Airplane2 belong to the same group that we name a forward graph fragment -→ Gf i of G. There are in total 4

-→ Gf in our example, two of them are illustrated in Figure 3.7b showing forward graph fragments physically stored in a tabular form.

The query Q 1 :

SELECT ?a ?m ?l WHERE { ?a :type :Airliner . ?a :has_length ?l . ?a :has_model ?m . FILTER (?l > 65.0) } could be efficiently solved by looking for the relevant graph fragment whose characteristic set contains the predicates type, has_length and has_model avoiding a full scan of the data.

Still, an organization of the data in forward graph fragments is non-optimal when solving queries with a very reduced number of predicates like for instance the query Q 2 :

SELECT AVG(?y) WHERE { ?x :nb_motors ?y . }

To solve this query, all the triples of the forward fragment Airplane must be read, even the triples with predicates other than has_motors. When exploring the graph for matches, 10 triples in the Airplane forward graph fragment must be scanned when only 2 triples are relevant.

Backward graph fragments

The previous problem is quite similar to the one that motivated vertical partitions in relational databases. Partitioning a table by attributes can be more efficient for some queries, where they involve few attributes. In our case, we create groups of triples by attributes which are named backward graph fragments. To build them, we gather first the triples by its incoming edges. For the graph of Figure 3.6 we obtain 13 groups "5", "4", "75.4", "70.1", Boeing, Airbus, France, USA, "Toulouse", "Chicago", A340, B747 and Airliner. We name these groups backward graph stars ← -Gs. Similarly to what was done for the forward fragment, we use the characteristic set to identify the groups of attributes. We name them backward graph fragments ← -Gf .

For the example graph of Figure 3.6 we obtain 8 backward graph fragments: the group of city names with the has_city predicate (2 triples), the group of manufacturers (2 triples), lengths (2 triples), locations (2 triples), models (2 triples) and types (2 triples). There is a group gathering the triples having only the nb_version predicate (1 triple), and another group gathering the triples with the predicates nb_version and nb_motors (3 triples). The predicates could stored shown in Figure 3.8c. We do not go into more details about the query execution modeling using the graph structures presented here and the selection of an optimal execution plan, both topics are out of the scope of this thesis.

← - Gf ⋆ ▷◁ ▷◁ ▷◁ ← - Gf ⋆ ▷◁ ← - Gf ⋆ ← - Gf ⋆ ← - Gf ⋆ ⋆ :Candidate set (b) ← -
-→ Gf ⋆ ▷◁ ← - Gf ⋆ ▷◁ ← - Gf ⋆ ⋆ :Candidate set (c) -→ Gf and ← - Gf
Graph fragments allocation As it was seen in Section 3.5, forward and backward graph fragments can be used as distribution units to allocate triples in a RDFDS. We propose to use graph partitioning heuristics to find solutions to the allocation problem in a reasonable time.

The graph shown in Figure 3.9a is the weighted graph of forward graph fragments of Figure 3.6. The graph has four nodes, one for each fragment, whose weight is the number of triples stored on each of them. An edge is drawn between two nodes if there is a triple on the source fragment whose object is the subject of the other fragment. The weights of each edge are the number of triples shared between both fragments. The edge's weights represent the number of triples that should be transferred between two fragments when they are joined. Let us consider for example the edge's weights between the forward graph fragments --→ Gf 1 and --→ Gf 2 . The weight in this case is 2 since the subjects :Airplane1 and :Airplane2 stored in --→ Gf 1 are connected to the subjects :A340 and :B747 that are the subjects of triples stored in --→ Gf 2 .

Figure 3.9b illustrates the weighted graph of backward graph fragments for the graph of Figure 3.6. The node's weights are the number of triples on each fragment and the edges are also drawn based on the data shared by triples in two distinct fragments. The cases are detailed in Table 3.1. The detail of the data on each fragment is found in the Appendix A. We do not show the weighted graph combining forward and backward graph fragments for readability. Finally, the allocations is decided using a graph partitioning heuristic like METIS [START_REF] Karypis | A fast and high quality multilevel scheme for partitioning irregular graphs[END_REF]. If the chosen graph partitioning heuristic works only for non directed graphs, the conversion is very simple.

--→ Gf 1 10 --→ Gf 2 4 --→ Gf 3 2 --→ Gf 4 2 has model 2 manufacturer 2 has seat 2 (a) Weighted graph of -→ Gf ← - Gb 1 2 ← - Gb 2 2 ← - Gb 3 2 ← - Gb 4 2 ← - Gb 5 3 ← - Gb 6 2 ← - Gb 7 4 ← - Gb 8 1 2 2 2 1 2 2 2 2 2 2 2 2 2 1 1 1 1 1 (b) Weighted graph of ← - Gf Figure 3
.9: Extract of weighted graphs of fragments for graph G

Dealing with large fragments

When the size of a forward or backward graph fragment exceeds a predifined threshold, the fragment needs to be repartitioned. The threshold can be set to the space available in a single site of a distributed system because if the size of a graph fragment surpasses the available space in a site, we will not be able to place it anywhere. To partition within a fragment, we apply a function that sub-partitions it keeping the data belonging to the same graph star together.

In other words, the function must hold triples with the same subject or object in the same forward or backward graph fragment respectively. This allows to keep the previously found logical structure intact so that the allocation methods based on the data connectivity can still be applied. The re-partitioning function is either obtained by hashing the triple's subject or object, or by using a range strategy on the predicates as seen below.

Let us start defining the fragments that need to be re-fragmented. Given a set of sites {s 1 , ..., s s } and graph fragments Gf = {Gf 1 , ..., Gf m }. If the site's capacity and a graph fragment's size are defined as |s i | and |Gf i | respectively. A graph fragment needs to be re-partitioned if |Gf i | > |s i |. The number of sub-partitions is obtained as:

n = ⌈ |Gf i | |s i | ⌉
Let us consider that the size of a graph fragment Gf i is bigger than the available space for a site. The hashing strategy applies a hashing function on every graph star such that:

∀Gs(h) ∈ Gf i : H(Gs(h)) mod (n)
where n is the number of sub-partitions. The advantage of this strategy is the creation of uniform partitions with similar sizes.

The next sub-partition strategy, named range re-partitioning, maps the forward or backward fragments to a partition according to the values of a predicate(s). If a fragment involving k predicates (p 1 , .., p k ) is too large, we propose to repartition it. To do so, we first consider one of its numerical predicates (having the following form: p n θvalue n , where value n is an integer or a float) and then re-split the initial fragment into two new fragments based on the domain of value n . We iterate this procedure till having fragments with reasonable size. The information related to the domain of different predicates could be available in the triple store statistic module [ZMG + 20]. In our case, we compute this information from the KG.

The process is iterative. For example, if after computing the re-partition operations on a fragment its size is still too large, the user can decide to use either of the previous strategies again.

Conclusion

In the relational databases world, data partitioning has been identified for a long time as a key optimization and manageability technique. In this context, data partitioning, characterized by its simplicity, is independent of the storage approach of the data. Consequently, a user does not have to deal with the physical storage layer of the system hosting the data, even though the partitions impact seriously the physical layer. These findings represent a wisdom of traditional relational data partitioning. In this chapter, we claim to reproduce this wisdom by tackling the partitioning problem of RDF data. Unlike traditional partitioning techniques, RDF techniques are dependent on the partitioning strategy and are difficult to generalize for different systems.

We draw on the philosophy adopted by the relational model to address partitioning within distributed RDF systems. Precisely, we introduced a logical layer to the merely physical distribution process of triples to a set of sites. We formalize and detail the algorithms used to create the logical entities that we named graph fragments (Gf ). Our entities extend the notion of partitioning by instances and by attributes in the relational model and offer great balance between conceptual and intuitive simplicity, in addition to its logic expressiveness. We formalized the allocation problem and presented a graph-based heuristic to minimize communication costs. Summary In the previous chapter we defined a logical layer to partition RDF datasets. This layer allows partitioning RDF data independently of its physical storage implementation while preserving its logical graph structure. In this chapter, we present the partitioning framework RDFPartSuite. This framework is built upon the logical structures that we defined in the previous chapter. It is composed of three main modules: fragmenter, allocator and dispatcher. These modules provide functionalities to assist managers (triple stores' administrators) to partition Knowledge Graphs based on their requirements. We detail the incorporation of this framework to a centralized (RDF QDAG) and a distributed (gStoreD) triple store. We conducted several experiments that demonstrate the virtues and the costs of incorporating our structures while loading and processing RDF data. Finally, we present a set of assistance tools proposed by our framework. These tools relieve managers from the partitioning design tasks with a declarative partitioning language and a partitioning advisor. The following chapter is organized as follows. We start in Section 4.2 giving an overview of the centralized triple store where we incorporated our framework. Then, in Section 4.3 we compare the loading costs of our framework with respect to other fragmentation strategies from the state of the art. Next, in Section 4.4 we evaluate our fragmentation strategies in terms of data coverage and query performance. The fragmentation process is evaluated in a centralized and also in a distributed triple store to which we incorporated our framework. In Section 4.5, we evaluate the allocation strategies of graph fragments. Then, in Section 4.6 we detail the assistance tools provided by RDFPartSuite. These tools are a partitioning language (Section 4.6), and an advisor (Section 4.7) . Finally Section 4.8 concludes this chapter.

Introduction

In the previous chapter we promoted a logical layer for RDF data partitioning. We defined a set of structures that allow partitioning RDF data regardless of how it is stored. These structures preserve the logical graph nature of RDF data and are used as fragmentation units. The logical fragments are placed to the sites of a distributed system according to data-driven algorithms that we have also detailed. In this chapter we introduce a framework named RDFPartSuite. The framework provides generic functionalities build upon the logical structures defined in the previous chapter. It can be adapted according to the manager's specifications (creator's requirements, triple store, available infrastructure, etc.). RDFPartSuite provides a standard way to build and deploy RDF partitioning schemas in a universal and reusable environment. The framework is composed of three main modules:

(i) Fragmenter: this component is in charge of partitioning the triples using their logical representation as graph fragments (i.e.

-→ Gf or ← -Gf ). The fragments can be built using structural or semantic rules as described in Section 3.3.1.1.

(ii) Allocator: the allocator builds a distribution schema for the fragments built by the fragmenter component. This schema is built using the data-driven strategies detailed in Section 3.5.

(iii) Dispatcher: this component sends the fragments to the sites of a distributed system following the allocation schema produced the allocator. The dispatcher is also in charge of loading the data to the target triple store.

In addition to these modules, our framework integrates a set of assistance tools for the administrators (managers) of triple stores. These tools include a declarative partitioning language, to fragment, allocate, and dispatch a Knowledge Graph to a target triple store. And, for non-expert users, it provides a partitioning wizard to help them build a partitioning schema for their data. This chapter is dedicated to this framework. We start describing how to incorporate our framework to a centralized triple store (RDF QDAG [KMG + 20]). This system uses data partitioning and graph exploration techniques to accelerate the execution of SPARQL queries in a centralized environment. We have also shown how to incorporate our framework to a distributed triple store (gStoreD [Z ÖC + 14]). We carried out a significant number of experiments that showed the feasibility of our partitioning strategies, its effectiveness and its limits. Finally, we presented RDFPartSuite's assistance tools. The sections of this chapter are organized as follows. We start in Section 4.2 detailing the incorporation of our framework to RDF QDAG. We describe its main modules along with their storage and processing strategies. This system uses the logical fragments (i.e.

-→ Gf or ← -Gf ) as physical storage units. This allows us to compare the performance gain of our model versus alternative partitioning strategies applied in other systems of the state-of-the-art. We detail our implementation choices and examine carefully the pre-processing costs (Section 4.3). In Section 4.4, we evaluated our fragmentation strategies in terms of query performance. We performed these experiments in RDF QDAG, a centralized relational-based system, and a graph-based distributed triple store (gStore). Then, in Section 4.5 we largely discussed the allocation strategies supported by our system and the results of our experimental comparisons. Finally, in Sections 4.6 and 4.7 we detail our assistance tools which are the declarative partitioning language and the partitioning advisor respectively.

RDF QDAG

Modern RDF processing systems can be distinguished in two groups as it was studied in Section 2. 3 figurations. The systems under this group are more easily scalable as they can use optimization strategies such as indexes and partitions available for relational databases. Unfortunately, the performance in these systems degrades rapidly, specially when dealing with complex SPARQL queries. The relational model is not suitable for handling RDF data inherently represented as a graph. The second group comprises RDF processing systems maintaining the graph structure of RDF data. These systems store the triples in data structures specifically designed to store graphs (cf. Section 2.2.2). The major issue confronted by these approaches is scalability to large RDF graphs [START_REF] Abdelaziz | A survey and experimental comparison of distributed SPARQL engines for very large RDF data[END_REF][START_REF] Özsu | A survey of RDF data management systems[END_REF]. They fail to efficiently manage the use of main memory and are not scalable in infrastructures with limited resources. RDF QDAG [KMG + 20] combines the virtues of data partitioning in relational-based systems with an execution model based on the exploration of the RDF graph. The system supports Basic Graph Pattern (BGP) SPARQL queries as well as wildcards, aggregation and sorting operators. The data in RDF QDAG are physically partitioned in Forward and Backward graph fragments. It is able to prune irrelevant graph fragments using the predicate's bounded values in the query. This feature allows to explore only the fragments in which a match is likely to be found. As mentioned before, the query execution in this system is based on graph exploration. To avoid memory overflows, the execution engine of RDF QDAG is based on the Volcano parallel query evaluation system [START_REF] Graefe | Volcano -an extensible and parallel query evaluation system[END_REF]. In what follows we give an overview of RDF QDAG describing its general architecture, storage, optimization and execution layers.

System architecture

The systems is composed of three main modules: Data Loader, Query Optimizer and Executor. The architecture is illustrated in Figure 4.1. Below we describe each of the system's components.

Data loader

This module prepares, indexes and partitions the raw RDF data received as input. It is composed of two main components: pre-processing and storage. The first one transforms the RDF data (stored in N-Triples, N3 or Turtle files) encoding all the strings and arranging the encoded data in forward and backward graph fragments. The string transformation takes place in the Encoder unit. The result of this stage is given as input to the Fragmenter component that splits the data in forward and backward graph fragments using Algorithms 1 and 4. The Data refiner adds to each triple on each fragment information related to its direct neighbors as it will be detailed later in Section 4.2.2. The pre-processing module is entirely coded in Java. The storage component, 4.2. RDF QDAG coded in C++, takes the encoded refined file from the pre-processing as input and sets up the data in indexes. The result of this step are a set of binary files used by the query optimizer and executor modules.

Query optimizer

This module is responsible for finding the optimal execution plan for a SPARQL query. It is composed of three main sub-modules: parser, plan generator and plan selector. The parser transforms the SPARQL query to a series of structures that are understandable by the plan generator sub-component. The plan generator enumerates a series of "acceptable plans" defined in Section 4.2.3 that are later ranked based on a cost model in the plan selector component. The best plan is selected using heuristics that take simple statistics from the fragmented data to estimate the execution cost of each plan. The optimization strategies applied by this component are described in detail in [ZMG + 20].

Executor

This component receives the chosen execution plan from the optimizer and implements it. The matcher sub-component interrogates the B+Tree index (cf. Section 4.2.2) and gets the encoded results. This component might interrogate the string dictionary (using the dictionary matcher sub-component) during the execution to enhance the index search. However, the dictionary matcher is often called at the end of the query execution decoding the original string values. The data are aggregated and sorted on the respective sub-components when necessary. The result's output (e.g., in console, to a file) is managed by the result writer.

Storage model

As we mentioned previously, the data in RDF QDAG are physically stored as graph fragments. The system stores two copies of the data, one as forward and another as backward graph fragments. This choice will be justified when presenting the execution model. In this section we present how the data are compressed and how the triples are physically represented on disk. Let us start describing the output files from the pre-processing phase. First, the predicates from the input dataset are gathered in a single file with their identifiers in a file named pred_index. An example of this file for the graph data of Figure 2.10 is shown in Figure 4.2a. Then, the identifiers of the forward and backward graph fragments are stored in separate files as shown in Figures 4.2b and 4.2c respectively. Lastly, the triples assigned to each graph fragment are stored in separate files. For each graph fragment (identified by a fragment id fid), the data are separated in three files:

• Dictionary (fid.dic): This file stores a map of the strings with their respective IDs of the triples assigned to the graph fragment. The strings are sorted in lexicographical order and the IDs are integer values. An example of this file is given in Figure 4.2d. The dictionary file is used as input by the Dictionary Builder component to store the data in a compressed string index.

• Schema (fid.schema): This file stores the list of predicates (encoded with the IDs from the pred index file) along with the data type of the triple's object if the schema file corresponds to a forward graph fragment or the subject otherwise. The first line of the file stores the data type of the encoded subjects (in case of a forward fragment) or the encoded object (in case of a backward fragment) stored in the graph fragment. The schema file for the graph fragment in our running example is illustrated in Figure 4.2e. -N ode 1 : it is the encoded subject (or object in a backward graph fragment). It is represented using 8 bytes.

-Gf : it is ID (fid) of the fragment (if any) storing the incoming (or outgoing edges in a backward graph fragment) edges of N ode 1 . If there is any this value equals zero.

-Predicate: this value is the predicate's ID of the triple. It is represented using 4 bytes.

-N ode 2 : it is the encoded object (or subject in a backward graph fragment). It is represented using 8 bytes.

-Gf in : it is the id (fid) of the fragment storing the incoming edges (if any) of N ode 2 . It is represented using 4 bytes.

-Gf out : it is the id (fid) of the fragment storing the outgoing edges (if any) of N ode 2 . It is represented using 4 bytes.

In the example of Figure 4.2f, the first line corresponds to the triple <:Airplane1> <:has_model> <:A340>, encoded as:

40 ⏞⏟⏟⏞ :Airplane1 0 ⏞⏟⏟⏞ ← - Gf 2 ⏞⏟⏟⏞ :has_model 10 ⏞⏟⏟⏞ :A340 6 ⏞⏟⏟⏞ ← - Gf 2 ⏞⏟⏟⏞ -→ Gf
The data file can be very dense and include many redundant information. The compression strategy for this file are shown in the following section.

RDF QDAG

Indicator Predicate

17 bits 1 bit

N ode 1 Gf N ode 2
Gf in Gf out 0-8 bytes 0-4 bytes 0-8 bytes 0-4 bytes 0-4 bytes

Data compression

The files storing the triples and its neighbors described in the previous section gather all the significant information to traverse the data from one fragment to another. To make the exploration even more efficient, each data fragment is stored in a clustered B+Tree index. To avoid the storage of redundant data and to limit the size of the indexes, the data are compressed using very similar techniques to the ones applied in RDF-3X [START_REF] Neumann | RDF-3X: a risc-style engine for RDF[END_REF]. Let us recall some features of the data stored in graph fragment file: i) First, the triples are sorted by subject (or object in backward graph fragments)and by predicate id, ii) The triples share the same characteristic set, iii) The characteristic set is unique for a single subject (or object in a backward graph fragment). These features allow to devote a single bit per triple (0 or 1) to indicate whether it has the same predicate as the previous one. Thus, it is not necessary to store the predicate value for each triple. This idea is reproduced to store N ode 1 and N ode 2 , where the 0 bit is used to denote when their values do not change with respect to the previous triple. If the value has changed, 8 bytes are devoted to store the identifier or value for both N ode 1 and N ode 2 . The 8 bytes are enough to support Integer → 4 bytes, Long → 8 bytes, Float → 4 bytes and Double → 8 bytes datatypes.

The values of Gf , Gf in and Gf out are represented using the same state logic. The state 0 indicates that the information does not change with respect to the previous triple or if the value does not exist (as in the first line of the example in Figure 4.2f). The following 4 bytes are used to indicate the identifiers of the fragments if any.

An indicator of 17 bits is assigned to each triple to state the number of bytes allocated to each element of the triples. The compression structure for each triple is shown in Figure 4.3.

Execution model

In this section we present the execution model of RDF QDAG that, as we mentioned in the previous sections, is depicted as a graph exploration process. Let us start by recalling the evaluation model used by most of the state-of-the-art RDF systems. In these systems, the evaluation of a SPARQL query is modeled as a succession of triple patterns. Let us consider, for instance, the following SPARQL query: SELECT ?x ?y ?m WHERE{ ?x :has_length ?y .

#tp 1 ?x :manufacturer ?m .

#tp 2 ?m :office_in "Toulouse" . #tp 3 } This query is composed of three single patterns, and the execution is modeled as a sequence of joins:

tp 1 ▷◁ ?x tp 2 ▷◁ ?m tp 3
The optimization problem in these systems consists in finding the optimal join order. On the other hand, the query execution in graph-based systems is modeled as a graph exploration process. These systems model the query as a graph as illustrated in Figure 4.4. An exploration plan defines the order in which the query vertices are assigned to graph vertices [START_REF] Bonifati | Querying Graphs[END_REF]. As with join-based plans, a graph-based plan determines the order of the operations performed by the executor component of the system to find the query matches. The nodes in the query graph can be grouped with their incoming or outgoing edges. This simplifies the execution plans and also allows modeling the query exploration with a similar logic to the one used to group triples in graph fragments in RDF QDAG. We name these structures Forward Query Stars and Backward Query Stars if they group the query's nodes by their outgoing or incoming edges respectively. They are formally described in Definition 4.1. The sets of forward and backward query stars for the query in Figure 4. 4 The query execution is then modeled as a sequence of Query Stars in an Execution Plan that we depict in Definition 4.2. Indeed, an execution plan for a query is not unique. It is the job of the query optimizer to rank the execution plans according to a given cost function and choose the one with the lowest cost. Definition 4.2 Execution plan An execution plan is an order function applied on a set of Query Stars. The function denotes the order in which the mappings for each Query Star will be found. We denote by P = [QS 1 , QS 2 , ..., QS n ] the plan formed by executing QS 1 , then QS 2 ,..., and finally QS n .

In order for an execution plan to be acceptable it must fulfill both of the following conditions: (i) Coverage: all the nodes and edges in the query graph must be covered by the sequence of query stars in the plan.

(ii) Bounded heads: the heads of all the query stars in the plan, excepting the first one, must have a bounded value before emerging in the plan. This condition avoids to perform a Cartesian product between the matches of two query stars and ensures that the results from the previous query stars prune irrelevant mappings in the query stars. This is illustrated in Figures 4.5a The generation and selection of the optimal execution plan is out of the scope of this thesis. We only give an overview of the most relevant definitions to give the reader an idea of how the system works. A detailed description of the cost model and the plan selection algorithm is given in [ZMG + 20]. In the following section we explain the execution of a graph-based execution plan.

Volcano execution model

Let us suppose that the chosen execution plan for a query is P = [QS(x 1 ), ..., QS(x m )]. For each query star of the plan, the execution engine must create a list of candidate graph fragments. The forward query stars admit only forward graph fragments as part of their candidate sets. Similarly, backward query stars admit only backward graph fragments as candidate sets. This set of candidates was already introduced in Section 3.6 but here we give a more formal definition. A graph fragment is part of the candidate set of a given query star if its characteristic set contains the characteristic set of the query star. More formally, Cand(QS

(x i ), Gf ) = {Gf i |cs(QS(x i )) ⊆ cs(Gf i ) ∧ Gf i ∈ Gf }.
For each candidate graph fragment of a query star, the execution engine searches the relevant triples on the B+tree index used to store the data of each fragment. Since for every triple we stored the location (fragment identifier) of their incoming and outgoing edges, the engine knows exactly to which fragment send the intermediate mappings in the next query star. This is illustrated in Figure 4.6. In this case, the first query star ( -→ QS(?x)) has two candidate forward fragments ( -→ Gf 11 and -→ Gf 12 ). The matches found in these fragments are sent to the candidate fragments of the second query star ( -→ QS(?m)). Knowing exactly to which graph fragment should be sent the result of the query star is possible because we stored the location of the direct forward and backward neighbors for each triple. Finally, the results are sent to the Result Writer without needing an extra coordination step (as it is the case in several systems). The core execution engine is based on the Volcano parallel query evaluation system. The model presented in [START_REF] Graefe | Volcano -an extensible and parallel query evaluation system[END_REF] allows to control the amount of data loaded to main memory avoiding any overflow. RDF QDAG uses two memory buffers per query star: input and output buffers. The input buffers load the data sequentially from the B+Tree indexes of each fragment. The matching triples are sent to an output buffer that sends the matching data to the following input buffer. This process is illustrated in

-→ Gf 11 -→ Gf 13 -→ Gf 14 Result writer -→ Gf 15 -→ Gf 12 -→ QS(?x) -→ QS(?m)

Loading costs

The identification and formulation of forward and backward graph fragments in RDF QDAG is certainly a more complex process than the one applied by other systems loading the data directly to a single relational table for instance. The dataset is read several times to identify and encode the data with the desired format. In this section we compare the pre-processing time of RDF systems with different storage and execution paradigms. We compared the loading module of RDF QDAG against relational, graph and cloud-based systems. We compared them in terms of loading time and also in their ability to scale to large scale datasets in architectures with limited resources. Indeed, we noticed that the experimental comparisons of RDF systems are usually performed in platforms in which the datasets fit up to 3x times in main memory (e.g., in [START_REF] Abdelaziz | A survey and experimental comparison of distributed SPARQL engines for very large RDF data[END_REF]). The loading module of RDF QDAG is able to partition very large RDF graphs even when the entire data does not fit in the available main memory. The compared systems are: i) Virtuoso [START_REF] Erling | Virtuoso: RDF support in a native RDBMS[END_REF], ii) RDF-3X [START_REF] Neumann | RDF-3X: a risc-style engine for RDF[END_REF], iii) gStore [Z ÖC + 14] and iv) CliqueSquare [GKM + 15] in a single node (from this point represent it as CliqueSquareS). We evaluated them using real and synthetic dataset described below.

Tested datasets

We used two real and two synthetic datasets with diverse sizes. Within the synthetic datasets we have LUBM 1 [GPH05], a customizable data generator describing information related to universities, departments and faculties. Similarly, WatDiv 2 [AH ÖD14] is a data generator offering the possibility to customize the entities and associations of dataset triples. WatDiv also offers a SPARQL query generator to vary structural characteristics and selectivities of the tested queries. Among the real datasets, we have the DBLP dataset collecting an extract of the information in this computer science bibliography 3 . This dataset 4 is stored in the N-Triples format connecting research papers, authors and venues. Lastly, the Yago2 dataset 5 gathers information from Wikipedia, Wordnet and GeoNames. We used the version of this dataset published in [START_REF] Abdelaziz | A survey and experimental comparison of distributed SPARQL engines for very large RDF data[END_REF].

The characteristics of the datasets are summarized in Table 4.1. We generated synthetic datasets with different sizes to test the scalability of the tested loading approaches.

1 http://swat.cse.lehigh.edu/projects/lubm/ 2 https://dsg.uwaterloo.ca/watdiv/ 3 https://dblp.uni-trier.de/ 4 Available at: http://dblp.l3s.de/dblp.rdf.gz 5 Available at https://github.com/ecrc/rdf-exp 128 4.3. LOADING COSTS

Configuration setup

The tested systems perform the data pre-processing in a single site (the master node in a distributed system with a master/slave architecture). The master site in our system runs a 64bit Linux with 32GB of RAM, an Intel(R) Xenon(R) Gold 5118 @ 2.30 GHz processor and 2TB of hard disk. As it was previously mentioned, the Data Loading module of RDF QDAG is coded in Java (only the indexing sub-component loading the data in the B+Tree is coded in C++). We implemented a fragmentation module on Scala that runs on a Spark cluster. However, the tests in this section are performed in the centralized version of the fragmentation module that successfully managed to load all the datasets.

Pre-processing times

The pre-processing results are summarized in Table 4.2 and are illustrated in a bar chart comparing their logarithmic times in Figure 4.8. The loading times of RDF QDAG are comparable to the ones obtained by other systems loading the data directly to triple tables. Clearly Virtuoso and RDF-3X loaded the data faster, yet the detection and division of data in graph fragments is not a process that makes the loading process a significantly more expensive step. As we will discuss later (in Section 4.4.3), partitioning the data in graph fragments enhances the performance of some queries. In addition, as we have discussed throughout this thesis, the identification of logical entities brings other benefits such as simpler design of other optimization strategies.

Furthermore, the loading module of RDF QDAG was the only one capable of charging all the datasets given the limited main memory (32GB). The graph-based system gStore was unable to load datasets whose size is greater than the available main memory. The relational-based systems managed to load all the datasets except LUBM1B in which we got a memory overflow error. In addition, RDF QDAG loaded more efficiently datasets with great number of predicates compared to Cliquesquare. Let us recall that Ciquesquare groups the triples in different files inside the Hadoop Distributed File System (HDFS) based on the triple's predicates. When the number of predicates augments, the partitioning becomes less efficient.

Dataset Logarithmic time

Virtuoso RDF-3X gStore Cliquesquare RDF QDAG

Evaluation of the fragmentation strategies

In this section we present an evaluation of the use of forward and backward graph fragments initially as logical entities and then as physical structures in RDF processing systems. We begin in Section 4.4.1 by verifying that the number of fragments generated for each dataset is reasonable. We show how many fragments are generated and what percentage of the dataset they represent. In addition, we show the number of fragments needed to cover the eighty percent of the data. This is to show that the groups of graph fragments are a large picture of the input data and could be later used to propose other optimization strategies. Then, in Section 4.4.2, we compare the performance of systems storing physically the data as forward or as backward graph fragments. We analyze the types of queries for which each fragmentation strategy works best. We named the section exclusive comparison since we compare separately forward and backward fragmentation strategies. Finally, in Section 4.4.3 we compare the performance of RDF QDAG, which uses both types of fragments simultaneously, with representative systems of the state of the art.

Data coverage

The results of this section are shown in Table 4.3. The forward and backward graph fragments are obtained using τ = 1 and considering the structural similarity measure. In this way, we analyze the boundary cases with the maximum number of graph fragments. For all the real datasets and for Watdiv, the number of forward graph fragments is greater that the number of backward graph fragments. This is due to the fact that in average, the outdegree of the vertices in these datasets is larger than their indegree. Thus, there are more possibilities to combine predicates as forward fragments and the number of outward characteristic sets is greater than the inward ones. For both synthetic datasets, the number of graph fragments covering 80% of the data is almost invariable with respect to the size of the dataset. This makes sense because our fragmentation strategy allows to detect the seed entities used to generate more data. Actually, the dataset's size is increased varying slightly the features of these seed entities identified as forward graph fragments (≈ 1030 in Watdiv and ≈ 10 in LUBM). LUBM has a very limited number of predicates, and being a synthetic database, the generated data is not very variable. This influences definitely the number of forward and backward fragments found for this dataset (less than 40 fragments in the dataset with more than a billion triples). Overall, the number of fragments is always finite and reasonable with respect to the size of the dataset they represent. As we will see later when analyzing the allocation strategies, the use of fragments that hold 80% of the data facilitates the use of graph partitioning algorithms to decide the location of the fragments in the system.

Exclusive comparison of fragmentation strategies

The objective of this section is to analyze the impact of organizing the data in forward or backward graph fragments and to determine which type of fragmentation strategy is more pertinent for a query type. Let us recall that RDF QDAG stores the data in forward and backward graph fragments simultaneously. At query runtime, the system moves through the inward (or outward) edges of each node in the graph to find matches for a given query pattern. This search is made very efficiently thanks to data partitioning in forward and backward graph fragments that include information of the direct neighbors of a node. However, in this section we are interested in evaluating both partitioning strategies separately. For this we use two scenarios, the first one described in Section 4.4.2.1 built in a relational database and the second one in Section 4.4.2.2 using a graph-based system.

Incorporating our framework to a relational-based centralized store

In this section we evaluate the influence of physically storing the data as backward graph fragments in a relational database. The results described in this section are part of the experimental study of the article Reverse Partitioning for SPARQL queries [START_REF] Galicia | Reverse partitioning for SPARQL queries: Principles and performance analysis[END_REF]. We stored RDF datasets into a relational database using three different strategies: i) single big table of three columns (subject, predicate, object) similar to RDF-3X's and Virtuoso's strategy, ii) vertical partitioning (one table per predicate) similar to the strategy applied by SW-Store [START_REF] Daniel | Sw-store: a vertically partitioned DBMS for semantic web data management[END_REF] and iii) applying our reverse partitioning strategy gathering the data by incoming edges. We implemented a customized query parser transforming SPARQL statements into SQL in accordance with each of the previous schemas. We preferrred to create the query translator instead of using the systems implementing the previous approaches to evaluate strictly the influence of the storage configurations. We evaluated on each schema the execution time of queries with different forms (The tested queries are available in the Appendix B).

Configuration setup

The partitioning module derived from the RDF QDAG loading module is implemented in Java. The translation module from SPARQL to SQL was implemented also in Java and the data were stored on PostreSQL 11. The experiments were performed in the master node of the hardware described in Section 4.3.2. We tested our approach with the WatDiv framework since it offered a wide variety of queries. We generated datasets of 1, 10 and 20 million triples. More details about the datasets are shown in Table 4.4. For each of them we generated 80 queries (20 of each query type).

Experimental results

The results are shown in Figure 4.9. Creating vertical partitions on the predicates gives the most performant execution times for the majority of queries considering that there was not an intense intermediary indexing strategy as it is the case for RDF-3X. The major drawback of the vertical partitioning strategy is data distribution on the tables. The performance of the data stored as backward graph fragments is almost as good as the vertical partitioning, especially when the dataset size is bigger and exploring a single table becomes more costly. Backward graph fragmentation performance suffers in queries with patterns in which the subject and object are unknown. In a relational-based system, storing the data in graph fragments is ideal to prune queries with patterns with bounded values at the object position. This is the case of queries 9-12. In this section we compare the performance of organizing the data as forward or as backward graph fragments in a graph-based triple store. We determine for which type of queries organizing the data as forward graph fragments is more suitable than backward graph fragments and vice versa. To the best of our knowledge, there is no graph-based RDF system storing the data exclusively as backward graph fragments. Indeed, RDF QDAG uses both structures (i.e.

-→ Gf and ← -Gf ) and gStore stores the data in adjacency lists grouping the data by subjects. For the experiments in this section, we adapted the distributed version of gStore [PZ Ö+ 16] to support the storage of forward graph fragments first and then of backward graph fragments. The results in this section are part of the experimental study of our framework: RDFPartSuite: Bridging Physical and Logical RDF Partitioning published in [START_REF] Galicia | RDFPartSuite: Bridging physical and logical RDF partitioning[END_REF].

Configuration setup gStoreD was deployed on a 5 machine cluster connected by a 10Gbps Ethernet switch. The cluster runs a 64-bit Linux and each site has a 8GB RAM, a processor Intel(R) Xeon(R) Gold 5118 CPU @ 2.30GHz and 100GB of hard disk. The latest version of gStoreD6 was configured to store the data on adjacency lists on the subjects, and a modified version storing the data on adjacency lists on the objects. The adjacency lists on the subjects are the default structures employed by gStore's V * -Tree index. At the loading stage, the user indicates in a file the location for each subject (data star head in our notation, cf. Definition 3.1) and all the triples with that subject are assigned to that location id. We make sure that the triples belonging to the same forward graph fragment are located in the same partition. Then, to load the data in adjacency lists by objects we slightly change the input file containing the raw RDF data. The data is injected to gStore in a file in N-Triples format whose triples are ordered as (subject predicate object). To force the creation of adjacency lists from the object, we change the order of the input file to (object predicate subject). We changed the file with the subject's location (giving the location for each distinct object) and the SPARQL queries accordingly. For example, a query pattern ?x p ?y in the original query list is changed to ?y p ?x in the queries used to test backward fragments. We performed the evaluation with the four query types (linear, star, snowflake and complex queries) of the Watdiv benchmark with 10 million triples. The list of queries is found in the Appendix B.

Experimental results

The results are shown in Figure 4.10. The system has much better performance when the data are organized as backward graph fragments when solving linear queries. It performed in average 1.4x faster than when the data was organized as forward fragments. For star queries, the use of backward fragments enhanced up to 1.2x in average the performance. For snowflake shaped queries, there is no strategy that works better than the other. We found queries in which backward graph fragments worked better because there was a bounded value in the object position of the query, but if this condition was not fulfilled forward fragments worked better. Organizing the data as forward fragment was definitely better to solve the workload of complex queries (up to 1.2x faster for query 18). Both strategies complement each other in the processing of certain query types. In the following section we show that the combination of both structures in RDF QDAG drives RDF data processing in centralized systems efficient and scalable.

Combining fragmentation strategies

In this section we present the results of an experimental study comparing RDF QDAG with three representative systems of the state of the art. We compared them in terms of query performance (for BGP queries) and scalability. The compared systems are:

(i) Virtuoso7 [EM09]: it is the relational-based system by excellence storing the data in a triple table.

(ii) RDF-3X8 [NW08]: intensive index-based system able to scale to billions of triples. Used as baseline of many optimization approaches (e.g., characteristic sets [START_REF] Neumann | Characteristic sets: Accurate cardinality estimation for RDF queries with multiple joins[END_REF]).

(iii) gStore9 [Z ÖC + 14]: graph-based system storing the data in adjacency lists.

To evaluate their scalability we used datasets of several millions of triples. Specifically we used Watdiv100M, Watdiv1B, LUBM500M, Yago and DBLP whose characteristics are described in Section 4.3.1. The testes were performed on the master node of our testing platform described in Section 4.3.2. The results presented in this section are an excerpt from our paper describing RDF QDAG main components in [KMG + 20]. The queries are in the Appendix B of this thesis. For all the experiments, we run the queries 3 times (excluding the first cold start run time to avoid the warm-up bias).

Let us start discussing the results of the queries performed in the Watdiv benchmark shown in Table 4.5. As it was explained when we compared the loading times in Section 4.3.3, gStore was unable to load Watdiv1B. Furthermore, at query runtime, gStore loads the V * -Tree index to main memory before looking for query matches slowing down the execution of most of the queries. Complex queries in Watdiv100M are solved in average 5.3x faster in RDF QDAG compared to Virtuoso and RDF-3X. For the dataset of more than a billion triples (i.e. Watdiv1B), RDF QDAG is clearly faster to solve complex queries (130x faster in average). For snowflake queries in the Watdiv100M dataset, Virtuoso, RDF-3X and RDF QDAG performed very similarly. However, the same queries in the dataset of 1 billion triples were solved 4.9x and 12.8x faster in RDF QDAG than in RDF-3X and Virtuoso respectively. Linear queries were solved 0.4x and 45x faster in our system than RDF-3X and Virtuoso for Watdiv1B, and all three performed similarly in Watdiv100M. Finally, star queries are solved faster in Virtuoso in the smaller dataset, but in average 4.9x faster than RDF-3X and 12.8x with respect to Virtuoso in the 1 billion dataset.

The other synthetic dataset, LUBM500M, whose results are shown in Table 4.6, could not be loaded by gStore for the same reasons as the previous one. RDF-3X performed slightly better for queries 8, 11, 12 and 14, that are snowflake shaped queries. Still, in all the other queries RDF QDAG outperformed both systems solving queries 9.8x and 1.1x faster than Virtuoso and RDF-3X respectively. Among the real datasets, we designed the workload of DBLP in queries with different shapes and selectivities. As it is shown in Table 4.7, RDF QDAG outperformed RDF-3X and Virtuoso for most of the queries (1.6x faster than Virtuoso and 13.8x faster than RDF-3X). The queries in which the systems had a similar performance are those very selective (e.g., L1, S1 and S5). Finally, the results of Yago are plotted in a logarithmic scale in Figure 4.11. RDF QDAG outperformed the three systems and managed to filter faster the results based on the known bounded values of the queries (e.g., query Y2). It achieved up to 4x faster performance compared to Virtuoso.

Summary The virtues of the logical partitioning strategy have been shown throughout these sections. Undoubtedly, a logical partitioning strategy grants much more freedom to designers and managers. They do not depend anymore on a specific system to partition their data. We have shown the feasibility of incorporating our framework into centralized and distributed triple stores. Furthermore, the experiments using RDF QDAG reveal that the use of these structures in a centralized native triple store ensures its scalability and good performance for certain queries.

Evaluation of the allocation strategies

In the previous section we evaluated whether both fragmentation strategies proposed in this thesis are effective to cover the completeness of the data in a reasonable manner. Then, we compared their effectiveness at query runtime with other physical organization strategies of the state of the art. In this section, we evaluate the allocation strategies proposed to place the forward and backward graph fragments to the sites of a distributed triple store. We start in Section 4.5.1 comparing three allocation strategies in terms of data skewness prior the query execution. Then, in Section 4.5.2 we present an extensive study of the communication costs of the state-of-the-art partitioning strategies versus the allocation heuristic proposed for our logical structures. This study is based on the execution logs of RDF QDAG. Finally, in Section 4.5.3, we compare the performances of a graph-based system, a cloud-based system and a system that applies the partitioning strategy proposed in this study. Part of the results in this section were published in our work [START_REF] Galicia | RDFPartSuite: Bridging physical and logical RDF partitioning[END_REF] introducingRDFPartSuite Framework.

Data skewness comparison

In this section we compare the round-robin, linear programming and min-cut allocation strategies in terms of data skewness. The first strategy assigns the fragments (forward and backward) to the sites in a round-robin manner. The linear programming uses a solver to find the optimal solution for the problem defined in Section 3.5.1. Finally, the min-cut strategy refers to the graph-based heuristic described in Section 3.5.2. We give as inputs to the linear programming and min-cut strategies only the necessary fragments to cover the 80% of the data (cf. Table 4.3). The other 20% are assigned in a round-robin manner. The results are shown in Figure 4.12 in which we represent the distribution when 5 and 20 partitions are created for some of the datasets described in Section 4.3.1. For each partitioning strategy we show the proportion of the number of triples assigned to each site in a stacked bar and in a secondary axis the precision of the distribution. 5) The linear programming solution, was implemented using the Gurobi10 optimization library [START_REF]Gurobi optimizer reference manual[END_REF] . To obtain a solution with a reasonable time, we configured the imbalance parameter in the first constraint of the problem ϵ = 500M triples. Even with this big tolerance, the majority of the data was allocated to one partition. Also, we validated that the round-robin distribution strategy leads to data skewness problems compared with the graph partitioning heuristic. For example, for LUBM100M, the number of triples stored in the second site is significantly larger to the number of triples in all of the other partitions.

GP RR LP GP RR LP 0 0, 2 0,4 0,6 0,8 1 Precision (e) WatDiv100M (20)
GP RR LP GP RR LP 0 0, 2 0,4 0,6 0,8 1 Precision (f) LUBM100M (20)
GP RR LP GP RR LP 0 0,2 0,4 0,6 0,8 1 Precision (g) Yago (20)
GP RR LP GP RR LP 0 0,2 0,4 0,6 0,8 1 Precision (h) DBLP (20)
The precision of each partitioning strategy is shown in the secondary axis of the graphs of Figure 4.12. It is calculated as: w (ec) w(e) , in which w(e c ) and w(e) are respectively the sum of the weights of the cut edges and the total number of edge's weights. In other words, it is the ratio of the number of triples that share a subject (or object) in two fragments located in different sites with respect to the number of triples on the site. The results are shown in the red line of Figure 4.12. As expected the higher precision is obtained by the linear program, however the scalability on this program is very low and in the ends puts most of the data to a single site. The min-cut partitioning algorithm, used by systems like EAGRE [START_REF] Zhang | EAGRE: towards scalable I/O efficient SPARQL query evaluation on the cloud[END_REF] to distribute forward fragments, gets better results than the round-robin strategy, not only in terms of data distribution but also on the precision.

Communication costs study

In this section, we present an extensive study of the communication costs induced by different allocation strategies. To evaluate fairly and isolate the impact of an allocation strategy at query runtime, we run the queries on the same execution engine. We measured precisely for each query the number of intermediate results exchanged. For this purpose, we use the execution logs of RDF QDAG [KMG + 20]. Even though it is a centralized system, we collected for each query the number of data sent from one fragment to another as it was explained when we described Figure 4.6. Then, we calculate the total mappings exchanged between fragments in different sites.

We analyzed the communication costs for the following allocation techniques:

• Hash on subject (H): as shown in the Related Work section, several systems follow this strategy applying a hashing function on the triple's subject.

• Linear programming (LP): the problem formalized in Section 3.5 was programmed and solved with the Gurobi [START_REF]Gurobi optimizer reference manual[END_REF] optimization library as in the previous section.

• Graph partitioning (GP): the data are firstly grouped in graph fragments that are distributed using a graph partitioning heuristic (METIS [START_REF] Karypis | A fast and high quality multilevel scheme for partitioning irregular graphs[END_REF]).

• Graph partitioning (small groups) (GPS): in this strategy the size of the graph fragments were restricted to form as many fragments as possible. Then these smaller fragments are distributed with a graph partitioning heuristic. We seek to see whether regulating the size of the partitions influence in the overall performance of the system.

• Round robin allocation (RR): data firstly grouped in graph fragments are distributed in a round-robin manner.

All of the previous allocation strategies were evaluated in the Watdiv benchmark since it offered queries with different structures (complex, snowflake, linear and star). We generated a dataset with about 100k triples to guarantee that the linear program finds a solution in a reasonable time. We partitioned the data in 5, 10 and 20 sites to evaluate the performance of the solutions as the number of sites grows. The results comparing the number of mappings exchanged by fragments in different sites for each query are shown in Figure 4. 13.

The linear programming strategy (identified as LP in the graphs) is, as expected, the one with the lowest number of mappings exchanged between sites in most of the queries. There are still some queries where the graph partitioning strategy with smaller groups (GPS) or hashing by the subjects performed better. This is because the function to optimize in LP considers moving the initial graph fragments from one site to another, but does not consider making smaller fragments. For those queries, making smaller fragments reduced the number of exchanged mappings (e.g., queries 1 and 13 in the case of 5 partitions). The hashing strategy performed well for linear queries but it induced several exchanges for the other query types. In general, for linear queries we did not find an absolute winning strategy, since the queries are quite simple the allocation strategy did not varied considerably the number of mappings. The round robin allocation strategy was the one with the highest number of mappings for all of the query types in the tests with 5, 15 and 20 partitions. Furthermore, the graph partitioning strategy that does not modify the size of the groups offers a reasonable performance without modifying the sizes of the loaded groups. This strategy worked better in snowflake and star-shaped queries. Another interesting finding was that the number of generated partitions (e.g., 5, 10 or 20) did not influence the number of mappings sent between sites.

Our experiments show that allocation strategies like graph-partitioning heuristics are a good compromise to reduce the number of data interchange at query runtime. Still, if the queries are mostly simple linear queries, a hashing function has shown to have also an advantageous performance. Another essential insight is that regulating the size of the groups of graph fragments is crucial to achieve a good performance, as it was proven by the number of exchanged results in complex queries.

Distributed experiments

We used synthetic and real datasets to compare three systems with distinct partitioning and execution strategies. Contrarily to the experiments detailed in Section 4.4.3, we compare RDF -QDAG with two distributed triple stores. Our goal is not to compare the performance of systems storing physically the data with different structures as in Sect. 4.4.3. Here, our focus is to compare systems distributing the triples with different strategies. The compared distribution strategies are: i)cloud-based, ii)simple hashing and iii)our allocation strategy of graph fragments. The tested systems are:

(i) gStoreD [PZ Ö+ 16]: graph-based system partitioning each node by subject. We use as well the centralized version of this system for reference.

(ii) Cliquesquare [GKM + 15]: cloud-based system fragmenting the data by predicates. We configured the system in a single and multi node modes.

(iii) RDF QDAG [KMG + 20]: centralized system partitioning the data in forward and backward graph fragments.

Configuration setup

The experiments were conducted on a cluster of 5 machines connected by a 10Gbps Ethernet switch. The cluster runs a 64-bit Linux and each site has 16GB (32GB in the master node) of main memory, a processor Intel(R) Xenon(R) Gold 5118 @ 2.30 GHz and 100GB (2TB in the master node) of hard disk. As it was done in the communication study, we use Yago and DBLP as real datasets. We use Watdiv100M and LUBM100M as synthetic datasets. Also, to be able to compare with gStore which was unable to load LUBM100M, we also tested in LUBM with 20 million triples.

Experimental results

The results are shown in Tables 4.9-4.10. We use the following abbreviations for each system: Cliquesquare in a single node (Cs), Cliquesquare in multiple nodes (CsD), gStore (gS), distributed gStore (gSD) and RDF QDAG. In the tables, we show the execution time in seconds, highlighting with bolds the best results for each query. Below we discuss the results for each dataset.

Watdiv For most of the queries, the execution time of RDF QDAG is up to 60x less than all the other systems. It performed on average 400x, 40x, 348x, and 40x faster for linear, star, snowflake and complex queries respectively. However, for the complex query C3 which involves several graph patterns without any subject or object known was performed almost 2x faster by gStore. This dataset fitted in main memory and therefore, for in-memory systems (like gStore) the matching processing is faster. Especially in queries that are not very selective or that do not have a bounded subject or object that could be used by RDF QDAG to prune. RDF QDAG processing is based on the Volcano execution model, exchanging data between the disk and main memory to guarantee scalability and the same time ensuring a good performance. As it is shown next in the real datasets, gStore was not able to treat these datasets whose size is bigger than the available main memory.

LUBM The results for both datasets are shown in the Table 4.9. The system RDF QDAG outperformed all the other tested systems (centralized or distributed versions) in most of the queries for both dataset sizes. As shown by the results in the Table 4.9, for the 20 million triple dataset Cliquesquare (single or multinode) is the slowest system due to the starting cost of the MapReduce engine which does not offset the performance gain of parallelism. Even if gStore systems (centralized and distributed) are able to load the 20M dataset, RDF QDAG performs better for all queries except the sixth which is a simple query but not very selective. However, the same query in the dataset of 100 million triples is solved 15x faster by RDF QDAG. For the dataset of 100 million triples, RDF QDAG is faster in almost 80% of the queries. The queries (2,[START_REF]Triple stores classification[END_REF]6,14) for which Cliquesquare performed in average 2.4x faster than RDF QDAG were simple queries not selective with many results. In this case, the parallel treatment offered by MapReduce in Cliquesquare works best. Let us remind that RDF QDAG partitioned the graph but worked in a centralized configuration, the parallel version of this system is part of our future perspectives.

Yago and DBLP The results are shown in Table 4.10. Cliquesquare and the centralized version of gStore were unable to process the tested queries. RDF QDAG outperformed gStoreD by almost 1000x. Concerning DBLP, the distributed versions of gStore and Cliquesquare as well as RDF QDAG were able to process queries on this dataset. RDF QDAG performed in average 500x better than all the tested systems.

Summary These experiments complement those that evaluated data fragmentation. We show the advantages of our allocation strategies in terms of balanced data distribution and query performance. Our experimental study showed that incorporating our logical partitioning strategies to a centralized triple store can make them more performant than many of the current distributed systems. Our partitioning strategies enable a graphbased system (RDF QDAG) to scale contrary to other centralized graph-based systems like gStore. The bold cells represent the lowest execution time and ✗ that the system was unable to perform the query.

Partitioning language

The creation of forward and backward graph fragments before partitioning a raw RDF file contributes to integrate a logical dimension to the purely physical partitioning process. This logical layer allows designers to deal with much more manageable structures than the one offered by single triples. These structures can be used not only by system's developers but also by Triple Store managers. In this section, we present a user-friendly extension to the RDFPartSuite framework. We propose a declarative partitioning language that allows designers, based on their expertise level, to manually partition a KG.

The declarations are done similarly to the ones of tables and partitions with a DDL (data definition language) available in some database management systems (e.g., Oracle11 , PostreSQL12 ). The language uses the logical structures and hides the implementation of the fragmentation and allocation algorithms presented in the previous chapter. In the following section we define the grammar and syntactical elements of this language. RDFPartSuite keeps a meta-data file with information related to the managed KGs. This includes, their names, fragments and predicates identifiers. The specifications of the infrastructure used by the triple store (number of sites, available space on each site, IP of each site, etc.) are also kept in a separate file by the framework.

Notations

Before defining the grammar, let us consider the notation used to define the syntax of the definition language. This declarative language is not case-sensitive. While describing the grammar we used some commands in uppercase just to facilitate their readability. The language is composed of seven main statements from the declaration of the KG to the allocation of graph fragments to the sites of the system. Each of these statements is described next.

CREATE KG statement

This statement creates an empty Knowledge Graph and stores the name in a metadata file maintained by the framework. If the KG exists already (identified by the kg name), it sends back an error. In the previous statement, the f ilename is the raw RDF file stored in the working directory 13 of the framework. For example, here we state that the triples of the file yago-knowledge.nt belong to the yago KG declared previously. The language allows to partition a KG (identified by kg name) in Forward or by Backward graph fragments. The structural partitioning (using characteristic sets only), a similarity threshold of 1, and the maximum size of 50 million triples per partition are the default parameter values. The fragmentation mode can be changed to either of the modes presented in Section 3.3.1.1. Also, it is possible to limit the maximum size of fragments (in number of triples) using the keyword MAX. Finally, it is also possible to change the similarity threshold (SIM) that is 13 Indicated in a configuration file defined in Sect 3.3.1.1. This value is a float between 0 and 1. If the user enters a similarity threshold greater than 1, the framework identifies it as an error and abort the command.

For example, let us consider that the yago KG declared previously. is partitioned by forward fragments, using the JACCARD MODE, restricting the number of triples in a fragments to 10,000 and choosing the similarity threshold to 0.8. All the fragments and predicates are identified with an integer identifier (frag id and pred id respectively) automatically generated by RDFPartSuite. A fragment can be sub partitioned using two main modes: hashing function or range partitioning as defined in Section 3.7. Let us consider the example in which we want to partition a fragment in the yago KG identified with the ID = 345. The fragment is partitioned in two parts according to the values of the predicate identified with the ID = 8 (whose range are integers).

ALTER FRAGMENT 345 IN yago SUBPARTITION BY RANGE 8 LESS THAN 4000

ALLOCATE statement

This statement allocates the fragments of the previous instruction according to a round-robin rule or using the graph partitioning heuristic described in Section 3.5.2. For example, in our running example, we can allocate the fragments in the yago KG using the graph heuristic in 5 sites.

ALLOCATE yago BY METIS SITES 5

ALTER ALLOCATION statement

This statement allocates a given fragment (identified by a fragment ID) to a specific site (identified with a site ID). In our example, the KG is dispatched to the sites of the system as follows:

DISPATCH KG yago 4.6.9 Integration of the language to other systems

In this section we show that the proposed language is able to express the partitioning strategies used by most of distributed RDF systems. For example, HadoopRDF [START_REF] Du | HadoopRDF: A scalable semantic data analytical engine[END_REF] applying a hashing function on the subject is mimicked creating forward star graphs fragments that are allocated using a round-robin. If there are 15 sites in the system, the partitioning is declared as:

FRAGMENT KG yago FORWARDLY ALLOCATE yago BY ROUND-ROBIN SITES 15

If the system uses vertical partitions (e.g., SW-Store [AMMH09]), backward graph fragments are then declared. The declaration of fragments with maximum partition size of 1000 is for example:

FRAGMENT KG yago BACKWARDLY BY SUPERSET MAX 1000 ALLOCATE yago BY ROUND-ROBIN IN SITES 5
The gStoreD [PZ Ö+ 16] system creates the forward entities and leaves to the user the freedom to choose the allocation strategy. Supposing that she/he chose a graph partitioning heuristic, the declaration is:

FRAGMENT KG yago FORWARDLY ALLOCATE yago BY METIS SITES 15
The system RDF QDAG[KMG + 20] uses both, forward and backward segments, and allocate them with a graph partitioning heuristic declared as:

RDF partitioning advisor

In this section we present a partitioning wizard that integrates in different modules each of the fragmentation and allocation approaches that have been proposed so far. Our goal is to provide user-friendly tools for experimented and non-expert users. An expert user (manager) can choose to integrate the interfaces of RDFPartSuite directly to her/his code. The user can also choose to manually partition the data using the declarative partitioning language that we proposed in the previous section. Our partitioning advisor is designed to assist non-expert designers or administrators of centralized or distributed triple stores. It produces a partitioning schema for a KG based on the input user's requirements. It provides a degree of comfort similar to the one offered by the partitioning advisors in the relational model (Sect. 1.4.3.1).

Main functionalities

RDFPartSuite's advisor functionalities are summarized as follows:

• Collect manager's requirements: the advisor provides means to managers of centralized and distributed triple stores to record the creator's requirements (functional and nonfunctional), constraints, and KGs to be considered in the fragmentation, allocation and loading processes.

• Smart KG Fragmentation: the advisor proposes a fragmentation schema for the input KG considering the manager's explicit requirements and using default parameters (e.g., similarity threshold).

• Smart KG Allocation: an allocation schema is proposed by the advisor. This schema considers the manager's requirements explicited in the first requirement.

• Tune fragmentation and allocation: the advisor leaves the final decision of how to fragment and how to allocate to the managers. The manager is able to choose different fragmentation and allocation strategies from the ones proposed automatically by the advisor. Additionally, it lets the manager change the values of the input parameters and let them sub partition manually large graph fragments.

• Load the data to a triple store: this functionality concerns the data transfer and loading to the target triple store. At the moment we support RDF QDAG and gStoreD.

As summary of the functionalities of the system is shown in Figure 4.14. Basically, the manager seeks to fragment a given raw RDF dataset in graph fragments. The tool adjusts the partitioning strategy according to a set of configuration parameters (e.g., system catalog, constraints). It allows exploring the set of fragments and their distribution and if necessary, adjusting the fragmentation strategy or re-partitioning some fragments. Finally, the set of graph fragments are distributed/loaded to the sites of the system.

The following section describes the architecture of this system that we name RDFPartSuite GUI. It is composed of five modules: features extractor, fragmenter, allocator, dispatcher and the Graphic User Interface (GUI). The framework provides a Web User Interface to manage the partitioning process. This interface is similar to the ones available to administrate the current big data frameworks. The back-end layer was implemented using the Java programming language chosen for its robustness, portability and available libraries. The communication between the backend and the graphic interface is performed using a REST API. The backend is built following the MicroProfile specification using JAX-RS and CDI components. The client layer (i.e. frontend) is implemented with Vue.js and Bootstrap. Below, we detail each of the RDFPartSuite components.

Features extractor

This component is in charge of processing the information collected from the GUI. It gets for instance the configuration parameters for the fragmentation algorithms. For example, the similarity threshold, the type of similarity scores and the allocation methods. It also processes information related to the system's hardware (e.g., available space in hard disk, main memory available per site).

Fragmenter

This component is in charge of creating the forward and backward graph fragments. It gathers the data following Algorithms 1 and 4 respectively. By default it creates groups of triples using the structural similarity measure on the characteristic sets. The similarity threshold is initially fixed to 1, but it can be tuned in the next component. This component also calculates a set of statistics characterizing the fragments. It counts the number of triples per fragment and calculates the distribution of the data on the fragments. It also detects which fragments should be re-partitioned because their size exceeds the maximium available space in a single site. It communicates with both, the fragmenter and dispatcher components, since it collects information to create the plots guiding the user to choose the optimal fragmentation and allocation strategies. For the distributor component, it calculates the precision of the distribution calculating the relative number of cuts in the sites.

Fragmenter Allocator

Dispatcher/ Loader

Features extractors

System catalog

Config. parameters

Back-end

REST API

Web application GUI

Front-end

Allocator

This component calculates firstly the distribution of the final graph fragments (the ones created after re-partitioning) to the sites of the system. It lets the user choose among the graph partitioning heuristic and the traditional hashing function. It sends the number of data exchanged between two partitions to the statistics generator component which calculates the allocation's precision. The output of this component is a file indicating the site to which each fragment should be assigned.

Dispatcher/Loader

This component is in charge of sending the fragments to the sites of the distributed system according to the allocation schema produced by the previous component. This component connects to the loading module of a centralized (RDF QDAG) or distributed triple store (gStore) and load the data according to the fragmentation (in centralized) or allocation (in distributed) schema.

Use case

In this section we present the functionalities of RDFPart following the sequence of screens in the web graphic user interface. We show for each screen the expected inputs, options and outputs from the processing modules in the back-end. The welcome screen of our interface is shown in Figure 4.16. In this interface, the user selects the raw RDF file to be partitioned (in N-Triples format). Then, it selects the directory to store the temporary files generated during the fragmentation stage. By default, this directory is set the same directory as the raw RDF file. Next, it collects information about the infrastructure in which the data will be partitioned. It gets the number of sites (workers and master), and their available space in hard disk and main memory. If the site's specifications are different in the master site (which sometimes have more available main memory and disk), it records this information in a different form. After this data is set, the Start Partitioning action button activates and the system performs an initial scan on the data to encode it and detect the distinct predicates. Finally, it allows to select the domain and range of each predicate, which by default are set to strings. After this stage, the fragmentation strategy using Algorithms 1 and 4 begins. The fragmentation progress can be tracked using the progress bar of the second screen shown in Figure 4.17a. Once the fragmentation process finishes, the forward and backward graph fragments are persisted to a temporary directory and a set of statistics are displayed. These statistics include the number of distinct predicates, forward and backward graph fragments. By default the fragmentation is performed using the structural similarity measure (which is by far the simplest). We displayed as well the distribution of the total data in the forward and backward fragments in a line chart. This graph shows from the total number of fragments (normalized to a percentage), what is the percentage of the total data stored on them. This visualization allows to detect if most of the data are condensed into a few fragments and should therefore be re-distributed. The re-fragmentation module is illustrated in Figure 4.17b. This screen allows to change the default structural similarity score and to select a distinct similarity threshold. Since the interface was developed with VueJs, the graph of Figure 4.17a would change when the similarity score is changed. A comparison of the total number of fragments of the default fragmentation and the tested one is shown in an horizontal bar chart in Figure 4.17b. Finally, if the set of fragments whose size is greater than the available space in a single site are shown in at the bottom of the screen in the section Big fragments. This menu allows to choose the re-partitioning strategy which by default is set to a hashing function as described in Section 3.7. However, the data from a fragment can be re-partitioned using a single predicate and the definition language of the previous section. To save the changes the user clicks on the Re-partition! button.

The final screen concerns the allocation of the forward and backward fragments to the sites of the distributed system. This screen is shown in Figure 4.18. When the workload is available, it selects the directory storing the SPARQL query files. The specification asks a single file per query. After clicking the Test allocation button it compares using a customized precision function the distribution of the case in which the fragments are distributed using a hashing function on the predicates, and the graph partitioning heuristic defined in Sect. 3.5. The final allocation method is selected from the right drop-down list and it generates in the temporary directory a file with the graph fragment identifier and its location id.

Conclusion

In this chapter we presented our framework in action. We used the fragmentation and allocation modules to load the data into a centralized and distributed triple store. We performed a series of tests on each of the tested systems to show the strengths, features and limits of our framework. We started giving an overview of the centralized RDF QDAG triple store. This system stores the data as forward and backward graph fragments. We integrated our findings to the loading module of this system. We compared the loading costs of RDF QDAG with other representative systems of the state of the art in terms of time and scalability. We showed that the fragmentation process with our entities (Gf ) is feasible, even in architectures with limited resources. Even though the loading times were high compared to other lighter fragmentation techniques (e.g., triple table), we saw the advantages at query runtime of this extra cost. Then, we performed a complete evaluation of the fragmentation strategies. We started showing that the number of fragments is reasonable with respect to the datasets' sizes. Next, we use our framework to fragment the data in forward and backward graph fragments in a graph-based distributed triple store (gStoreD). This system was used to compare Forward and Backward fragmentation strategies. Next, we showed that combining both types of fragments in a single system contributes not only for scalability but to enhance the query performance. We performed an extensive study on the communication costs comparing our partitioning strategy with the most relevant state-of-theart techniques. We have shown that our strategies give a promising compromise between the allocation cost, measured in terms of loading time, distribution's quality, and query performance. Finally, we introduce a user friendly extensions to our framework. These extensions are a declarative partitioning language built on top of the logical structures of the previous chapter and a partitioning advisor.

Conclusions and Perspectives

Conclusion

Currently, our world is filled with data. A large part of this data is freely available on the Web. The W3C devoted many efforts to the development of standards that facilitate the exploitation, exchange, and reuse of this data. Among these standards, RDF excels for its flexibility, simplicity, and the expressiveness of its query language (SPARQL). RDF statements are triples logically represented in a graph. These graphs interconnect data coming from multiple datasets constituting a Knowledge Graph (KG). The complexity of this later concerns both its ecosystem that involves several actors (e.g., creators, consumers, managers) and infrastructures, and its size. To satisfy the requirements of these actors, each KG has to be efficiently stored and queried to facilitate the different processes of its exploitation. As quoted by Clifford Stoll, "Data is not information, information is not knowledge, knowledge is not understanding, understanding is not wisdom", reaching wisdom passes through the availability of both data and knowledge.

The storage infrastructure, and specifically the Triple Stores are a cornerstone to satisfy these needs. This pushed researchers from diverse communities (e.g., Semantic Web, Core Databases, Information Systems Infrastructures) to propose a large collection of triple stores. Some are built on top of existent solutions (like RDBMS), others are built from scratch using customized storage implementations (e.g., clustered indexes, adjacency lists). They all have in common the use of physical optimization strategies that are specific to each system. These strategies usually ignore the underlying graph-based logical schema of KGs. This is far from the optimizations based on logical structures broadly studied in relational databases. Within these strategies we find data partitioning in the first line.

Data partitioning grants managers means to enhance the performance, manageability, and availability of centralized triple stores by splitting the data in parts (fragments). Still, data partitioning in centralized triple stores has not had its rightful place in the design of these systems. To scale to large KGs, many parallel and distributed triple stores came to light. In these systems, data partitioning becomes a mandatory stride. Many systems offer managers the possibility to control the partitioning of their data (opaque systems) while others delegate this task to a host like a cloud provider (transparent systems). For the former systems, there are several partitioning modes (hashing, graph partitioning, semantic hashing, etc.). They are applied at the triple-level distributing the data at its finer granularity. Recently, there has been a research boom to study the performance impact of these data placement strategies in triple stores [START_REF] Janke | Data placement strategies that speed-up distributed graph query processing[END_REF][START_REF] Akhter | An empirical evaluation of RDF graph partitioning techniques[END_REF].

The need to address the problem of RDF data partitioning is evident and crucial for performance and manageability issues. Our vision encourages the reuse and the reproduction of strong points of data partitioning applied in different database generations (relational, object-oriented, XML, data warehouses, etc.) that preceded RDF databases. To do so, it is necessary to make the partitioning environment explicit, identifying its strengths, evolution, and how their main elements can be reused in the context of KGs. We surveyed the data partitioning problem to establish the bases that will guide the development of our partitioning framework. It is important to notice that reproducibility is the hallmark of scientific research. A recent initiative from Information Systems Journal (Elsevier) identified that much of the research published in computer science journals and presented at conferences cannot be readily and fully reproduced. This motivates the Editors of this journal to establishing a new article type: the Invited Reproducibility Paper 14 . This reproducibility concerns only experiments. At the same time, several nice conceptual ideas and visions already published and implemented in systems/products in the last decades are not well reproduced in current trends in the database world. The wealth of data partitioning findings in the traditional databases in terms of availability of large body of partitioning techniques, algorithms, data structures, optimizations, deployment (in commercial and open-source DBMSs), advisors, connection with other optimization techniques (such as indexes, materialized views, etc.), fragment manipulation languages, adaptation for different database generations, and the large number of Ph.D. theses (a quick search using "Fragmentation Bases de Données Informatique" on theses.fr which is a Website that lists all Ph.D. thesis defended in France since 1985, we find around 875 theses). By this thesis, we attempt to promote the vision of the reproduction of findings of data partitioning in the context of triple stores.

This vision is embedded in our RDF data partitioning framework for the contexts of centralized, distributed, and parallel triple stores. The framework follows the paradigm of being outside the DBMS so it can be reused, improved, and extended as we will discuss later. Our framework works using a logical representation of the fragments. We define a set of logical entities that allow partitioning KGs independently on the storage representation of each system. Finally, we show how this framework was introduced into centralized and distributed triple stores. We conducted several experiments that showed some scenarios that demonstrate when these partition strategies are most efficient. Our contributions are summarized as follows.

• Data partitioning survey

We provide a complete survey of the partitioning problem in relational databases. We have cleared the foundation of the problem and its evolution over all the database generations. We characterized the problem thanks to a star-schema like the representation of data partitioning defining 10 main dimensions comprising: (1) Partitioning type, (2) Algorithm, (3) Main objective, (4) Adaptability, (5) Mechanism, (6) Cost model, (7) System element, (8) Platform, (9) Constraints and (10) Data model. These dimensions make the elements of the partitioning environment explicit and they are used to classifying the surveyed works. Secondly, since we are dealing with Knowledge Graphs we cannot disregard how graphs have been treated in the literature. We surveyed their logical representation, storage, and querying strategies of this data model. Then, we focus on RDF systems giving some background concepts and an overview of the current storage and partitioning strategies applied by triple stores. Thanks to both surveys, we found that the study of data partitioning in triple stores has not followed the same philosophy as in relational databases. The partitioning environment in RDF datasets is still un-explicit. Several methods exist to partition an RDF dataset, but they are hardly reproducible and extensible to other systems. This is due to the dependency of these methods on the physical storage structure of triples on a given triple store.

• Foundations to RDF Logical Partitioning Drawing on the lessons learned from the partitioning environment in relational databases, our first concern was the definition of logical partitioning structures to partition a KG. These structures should (i) offer more expressiveness than single triples, (ii) represent the overall structure of the data and, (iii) maintain their graph connectivity. In this thesis, we formally defined these structures. We distinguish two structures: forward graph fragments -→ Gf and backward graph fragments ← -Gf . They harmonize with the notions of horizontal and vertical partitions in the relational model, respectively. However, they have been defined on graph abstractions and not on a table. We proved that the partitioning process of a KG in graph fragments enforces the correctness rules of fragmentation [ ÖV11]. Also, graph fragments are independent of the storage structure of a triple store (table-or graph-driven). Besides, since they are built from the original KG and not from the storage representation of the triples, they manage to keep the inherent graph structure of a KG.

• RDFPartSuite Framework

We define a common partitioning framework for centralized and parallel triple stores. Our framework follows the paradigm of outside the DBMS (outside the Triple Store in our case). This enables users to reuse and extend this framework independently from a given triple store. The framework is composed of three main modules: fragmentor, allocator and dispatcher. The first module partitions a given dataset in fragments according to their logical representation in forward or backward graph fragments. This logical representation is sent to the target centralized triple store (if the systems are centralized) or to the allocator module (in distributed systems). The allocator assigns the fragments to the different sites of the system according to data-driven algorithms. This module outputs an allocation schema that is sent to the dispatcher in charge of distributing the triples according to this schema. Finally, our framework offers managers support tools. These tools consider the manager's expertise level to design a partitioning scheme. For beginners, it offers a partitioning advisor that automatically chooses the partitioning scheme. If the manager is an expert, a declarative partitioning language is given to partition a KG manually.

• RDFPartSuite in Action

Our framework was first incorporated to the loading module of a centralized triple store. The chosen system was the centralized triple store RDF QDAG [KMG + 20], currently developed in our LIAS Laboratory. We showed the scalability of the fragmentor module and compared the performance of non-partitioned centralized stores with respect to this system leveraging data partitioning. Next, we used our framework to load the data to a distributed triple store (gStoreD[PZ Ö+ 16]). We compared the query performance for configurations in which the data are loaded as forward and as backward graph fragments in this system. Our experimental study revealed that the use of these structures in triple stores not only grants designers more freedom, but also ensures the scalability and good performance for certain queries.

Final Takeaways

In this section, we share our own experiences that led to the establishment of our vision that was materialized in our partitioning framework. Our aim is to give future researchers an overview of the process followed in the development and implementation of our framework so they can reuse/improve their future works with our feedback. The need to create a partitioning framework arose after exploring the papers and source codes of several triple stores. Our aim was initially to reproduce and learn how the systems that had been tested in several surveys (e.g., [START_REF] Abdelaziz | A survey and experimental comparison of distributed SPARQL engines for very large RDF data[END_REF][START_REF] Kaoudi | RDF in the clouds: a survey[END_REF]) works. Many of these systems had not been maintained for a long time and they have been barely used in real implementations. Testing every single system was impossible since the number of existing triple stores is huge. This because usually improving existent triple store systems can be more expensive than starting everything from scratch. At this point, we questioned why this has been the case for triple stores and not for RDBMS? Certainly, there are many RDBMSs on the market now, however studying their optimization strategies remains constant to the relational model. We decided to reproduce a similar methodology for the design of triple stores. We focused on data partitioning because recently this optimization strategy has gained momentum in centralized and especially in parallel and distributed triple stores. Our goal was then, to overview in detail the main components of data partitioning to reuse them in the context of triple stores. We seek to imitate the methodology used to partition RDF data and not exactly the implementations used by RDBMS. Our idea is to take advantage of so many lessons learned over the years for the creation of partitions in the relational model and incorporate them into the creation of our framework. Our framework can be improved and extended. The main perspectives of our work are detailed in the following section.

Perspectives Extensions to our framework

Calibrator component

The calibrator component would be in charge of monitoring the different schemes generated by our framework using data-driven approaches. This calibration is performed by the exploitation of workloads running on the target store. This allows us to have a mixed approach combing the connectivity of the data and workloads while designing our stores. We use the workload to boost the quality of the initial allocation. This task could be divided in two sub-modules: workload handler and smart re-allocator. In the following, we give a brief overview of how both modules could work.

Workload handler : This sub-component would be in charge of measuring the closeness between the graph fragments based on the information available on the workload. We could adapt some of the workload-aware partitioning algorithms of the state of the art. Let us for example describe how we could use the techniques of [START_REF] Hose | WARP: workload-aware replication and partitioning for RDF[END_REF] and [START_REF] Galárraga | Partout: a distributed engine for efficient RDF processing[END_REF] to extract the most relevant information from a representative workload. This is illustrated in Figure 4.19 in which a query (Fig. 4.19a) is normalized using the techniques of [START_REF] Hose | WARP: workload-aware replication and partitioning for RDF[END_REF]. To measure the connectivity between graph fragments in the workload we can detect a set of candidate graph fragments for each part of the query. In the example shown in Fig. 4.19b we can calculate the interactions between the candidate fragments. This information is transmitted to the following module, that adjusts the cost model used by the allocator component.

SELECT ?a ?m ?z WHERE { ?a :type :Airliner . ?a :nbMotors "4". ?a :hasModel ?m . ?a :manufacturer ?z . ?z :has_seat :France . ?z :office_in ?t . FILTER regex(?t, "Toulouse") } (a) Original query

--→ Gf A { -→ Gf 11 , -→ Gf 12 , -→ Gf 13 } --→ Gf B { -→ Gf 21 , -→ Gf 22 }
Normalized query: Smart re-partitioner this component considers the former data-driven partitioning proposed by the allocator and the insights from the workload handler to determine if a fragment should be transferred or replicated to a given site. To find a solution to the fragment re-allocation problem, one of the following actions must be performed on each fragment (V i ):

Ω1 :type :Airliner Ω1 :nbMotors Ω2 Ω1 :hasModel Ω3 Ω1 :manufacturer Ω4 Ω4 :has_seat Ω5 Ω4 :office_in Ω6 -→ Gf A -→ Gf B (b) Query normalization
• Replicate: the fragment V i is replicated to as many sites in S as long as the replication, space availability and imbalance constraints are met.

• Move: this action moves the fragment V i from its former site S j to another site in the network.

• Keep: this action maintains the fragment in its original location S j .

The interaction between both sub-components is illustrated in Figure 4.20.

Other allocation rules

Currently, the allocator component of our framework implements data-driven algorithms to place graph fragments to the sites of a distributed system. This strategy is based on the inherent connectivity of the triples. However, we can imagine other data-driven rules to extend our framework. For example, for datasets containing geospatial information. Triple stores have been recently extended for the efficient management of spatial data. Thus, one may want to place graph fragments together according to geospatial variables. Another data-driven strategy to be considered is that useful for triple stores that support reasoning. This allocation strategy should consider the semantical closeness of their fragments with respect to a given set of ontologies. This will not only leave connected triples on the graph in the same site, but also triples that are semantically close but not directly with an arc.

Consideration of other optimization techniques

For the moment, our framework is used to partition KGs in triple stores. We are aware that data partitioning is just one of the pool of optimizations strategies to consider while designing efficient storage systems. Considering the impact of data partitioning and its interaction with indexes, replicas, materialized views, etc. is the next step. Following what happened in RDBMS, partitioning advisors proposed first a partitioning scheme that is tuned by subsequent optimization structures (e.g., indexes) [START_REF] Rimma | Automated partitioning design in parallel database systems[END_REF]. Our framework can be used as a baseline for other components in charge of proposing indexes or replications of some fragments.

Implementation to transparent triple stores

We have introduced the notion of data transparency associated with data partitioning. In transparent distributed triple stores, the partitioning task is delegated to the host where the system is deployed. What if the host offered clients more visibility and control to partition their own data? Incorporating our partitioning framework into existent distributed frameworks should be considered. This need is evidenced, for example, by the overheads suffered by many Hadoop-based systems due to the high communications costs of MapReduce joins [START_REF] Abdelaziz | A survey and experimental comparison of distributed SPARQL engines for very large RDF data[END_REF]. Native Ces systèmes ont été spécialement conçus pour traiter les données RDF. Deux stratégies de stockage principales sont utilisées dans ces systèmes: les stratégies basées sur une structure d'arbre et les listes d'adjacence. Le système RDF-3X [START_REF] Neumann | RDF-3X: a risc-style engine for RDF[END_REF] est le système le plus représentatif dans la première catégorie. Il stocke les triplets dans des arbres B+Tree. Pour améliorer les performances, il stocke toutes les permutations des colonnes (par exemple, SPO, OPS, PSO). Les systèmes de la deuxième catégorie utilisent des implémentations physiques de graphes tels que des listes d'adjacence. Les optimisations de ces systèmes dépendent fortement des structures de mise en oeuvre du graphe.

Résumé

Triple Stores distribués et parallèles Pour assurer la scalabilité, il existe une grande nombre de triple stores distribués et paralleles. Le cycle du développement d'un tel système peut facilement s'inspirer de celui utilisé pour la conception des bases de données traditionnelles. Le partitionnement des données est une condition préalable pour assurer le déploiement, l'efficacité, la scalabilité et la tolérance aux pannes de ces systèmes [ ÖV11]. La sensibilité du partitionnement des données RDF et son impact sur les performances dans les triple stores ont été récemment discutés dans un article présenté lors d'un workshop de SIGMOD 2020 [START_REF] Janke | Data placement strategies that speed-up distributed graph query processing[END_REF]. Nous classons ces systèmes en trois groupes: homogènes, hétérogènes et basés sur le cloud. Les systèmes homogènes et hétérogènes sont généralement implémentés dans des architectures master/slave. Les premiers clonent un triple store centralisé sur les noeuds d'un système distribué tandis que le second utilise des triple stores différents en chaque noeud. Dans les systèmes basés sur le cloud, le stockage et l'accès aux données sont délégués à l'hôte. Plusieurs modes de partitionnement pour les données RDF ont également été implémentés (par exemple, Hashing, Partitionnement de graphes et Hashing sémantique.

De la présentation ci-dessus, y compris les triple stores centralisés, distribués et parallèles, trois leçons principales sont tirées:

1. Une forte demande des gestionnaires et des consommateurs pour développer des triple stores en exploitant l'opportunité technologique en termes de logiciels et de matériels.

2. Toute initiative visant à utiliser le partitionnement des données dans des triple stores devrait bénéficier de la grande expérience dans les bases des données traditionnels. Cette expérience doit être capitalisée pour augmenter la réutilisation et la reproductibilité des résultats du partitionnement des données dans les données RDF.

3. La nécessité de développer un cadre de partitionnement de données RDF pour les gestionnaires désireux de concevoir des triple stores centralisés et parallèles.

Notre vision, objectifs et contributions

Dans cette thèse, nous visons d'abord à expliciter le problème du partitionnement pour les bases de données traditionnelles. Nous privilégions l'utilisation du partitionnement de données dans la conception de triple stores en réutilisant ses points forts. Notre vision est de construire un cadre de partitionnement basé sur l'analyse de forces et de contraintes des deux univers (bases de données traditionnels et KG). Pour cela une étude approfondie du partitionnement des données proposé dans le contexte des bases de données traditionnelles centralisées/parallèles/distribuées est nécessaire.

Les objectifs que nous avons fixés dans notre thèse sont:

(i) La définition d'un cadre commun pour les triple stores centralisés et parallèles avec des composants complets mettant en oeuvre notre vision.

(ii) La proposition d'algorithmes efficaces de partitionnement pilotés par les données définis sur des structures logiques définis préalablement.

(iii) Montrer la faisabilité du framework en l'instanciant dans un triple store centralisé et distribué.

(iv) Mise à disposition d'outils pour les concepteurs, y compris un langage de manipulation de fragments et un assistant automatique de partitionnement, basés sur des fragments logiques.

Les principales contributions de notre travail sont:

• Avec la motivation d'augmenter la reproduction et la réutilisation des résultats importants du partitionnement des données dans les bases de données centralisées et parallèles traditionnelles, nous proposons une étude complète de ce problème couvrant les générations importantes du monde des bases de données.

Fondements du Partitionnement des Données

Dans les techniques d'optimisation les plus étudiées dans les bases de données, le partitionnement des données occupe une place très importante non seulement pour son efficacité à améliorer les performances de la base de données, mais aussi parce que dans les architectures parallèles et distribuées à grande échelle modernes, c'est un pas obligatoire. Les notions de partitionnement de données ont été introduites dans les années soixante-dix en [HS75] peu de temps après la définition des index de base de données.

Dans les bases de données relationnelles, le partitionnement consiste à diviser ce qui est logiquement une grande table en morceaux physiques plus petits. Comme pour les index, le problème du partitionnement des données a été couvert dans toutes les générations de bases de données: deductives [Spy87, NH94], orientée objet [START_REF] Bellatreche | Horizontal class partitioning in object-oriented databases[END_REF] et entrepôts de données [START_REF] Stöhr | Multi-dimensional database allocation for parallel data warehouses[END_REF]. Pourtant, contrairement à d'autres stratégies d'optimisation et avant l'introduction de techniques de partitionnement dynamique, des partitions sont créées lors de la déclaration des tables de base de données. Cette fonctionnalité distingue le partitionnement des données des autres techniques d'optimisation qui peuvent être créées à la demande pendant l'exécution de la base de données. Recréer des partitions après sa définition est coûteux et peu pratique.

Nous avons caractérisé le problème de partitionnement en fonction de son:

• Maturité: le problème existe presque depuis la définition des premiers systèmes de base de données et a été largement exploré,

• Couverture: il a été implémenté pour toutes les générations de bases de données,

• Évolution: il a été adapté aux différentes architectures, besoins et contraintes, et

• Complexité: trouver un schéma de partition optimal doit considérer plusieurs alternatives et parfois des fonctions objectives mutuellement exclusives.

Dimensions de partitionnement

Nous avons modélisé l'environnement de partitionnement à l'aide d'un schéma en étoile illustré dans la Figure • Partitionnement de liste: cette stratégie divise une table selon une liste de valeurs discrètes pour la clé de partitionnement d'une colonne.

• Partitionnement hash: cette modalité décompose les données en appliquant une fonction de hachage aux attributs de partitionnement.

Un autre mode de partitionnement horizontal, appelé composite, combine les modes de partitionnement simple (par example, plage-hash, hash-liste). Enfin, le partitionnement horizontal dérivée permet de partitionner une table en exploitant une relation parent-enfant existante établie selon une clé étrangère entre deux relations [START_REF] Bellatreche | Referential horizontal partitioning selection problem in data warehouses: Hardness study and selection algorithms[END_REF].

Objectif principal

Le problème du partitionnement optimal des données sur un système de base de données centralisé, distribué ou parallèle pourrait à première vue sembler le même. Même si la sortie attendue est un ensemble de partitions horizontales ou verticales, l'objectif principal de créer chaque partition est très différent selon les exigences du système. Nous classons les objectifs de partitionnement comme suit: (i) Temps de réponse, (ii) Concurrence, (iii) Maintenance and (iv) Combiné.

Mécanisme

Cette dimension fait référence aux moyens utilisés par les techniques de partitionnement pour atteindre les objectifs mentionnés précédemment. Il est composé de deux alternatives: le clustering et le declustering.

Contraintes

Les algorithmes de partitionnement cherchent à optimiser une fonction objective par rapport à certaines variables en présence de contraintes. La liste suivante résume les contraintes les plus courantes: (i) La taille maximale/minimale de la partition, (ii) Nombre de partitions, (iii) Redondance, et (iv) La charge de requêtes.

Plateforme

Cette dimension considère les trois types d'architectures de base de données: (i) Centralisée, (ii) Distribuée et (iii) Parallèle.

Élément du Système

Dans cette dimension, nous considérons si l'élément matériel ciblé par l'approche de partitionnement. Parmi les composants, nous pouvons mentionner: mémoire primaire et secondaire, réseau local, processeur.

Adaptabilité

Cette dimension classe les stratégies de partitionnement en statiques et dynamiques. La différence dépend si le partitionnement décrit la procédure qui est effectuée lors de la déclaration de la base de données et qu'elle ne change jamais, ou s'il inclut décrit les stratégies effectuées après l'exécution de plusieurs charges de travail et que le système est capable d'adapter son partitionnement.

Modèle de données

Dans cette section, nous classons les stratégies de partitionnement selon le modèle de données utilisé pour représenter logiquement les données. Nous incluons dans cette catégorie le modèle relationnel et les modèles directement dérivés de celui-ci. Nous incluons alors: (i) Modèle relationnel, (ii) Orientée objet, (iii) Déductive and (iv) Dimensionnelle.

Partitionnement dans les plates-formes récentes à grande échelle

Conclusion

Avec le déluge de données et l'explosion des architectures de déploiement, le partitionnement des données est devenu la une technique que les acteurs de la base de données (concepteurs, administrateurs, architectes, analystes, étudiants, chercheurs) doivent connaître en détail. Le partitionnement des données a été étudié à partir de l'arrivée de bases de données évoluant avec ses générations. Dans ce chapitre, nous avons cherché à donner un aperçu historique du problème de partitionnement de données, de son historique, de son évolution, de ses contraintes et de son comportement après l'arrivée de chaque nouvelle architecture et plateforme de déploiement de données. Pour ce faire, nous avons proposé une base de partitionnement de données comprenant: des définitions et des types implicites et explicites, ainsi que des dimensions de partitionnement de données comprenant: (1) Type de partitionnement, (2) Algorithme, (3) Objectif principal, (4) Adaptabilité, (5) Mécanisme, (6) Modèle de coût, (7) Élément Système, (8) Plateforme, (9) Contraintes et (10) Modèle de données. Ces dimensions offrent une représentation graphique (comme un schéma en étoile) du partitionnement des données. Pour chaque dimension, nous avons décrit ses caractéristiques et représenté ses éléments et ses étiquettes.

Nous nous sommes concentrés sur la présentation de l'état de l'art du partitionnement de données dans des bases de données relationnelles et d'autres modèles proches dans des architectures centralisées, distribuées et parallèles. Nous avons cité les travaux qui ont conduit à une définition explicite du problème du partitionnement et montré le développement progressif des principales formes de partitionnement de données. Par la suite, nous avons exposé les algorithmes, stratégies et heuristiques introduits pour partitionner la base de données selon un ensemble de dimensions précédemment définies. Nous offrons un examen complet sur le partitionnement des données et peut être utilisé comme un flambeau pour les lecteurs et les acteurs de travailler dans ce problème passionnant et durable. Enfin, nous montrons comment le problème a évolué dans les plates-formes cloud actuelles et comment il s'est adapté pour faire face aux données à grande échelle. Dans le chapitre suivant, nous montrons comment le problème a été traité spécifiquement pour le traitement de graphes.

Les Données Orientée Graphe : Représentation et Traitement

Dans le chapitre précédent, nous avons détaillé le problème de partitionnement dans les bases de données relationnelles. Nous avons montré son évolution et comment elle a été adaptée aux modèles de données orientés objet, déductifs et multidimensionnels. Nous avons expliqué le développement de plates-formes à grande échelle et comment elles se sont adaptées au besoin récent de gérer efficacement les grandes volumes de données. Cependant, les modèles de données discutés dérivent directement de la conception relationnelle si largement étudiée. Dans ce chapitre, nous détaillons un modèle de données qui permet de décrire des relations plus complexes. Plus précisément, des modèles orientés graphes représentant les données sous forme de graphe dont la manipulation est exprimée sous forme d'opérateurs de graphes. Ils ont pris de l'ampleur au cours des dernières années avec le développement du Web sémantique, des réseaux sociaux et avec l'augmentation de la capacité de capturer des données provenant de différentes disciplines telles que la Biologie et le Transport. Dans ces applications, l'interconnectivité des données est une caractéristique clé et elle est aussi importante que les données elles-mêmes. La modélisation des données sous forme de graphe permet une manière plus naturelle de gérer ces applications. Dans ce chapitre, nous commençons à donner plus d'informations sur le modèle de données de graphes en général. Ensuite, nous nous concentrons sur le modèle RDF introduit pour représenter les données dans le Web sémantique en donnant quelques définitions principales et en décrivant les approches de stockage et de traitement les plus pertinentes.

Modèles de bases de données orientées graphes

La recherche autour des modèles de base de données orientées graphes n'est pas nouvelle, en fait, elle a connu un pic à la fin des années 1980 début des années 1990, mais elle a été éclipsée par le développement de structures arborescentes comme la modélisation XML dans les sites Web de première génération. L'utilisation des graphes en informatique remonte au début des bases de données relationnelles au milieu des années 1970 dans lesquelles des modèles de graphes ont été proposés pour étendre les informations stockées dans des bases de données avec des réseaux sémantiques (d'abord défini dans [START_REF] Robert | Semantic networks: their computation and use for understanding English sentences[END_REF]).

Structures de données, langages et traitement des requêtes

Les modèles de données orientées graphes représentent les données sous forme de graphes fournissant des opérations de traversée efficaces pour les interroger et les analyser. Les graphes sont composés d'entités représentant quelque chose qui existe en tant qu'unité unique ou composée et de relations établissant des connexions entre deux entités ou plus. Quelques structures de données utilisées pour modéliser les entités et les relations dans ce modèle sont: la matrice d'adjacence, la liste d'adjacence, la liste de bord, le compressed sparse row(CSR) et les indexes complexes.

Parmi les études de recherche, il existe plusieurs travaux sur les langages de requête. Ces travaux présentent des collections d'opérateurs et de règles d'inférence pour manipuler et interroger la structure de données orientées graphes. Compte tenu du grand nombre d'approches disponibles et de la portée de cette thèse, nous ne mentionnons dans cette section que les langages de requête de graphes les plus récents et les plus populaires. On retrouve alors: SPARQL, Cypher, Gremlin, Oracle PGQL et G-Core.

Les stratégies de traitement des requêtes dépendent du type de requête ciblé par l'application. Ces stratégies peuvent être aussi simples que de trouver les voisins directs d'un noeud ou de trouver des graphes isomorphes en fonction d'un modèle de requête, ou des chemins de traversée plus complexes utilisés dans des algorithmes tels que PageRank.Nous avons donné un aperçu des stratégies de traitement de graphes qui sont au coeur de plusieurs langages de requête. Une description détaillée de chaque algorithme et des stratégies plus complexes traitant de l'accessibilité se trouve dans [START_REF] Bonifati | Querying Graphs[END_REF].

Partitionnement de graphes

Au cours des dernières années, les données stockées sous forme de graphes ont considérablement augmenté. Par exemple, la taille du graphe de données Facebook compte un milliard de noeuds et environ deux cents milliards d'arêtes [START_REF] Lenharth | Parallel graph analytics[END_REF]. Des solutions distribuées et parallèles ont vu le jour pour répondre à la demande de stockage et de traitement de graphes efficaces. Dans ces systèmes, couper le graphe en petits morceaux est une étape fondamentale pour permettre le parallélisme. Le partitionnement de graphes doit trouver un équilibre entre les objectifs suivants:

• Minimiser les coûts de communication, et

• Maximiser l'équilibre de charges.

Bases de données orientées graphes

Dans les sections précédentes, nous avons caractérisé les dimensions du modèle de base de données orientées graphe: i) Structure de données logique, ii) stockage de données, iii) langages de requête et de manipulation, et iv) stratégies de traitement des requêtes. Nous utilisons ces dimensions pour classer les systèmes les plus populaires. Nous classons les approches en deux grands groupes: natif et non-natif. Le premier groupe est constitué de systèmes spécialement conçus pour stocker et interroger des données représentées sous forme de graphes. En revanche, les approches non natives sont construites sur des plates-formes existantes telles que les bases de données relationnelles, les systèmes clé-valeur et d'autres systèmes comme par example le cloud.

Le Resource Description Framework (RDF)

Le Resource Description Framework (RDF) [START_REF] Lanthaler | RDF 1.1 concepts and abstract syntax[END_REF] a été largement accepté comme modèle de données standard pour l'échange de données issues du Web. RDF est suffisamment flexible pour faciliter l'intégration des données avec différents schémas. Le modèle utilise des triplets composés d'un sujet, d'un prédicat et d'un objet (s, p, o) comme structure de données abstraite de base pour représenter l'information. Un ensemble de tels triplets forme un graphe de connaissances (KG). Les noeuds représentent des IRIs (International Resource Identifiers), des noeuds vides (ressources non spécifiées) ou des littéraux. Les arcs caractérisent une ressource en reliant les noeuds sujet et objet par un prédicat. Ce chapitre classe les systèmes les plus représentatifs en natifs et non natifs. Nous nous concentrons ici sur les stratégies de partitionnement appliquées par la plupart de ces systèmes.

Partitionnement des données RDF

Pour faire face à l'augmentation des données RDF disponibles et à la nécessité de les traiter efficacement, les systèmes RDF ont eu recours à des techniques de distribution et de traitement parallèle largement explorées dans les bases de données relationnelles. Dans les systèmes RDF distribués, nous trouvons deux groupes, les systèmes fédérés et les systèmes en cluster qui sont décrits comme suit:

• Systèmes fédérés: ces systèmes exécutent des requêtes SPARQL sur plusieurs SPARQL endpoints 16 . De tels systèmes nécessitent d'effectuer l'intégration de données à la volée de plusieurs sources RDF hétérogènes. Les systèmes fédérés sont hors du champ de notre étude.

• Systèmes en cluster : ces systèmes distribuent les données entre différents noeuds qui forment une seule solution de stockage. Depuis plusieurs années, un grand nombre de systèmes distribués offrant un traitement efficace des données RDF ont vu le jour. Nous concentrons notre étude sur ce type de systèmes.

Nous divisons le processus de partitionnement en trois phases: Fragmentation, Allocation et Réplication. Ensuite, nous détaillons les entrées, les sorties et les algorithmes sur chacune de ces étapes.

• Fragmentation: Le processus de fragmentation consiste à définir l'unité de fragmentation à allouer sur les sites du système distribué. + Intégration flexible de nouvelles données.

+ SGBD-indépendant: le partitionnement est indépendant du système de gestion de base de données.

-SGBD-dépendant: le système d'exécution et la stratégie de partitionnement sont couplés.

+ Partitionnement au niveau logique: Indépendamment du modèle physique utilisé pour stocker les données (par exemple, NSM, DSM).

-Dépend du modèle de stockage physique (par exemple, basé sur les triplets).

+ Les langages de définition de base de données natifs prennent en charge la déclaration de partitions horizontales.

-Partitionnement effectué de manière transparente pendant la phase de chargement.

+ Plusieurs conseillers de partitionnement automatique sont disponibles pour aider le concepteur à créer des partitions.

-Le partitionnement des données est principalement imposé par le triple store.

Les stratégies de partitionnement adoptées par les systèmes RDF présentent également plusieurs avantages. Par exemple, la plupart des approches permet l'intégration des données. En effet, L'un des atouts de RDF est sa flexibilité pour intégrer des données avec différents schémas sous-jacents. Le modèle relationnel, en revanche, est souvent trop rigide pour gérer les données sans donner un schéma initial. Certaines approches de RDF ont essayé de modéliser les données RDF dans un schéma de base de données relationnelle avant de stocker les données dans un SGBDR. Cependant, comme le démontrent plusieurs études expérimentales, les systèmes relationnels ne sont pas optimaux lorsqu'ils traitent des requêtes très complexes. Les forces et les inconvénients (principalement mutuellement exclusifs) des deux modèles de données sont résumés dans le tableau précédent.

Nous considérons nécessaire de fournir des outils pour les concepteurs de systèmes RDF imitant le confort offert dans les systèmes de bases de données relationnelles. Cela nous a amené à fixer l'objectif de cette thèse qui consiste à proposer un framework de partitionnement de données RDF basé sur des structures logiques implicites. L'élaboration de ce framework (RDFPartSuite) sera abordée dans les prochains chapitres.

Partitionnement logique des triplets RDF

Nous nous appuyons sur les enseignements tirés du modèle relationnel dans lequel le partitionnement des données est effectué à un niveau logique, indépendamment de l'approche de stockage. Dans ce qui suit, nous introduisons une couche logique au processus de partitionnement des triple stores distribués homogènes. Nous commençons à donner un aperçu de cette couche logique en comparant notre stratégie à l'état actuel de l'art. Ensuite, nous définissons formellement les entités logiques et proposons des algorithmes pour regrouper les triplets RDF en fragments de graphes. Ensuite, nous discutons de l'utilisation de ces fragments comme structures de stockage physique et formalisons leur problème d'allocation. Enfin, nous présentons un exemple complet des heuristiques de création et d'allocation définies dans ce chapitre.

La conception d'un système distribué implique la distribution de données et de programmes sur les sites du réseau informatique dans lequel le système est déployé. Nous nous concentrons sur le problème de la distribution des données en cherchant à trouver et à allouer les unités de distribution optimales. Pour rendre ce processus plus compréhensible, la distribution de données est subdivisée en [ ÖV11] en deux sous-étapes. Le premier, nommé fragmentation, détermine les unités de distribution puis l'étape d'allocation qui place les fragments sur les sites du réseau.

La phase de conception déclarant explicitement les entités de haut niveau comme dans les bases de données relationnelles ne se produit pas dans les systèmes RDF. Au contraire, les données sont organisées dans un modèle sans schéma en utilisant des triples comme unités de distribution. Pourtant, les données relatives à la même entité de haut niveau peuvent être facilement dispersées dans le lot de données. Il n'y a pas de consensus sur la façon dont les données devraient être fragmentées et allouées. Actuellement, les stratégies de partitionnement dépendent fortement du système principal utilisé pour stocker les données. Il y a eu des efforts pour ajouter explicitement un schéma de hiérarchie de classes à RDF via des annotations (par exemple, schéma-RDFS et ontologies). De plus, comme indiqué dans [START_REF] Pham | Deriving an emergent relational schema from RDF data[END_REF], i) les entités d'un seul ensemble de données peuvent être décrites avec plusieurs ontologies, ii) toutes les entités d'un ensemble de données ne sont pas annotées avec les mêmes métadonnées et, iii) tous les modèles de requêtes SPARQL ne les considèrent pas. L'utilisation de ces annotations dans l'identification des entités implicites n'est pas très efficace.

Notre stratégie identifie des entités en utilisant les ensembles de caractéristiques [START_REF] Neumann | Characteristic sets: Accurate cardinality estimation for RDF queries with multiple joins[END_REF]. Un ensemble de caractéristiques regroupe d'abord les triplets par sujet et collecte ensuite les données en fonction de leurs prédicats. Cette stratégie ne repose pas sur des annotations pour identifier les entités et elle permet de considérer certaines corrélations entre les triplets. Nous avons réutilisé cette notion pour détecter les entités décrites ci-dessous. Nous considérons nécessaire de fournir des outils pour les concepteurs de systèmes RDF imitant le confort offert dans les systèmes de bases de données relationnelles. Cela nous a amenés à fixer l'objectif de cette thèse qui consiste à proposer un framework de partitionnement de données RDF basé sur des structures logiques implicites. L'élaboration de ce cadre sera abordée dans les prochains chapitres.

Fragments de graphes

Dans cette section, nous proposons de regrouper les données inspirés du partitionnement relationnel. Dans les bases de données relationnelles, une entité (une table) est partitionnée au niveau de l'instance (horizontale) ou de l'attribut (verticale). Considérant qu'en RDF il n'y a pas d'étape de conception comme dans les bases de données relationnelles, notre proposition cherche à détecter les entités implicites dans un jeu de données RDF.

L'ensemble de caractéristiques proposé dans [START_REF] Neumann | Characteristic sets: Accurate cardinality estimation for RDF queries with multiple joins[END_REF] permet de regrouper les instances d'une même entité de haut niveau pour former une partition. Nous définissons deux types d'entités: par instances et par attributs décrites ci-dessous.

Regroupement par instances

Pour rassembler les triples d'une même entité de haut niveau, nous regroupons en premier lieu les triples par ses sujets. Ces structures sont nommées étoiles de données en avant. Nous définissons d'abord les fonctions f s (t) → s, f p (t) → p and f o (t) → o renvoyant le sujet, le prédicat et l'objet d'un triplet RDF t = ⟨s, p, o⟩ respectivement. Ces deux fonctions sont appliquées dans certaines des définitions du présent chapitre. Une étoiles de données en avant rassemble toutes les propriétés associées à un noeud décrivant une seule occurrence d'une certaine entité. Les entités peuvent être identifiées de manière unique par un sous ensemble de leurs bords émetteurs [START_REF] Neumann | Characteristic sets: Accurate cardinality estimation for RDF queries with multiple joins[END_REF].

Un fragment de graphe avant rassemble des étoiles de données en avant selon leur ensemble caractéristique. Comme il a été mentionné précédemment, nous pouvons caractériser une entité par ses bords émetteurs. Un fragment de graphe avant est une structure logique utilisée pour rassembler les données liées à la même entité de haut niveau. Un fragment de graphe avant peut être utilisé comme structure logique pour distribuer les données.

En général, deux étoiles de données avant appartiennent à la même entité si les étiquettes de leurs bords émetteurs (c'est-à-dire les prédicats) sont les mêmes. Pourtant, parfois deux instances appartiennent à la même entité mais leurs ensembles caractéristiques ne sont pas exactement les mêmes. C'est le cas lorsque deux ensembles de caractéristiques ne diffèrent que par des prédicats non discriminants. Pour éviter de créer un grand nombre de fragments avec des critères de similarité très stricts, nous avons utilisé un score de similarité et un seuil. Pour simplifier la notation, la fonction cs( -→ Gf ) retourne l'ensemble des caractéristiques (qui est l'identifiant) du fragment.

Scores de similarité La fonction de similarité Sim(cs(s i ), cs(s j )) renvoie un score mesurant la similitude des deux ensembles de caractéristiques. Dans son calcul, il peut considérer uniquement la structure de l'ensemble de caractéristiques et leurs relations ou des caractéristiques sémantiques plus complexes. Parmi les fonctions de similarité structurelle, nous trouvons: Supersets, Tf-idf, ou enfin mesures sémantiques (même étiquette et basée sur les ancêtres).

Regroupement par attributs

L'organisation d'un graphe RDF en fragments de graphe avant identifie l'ensemble des instances implicites à l'aide d'ensembles de caractéristiques. Les fragments créés avec cette stratégie ressemblent aux groupes de tuples générés lors du partitionnement horizontal d'une base de données relationnelle. Comme dans le modèle relationnel, fragmenter au niveau instance est utile pour un certain type de requêtes. Par exemple, si la charge de travail est composée de requêtes en forme d'étoile, ce type d'organisation est idéal. Cependant, cette stratégie de fragmentation unique n'optimise pas tous les spectres de requêtes. Le partitionner d'une entité par ses attributs dans le modèle relationnel (partitionnement vertical), optimise d'autres types de requêtes qui impliquent un petit nombre d'attributs. Plusieurs systèmes de traitement RDF utilisent une stratégie similaire, où un fragment est créé pour chaque propriété (par exemple SW-Store [AMMH09], S2RDF [START_REF] Schätzle | S2RDF: RDF querying with SPARQL on Spark[END_REF]). Dans les systèmes relationnels, la stratégie stocke les triplets dans différentes tables par propriété. Cette stratégie est efficace lors de la résolution de requêtes avec quelques attributs, mais souffre de frais généraux lorsque plusieurs prédicats sont joints dans une requête.

Dans cette section, nous décrivons la création de fragments en regroupant les noeuds par leurs propriétés. Au lieu de regrouper strictement chaque propriété dans un fragment différent, nous utilisons la notion d'ensembles de caractéristiques pour regrouper les attributs affectant le même noeud. Nous nommons ces structures fragments de graphe arrière dont la construction est très similaire aux fragments de graphe avant décrits précédemment. Nous commençons par définir un étoile de données arrière qui regroupe un noeud et ses bords entrants. Cette structure permet d'identifier les propriétés qui affectent le même noeud pour les regrouper plus tard avec les mêmes seuils de similarité que pour les fragments de graphe avant.

Des fragments logiques aux structures physiques

L'organisation des données RDF dans des fragments de graphe permet de détecter des entités logiques implicites qui sont utilisées comme unités de distribution dans des triple stores distribués. De plus, l'utilisation de ces fragments logiques comme structures physiques pourrait con-sidérablement améliorer les performances des systèmes centralisés et distribués. Les travaux de Pham et al. dans [START_REF] Pham | Deriving an emergent relational schema from RDF data[END_REF] a montré que le stockage explicite des données à l'aide d'un schéma relationnel découvert automatiquement améliore les performances de Virtuoso [START_REF] Erling | Virtuoso: RDF support in a native RDBMS[END_REF],un triple store non-natif. Organiser les données en fragments de graphe avant et arrière, quelle que soit la structure utilisée pour stocker les données (par exemple, tables, arbres ou listes d'adjacence), évite de scanner l'ensemble de données plusieurs fois avec une seule requête, comme cela est fait par la plupart des systèmes.

Partitionner le graphe RDF en fragments physiques peut éviter d'analyser l'ensemble des données avec chaque requête. Pour ce faire, les partitions pertinentes doivent être identifiées en fonction des informations disponibles dans la requête. Les fragments en avant et en arrière permettent d'identifier les partitions pertinentes en fonction des prédicats de la requête, qui sont connus dans la plupart des requêtes SPARQL.

Combinaison de fragments avant et arrière L'intégration des partitions horizontales et verticales dans le modèle relationnel a été explorée par de nombreux chercheurs dans le passé. Par exemple, les conseillers d'une conception physique de base de données décrite dans [START_REF] Agrawal | Integrating vertical and horizontal partitioning into automated physical database design[END_REF] ou les miroirs fracturés [START_REF] Ramamurthy | A case for fractured mirrors[END_REF]. Pendant ce temps, de nombreux systèmes de traitement massifs proposent des stratégies de réplication non seulement pour récupérer et prendre en charge la tolérance aux pannes, mais pour améliorer le temps de réponse des requêtes. Nous considérons une approche similaire aux miroirs fracturés [START_REF] Ramamurthy | A case for fractured mirrors[END_REF] dans laquelle un système stocke deux copies des données. Une copie organise les données comme des fragments à l'avant et une autre en arrière. Cette configuration est utile en particulier lorsque la charge de travail est inconnue lors de la phase de partitionnement initiale.

Problème d'allocation

L'allocation de fragments est une étape obligatoire dans les systèmes distribués. Le problème consiste à trouver la distribution optimale des fragments sur les sites d'un réseau informatique. Le problème a d'abord été étudié dans le contexte de la distribution de fichiers, puis approfondi dans les bases de données relationnelles où il s'est avéré NP-complet [Esw74, SW85, LY80]. Dans le modèle relationnel, l'optimisation d'une stratégie dépend de divers critères qui sont évalués sur la base de modèles de coûts. Ces modèles estiment les coûts de stockage et de maintenance ainsi que des mesures de performance telles que le débit et le temps de réponse. Étant donné que la complexité du problème ne permet pas de calculer des solutions exactes dans un temps raisonnable, un certain nombre d'heuristiques différentes utilisées en recherche opérationnelle(e.g. knapsack problem [START_REF] Ceri | Optimal file allocation in a computer network: a solution method based on the knapsack problem[END_REF]) ont été appliqués dans le SGBDR. Ces techniques sont aussi utilisées dans les architectures distribuées modernes comme Hadoop, qui, bien qu'elles soient basées sur d'autres paradigmes d'exécution, font face au même problème de distribution des données.

De même, la plupart des triple stores optent pour des solutions de distribution très simples. Ces solutions ne garantissent pas que les triples étroitement liés les uns aux autres seraient dans le même site. Une requête qui fusionne des résultats intermédiaires qui ne se trouvent pas dans la même machine est très inefficace principalement en raison des coûts de transfert élevés. Comme dans les bases de données relationnelles distribuées, nous considérons les coûts de réseau comme le goulot d'étranglement de traitement lors de l'exécution de la requête. Par conséquent, les stratégies visant à améliorer le rendement du système devraient viser à maximiser la localisation des données. Cela peut être réalisé grâce à des techniques d'indexation, de partitionnement et de réplication.

L'utilisation de fragments de graphes comme structures de stockage physique réduit les coûts de disque et permet le parallélisme dans les systèmes centralisés et distribués. Nous considérons l'utilisation de fragments de graphes avant et arrière pour réduire le coût du réseau ces systèmes.

Nous cherchons à allouer des triples au plus près de ses voisins pour élaguer les résultats intermédiaires générés pour une requête localement sur chaque site. Nous supposons que la charge de travail n'est pas disponible et donc nous construisons notre modèle de distribution basé sur la connectivité innée des données. Le problème est soumis à une série de contraintes qui sont le déséquilibre, la réplication et l'espace disque disponible. Heuristique de partitionnement de graphe L'ensemble de fragments de graphe est mappé à un graphe pondéré non orienté, transformant le problème d'allocation en un problème de partitionnement de graphe. Le problème de partitionnement de graphes s'est avéré être un problème très complexe et coûteux en calcul. Cependant, de nombreuses heuristiques efficaces ont été développées comme par example le package METIS [START_REF] Karypis | A fast and high quality multilevel scheme for partitioning irregular graphs[END_REF]. Nous recherchons une partition qui minimise le nombre total de coupes de bord soumises aux mêmes contraintes définies précédemment.

Conclusion

Dans le monde des bases de données relationnelles, le partitionnement des données est identifié depuis longtemps comme une technique clé d'optimisation et de gestion. Le partitionnement des données dans les SGBDR est indépendant de la technique de stockage des données. Dans ce chapitre, nous prétendons reproduire cette stratégie en abordant le problème du partitionnement des données RDF. Contrairement aux techniques de partitionnement traditionnelles, les techniques RDF dépendent de la stratégie de partitionnement et sont difficiles à généraliser pour différents systèmes.

Nous nous appuyons sur la philosophie adoptée par le modèle relationnel pour aborder le partitionnement au sein de systèmes RDF distribués. Précisément, nous avons introduit une couche logique au processus de distribution simplement physique des triplets à un ensemble de sites. Nous formalisons et détaillons les algorithmes utilisés pour créer les entités logiques que nous avons nommées fragments de graphes (Gf . Nos entités étendent la notion de partitionnement par instances et par attributs dans le modèle relationnel et offrent un grand équilibre entre simplicité conceptuelle et intuitive, en plus de son expressivité logique. Nous avons formalisé le problème d'allocation et présenté une heuristique de graphes pour minimiser les coûts de communication.

Notre framework RDFPartSuite en Action

Dans le chapitre précédent, nous avons promu une couche logique pour le partitionnement des données RDF. Nous avons défini un ensemble de structures qui permettent de partitionner les données RDF indépendamment de la façon dont elles sont stockées. Ces structures préservent la nature logique de graphe des données RDF et sont utilisées comme unités de fragmentation. Les fragments logiques sont placés sur les sites d'un système distribué selon des algorithmes pilotés par les données que nous avons également détaillés. Dans ce chapitre, nous introduisons un framework nommé RDFPartSuite. Le framework fournit des fonctionnalités génériques basées sur les structures logiques définies dans le chapitre précédent. Il peut être adapté en fonction des spécifications du gestionnaire (exigences du créateur, triple store, infrastructure disponible, etc.). RDFPartSuite fournit un moyen standard de construire et de déployer des schémas de partitionnement RDF dans un environnement universel et réutilisable. Le framework est composé de trois modules principaux: (i) Fragmenteur: ce composant est chargé de partitionner les triples en utilisant leur représentation logique sous forme de fragments de graphe (c'est-à-dire -→ Gf or ← -Gf ).Les fragments peuvent être construits en utilisant des règles structurelles ou sémantiques.

(ii) Allocateur: ce composant crée un schéma de distribution pour les fragments créés par le fragmenteur. Ce schéma est construit à l'aide des stratégies basées sur les données détaillées précédemment.

(iii) Dispatcher: ce composant envoie les fragments aux sites d'un système distribué suivant le schéma d'allocation produit par l'allocateur. Le dispatcheur charge aussi les données dans le triple store cible.

En plus de ces modules, notre framework intègre un ensemble d'outils d'assistance pour les administrateurs de triple stores. Ces outils comprennent un langage de partitionnement déclaratif, pour fragmenter, allouer et envoyer un graphe de connaissances à un triple store cible. Et, pour les utilisateurs non experts, il fournit un assistant de partitionnement pour les aider à créer un schéma de partitionnement. Nous commençons par décrire comment intégrer notre framework à un triple store centralisé (RDF QDAG [KMG + 20]). Ce système utilise des techniques de partitionnement de données et d'exploration de graphes pour accélérer l'exécution des requêtes. Nous avons également montré comment intégrer notre framework dans un triple store distribué (gStoreD [Z ÖC + 14]). Nous avons réalisé un nombre important d'expériences qui ont montré la faisabilité de nos stratégies de partitionnement, son efficacité et ses limites.

Incorporation au RDF QDAG

Les systèmes de traitement RDF modernes peuvent être distingués en deux groupes. Le premier groupe utilise le modèle relationnel pour stocker les triplets RDF dans des tables. Les systèmes de ce groupe sont plus facilement scalables car ils peuvent utiliser des stratégies d'optimisation telles que les indexes et les partitions disponibles pour les bases de données relationnelles. Malheureusement, les performances de ces systèmes se dégradent rapidement, en particulier lorsqu'il s'agit de requêtes SPARQL complexes. Le modèle relationnel ne convient pas pour gérer les données RDF représentées de manière inhérente sous forme de graphe. Le deuxième groupe comprend des systèmes de traitement RDF maintenant la structure de graphe des données RDF. Ces systèmes stockent les triplets dans des structures de données spécialement conçues pour les stocker. Le problème majeur auquel sont confrontées ces approches est la scalabilité [START_REF] Abdelaziz | A survey and experimental comparison of distributed SPARQL engines for very large RDF data[END_REF][START_REF] Özsu | A survey of RDF data management systems[END_REF]. Ils ne parviennent pas à gérer efficacement l'utilisation de la mémoire principale dans les infrastructures avec des ressources limitées.

RDF QDAG [KMG + 20] il combine les vertus du partitionnement des données dans les systèmes relationnels avec un modèle d'exécution basé sur l'exploration du graphique RDF. Le système prend en charge les requêtes SPARQL Basic Graph Pattern (BGP) ainsi que les opérateurs de caractères génériques, d'agrégation et de tri. Les données dans RDF QDAG sont physiquement partitionnés en fragments de graphe avant et arrière. Il est capable d'élaguer des fragments de graphe non pertinents en utilisant les valeurs des prédicats dans la requête. Cette fonctionnalité permet d'explorer uniquement les fragments dans lesquels une correspondance est susceptible d'être trouvée. Comme mentionné précédemment, l'exécution de la requête dans ce système est basée sur l'exploration de graphes. Pour éviter les débordements de mémoire, le moteur d'exécution de RDF QDAG est basé sur le système d'évaluation de requête parallèle Volcano [START_REF] Graefe | Volcano -an extensible and parallel query evaluation system[END_REF].

Ce système est utilisé pour évaluer les temps de chargement, la couverture des données et pour comparer les performances par rapport à d'autres systèmes en utilisant différentes stratégies de partitionnement. Le module de chargement prépare, indexe et partitionne les données RDF brutes reçues en entrée. Il est composé de deux composants principaux: le module de prétraitement et le module de stockage. Le premier transforme les données RDF (stockées dans des fichiers N-Triples, N3 ou Turtle) codant toutes les chaînes de caractères et organisant les données en fragments de graphes avant et arrière. Le module de prétraitement est entièrement codé en Java. Le composant de stockage, codé en C++, prend le fichier affiné codé du Pré-traitement en entrée et configure les données dans les index. Le résultat de cette étape est un ensemble de fichiers binaires utilisés par les modules en charge du traitement de requêtes.

Coûts de chargement L'identification et la formulation de fragments de graphes avant et arrière dans RDF QDAG est certainement un processus plus complexe que celui appliqué par d'autres systèmes chargeant les données directement dans une seule table relationnelle par exemple. L'ensemble de données est lu plusieurs fois pour identifier et encoder les données avec le format souhaité. Dans cette section, nous comparons le temps de prétraitement des systèmes RDF avec différents paradigmes de stockage et d'exécution. Le module de chargement de RDF QDAG était le seul capable de charger tous les jeux de données étant donné la mémoire principale limitée (32 Go). Le système basé sur des graphiques gStore n'a pas pu charger des ensembles de données dont la taille est supérieure à la mémoire principale disponible. Les systèmes relationnels ont réussi à charger tous les ensembles de données sauf LUBM1B dans lequel nous avons eu une erreur de débordement de mémoire.

Performance des requêtes Les vertus de la stratégie de partitionnement logique ont été montrées tout au long de ces sections. Sans aucun doute, une stratégie de partitionnement logique accorde beaucoup plus de liberté aux concepteurs et aux gestionnaires. Ils ne dépendent plus d'un système spécifique pour partitionner leurs données. Nous avons montré la faisabilité d'intégrer notre cadre dans des magasins triples centralisés et distribués. De plus, les expériences utilisant RDF QDAG révèlent que l'utilisation de ces structures dans un triple store natif centralisé garantit son scalabilité et de bonnes performances pour certaines requêtes.

Incorporation au gStoreD

Nous comparons les performances de l'organisation des données sous forme de fragments de graphe vers l'avant ou vers l'arrière dans un triple store distribué. Nous déterminons pour quel type de requêtes l'organisation des données en tant que fragments de graphe en avant est plus approprié que les fragments de graphe en arrière et vice versa. À notre connaissance, il n'existe pas de système RDF basé sur des graphes stockant les données exclusivement sous forme de fragments de graphes en arrière. En effet, RDF QDAG utilise les deux structures (c'est-à-dire -→ Gf et ← -Gf ) et gStore stocke les données dans des listes d'adjacence regroupant les données par sujets. Pour les expériences de cette section, nous avons adapté la version distribuée de gStore [PZ Ö+ 16] pour prendre en charge le stockage des fragments de graphe avant d'abord, puis des fragments de graphe arrière. Les résultats de cette section font partie de l'étude expérimentale de notre étude: RDFPartSuite: Bridging Physical and Logical RDF Partitioning [START_REF] Galicia | RDFPartSuite: Bridging physical and logical RDF partitioning[END_REF].

Conclusion

Dans ce chapitre, nous avons présenté notre cadre d'action. Nous avons utilisé les modules de fragmentation et d'allocation pour charger les données dans un triple store centralisé et distribué. Nous avons effectué une série de tests sur chacun des systèmes pour montrer les forces et les limites de notre framework. Nous avons commencé à donner un aperçu du triple store RDF -QDAG. Ce système stocke les données sous forme de fragments de graphe avant et arrière. Nous avons intégré nos résultats au module de chargement de ce système. Nous avons comparé les coûts de chargement de RDF QDAG avec d'autres systèmes représentatifs de l'état de l'art en termes de temps et de scalabilité. Nous avons montré que le processus de fragmentation avec nos entités (Gf ) est réalisable, même dans les architectures avec des ressources limitées. Même si les temps de chargement étaient élevés par rapport à d'autres techniques de fragmentation plus légères (par exemple, triple table), nous avons vu les avantages lors de l'exécution des requêtes de ce coût supplémentaire.

Ensuite, nous avons effectué une évaluation complète des stratégies de fragmentation. Nous avons commencé à montrer que le nombre de fragments est raisonnable par rapport à la taille des ensembles de données. Ensuite, nous utilisons notre framework pour fragmenter les données en fragments de graphes avant et arrière dans un triple store distribué basé sur des graphes (gStoreD). Ce système a été utilisé pour comparer les stratégies de fragmentation avant et arrière. Ensuite, nous avons montré que la combinaison des deux types de fragments dans un seul système contribue non seulement à la scalabilité, mais également à améliorer les performances des requêtes. Nous avons réalisé une étude approfondie sur les coûts de communication en comparant notre stratégie de partitionnement avec les techniques les plus pertinentes. Nous avons montré que nos stratégies offrent un compromis entre le coût d'allocation, mesuré en termes de temps de chargement, de qualité de distribution et de performances. Enfin, nous introduisons une extension conviviale à notre framework. Ces extensions sont un langage de partitionnement déclaratif construit sur les structures logiques du chapitre précédent et un conseiller de partitionnement.

Conclusions et Perspectives

Actuellement, notre monde est rempli de données. Une grande partie de ces données est disponible gratuitement sur le Web. Le W3C a consacré de nombreux efforts au développement de normes facilitant l'exploitation, l'échange et la réutilisation de ces données. Parmi ces standards, RDF excelle pour sa flexibilité, sa simplicité et l'expressivité de son langage de requête (SPARQL). Les déclarations RDF sont des triples logiquement représentés dans un graphe. Ces graphes interconnectent des données provenant de plusieurs ensembles de données constituant un graphe de connaissances (KG). La complexité de ce dernier concerne à la fois son écosystème qui implique plusieurs acteurs (par exemple, les créateurs, les consommateurs, les gestionnaires) et les infrastructures, et sa taille. Pour satisfaire les exigences de ces acteurs, chaque KG doit être efficacement stocké et interrogé pour faciliter les différents processus de son exploitation.

L'infrastructure de stockage, et en particulier les Triple Stores, sont une pierre angulaire pour répondre à ces besoins. Cela a poussé des chercheurs de diverses communautés à proposer une grande collection de ces systèmes. Certains sont construits sur des solutions existantes (comme les SGBDR), d'autres sont construits en utilisant des implémentations de stockage personnalisées. Ils ont tous en commun l'utilisation de stratégies d'optimisation physique qui sont spécifiques à chaque système. Ces stratégies généralement ignorent le schéma logique du KG. Ceci est loin des optimisations basées sur des structures logiques largement étudiées dans les bases de données relationnelles. Dans ces stratégies, nous trouvons data partitioning dans la première ligne.

Le partitionnement des données accorde aux gestionnaires des moyens d'améliorer les performances, la gérabilité et la disponibilité des triple stores centralisés en divisant les données en fragments. Pourtant, le partitionnement des données dans les triple stores centralisés n'a pas eu la place qui lui revient dans la conception de ces systèmes. Pour des raisons de scalabilité, de nombreux triple stores parallèles et distribués ont vu le jour. Dans ces systèmes, le partitionnement des données devient une évidence. Il existe plusieurs modes de partitionnement (hachage, partitionnement graphique, hachage sémantique, etc) qui sont appliqués au niveau des triplets. Récemment, il y a eu un boom de recherche pour étudier l'impact sur la performance de ces stratégies de placement de données dans les triple stores [START_REF] Janke | Data placement strategies that speed-up distributed graph query processing[END_REF][START_REF] Akhter | An empirical evaluation of RDF graph partitioning techniques[END_REF].

Notre vision encourage la réutilisation et la reproduction des points forts du partitionnement de données appliqué dans différentes générations de bases de données qui ont précédé les bases de données RDF. Pour ce faire, il est nécessaire de rendre l'environnement de partitionnement explicite, en identifiant ses forces, son évolution et la manière dont leurs principaux éléments peuvent être réutilisés dans le contexte de KGs. Nous avons étudié le problème du partitionnement des données pour établir les bases qui guideront le développement de notre framework de partitionnement. Dans cette thèse, nous promouvons la vision de la reproduction des résultats du partitionnement de données dans le contexte des triple stores.

Cette vision est intégrée dans notre framework de partitionnement de données RDF pour triple stores centralisés, distribués et parallèles. Le framework suit le paradigme d'être en dehors du SGBD afin qu'il puisse être réutilisé, amélioré et étendu. Notre framework fonctionne en utilisant une représentation logique des fragments qui permettent de partitionner KGs indépendamment de la représentation de stockage de chaque système. Enfin, nous montrons comment ce framework a été implémenté dans des triple stores centralisés et distribués. Nous avons mené plusieurs expérimentations qui ont montré quand ces stratégies de partitionnement sont les plus efficaces.

Perspectives

Extensions de notre framework Composant de calibration Ce composant serait chargée de surveiller les différents schémas générés par notre framework en utilisant des approches basées sur les données. Le calibrage est réalisé par l'exploitation des charges de requêtes en cours dans le triple store. Nous utilisons la charge de requêtes pour améliorer la qualité de l'allocation initiale. Cette tâche pourrait être divisée en deux sous-modules: gestionnaire de charge de travail et réaffectateur intelligent.

Autres règles d'allocation

Actuellement, le composant allocateur de notre framework implémente des algorithmes pilotés par les données pour placer des fragments de graphes sur les sites d'un système distribué. Cette stratégie est basée sur la connectivité inhérente des triples. Cependant, nous pouvons imaginer d'autres règles basées sur les données pour étendre notre cadre. Par exemple, pour les ensembles de données contenant des informations géospatiales.

Prise en compte d'autres techniques d'optimisation

Pour le moment, notre framework est utilisé pour partitionner KGs. Nous sommes conscients que le partitionnement des données n'est qu'une des stratégies d'optimisation à prendre en compte lors de la conception de systèmes de stockage efficaces. Tenir compte de l'impact du partitionnement des données et de son interaction avec les index, les répliques, les vues matérialisées, etc. est la prochaine étape.

Stratégies d'optimisation dynamique

Aujourd'hui, il existe de nombreux triple stores distribués à mémoire principale très efficaces. Dans ces systèmes, des optimisations dynamiques rapides de la distribution des données peuvent être envisagées. Ces optimisations peuvent prendre en compte les flux de requêtes pour décider des stratégies de re-partitionnement ou de réplication. Un composant peut être ajouté à notre cadre pour traiter spécifiquement de cette réorganisation en ligne. La première génération de systèmes RDF a été construite sur des bases de données relationnelles traditionnelles. Malheureusement, les performances de ces systèmes se dégradent rapidement car le modèle relationnel ne convient pas au traitement des données RDF intrinsèquement représentées sous forme de graphe. Les systèmes RDF natifs et distribués cherchent à surmonter cette limitation. Les premiers utilisent principalement l'indexation comme stratégie d'optimisation pour accélérer les requêtes. Les deuxièmes recourent au partitionnement des données. Dans le modèle relationnel, la représentation logique de la base de données est cruciale pour concevoir le partitionnement. La couche logique définissant le schéma explicite de la base de données offre un certain confort aux concepteurs. Cette couche leur permet de choisir manuellement ou automatiquement, via des assistants automatiques, les tables et les attributs à partitionner. Aussi, elle préserve les concepts fondamentaux sur le partitionnement qui restent constants quel que soit le système de gestion de base de données. Ce schéma de conception n'est plus valide pour les bases de données RDF car le modèle RDF n'applique pas explicitement un schéma aux données. Ainsi, la couche logique est inexistante et le partitionnement des données dépend fortement des implémentations physiques des triplets sur le disque. Cette situation contribue à avoir des logiques de partitionnement différentes selon le système cible, ce qui est assez différent du point de vue du modèle relationnel. Dans cette thèse, nous promouvons l'idée d'effectuer le partitionnement de données au niveau logique dans les bases de données RDF. Ainsi, nous traitons d'abord le graphe de données RDF pour prendre en charge le partitionnement basé sur des entités logiques. Puis, nous proposons un framework pour effectuer les méthodes de partitionnement. Ce framework s'accompagne de procédures d'allocation et de distribution des données. Notre framework a été incorporé dans un système de traitement des données RDF centralisé (RDF QDAG) et un système distribué (gStoreD). Nous avons mené plusieurs expériences qui ont confirmé la faisabilité de l'intégration de notre framework aux systèmes existants en améliorant leurs performances pour certaines requêtes. Enfin, nous concevons un ensemble d'outils de gestion du partitionnement de données RDF dont un langage de définition de données (DDL) et un assistant automatique de partitionnement.

Reproductibilité de notre framework à d'autres types de données

List of Tables

Mots-clés : Bases de données-Conception; Bases des données-Gestion; Graphes, Théorie des; Partionnement de graphes; Resource Description Framework (informatique); SPARQL (langage de programmation); Structure logique; Systèmes experts (informatique)

Abstract

The Resource Description Framework (RDF) and SPARQL are very popular graph-based standards initially designed to represent and query information on the Web. The flexibility offered by RDF motivated its use in other domains and today RDF datasets are great information sources. They gather billions of triples in Knowledge Graphs that must be stored and efficiently exploited. The first generation of RDF systems was built on top of traditional relational databases. Unfortunately, the performance in these systems degrades rapidly as the relational model is not suitable for handling RDF data inherently represented as a graph. Native and distributed RDF systems seek to overcome this limitation. The former mainly use indexing as an optimization strategy to speed up queries. Distributed and parallel RDF systems resorts to data partitioning. The logical representation of the database is crucial to design data partitions in the relational model. The logical layer defining the explicit schema of the database provides a degree of comfort to database designers. It lets them choose manually or automatically (through advisors) the tables and attributes to be partitioned. Besides, it allows the partitioning core concepts to remain constant regardless of the database management system. This design scheme is no longer valid for RDF databases. Essentially, because the RDF model does not explicitly enforce a schema since RDF data is mostly implicitly structured. Thus, the logical layer is inexistent and data partitioning depends strongly on the physical implementations of the triples on disk. This situation contributes to have different partitioning logics depending on the target system, which is quite different from the relational model's perspective. In this thesis, we promote the novel idea of performing data partitioning at the logical level in RDF databases. Thereby, we first process the RDF data graph to support logical entity-based partitioning. After this preparation, we present a partitioning framework built upon these logical structures. This framework is accompanied by data fragmentation, allocation, and distribution procedures. This framework was incorporated to a centralized (RDF QDAG) and a distributed (gStoreD) triple store. We conducted several experiments that confirmed the feasibility of integrating our framework to existent systems improving their performances for certain queries. Finally, we design a set of RDF data partitioning management tools including a data definition language (DDL) and an automatic partitioning wizard.

Keywords

1 Data Partitioning Foundations 1 . 1

 11 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Data Partitioning Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Partitioning definition and development overview . . . . . . . . . . . . . . 1.2.2 Partitioning concept evolution . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Partitioning dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.2 Main objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.3 Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.4 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.5 Cost Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.6 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.7 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.8 System Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.9 Adaptability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.10 Data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Partitioning approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 Partitioning by type, platform and mechanism . . . . . . . . . . . . . . . 1.4.2 Partitioning by data model . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.3 Partitioning by adaptability . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.4 Partitioning by constraints . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5 Partitioning in large-scale platforms . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 Hadoop ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.2 Apache Spark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.3 NoSQL stores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.4 Hybrid architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Graph Data : Representation and Processing 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Graph database models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Logical graph data structures . . . . . . . . . . . . . . . . . . . . . . . . . vii

Figure 1 :

 1 Figure 1: Examples for RDF and SPARQL

Figure 2 :

 2 Figure 2: Linked Open Data (LOD) evolution

Figure 4 :

 4 Figure 3: Knowledge Graphs Ecosystem

Figure 5 :

 5 Figure 5: Triple stores classification

Figure 6 :

 6 Figure 6: Horizontal partitioning evolution in Oracle RDBMS

Figure 7 :

 7 Figure 7: Partitioning environment in relational databases

Figure 9 :

 9 Figure 9: Partitioning example by data model

Figure 10 :

 10 Figure 10: Fusing data partitioning to both worlds

Figure 11 :

 11 Figure 11: RDFPartSuite Framework

1 . 1 1 . 4 1 . 5

 111415 Figure 12: Breakdown of thesis chapters

Figure 1 . 2 :

 12 Figure 1.2: Database partitioning origins

Figure 1 . 5 :

 15 Figure 1.5: Hybrid partitioning example

Figure 1 . 7 : 1 1. 4 . 1

 17141 Figure 1.7: Organization of schema Section 1.4.1

Figure 1 . 10 :

 110 Figure 1.10: Owner and member relations

Figure 1 . 11 :

 111 Figure 1.11: Schism data representation

•

  Greedy allocation strategy. ✓ AlCo [GLL + 20] • Custom cost model. ✓ No ✓ • modified genetic algorithm.

Figure 1 . 13 :

 113 Figure 1.13: Large-scale systems

Figure 1 .

 1 Figure 1.14: MapReduce schema

Figure 2 . 1 .•

 21 Directed/Undirected graphs In an undirected graph like the one shown in Figure 2.1a, all relationships are symmetric. Contrarily, the edges on directed graphs illustrated in Figure 2.1b have a single source and a destination vertex. The number of incoming/outgoing edges define the in/out degree of each node respectively.

Figure 2 . 1 :

 21 Figure 2.1: Graph data structures

Figure 2 . 2 :

 22 Figure 2.2: Storage structures for graph of Figure 2.1c

Figure 2 . 3 :

 23 Figure 2.3: Graph query examples

Figure 2 . 4 :

 24 Figure 2.4: Nodes visiting order

  Figure 2.6: Partitioning problems

Figure 2 .

 2 Figure 2.7: Graph partitioning algorithms

Figure 2 . 8 :

 28 Figure 2.8: Graph algorithms schemas

Figure 2 . 9 :

 29 Figure 2.9: Partitioning in Sedge

Figure 2 .

 2 Figure 2.10: RDF example

Figure 2 . 11 :

 211 Figure 2.11: RDF-Schema associated to graph of Figure 2.10a

Figure 2 .

 2 Figure 2.12: Relational-based storage of the graph of Figure 2.10a

Figure 2 . 13 :

 213 Figure 2.13: Property table optimizations of Figure 2.10a

Figure 2 . 14 :

 214 Figure 2.14: Partitioning Process in RDF Systems

Fusion

  , GP: Graph partitioning, W: Workload-based, SM: Semantic-based, RR: round-robin, H:Hash, CP: Cloud Platform α Native: systems built specifically for RDF data, β On top: systems built on top of cloud platforms.

Contents 3 . 1

 31 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 RDF partitioning design process . . . . . . . . . . . . . . . . . . . . . 3.3 Graph fragments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Grouping the graph by instances . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Grouping the graph by attributes . . . . . . . . . . . . . . . . . . . . . . 3.4 From logical fragments to physical structures . . . . . . . . . . . . . 3.5 Allocation problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Problem definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 Graph partitioning heuristic . . . . . . . . . . . . . . . . . . . . . . . . .

3. 6

 6 RDF partitioning example . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Dealing with large fragments . . . . . . . . . . . . . . . . . . . . . . . 3.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 3 . 1 :

 31 Figure 3.1: Partitioning design process

Figure 3 . 2 :

 32 Figure 3.2: Forward graph fragment example

3 . 3 . 3 (

 333 3. A triple belong to a single backward graph star as shown in Theorem 3.Definition Backward graph star) A backward graph star denoted as ← -Gs(o) is a subset of the original RDF graph G in which the triples share the same object o. Formally

Definition 3 . 4 (Definition 3 . 5 (

 3435 Characteristic set extension) Each subject s and object o in an RDF graph G has a characteristic set defined as -→ cs(s) = {p|∃ o : (s, p, o) ∈ G} and -→ cs(o) = {p|∃ o : (s, p, o) ∈ G}. Backward graph fragment) A backward segment ← -Gf is a set of backward graph stars

3. 4 .

 4 FROM LOGICAL FRAGMENTS TO PHYSICAL STRUCTURES Algorithm 5 updateGb function Input: A graph star ← -Gs(o), a set of graph fragments ← -Gf , a similarity threshold τ , Map of graph fragment keys CSM ⟨key, ←

Figure 3 . 4 :

 34 Figure 3.4: Query execution by storage

Figure 3 . 5 :

 35 Figure 3.5: Graph partitioning example

Figure 3 . 6 :

 36 Figure 3.6: Miniature of graph G of Figure 2.10

Figure 3 . 8 :

 38 Figure 3.8: Execution strategies for query Q 3

Figure 4 . 1 :

 41 Figure 4.1: RDF QDAG architecture

Figure 4 . 2 :

 42 Figure 4.2: Storage files examples for graph of Figure 2.10

Figure 4 . 3 :

 43 Figure 4.3: Compression structure in RDF QDAG

Figure 4 . 4 :

 44 Figure 4.4: Query graph example

and 4 .

 4 5b showing an acceptable and a non-acceptable query plan respectively. [ -→ QS(?x), -→ QS(?m)]

Figure 4 . 5 :

 45 Figure 4.5: Query execution plans example

Figure 4 . 6 :

 46 Figure 4.6: Execution pipeline example

Figure 4

 4

Figure 4 . 7 :

 47 Figure 4.7: Volcano execution in RDF QDAG example

Figure 4 . 8 :

 48 Figure 4.8: Logarithmic loading times

Figure 4 . 9 :Figure 4 . 10 :

 49410 Figure 4.9: Performance of partitioning configurations in relational-based system

  , 3X: RDF-3X, V:Virtuoso, QD: RDF QDAG, ✗: Error, Bold: lowest execution time

  01 139.5 0.01 0.03 0.1 550.0 0.03 3 13.9 0.01 2.6 3.0 44.6 550.0 3X: RDF-3X, V:Virtuoso, QD: RDF QDAG, Bold: lowest execution time

Figure 4 .

 4 Figure 4.12: Triple distribution by allocation method GP: graph partitioning, RR: rond-robin, LP: linear programming

Figure 4 . 13 :

 413 Figure 4.13: Mappings analysis for Watdiv100k LP: Linear programming, RR: round-robin, H: hashing on the subject, GPS: graph partitioning -small groups, GP: Graph partitioning

-

  ⟨element⟩: nonterminal element; element: terminal element; -[element]: optional element; -{element}: is an element that can be repeated 0 or n times; -| : represents an alternative; -⟨element list⟩ is an element defined as ⟨element⟩{, ⟨ element ⟩}. The main lexical elements are described as follows: ⟨non quote characters⟩ ::= {a-z} ⟨quote characters⟩ ::= '{a-z}' ⟨unsigned integer⟩ ::= {init digit}[{digit}] ⟨unsigned float⟩ ::= {init digit}[{digit}].{⟨digit⟩} ⟨digit⟩ ::= 0|1|2|3|4|5|6|7|8|9 ⟨init digit⟩ ::= 1|2|3|4|5|6|7|8|9

  ⟨kg definition⟩ ::= CREATE KG ⟨kg name⟩ ⟨kg name⟩ ::= ⟨non quote characters⟩ Let us consider for example the following statement declaring a KG named yago. CREATE KG yago 4.6.3 LOAD DATA statement This statement indicates that the data in a file (in .NT or .ttl format) belongs an existent knowledge graph. ⟨load data⟩ ::= LOAD DATA INFILE ⟨file name ⟩ INTO ⟨kg name⟩ ⟨file name⟩ ::= ⟨non quote characters⟩

  LOAD DATA INFILE yago-knowledge.nt INTO yago 4.6.4 FRAGMENT KG statement This statement fragments the data in an existent KG in Forward or Backward graph fragments. ⟨fragment kg⟩ ::= FRAGMENT KG ⟨kg name⟩ FORWARDLY [⟨partition options⟩] | FRAGMENT KG ⟨kg name⟩ BACKWARDLY [⟨partition options⟩] ⟨partition options⟩ ::= BY ⟨fragment mode⟩ [⟨max frag⟩][⟨similarity⟩] MAX ⟨unsigned integer⟩ ⟨similarity⟩ ::= SIM ⟨unsigned float⟩

FRAGMENT

  KG yago FORWARDLY BY JACCARD MAX 10000 SIM 0.8 4.6.5 ALTER FRAGMENT statement It is possible to re-split a given fragment because it is too large with the methods described in Sect. 3.7. ⟨alter fragment⟩ ::= ALTER FRAGMENT ⟨frag id⟩ IN ⟨kg name⟩ SUBPARTITION BY ⟨subpartition mode⟩ ⟨frag id⟩ ::= ⟨unsigned integer⟩ ⟨subpartition mode⟩ ::= HASH | ⟨range⟩ ⟨range⟩ ::= RANGE ⟨pred id⟩ LESS THAN ⟨range value⟩ ⟨pred id⟩ ::= ⟨unsigned integer⟩ ⟨range value⟩ ::= ⟨unsigned integer⟩ | ⟨unsigned float⟩

  ⟨allocate fragments⟩ ::= ALLOCATE KG ⟨kg name⟩ BY ⟨allocation mode⟩ ⟨nb sites⟩ ⟨allocation mode⟩ ::= ROUND-ROBIN | METIS ⟨nb sites⟩ ::= SITES ⟨unsigned integer⟩

  ⟨alter allocation⟩ ::= ALTER ALLOCATION FRAGMENT ⟨frag id⟩ IN ⟨kg name⟩ ⟨site id⟩ ⟨site id⟩ ::= TO SITE ⟨unsigned integer⟩ In our example in the yago KG, we change the allocation of fragment 2 to the site identified with the ID 5. ALTER ALLOCATION FRAGMENT 2 IN yago TO SITE 5 4.6.8 DISPATCH statement This statement calls the dispatcher component of RDFPartSuite. It sends the fragments of a KG to the sites according to the allocation schema. It can be called only after the allocation schema has been created using the ALLOCATE statement. The data are sent to the sites indicated in the configuration file of the framework. ⟨dispatch allocation⟩ ::= DISPATCH KG ⟨kg name⟩

FRAGMENT

  KG yago FORWARDLY FRAGMENT KG yago BACKWARDLY ALLOCATE yago BY METIS SITES 15

FragmentFigure 4 . 14 :

 414 Figure 4.14: Partitioning advisor use case

Figure 4 . 15 :

 415 Figure 4.15: Partitioning advisor architecture

Figure 4 .

 4 Figure 4.16: RDFPart advisor's welcome screen

( a )

 a RDFPart initial statistics (b) RDFPart re-fragmentation module

Figure 4 .

 4 Figure 4.17: RDFPart statistics and re-fragmentation modules

Figure 4 .

 4 Figure 4.19: Normalization process

Figure 4 .

 4 Figure 4.20: Calibration component extension

Figure 4 .

 4 Figure 4.21: Schéma en étoile de l'environnement de partitionnement

  a common data

	http://dbpedia.org/	http://example.org/
			Aircraft		22 February 1962			@prefix db:<http://dbpedia.org/> .
			builds		born on			@prefix ex:<http://example.org/> .
	Airbus	name	Airbus	works in	Guillaume	profession	Engineer	SELECT ?x ?y WHERE {
			industry	is a			?x ex:works_in db:Airbus . ?x ex:profession ?y .
			Aerospace		Person			}
				(a) RDF Graph			(b) SPARQL query

  table partitioned on attribute Dev is declared in PosgreSQL with following Data Definition Language (DDL) as:

	CREATE TABLE Airplane
	(
	ID integer PRIMARY KEY,
	Model varchar(15),
	Dev varchar(15),
	Length real,
	Cost real
	)
	PARTITION BY LIST (Dev)

Table 1 .

 1 1: High-level variants of the partitioning problem

	Stage	Platform	Type	Mechanism System element
	Optional	Centralized Horizontal	Clustering	Memory & Disk
	Mandatory	Distributed	Vertical		Memory, Disk
		Parallel			& Network

  1.4a and 1.4b at a record level (horizontally) or at an attribute level (vertically) respectively.

							ID	Model	Dev
	ID	Model	Dev	Length Cost		1609 A320 1909 A340-600 Airbus Airbus
	1609 A320	Airbus 37.57	101		1912 B737-800 Boeing
	1752 A350-900 Airbus 64.75	317.4		1212 B777-300 Boeing
	1909 A340-600 Airbus 75.36	300.1		ID	Length Cost
	ID	Model	Dev	Length Cost		1609 37.57 1909 75.36	101 300.1
	1912 B737-800 Boeing 39.5	102.2		1912 39.5	102.2
	1212 B777-300 Boeing 73.86	361.5		1212 73.86	361.5
		(a) Horizontal partitions				(b) Vertical partitions
			Figure 1.4: Partitioning types for table Airplane
					Main objective	Adaptability
			Algorithm
							Mechanism
				Type
					Partitioning	Cost model
			Data model			System element
				Constraints	Platform
			Figure 1.3: A star-schema partitioning environment

Table 1 . 2

 12

	Partitioning Strategy

: Partitioning type by DBMS

Table 1 .

 1

		4: Vertical partitioning approaches
	Approach Algorithm Strategy Details
	[Hof76]	Splitting	Integer programming formulation
	[Nia78]	Exact

Table 1 .

 1 5: Single-attribute horizontal declustering strategies

	Strategy	Strenghts	Drawbacks
	Round robin	Sequential access queries. Direct access to individual tuples. Uniform data distribution.
	Hash	Exact match queries	Range queries
	Range	Exact match queries Range queries	Partition size disparity

Table 1

 1

		.6: Multi-attribute declustering
	Objective	Strategy name	Reference
	Localize execution to as	MAGIC	[GD94]
	few nodes as possible.	BERD	[BAC + 90]
		Disk Modulo	[DS82]
	Reduce execution	Fieldwise XOR	[KP88]
	skewness.	Error Correcting Codes (ECC) [FM91]
		Hilbert Curve Allocation	[FB93]

  .1.1.

			1
	TupleID QueryID	2	1
	1	1,2,3,6	2	1	4
	2	1,4,6
	3	1,2,4,5	2	1
	4	3,5	3
	(a) Workload as inverted table	(b) Schism graph

Table 1

 1

		Approach
		Main strategy
	Schema Workload Replication	Inputs	.7: Recent horizontal partitioning approaches
	Locality	Max
	Redundancy	Min	Objective
	Workload skew	Min

Table 1

 1

		.8: Partitioning advisors
		Optimization
		Strategy
	Advisor	P a

Table 1 .

 1 9: Online partitioning approaches

	Changing

• Identify clumps of tuples to migrate. ✓ GridFormation [DPP + 18] • Reinforcement learning. ✓

Table 1 .

 1 10: Partitioning approaches

	Type	Data model / Approach	Workload-aware Constraints Main objecive Mech. Alg. Adapt. Replication Schema Response-time Concurrency Load balance Combined Clustering Declustering Exact Heuristics Online Offline
	Vertical	[Hof76]

  Contents 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 2.2 Graph database models . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 2.2.1 Logical graph data structures . . . . . . . . . . . . . . . . . . . . . . . . 64 2.2.2 Data storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 2.2.3 Query and manipulation languages . . . . . . . . . . . . . . . . . . . . . 66 2.2.4 Query processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 2.2.5 Graph partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 2.2.6 Graph databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 2.3 Resource Description Framework . . . . . . . . . . . . . . . . . . . . . 80 2.3.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 2.3.2 Storage models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 2.3.3 Processing strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 2.3.4 Data partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

  in partial permutation matrices. A naïve approach would start at the first row assigning 1 to the first row and column and all the other values to 0. If the isomorphic condition is fulfilled, it continues to the other row and the procedure is called recursively. If the isomorphism condition is violated, it backtracks to the previous row and set the next column to 1 and all the other values to 0. Then it calls the procedure again. It should be noted that the intermediate results are not stored in any structure making DFS-based algorithms memory efficient. More details are found in[START_REF] Bonifati | Querying Graphs[END_REF].

	G2.node B
	(b) Relational logical query tree
	Figure 2.5: Examples of Sections 2.2.4.1 and 2.2.4.2
	must be fulfilled

2.2.4.2 Breadth-first search (BFS)

Several subgraph matching algorithms are based on a BFS searching strategy illustrated in Figure

2

.4b. Contrarily to DFS, it does not use recursion and its iterative-based making it less complex. It can even be optimized with dynamic programming. However, it needs a structure to memorize the partial solutions that when combined could become a subgraph match. Algorithms based on the relational model follow a BFS graph exploration matching. Considering the query of Figure

2

.3a, and assuming that the data is stored in a single table like the one shown in Figure

2

.2c. Supposing that the data are stored in a relational database, one of the possible logical execution tree is given in Figure

2

.5b. The self joins to the tables are executed pairwise in an equivalent BFS-like subgraph matching strategy. In this case, the intermediate results are stored in main memory causing excessive memory consumption. In the example of Figure

2

.5b at least two intermediate result structures must be stored in main memory before projecting the values in the final result.

Table 2 .

 2 1: Dynamic graph partitioning approaches

	System		Main technique	Changing Workload Graph	Replication
	ParMETIS [SKK97]	• Difussion schemes.	✓
	xDGP	[VCLM13] • Greedy vertex migration.	✓
	Hermes	[NKDC15] • Neighboring vertices.	✓
	Leopard	[HA16]	• Neighboring vertices.	✓	✓
	Inc	[FLT + 20]	• Incrementalization.	✓
	Fennel	[TGRV14] • Stream graphs.	✓
			• Neighboring vertices.
	Spinner	[MLLS17]	• Pregel label propagation.	✓
	Sedge	[YYZK12] • Two-level partition.	✓	✓
		[T Ö15]	• Graph access patterns.	✓
	TAPER	[FM17]	• Stability.	✓
			• Random walks.
	IOGP	[DZC17]

• Hasing, ✓ • Edge-cut and split.

Table 2 .

 2 2: Graph databases mentioned in Section 2.2.6

	Graph	Query

D:Disk, DLG: Directed labeled graph, Hyp: Hypergraph, Im: In memory, K-v: key-value store, N: Native, Nn: Non-native, , Part: Partitioning strategy, Proc: Processing strategy, Rel: Relational.

  was introduced to to treat read-only queries on the Facebook's social graph. It is built on top of a distributed NoSQL database adding an intermediary layer to access the data stored in MySQL using caches. GraphX[START_REF] Xin | GraphX: a resilient distributed graph system on Spark[END_REF] is a graph computing library built on top of Apache Spark 3 . It stores vertices and edges in two RDDs which are Spark's distributed collections. Graph operations are transformations applied to the vertices and nodes RDDs.Native Most of the systems in this category are based on the Bulk Synchronous Parallel (BSP) programming model which uses a message passing interface (MPI). BSP computation consists on a series of supersteps that are synchronized when moving from one step to another (in different machines). Google researchers were the pioneers to use the BSP model in an in-memory graph system named Pregel [MAB+ 10]. The programming model used was later known as vertexcentric since it is based on message propagation from vertex to vertex. At runtime, messages are received and sent from/to the node's neighbors that update its current state and also the edges' state.

  table is possible on single columns. If the query involves a lookup in one of the unordered columns, it may require to scan the entire table. The naive strategy to overcome this problem creates a primary index of the other columns despite replication. A cheaper option in terms of space are secondary indexes and single-column indexes adding a column to the triple table with pointers. The popular RDF system Viruoso [EM09] built on top of a relational database stores the data in a table of 4 columns (graph G, subject S, predicate P, object O). It is composed of a main index GSPO and a secondary OPGS bitmap index. Another popular indexing strategy stores the permutations of the single table (SPO, OPS, PSO, SOP, POS, OSP). This technique is strongly inspired from the indexing strategies proposed in the seventies in

•

  Binary table: this strategy creates a two-column table (subject, object) per predicate. It is illustrated in Figure 2.12b The strategy is applied by SW-Store[AMMH09] and HadoopRDF[DWNY12] for example. It suffers from join overheads when a query involves several predicates. • Property table: this approach also known as pivited table aims to reduce the number of self-joins storing the data in a wider table whose dimensions correspond to the number of distinct subjects and predicates. The drawbacks of this approach are the great number of null values in the table causing storage overheads, the complexity to treat multi-valued

	Subject	Predicate Object
	Airplane1 has model	A340	nb motors		nb version
	Airplane1 has length Airplane1 nb motors	75.4 4	Subject	Object	...	Subject Object
	Airplane1 type	Airliner	Airplane1 4		B747	4
	...	...	...	Airplane2 4		A340	5
		(a) Triple table			(b) Binary tables
		has model has length nb motors type	nb version . . .
	Airplane1 A340	75.4	4	Airliner null
	Airplane2 B747	70.1	4	Airliner null
	B747	null	null	null	null	5
	. . .
				(c) Property table

properties and its fixed nature not supporting the schema-flexible nature of RDF (e.g., complex to add a triple with a new property). An excerpt of a property table is shown in Figure

2

.12c. This strategy is applied by the Jena2 [Wil06] system. Many strategies have been proposed to alleviate some of the problems described previously within which we find:

Table 2 . 3 :

 23 State of the art systems

	T Group By	Fragmentation
		Allocation
		Replication

  Based on the backward entity definition,f o (t 1 ) = f o (t) and f o (t 2 ) = f o (t).Using the transitivity property of the equality,

			o 9	s 8
			o 8	s 6
			s 9
	o 7 s 5	p 4	s 4 Backward entity p 3 . s 7 {p 3 , p 4 }	o o 7 s 4 s 5 p 3 p 4 o 8 s 6 s 7 o 9 s 8 s 9	{ {o7 : {{p3:s4}, {p4:s5}}}, {o8 : {{p3:s6}, {p4:s7}}}, {o9 : {{p3:s8}, {p4:s9}}} }
	(a) Graph		(b) Table	(c) Adjacency list
				Figure 3.3: Backward graph fragment example
	Proof To prove by contradiction. Let us assume that a triple t ∈ consider two not equal triples t 1 , t 2 , both different from t, such that t 1 ∈ ← -G s i and t ∈ ← -G s i and t 2 ∈ ← -G f s j . Let us ← -G s j .

Theorem 3.3 A triple belongs to one and only one backward graph star. Let t be a triple t ∈ G, if t ∈ ← -Gs i ⇒ ∀ i̸ =j (t / ∈ ← -Gs j ).

Table 3 .

 3 1: Edge's weights in fragment graph G

	Edge type	Condition a

  .2. The first group uses the relational model to store RDF triples in tables with diverse con-

			RDF QDAG
	Data Loader	Query optimizer	Executor
				Result writer
	Pre-processing	Storage		Dict. matcher
	Encoder	Dict. builder	Parser	Sorter
	Fragmenter	Indexer	Plan generator	Aggregator
	Data refiner		Plan selector	Matcher

  QS to denote the set of forward and backward graph stars and qs to denote indistinctly a forward and backward query star.

	← -QS = {	← -QS(?y),	← -QS(?m),	← -QS("T oulouse")}.	are	-→ QS = { -→ QS(?x),	-→ QS(?m)} and
	Definition 4.1 Query Star Let Q be the SPARQL query graph. A Forward Query Star is the set of triple patterns such that -→ QS(x) = {(x, p, o)|∃ p,o : (x, p, o) ∈ Q}, x is named the head -→ QS(x) of the Query Star. Likewise, a Backward Query Star ← -QS(x) is ← -QS(x) = {(s, p, x)|∃ s,p : (s, p, x) ∈ Q}. We use -→ QS, ← -

Table 4 .

 4 1: Experimental datasets

	Dataset	Triples (M)	Size (GB)	# S (M)	# P (M)	# O (M)
	Watdiv100M	109	15	5.21	86	9.76
	Watdiv1B	1000	149	52.12	86 179.09
	LUBM100M	100	17	16.27	17	12.10
	LUBM500M	500	83	81.38	17	60.54
	LUBM1B	1367	224 222.21	17 165.29
	Yago	284	42	10.12	98	52.37
	DBLP	207	32	6.84	27	35.52
		M: Millions, GB: Gigabytes

Table 4 .

 4 2: Loading times comparisons

	Dataset	Loading times (minutes) Virtuoso RDF-3X gStore CliquesquareS RDF QDAG
	Watdiv100M	45	27	382		107	71
	Watdiv1B	188	329	✗		✗	1,080
	LUBM100M	284	20	✗		143	348
	LUBM500M	1,390	114	✗		✗	1,490
	LUBM1B	✗	✗	✗		✗	3,320
	Yago	608	520	✗		✗	815
	DBLP	97	59	✗		184	127
			✗: Unable to load
	10 3
	10 2
	10 1
	10 0
	Watdiv100M	Watdiv1B	LUBM100M	LUBM500M	LUBM1B	Yago	DBLP

Table 4 .

 4

		3: Data coverage per dataset
	Dataset	-→ Gf N o of fragments N o of fragments ← -Gf
	Watdiv100M 39,855 (1,028) 1,181	(17)
	Watdiv1B	96,344 (1,030) 4,725	(19)
	LUBM100M	11	(6)	13	(8)
	LUBM500M	18	(9)	17	(9)
	LUBM1B	36	(19)	33	(18)
	Yago	25,511	(100) 1,216	(24)
	DBLP	247	(10)	26	(14)
	( ): Number of fragments covering 80% of the data

Table 4 .

 4 4: Experimental datasets in relational-based system

	Dataset	Size (GB)	#S #P	#O # ← -Gf
	Watdiv1M	0.148	52,505 87	105,492 222
	Watdiv10M	1.54	521,585 87 1,003,136 587
	Watdiv20M	3.28 1,042,785 87 2,473,723 641

M: millions

Table 4 .

 4 5: Watdiv BGP queries results in seconds

		93.8
	Star	91.2 89.2 85.0
	Linear	92.3 93.3 95.2
		94.4
		91.9 93.8
	Snowflake	96.4 91.3 93.1 97.8 88.9
	Complex	92.1
		93.9
		gS	3X
		Watdiv100M

Table 4 .

 4 6: LUBM500M BGP queries results in seconds

Table 4 .

 4

	7: DBLP BGP queries results in seconds	L1 L2 L3 L4 S1 S2 S3 S4 S5	3X 4226.37 0.40 0.15 0.10 2687.48 0.19 155.36 2.68 439.45	V ✗ 0.05 0.48 0.13 ✗ 2.26 210.78 88.35 405.85	QD 2023.34 0.01 0.01 0.005 537.50 0.01 145.1 1.23 237.9	3X: RDF-3X, V:Virtuoso, QD: RDF QDAG, Bold: lowest execution time

Table 4

 4

		S7	44.2	27.5	93.8	21.8	1.91
		S6	42.7	27.6	85.0	21.9	0.76
	.8: Execution time (in seconds) for Watdiv100M queries	C1 C2 C3 F1 F2 F3 F4 F5 L1 L2 L3 L4 L5 S1 S2 S3 S4 S5	124.5 181.1 138.4 ✗ 181.0 75.7 59.1 104.4 51.5 51.8 40.9 41.8 50.5 57.8 47.9 ✗ 40.6 46.5	69.9 93.0 91.7 ✗ 92.0 81.7 163.9 ✗ 30.4 30.3 26.4 26.3 31.4 125.7 37.5 ✗ 26.4 36.5	93.9 92.1 96.4 91.3 93.1 97.8 88.9 91.9 93.8 94.4 92.3 93.3 95.2 91.2 89.2 90.8 88.8 90.5	139.8 55.0 24.0 22.0 33.0 29.3 59.4 73.1 27.6 22.6 21.9 22.8 23.3 22.9 21.8 21.8 21.8 21.9	1.36 1.68 45.05 0.27 0.44 0.63 0.41 0.001 0.09 1.15 0.001 1.11 0.45 5.57 0.78 0.29 0.95 0.24	Table 4.9: Execution time (in seconds) for LUBM queries	Ds. Sys. 1 2 3 4 5 6 7 8 9 10 11 12 13 14	Cs 42.4 76.3 43.8 45.0 40.4 46.9 120.8 104.6 155.8 42.4 49.1 38.4 42.4 47.8	20M CsD 38.3 gS 26.0 25.0 gSD 10.1 883.1 67.6 159.2 29.1 28.0 31.0 505.1 49.2 108.4 29.0 31.1 27.0 29.0 30.0 26.2 26.5 32.2 47.9 25.9 25.7 26.6 25.3 25.7 26.8 34.2 49.0 9.8 9.8 9.8 17.1 29.7 353.0 33.9 9.9 12.9 9.9 14.1 17.3	QDAG 0.01 6.0 0.01 0.02 0.09 19.5 0.03 0.47 0.99 0.004 0.02 0.015 7.9 18.4	Cs 73.3 143.8 86.4 81.5 45.9 87.7 388.6 301.8 600.9 78.7 56.6 39.5 40.9 89.8	100M CsD 57.1 67.5 gS ✗ ✗ gSD 2684 ✗ 45.0 43.2 30.0 43.0 146.1 ✗ ✗ ✗ ✗ ✗ ✗ 2815 1818 1801 1912 11063 22439 122.3 291.4 41.1 32.0 ✗ ✗ ✗ 8747 3312 3455 26.9 27.9 43.1 ✗ ✗ ✗ 1639 1834 1920	QDAG 0.005 173.9 22.5 4.1 35.6 121.9 0.039 1.2 0.05 0.006 1.04 0.80 12.9 123.8
		Sys.	Cs	CsD	gS	gSD	QDAG

Table 4 .

 4 10: Execution time (in seconds) for DBLP and YAGO queries

	Ds. Sys.

Contexte

  Nous vivons dans un monde hyper-connecté dans lequel de grandes quantités de données et de connaissances sont émises par plusieurs fournisseurs tels que les réseaux sociaux, les appareils mobiles, le commerce électronique, des capteurs, l'Internet des objets et bien d'autres. Une grande partie de ces données est produite et disponible sur Internet. À ce jour, le Web contient plus de 1,8 milliard de sites15 et sa taille est en constante expansion. Les données issues du Web se caractérisent, entre autres, par leur volume, variété, véracité et vélocité. Les informations et les connaissances associées à ces données, si elles sont bien préparées, peuvent être précieuses pour les consommateurs (entreprises, gouvernements, utilisateurs privés, etc.) qui peuvent obtenir des connaissances pertinentes et éventuellement de la valeur ajouté.Cependant, la disponibilité des données issues du Web n'implique pas leur exploitation directe. Les ordinateurs doivent manipuler et interpréter les informations publiées sur le Web. Cette idée a donné lieu au Web sémantique. Les données issues du Web doivent être représentées et interrogeables de manière intuitive et claire. Le World Wide Web Consortium (W3C) a mené de nombreux efforts pour spécifier, développer et déployer des directives, des modèles de données et des langages. Parmi ces modèles, le Resource Description Framework (RDF)[START_REF] Lanthaler | RDF 1.1 concepts and abstract syntax[END_REF] a été conçu pour exprimer des informations sur les ressources du Web. Ce modèle est la pierre angulaire des autres modèles et langages du W3C.Le triplet est la plus petite unité de données dans RDF. Un triplet modélise une seule déclaration sur les ressources avec la structure suivante ⟨sujet, predicat, objet⟩. Le triplet indique qu'une relation identifiée par le prédicat (également connu sous le nom de propriété) est maintenu entre le sujet et l'objet représentant des ressources Web (entités, documents, concepts, etc.).Cette caractéristique d'interconnexion donne à RDF la possibilité de lier des triplets de différents ensembles de données via leur IRIs (International Resource Identifiers). Le résultat de la fusion des triplets constitue une Graphe de Connaissances (KG). Pour interroger les ensembles de données RDF et les KGs, le W3C a défini SPARQL[START_REF] Seaborne | SPARQL 1.1 overview[END_REF] comme langage de requête standard. SPARQL permet d'exprimer des requêtes sur divers ensembles de données.La popularité de RDF est due à sa flexibilité, simplicité et disponibilité d'un langage de requête. Aujourd'hui, les graphes de connaissances (KGs) sont devenus des moyens populaires pour les chercheurs académiques et industrielles pour capturer, représenter et exploiter des connaissances structurées. Cette variété et la richesse de KGs a motivé des chercheurs d'autres domaines à les intégrer dans les différentes phases de leur cycle de vie.La course aux Triple Stores efficacesAvec l'essor des graphes de connaissances, deux problèmes se posent: (i) stockage scalable et (ii) accès efficace aux KGs. Les systèmes en charge du stockage et de l'accès aux triplets sont appelés Triple Stores. Ces systèmes peuvent être classés en deux groupes principaux: non-native et native.Non-native Ces systèmes choisissent des solutions de stockage existantes pour construire leurs triple stores. Les systèmes de gestion de bases de données relationnelles (SGBDR) ont été largement utilisés pour concevoir de tels systèmes. Les premiers systèmes stockent les triplets dans une seule tabledetrois colonnes (sujet S, prédicat P et objet O). Pour réduire le nombre d'auto-jointures induites par cette approche, d'autres systèmes utilisent une table plate appelée table de propriétés. Cette table stocke chaque propriété dans des colonnes différentes. Cette stratégie de stockage génère le problème des valeurs nulles et des contraintes pour représenter des propriétés à valeurs multiples. Pour surmonter les inconvénients ci-dessus, certains systèmes partitionnent verticalement la table de propriétés en L fragments (où L représente le nombre de prédicats). Chaque fragment est associé à un prédicat et composé de deux colonnes (sujet, objet).

	Introduction

•

  La définition d'un Framework, appelé RDFPartSuite. Il soutient notre vision dans la conception de triple stores centralisés et parallèles. RDFPartSuite peut être personnalisé en fonction du type de plateforme et il suit le paradigme en dehors d'un SGBD[START_REF] Ordonez | Can we analyze big data inside a dbms?[END_REF], dans lequel tous les efforts techniques sont effectués en externe. En fonction du type de plateforme deux scénarios sont possibles:1. Si la plateforme est centralisée, notre framework active le module fragmenteur en charge du partitionnement des triples en fonction de leur représentation logique. 2. Lorsque la plate-forme est distribuée ou parallèle, le fragmenteur envoie le schéma de fragmentation obtenu au composant allocateur. Ce dernier attribue les différents fragments aux noeuds de la plate-forme cible. Une fois le schéma d'allocation obtenu, le composant dispatcher envoie la description détaillée de ce schéma à différents noeuds, puis charge les triplets en fonction de leurs définitions. 3. Des outils d'assistance (langage de manipulation de fragments et assistant automatique de partitionnement) sont proposés pour aider les gestionnaires dans leurs tâches.

	Objectif principal	Adaptabilité
	Algorithme
			Mécanisme
	Type
	Partitionnement	Modèle de coût
	Modèle de données		Élément du système
	Contraintes	Plateforme

• La définition d'un ensemble d'entités logiques (appelées fragments de graphe) utilisées pour effectuer la fragmentation d'ensembles de données RDF au niveau logique dans des environnements centralisés et parallèles. • Le déploiement de ce framework sur le module de chargement d'un système centralisé (RDF QDAG [KMG + 20]) et d'un triple store distribué (gStoreD [PZ Ö+ 16]).

  TypeCette dimension décrit les façons alternatives de diviser une table en plus petites parties. Deux alternatives sont clairement visibles: la diviser horizontalement ou verticalement. Un troisième type de partitionnement nommé hybride est une combinaison des techniques de partitionnement précédentes. En bref, les entités logiques sont représentées sous forme de relations (tables) dans le modèle relationnel. Chaque relation regroupe des ensembles de tuples qui sont des instances d'une entité logique qui sont représentées par un ensemble d'attributs.Le partitionnement horizontal a été exploré plus largement par les SGBD et il en existe de nombreuses versions. Tout d'abord, nous distinguons les partitions horizontales effectuées dans une seule table nommée partitionnement horizontal simple. Plusieurs modalités de partitionnement sont implémentes:• Partitionnement par plage: une relation est divisée en fonction d'une plage de valeurs pour un ensemble donné d'attributs.

4.

21. Les dimensions avec une double bordure dans cette Figure correspondent à celles définissant le problème de partitionnement de base. Nous organisons les approches de partitionnement dans ce chapitre en utilisant les dix dimensions détaillées ci-dessous qui sont utilisées comme critères de diversification. Ces schéma est utilisé pour organiser les travaux étudiés dans ce chapitre.

•

  Le clustering fait référence au partitionnement dans des systèmes de base de données centralisés et distribués. Dans les premiers systèmes, le partitionnement des données cherche à minimiser les coûts de transfert entre la mémoire primaire et la mémoire secondaire en récupérant les enregistrements ou les attributs pertinents à la demande de l'utilisateur. Dans les systèmes de bases de données distribuées, l'objectif principal est d'éviter les communications réseau coûteuses en localisant les exécutions aux noeuds du système distribué où résident les données. Dans les deux cas, les données sont regroupées pour former des groupes de tuples ou d'attributs qui sont généralement récupérés ensemble.Trouver le bon ensemble de partitions s'est avéré être un problème très complexe. Le problème de partitionnement horizontal s'est avéré être NP hard [SW85, SW83], de même que le problème de trouver des partitions verticales appliquant un graphe d'affinité. Le partitionnement horizontal et vertical ont été formalisés mathématiquement et posés comme des problèmes d'optimisation dont la solution est trouvée grâce à l'utilisation d'heuristiques. Nous classons les algorithmes en: (i) Solutions exactes et (ii) Heuristiques.Pour évaluer objectivement si une stratégie de partitionnement améliore les performances du système de base de données, un ensemble de métriques est établi pour définir les critères qui déterminent un système performant. Après tout, sans une métrique bien définie, il est impossible de décider quelle alternative de partitionnement est meilleure qu'une autre. De plus, les modèles de coûts sont essentiels pour prédire les coûts d'exécution réels d'une requête a priori, sans l'évaluer réellement. Les modèles de coûts offrent une vision simplifiée d'un système et sont liés aux objectifs décrits avant. Nous classons les modèles de coûts comme suit: (i) Basé sur le temps de réponse, (ii) Basé sur le débit, (iii) Basé sur la maintenance et (iv) Coût global du système.

	Résumé
	Algorithme
	Modèle De Coût

• La stratégies de declustering est préférée par les systèmes de base de données parallèles où il n'est pas nécessaire de maximiser le traitement local à chaque noeud. Le partitionnement des données dans les systèmes parallèles se traduit par un compromis entre maximiser le temps de réponse pour chaque requête individuelle mais au prix d'une asymétrie d'exécution ou maximiser le parallélisme intra-requête.

  Au début des années 2000, la nécessité d'incorporer, de stocker et d'interroger de grandes quantités de données sur le Web, avec différentes sources, formats et à moindre coût, a contribué au développement de nouveaux types d'outils de gestion des données. Les systèmes basés sur le modèle relationnel, en particulier les bases de données parallèles, évoluent et peuvent gérer de vastes volumes de données, comme le montre [PPR + 09]. Cependant, le modèle relationnel est trop rigide pour s'adapter à la variabilité des sources et des formats de données actuelles. De plus, étant donné que le schéma de données est rarement disponible au préalable, il est impossible d'effectuer l'étape de conception qui est essentielle lors de la construction d'une base de données relationnelle. Par conséquent, les systèmes appliquant une stratégie schéma-après ont été largement acceptés. Ces systèmes stockent initialement les données dans leur format brut et les analysent lors de l'exécution. Le pionnier présentant un nouvel outil de gestion de données évolutif était Google, introduisant le système de fichiers Google[START_REF] Ghemawat | The Google file system[END_REF] et le modèle de traitement MapReduce[START_REF] Dean | Mapreduce: Simplified data processing on large clusters[END_REF]. Leurs travaux ont servi de base à Hadoop, l'un des frameworks de données à grande échelle les plus populaires jusqu'à aujourd'hui. Dans cette section, nous commençons à donner un bref aperçu de Hadoop en mettant l'accent sur la stratégie de partitionnement appliquée par ce framework. Ensuite, nous expliquons et détaillons les systèmes les plus pertinents construits sur Hadoop et décrivons leurs stratégies de partitionnement.Le stockage dans Hadoop est géré par le composant Hadoop Distributed File System (HDFS).Le HDFS est un système de stockage de données distribué basé sur une architecture maîtreesclave. HDFS est conçu pour stocker des données structurées et non structurées de manière évolutive, hautement disponible et tolérante aux pannes. Les fichiers sont divisés en blocs d'une taille configurable (128 Mo par défaut) qui sont distribués et stockés entre les noeuds de données. Pour garantir la tolérance aux pannes et l'équilibrage de charge, les blocs de données du même fichier sont répliqués et stockés sur différents noeuds. Le noeud de nom (maître) gère le système de fichiers et régule l'accès des blocs de fichiers aux emplacements à l'aide des métadonnées du fichier.Lorsqu'un fichier est importé dans HDFS, il est divisé séquentiellement en petits blocs d'une taille de stockage fixe. Chaque bloc est répliqué en un nombre fixe personnalisable de copies et une fonction de hachage est utilisée pour distribuer les données aux noeuds. Cette stratégie est assez simple et permet de distribuer les données contrôlant son équilibre. Cependant, il ne prend pas en compte le schéma des données et il peut produire des frais généraux de réseau à la récupération.

	Partitionnement dans l'écosystème Hadoop

  ConclusionDans ce chapitre, nous avons d'abord donné un aperçu général du modèle de données orientées graphes. Nous avons détaillé ses structures logiques et de stockage, les stratégies de traitement des requêtes, ses langages de requêtes, et enfin nous avons détaillé certains systèmes actuels. Nous avons vu les avantages du modèle mais aussi ses limites, notamment en raison de la variabilité des méthodes utilisées pour le partitionnement et traitement de données. Ensuite, nous nous sommes concentrés sur RDF. Nous avons donné quelques concepts de base, et aussi décrit les stratégies de stockage, de traitement et de partitionnement. Le partitionnement dans les triple stores dépend de l'organisation physique des données (c'est-à-dire stockées dans une seule table, une table de propriétés ou une liste adjacente). Nous avons montré que les stratégies de partitionnement RDF sont dépendantes aux systèmes. De plus, contrairement aux bases de données relationnelles, il n'y a pas de couche logique commune. Le partitionnement de données RDF est piloté par le système, contrairement au partitionnement dans les bases de données relationnelles où il est piloté par les données. Dans les bases de données relationnelles, il existe des outils (par exemple, des systèmes automatiques de partitionnement, langages de définition) qui permettent au concepteur de base de données de créer des partitions en fonction de la structure des tables ou d'un schéma de partitionnement qui répond aux exigences d'une certaine charge de requêtes.

	Relationnel	RDF
	-L'intégration des données avec différents
	schémas est complexe.

Il n'y a pas de consensus sur la façon dont les données RDF devraient être distribuées. La plupart des solutions actuelles utilisent le triple comme unité de fragmentation. Cependant,il a été affirmé que le regroupement des triples en premier pourrait améliorer les performances en découvrant des structures implicites dans le graphe RDF [BDK + 13, SGK + 08]. Par conséquent, d'autres solutions proposent de regrouper d'abord les triplets par sujet, prédicat ou objet et d'utiliser ces groupes comme unités de fragmentation.

• Allocation: L'étape de l'attribution consiste à trouver la distribution d'un ensemble de fragments {F 1 , ..., F n } (qui sont le résultat de l'étape précédente) pour un ensemble de sites {S 1 , ..., S m }. La distribution des fragments se fait en appliquant les techniques suivantes: fonction de hachage, round-robin ou dépendant de la plateforme cloud.

• Réplication: La réplication des données est une stratégie d'optimisation fréquente mais pas obligatoire appliquée par plusieurs systèmes distribués RDF. Il permet également la tolérance aux pannes dans ces systèmes.

1

  Partitioning advisors in [Bel18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 High-level variants of the partitioning problem . . . . . . . . . . . . . . . . . . . 1.2 Partitioning type by DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Partitioning approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Vertical partitioning approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5 Single-attribute horizontal declustering strategies . . . . . . . . . . . . . . . . . . 1.6 Multi-attribute declustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7 Recent horizontal partitioning approaches . . . . . . . . . . . . . . . . . . . . . . 1.8 Partitioning advisors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.9 Online partitioning approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.10 Partitioning approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Dynamic graph partitioning approaches . . . . . . . . . . . . . . . . . . . . . . . 2.2 Graph databases mentioned in Section 2.2.6 . . . . . . . . . . . . . . . . . . . . . 2.3 State of the art systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Main strenghts relational and RDF partitioning . . . . . . . . . . . . . . . . . . . 3.1 Edge's weights in fragment graph G . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Experimental datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Loading times comparisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Data coverage per dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Experimental datasets in relational-based system . . . . . . . . . . . . . . . . . . 4.5 Watdiv BGP queries results in seconds . . . . . . . . . . . . . . . . . . . . . . . . 4.6 LUBM500M BGP queries results in seconds . . . . . . . . . . . . . . . . . . . . . 4.7 DBLP BGP queries results in seconds . . . . . . . . . . . . . . . . . . . . . . . . 4.8 Execution time (in seconds) for Watdiv100M queries . . . . . . . . . . . . . . . . 4.9 Execution time (in seconds) for LUBM queries . . . . . . . . . . . . . . . . . . . 4.10 Execution time (in seconds) for DBLP and YAGO queries . . . . . . . . . . . . . XVII Résumé Le Resource Description Framework (RDF) et SPARQL sont des standards très populaires basés sur des graphes initialement conçus pour représenter et interroger des informations sur le Web. La flexibilité offerte par RDF a motivé son utilisation dans d'autres domaines. Aujourd'hui les jeux de données RDF sont d'excellentes sources d'information. Ils rassemblent des milliards de triplets dans des Knowledge Graphs qui doivent être stockés et exploités efficacement.

:

  Database design; Database management; Graph theory; Knowledge graph; RDF (Document markup language); SPARQL (Computer program language); Logic design; Expert systems (Computer science); Performance Secteur de recherche : Informatique et applications Laboratoire d'Informatique et d'Automatique pour les Systèmes Ecole Nationale Supérieure de Mécanique et d'Aérotechnique Téléport 2 -1 avenue Clément Ader -BP 40109 -86961 FUTUROSCOPE CHASSENEUIL CEDEX Tél : 05.49.49.80.63 -Fax : 05.49.49.80.64

This triple is a part of DBpedia's Knowledge Graph.

A part of a KG: http://example.org/Guillaume

https://lod-cloud.net/

Transparency is associated to the data partitioning

https://db-engines.com/en/ranking/rdf+store

Taken from the Oxford dictionary

Decomposing the query into smaller tasks that execute concurrently on multiple processors.

Several queries execute concurrently on multiple processors to improve the overall throughput of the system.

http://glaros.dtc.umn.edu/gkhome/metis/hmetis/overview

https://docs.oracle.com/database/121/VLDBG/GUID-E864E9E2-0456-4FB5-860B-44444337D7D8.htm

https://hive.apache.org/

https://pig.apache.org/

https://cwiki.apache.org/confluence/display/Hive/HCatalog

https://spark.apache.org/

https://mahout.apache.org/

https://redis.io/

https://hbase.apache.org/

https://www.mongodb.com/

https://tinkerpop.apache.org/

https://pgql-lang.org/

https://spark.apache.org/

https://neo4j.com/

https://dgraph.io/

https://virtuoso.openlinksw.com/

https://www.stardog.com

https://azure.microsoft.com/en-us/services/cosmos-db/

https://aws.amazon.com/neptune/

https://orientdb.com/

https://www.arangodb.com/

https://www.stardog.com/

https://rocksdb.org/

https://spark.apache.org/

https://hadoop.apache.org/

https://hbase.apache.org/

https://wiki.dbpedia.org/about/facts-figures

https://www.lod-cloud.net/dataset/bio2rdf-pubmed

From this point we use the abbreviation RDFDS to denote both, parallel and distributed RDF systems

According to the correctness fragmentation rules in[ ÖV11]

Available at https://github.com/bnu05pp/gStoreD

http://vos.openlinksw.com/owiki/wiki/VOS

https://gitlab.db.in.tum.de/dbtools/rdf3x

https://github.com/pkumod/gStore

Availabe at: https://www.gurobi.com/downloads/gurobi-optimizer-eula/

https://docs.oracle.com/cd/E18283_01/server.112/e16541/part_admin001.htm

https://www.postgresql.org/docs/10/ddl-partitioning.html

https://www.elsevier.com/connect/new-article-type-verifies-experimental-reproducibility

https://www.internetlivestats.com/

Services web RESTful pour exposer les données RDF interrogées avec SPARQL

Dans cette thèse, nous présentons une vision qui inclut le processus de conception des triple stores. Notre vision peut être réutilisée/adaptée aux contextes d'autres types de données existants qui existent aujourd'hui (par exemple, les graphes de propriétés) ou des modèles de données qui sont encore à venir.

Acknowledgements

{ "nb_version,nb_motors" :{ "4" : { "nb_version" :[A340], "nb_motors" :[Airplane1, Airplane2] },}, "nb_version" :{ "5" : {"nb_version" :[B747] }}, "has_city,office_in" :{ "Chicago" :{"has_city" :[USA], "office_in" :[Boeing]}, "Toulouse" :{"has_city" :[ France],"office_in" :[Airbus] }}, ... } (b) Backward graph fragments stored in adjacency list The solution to the query getting the average number of motors in an entity could be solved by scanning only the backward graph fragment storing triples with the predicate nb_motors. The execution engine checks which characteristic sets contain the given predicate and scans only the backward graph fragment (nb_version, nb_motors) ←-Gb 5 that gathers 3 triples. Comparing to the result obtained when the data are organized as forward graph fragments, the execution process on the backward fragments is more efficient. The process saves, in this case, the resources used to scan 7 triples. However, as it is the case for vertical partitions in the relational model, the performance can be degraded for SPARQL queries joining many single patterns.

Combining forward and backward fragments Some queries require to join several forward or backward graph fragments to find a solution.

For example, let us consider the query Q 3 :

SELECT ?y ?z WHERE { ?x :has_model :A340 . ?x :has_length ?y . ?x :manufacturer ?m . ?m :has_seat ?z . ?z :has_city "Toulouse" . } If the data are physically stored as forward graph fragments, the query can be solved scanning at least 3 candidate sets as shown in Figure 3.8a. In this example, we start by scanning the fragments whose characteristic set contains the predicates has_model, manufacturer and has_length. The results of this matches are joined with the candidate fragments assigned to the nodes with outgoing edges in the query. On the other side, if the data are stored physically as backward graph fragments, the execution would involve many more joins. A candidate set of fragments is needed for each node with incoming edges in the query graph as shown in Figure 3.8b. Even if a backward graph fragment would be much more efficient to find the bounded value in the fifth query pattern of Q 3 , the great number of joins needed impairs the overall performance. To fix this problem, a strategy presented in Section 3.4 considers storing the data using both types of physical fragments. The execution schema for Q 3 using this strategy is

Dynamic optimization strategies

Today there are many very efficient main-memory distributed triple stores. In these stores, fast dynamic optimizations to the data distribution can be considered. These optimizations may consider query streams to decide on re-partitioning or replication strategies. A component can be added to our framework to deal specifically with this online reorganization.

Reproducibility of our framework to other types of data

In this thesis we present a vision that includes the design process of triple stores. Our vision can be reused/adapted to the contexts of other existent data types that exist today (e.g., property graphs) or data models that are yet to come.

A repository for data partitioning findings

In presenting our thesis, we did our best to promote the idea of reproductivity of the strong points of data partitioning in the traditional databases (deployed in centralized and parallel infrastructures) in RDF stores. If we deepen our analysis, the development of a repository (a knowledge graph-like) containing all findings of data partitioning in both traditional and RDF databases will be a great asset for students, academia, industry, developers of Open Sources systems, just to name a few. These findings have to be associated with their scientific papers and/or the systems implementing them. Such a repository will allow any user to navigate through different dimensions of this repository to find their needs. This repository can be complementary to a traditional survey.

Résumé

Un référentiel pour les résultats de partitionnement de données

En présentant notre thèse, nous avons fait de notre mieux pour promouvoir l'idée de reproductivité des points forts du partitionnement de données dans les bases de données traditionnelles (déployées dans des infrastructures centralisées et parallèles) dans les triple stores. Si nous approfondissons notre analyse, le développement d'un référentiel (un graphe de connaissances) contenant toutes les conclusions du partitionnement des données dans les bases de données traditionnelles et RDF sera un grand atout pour les étudiants, les universités, l'industrie, les développeurs de systèmes Open Sources, pour n'en nommer que quelques-uns.

Appendix A Logic fragmentation example

A.1 Raw data & encoding <:Airplane1> <:has_model> <:A340> . <:Airplane1> <:has_length> "75.4" . <:Airplane1> <:nb_motors> "4" . <:Airplane1> <:type> <Airliner> . <:Airplane1> <:manufacturer> <Airbus> . <:Airplane2> <:has_model> <:B747> . <:Airplane2> <:has_length> "70.1" . <:Airplane2> <:nb_motors> "4" . <:Airplane2> <:type> <Airliner> . <:Airplane2> <:manufacturer> <Boeing> . <:Airbus> <:office_in> "Toulouse" . <:Airbus> <:has_seat> <:France> . <:Boeing> <:office_in> "Chicago" . <:Boeing> <:has_seat> <:USA> . <:USA> <:has_city> "Chicago" . <:France> <:has_city> "Toulouse" . <:B747> <:nb_version> "5" . <:A340> <:nb_version> "4" . @prefix pr: <http://purl.org/stuff/rev#> @prefix prg: <http://purl.org/goodrelations/> @prefix foaf: <http://xmlns.com/foaf/> @prefix sc: <http://schema.org/> @prefix prt: <http://purl.org/dc/terms/> @prefix pro: <http://purl.org/ontology/mo/> @prefix rdfs: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> @prefix w: <http://db.uwaterloo.ca/~galuc/wsdbm/> @prefix ogp: <http://ogp.me/ns#> @prefix geo: <http://www. @prefix foaf: <http://xmlns.com/foaf/0.1#> @prefix el: <http://purl.org/dc/elements/1.1#> @prefix o: <http://swrc.ontoware.org/ontology#> @prefix te: <http://purl.org/dc/terms#> @prefix owl: <http://www.w3.org/2002/07/owl#> @prefix dblp: <http://dblp.uni-trier.de/rec/bibtex/series/cogtech/> @prefix rdfs: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> @prefix book: <http://dblp.l3s.de/d2r/resource/publications/books/ph/> @prefix author: <http://dblp.l3s. de

Predicate