ETL so much faster than SQL at joining
Not so much a question but a statement of my experience with DOMO
I am not a SQL person (if that is a thing). I had only been using SQL to join datasets where ETL would run into the 10 000 repeats limit that would prevent it from running a Left Join.
I later realised that you cna go around the 10000 limit by using a Right Join but at that stage I already had some dataflows using SQL to do some joints.
In an attempt to see if I could speed up some dataflows (or series of dataflows) I tried right joining instead of SQL and the difference quite remarkables.
1 data set went from 22min to 3 min, another from 3 min to 40 sec.
I would recommend trying this to anyone looking at reducing processign times, or just normal practice.
Comments
-
Hi @rado98,
A reason for that drop in run time could be because the dataset that is on the "right" of the join could have significantly less rows than on the left, thus bringing through less rows in total, less rows to process later in the ETL, etc. Have you noticed a drop in row count in the ETLs where you've changed from a Left Join to a Right Join?
This blog post explains the differences between an inner join, left join and right join very well.
Regards,
Eric
0 -
Hi
The operatinos are escentially the same and the outputs is exactly the same.
Joining usign SQL 22min
Joining using Magic ETL 3min
0 -
In our experience MySQL is a little tricky to optimize with indexing, so we have switched to redshift which handles the indexing for us, and we have seen dramatic speed increase even over ETLs. Redshift also has the added benifit of choosing only the columns you want to bring in on the input itself which has sped up our queries as well.
0 -
The reason for that is more of an underlying structural component of DOMO. When you run SQL statements there are two things that DOMO does or doesn't do that impacts the run time of the SQL.
First, the resources it applies to the SQL run is not as great as the resources that are applied to anything that is run in the ETL.
The other component, which is the real impact is that when the SQL is running it basically runs in order, so the first step is running, everything else waits until its finished, then it steps down to the next layer.
When its running in the ETL, DOMO has designed their system to truely optimize all resources, meaning that almost all of the processes run at the same time, some finishing sooner than others and then compiles the results when all are done.
If you take a look at a running ETL process you will see all of the components showing as running or completed and there is no specific order in which they appear, the last in the line could be the first to finish.
So yes, the ETL by design is much faster.
Hope that helps explain what is going on in the background and why there is such a difference in the run time of complex routines.
Randy
0
Categories
- All Categories
- 1.8K Product Ideas
- 1.8K Ideas Exchange
- 1.5K Connect
- 1.2K Connectors
- 300 Workbench
- 6 Cloud Amplifier
- 8 Federated
- 2.9K Transform
- 100 SQL DataFlows
- 616 Datasets
- 2.2K Magic ETL
- 3.8K Visualize
- 2.5K Charting
- 738 Beast Mode
- 56 App Studio
- 40 Variables
- 684 Automate
- 176 Apps
- 452 APIs & Domo Developer
- 46 Workflows
- 10 DomoAI
- 36 Predict
- 15 Jupyter Workspaces
- 21 R & Python Tiles
- 394 Distribute
- 113 Domo Everywhere
- 275 Scheduled Reports
- 6 Software Integrations
- 123 Manage
- 120 Governance & Security
- 8 Domo Community Gallery
- 38 Product Releases
- 10 Domo University
- 5.4K Community Forums
- 40 Getting Started
- 30 Community Member Introductions
- 108 Community Announcements
- 4.8K Archive