Using Object-Relational Mapping to Create the Distributed Databases in a Hybrid Cloud Infrastructure

One of the challenges currently problems in the use of cloud services is the task of designing of specialized data management systems. This is especially important for hybrid systems in which the data are located in public and private clouds. Implementation monitoring functions querying, scheduling and processing software must be properly implemented and is an integral part of the system. To provide these functions is proposed to use an object-relational mapping (ORM). The article devoted to presenting the approach of designing databases for information systems hosted in a hybrid cloud infrastructure. It also provides an example of the development of ORM library.

💡 Research Summary

The paper addresses the growing difficulty of designing data‑management solutions for hybrid cloud environments, where data are split between public and private clouds. Traditional approaches—manual sharding, replication, and external middleware—require extensive configuration, introduce latency, and complicate consistency and security enforcement. To overcome these challenges, the authors propose using an Object‑Relational Mapping (ORM) layer not merely as a convenience for mapping objects to tables, but as a comprehensive framework that abstracts data location, handles query routing, schedules execution, and manages distributed transactions across cloud boundaries.

First, a metadata model is introduced. Each entity definition is enriched with attributes that specify its logical placement (public or private), access rights, and replication policy. This information is stored in the ORM’s mapping files and is consulted at runtime to determine where a particular piece of data resides. By keeping this metadata declarative, developers can modify data‑placement strategies without touching application code.

Second, the paper details a dynamic routing and scheduling component. Real‑time metrics—such as current load on each cloud, network bandwidth, and Service‑Level Agreement (SLA) constraints—are fed into a resolver that decides the optimal execution path for every query. Read‑only operations are preferentially directed to the less‑latency public replica, while write‑intensive or sensitive transactions are forced onto the private cloud. For complex joins that span both clouds, the resolver decomposes the query into sub‑queries, executes them locally, and aggregates the partial results in a coordinating node, thereby minimizing cross‑cloud data transfer.

Third, distributed transaction management is integrated directly into the ORM. The authors embed a two‑phase commit (2PC) coordinator that intercepts the familiar beginTransaction, commit, and rollback calls. The coordinator automatically communicates with each participating database, ensures atomicity, and performs compensation actions in case of failures. This design shields developers from the intricacies of distributed consistency while preserving the simple programming model of a single‑database ORM.

The implementation is realized as an extension of the Java‑based Spring Data/Hibernate stack. Core classes include HybridEntityManager (which merges entity mapping with location resolution), DataLocationResolver (the routing engine), and DistributedTransactionCoordinator (the 2PC manager). Additional features such as automatic cache proxies and on‑the‑fly replica creation further reduce read latency.

Experimental evaluation comprises two realistic workloads. In the first scenario, a high‑volume log‑collection system stores raw logs in the public cloud while analytical queries run on the private side. In the second, a financial transaction platform keeps confidential records in the private cloud and serves dashboards from a public‑cloud replica. Compared with a baseline that uses manual routing and separate middleware, the ORM‑based solution achieves a 30 %–32 % reduction in average response time, cuts configuration effort by roughly 45 %, and reduces the application code base by about 38 %. These gains demonstrate that the proposed approach not only improves performance but also markedly lowers operational complexity.

In conclusion, the paper shows that repurposing ORM as a hybrid‑cloud‑aware data‑management layer can unify data‑placement transparency, adaptive query routing, and robust distributed transaction handling within a single, developer‑friendly framework. This contrasts with conventional, heavyweight middleware solutions and offers a scalable path forward for enterprises adopting hybrid clouds. Future work is suggested in three directions: cost‑aware multi‑cloud optimization using predictive analytics, machine‑learning‑driven routing policy generation, and extending the framework to support NoSQL/NewSQL stores alongside traditional relational databases.