Take Data Migration to the Next Level Using Dexecutor
Take Data Migration to the Next Level Using Dexecutor
See how you can use Dexecutor to migrate your data in parallel to avoid long wait times and delays.
Join the DZone community and get the full member experience.
Join For FreeMariaDB TX, proven in production and driven by the community, is a complete database solution for any and every enterprise — a modern database for modern applications.
Say you have a data migration process that updates your application from version X to X+1 by running migration scripts (each script consists of a sequence of instructions) sequentially to bring the application to a desired state.
Problem
The synchronous process is causing delays, leading to unproductive wait times and dissatisfaction from users. There is a need to run tasks in parallel wherever applicable to come to the desired state.
Driving Forces
The following are driving forces behind Dexecutor.
- Supports parallel execution, conditionally may revert to sequential execution (if such logic is provided)
- Ultra light (Version 1.1.1 is 44KB)
- Ultra fast
- Distributed Execution supported
- Immediate/Scheduled Retry logic supported
- Non-terminating behavior supported
- Conditionally skip the task execution
Solution
Incorporate Dexecutor into your script execution logic — additionally distribute the execution using Infinispan, Hazelcast, or Ignite. Here is the sample application that demonstrates this functionality. Fork it and have fun!
Dexecutor can be used in this case easily by adding algorithmic logic on top of Dexecutor, which builds the graph based on table names. Let's assume the following scripts:
Script 1 ==> operates on Tables t1 and t2 and takes 5 minute
Script 2 ==> operates on Tables t1 and t3 and takes 5 minute
Script 3 ==> operates on Tables t2 and t4 and takes 5 minute
Script 4 ==> operates on Tables t5 and t6 and takes 5 minute
Script 5 ==> operates on Tables t5 and t7 and takes 5 minute
Script 6 ==> operates on Tables t6 and t8 and takes 5 minute
Normally these scripts are executed sequentially as follows.
Script 1 5 minutes
|
V
Script 2 5 minutes
|
V
Script 3 5 minutes
|
V
Script 4 5 minutes
|
V
Script 5 5 minutes
|
V
Script 6 5 minutes
Total time 30 minutes In a sequential case, your total execution time would be 30 minutes. However, if we could parallelize the script execution and make sure scripts are executed in right sequence and order, then we could save time, decreasing the total execution time to just 10 minutes.
+----------+ +----------+
| Script 1 | | Script 4 | ==> 5 minutes
+----+----------+--+ +----+----------+-----+
| | | |
| | | |
+-----v----+ +-----v----+ +----v-----+ +------v---+
| Script 2 | | Script 3 | | Script 5 | | Script 6 | ==> 5 minutes
+----------+ +----------+ +----------+ +----------+
Total Time 10 minutesUsing Dexecutor, we just have to write the algorithm, which facilitates building graph using the API exposed by Dexecutor, and the rest would be taken care by Dexecutor.
MigrationTasksExecutor implements that algorithm, considering the SQL in the migration scripts. Because table names in the SQL play a crucial role in building the graph, we need an efficient, ultra light, and ultra fast library to extract table names out of the SQL, and hence, we would use sql-table-name-parser. Use it by adding the following dependency in your POM.
<dependency>
<groupId>com.github.mnadeem</groupId>
<artifactId>sql-table-name-parser</artifactId>
<version>0.0.2</version>
</dependency>And of course, Dexecutor should be added as dependency as well
<dependency>
<groupId>com.github.dexecutor</groupId>
<artifactId>dexecutor-core</artifactId>
<version>LATEST_VERSION</version>
</dependency>The graph, that would be built, considering the migration script is the following:
As can be seen here, nodes base1, base3, and base 4 run in parallel and once one of them finishes, their children are executed. For example, if node base1 is finished, then its children base2 and app3-1 are executed, and so on.
Notice that for node app2-4 to start, app1-4 and app2-1 must finish. Similarly, for node app3-2 to start, app3-1 andapp2-4 must finish.
Just run this class to see how things proceed.
Conclusion
We can indeed run dependent/independent tasks in easy and reliable way with Dexecutor.
References
MariaDB AX is an open source database for modern analytics: distributed, columnar and easy to use.
Like This Article? Read More From DZone
Published at DZone with permission of Mohammad Nadeem , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}