Mortadelo: Automatic generation of NoSQL stores from platform-independent data models

Highlights

• A NoSQL design process based on a paradigm-independent conceptual data model.

• Physical database models are generated through model transformation techniques.

• Physical database models can be obtained for column family or document databases.

• The generation process can be configured with technology-independent annotations.

• Design quality is not compromised to achieve genericity.

Abstract

In the last decade, several NoSQL systems have emerged as a response to the scalability problems manifested by classical relational databases when used in Big Data contexts. These NoSQL systems appeared first as physical-level solutions, initially lacking any design methodologies. After this initial batch of systems, several design methodologies for NoSQL have been recently created. Nevertheless, most of these methodologies target just one NoSQL paradigm. In addition, as each methodology uses a different conceptual modeling approach, NoSQL database designers would need to remake conceptual models as they switch from one NoSQL paradigm to another. Moreover, most of these design processes provide just a set of design heuristics and guidelines that database designers need to apply manually, which can be a time-consuming and error-prone process. To overcome these limitations, this article presents Mortadelo, a model-driven NoSQL database design process where, from a high-level conceptual model, independent of any specific NoSQL paradigm, an implementation for a concrete NoSQL database system can be automatically generated. Moreover, this database generation process can be customized, so that some design trade-offs can be managed differently according to each context needs. We evaluated Mortadelo’s capabilities by generating database implementations for several typical NoSQL case studies. In these cases, Mortadelo was able to generate implementations for the Cassandra and MongoDB NoSQL systems from the same conceptual data model. These implementations were similar to the ones generated by design methodologies specifically developed for a single paradigm. Therefore, design quality is not sacrificed by our approach in favor of generality.

Introduction

Nowadays, several kinds of software systems have pushed relational databases to their limits. Examples of these new kinds of applications are internet-scale applications, such as Twitter or Amazon; Internet of Things (IoT) applications, such as Smart Cities [1], [2]; Industry 4.0 systems [3], [4]; or Big Data systems [5], [6]. All these systems need to manage large volumes of data that are often distributed in several servers and assure low response times and high availability in the contexts of a high number concurrent requests. In these scenarios, relational databases have manifested different scalability problems [7].

In response to these limitations, a new generation of database management systems, denoted as NoSQL systems [8], started to offer some alternatives. Each one of these alternatives was designed for a specific purpose and following a different approach. So, NoSQL is not just a single alternative to relational databases, but a global term that comprises different database strategies, including, among others, document-oriented databases [9], [10], key–value stores [11], [12] or column family stores [13], [14]. Despite their differences, most NoSQL database systems rely on two common features: (1) they make use of data denormalisation to improve response times [15], and (2) they sacrifice some ACID (Atomicity, Consistency, Isolation, and Durability) properties [7], [16] to increase scalability, while providing other less restrictive properties but also useful in a best-effort approach, such as eventual consistency [17].

These NoSQL technologies emerged first at the implementation level and, consequently, they initially lacked well-defined design processes. Database design methodologies for relational databases [18], which are usually based on conceptual modeling notations such as ER (Entity-Relationship) [19] or UML (Unified Modeling Language) [20], revealed soon to be not enough for designing NoSQL databases. To take advantage of the benefits provided by data nesting and denormalisation, database designers need to take into account not only which data will be stored in the database, but also how these data will be accessed [21], [22]. In NoSQL systems, working with the same set of data, but with different data access patterns, might lead to different database implementations. This is due to the fact that, in many NoSQL systems, design decisions are driven by how data will be accessed. Traditional database design approaches do not provide an adequate support for these issues, mainly because they were created to satisfy other goals, e.g., the commented ACID properties [16].

To address this gap, several design methodologies for NoSQL systems have been created in the last years [21], [22], [23], [24]. Nevertheless, these approaches still present some limitations, which can be summarized as follows:

• Each one of these approaches focuses on a concrete NoSQL paradigm, providing its own conceptual modeling languages and notations. This implies that the same conceptual data model cannot be used to describe the same database in different NoSQL paradigms.

• Most approaches describe how to design a NoSQL database by means of guidelines or heuristics that must be interpreted and applied manually by database designers. This can be an error-prone and time-consuming process. Just two approaches [21], [24] address design process automation and provide the basis for building CASE tools.

• Those approaches that tackle automation often use the same strategy to transform the patterns they found at the conceptual level into constructs of the target database. Therefore, they neglect the existence of alternative strategies that might be more adequate in certain contexts, or when targeting different NoSQL paradigms, e.g., document-based or column family stores.

To overcome these limitations, we present Mortadelo, a model-driven development process for NoSQL database design. This process builds on previous work and goes one step further by being able to automatically generate implementations for different NoSQL paradigms from the same conceptual model. The generation process is achieved by means of model transformation and code generation techniques. Currently, we have created and implemented model transformation rules for supporting the generation of column family stores and document databases, but the framework could be extended to support other paradigms, such as key–value stores.

To evaluate the expressiveness and effectiveness of our approach, we used Mortadelo to model different case studies used as test-beds in the NoSQL literature. We compared the generated NoSQL databases with the databases obtained with state-of-the-art NoSQL design methodologies. The results of this evaluation process showed that, using Mortadelo, the same conceptual model can be transformed into either a column family database, implemented in Cassandra [25]; or a document database, expressed in MongoDB [9]. Moreover, the obtained databases were pretty similar to those generated by design methodologies devised specifically for one NoSQL paradigm. In some cases, our approach performed even better, and, in one case, our designs might not be as good as the ones generated by other approaches. Moreover, our approach offers several transformation alternatives, so the same conceptual model might be handled differently depending on each concrete context. This feature is scarcely supported by NoSQL design methodologies.

The remaining of this article is structured as follows. Section 2 presents the running example used throughout the paper, and introduces to the used NoSQL technologies. Next, in Section 3, related works are discussed. In Section 4, we detail the different phases of the transformation process followed by Mortadelo to generate NoSQL databases. Section 5 includes the evaluation of Mortadelo. Lastly, we expose our conclusions and future work in Section 6.