Dynamic scalable queries in federated graph databases

Abstract

A graph query scaling process includes receiving a graph query requesting data from a graph database. An execution plan is generated for the graph query that includes a first query to be performed. The first query is analyzed to determine a first differential insight for the first query. The differential insight is compared to a differential insight threshold to determine if the first query is scalable. If the first query is scalable, the first query is rewritten to scale an amount of database reads required to execute the first query. The actual query latency from executing the first query is measured and a scaling factor is generated which is fed back to the execution planner to use in scaling later queries.

Description

DYNAMIC SCALABLE QUERIES IN FEDERATED GRAPH DATABASESBACKGROUND

[0001] Graph data storage systems are designed to maintain a target Quali ty of Service (QoS) while processing requests (or queries). However, the system may have spikes in usage which can cause the system to have failure issues due to increasing request queues, retry logic and missing fallback mechanisms.

[0002] Hence, what is needed is a system and method of adapting QoS for structured graph data storage systems that enables the QoS to be scaled to compensate for increased loads on the system while still complying with all applicable service level agreements (SLAs).SUMMARY

[0003] In one general aspect, the instant disclosure presents a data processing system having a processor and a memory in communication with the processor wherein the memory stores executable instructions that, when executed by the processor, cause the data processing system to perform multiple functions. The functions include receiving, at an execution planning component of a graph query execution planner, a graph query' for requesting data from a graph data structure which abstracts data from a graph data storage system having a plurality of different data stores; generating an execution plan for executing the graph query across the different data stores of the graph data storage system, the execution plan including a first query to be performed on a first data store of the plurality of data stores; determining a first differential insight for the first query at the graph query execution planner; determining at the graph query' execution planner that the first query is scalable by comparing the first differential insight to a differential insight threshold; rewriting the first query at the graph query execution planner according to at least one query scaling technique to adjust an amount of database reads required to execute the first query' based at least in part on the comparison between the first differential insight and the differential insight threshold; and delivering the rewritten first query to a graph query execution engine for execution on the first data store.

[0004] In yet another general aspect, the instant disclosure presents a method for dy namic scaling of graph queries for a graph data storage system. The method includes receiving, at an execution planning component of a graph query' execution planner, a graph query for requesting data from a graph data structure which abstracts data from a graph data storage system having a plurality of different data stores; generating an execution plan for executing the graph query across the different data stores of the graph data storage system, the execution plan including a first query to be performed on a first data store of the plurality of data stores; determining a first differential insight for the first query at the graph query execution planner, the first differential insightcorresponding to a difference in query output between an output of the first query when all relevant data records are considered and an output of the first query when a single one of the relevant data records is altered; determining at the graph uery execution planner that the first query7is scalable by comparing the first differential insight to a differential insight threshold; rewriting the first query at the graph query execution planner according to at least one query scaling technique to adjust an amount of database reads required to execute the first query based at least in part on the comparison between the first differential insight and the differential insight threshold; and delivering the rewritten first query7to a graph query7execution engine for execution on the first data store.

[0005] In a further general aspect, the instant application describes a non-transilory computer readable medium on which are stored instructions that when executed cause a programmable device to perform functions of receiving, at an execution planning component of a graph query7execution planner, a graph query7for requesting data from a graph data structure which abstracts data from a graph data storage system having a plurality of different data stores; generating an execution plan for executing the graph query7across the different data stores of the graph data storage system, the execution plan including a first query7to be performed on a first data store of the plurality of data stores; determining a first differential insight for the first query at the graph query execution planner; determining at the graph query execution planner that the first query is scalable by comparing the first differential insight to a differential insight threshold; rewriting the first query at the graph query7execution planner according to at least one query7scaling technique to adjust an amount of database reads required to execute the first query based at least in part on the comparison between the first differential insight and the differential insight threshold; and delivering the rewritten first query to a graph query execution engine for execution on the first data store.

[0006] This Summary7is 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. Furthermore, the claimed subject of this disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The drawing figures depict one or more implementations in accord with the present teachings, by way of example only, not by way of limitation. In the figures, like reference numerals refer to the same or similar elements. Furthermore, it should be understood that the drawings are not necessarily to scale.

[0008] FIG. 1 is a diagram showing an example computing environment in which the techniques disclosed herein may be implemented.

[0009] FIG. 2 depicts an example implementation of a graph query processing engine which may be implemented for the graph data storage service of the computing environment of FIG. 1.

[0010] FIG. 3 is an example diagram showing the feedback loop for calculating and returning a scaling factor to a graph query execution planner of the graph query processing engine of FIG.2.

[0011] FIG. 4 is a flow diagram depicting an example method for dynamic scaling of graph queries for the graph query storage system of FIG. 2.

[0012] FIG. 5 is a block diagram illustrating an example software architecture, various portions of which may be used in conjunction with various hardware architectures herein described.

[0013] FIG. 6 is a block diagram illustrating components of an example machine configured to read instructions from a machine-readable medium and perform any of the features described herein.DETAILED DESCRIPTION

[0014] Enterprise systems often provide a cloud-based software-as-a-service (SaaS) system that provides a plurality of web-based services and applications to the enterprise that allow the enterprise to integrate business processes and share information across business functions and employee hierarchies. Data related to these services, applications, protocols, and functionalities is typically stored in different workload specific data stores which are designed to service a specific category of request traffic. These data stores may have different partition and index configurations and different search capabilities, and may be distributed across multiple servers and in different regions. A graph abstraction, or graph schema, may be used to reason over the enterprise data. The graph data structure comprises nodes that represent various types of data objects (e.g., user, application, file, etc.) and edges between the nodes that represent relationships between these data objects. The graph schema enables a single query execution engine to treat the disparate graph data stores as a single graph.

[0015] Graph data storage systems are designed to maintain a target Quali ty of Service (QoS) while processing requests (or queries). The target QoS can be based on service level agreements (SLAs) with customers and / or service level objectives (SLOs) which must be achieved to meet the terms of SLAs. However, the system may have spikes in usage for various reasons which can result in higher than expected load, such as higher numbers of concurrent users and / or requests received, on the system. In these situations, the system can exhibit interdependent failure patterns and cascading failure issues due to increasing request queues, retry logic and missing fallback mechanisms.

[0016] Some service types can adapt to higher than expected loads using graceful degradation techniques that involve scaling the QoS provided to users inversely with respect to the load on thesystem. For example, a video streaming service can reduce the resolution of streamed content to maintain service to end users while the service is under high load. However, reducing QoS is ty pically not an option for structured data storage platforms (such as the graph storage systems described herein) which are often required to a maintain target QoS and accuracy according to SLAs. As a result, little effort has been applied to finding ways to adapt QoS in structured data storage platforms to compensate for loads that would otherwise cause the system to fail to comply with an SLA.

[0017] To address the technical problems associated with maintaining a target QoS in structured graph data storage systems while under increased loads, this description provides technical solutions in the form of a dynamic resolution scaling process that enables queries to be rewritten to reduce the amount of database reads required to execute the query in order to reduce the latency of query execution while the system is under heavy loads. The process involves identifying query’ patterns where dynamic resolution scaling can be applied and rewriting those queries so that the number of database reads required to execute the query' is reduced. A feedback loop is used to measure system load so that dynamic scaling can be applied as needed and scaled based on the load.

[0018] Scalable queries are detected based on the concept of differential insight. As used herein, the term "differential insight’7refers to the degree to which a result A of a query performed using a reduced number of database reads is distinguishable from a result B of the query performed using all required database reads. A query performed with a reduced number of database reads incurs differential insight if result A is distinguishable from result B. Conversely, a query' performed with a reduced number of database reads does not incur differential insight if result A is not distinguishable from result B. A scalable query for the purposes of this disclosure is a query for which a reduction in database reads does not incur differential insight.

[0019] For each query7, the maximum differential insight Smax(f) for the query is determined and compared to a predefined differential insight threshold value Sthreshoia. If the maximum differential insight Smax(f) is less than the threshold, the query7is considered scalable. Scalable queries can be rewritten according to a query7scaling technique which adjust the number of database reads required to perform the query7. In various implementations, this disclosure provides three query7scaling techniques for rewriting queries to adjust the number of database reads required for the query7: predicate restriction, sorted index retrieval, and Montecarlo selection (described in more detail below). Scalable queries can be rewritten such that the reduction in database reads required by the query7is scaled based on the system load (e.g., latency) associated with executing the query7. To this end, query latency is measured at execution time and used in conjunction with the expected latency and differential insight of the query to determine a scalingfactor. The scaling factor is fed back to the execution planning engine where it can be used as a factor in rewriting scalable queries.

[0020] FIG. 1 is a diagram of an example computing environment 100 in which the dynamic scalable graph queries described herein are implemented. The example computing environment 100 includes an application services platform 102, a graph storage service 104. and client devices 106 which communicate via a network 108. The network 108 includes one or more wired, wireless, and / or a combination of wired and w ireless netw orks. The netw ork 108 may include one or more local area networks (LAN), wide area networks (WAN) (e.g., the Internet), public networks, private networks, virtual networks, mesh networks, peer-to-peer networks, and / or other interconnected data paths across which multiple devices may communicate.

[0021] The application services platform 102 provides one or more services 110 and / or web applications 112 which may be accessed and utilized by users via client devices 106. For example, in various implementations, the services 110 provided by application services platform 102 may include web hosting, conferencing, messaging, Software as a Service (SaaS), e-commerce, social media, online payment, email, and the like. Web applications 112 can include cloud storage, document creating and editing applications, database applications, email applications, productivity applications, collaboration applications, and the like. The application services platform 102 includes at least one server (not shown) which is configured to provide computational and / or storage resources for implementing services 110 and web applications 112. Servers host data and / or content in connection with the sendees 110 and applications 112 and makes this data and / or content available to the users of client devices 106 via the network 108. Program code, instructions, user data and / or content for the services 110 are stored in one or more data stores (not shown).

[0022] Graph data storage service 104 includes a graph API 114, a graph data collection system 116, graph data stores 118, and a graph query processing engine 120. The graph API 114 defines the protocols, functions, parameters, procedures, and the like for communicating with and accessing the functionality provided by the graph data storage service 104. The graph data collection system 116 collects graph data representative of user interactions with applications, files, data, other users, and the like. In various implementations, the graph data storage service 104 is provided by the application services platform 102 and is used to collect data pertaining to users, applications, files, documents, etc. in connection with the application services platform 102. Graph data may be collected from web applications and client applications in any suitable manner. The collected graph data is stored in the graph data stores 118.

[0023] The graph data stores 118 can store various types of data that may be generated by and / or collected from client applications and web applications, such as user information, files,documents, metadata, media content, and other information. Data stores 118 can include databases, key-value stores, APIs that pull data from other sources, and other data sources that are collectively referred to herein as data stores. Data stores 118 can be distributed across multiple servers and in different locations. The graph data storage service includes a graph schema 122 which maps graph data in the data stores 118 to a graph data structure. The graph schema is capable of handling typed entities, both scalar and temporal. The schema also enables annotation of the connections between typed entities, such as relationships in a graph or foreign keys in a relational database, as well as annotation of index keys and sortable columns to relevant types in the schema. The schema represents the composite knowledge across graph data stores and enables a single query execution engine to treat the disparate graph data stores as a single graph.

[0024] The graph data structure comprises nodes that represent various types of data objects, such as users, applications, fdes, etc., and edges between the nodes that represent relationships between these data objects. For example, if a node represents a user, the node can contain user information, such as name, emails address, phone number, address, etc. If anode represents a file, the node can contain file information, such as file name, file creation date, last modified date, etc. Each edge connects two nodes and represents a relationship between the two nodes. For example, an edge between two user nodes can indicate a relationship between the two users and specify the type of relationship (e.g., contact, friend, co-worker, relative, etc.). An edge between two file nodes can indicate that the files are related and specify how they are related (e g., two version of the same file, pertain to the same project, etc.). An edge between a user node and a file node can indicate that the user has interacted with the file and can specify the ty pe of interaction (e.g., accessed, viewed, edited, shared, collaborated on, etc.).

[0025] Requests for data from the graph data storage service 104 comprise graph queries which are submitted to the graph data storage service 104 via the graph API 114. Graph queries can be written in a structured query language, such as Cypher Graph query7language, Structured Query7Language (SQL), or any query language capable of handling dynamically scalable elements (explained in more detail below). The graph query processing engine 120 processes each graph query7with reference to the graph schema 122 to determine which data stores need to be accessed for the query7and the which operations (e.g., joins, filtering, aggregation) should be performed across the different data stores 118 to achieve efficient results. The graph query processing engine coordinates the data retrieval and processing, potentially pushing down operations to the source systems where possible. Finally, the graph query processing engine 120 combines the results received from the different data stores into a single coherent result which is returned to the user, application, or service which submitted the query. The graph query7processing engine acts as an abstraction layer which allows users to treat the disparate data stores 118 as a single, virtualdatabase which in turn allows users to write queries that span multiple data stores without needing to manage data integration manually.

[0026] Client devices 106 enable users to communicate with and submit graph queries to the graph data storage service 104. Client devices 106 can be implemented using any suitable type of computing device, such as personal computers, desktop computers, laptop computers, mobile telephones, smart phones, tablets, and the like. Each client device 106 includes at least one client application 124 for interacting with the graph data storage service 104. In some implementations, the client application 124 is a local application that is capable of accessing the functionality of the graph data storage service 104. In other implementations, the client application 124 is a web browser that enables access to web-based application(s) implemented by the graph data storage service 104.

[0027] An example implementation of a graph query processing engine 120 is show n in greater detail in FIG. 2. The graph query processing engine 120 includes graph data stores 118. a graph query API 204, a graph query execution planner 206, and a graph query execution engine 208. Graph queries are submitted to the graph query execution planner 206 via the graph query API 204. The graph query7processing engine 208 includes an execution planning component 210 and a result consolidating component 212. The execution planning component 210 processes each query to identify the graph data stores which are relevant to the query and the characteristics of the relevant data stores (e g., search capabilities, index configurations, partition configurations, etc.) with reference to a graph schema 214. The execution planning component 210 then generates multiple possible execution plans for executing the query over the relevant graph data stores. The plans can be generated by varying traversal paths, indexing methods, join strategies, and the like that will be used to execute the query. In various implementations, the execution planning component generates execution plans that include a series of sub-queries pertaining to each relevant data store. Once the multiple plans have been generated, the execution planner estimates a cost associated with each plan according to one or more predefined cost functions. Any suitable cost function may be utilized to estimate the cost associated with each execution plan. Once a cost has been estimated for each plan, the execution planner selects the plan having the lowest cost to use for executing the query.

[0028] The selected execution plan is then provided to the graph query execution engine 208. In some implementations, the execution planning component 210 provides the execution plan to the execution engine. In some implementations, the execution planning component 210 provides the execution plan to execution engine 208 one step, or sub-query, at a time. In other implementations, the execution planning component 210 provides the entire plan to the graph query execution engine 208. In any event, the graph query execution engine 208 coordinates theexecution of the sub-queries of the plan across the relevant data stores 118 in accordance with an order and a timing specified by the plan.

[0029] The graph query7execution engine 208 includes a query execution component 216 which receives the execution plan, including each sub-query, from the execution planning component 210 and provides each sub-query to the data store 118 for which it is intended. In the implementation of FIG. 2, the graph query execution engine 208 includes data store adapter 218 which provide interfaces to the data stores 202 via which queries can be communicated to the data stores and query results returned. Each data store 118 includes a data management system (not shown) that is capable of processing queries and returning results from the corresponding data store 118. Results retrieved by the data management systems for each sub-quety are returned to the query7execution component 216 via the data store adapters 218. The results are provided to the result consolidating component 212 which consolidates the results into a single coherent result which is returned to the device or application from which the query was received.

[0030] The graph data storage system 118 is designed to maintain a target Quality of Service (QoS) while processing requests (or queries). In various implementations, the QoS is based on request latency which is the amount of time required to process a query and return a result. The target QoS is a predefined latency or latency range for processing queries that the system is designed to maintain under normal or expected loads). The target QoS can be based on service level agreements (SLAs) with customers and / or service level objectives (SLOs) which must be achieved to meet the terms of SLAs. However, the system can have spikes in usage for various reasons which can result in high loads on the system which increase the latency of processing queries to the point that the system does not meet the target QoS.

[0031] To enable the graph data storage system to maintain a target QoS when the system is faced with high loads that would otherwise adversely impact QoS, the graph data storage system is configured to implement a dynamic resolution scaling process that involves detecting scalable graph queries where the number of database reads required to perform the query can be scaled without noticeably impacting the accuracy of the result of the query. Scalable graph queries can then be rewritten so that the reduction in database reads required for the query is scaled based on result feedback which is indicative of the load and / or the latency on the system. To this end, the graph query execution planner 206 includes a scalable query detecting component 220 for detecting scalable graph queries and a query rewriting component 222 for rewriting the component scalable queries in a manner that reduces the number of database reads required for the query depending on the current load (e.g., latency) on the system. In various implementations, the execution planning component 210 provides the queries, or sub-queries, from the execution plan to the scalable query detecting component 220 to determine if the query can be scaled. If the querycan be scaled, the scalable query is provided to the query rewriting component 222 which rewrites the query according to at least one query scaling technique.

[0032] As discussed below, as each query' is performed at a data store, a determination is made as to whether the latency of the query complies with the target QoS of the system. If the latency of the query does not comply with the target QoS, a scaling factor for the data store is calculated based on a measured latency, an expected latency, and other factors (described in more detail below) which is returned to the execution planning component 21. The query' rewriting component then rewrites queries for the data store with reference to the scaling factors so that the rewritten query scales database reads commensurate with the load on the data store so the target QoS can be maintained.

[0033] Scalable queries are detected based on the concept of differential insight. As used herein, the term “differential insight'’ refers to the degree to which a result A of a query7performed using a reduced number of database reads is distinguishable from a result B of the query performed using all required database reads. A query performed with a reduced number of database reads incurs differential insight if result A is distinguishable from result B. Conversely, a query performed with a reduced number of database reads does not incur differential insight if result A is not distinguishable from result B. A scalable query for the purposes of this disclosure is a query7for which a reduction in database reads does not incur differential insight.

[0034] The following query (written in Cypher) is an example of a query which does incur differential insight and therefore is not scaleable:MATCH (a: Me)-[r: ModifiedBy ] ->(b Tile)RETURN b.fileName ORDER BY r.When .The query attempts to return the files modified by Me sorted by recency. In this case, alterations to the quantity of database reads used to retrieve the files can result in missed files which will reflect on the correctness of the query, therefore incurring differential insight.

[0035] A query which performs an aggregate operation that does not reveal omissions of the original content can be scaled without incurring differential insight. One example of this is the following query:MATCH (a:Me)-[rl :ModifiedBy]->(b:File)RETURN avg(count(b. Authors))This query produces the average number of authors of files that a person (Me) has modified. In this example, it is possible that the average value that is returned for the query when performed wi th a reduced number of database reads relative to the average value returned when all required database reads are performed. Because the result obtained with a reduced number of database reads is not distinguishable from the result obtained using all required database reads, the query7does not incur differential insight.

[0036] The mathematical definition of differential insight is similar to the concept of differential privacy, with similar goals. An algorithm is considered differentially private if an observer seeing its output cannot tell whether a particular individual's information was used in the computation. In other words, the guarantee of a differentially private algorithm is that its behavior hardly changes when a single individual joins or leaves the dataset — anything the algorithm might output on a database containing some individual's information is almost as likely to have come from a database without that individual's information. This guarantee holds for any individual and any dataset.

[0037] For differential insight, consider an arbitrary function f(x). The sensitivity of that function S(f) is the difference in function output when altering a single record:S(f) = |f(D) -f(D’)|where f(D) is the output of the function based on the current input and f(D’) is the output of the function when a single record is altered.

[0038] For the average (avg function) example above, this sensitivity is bound by a range of values defined by the number of possible start nodes for the Match function (aMe) which refers to a single author (Me) in this case and the total number of possible end nodes (b.file) which corresponds to the total number of files. The sensitivity representing the largest possible change) of S(f) is then:S(f) = (b - a) / nwhere a and b are the smallest and largest values respectively, and n is the number of elements in the selection. This sensitivity corresponds to the maximum sensitivity for the function S(f) when altering a single record, referred to herein as maximum differential insight Smax(f). Quantifying differential insight in terms of sensitivity, or differential insight, enables the maximum differential insight Smax(f) to be used as an indicator for determining whether a query' is scalable. For example, the maximum differential insight Smax(f) of a query can be compared to a predefined threshold for the maximum differential insight which corresponds to the maximum allowed change in output of the function when altering a single record.

[0039] The maximum differential insight Smax(f) of a uery can be determined in any suitable manner by any component of the system that has access to the range of values (a and b) and number of elements (n) in the selection. Furthermore, the concept of universal function approximation states that a neural network with even a single hidden layer and an arbitrary activation function can approximate any continuous function. Accordingly, based on this concept, any query' can be used to determine its own Smax.

[0040] Accordingly, for each query, the maximum differential insight Smax(f) for the query isdetermined and compared to a predefined differential insight threshold value Sthreshoid. If the maximum differential insight Smax(f) is less than the threshold, the query can be scaled by rewriting the query in a manner that reduces the number of database reads required to perform the query. In various implementations, this disclosure provides three query scaling techniques for rewriting queries to enable a reduction in database reads required for the query: predicate restriction, sorted index retrieval, and Montecarlo selection.

[0041] Predicate restriction refers to rewriting a query by adding restrictions to predicate ranges in the query which in turn reduces the number of reads required for the query. This technique requires that the underlying data store be capable of processing time series natively. Though this technique may not reduce data reads initially, pushdown optimizations ensure early evaluation of the predicate. This can be beneficial in certain storage configurations, such as ranges in B+ trees.

[0042] Following is an example of rewriting a query’ having a predicate in the form of a time range:MATCH (a:Me)-[rl :ModifiedBy]->(b:File)WHERE r.When > now() - 30daysRETURN avg(count(b. Authors))In this example, the predicate is the Boolean function used to filter results for the WHERE clause. In the original query, the WHERE clause used time range r.When > now() which will select all files that were modified by Me before now. The example query has been rewritten by restricting the time range to within the last 30 days by rewriting the time range as r.When > now() - 30days. Because the average function provides moderate differential insight, the predicate range can be restricted to reduce database reads dependent on system load. Even if the query produces no predicate, given the moderate differential insight of the query, a predicate can be injected to restrict load.

[0043] The sorted index retrieval technique is primarily useful for data stores which support native sorted indices. The index configurations and capabilities of data stores can be included in the graph schema, so that the system can determine the appropriate scaling technique to use for each data store. Sorted index retrieval can be used to restrict relevant content for the query when a sorted index is available for the database. An example of a query optimized for sorted index retrieval can be written as follows:MATCH (a:Me)-[rl :ModifiedBy]->(b:File)WITH b. Authors ORDER BY r.When LIMIT 10RETURN avg(count(b. Authors))In this example, the query is rewritten to take advantage of a sorted index by adding the ORDERBY and LIMIT clauses to the WITH clause to limit the number of records passed to the MATCH clause. Rewriting the query in this manner enables the desired records to be identified by ordering the sorted index which puts the relevant records at the top of the order. The LIMIT clause then restricts the selected records to the first ten which reduces the database reads that would otherwise be required for the query.

[0044] The choice of scaling technique depends on the data retrieval API's capabilities. Some data stores may require both techniques. Following is an example illustrating a combination of predicate restriction and sorted index filtering approaches:MATCH (a:Me)-[rl :ModifiedBy]->(b:File)WITH b. Authors ORDER BY r.When LIMIT 10 WHERE r.When > now() - 30days RETURN avg(count(b. Authors))In this example, the query is rewritten to include the ORDER BY and LIMIT clauses similar to the sorted index filtering example to enable ordering and limiting of selected records. The query’ also includes a predicate restriction (WHERE r.When > now() - 30days) for identifying the records to select. It is unlikely that a single index is optimized towards both retrieval methods, and explicit read operations are likely only efficiently processed by one technique. Regardless, the compounding cardinality and network transfer cost of multi -hop federated graph queries make the approach scalable.

[0045] Another technique for rewriting queries to reduce database reads is Montecarlo selection. This technique is useful when the index does not support ordered retrieval or sorted index filtering. Montecarlo selection involves random sampling a subset of data to identify records for selection. Similar to the previous example, the compounding cost of multiple round trips in a graph query and the cardinality of outer join operations make this approach feasible.

[0046] Rewriting queries to reduce database reads for queries (and in turn the latency of processing queries) is only required when the load on the system is such that the system cannot meet the target QoS, or target query’ latency. Accordingly, the system is configured to monitor query latency for the data stores to identify when the latency does not comply with the target QoS. To accomplish this, each query is instrumented to determine its own query latency. This can be accomplished by comparing current query latency measurements to a predefined latency threshold value. When the query latency does not satisfy the threshold, a scaling factor is calculated which is used to guide scaling of queries to reduce database reads for queries and in turn query latency.

[0047] The following equation can be used to calculate the scaling factor for scaling queries:FA (tmeasured — tSLA ) * Smax(f) * (rmax “ Tmin)where tmeasured is the measured latency of a query, ISLA is the expected latency of the query, Smax(f is the differential insight of the query’, and rmax and rmin define the acceptable scaling range for thescaling factor. In various implementations, when a query determines that the query latency does not satisfy the target QoS, the query calculates the scaling factor and returns the scaling factor along with the query result to the query7execution engine, as show n in FIG. 3. In FIG. 3, a graph query processing engine 120 receives a graph query 304 to be executed on a graph. The graph query engine 120 generates an execution plan for executing the query over relevant graph data stores. As shown in FIG. 3, the graph query' processing engine 120 produces a query7step 306 as part of the plan which is to be executed in a data store 308. The query step 306 includes the query7, the range (rmax-rmm), the target SLA (ISLA) (e.g., target latency), and the maximum differential insight (Smax(f ). The query is executed at the data store 118 and a step result is returned along with a scaling factor (FA) 310 that is calculated based on the measured query latency (tmeasured), the target latency (ISLA), the query differential insight (Smax(f)), and the range (rmax-rmm).

[0048] The scaling factor FA is returned to the query7execution planning component 210 so it can be used by the query rewriting component 222 to rewrite queries for the data store that scale based on the current latency of the data store. In various implementations, the scaling factor FA can used as the basis for deriving values to use in rewriting queries. For example, the scaling factor FA can be used to derive values for restricting predicate ranges and limiting selections from ordered lists. The example query from above can be rewritten as follows:MATCH (a: Me)- [r 1 : ModifiedBy ] ->(b Tile)WITH b. Authors ORDER BY r.When LIMIT N WHERE r.When > now() - 30days RETURN avg(count(b. Authors))In this example, the query has been rew ritten by replacing the LIMIT predicate with a value N which is derived from the scaling factor, where N = 1 / FA * I and I is the expected size of the index without any scaling restrictions.

[0049] FIG. 4 depicts a flowchart of an example method 400 for dynamic scaling of graph queries for a graph data storage system. The method 400 begins with receiving a graph query7requesting data from a graph data structure which abstracts data from a graph data storage system having a plurality of different data stores (block 402). An execution plan is then generated for executing the graph query across the different data stores of the graph data storage system (block 404). A first maximum differential insight is determined for a first query7of the execution plan (block 406), and a determination is made whether the first query is scalable by comparing the first maximum differential insight to a differential insight threshold (block 408). If the first query is scalable, the first query' is rewritten according to at least one query scaling technique such that an amount of database reads required to execute the first query is reduced without causing a differential insight of the first query7to increase above the differential insight threshold (block 410). The rewritten first query is then delivered to a graph query execution engine for executionon the first data store (block 412).

[0050] FIG. 5 is a block diagram 500 illustrating an example software architecture 502, various portions of which may be used in conjunction with various hardware architectures herein described, which may implement any of the above-described features. FIG. 5 is a non-limiting example of a software architecture and it will be appreciated that many other architectures may be implemented to facilitate the functionality described herein. The software architecture 502 may execute on hardware such as client devices, native application provider, web servers, server clusters, external services, and other servers. A representative hardware layer 504 includes a processing unit 506 and associated executable instructions 508. The executable instructions 508 represent executable instructions of the software architecture 502, including implementation of the methods, modules and so forth described herein.

[0051] The hardware layer 504 also includes a memory / storage 510, which also includes the executable instructions 508 and accompanying data. The hardware layer 504 may also include other hardware modules 512. Instructions 508 held by processing unit 506 may be portions of instructions 508 held by the memory / storage 510.

[0052] The example software architecture 502 may be conceptualized as layers, each providing various functionality. For example, the software architecture 502 may include layers and components such as an operating system (OS) 514, libraries 516, frameworks 518, applications 520, and a presentation layer 544. Operationally, the applications 520 and / or other components within the layers may invoke API calls 524 to other layers and receive corresponding results 526. The layers illustrated are representative in nature and other software architectures may include additional or different layers. For example, some mobile or special purpose operating systems may not provide the frameworks / middleware 518.

[0053] The OS 514 may manage hardware resources and provide common services. The OS 514 may include, for example, a kernel 528, services 530, and drivers 532. The kernel 528 may act as an abstraction layer between the hardware layer 504 and other software layers. For example, the kernel 528 may be responsible for memory management, processor management (for example, scheduling), component management, networking, security settings, and so on. The sendees 530 may provide other common services for the other software layers. The drivers 532 may be responsible for controlling or interfacing with the underlying hardware layer 504. For instance, the drivers 532 may include display drivers, camera drivers, memory / storage drivers, peripheral device drivers (for example, via Universal Serial Bus (USB)), network and / or wireless communication drivers, audio drivers, and so forth depending on the hardware and / or software configuration.

[0054] The libraries 516 may provide a common infrastructure that may be used by theapplications 520 and / or other components and / or layers. The libraries 516 typically provide functionality for use by other software modules to perform tasks, rather than rather than interacting directly with the OS 514. The libraries 516 may include system libraries 534 (for example, C standard library ) that may provide functions such as memory allocation, string manipulation, file operations. In addition, the libraries 516 may include API libraries 536 such as media libraries (for example, supporting presentation and manipulation of image, sound, and / or video data formats), graphics libraries (for example, an OpenGL library' for rendering 2D and 3D graphics on a display), database libraries (for example, SQLite or other relational database functions), and web libraries (for example, WebKit that may provide web browsing functionality). The libraries 516 may also include a wide variety of other libraries 538 to provide many functions for applications 520 and other softw are modules.

[0055] The frameworks 518 (also sometimes referred to as middleware) provide a higher-level common infrastructure that may be used by the applications 520 and / or other software modules. For example, the frameworks 518 may provide various graphic user interface (GUI) functions, high-level resource management, or high-level location services. The frameworks 518 may provide a broad spectrum of other APIs for applications 520 and / or other software modules.

[0056] The applications 520 include built-in applications 540 and / or third-party applications 542. Examples of built-in applications 540 may include, but are not limited to, a contacts application, a browser application, a location application, a media application, a messaging application, and / or a game application. Third-party applications 542 may include any applications developed by an entity other than the vendor of the particular system. The applications 520 may use functions available via OS 514, libraries 516, frameworks 518. and presentation layer 544 to create user interfaces to interact with users.

[0057] Some software architectures use virtual machines, as illustrated by a virtual machine 548. The virtual machine 548 provides an execution environment where applications / modules can execute as if they were executing on a hardware machine (such as the machine depicted in block diagram 600 of FIG. 6, for example). The virtual machine 548 may be hosted by a host OS (for example, OS 514) or hypervisor, and may have a virtual machine monitor 546 which manages operation of the virtual machine 548 and interoperation with the host operating system. A software architecture, which may be different from software architecture 502 outside of the virtual machine, executes within the virtual machine 548 such as an OS 550, libraries 552, frameworks 554, applications 556, and / or a presentation layer 558.

[0058] FIG. 6 is a block diagram illustrating components of an example machine 600 configured to read instructions from a machine-readable medium (for example, a machine-readable storage medium) and perform any of the features described herein. The example machine600 is in a form of a computer system, within which instructions 616 (for example, in the form of software components) for causing the machine 600 to perform any of the features described herein may be executed. As such, the instructions 616 may be used to implement methods or components described herein. The instructions 616 cause unprogrammed and / or unconfigured machine 600 to operate as a particular machine configured to carry out the described features. The machine 600 may be configured to operate as a standalone device or may be coupled (for example, networked) to other machines. In a networked deployment, the machine 600 may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a node in a peer-to-peer or distributed network environment. Machine 600 may be embodied as, for example, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a gaming and / or entertainment system, a smart phone, a mobile device, a wearable device (for example, a smart watch), and an Internet of Things (loT) device. Further, although only a single machine 600 is illustrated, the term “machine” includes a collection of machines that individually or jointly execute the instructions 616.

[0059] The machine 600 may include processors 610, memory 630, and I / O components 650, which may be communicatively coupled via, for example, a bus 602. The bus 602 may include multiple buses coupling various elements of machine 600 via various bus technologies and protocols. In an example, the processors 610 (including, for example, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), an ASIC, or a suitable combination thereof) may include one or more processors 612a to 612n that may execute the instructions 616 and process data. In some examples, one or more processors 610 may execute instructions provided or identified by one or more other processors 610. The term “processor” includes a multi-core processor including cores that may execute instructions contemporaneously. Although FIG. 6 shows multiple processors, the machine 600 may include a single processor with a single core, a single processor with multiple cores (for example, a multi-core processor), multiple processors each with a single core, multiple processors each with multiple cores, or any combination thereof. In some examples, the machine 600 may include multiple processors distributed among multiple machines.

[0060] The memory / storage 630 may include a main memory 632, a static memory7634, or other memory, and a storage unit 636, both accessible to the processors 610 such as via the bus 602. The storage unit 636 and memory 632, 634 store instructions 616 embodying any one or more of the functions described herein. The memory / storage 630 may also store temporary, intermediate, and / or long-term data for processors 610. The instructions 616 may also reside, completely or partially, within the memory 632, 634, within the storage unit 636, within at least one of the processors 610 (for example, within a command buffer or cache memory), withinmemory at least one of I / O components 650, or any suitable combination thereof, during execution thereof. Accordingly, the memory7632, 634, the storage unit 636, memory in processors 10, and memory in I / O components 650 are examples of machine-readable media.

[0061] As used herein, “machine-readable medium” refers to a device able to temporarily or permanently store instructions and data that cause machine 600 to operate in a specific fashion. The term “machine-readable medium,” as used herein, does not encompass transitory electrical or electromagnetic signals per se (such as on a carrier wave propagating through a medium); the term “machine-readable medium” may therefore be considered tangible and non-transitory. Nonlimiting examples of a non-transitory, tangible machine-readable medium may include, but are not limited to, nonvolatile memory (such as flash memory or read-only memory (ROM)), volatile memory (such as a static random-access memory' (RAM) or a dynamic RAM), buffer memory7, cache memory, optical storage media, magnetic storage media and devices, network-accessible or cloud storage, other types of storage, and / or any suitable combination thereof. The term “machine-readable medium” applies to a single medium, or combination of multiple media, used to store instructions (for example, instructions 616) for execution by a machine 600 such that the instructions, when executed by one or more processors 610 of the machine 600, cause the machine 600 to perform and one or more of the features described herein. Accordingly, a “machine-readable medium” may refer to a single storage device, as well as "cloud-based” storage systems or storage netw orks that include multiple storage apparatus or devices.

[0062] The I / O components 650 may include a wide variety7of hardw are components adapted to receive input, provide output, produce output, transmit information, exchange information, capture measurements, and so on. The specific I / O components 650 included in a particular machine will depend on the type and / or function of the machine. For example, mobile devices such as mobile phones may include a touch input device, whereas a headless sen7er or loT device may not include such a touch input device. The particular examples of I / O components illustrated in FIG. 6 are in no way limiting, and other ty pes of components may be included in machine 600. The grouping of I / O components 650 are merely for simplifying this discussion, and the grouping is in no way7limiting. In various examples, the I / O components 650 may include user output components 652 and user input components 654. User output components 652 may include, for example, display components for displaying information (for example, a liquid cry stal display (LCD) or a projector), acoustic components (for example, speakers), haptic components (for example, a vibratory motor or force-feedback device), and / or other signal generators. User input components 654 may include, for example, alphanumeric input components (for example, a keyboard or a touch screen), pointing components (for example, a mouse device, a touchpad, or another pointing instrument), and / or tactile input components (for example, a physical button ora touch screen that provides location and / or force of touches or touch gestures) configured for receiving various user inputs, such as user commands and / or selections.

[0063] In some examples, the I / O components 650 may include biometric components 656, motion components 658, environmental components 660 and / or position components 662, among a wide array of other environmental sensor components. The biometric components 656 may include, for example, components to detect body expressions (for example, facial expressions, vocal expressions, hand or body gestures, or eye tracking), measure biosignals (for example, heart rate or brain waves), and identify a person (for example, via voice-, retina-, and / or facial-based identification). The position components 662 may include, for example, location sensors (for example, a Global Position System (GPS) receiver), altitude sensors (for example, an air pressure sensor from which altitude may be derived), and / or orientation sensors (for example, magnetometers). The motion components 658 may include, for example, motion sensors such as acceleration and rotation sensors. The environmental components 660 may include, for example, illumination sensors, acoustic sensors and / or temperature sensors.

[0064] The I / O components 650 may include communication components 664, implementing a wide variety' of technologies operable to couple the machine 600 to network(s) 670 and / or device(s) 680 via respective communicative couplings 672 and 682. The communication components 664 may include one or more network interface components or other suitable devices to interface with the network(s) 670. The communication components 664 may include, for example, components adapted to provide wired communication, wireless communication, cellular communication, Near Field Communication (NFC), Bluetooth communication, Wi-Fi, and / or communication via other modalities. The device(s) 680 may include other machines or various peripheral devices (for example, coupled via USB).

[0065] In some examples, the communication components 664 may detect identifiers or include components adapted to detect identifiers. For example, the communication components 664 may include Radio Frequency Identification (RFID) tag readers, NFC detectors, optical sensors (for example, one- or multi-dimensional bar codes, or other optical codes), and / or acoustic detectors (for example, microphones to identify tagged audio signals). In some examples, location information may be determined based on information from the communication components 664 such as, but not limited to, geo-location via Internet Protocol (IP) address, location via Wi-Fi, cellular, NFC, Bluetooth, or other wireless station identification and / or signal triangulation.

[0066] While various embodiments have been described, the description is intended to be exemplary, rather than limiting, and it is understood that many more embodiments and implementations are possible that are within the scope of the embodiments. Although many possible combinations of features are shown in the accompanying figures and discussed in thisdetailed description, many other combinations of the disclosed features are possible. Any feature of any embodiment may be used in combination with or substituted for any other feature or element in any other embodiment unless specifically restricted. Therefore, it will be understood that any of the features shown and / or discussed in the present disclosure may be implemented together in any suitable combination. Accordingly, the embodiments are not to be restricted except in light of the attached claims and their equivalents. Also, various modifications and changes may be made within the scope of the attached claims.

[0067] While the foregoing has described what are considered to be the best mode and / or other examples, it is understood that various modifications may be made therein and that the subject matter disclosed herein may be implemented in various forms and examples, and that the teachings may be applied in numerous applications, only some of which have been described herein. It is intended by the following claims to claim any and all applications, modifications and variations that fall within the true scope of the present teachings.

[0068] Unless otherwise stated, all measurements, values, ratings, positions, magnitudes, sizes, and other specifications that are set forth in this specification, including in the claims that follow, are approximate, not exact. They are intended to have a reasonable range that is consistent with the functions to which they relate and with what is customary in the art to which they pertain.

[0069] The scope of protection is limited solely by the claims that now follow. That scope is intended and should be interpreted to be as broad as is consistent with the ordinary meaning of the language that is used in the claims when interpreted in light of this specification and the prosecution history that follows and to encompass all structural and functional equivalents. Notwithstanding, none of the claims are intended to embrace subject matter that fails to satisfy the requirement of Sections 101, 102, or 103 of the Patent Act, nor should they be interpreted in such a way. Any unintended embracement of such subject matter is hereby disclaimed.

[0070] Except as stated immediately above, nothing that has been stated or illustrated is intended or should be interpreted to cause a dedication of any component, step, feature, object, benefit, advantage, or equivalent to the public, regardless of whether it is or is not recited in the claims.

[0071] It will be understood that the terms and expressions used herein have the ordinary meaning as is accorded to such terms and expressions with respect to their corresponding respective areas of mquirv and study except where specific meanings have otherwise been set forth herein. Relational terms such as first and second and the like may be used solely to distinguish one entity or action from another without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises,” “comprising,” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process,method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by “a'’ or "an" does not, without further constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element. Furthermore, subsequent limitations referring back to "said element” or “the element” performing certain functions signifies that “said element” or “the element” alone or in combination with additional identical elements in the process, method, article or apparatus are capable of performing all of the recited functions.

[0072] The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in various examples for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claims require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed example. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject mater.

Claims

CLAIMS1. A data processing system for dynamic scaling of graph queries for a graph data storage system, the data processing system comprising:a processor (610); anda memory (630) in communication with the processor (610). the memory (630) comprising executable instructions (616) that, when executed by the processor (610) alone or in combination with other processors (610), cause the data processing system to perform operations of:receiving, at an execution planning component (210) of a graph query execution planner (206), a graph query for requesting data from a graph data structure which abstracts data from a graph data storage system having a plurality of different data stores (118);generating an execution plan for executing the graph query across the different data stores (118) of the graph data storage system, the execution plan including a first query to be performed on a first data store ( 118) of the plurality’ of data stores (118);determining a first differential insight for the first query at the graph query execution planner (206);determining at the graph query’ execution planner (206) that the first query’ is scalable by comparing the first differential insight to a differential insight threshold;rewriting the first query at the graph query execution planner (206) according to at least one query scaling technique to adjust an amount of database reads required to execute the first query’ based at least in part on the comparison between the first differential insight and the differential insight threshold; anddelivering the rewritten first query to a graph query execution engine (208) for execution on the first data store (118).

2. The data processing system of claim 1, further comprising:measuring a query’ latency for executing the first query'; andcomparing the measured query latency to an expected query’ latency for the first query to identify when the query latency does not comply with a target Quality of Service (QoS).

3. The data processing system of claims 1-2, further comprising:calculating a scaling factor for the first data store (118) based on the measured query' latency, the expected query' latency, and the first differential insight for the first query'; and returning the scaling factor for the first data store (118) to the graph query execution planner (206).

4. The data processing system of any of claims 1-3, wherein the scaling factor is calculated by multiplying a difference between the measured query latency and the expected query' latency by the first differential insight and a predetermined scaling range.

5. The data processing system of any of claims 1-4, further comprising:determining a second differential insight for a second query at the graph query execution planner (206), the second query7to be executed on the first data store (118);determining at the graph query execution planner (206) that the second query is scalable by comparing the second differential insight of the second query to the differential insight threshold;rewriting the second query7at the graph query' execution planner (206) according to at least one query scaling technique and with reference to the scaling factor to adjust an amount of database reads required to execute the second query based at least in part on the comparison between the second differential insight and the differential insight threshold ; and delivering the rewritten second query to the graph query7execution engine (208) for execution on the first data store (118).

6. The data processing system of any of claims 1-5, wherein the first query is rewritten to reduce the amount of database reads required to execute the first query7without causing the differential insight of the first query to increase above the differential insight threshold.

7. The data processing system of any of claims 1-6, wherein the first query7is configured to determine the first differential insight, the query latency, and the scaling factor.

8. The data processing system of any of claims 1-7, the first differential insight corresponds to a difference in query7output between an output of the first query when all relevant data records are considered and an output of the first query when a single one of the relevant data records is altered.

9. A method for dynamic scaling of graph queries for a graph data storage system the method comprising:receiving, at an execution planning component (210) of a graph query execution planner (206), a graph query for requesting data from a graph data structure which abstracts data from a graph data storage system having a plurality of different data stores (118);generating an execution plan for executing the graph query across the different data stores (118) of the graph data storage system, the execution plan including a first query to be performed on a first data store (118) of the plurality7of data stores (118);determining a first differential insight for the first query7at the graph query execution planner (206), the first differential insight corresponding to a difference in query output between an output of the first query when all relevant data records are considered and an output of the first query7when a single one of the relevant data records is altered;determining at the graph query execution planner (206) that the first query is scalable by comparing the first differential insight to a differential insight threshold;rewriting the first query at the graph query execution planner (206) according to at least one query scaling technique to adjust an amount of database reads required to execute the first query based at least in part on the comparison between the first differential insight and the differential insight threshold; anddelivering the rewritten first query to a graph query execution engine (208) for execution on the first data store (118).

10. The method of claim 9, further comprising:measuring a query latency for executing the first query;comparing the measured query latency to an expected query latency for the first query to identify when the query latency does not comply with a target Quality of Service (QoS).

11. The method of any of claims 9-10, further comprising:calculating a scaling factor for the first data store (118) based on the measured query' latency, the expected query’ latency, and the first differential insight for the first query; and returning the scaling factor for the first data store (118) to the graph query execution planner (206).

12. The method of any of claims 9-11, wherein the scaling factor is calculated by multiplying a difference between the measured query' latency and the expected query latency by the first differential insight and a predetermined scaling range.

13. The method of any of claims 9-12, further comprising:determining a second differential insight for a second query' at the graph query’ execution planner (206), the second query to be executed on the first data store (118);determining at the graph query execution planner (206) that the second query is scalable by comparing the second differential insight of the second query to the differential insight threshold;rewriting the second query at the graph query' execution planner (206) according to at least one query scaling technique and with reference to the scaling factor to adjust an amount of database reads required to execute the second query based at least in part on the comparison between the second differential insight and the differential insight threshold; anddelivering the rewritten second query to the graph query' execution engine (208) for execution on the first data store (118).

14. The method of any of claims 9-13, wherein the first query is rewritten to reduce the amount of database reads required to execute the first query without causing the differential insight of the first query to increase above the differential insight threshold.

15. The method of any of claims 9-14, wherein the first query' is configured to determine the first differential insight, the query latency, and the scaling factor.

16. The method of any of claims 9-15, the first differential insight corresponds to a difference in query output between an output of the first query when all relevant data records are considered and an output of the first query when a single one of the relevant data records is altered.

17. A non-transitory computer readable medium on which are stored instructions that, when executed, cause a programmable device to perform functions ofreceiving, at an execution planning component (210) of a graph query execution planner (206), a graph query for requesting data from a graph data structure which abstracts data from a graph data storage system having a plurality of different data stores (118);generating an execution plan for executing the graph query across the different data stores (118) of the graph data storage system, the execution plan including a first query to be performed on a first data store (118) of the plurality of data stores (118);determining a first differential insight for the first query' at the graph query execution planner (206);determining at the graph query- execution planner (206) that the first query is scalable by comparing the first differential insight to a differential insight threshold;rewriting the first query' at the graph query' execution planner (206) according to at least one query scaling technique to adjust an amount of database reads required to execute the first query based at least in part on the comparison between the first differential insight and the differential insight threshold; anddelivering the reyvritten first query' to a graph query execution engine (208) for execution on the first data store (118).

18. The non-transitory computer readable medium of claim 17, further comprising:measuring a query latency for executing the first query;comparing the measured query' latency to an expected query latency for the first query to identify yvhen the query' latency does not comply with a target Qualify of Service (QoS).

19. The non-transitory computer readable medium of any of claims 17-18. further comprising:calculating a scaling factor for the first data store (118) based on the measured query latency, the expected query latency, and the first differential insight for the first query; and returning the scaling factor for the first data store (118) to the graph query' execution planner (206).

20. The non-transitory computer readable medium of any of claims 17-19. further comprising:determining a second differential insight for a second query at the graph query execution planner (206), the second query to be executed on the first data store (118);determining at the graph query execution planner (206) that the second query' is scalable by comparing the second differential insight of the second query to the differential insightthreshold;rewriting the second query at the graph query execution planner (206) according to at least one query7scaling technique and with reference to the scaling factor to adjust an amount of database reads required to execute the first query; anddelivering the rewritten second query to the graph query’ execution engine (208) for execution on the first data store (118).

Images