Materialized view generation and provision based on queries with semantic equivalence or inclusion relationships

Abstract

Embodiments described herein relate to generating and returning materialized views for queries (or sub-expressions) having specific relationships with one another. For example, machine learning-based techniques may be utilized to identify query sub-expressions that have at least one of a semantic equivalence relationship or an inclusion relationship with each other. In response to identifying such relationship (s), a materialized view may be generated for the identified sub-expressions. When a subsequent query is received, a machine learning-based technique may be utilized to determine whether a sub-expression of the query has at least one of a semantic equivalence relationship or an inclusion relationship with another sub-expression for which the materialized view has been generated. In response to determining that this sub-expression of the query has one or more such relationships, a materialized view generated for another sub-expression is returned.

Description

Background Art

[0001] Continued advances in technology have enabled large amounts of data to be generated and retained in data repositories. For example, modern databases may include several petabytes of data, most of which are retained in large base tables. Despite the increasing computing power, executing specific queries against these base tables may require a significant amount of time. Therefore, various tools (such as view materialization) have been developed to help reduce the time required to execute queries against a database. Summary of the invention

[0002] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0003] The methods, systems, devices, and computer-readable storage media described herein are configured to generate and return materialized views for queries (or sub-expressions) that have specific relationships with each other. For example, machine learning-based techniques can be utilized to identify query sub-expressions that have at least one of a semantic equivalence relationship or a containment relationship with each other. In response to identifying such (multiple) relationships, a materialized view can be generated for the identified sub-expressions. When a subsequent query is received, machine learning-based techniques can be utilized to determine whether a sub-expression of the query has at least one of a semantic equivalence relationship or a containment relationship with another sub-expression for which a materialized view has been generated. In response to determining that such a sub-expression of the query has one or more such relationships, a materialized view generated for the other sub-expression is returned.

[0004] Other features and advantages of various example embodiments and structures and operations are described in detail below with reference to the accompanying drawings. It should be noted that the example embodiments are not limited to the specific embodiments described herein. Such example embodiments are presented herein for illustrative purposes only. Based on the teachings contained herein, additional embodiments will be apparent to those skilled in the relevant art(s). BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate example embodiments of the present application and, together with the description, further serve to explain the principles of the example embodiments and enable those skilled in the relevant art to make and use the example embodiments.

[0006] Figure 1 A block diagram of an example network-based computing system configured to generate and return materialized views according to an example embodiment is shown;

[0007] Figure 2depicts a block diagram of a system for generating a materialized view according to an example embodiment;

[0008] Figure 3 A flowchart of a method for generating a materialized view according to an example embodiment is shown;

[0009] Figure 4 A flow chart of a method for generating a machine learning model according to an example embodiment is shown; the machine learning model is used to classify a query as having a semantic equivalence relationship or a containment relationship with another query;

[0010] Figure 5 depicts a block diagram of a system for returning a materialized view according to an example embodiment;

[0011] Figure 6 A flowchart of a method for returning a materialized view according to an example embodiment is shown;

[0012] Figure 7 A flowchart of a method for reformulating a query according to an example embodiment is shown;

[0013] Figure 8 is a block diagram of an example processor-based computer system that may be used to implement various embodiments.

[0014] Features and advantages of the embodiments described herein will become more apparent from the detailed description set forth below in conjunction with the accompanying drawings, in which like reference numerals identify corresponding elements throughout. In the accompanying drawings, like figure numbers generally indicate identical, functionally similar, and / or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding figure number. DETAILED DESCRIPTION I. introduce

[0015] This specification and the accompanying drawings disclose many example embodiments. The scope of the present application is not limited to the disclosed embodiments, and also includes combinations of the disclosed embodiments and modifications to the disclosed embodiments. References in the specification to "one embodiment", "an embodiment", "an example embodiment", "an example embodiment", etc. indicate that the described embodiment may include specific features, structures, or characteristics, but each embodiment may not necessarily include the specific features, structures, or characteristics. In addition, such phrases do not necessarily refer to the same embodiment. In addition, when specific features, structures, or characteristics are described in conjunction with a specific embodiment, whether or not explicitly described, it is considered that it is within the knowledge of a technician in (multiple) related fields to implement such features, structures, or characteristics in conjunction with other embodiments.

[0016] In the discussion, unless otherwise stated, adjectives such as "substantially" and "about" that modify conditions or relational characteristics of one or more features of embodiments of the present disclosure should be understood to mean that the condition or characteristic is defined within an acceptable tolerance for the operation of the embodiment for its intended application.

[0017] In addition, it should be understood that the airspace descriptions used herein (e.g., "above," "below," "up," "left," "right," "down," "top," "bottom," "vertical," "horizontal," etc.) are for illustrative purposes only and that actual implementations of the structures described herein may be arranged in any orientation or manner on the airspace.

[0018] A number of example embodiments are described below. Note that any section / subsection headings provided herein are not intended to be limiting. Implementations are described throughout this document, and any type of implementation may be included under any section / subsection. In addition, implementations disclosed in any section / subsection may be combined in any manner with any other implementations described in the same section / subsection and / or in different sections / subsections. II. Example Implementations

[0019] Embodiments described herein relate to generating and returning materialized views for queries (or sub-expressions) that have specific relationships with each other. For example, machine learning-based techniques may be utilized to identify query sub-expressions that have at least one of a semantic equivalence relationship or a containment relationship with each other. In response to identifying such (multiple) relationships, a materialized view may be generated for the identified sub-expressions. When a subsequent query is received, machine learning-based techniques may be utilized to determine whether a sub-expression of the query has at least one of a semantic equivalence relationship or a containment relationship with another sub-expression for which a materialized view has been generated. In response to determining that such a sub-expression of the query has one or more such relationships, a materialized view generated for the other sub-expression is returned.

[0020] By returning materialized views of sub-expressions that are semantically equivalent to other sub-expressions or have a containment relationship, the number of instances of materialized views provided is increased, and the number of instances of query execution is reduced. Executing a query requires several steps. For example, the execution of a query requires generating a query plan, optimizing the query plan, and executing the optimized query plan. Such steps require many computing resources (e.g., processing cycles, memory, power supply, etc.). However, the use of materialized views avoids the execution of queries because the data to be returned has been pre-calculated. Therefore, the embodiments described herein improve the functionality of the computing device on which the technology described herein is implemented, thereby saving computing resources.

[0021] Current methods for generating and returning materialized views are limited because they only identify syntactically identical expressions and are not scalable. The embodiments described herein extend such methods by generating and returning materialized views based on expressions that are semantically equivalent to or have a containment relationship with other expressions. In addition, machine learning-based techniques that require relatively small seed training sets are utilized to identify such relationships, thereby enabling such techniques to be extended to a variety of computing environments, including but not limited to cloud-based computing environments that are configured to process hundreds of thousands of queries and maintain large amounts (e.g., petabytes) of data. In addition, the techniques described herein do not require changes to the query optimizer implemented by the database application, which are typically cumbersome to modify due to their complex nature.

[0022] For example, Figure 1 1 is a block diagram of an example network-based computing system 100 configured to generate and return materialized views according to an example embodiment. Figure 1 As shown, system 100 includes a plurality of clusters 102A, 102B, and 102N and a storage cluster 124. Each of clusters 102A, 102B, and 102N and storage cluster 124 are communicatively coupled to each other via a network 116. Network 116 may include one or more networks, such as a local area network (LAN), a wide area network (WAN), an enterprise network, the Internet, etc., and may include one or more of wired and / or wireless portions.

[0023] Clusters 102A, 102B, and 102N and / or storage cluster 124 may form a network-accessible set of servers (e.g., a cloud-based environment). Each of clusters 102A, 102B, and 102N may include a set of one or more nodes (also referred to as compute nodes) and / or a set of one or more storage nodes. Figure 1 As shown, cluster 102A includes nodes 108A-108N, cluster 102B includes nodes 112A-112N, and cluster 102N includes nodes 114A-114N. Each of nodes 108A-108N, nodes 112A-112N, and / or nodes 114A-114N is accessible via network 116 (e.g., in a "cloud-based" embodiment) to build, deploy, and manage applications and services. Storage cluster(s) 124 includes one or more storage nodes of storage nodes 110A-110N, each of which includes multiple physical storage disks accessible via network 116 and is configured to store data associated with applications and services managed by nodes 108A-108N, nodes 112A-112N, and / or nodes 114A-114N.

[0024] like Figure 1As shown, the storage node 110A may include one or more data sets 122 respectively. In an embodiment, (multiple) data sets 122 include databases and / or other similar data sets, which may be very large data sets such as those used for "big data" analysis and / or data warehouses. It is contemplated herein that, in an embodiment, (multiple) data sets 122 are of the order of petabytes or higher. (Multiple) data sets 122 may include multiple data files. A data file may include structured relational data organized as rows of a table, with columns for data. Examples of data files include, but are not limited to, database files, blocks, groups of one or more rows of a table (i.e., row groups, partitions, etc.). According to an embodiment, (multiple) data sets 122 are part of the same database and / or may be distributed between (multiple) storage nodes 110A-110N.

[0025] In embodiments, one or more of the clusters 102A, 102B, and 102N and / or storage node(s) 110A-110N may be co-located (e.g., housed in one or more nearby buildings along with associated components such as backup power, redundant data communications, environmental controls, etc.) to form a data center, or may be arranged in other ways. Thus, in embodiments, one or more of the clusters 102A, 102B, and 102N and / or storage nodes 110A-110N may be a data center in a distributed collection of data centers.

[0026] Each of the node(s) 108A-108N, nodes 112A-112N, and nodes 114A-114N may include one or more server computers, server systems, and / or computing devices. Each of the node(s) 108A-108N, nodes 112A-112N, and nodes 114A-114N may be configured to execute one or more software applications (or "applications") and / or services and / or manage hardware resources (e.g., processors, memory, etc.) that may be utilized by users (e.g., clients) of the network-accessible set of servers. The node(s) 108A-108N, nodes 112A-112N, and nodes 114A-114N may also be configured for specific purposes. For example, Figure 1As shown, node 108A may be configured to execute database server application 118, and node 108N may be configured to execute materialized view engine 130. It should be noted that instances of database server application 118 and / or materialized view 130 may be executed on other node(s) (e.g., node(s) 108B-108N, node(s) 112A-112N, and / or node(s) 114A-114N), respectively, instead of or in addition to nodes 102A and 108N. It should also be noted that materialized view 130 may be incorporated into another application, such as database server application 118.

[0027] Node 108A (or any other node executing an instance of database server application 118) may be a control node configured to act as a query endpoint for an incoming query to generate a distributed plan (e.g., an execution graph) for the incoming query and to divide the work of query processing among one or more of compute nodes 108B-108N, nodes 112A-112N, and nodes 114A-114N, wherein, according to an embodiment, node 108A is configured to transform the incoming query into a set of queries that are run for each distribution of the data set in parallel via one or more of nodes 108B-108N, nodes 112A-112N, and nodes 114A-114N.

[0028] Each query may include multiple sub-expressions (or sub-queries) (also referred to herein as "expressions" for simplicity). A sub-expression is a query included in another query statement. The database server application 118 may generate a query plan for each sub-expression. Each query plan includes a series of steps for accessing data (such as (multiple) data sets 122). The series of steps is organized via a tree structure including multiple nodes, where each node may represent a specific query operator (e.g., arithmetic operators, logical operators (e.g., union operations, column predicates, etc.), etc.). The database server application 118 may be configured to store the query plans generated for the query (and its sub-queries) in a query workload repository 126. The workload repository 126 may be configured to store query plans periodically. For example, the workload repository 126 may store query plans generated for queries received by the database server application 118 in the last N hours, days, weeks, months, etc. Therefore, the workload repository 126 stores a historical collection of query plans generated by the database server application 118. The database server application 118 may also be configured to store various runtime statistics associated with query plan executions in the workload repository 126. Examples of runtime statistics include, but are not limited to, the number of rows returned as a result of a particular query plan execution.

[0029] The database server application 118 may be any database server application, including but not limited to the Microsoft Windows® database server application released by Microsoft Corporation of Redmond, Washington. Azure SQL Database TM The database server application 118 is configured to execute statements (eg, based on an incoming query) to create, modify, and delete one or more data files of data tables, indexes, and relationships in the data set(s) 122 .

[0030] The query may be user initiated or automatically generated by one or more background processes. Such a query may be configured to add (multiple) data files, copy (multiple) data files, merge (multiple) data files into a larger data file, reorganize (or re-cluster) (multiple) data files within a particular set of data files (e.g., based on commonalities of (multiple) data files), delete (multiple) data files (e.g., via a garbage collection process that deletes unwanted or obsolete data), etc.

[0031] Materialized view engine 130 is configured to generate a materialized view, which is a pre-computed database object that contains query results. The database object is a copy (or "view") of the query results. The materialized view is stored separately from the base table or (multiple) data sets (e.g., (multiple) data sets 122), where the data was originally collected and derived from a previously executed query. For example, Figure 1 As shown, the materialized view may be stored in any storage node of (multiple) storage nodes 110A-110N (eg, storage node 110N, such as Figure 1 122). When a query for the data maintained by one of the materialized views is subsequently received, the materialized view is retrieved as a query result from the storage device (e.g., storage node 110N) where the view is located. Because the data is pre-computed, querying the materialized view is faster than executing a query on the base table of the view. When the queries are frequently run or are sufficiently complex, the performance difference can be significant. Therefore, materialized views can speed up expensive aggregation, projection, and selection operations, especially those operations that are frequently run and run on large data sets (e.g., (multiple) data sets 122).

[0032] The materialized view engine 130 is configured to generate materialized views for queries (or sub-expressions) that have specific relationships with each other. For example, the materialized view engine 130 can be configured to identify query sub-expressions that have at least one of a semantically equivalent relationship or a containment relationship with each other. In response to identifying such (multiple) relationships, the materialized view engine 130 can generate a materialized view for the identified query. When both sub-expressions produce the same query result but are syntactically different (i.e., the sub-expressions use different syntax (e.g., operators, etc.), but return the same result), the first sub-expression can have a semantically equivalent relationship with the second sub-expression. For example, the code snippets 1 and 2 shown below provide examples of two query sub-expressions (Q1 and Q2) that are semantically equivalent: Q1: Q2:

[0033] As shown above, both Code Snippet 1 and Code Snippet 2 are configured to return identifiers of employees that are not included in a table named MANAGERS (ie, Snippets 1 and 2 are configured to return identifiers of employees that are not managers). Snippets 1 and 2 both accomplish the same task, but differ in syntax.

[0034] A first sub-expression may have a containment relationship with another sub-expression when the result of the first sub-expression is included in the result of the second sub-expression (ie, the result of the first sub-expression is a subset of the result of the second sub-expression).

[0035] For example, code snippets 3 and 4 shown below provide examples of two query sub-expressions (Q1 and Q2) having a containment relationship: Q1: Q2: SELECT_empid,deptname FROM EMP WHERE hire_date>='2016-01-01'; (Clip 4)

[0036] As shown above, the data requested by the query sub-expression Q1 of fragment 3 is configured to receive data that is contained (ie, included) in the data requested by the query sub-expression Q2 of fragment 4.

[0037] When a new query for data is received, the materialized view engine 130 is configured to determine whether a materialized view exists for the query by identifying, from among the materialized views, a materialized view that has been generated for a previously executed query that has at least one of a semantic equivalence relationship or a containment relationship.

[0038] Figure 2 A block diagram of a system 200 for generating a materialized view according to an example embodiment is depicted. Figure 2 As shown, system 200 includes database server application 218, materialized view engine 230, workload repository 226, and materialized view repository 228. Database server application 218 is an example of database server application 118, as described above with reference to Figure 1 Materialized view engine 230 is an example of materialized view engine 130, as described above with reference to Figure 1 The workload repository 226 is an example of the workload repository 126, as described above with reference to Figure 1 The materialized view repository 228 is an example of the materialized view repository 128, as described above with reference to Figure 1 described.

[0039] The database server application 218 is configured to store query plans for queries (and their subqueries) generated by it in the workload repository 226. As described above, the workload repository 226 can be configured to periodically store query plans. The database server application 218 can also be configured to store various runtime statistics associated with query plan execution in the workload repository 226.

[0040] Still like Figure 2As shown, the materialized view engine 230 includes a workload analyzer 202, a characterizer 212, a semi-supervised dataset enhancer 204, a machine learning algorithm 206, a machine learning model 208, a classification validator 210, and a view generator 224. The workload analyzer 202 is configured to analyze past query workloads maintained by a workload repository 226 to determine query sub-expressions for which materialized views should be generated. The workload analyzer 202 can analyze past query workloads within a specific time interval (e.g., query workloads for the last 7 days). In order to determine which query sub-expressions from the workload repository 226 should be analyzed, the workload analyzer 202 can determine sub-expressions issued periodically (e.g., hourly, daily, weekly, etc.) and / or with reference to a subset of tables of interest. If one or more views of a materialized table subset have the potential to significantly reduce the computational cost of the workload (e.g., the number of processor cycles) relative to a threshold, the table subset can be determined to be of interest. For example, assume that the threshold is N processor cycles, where N is a positive value. According to such an example, if executing a subexpression that references a subset of tables would require a number of processor cycles exceeding N, then the workload analyzer 202 may determine that a subset of tables is of interest. Equation 1 provided below illustrates an exemplary metric for determining the importance of a subset of tables. Note that other metrics may be utilized to determine a subset of tables of interest. Where T represents a specific table subset, TS-Weight(T) represents the measure of the relative importance of the table subset, and Q i represents a specific query i, and Cost(Q i ) indicates execution of query Q i. As shown in Equation 1, the summation occurs over queries in the workload where a subset of tables T appears.

[0041] The workload analyzer 202 may be configured to select a subset of sub-expressions maintained by the workload repository 226 that reference a subset of tables of interest for analysis. According to an embodiment, the workload analyzer 202 is configured to select a certain percentage (e.g., 10%) of such sub-expressions. In such an example, if 1000 sub-expressions are determined to be associated with a set of tables of interest, 100 of such sub-expressions will be selected for analysis. The remaining sub-expressions (e.g., shown as remaining sub-expressions 219) are provided to the characterizer 212, which will be described below.

[0042] The workload analyzer 202 may be configured to then determine sub-expression pairs from the subsets having a particular relationship. For example, the workload analyzer 202 may be configured to determine sub-expression pairs that have at least one of a semantically equivalent relationship or a containment relationship with each other, and / or sub-expression pairs that do not have such a relationship. The workload analyzer 202 may be configured to analyze the structure, attributes, and / or syntax of the query sub-expressions included in the subset to determine whether such a relationship(s) may exist.

[0043] After determining the query sub-expression pairs that have a semantically equivalent relationship, a containment relationship, or neither relationship, the workload analyzer 202 may be configured to mark such pairs accordingly. For example, query sub-expression pairs that have a containment relationship may be marked as having a containment relationship, query sub-expression pairs that have a semantically equivalent relationship may be marked as having a semantically equivalent relationship, and query sub-expression pairs that have neither a containment relationship nor a semantically equivalent relationship may be marked as not having such a relationship.

[0044] The labeled query sub-expression pairs are used as a seed set for a machine learning algorithm, which uses the seed set to learn to construct sub-expression pairs with semantic equivalence relationships, sub-expression pairs with inclusion relationships, and sub-expression pairs with neither inclusion relationships nor semantic equivalence relationships.

[0045] Workload analyzer 202 may also be configured to provide the marked sub-expressions (shown as marked sub-expressions 214) to characterizer 212. Characterizer 212 may be configured to extract one or more features from marked sub-expressions 214 and remaining sub-expressions 219. Feature(s) include, but are not limited to, table names referenced by sub-expressions 214 and sub-expressions 219, logical operators utilized by sub-expressions 214 and sub-expressions 219 (e.g., join clauses, column predicates, etc.), etc. Characterizer 212 may also characterize runtime statistics associated with each of sub-expressions 214 and sub-expressions 219. Examples of runtime statistics include, but are not limited to, runtime lengths for executing sub-expressions 214 and sub-expressions 219, the number of rows returned by sub-expressions 214 and sub-expressions 219, etc. Characterizer 212 may obtain runtime statistics from workload repository 226 , or alternatively, workload analyzer 202 may provide runtime statistics for each of sub-expression 214 and sub-expression 219 to characterizer 212 .

[0046] The characterizer 212 may also be configured to generate a feature vector (shown as feature vector 216) for each of the labeled sub-expressions 214 and sub-expressions 219 (shown as feature vector 220) based on the extracted features described above. The feature vectors 216 and feature vectors 220 generated by the characterizer 212 may take any form, such as a numeric, visual, and / or textual representation, or may include any other form suitable for representing the sub-expressions 214 and sub-expressions 219. The characterizer 212 may operate to characterize or generate feature vectors for a given sub-expression of the sub-expressions 214 and sub-expressions 219 in a variety of ways. For example, but not limited to, the characterizer 212 may characterize a given sub-expression of the sub-expressions 214 and sub-expressions 219 through time series analysis, keyword characterization, semantic-based characterization, digit count characterization, and / or n-gram-TFIDF characterization.

[0047] According to an embodiment, the characterizer 212 uses a unique hot encoding to represent each feature of the feature vector of the feature vector 216 of a given sub-expression of the sub-expression 214 and the feature vector 220 of a given remaining sub-expression of the sub-expression 219. Since the number of features (e.g., operators) of a given sub-expression of the sub-expression 214 and the sub-expression 219 can be different, the feature vector generated for one sub-expression of the sub-expression 214 and the sub-expression 219 can have a different length from the feature vector generated for another sub-expression of the sub-expression 214 and the sub-expression 219. As described below, the feature vector 216 and / or the feature vector 220 are input into the machine learning algorithm to perform the classification task. Using a feature vector with a variable length to complete the task may cause the machine learning algorithm to perform inefficiently because it may be difficult to compare feature vectors of different lengths. In order to prevent this, the characterizer 212 is configured to generate the feature vector 216 and the feature vector 220 so that they have the same fixed length. For example, as will be appreciated by those skilled in the relevant art(s), the characterizer 212 may implement this using a tree-based characterization technique, wherein tree-based convolution and dynamic pooling operations are performed with respect to the query graphs representing the sub-expressions 214 and 219 to generate a fixed-length feature vector 216 and a fixed-length feature vector 220. Each feature vector in the feature vectors 216 retains the labeling provided to its associated sub-expression by the workload analyzer 202. The feature vectors 216 and the feature vectors 220 are provided to the semi-supervised dataset enhancer 204.

[0048] The semi-supervised data enhancer 204 is configured to propagate the label to the feature vector pairs 220 of the remaining query sub-expressions 219. For example, the semi-supervised data enhancer 204 may include a semi-supervised machine learning algorithm configured to analyze the labeled feature vector pairs 216 and learn which types of feature vector pairs (e.g., feature vectors 220) received for classification should be labeled as having a semantically equivalent relationship, a containment relationship, or not having both relationships. The semi-supervised data enhancer 204 is configured to propagate the learned label to the corresponding feature vector pairs 220 by utilizing one or more label propagation techniques known to a person of ordinary skill in the relevant field (multiple). For example, a first feature vector pair 220 determined to have a semantically equivalent relationship can be labeled as having a semantically equivalent relationship. A second feature vector pair 220 determined to have a containment relationship can be labeled as having a containment relationship. A third feature vector pair 220 determined to not have both relationships can be labeled as not having a relationship, and so on. Such a technique advantageously automatically generates a seed data set used to train the machine learning algorithm 206, as described below. In this way, the user does not need to mark hundreds or thousands of query sub-expressions as having one of the above relationships. Such techniques also advantageously make the embodiments described herein scalable in a variety of computing environments, including but not limited to cloud-based computing environments that are configured to process hundreds of thousands of queries and maintain large amounts (e.g., petabytes) of data.

[0049] The semi-supervised dataset enhancer 204 is configured to provide the labeled feature vectors 216 and the labeled remaining feature vectors (generally shown as a seed set 222) to the machine learning algorithm 206. The machine learning algorithm 206 receives the feature vector pairs of the seed set 222 labeled as having a semantically equivalent relationship as a first input, receives the feature vector pairs of the seed set 222 labeled as having a containment equivalence relationship as a second input, and receives the feature vector pairs of the seed set 226 labeled as not having a relationship as a third input. The machine learning algorithm 206 learns what kind of sub-expression pairs have a containment equivalence relationship, a semantic equivalence relationship, or no relationship based on the first input, the second input, and the third input, and generates a machine learning model 208 (e.g., including multiple weight parameters). The machine learning algorithm 206 can learn different relationships between sub-expression pairs using a technique based on logistic regression or a technique based on semi-supervision. The machine learning model 208 is used to classify new queries received by the database server application 218.

[0050] According to an embodiment, the accuracy of the classification generated by the machine learning model 206 is verified using the classification verifier 210. The classification verifier 210 can be configured to execute a deterministic semantic equivalence determination algorithm and a deterministic inclusion determination algorithm to determine whether the classification generated by the machine learning model 208 is correct. Examples of semantic equivalence determination algorithms include, but are not limited to, SPES-based algorithms, where in a first stage, sub-expressions are simplified to algebraic representations that are normalized to minimize structural differences, and in a second stage, a verification algorithm is applied to convert the normalized algebraic expressions into query pair symbolic representations, and their equivalence under bag-of-words semantics is proved using satisfiability modulo theory. Examples of inclusion determination algorithms include, but are not limited to, algorithms based on arithmetic comparison.

[0051] Upon successfully verifying that the two query sub-expressions have at least one of a containment relationship or a semantic equivalence relationship, the materialized view generator 224 may generate a materialized view that includes at least a portion of the results generated based on the execution of the two query sub-expressions, and store the materialized view in the view repository 228. For example, if the first query sub-expression and the second query sub-expression are determined to have a semantic equivalence relationship, the view generator 224 may generate a materialized view that includes the results of executing one of the first query sub-expression or the second query sub-expression. In another example, if the first query sub-expression and the second query sub-expression are determined to have a containment equivalence relationship (e.g., the results of the first query are included in the results of the second query), the view generator 224 may generate a materialized view that includes the results of the second query (i.e., the materialized view is generated for a superset).

[0052] According to an embodiment, a materialized view for each pair of seed sets 222 having at least one of a semantically equivalent relationship or a containment relationship can be generated. However, such an embodiment assumes that there are no storage constraints on storing materialized views. According to an embodiment in which storage constraints exist, the view generator 224 can selectively determine which pair of seed sets 222 will have a materialized view generated for it. The determination can be based on runtime statistics associated with such a pair. For example, the determination can be based on the number of processing cycles required to execute (multiple) queries (and return results) for a given pair. If the number of processing cycles is higher than a threshold (i.e., the query is relatively long to execute), the view generator 224 can generate a materialized view for the query. In this way, queries subsequently received that are considered to have a semantically equivalent relationship or a containment relationship with the query will utilize the materialized view instead of having to be executed by the database server application 218, thereby saving a large amount of computing resources (e.g., power, processing cycles, memory, etc.).

[0053] Therefore, materialized views can be generated in many ways. For example, Figure 3300 is a flowchart of a method for generating a materialized view according to an example embodiment. In an embodiment, the flowchart 300 can be implemented by the system 200, such as Figure 2 Therefore, we will continue to refer to Figure 2 To describe the flowchart 300. Figure 2

[0046] Given the discussion of flowchart 300 and system 200, other structural and operational embodiments will be apparent to persons skilled in the relevant art(s).

[0054] Flowchart 300 begins at step 302. In step 302, a plurality of query expressions are extracted from a plurality of previously executed queries. Figure 2 , the workload analyzer 202 is configured to extract a plurality of query expressions (e.g., sub-expressions) from a plurality of previously executed queries stored in the workload repository 226. The queries stored in the workload repository 226 were previously executed by the database server application 218. The workload analyzer 202 can extract the query expressions from the query plans maintained by the workload repository 226.

[0055] In step 304, a plurality of pairs of query expressions are determined from a subset of the plurality of query expressions. Each pair of query expressions in the plurality of pairs of query expressions has at least one of a semantic equivalence relationship or a containment relationship with respect to each other. For example, referring to Figure 2 , the workload analyzer 202 determines multiple pairs of query expressions from a subset of multiple query expressions. For example, the workload analyzer 202 can determine query expressions that reference a set of tables of interest. Among the query expressions determined in this way, the workload analyzer 202 can analyze a certain percentage thereof to determine that the query expression pairs have at least one of a semantic equivalence relationship or an inclusion relationship with respect to each other. The workload analyzer 202 can mark such query expression pairs as having one or more such relationships or having no such relationship. As described above, the semi-supervised data enhancer 204 can be configured to utilize semi-supervised machine learning techniques to generate labels for the remaining query expression pairs that are not marked by the workload analyzer 202.

[0056] In step 306, for each pair of query expressions in the determined multiple pairs of query expressions, a materialized view of the results generated based on the execution of at least one query expression in the determined query expression pair is generated. Figure 2 The view generator 224 may generate a materialized view for each pair of query expressions in the determined multiple pairs of query expressions.

[0057] In step 308, each materialized view is stored in a storage device. Figure 2 , the view generator 224 stores the generated materialized view in the view repository 228 .

[0058] Figure 4 400 is a flowchart of a method for generating a machine learning model for classifying a query as having a semantically equivalent relationship or a containment relationship with another query according to an example embodiment. In an embodiment, flowchart 400 can be implemented by system 200, such as Figure 2 Therefore, we will continue to refer to Figure 2 To describe the flowchart 400. Figure 2

[0046] Given the discussion of flowchart 400 and system 200, other structural and operational embodiments will be apparent to those skilled in the relevant art(s).

[0059] Flowchart 400 begins at step 402. In step 402, for each pair of query expressions in the determined plurality of pairs of query expressions, a feature vector is generated based on each query expression in the pair of query expressions. Figure 2 , characterizer 212 generates feature vector 216 and feature vector 220 , which correspond to corresponding pairs of query expressions determined by workload analyzer 202 .

[0060] According to one or more embodiments, each feature vector includes at least one of the following: a table name referenced by each corresponding query expression of each pair of query expressions, one or more logical operators specified by each corresponding query expression of each pair of query expressions, or the number of rows retrieved via the execution of each corresponding query expression of each pair of query expressions. Figure 2 , each of feature vectors 216 and feature vectors 220 includes features representing at least one of: a table name referenced by each corresponding query expression of each pair of query expressions, one or more logical operators specified by each corresponding query expression of each pair of query expressions, or a number of rows retrieved via execution of each corresponding query expression of each pair.

[0061] In step 404, each generated feature vector is provided as an input to a machine learning algorithm, which outputs a machine learning model based on the generated feature vector. Figure 2, the machine learning algorithm 206 receives a pair of feature vectors of a seed set 222 marked as having a semantically equivalent relationship as a first input, receives a pair of feature vectors of a seed set 222 marked as having a containment equivalence relationship as a second input, and receives a pair of feature vectors of a seed set 222 marked as not having a relationship as a third input. The machine learning algorithm 206 learns what kind of sub-expression pairs have a containment equivalence relationship, a semantic equivalence relationship, or do not have a relationship based on the first input, the second input, and the third input, and generates a machine learning model 208 (e.g., including multiple weight parameters). The machine learning algorithm 206 can learn different relationships between sub-expression pairs using techniques based on logistic regression or based on semi-supervised techniques. The machine learning model 208 is used to classify new queries received by the database server application 218.

[0062] Figure 5 A block diagram of a system 500 for returning a materialized view according to an example embodiment is depicted. Figure 5 As shown, system 500 includes database server application 518, materialized view engine 530, workload repository 526, and materialized view repository 528. Database server application 518 is an example of database server application 218, as described above with reference to Figure 2 Materialized view engine 530 is an example of materialized view engine 230, as described above with reference to Figure 2 Workload repository 526 is an example of workload repository 226, as described above with reference to Figure 2 The materialized view repository 528 is an example of the materialized view repository 228, as described above with reference to Figure 2 described.

[0063] Still like Figure 2 As shown, materialized view engine 530 includes a characterizer 512, a machine learning model 508, a classification validator 510, and a query rewriter 516. Characterizer 512, machine learning model 508, and classification validator 510 are examples of characterizer 212, machine learning model 208, and classification validator 210, as described above with reference to Figure 2 For brevity, the above reference Figure 2 Other components described in the materialized view engine 230 (e.g., workload analyzer 202, semi-supervised dataset enhancer 204, machine learning algorithm 206, and / or view generator 224) are not described in detail. Figure 5 Shown in.

[0064] The database server application 518 is configured to receive and execute queries, and to store query plans for such queries (and their subqueries) generated in the workload repository 526 (as described above with reference to Figure 2The materialized view engine 230 may periodically analyze query plans associated with queries stored in the workload repository 526. After the machine learning model 508 is generated and deployed, the machine learning model 508 may continue to be updated (i.e., the values ​​of the weight parameters may be updated) to refine the classifications generated thereby using weighted bootstrap-based techniques known to those of ordinary skill in the relevant art(s).

[0065] When the database server application 518 receives a new query 502 (e.g., after the machine learning model 508 is generated and deployed), the database server application 518 can provide the query 502 to the characterizer 512. The characterizer 512 is configured to generate a feature vector (shown as (multiple) feature vectors 522) for each sub-expression included in the query 502 provided thereto. Each feature vector in the feature vectors 522 may include multiple features, including but not limited to table names referenced by the corresponding sub-expression of the query 502, logical operators used by the corresponding sub-expression of the query 502, etc. The (multiple) feature vectors 522 may take any form, such as a numeric, visual and / or textual representation, or may include any other form suitable for representing a sub-expression. The characterizer 512 may operate to characterize or generate feature vectors for a given sub-expression in a variety of ways. For example, but not limited to, the characterizer 512 may characterize a given sub-expression by time series analysis, keyword characterization, semantic-based characterization, digit count characterization, and / or n-gram-TFIDF characterization.

[0066] According to an embodiment, the characterizer 512 uses a one-hot encoding to represent each feature of a feature vector of (multiple) feature vectors 522 for a given sub-expression. Since the number of features (e.g., operators) for a given sub-expression can be different, the feature vector generated for one sub-expression of the query 502 can have a different length than the feature vector generated for another sub-expression of the query 502. In order to prevent feature vectors of different lengths, the characterizer 512 is configured to generate (multiple) feature vectors 522 so that they have the same fixed length. For example, as will be understood by (multiple) persons skilled in the relevant art, the characterizer 512 can achieve this using a tree-based characterization technique, in which tree-based convolution and dynamic pooling operations are performed on the query graph representing the sub-expression to generate (multiple) feature vectors 522 of fixed length. The feature vector 522 is provided to the machine learning model 508.

[0067] The machine learning model 508 is configured to output an indication (e.g., classification 524) as to whether the query 502 (corresponding to the feature vector(s) 522) includes a semantic equivalence relationship with another query sub-expression for which a materialized view has been generated, a containment relationship with another query sub-expression for which a materialized view has been generated, or has no such relationship with other query sub-expressions for which a materialized view has been generated. For example, the machine learning model 508 may compare each feature vector in the feature vector(s) 522 with the feature vectors of the sub-expressions for which a materialized view has been generated to determine whether any such relationship exists. The feature vectors of the sub-expressions for which a materialized view has been generated may be stored by the machine learning model 508 or may be retrieved from a data storage device (e.g., workload repository 526).

[0068] According to an embodiment, the classification 524 output by the machine learning model 508 includes one or more probabilities (e.g., each probability has a value between 0.0 and 1.0) that a given sub-expression of the query has a semantic equivalence relationship with another query sub-expression for which a materialized view has been generated, a containment relationship with another query sub-expression for which a materialized view has been generated, or does not have such a relationship with other query sub-expressions for which a materialized view has been generated. The classification 524 is provided to the classification validator 510.

[0069] The classification validator 510 can compare each probability of the classification 524 to a threshold value. If any probability exceeds the threshold value, the classification validator 510 can verify the classification 524 using a deterministic semantic equivalence determination algorithm and / or a deterministic inclusion determination algorithm, as described above with reference to Figure 2 As described. For example, assume that the threshold is set to 0.90. Further assume that the classification verifier 510 outputs a semantic equivalence probability of 0.95, indicating that the particular sub-expression is very likely to be semantically equivalent to another query sub-expression for which a materialized view has been generated. Because the probability exceeds the threshold, the classification verifier 510 can apply a deterministic semantic equivalence determination algorithm to verify the classification 524. In another example, assume that the classification verifier 510 outputs an inclusion probability of 0.92, indicating that the particular sub-expression is very likely to have an inclusion relationship with another query sub-expression for which a materialized view has been generated. Because the probability exceeds the threshold, the classification verifier 510 can apply a deterministic inclusion determination algorithm to verify the classification 524.

[0070] In the event that the classification determines that the classification 524 is correct, the classification validator 510 provides a notification 530 to the query rewriter 516. The query rewriter 516 reformulates the query expression that generates the classification 524 so that the query expression references the materialized view. For example, assume that the classification 524 indicates that the query sub-expression of code snippet 3 (described above) is determined to have a containment relationship with another query generated for the materialized view. The query rewriter 516 can reformulate the sub-expression in code snippet 5 as follows: where V corresponds to the materialized view generated for another query.

[0071] The reformulated query (shown as reformulated query 532) is provided to the database server application 518. The database server application 518 can retrieve the materialized view referenced by the reformulated query 532 from the view repository 528 and return the materialized view (shown as materialized view 534) to the query 502 as a query result. The foregoing is performed without the database server application 518 having to execute the query 502. For example, the database server application 518 is not required to generate a query plan, optimize the query plan, and execute the optimized query plan). In the scenario where the materialized view 534 is generated for a query that has a containment relationship with the query 502, the portion of the materialized view 534 corresponding to the data requested by the query sub-expression of the query 502 can be returned to the database server application 518. Therefore, the foregoing techniques advantageously save various computing resources (e.g., processing cycles, memory, power, etc.) because the number of queries that need to be executed is reduced.

[0072] In the event that the classification validator 510 determines that the classification 524 is incorrect, the classification validator 510 may provide a notification to the database server application 518 indicating that no materialized view is available for the query to the database server application 518. In this case, the database server application 518 executes the query (e.g., by parsing the query, validating the query, generating a query plan, optimizing the query plan, and executing the optimized query plan).

[0073] Therefore, materialized views can be returned in many ways. For example, Figure 6 600 is a flowchart of a method for returning a materialized view according to an example embodiment. In an embodiment, flowchart 600 may be implemented by system 500, such as Figure 5 Therefore, we will continue to refer to Figure 5 To describe the flowchart 600. Figure 5

[0066] Given the discussion of flowchart 600 and system 500, other structural and operational embodiments will be apparent to persons skilled in the relevant art(s).

[0074] Flowchart 600 begins at step 602. In step 602, a query including a first query expression is received, the query being for a first data set referenced by the first query expression. Figure 5 , the characterizer 512 may receive a query 502 including a query expression from a database server application 518. The query sub-expression of the query 502 may reference (e.g., be configured to retrieve data from) a data set (e.g., (a plurality of) data sets 122, such as Figure 1 shown).

[0075] In step 604, a feature vector is generated based on the first query expression. Figure 5 , the featureizer 512 can generate (multiple) feature vectors 522 based on the query expression included in the query 502.

[0076] In step 606, the feature vector is provided as input to a machine learning model, and the machine learning model outputs a determination that the first query expression has at least one of a semantic equivalence relationship or a containment relationship with respect to the second query expression, and a first materialized view for the second query expression has been generated. Figure 5 , the feature vector(s) 522 are provided as input to a machine learning model 508, which outputs a determination (e.g., a classification 524) that the query expression has at least one of a semantic relationship or a containment relationship with respect to another query expression for which the first materialized view has been generated.

[0077] According to one or more embodiments, when a first query expression and a second query expression both produce the same query result but include different syntax relative to each other, the first query expression has a semantically equivalent relationship with the second query expression. Figure 5 When the query expression of query 502 and another query both produce the same query result but include different syntaxes from each other, they have a semantically equivalent relationship. Examples of query expressions having a semantically equivalent relationship are described above with reference to code snippets 1 and 2.

[0078] According to one or more embodiments, when a first data set is included in a second data set referenced by a second query expression, the first query expression has an inclusion relationship with the second query expression. Figure 5 When the first data set is included in the second data set referenced by the second query expression, the query expression of query 502 has a containment relationship with another query expression for which a materialized view has been generated. Examples of query expressions having a containment relationship are described above with reference to code snippets 3 and 4.

[0079] In step 608, at least a portion of the first materialized view is returned to the query as a query result. Figure 5 , the database server application 518 retrieves at least a portion of the materialized view 534 (generated for other query expressions) from the view repository 528 and returns it to the query 502 as a query result.

[0080] According to one or more embodiments, query 502 is reformulated so that query 502 references materialized view 534. For example, Figure 7 Flowchart 700 of a method for reformulating a query according to an example embodiment is shown. In an embodiment, flowchart 700 may be implemented by system 500, such as Figure 5 Therefore, we will continue to refer to Figure 5 To describe the flowchart 700. Figure 5

[0066] Given the discussion of flowchart 700 and system 500, other structural and operational embodiments will be apparent to persons skilled in the relevant art(s).

[0081] Flowchart 700 begins at step 702. In step 702, a first query expression is reformulated to reference a materialized view. Figure 6 , query rewriter 516 reformulates the query expression of query 502 to reference materialized view 534 .

[0082] In step 704, at least a portion of the materialized view is retrieved via the reformulated first query expression. Figure 5 , database server application 518 retrieves at least a portion of materialized view 534 via reformulated query 532 . III. Example Computer System Implementation

[0083] References Figures 1 to 7 The described systems and methods may be implemented in hardware, or in hardware in combination with one or both of software and / or firmware. For example, system 800 may be used to implement Figure 1 nodes 108A-108N, any of nodes 112A-112N and / or nodes 114A-114N, storage nodes 110A-110N, database server application 118, and materialized view engine 130, Figure 2 database server application 218, materialized view engine 230, workload repository 226, view repository 228, workload analyzer 202, characterizer 212, semi-supervised dataset enhancer 204, machine learning algorithm 206, machine learning model 208, classification validator 210, and view generator 224, Figure 5The database server application 518, data consistency engine 530, workload repository 526, view repository 528, characterizer 512, machine learning model 508, classification validator 510 and query rewriter 516 and / or any components described respectively therein, and flowcharts 300, 400, 600 and / or 700 may each be implemented as computer program code / instructions configured to be executed in one or more processors and stored in a computer-readable storage medium. Alternatively, Figure 1 nodes 108A-108N, any one of nodes 112A-112N and / or nodes 114A-114N, storage nodes 110A-110N, database server application 118, and materialized view engine 130, Figure 2 database server application 218, materialized view engine 230, workload repository 226, view repository 228, workload analyzer 202, characterizer 212, semi-supervised dataset enhancer 204, machine learning algorithm 206, machine learning model 208, classification validator 210, and view generator 224, Figure 5 The database server application 518, data consistency engine 530, workload repository 526, view repository 528, characterizer 512, machine learning model 508, classification validator 510 and query rewriter 516 and / or any components described respectively therein, and flowcharts 300, 400, 600 and / or 700 may be implemented as hardware logic / circuitry. In an embodiment, Figure 1 nodes 108A-108N, any one of nodes 112A-112N and / or nodes 114A-114N, storage nodes 110A-110N, database server application 118, and materialized view engine 130, Figure 2 database server application 218, materialized view engine 230, workload repository 226, view repository 228, workload analyzer 202, characterizer 212, semi-supervised dataset enhancer 204, machine learning algorithm 206, machine learning model 208, classification validator 210, and view generator 224, Figure 5The database server application 518, data consistency engine 530, workload repository 526, view repository 528, characterizer 512, machine learning model 508, classification validator 510 and query rewriter 516 and / or any components described respectively therein, and flowcharts 300, 400, 600 and / or 700 may be implemented in one or more SoCs (systems on chips). SoCs may include integrated circuit chips that include one or more processors (e.g., central processing units (CPUs), microcontrollers, microprocessors, digital signal processors (DSPs), etc.), memory, one or more communication interfaces and / or other circuit systems, and may optionally execute received program codes and / or include embedded firmware to perform functions.

[0084] Figure 8 An example implementation of a computing device 800 is depicted in which embodiments may be implemented, including Figure 1 any one of the nodes 108A-108N, the nodes 112A-112N and / or the nodes 114A-114N, the storage nodes 110A-110N, the database server application 118 and the materialized view engine 130, Figure 2 database server application 218, materialized view engine 230, workload repository 226, view repository 228, workload analyzer 202, characterizer 212, semi-supervised dataset expander 204, machine learning algorithm 206, machine learning model 208, classification validator 210 and view generator 224, Figure 5 The database server application 518, data consistency engine 530, workload repository 526, view repository 528, characterizer 512, machine learning model 508, classification validator 510 and query rewriter 516, and / or any components described therein, and flowcharts 300, 400, 600 and / or 700. The description of computing device 800 provided herein is provided for illustrative purposes and is not intended to be limiting. As known to those skilled in the relevant art(s), embodiments may be implemented in other types of computer systems.

[0085] like Figure 8As shown, computing device 800 includes one or more processors referred to as processor circuit 802, system memory 804, and bus 806 that couples various system components including system memory 804 to processor circuit 802. Processor circuit 802 is an electrical and / or optical circuit implemented as a central processing unit (CPU), microcontroller, microprocessor, and / or other physical hardware processor circuit in one or more physical hardware circuit device elements and / or integrated circuit devices (semiconductor material chips or dies). Processor circuit 802 can execute program codes stored in computer-readable media, such as program codes of operating system 830, application program 832, other programs 834, etc. Bus 806 represents any one or more of several types of bus structures, including memory bus or memory controller, peripheral bus, accelerated graphics port, and processor or local bus using any of various bus architectures. System memory 804 includes read-only memory (ROM) 808 and random access memory (RAM) 810. Basic input / output system 812 (BIOS) is stored in ROM 808.

[0086] The computing device 800 also has one or more of the following drives: a hard disk drive 814 for reading and writing a hard disk, a disk drive 816 for reading and writing a removable disk 818, and an optical drive 820 for reading and writing a removable optical disk 822 such as a CD ROM, DVD ROM or other optical media. The hard disk drive 814, the disk drive 816, and the optical drive 820 are connected to the bus 806 via a hard disk drive interface 824, a disk drive interface 826, and an optical drive interface 828, respectively. The drive and its associated computer-readable media provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer. Although a hard disk, a removable disk, and a removable optical disk are described, other types of hardware-based computer-readable storage media may be used to store data, such as flash memory cards, digital video disks, RAM, ROM, and other hardware storage media.

[0087] A plurality of program modules may be stored in a hard disk, a magnetic disk, an optical disk, a ROM, or a RAM. These programs include an operating system 830, one or more application programs 832, other programs 834, and program data 836. The application program 832 or other program 834 may include, for example, computer program logic (e.g., computer program code or instructions) for implementing the above-mentioned system, including the above-referenced Figures 1 to 7 Described embodiments.

[0088] A user may enter commands and information into the computing device 800 through input devices such as a keyboard 838 and a pointing device 840. Other input devices (not shown) may include a microphone, a joystick, a game pad, a satellite dish, a scanner, a touch screen and / or touchpad, a voice recognition system for receiving voice input, a gesture recognition system for receiving gesture input, etc. These and other input devices are typically connected to the processor circuit 802 through a serial port interface 842 coupled to the bus 806, but may be connected by other interfaces, such as a parallel port, a game port, or a universal serial bus (USB).

[0089] The display screen 844 is also connected to the bus 806 via an interface such as a video adapter 846. The display screen 844 may be external to the computing device 800 or incorporated into the computing device 800. The display screen 844 may display information, as well as serve as a user interface for receiving user commands and / or other information (e.g., by touch, finger gestures, a virtual keyboard, by providing a tap input (a user lightly presses and quickly releases the display screen 844), by providing a “touch and hold” input (a user touches and holds his finger (or touch tool) on the display screen 844 for a predetermined period of time), by providing a touch input exceeding a predetermined pressure threshold, etc.). In addition to the display screen 844, the computing device 800 may include other peripheral output devices (not shown), such as a speaker and a printer.

[0090] The computing device 800 is connected to a network 848 (e.g., the Internet) through an adapter or network interface 850, a modem 852, or other means for establishing communications over the network. The modem 852 (which may be internal or external) may be connected to the bus 806 via the serial port interface 842, such as a Figure 8 As shown, or may be connected to bus 806 using another interface type, including a parallel interface.

[0091] As used herein, the terms "computer program medium", "computer readable medium" and "computer readable storage medium" are used to broadly refer to physical hardware media, such as a hard disk associated with hard disk drive 814, removable magnetic disk 818, removable optical disk 822, other physical hardware media, such as RAM, ROM, flash memory cards, digital video disks, compact disks, MEMs, nanotechnology-based storage devices, and other types of physical / tangible hardware storage media (including Figure 8System memory 804). Such computer readable storage media are distinguished from and do not overlap with (do not include) communication media and propagated signals. Communication media typically contain computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave. The term "modulated data signal" refers to a signal that sets or changes one or more characteristics in a manner that encodes information in the signal. By way of example and not limitation, communication media include wireless media such as acoustic, RF, infrared and other wireless media and wired media. Embodiments also relate to such communication media.

[0092] As described above, computer programs and modules (including application programs 832 and other programs 834) can be stored on a hard disk, disk, optical disk, ROM, RAM or other hardware storage medium. Such computer programs can also be received via a network interface 850, a serial port interface 852 or any other interface type. Such computer programs enable the computing device 800 to implement the features of the embodiments discussed herein when executed or loaded by an application. Therefore, such computer programs represent the controller of the computing device 800.

[0093] Embodiments also relate to computer program products including computer codes or instructions stored on any computer readable medium. Such computer program products include hard drives, optical drives, memory device packages, portable memory sticks, memory cards, and other types of physical storage hardware. IV. Other Example Embodiments

[0094] A system is described herein. The system includes: at least one processor circuit; and at least one memory storing program code, the program code being configured to be executed by the at least one processor circuit, the program code including: a materialized view engine configured to: receive a query including a first query expression, the query being for a first data set referenced by the first query expression; generate a feature vector based on the first query expression; provide the feature vector as input to a machine learning model, the machine learning model outputting a determination that the first query expression has at least one of a semantic equivalence relationship or a containment relationship with respect to a second query expression, and a first materialized view for the second query expression has been generated; and in response to determining that the first query expression has at least one of a semantic equivalence relationship or a containment relationship with respect to the second query expression, return at least a portion of the first materialized view to the query as a query result.

[0095] In one embodiment of the aforementioned system, the materialized view engine is configured to return at least a portion of the first materialized view to the query as a query result by: reformulating the first query expression to reference the materialized view; and retrieving at least a portion of the materialized view via the reformulated first query expression.

[0096] In one embodiment of the aforementioned system, the materialized view engine is also configured to: extract multiple query expressions from multiple previously executed queries; determine multiple pairs of query expressions from a subset of the multiple query expressions, each pair of query expressions in the multiple pairs of query expressions having at least one of a semantic equivalence relationship or an inclusion relationship with respect to each other; for each pair of query expressions in the determined multiple pairs of query expressions, generate a second materialized view of the results generated based on the execution of at least one query expression in the determined query expression pair; and store each second materialized view in the second materialized view in a storage device, the first materialized view being a second materialized view in the second materialized view.

[0097] In one embodiment of the aforementioned system, the materialized view engine is further configured to: for each pair of query expressions in the determined multiple pairs of query expressions: generate a second feature vector based on each query expression in the query expression pair; and provide each generated second feature vector as input to a machine learning algorithm, and the machine learning algorithm outputs a machine learning model based on the generated second feature vector.

[0098] In one embodiment of the aforementioned system, each second feature vector includes at least one of the following: a table name referenced by each corresponding query expression of each pair of query expressions, one or more logical operators specified by each corresponding query expression of each pair of query expressions, or the number of rows retrieved via the execution of each corresponding query expression of each pair of query expressions.

[0099] In one embodiment of the aforementioned system, when the first data set is included in the second data set referenced by the second query expression, the first query expression has a containment relationship with the second query expression.

[0100] In one embodiment of the aforementioned system, when the first query expression and the second query expression both generate the same query result but include different syntax relative to each other, the first query expression has a semantically equivalent relationship with the second query expression.

[0101] The present invention also describes a method. The method includes: receiving a query including a first query expression, the query being for a first data set referenced by the first query expression; generating a feature vector based on the first query expression; providing the feature vector as input to a machine learning model, the machine learning model outputting a determination that the first query expression has at least one of a semantic equivalence relationship or a containment relationship with respect to a second query expression, and a first materialized view for the second query expression has been generated; in response to determining that the first query expression has at least one of a semantic equivalence relationship or a containment relationship with respect to the second query expression, returning at least a portion of the first materialized view to the query as a query result.

[0102] In one embodiment of the aforementioned method, returning includes: reformulating the first query expression to reference the materialized view; and retrieving at least a portion of the materialized view via the reformulated first query expression.

[0103] In one embodiment of the aforementioned method, the method also includes: extracting multiple query expressions from multiple previously executed queries; determining multiple pairs of query expressions from a subset of the multiple query expressions, each pair of query expressions in the multiple pairs of query expressions having at least one of a semantic equivalence relationship or an inclusion relationship with respect to each other; for each pair of query expressions in the determined multiple pairs of query expressions, generating a second materialized view of the results generated based on the execution of at least one query expression in the determined query expression pair; and storing each second materialized view in the second materialized view in a storage device, the first materialized view being a second materialized view in the second materialized view.

[0104] In one embodiment of the aforementioned method, the method also includes: for each pair of query expressions in the determined multiple pairs of query expressions: generating a second feature vector based on each query expression in the query expression pair; and providing each generated second feature vector as input to a machine learning algorithm, and the machine learning algorithm outputs a machine learning model based on the generated second feature vector.

[0105] In one embodiment of the aforementioned method, each second feature vector includes at least one of the following: a table name referenced by each corresponding query expression of each pair of query expressions, one or more logical operators specified by each corresponding query expression of each pair of query expressions, or the number of rows retrieved via the execution of each corresponding query expression of each pair of query expressions.

[0106] In one embodiment of the aforementioned method, when the first data set is included in the second data set referenced by the second query expression, the first query expression has an inclusion relationship with the second query expression.

[0107] In one embodiment of the aforementioned method, when the first query expression and the second query expression both generate the same query result but include different syntax relative to each other, the first query expression has a semantically equivalent relationship with the second query expression.

[0108] A computer-readable storage medium having program instructions recorded thereon, the program instructions performing a method when executed by at least one processor. The method comprises: receiving a query including a first query expression, the query being for a first data set referenced by the first query expression; generating a feature vector based on the first query expression; providing the feature vector as input to a machine learning model, the machine learning model outputting a determination that the first query expression has at least one of a semantic equivalence relationship or a containment relationship with respect to a second query expression, and a first materialized view for the second query expression has been generated; and in response to determining that the first query expression has at least one of a semantic equivalence relationship or a containment relationship with respect to the second query expression, returning at least a portion of the first materialized view to the query as a query result.

[0109] In one embodiment of the aforementioned computer-readable storage medium, returning includes: reformulating the first query expression to reference the materialized view; and retrieving at least a portion of the materialized view via the reformulated first query expression.

[0110] In one embodiment of the aforementioned computer-readable storage medium, the method also includes: extracting multiple query expressions from multiple previously executed queries; determining multiple pairs of query expressions from a subset of the multiple query expressions, each pair of query expressions in the multiple pairs of query expressions having at least one of a semantic equivalence relationship or an inclusion relationship relative to each other; for each pair of query expressions in the determined multiple pairs of query expressions, generating a second materialized view of the results generated based on the execution of at least one query expression in the determined query expression pair; storing each second materialized view in the second materialized view in a storage device, the first materialized view being a second materialized view in the second materialized view.

[0111] In one embodiment of the aforementioned computer-readable storage medium, the method also includes: for each pair of query expressions in the determined multiple pairs of query expressions: generating a second feature vector based on each query expression in the query expression pair; and providing each generated second feature vector as input to a machine learning algorithm, and the machine learning algorithm outputs a machine learning model based on the generated second feature vector.

[0112] In one embodiment of the aforementioned computer-readable storage medium, each second feature vector includes at least one of the following: a table name referenced by each corresponding query expression of each pair of query expressions, one or more logical operators specified by each corresponding query expression of each pair of query expressions, or the number of rows retrieved via the execution of each corresponding query expression of each pair of query expressions.

[0113] In one embodiment of the aforementioned computer-readable storage medium, when the first data set is included in the second data set referenced by the second query expression, the first query expression has an inclusion relationship with the second query expression. V. Conclusion

[0114] Although various exemplary embodiments have been described above, it should be understood that they are presented by way of example only and not limitation. (Multiple) persons skilled in the relevant art will understand that various changes in form and details may be made therein without departing from the spirit and scope of the embodiments as defined in the appended claims. Therefore, the breadth and scope of the present disclosure should not be limited by any of the above exemplary embodiments, but should be limited only in accordance with the appended claims and their equivalents.

Claims

1. A system comprising: at least one processor circuit; as well as At least one memory storing program codes, wherein the program codes are configured to be executed by the at least one processor circuit, the program codes comprising: The materialized view engine is configured to: Receiving a query including a first query expression, the query being for a first data set referenced by the first query expression; generating a feature vector based on the first query expression; providing the feature vector as input to a machine learning model, the machine learning model outputting a determination that the first query expression has at least one of a semantic equivalence relationship or a containment relationship with respect to a second query expression for which a first materialized view has been generated; and In response to determining that the first query expression has at least one of the semantic equivalence relationship or the inclusion relationship with respect to the second query expression, at least a portion of the first materialized view is returned to the query as a query result.

2. The system of claim 1 , wherein the materialized view engine is configured to return the at least a portion of the first materialized view as the query result to the query by: reformulating the first query expression to reference the materialized view; and The at least a portion of the materialized view is retrieved via the reformulated first query expression.

3. The system according to claim 1, wherein the materialized view engine is further configured to: Extract multiple query expressions from multiple previously executed queries; Determine a plurality of pairs of query expressions from a subset of the plurality of query expressions, each pair of query expressions in the plurality of pairs of query expressions having at least one of the semantic equivalence relationship or the inclusion relationship with respect to each other; For each pair of query expressions in the determined plurality of pairs of query expressions, generating a second materialized view of results generated based on execution of at least one query expression in the determined pair of query expressions; as well as Each of the second materialized views is stored in a storage device, the first materialized view being a second materialized view of the second materialized views.

4. The system according to claim 3, wherein the materialized view engine is further configured to: For each pair of query expressions in the determined plurality of pairs of query expressions: generating a second feature vector based on each query expression in the query expression pair; and Each generated second feature vector is provided as input to a machine learning algorithm, which outputs the machine learning model based on the generated second feature vector.

5. The system of claim 4, wherein each second feature vector comprises at least one of the following: the name of the table referenced by each corresponding query expression of each pair of query expressions, One or more logical operators specified by each corresponding query expression of each pair of query expressions, or The number of rows retrieved via execution of each corresponding query expression of each pair of query expressions. 6 . The system according to claim 1 , wherein the first query expression has the containment relationship with the second query expression when the first data set is included in a second data set referenced by the second query expression.

7. The system of claim 1, wherein the first query expression has the semantic equivalence relationship with the second query expression when the first query expression and the second query expression both produce the same query result but include different syntax relative to each other.

8. A method comprising: Receiving a query including a first query expression, the query being for a first data set referenced by the first query expression; generating a feature vector based on the first query expression; providing the feature vector as input to a machine learning model, the machine learning model outputting a determination that the first query expression has at least one of a semantic equivalence relationship or a containment relationship with respect to a second query expression, for which a first materialized view has been generated; as well as In response to determining that the first query expression has at least one of the semantic equivalence relationship or the inclusion relationship with respect to the second query expression, at least a portion of the first materialized view is returned to the query as a query result.

9. The method of claim 8, wherein the returning comprises: reformulating the first query expression to reference the materialized view; as well as The at least a portion of the materialized view is retrieved via the reformulated first query expression.

10. The method according to claim 8, further comprising: Extract multiple query expressions from multiple previously executed queries; Determine a plurality of pairs of query expressions from a subset of the plurality of query expressions, each pair of query expressions in the plurality of pairs of query expressions having at least one of the semantic equivalence relationship or the inclusion relationship with respect to each other; For each pair of query expressions in the determined plurality of pairs of query expressions, generating a second materialized view of results generated based on execution of at least one query expression in the determined pair of query expressions; as well as Each of the second materialized views is stored in a storage device, the first materialized view being a second materialized view of the second materialized views.

11. The method according to claim 10, further comprising: For each pair of query expressions in the determined plurality of pairs of query expressions: generating a second feature vector based on each query expression in the query expression pair; as well as Each generated second feature vector is provided as input to a machine learning algorithm, which outputs the machine learning model based on the generated second feature vector.

12. The method according to claim 11, wherein each second feature vector comprises at least one of the following: the name of the table referenced by each corresponding query expression of each pair of query expressions, One or more logical operators specified by each corresponding query expression of each pair of query expressions, or The number of rows retrieved via execution of each corresponding query expression of each pair of query expressions.

13. The method according to claim 8, wherein when the first data set is included in a second data set referenced by the second query expression, the first query expression has the containment relationship with the second query expression.

14. The method of claim 8, wherein the first query expression has the semantic equivalence relationship with the second query expression when the first query expression and the second query expression both produce the same query result but include different syntax relative to each other.

15. A computer-readable storage medium having program instructions recorded thereon, wherein the program instructions, when executed by at least one processor, perform any one of the methods according to claims 8 to 14.

Images