IP Library › Granted Patent US 12,229,135
Granted Patent B2
US 12,229,135 · App. 17/699,607 · Granted Feb 18, 2025

Workload-aware data placement advisor for OLAP database systems

Inventors: Urvashi Oswal (Fremont, CA); Jian Wen (Hollis, NH); Farhan Tauheed (Zurich, CH); Onur Kocberber (Thalwil, CH); Seema Sundara (Nashua, NH); Nipun Agarwal (Saratoga, CA)
Assignee: Oracle International Corporation
G06F16/24544G06F11/3409G06F16/211G06F16/2282G06F16/278
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 12,229,135
App. No.
17/699,607
Granted
Feb 18, 2025
Kind
B2
Abstract

Embodiments implement a prediction-driven, rather than a trial-driven, approach to automatic data placement recommendations for partitioning data across multiple nodes in a database system. The system is configured to extract workload-specific features of a database workload running at a database system and dataset-specific features of a database running on the database system. The workload-specific features characterize utilization of the database workload. The dataset-specific features characterize how data is organized within the database. The system identifies a plurality of candidate keys for determining how to partition data stored in the database across nodes. Based at least in part on the workload-specific features, the dataset specific features, and the plurality of candidate keys, a set of candidate key combinations for partitioning data is generated. Using a machine learning model, determine a particular candidate key combination that optimizes query execution performance benefit based on the workload-specific features and the dataset specific features. Generate data placement commands to allocate the database tables across the nodes.

Claims (47)

1. A method comprising:

extracting one or more workload-specific features of a database workload running at a database system and one or more dataset-specific features of a database running on the database system;

wherein the one or more workload-specific features of the database workload characterize resource utilization of the database workload;

wherein the one or more dataset-specific features of the database characterize how data is logically organized within the database running on the database system;

identifying a plurality of candidate keys for determining how to partition data stored in the database across two or more computing nodes running the database system;

based at least in part, on the one or more workload-specific features, the one or more dataset-specific features, and the plurality of candidate keys, generating a set of candidate key combinations for partitioning data in the database over two or more computing nodes;

determining, using a machine-learning model, a particular candidate key combination from the set of candidate key combinations that optimizes query execution performance benefit based on the one or more workload-specific features and the one or more dataset-specific features of the database; and

generating one or more data placement commands to allocate one or more database tables of the database across the two or more computing nodes.

2. The method of claim 1 , wherein the one or more workload-specific features comprise at least one of: query execution times, a list of join tables, a list of group by tables, join attributes of tables, join keys for each table, table types, network compute times, actual size of data transferred over a network for each join operation and each group by operation, and heuristic-estimated size of data transferred over the network for each of the join operations and each of the group by operations.

3. The method of claim 1 , wherein the one or more dataset-specific features comprise at least one of: table cardinality, data placement type, actual number of distinct values in each column of the tables in the database, and estimated number of distinct values in each column of the tables in the database.

4. The method of claim 1 , further comprising, prior to identifying the plurality of candidate keys, receiving database execution logs for the database running on the database system;

wherein the database execution logs are post-execution logs comprising executed queries on the data system and their associated query plans; and

wherein the associated query plans include candidate keys from sets of join keys for each join operation and sets of group by keys for each group by operation.

5. The method of claim 4 , wherein the plurality of candidate keys represent at least one of a join key from a join operation recorded in the database execution logs, and a group by key from a group by operation recorded in the database execution logs.

6. The method of claim 1 , wherein the machine-learning model is a linear regression model.

7. The method of claim 1 , further comprising training the machine-learned model using a training corpus with data representing a plurality of different database workloads, including a plurality of different workload-specific features, a plurality of different dataset-specific features, a plurality of different database schemas, and a plurality of performance metrics associated with the plurality of different database workloads.

8. The method of claim 1 , wherein determining the particular candidate key combination from the set of candidate key combinations comprises, for each candidate key combination in the set of candidate key combinations:

calculating a first performance benefit for join operations based on a particular data placement, wherein the particular data placement is based upon the candidate key combination;

calculating a second performance benefit for group by operations based on the particular data placement; and

aggregating the first performance benefit and the second performance benefit to generate an overall performance benefit for the candidate key combination.

9. The method of claim 8 , further comprising:

determining the particular candidate key combination from the set of candidate key combinations that has the highest overall performance benefit.

10. The method of claim 1 , further comprising pruning a subset of candidate key combinations, from the set of candidate key combinations, that have join sizes below a minimum join size threshold.

11. The method of claim 1 , further comprising pruning a subset of candidate key combinations, from the set of candidate key combinations, that cause a skew of data that is above a data skew threshold.

12. The method of claim 1 , further comprising executing the one or more data placement commands to cause partitioning of data in the one or more database tables of the database and loading the partitioned data into the two or more computing nodes.

13. One or more non-transitory computer-readable media storing instructions which, when executed by one or more processors, cause:

extracting one or more workload-specific features of a database workload running at a database system and one or more dataset-specific features of a database running on the database system;

wherein the one or more workload-specific features of the database workload characterize resource utilization of the database workload;

wherein the one or more dataset-specific features of the database characterize how data is logically organized within the database running on the database system;

identifying a plurality of candidate keys for determining how to partition data stored in the database across two or more computing nodes running the database system;

based at least in part, on the one or more workload-specific features, the one or more dataset-specific features, and the plurality of candidate keys, generating a set of candidate key combinations for partitioning data in the database over the two or more computing nodes;

determining, using a machine-learning model, a particular candidate key combination from the set of candidate key combinations that optimizes query execution performance benefit based on the one or more workload-specific features and the one or more dataset-specific features of the database; and

generating one or more data placement commands to allocate one or more database tables of the database across the two or more computing nodes.

14. The one or more non-transitory computer-readable media of claim 13 , wherein the one or more workload-specific features comprise at least one of: query execution times, a list of join tables, a list of group by tables, join attributes of tables, join keys for each table, table types, network compute times, actual size of data transferred over a network for each join operation and each group by operation, and heuristic-estimated size of data transferred over the network for each of the join operations and each of the group by operations.

15. The one or more non-transitory computer-readable media of claim 13 , wherein the one or more dataset-specific features comprise at least one of: table cardinality, data placement type, actual number of distinct values in each column of the tables in the database, and estimated number of distinct values in each column of the tables in the database.

16. The one or more non-transitory computer-readable media of claim 13 storing additional instructions which, when executed by the one or more processors, further cause:

prior to identifying the plurality of candidate keys, receiving database execution logs for the database running on the database system;

wherein the database execution logs are post-execution logs comprising executed queries on the data system and their associated query plans; and

wherein the associated query plans include candidate keys from sets of join keys for each join operation and sets of group by keys for each group by operation.

17. The one or more non-transitory computer-readable media of claim 16 , wherein the plurality of candidate keys represent at least one of a join key from a join operation recorded in the database execution logs, and a group by key from a group by operation recorded in the database execution logs.

18. The one or more non-transitory computer-readable media of claim 13 storing additional instructions which, when executed by the one or more processors, further cause training the machine-learned model using a training corpus with data representing a plurality of different database workloads, including a plurality of different workload-specific features, a plurality of different dataset-specific features, a plurality of different database schemas, and a plurality of performance metrics associated with the plurality of different database workloads.

19. The one or more non-transitory computer-readable media of claim 13 , wherein determining the particular candidate key combination from the set of candidate key combinations comprises, for each candidate key combination in the set of candidate key combinations:

calculating a first performance benefit for join operations based on a particular data placement, wherein the particular data placement is based upon the candidate key combination;

calculating a second performance benefit for group by operations based on the particular data placement; and

aggregating the first performance benefit and the second performance benefit to generate an overall performance benefit for the candidate key combination.

20. The one or more non-transitory computer-readable media of claim 19 storing additional instructions which, when executed by the one or more processors, further cause:

determining the particular candidate key combination from the set of candidate key combinations that has the highest overall performance benefit.

Assignments (1)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Mar 21, 2022
From: OSWAL, URVASHI; WEN, JIAN; TAUHEED, FARHAN; KOCBERBER, ONUR; SUNDARA, SEEMA; AGARWAL, NIPUN
To: ORACLE INTERNATIONAL CORPORATION
Reel/Frame 059325/0943 →
Continuity (1)
Related Publication 20230297573A1 · Sep 21, 2023
References Cited (31)
US 10489215B1 · Wen · 2019 [cited by applicant]
US 10554738B1 · Ren · 2020 [cited by applicant]
US 10606649B2 · Baggerman · 2020 [cited by applicant]
US 20100153956A1 · Capps, Jr. · 2010 [cited by applicant]
US 20140006383A1 · Hacigumus · 2014 [cited by examiner]
US 20150154255A1 · Cole · 2015 [cited by examiner]
US 20160004621A1 · Gongloor · 2016 [cited by applicant]
US 20170068675A1 · Hazel · 2017 [cited by applicant]
US 20180096000A1 · Harrison · 2018 [cited by examiner]
US 20180107711A1 · Tariq · 2018 [cited by applicant]
US 20190340095A1 · Faibish · 2019 [cited by applicant]
US 20200034197A1 · Nagpal · 2020 [cited by applicant]
US 20200125545A1 · Idicula · 2020 [cited by examiner]
US 20200125568A1 · Idicula · 2020 [cited by applicant]
US 20210081453A1 · Eadon · 2021 [cited by examiner]
Paiva, Joao, et al., “AutoPlacer: Scalable Self-Tuning Data Placement in Distributed Key-value Stores”, 10th Intl Conf on Autonomic Computing (ICAC 13), pp. 119-131, USENIX Association, Jun. 2013, 13pgs. [cited by applicant]
Breitbach, Martin, et al., “Context-Aware Data and Task Placement in Edge Computing Environments”, 2019 IEEE Intl Conf on Pervasive Computing and Communctns (PerCom), pp. 1-10, https://doi.org/10.1109/PERCOM.2019.876738… [cited by applicant]
Duan et al., “Tuning Database Configuration Parameters with iTuned”, VLDB dated 2009, 12 pages. [cited by applicant]
Duggan, et al., ‘Performance Prediction for Concurrent Database Workloads’, p. 337-348, SIGMOD'11, Jun. 12-16, 2011, Athens, Greece, 12pgs. [cited by applicant]
Ganapathi, A. et al. “Predicting multiple performance metrics for queries: Better decisions enabled by machine learning”, ICDE 2009, 12 pages. [cited by applicant]
Hilprecht, Benjamin, et al., “Learning a Partitioning Advisor with Deep Reinforcement Learning”, https://doi.org/10.48550/arXiv.1904.01279, Apr. 2, 2019, 13pgs. [cited by applicant]
B. Debnath et al., SARD: A statistical approach for ranking database tuning parameters. In ICDEW, pp. 11-18, dated 2008. [cited by applicant]
Nehme, Rimma, et al., “Automated Partitioning Design in Parallel Database Systems”, Proceedings of the 2011 ACM SIGMOD Intl Conf on Mgmt of Data, pp. 1137-1148, https://doi.org/10.1145/1989323.1989444, Jun. 12, 2011, 12… [cited by applicant]
Zilio, D.C.A. “DB2 design advisor: integrated automatic physical database design” VLDB dated 2004, Proceedings of the Thirtieth international conference on Very large data bases, 11 pages. [cited by applicant]
Parchas, Panos, et al., “Fast and Effective Distribution-Key Recommendation for Amazon Redshift”, Proceedings of the VLDB Endowment, https://doi.org/10.14778/3407790.3407834, 13(12), pp. 2411-2423, Jul. 1, 2020, 13pgs. [cited by applicant]
Pavlo, Andrew, et al., “Skew-aware automatic database partitioning in shared-nothing, parallel OLTP systems”, Proceedings of the 2012 ACM SIGMOD Intl Conf on Mgmt of Data, pp. 61-72, https://doi.org/10.1145/2213836.2213… [cited by applicant]
Rabl, Tilmann, et al., “Query Centric Partitioning and Allocation for Partially Replicated Database Systems”, Proceedings of the 2017 ACM Intl Conf on Mgmt of Data, http://dx.doi.org/10.1145/3035918.3064052, pp. 315-330… [cited by applicant]
Reif et al., “Meta-learning for evolutionary parameter optimization of classifiers, Machine Learning”, dated 2012, 24 pages. [cited by applicant]
Sullivan et al., “Using probabilistic reasoning to automate software tuning”, In SIGmetrics, dated 2004, 13 pages. [cited by applicant]
Van Aken et al., “Automatic Database Management System Tuning Through Large-scale Machine Learning,” Proceedings of the 2017 ACM International Conference on Management of Data, 2017, pp. 1009-1024. [cited by applicant]
Narayanan et al., “Continuous resource monitoring for self-predicting DBMS”, IEEE International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems, 2005, 10 pages. [cited by applicant]