Object to NoSQL Database Mappers (ONDM): A systematic survey and comparison of frameworks

Abstract

Context: Software applications frequently interact with database systems to persist and retrieve objects. Objectmapping frameworks address (i) the bi-directional conversion of data between object and target database and (ii) provide a programmatic interface for querying and storing data. The rise of NoSQL databases poses challenges beyond object-relational mapping (ORM) frameworks to abstract from various data models and non-standardized API's, but also take into account the different database capabilities (e.g. unsupported query operators, data ordering). Objective: A systematic survey study of existing Object-NoSQL data mapping (ONDM) frameworks. Specific focus is given to the level of abstraction of data and operations to multiple database technologies, as a means to limit vendor and technology lock-in and an enabler for multi-store and polyglot architectures. Additional attention is paid to mapping strategies that are specific to NoSQL databases (e.g. object embedding, schema flexibility). Method: A systematic search methodology identifies all relevant mapping frameworks (in total 342 frameworks). Subsequently, a subset of ONDM frameworks is selected and systematically compared in terms of criteria of: database support, interface and query functionality, architecture and software coupling. Secondly, we provide an in-depth comparison of object-oriented mapping strategies for classes, inheritance, relationships, and attribute types to NoSQL data models. Results: ONDM frameworks are most prevalent in Java, Ruby, Python, and overall 54 frameworks support multiple NoSQL databases. Interfaces are frequently standardized and commonly feature a uniform query language and even native DB query mapping. However, database portability may be hindered due to non-uniform abstractions. As for mapping strategies, current frameworks do not fully exploit NoSQL modeling potential, such as (i) the embedding of relationship data within referring objects' records, (ii) mapping at the individual object-level vs. class-level, and lacking (iii) collection normalization despite being supported for associations or when using relational databases. Conclusion: The study consolidates knowledge on available ONDM frameworks, and applied object-document, object-graph, and object-column mapping patterns. The study can guide practitioners in framework selection, and pinpoints areas of future development and research in this domain, most notably towards improved support for flexible, NoSQL-aware mapping strategies.

Research on Financial Data Query and Distribution Scheme Based on SQL Database

“…The allocation clusters have performed the allocation, in which communication costs within need to be defined and clarified. In addition, for the above definition, the internal equation is included as shown in [21,22]…”

A Bi-Directional Engine for Transformation of Big Data Between NoSQL and SQL Data

“…The advantage of MongoDB is that it is open-sourced document stored data model that can provide storage support for all kinds of data (SD, SSD, USD, or big data) efficiently [17,18]. Data are stored in document format, and the data is stored in a collection that supports JSON 1 and BSON 2 types of complex data types.…”

Metadata-driven Data Migration from Object-relational Database to NoSQL Document-oriented Database

“…In addition, several object-NoSQL data-mapping (ONDM) frameworks have been developed for the migration of an object-oriented database to NoSQL [27]. As an example, the Hibernate OGM framework (OMG) [16] supports the migration of an object-oriented database to three types of NoSQL stores: MongoDB documentoriented, Neo4j graph-oriented, and Infinispan key-value databases.…”

“…However, the tremendously increasing volume of multiple data types (multimedia, embedded data, etc.) makes ORDBMS very complex, and its performance degrades rapidly [27]. Also, the data heterogeneity and rigid schema introduce a storage problem when the data to be inserted is not adequate [20].…”