OrientDB Teleporter: Making Migrations Easier (Part 1)
OrientDB Teleporter: Making Migrations Easier (Part 1)
To help with migrations to their NoSQL database, OrientDB has unveiled its Teleporter tool. See the use cases and how it works!
Join the DZone community and get the full member experience.Join For Free
RavenDB vs MongoDB: Which is Better? This White Paper compares the two leading NoSQL Document Databases on 9 features to find out which is the best solution for your next project.
Big Data is an important topic nowadays. The large amount of data and their unstructured and heterogeneous nature have exposed the limitations of the relational database model.
In order to restrict these barriers in recent years, the NoSQL movement was born, which proposed new procedural and architectural approaches. Among these technologies are graph databases, innovative databases which organize and manage information in a graph structure, applied in the representation of complex networks such as social ones.
Despite the wide variety of new solutions, we are often reluctant to switch to new technologies for several reasons. First of all, migration from the old DB to the new one. Migration requires substantial costs and takes considerable time because the task is usually commissioned to specialized companies who perform it manually and individually for the customer.
This reality prompted the OrientDB team to develop Teleporter. Teleporter is a free tool that allows an automated and quick migration from a relational database to the OrientDB graph database.
Teleporter was conceived to satisfy various requirements:
Ensure high versatility, in order to make the import ductile and effective for different use cases.
Provide a low configuration level in order to be quickly usable and offer a certain degree of customization to the process by allowing different strategies and approaches that permit users to overcome the automatic nature of the tool.
Ensure high scalability.
Problem: How can we achieve an automatic migration between two DBMSs that manage data in different ways? The answer is by defining an effective and efficient mapping between the two models in question: the relational and the graph model.
The whole process consists of four phases:
Source DB Schema Building (E-R model): The source DB schema is built by querying the source DB metadata.
Graph Model Building: A correspondent and coherent graph model are built.
OrientDB Schema Writing: The OrientDB schema is written according to the graph model just built.
OrientDB importing: Importing data from the source DB to the graph database of OrientDB.
Below is an OrientDB Teleporter execution dump:
The graph model's expressive power allows it to perform various optimizations based on the aggregation of data. For this reason, Teleporter provides two different import strategies:
The naive strategy follows a direct transformation approach between the E-R model of the source DB and the correspondent Graph Model, in which:
Each entity (or table) with its attributes is converted in a "Vertex-Type" (an OrientDB vertex class).
Each relationship between two entities is converted in an "Edge-Type" (an OrientDB edge class).
This strategy is fast and requires fewer transformation rules. Nevertheless, a certain degree of redundancy is permitted.
As you can see in the following example, in the relational model, the only function of the film_actor join table is to represent a many-to-many relationship between movies and actors, which in OrientDB has been converted into a Vertex-Type.
Thus, the second strategy aggregates complex relationships into "aggregator-edges," simplifying the structure of the resulting graph model.
In this way, even if this strategy requires more transformation rules, we obtain an overhead reduction and better performance on the graph imported in OrientDB.
The following example shows how two different strategies can be used on the same source DB to aggregate data. On the left, there's a naive translation of tables, and on the right, an optimized naive-aggregate solution.
Sequential Executions and One-Way Synchronizer
Teleporter is conceived to support many sequential executions from the same source DB to the same graph DB of OrientDB, in this way you can:
Personalize your import, combining the different strategies and settings by including or excluding the chosen tables and by running Teleport more times in order to obtain a more complex and customized import strategy.
Use it as a one-way synchronizer and maintain a copy of your DB: All the changes applied to the source DB (primary DB) are propagated to the imported graph DB, but not vice versa.
Thus if you want your data to remain synchronized, you only have to perform the write operations on the primary database, but you can perform the reads on both databases.
Teleporter currently offers other features adoptable during the import process:
Inheritance relationships inference.
Filters based on white-list and black-list policies.
Auto-rename of all elements in the source DB according to the Java convention.
Driver JDBC auto-configuration.
Output Manager with five different verbosity levels.
These will be shown and discussed in the next posts.
Teleporter is a tool written in Java, but it can be used more broadly thanks to the teleporter.sh script (or.bat on Windows).
oteleporter.sh -jdriver <jdbc-driver> -jurl <jdbc-url> -ourl <orientdb-url> [-juser <username>] [-jpasswd <password>] [-s <strategy>] [-nr <name-resolver>] [-v <verbose-level>] ([-include <table-names>] | [-exclude <table-names>] [-inheritance <orm-technology>:<ORM-file-url>]
The main arguments necessary for migration are:
-jdriver is the driver name of the DBMS from which you want to execute the import.
-jurl is the JDBC URL giving the location of the source DB to import.
-juser is the username to access the source DB.
-jpasswd is the password to access the source DB.
-ourl is the URL for the destination Orient graph DB.
Through the argument "-s," we can choose the strategy adopted during the importing phase. If not specified, naive-aggregate strategy is adopted. Possible values:
Naive: performs a "naive" import of the data source. The data source schema is translated semi-directly in a correspondent and coherent graph model.
Naive-aggregate: performs a "naive" import of the data source. The data source schema is translated semi-directly in a correspondent and coherent graph model using an aggregation policy on the join tables.
In the following example, we'll import the source DB "testdb" from a PostgreSQL DBMS to OrientDB through the naive strategy:
oteleporter.sh -jdriver postgresql -jurl jdbc:postgresql://localhost:5432/testdb -juser username -jpasswd password -ourl plocal:$ORIENTDB_HOME/databases/testdb -s naive
Teleporter is compatible with all the RDBMS that have a JDBC driver. We have successfully tested Teleporter with:
Oracle (last tested version: 12c)
SQLServer (last tested version: SQLServer 2014)
MySQL (last tested version: 5.1.35)
PostgreSQL (last tested version: 9.4-1201)
HyperSQL (last tested version: 2.3.2)
Teleporter manages all the necessary type conversions for these DBMSs during the import process.
Published at DZone with permission of Gabriele Ponzi . See the original article here.
Opinions expressed by DZone contributors are their own.