Generating and executing query plans including sharding operations

Abstract

A method performed by a computing device to execute a query plan including a sharding operation is disclosed herein. The method comprises the following steps: executing a first operation included in a query plan to obtain target fragment discovery information for one or more fragment objects from a first group of one or more fields of one or more fragment objects of an object type; and in response to determining that a second operation included in the query plan is a fragmentation operation, executing the second operation included in the query plan to identify one or more sub-graph instances storing the one or more fragmentation objects based on target fragmentation discovery information for the one or more fragmentation objects, and retrieve one or more shard objects from one or more sub-graph instances that store the one or more shard objects.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of data query services, and more specifically, to generating and executing query plans that include sharding operations. Background Technology

[0002] GraphQL is an open-source data querying and manipulation language for application programming interfaces (APIs) and query runtime engines. GraphQL enables declarative data retrieval, where clients can specify exactly what data they need from the API. Instead of multiple endpoints that return separate data, a GraphQL server exposes a single endpoint and responds with the data requested by the client. Because a GraphQL server can retrieve data from multiple data sources and represent it in a unified graph, it is not dependent on any particular database technology or storage engine.

[0003] GraphQL federation is an architectural model that allows multiple GraphQL services (sometimes referred to as subgraphs or federated services) to be combined into a single schema or API. In a federated architecture, multiple subgraphs can be combined to form a hypergraph. Routers can be configured with a description of the hypergraph. Clients can query routers for data belonging to any subgraph of the hypergraph. When a router receives a query for data, it can use the hypergraph description to generate a query plan to retrieve the requested data from the appropriate subgraph of the hypergraph.

[0004] A query plan describes the operations to be performed to generate query results for a given query. A query plan can describe which subgraphs need to be queried and what data to retrieve from those subgraphs (e.g., which objects and which fields of those objects). A query plan can consider dependencies between different operations (e.g., whether the first subgraph needs to be queried before the second subgraph, because a query sent to the second subgraph depends on query results from the first subgraph). Furthermore, a query plan can consider whether specific operations can be executed in parallel or need to be executed sequentially.

[0005] Sharding is a technique used for horizontally scaling databases. In a sharded database architecture, instead of storing all data in a single database, data is divided into smaller chunks and stored across multiple database instances to distribute the load.

[0006] Data belonging to a subgraph can be sharded, but shards are not visible to GraphQL routers. Existing GraphQL solutions can generate query plans that can route queries to the appropriate subgraph based on the type of the queried object (e.g., by leveraging the description of the hypergraph), but they cannot generate query plans that can route queries to the appropriate shard based on the value of the queried object when the data is sharded. GraphQL does not provide a native shard discovery mechanism. Summary of the Invention

[0007] The embodiments disclosed herein disclose a method executed by a computing device to perform a query plan including a sharding operation. The method includes: performing a first operation included in the query plan to obtain target sharding discovery information for the one or more sharding objects from a first set of one or more fields of one or more sharding objects of an object type; and in response to determining that a second operation included in the query plan is a sharding operation, performing the second operation included in the query plan to identify one or more subgraph instances storing the one or more sharding objects based on the target sharding discovery information for the one or more sharding objects, and obtaining the one or more sharding objects from the one or more subgraph instances storing the one or more sharding objects.

[0008] The embodiments disclosed herein are a non-transitory machine-readable medium including computer program code that, when executed by a computing device, causes the computing device to perform operations for executing a query plan including sharding operations. The operations include: performing a first operation included in the query plan to obtain target sharding discovery information for the one or more sharding objects from a first set of one or more fields of one or more sharding objects of an object type; and, in response to determining that a second operation included in the query plan is a sharding operation, performing the second operation included in the query plan to identify one or more subgraph instances storing the one or more sharding objects based on the target sharding discovery information for the one or more sharding objects, and obtaining the one or more sharding objects from the one or more subgraph instances storing the one or more sharding objects.

[0009] The embodiments disclosed herein disclose a computing device configured to execute a query plan including sharding operations. The computing device includes one or more processors and a non-transitory machine-readable storage medium storing instructions, which, when executed by the one or more processors, cause the computing device to perform operations for executing the query plan including sharding operations. The operations include: performing a first operation included in the query plan to obtain target sharding discovery information for the one or more sharding objects from a first set of one or more fields of one or more sharding objects of an object type; and, in response to determining that a second operation included in the query plan is a sharding operation, performing the second operation included in the query plan to identify one or more subgraph instances storing the one or more sharding objects based on the target sharding discovery information for the one or more sharding objects, and obtaining the one or more sharding objects from the one or more subgraph instances storing the one or more sharding objects. Attached Figure Description

[0010] The invention can be best understood by referring to the following description and drawings used to illustrate embodiments of the invention. In the drawings:

[0011] Figure 1 This is a diagram illustrating an environment in which query plans, including sharding operations, can be generated and executed according to some embodiments;

[0012] Figure 2 This is a diagram illustrating a sub-diagram description according to some embodiments;

[0013] Figure 3 This is a flowchart illustrating a method for generating a query plan according to some embodiments;

[0014] Figure 4 This is a flowchart illustrating a method for executing a query plan according to some embodiments;

[0015] Figure 5 This is a diagram illustrating query plans and query plans without shard discovery according to some embodiments;

[0016] Figure 6 This is a diagram illustrating a query plan that includes sharding operations for a specific subgraph instance, according to some embodiments;

[0017] Figure 7 This is a diagram illustrating a query plan that includes sharding operations for all subgraph instances according to some embodiments;

[0018] Figure 8 This is a diagram illustrating a method for generating and executing a query plan including sharding operations according to some embodiments;

[0019] Figure 9 This is a diagram illustrating another method for generating and executing a query plan that includes sharding operations, according to some embodiments;

[0020] Figure 10 The diagram illustrates the connection between network devices within a network according to some embodiments of the present invention, and three possible implementations of the ND. Detailed Implementation

[0021] The following description describes methods and apparatus for generating and executing query plans that include sharding operations. In this description, numerous specific details are set forth, such as logical implementation, opcodes, means of specifying operands, resource partitioning / sharing / copying implementation, types and interrelationships of system components, and logical partitioning / integration choices, in order to provide a more thorough understanding of the invention. However, those skilled in the art will understand that the invention can be practiced without such specific details. In other instances, control structures, gate-level circuits, and complete sequences of software instructions have not been shown in detail so as not to obscure the invention. With the included description, those skilled in the art will be able to implement appropriate functionality without excessive experimentation.

[0022] References to "an embodiment," "embodiment," "example embodiment," etc., in this specification indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment may necessarily include that particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Additionally, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is assumed that implementing such a feature, structure, or characteristic in conjunction with other embodiments (whether explicitly described or not) is well known to those skilled in the art.

[0023] This document may use text within parentheses and boxes with dashed borders (e.g., thick dashed lines, thin dashed lines, dotted dashed lines, and dots) to illustrate optional operations for adding additional features to embodiments of the invention. However, such notation should not be interpreted as these texts and boxes being merely options or optional operations, and / or boxes with solid borders not being optional in particular embodiments of the invention.

[0024] In the following description and claims, the terms “coupled” and “connected” and their derivatives may be used. It should be understood that these terms are not intended to be synonyms with each other. “Coupled” is used to indicate that two or more elements (which may or may not be in direct physical or electrical contact with each other) cooperate or interact with each other. “Connected” is used to indicate the establishment of communication between two or more elements that are coupled to each other.

[0025] Electronic devices use machine-readable media (also known as computer-readable media) to store and transmit (internal and / or via a network with other electronic devices) code (which consists of software instructions and is sometimes referred to as computer program code or computer program) and / or data. Machine-readable media include, for example, machine-readable storage media (e.g., disks, optical discs, solid-state drives, read-only memory (ROM), flash memory devices, phase-change memory) and machine-readable transmission media (also known as carriers) (e.g., electrical, optical, radio, acoustic, or other forms of propagation signals, such as carrier waves, infrared signals). Therefore, electronic devices (e.g., computers) include hardware and software, such as a group of one or more processors (e.g., where the processors are microprocessors, controllers, microcontrollers, central processing units, digital signal processors, application-specific integrated circuits, field-programmable gate arrays, other electronic circuits, or combinations thereof) coupled to one or more machine-readable storage media to store code for execution on that group of processors and / or stored data. For example, an electronic device may include non-volatile memory containing code, because even when the electronic device is turned off (when power is off), the non-volatile memory can retain the code / data, and when the electronic device is turned on, that portion of the code to be executed by the processor of the electronic device is typically copied from the slower non-volatile memory to the volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)) of the electronic device. A typical electronic device also includes a set of one or more physical network interfaces (NIs) to establish network connections with other electronic devices (to send and / or receive code and / or data using propagation signals). For example, the set of physical NIs (or the set of physical NIs combined with the set of processors executing the code) can perform any formatting, encoding, or conversion to allow the electronic device to send and receive data (whether via wired and / or wireless connections). In some embodiments, the physical NIs may include radio circuitry capable of receiving data from other electronic devices and / or transmitting data to other devices via wireless connections. The radio circuitry may include transmitters, receivers, and / or transceivers suitable for radio frequency communications. Radio circuits can convert digital data into radio signals with appropriate parameters (e.g., frequency, timing, channel, bandwidth, etc.). These radio signals can then be transmitted via an antenna to a suitable receiver. In some embodiments, this set of physical NIs may include a network interface controller (NIC), also known as a network interface card, network adapter, or local area network (LAN) adapter. A NIC facilitates the connection of electronic devices to other electronic devices, allowing them to communicate via wires by plugging cables into physical ports connected to the NIC. One or more portions of embodiments of the invention may be implemented using different combinations of software, firmware, and / or hardware.

[0026] A network device (ND) is an electronic device that connects other electronic devices (e.g., other network devices, end-user devices) on a communication interconnection network. Some network devices are "multi-service network devices" that provide support for a variety of networking functions (e.g., routing, bridging, switching, Layer 2 aggregation, session boundary control, quality of service, and / or user management) and / or support for a variety of application services (e.g., data, voice, and video).

[0027] As mentioned above, existing GraphQL solutions can generate query plans that route queries to the appropriate subgraph based on the type of the queried object (e.g., based on a description utilizing the hypergraph), but they cannot generate query plans that route queries to the appropriate shard based on the value of the queried object when the data is sharded. Plugins or standalone databases / services can be used to help identify queries and route them to the appropriate shards, but this requires building, customizing, and integrating add-ons, which adds complexity. GraphQL does not provide a native shard discovery mechanism.

[0028] Fragmentation can be used in mobile networks. For example, in the 3GPP Service-Based Architecture (SBA), some services are “fragmented,” meaning that different instances of a function (e.g., the Policy Control Function (PCF)) are responsible for answering queries for different UE (User Equipment) groups. A caller wishing to query a fragmented function for information about a specific UE group (e.g., the Network Open Function (NEF)) must first query a “discovery” function (e.g., the Binding Support Function (BSF)) to identify which instances of the fragmented function are responsible for storing information about that specific UE group. If such a function is modeled in the GraphQL ecosystem, a GraphQL router can determine, based on the resolution of dependencies between multiple operations, that the discovery function (e.g., the BSF) must be queried before the fragmented function (e.g., the PCF) is queried. However, GraphQL routers do not have a native way to customize the query plan to use the information obtained from the discovery function to direct the query to the specific instance of the fragmented function responsible for storing data about that specific UE group. Separate plugins or databases / services can be used to perform fragmented discovery and / or fragmented queries “on the side.” However, this increases complexity and requires building, customizing, and maintaining separate components, which introduces more potential points of failure and incurs additional costs.

[0029] The embodiments described herein can natively incorporate shard discovery and shard query functionality (e.g., splitting / routing queries to appropriate shards (determined based on shard discovery) and aggregating results) as part of the query plan generation and execution phase, without relying on separate plugins or databases / services to perform shard discovery and / or shard queries. In the embodiments, the subgraph description of a subgraph includes instructions associated with an object type, indicating that objects of that object type are sharded (e.g., data related to the object may be stored across multiple subgraph instances of the subgraph). These instructions may include an indication of which field is used to store shard discovery information for objects of that object type. The shard discovery information for the object may include an address associated with the subgraph instance responsible for storing the corresponding object, or information that can be used to derive those addresses. When a router receives a query from a client for an object of an object type, the router can determine, based on these instructions, which field is used to store shard discovery information for the requested object. The router can then add a first operation to the query plan to retrieve the shard discovery information for the sharded object from the field set of the sharded object (if the query plan has not already included an operation to retrieve shard discovery information). Routers can also add a second operation to the query plan to retrieve the requested object. This second operation can be marked as a sharding operation in the query plan so that it receives special handling when the query plan is executed.

[0030] During the query plan execution phase, the router may perform a first operation included in the query plan to obtain fragmentation discovery information for the requested object from the field group of the requested object. Furthermore, in response to determining that a second operation included in the query plan is a fragmentation operation, the router may perform the second operation by: (1) identifying the subgraph instance storing the requested object based on the fragmentation discovery information; and (2) retrieving the requested object from the identified subgraph instance. For example, the router may determine the address of the subgraph instance responsible for storing the requested object based on the fragmentation discovery information and send queries addressed to those addresses to retrieve the requested object from the subgraph instance.

[0031] The technical advantage of the embodiments described herein lies in their provision of native support for shard discovery and shard querying by incorporating these functionalities into the query plan generation and execution phases. This contrasts with conventional shard discovery solutions that use plugins or separate databases / services to perform shard discovery and / or shard querying "in the side." By providing native support for shard discovery and shard querying functionality, the embodiments eliminate the need to build, customize, and maintain separate mechanisms for providing such functionality, simplifying the implementation of sharding services. Furthermore, by centralizing shard discovery and shard querying functionality within the router, the embodiments eliminate the complexity of subgraphs (e.g., compared to GraphQL implementations where sharding is performed within the subgraph). Additionally, the embodiments are capable of handling more complex queries where only some of the requested data is sharded. While specific technical advantages of the embodiments have been mentioned above, those skilled in the art will understand that, in light of this disclosure, the embodiments can possess other advantages. The embodiments are now described with reference to the accompanying drawings.

[0032] Figure 1 This is a diagram illustrating an environment in which query plans, including sharding operations, can be generated and executed according to some embodiments.

[0033] As shown in the figure, the environment includes router 110, client 120, and hypergraph 130. Client 120 can send a query to router 110 to request data belonging to hypergraph 130. In response to receiving the query from client 120, router 110 can generate a query plan for the query and execute the query plan. Query plan execution may involve retrieving objects from different subgraphs 140 of hypergraph 130 (and possibly different subgraph instances 150 of subgraph 140) and aggregating the retrieved objects to generate query results for the query. Router 110 can then send the query results to client 120. Router 110 may maintain or otherwise access a description of hypergraph 130 to enable federation.

[0034] Although a specific arrangement of components is shown in the figures to illustrate an embodiment, it should be understood that other embodiments may have different component arrangements. For example, although the environment is shown as including a single client 120 for simplicity, it should be understood that the environment will typically include multiple clients 120 that can send queries to router 110.

[0035] Hypergraph 130 may include multiple subgraphs. Each subgraph 140 may store objects and fields of a specific type, as described in the subgraph description of subgraph 140. An example subgraph description is provided in... Figure 2 As shown in the text, and for Figure 2The following description is provided. Each subgraph 140 may include one or more subgraph instances 150. Each subgraph instance 150 of subgraph 140 may store a subset of data belonging to subgraph 140 and may answer queries related to that data. In embodiments, subgraph instances 150 may be GraphQL servers or similar servers. Some subgraphs 140 may include only one subgraph instance 150 and are therefore not considered "sharded," while other subgraphs 140 may include multiple subgraph instances 140, in which case the subgraph 140 is considered "sharded."

[0036] For example, in the example shown in the figure, supergraph 130 includes two subgraphs: subgraph A 140A and subgraph B 140B. Subgraph A can represent the BSF of the mobile network, and subgraph B 140B can represent the PCF of the mobile network. Subgraph A 140A stores the "id" field and the "PcfBinding" field of an "ApplicationSession" object. The "ApplicationSession" object can represent an application session in the mobile network. The "id" field of the "ApplicationSession" object can be used to store the unique identifier of the "ApplicationSession" object. The "PcfBinding" of the "ApplicationSession" object can be used to store the "PcfBinding" object associated with the "ApplicationSession" object. The "PcfBinding" object can represent the binding between an instance of the PCF and the UE (in addition, the application session is associated with the UE, so the binding can effectively represent the binding between an instance of the PCF and the application session). The "PcfBinding" object may include the "ipv4Addr" field and the "pcfFqdn" field. The "ipv4Addr" subfield of the "PcfBinding" object can be used to store the Internet Protocol Version 4 (IPv4) address of the "PcfBinding" object (which can represent the IPv4 address of the UE), and the "pcfFqdn" field of the "PcfBinding" object can be used to store the fully qualified domain name (FQDN) of the "PcfBinding" object (which can represent the FQDN associated with the PCF instance). In the example shown in the figure, subgraph A 140A also stores the "PcfFqdns" field, which is used to store a list of all FQDNs associated with the "ApplicationSession" object (which can represent the FQDNs associated with all instances of the PCF). Note that in this example, subgraph A 140A has a single subgraph instance 150A and is therefore not fragmented.

[0037] The "pcfFqdn" field of the "PcfBinding" object of the "ApplicationSession" object can be used to store the FQDN associated with a specific subgraph instance 150 of sharded subgraph B 140B that is responsible for storing data related to the "ApplicationSession" object. Therefore, the "pcfFqdn" field can be considered as providing "target" sharding discovery information for the "ApplicationSession" object. The "PcfFqdns" field can be used to store a list of all FQDNs associated with the subgraph instance 150 of sharded subgraph B 140B that stores the "ApplicationSession" object. Therefore, the "PcfFqdns" field can be considered as providing "complete" sharding discovery information.

[0038] Furthermore, in the example shown in the diagram, subgraph B 140B stores the "id" and "afAppId" fields of the "ApplicationSession" object. The "id" field of the "ApplicationSession" object can be used to store the unique identifier of the "ApplicationSession" object. The "afAppId" field of the "ApplicationSession" object can be used to store the identifier of the application associated with the "ApplicationSession" object. Subgraph B 140B is fragmented and includes two subgraph instances 150: subgraph instance 150B and subgraph instance 150C. In the example shown in the diagram, subgraph instance 150B (which is associated with FQDN "instance2.pcf.network") stores data related to the "ApplicationSession" object with "id" 1 and the "ApplicationSession" object with "id" 3. Subgraph instance 150C (which is associated with FQDN "instance1.pcf.network") stores data related to the "ApplicationSession" object with "id" 2.

[0039] The following example operation for processing queries against sharded objects will now be described with reference to the figure to illustrate the implementation.

[0040] In operation 1, client 120 sends a query to router 110 for sharded objects of object type. For example, client 120 may send a query to router 110 for "ApplicationSession" objects with "id" values ​​of 1 and 2. Note that client 120 may not be aware of the details of federation and / or sharding implementation.

[0041] In operation 2, router 110 generates a query plan for the query. The query plan may include a first operation to obtain fragmentation discovery information for fragmented objects and a second operation to obtain the fragmented objects. The second operation may be marked as a fragmentation operation so that it can receive special processing during the query plan execution phase.

[0042] For example, a query plan could include a first operation to retrieve the FQDN from the "pcfFqdn" subfield of the "PcfBinding" field of the "ApplicationSession" objects with "id" 1 and 2. The query plan could also include a second operation to retrieve the "ApplicationSession" objects with "id" 1 and 2, where the second operation is marked as a sharding operation.

[0043] In operation 3, router 110 performs a first operation included in the query plan to obtain fragmentation discovery information for the fragmentation object. For example, router 110 may perform a first operation to obtain the FQDN from the "pcfFqdn" field of the "PcfBinding" field of the "ApplicationSession" object with "id" 1 and 2. In this example, the FQDN obtained from the "ApplicationSession" object with "id" 1 is "instance2.pcf.network", and the FQDN obtained from the "ApplicationSession" object with "id" 2 is "instance1.pcf.network". These FQDNs identify the subgraph instance 150 that stores data related to the requested "ApplicationSession" object, and are therefore considered as "target" fragmentation discovery information for the requested "ApplicationSession" object.

[0044] In operation 4, router 110 performs a second operation included in the query plan. Because the second operation is marked as a sharding operation, router 110 can perform this operation specially. For example, router 110 can perform the following two sub-operations as part of performing the second operation: (1) router 110 identifies a subgraph instance storing sharded objects based on sharding discovery information (e.g., by determining the address associated with the subgraph instance); and (2) router 110 retrieves the sharded objects from the identified subgraph instance. For example, router 110 can perform the second operation by determining the FQDN associated with subgraph instance 150 storing “ApplicationSession” objects with “id” 1 and 2 (e.g., which can be extracted or exported from the result of performing the first operation), and then sending a query addressing to the retrieved FQDN to retrieve data related to these “ApplicationSession” objects from subgraph instance 150. In this example, router 110 can send a query addressed to FQDN "instance2.pcf.network" to retrieve data related to the "ApplicationSession" object with "id" 1 from subgraph instance 150B, and send a query addressed to FQDN "instance1.pcf.network" to retrieve data related to the "ApplicationSession" object with "id" 2 from subgraph instance 150C.

[0045] Then, router 110 can generate query results based on the objects obtained from the aggregation, and send the query results to client 120. For example, router 110 can generate query results that include data related to the "ApplicationSession" object with "id" 1 and data related to the "ApplicationSession" object with "id" 2, and send the query results to client 120.

[0046] The embodiments provide native support for sharding by incorporating sharding discovery and sharding query functionality into the query plan generation and execution phases. Therefore, the embodiments provide native support for querying sharded subgraphs without requiring the construction, customization, and maintenance of separate mechanisms for performing sharding discovery and sharding queries, simplifying the implementation of sharding services. Furthermore, by centralizing sharding discovery and sharding query functionality within the router, the embodiments eliminate the complexity of subgraphs (e.g., compared to GraphQL implementations where sharding is performed internally within the subgraph). Moreover, by marking specific operations included in the query plan as sharding operations and providing special handling for these operations during query plan execution, the embodiments are able to handle more complex queries where only some of the requested data is sharded.

[0047] Although the embodiments are described primarily in the context of a GraphQL environment, it should be understood that the techniques disclosed herein are not limited thereto and can be used in other environments using different query languages ​​or query runtime engines.

[0048] Figure 2 This is a diagram illustrating a sub-diagram description according to some embodiments.

[0049] This figure illustrates example subgraph descriptions for subgraphs A 140A and B 140B. In GraphQL, these descriptions can also be referred to as "schemas." For ease of illustration, the GraphQL schema language is used to represent the subgraph descriptions. It should be understood that other languages / formats can be used to express subgraph descriptions.

[0050] Subgraph A description 210 describes the objects and fields belonging to subgraph A. As shown in the figure, subgraph A description 210 describes the "PcfBinding" object and the "ApplicationSession" object.

[0051] The “PcfBinding” object can represent the binding between a PCF instance and a UE / application session. According to Sub-Figure A, Description 210, the “PcfBinding” object includes an “ipv4Addr” field and a “pcfFqdn” field. The “ipv4Addr” field of the “PcfBinding” object is used to store a string indicating the IP address of the “PcfBinding” object (e.g., it could represent the IP address of the UE). The “pcfFqdn” field of the “PcfBinding” object is used to store a string indicating the FQDN of the “PcfBinding” object (e.g., it could represent the FQDN associated with the PCF instance).

[0052] The “ApplicationSession” object can represent an application session. According to subgraph A, description 210, the “ApplicationSession” object includes an “id” field, a “PcfBinding” field, and a “PcfFqdns” field. The “id” field of the “ApplicationSession” object is used to store the unique identifier of the “ApplicationSession” object. The “PcfBinding” field of the “ApplicationSession” object is used to store / reference the “PcfBinding” object associated with the “ApplicationSession” object. The “PcfFqdns” field is used to store a list of strings indicating the FQDN associated with the subgraph instance storing the “ApplicationSession” object.

[0053] Subgraph B description 220 describes the objects and fields belonging to subgraph B. As shown in the figure, subgraph B description 220 describes the "ApplicationSession" object. The "ApplicationSession" object includes the "id" field, the "PcfBinding" field, and the "PcfFqdns" field. The "PcfBinding" and "PcfFqdns" fields are annotated with the "@external" directive to indicate that these fields can be accessed through a different subgraph (subgraph A in this example). In addition, the "ApplicationSession" object includes the "afAppId" field, which is used to store a string indicating the identifier of the application associated with the "ApplicationSession" object.

[0054] Furthermore, as shown in the figure, subgraph B description 220 includes instruction 230 (“@sharded” instruction) to indicate that the “ApplicationSession” object is sharded in subgraph B. Instruction 230 includes “fields”, “forced”, and “instances” parameters. The “fields” parameter can indicate one or more fields used to store target sharding discovery information for the sharded object. The “forced” parameter can indicate whether sharding is forced. The “instances” parameter can indicate one or more fields used to store complete sharding discovery information for the sharded object. In the example shown in the figure, instruction 230 instructs that the "pcfFqdn" subfield of the "PcfBinding" field is used to store target sharding discovery information for the "ApplicationSession" object ("fields: 'PcfBinding { pcfFqdn}"), sharding is not forced ("forced: false"), and the "PcfFqdns" field is used to store full sharding discovery information for the "ApplicationSession" object ("instances: PcfFqdns").

[0055] As will be described in further detail herein, the “forced” field can be set to “true” to force router 110 to store only subgraph instances of the requested shard object. The “forced” field can be set to “false” to allow router 110 to obtain complete shard discovery information and query all subgraph instances of the stored shard object.

[0056] In one embodiment, the target fragmentation discovery information for a fragmented object includes the address of a subgraph instance storing the fragmented object. In another embodiment, the address of the subgraph instance is an FQDN or an IP address. In yet another embodiment, the target fragmentation discovery information does not include the address itself, but includes information that can be used to derive the address. In this case, router 110 can apply a function / translation to the target fragmentation discovery information to derive the address.

[0057] Figure 3 This is a flowchart illustrating a method for generating a query plan according to some embodiments. In the embodiments, the method is performed by a computing device (e.g., a computing device implementing router 110).

[0058] The operations in the flowcharts will be described with reference to exemplary embodiments of other figures. However, it should be understood that the operations in the flowcharts may be performed by embodiments of the invention other than those discussed with reference to the other figures, and the embodiments of the invention discussed with reference to those other figures may perform operations different from those discussed with reference to those flowcharts.

[0059] In operation 305, the computing device receives a query for an object of type object. In this embodiment, the query is a GraphQL query or a similar query. For example, continuing the example provided above, the computing device may receive a query for an object of type "ApplicationSession".

[0060] In operation 310, the computing device determines whether an object is sharded. In an embodiment, the computing device determines that an object is sharded based on detecting an instruction associated with the object type (in the subgraph description) indicating that the object type is sharded. For example, the computing device may determine that an "ApplicationSession" object is sharded based on detecting an "@sharded" instruction associated with the "ApplicationSession" object type in the subgraph description of subgraph B. If the computing device determines that the object is not sharded, in operation 315, the computing device adds an operation to the query plan to retrieve the non-sharded object (e.g., using conventional means), and the process ends.

[0061] Otherwise, if the computing device determines that an object is sharded, then in operation 320, the computing device determines a first set of fields used to store target sharding discovery information for sharded objects of the object type. In an embodiment, the instruction associated with the object type includes an indication of the first set of fields, and the computing device determines the first set of fields based on that indication. For example, the computing device may determine that the "PcfBinding { pcfFqdn}" field is used to store target sharding discovery information for the "ApplicationSession" object based on the "fields" parameter of the "@sharded" instruction associated with the "ApplicationSession" object type.

[0062] In operation 325, the computing device determines whether the query plan already includes the operation of retrieving the values ​​of the first set of fields of the sharded object. If the computing device determines that the query plan already includes the operation of retrieving the values ​​of the first set of fields of the sharded object, the process moves to operation 345. Otherwise, if the computing device determines that the query plan does not include the operation of retrieving the values ​​of the first set of fields of the sharded object, the process moves to operation 330.

[0063] In operation 330, the computing device determines whether sharding is forced. In an embodiment, the instruction associated with the object type includes an indication of whether sharding is forced, and the computing device determines whether sharding is forced based on this indication. For example, if the value of the "forced" parameter of the "@sharded" instruction associated with the "ApplicationSession" object type is "true", the computing device can determine that sharding is forced, and if the value of the "forced" parameter is "false", it determines that sharding is not forced. If the computing device determines that sharding is forced, in operation 335, the computing device adds an operation to the query plan to obtain target sharding discovery information for the sharding object from a first set of fields of the sharding object. For example, the computing device can add an operation to the query plan to obtain target sharding discovery information for the requested "ApplicationSession" object from the "PcfBinding { pcfFqdn}" field of these "ApplicationSession" objects (from the (non-sharded) subgraph A).

[0064] Returning to operation 330, if the computing device determines that sharding is not enforced, then in operation 340, the computing device adds an operation to the query plan to retrieve complete sharding discovery information for the sharded object of the object type from the second set of fields. In an embodiment, the instruction associated with the object type includes an indication of the second set of fields, and the computing device determines the second set of fields based on this indication. For example, the computing device may determine that the "PcfFqdns" field is used to store complete sharding discovery information for the "ApplicationSession" object based on the "instances" parameter of the "@sharded" instruction associated with the "ApplicationSession" object type. The computing device may then add an operation to retrieve complete sharding discovery information for the "ApplicationSession" object from the "PcfFqdns" field (e.g., if the query plan has not already included such an operation).

[0065] In operation 345, the computing device adds an operation to the query plan to retrieve sharded objects. This operation is marked as a sharding operation. In an embodiment, the operation is annotated with a Boolean parameter indicating whether the operation is sharded. This Boolean parameter can be set to the value "true" to indicate that the operation is a sharding operation, and set to the value "false" to indicate that the operation is not a sharding operation. In an embodiment, the operation references a first set of fields and / or a second set of fields.

[0066] As a result of the operations described above, the query plan includes at least a first operation to obtain shard discovery information from the appropriate field group and a second operation to obtain shard objects, wherein the second operation is marked as a sharding operation. As will be described in further detail herein, the router may perform special processing on the second operation (which is marked as a sharding operation) during the execution of the query plan.

[0067] Figure 4 This is a flowchart illustrating a method for executing a query plan according to some embodiments. In these embodiments, the method is executed by a computing device (e.g., a computing device implementing a GraphQL router).

[0068] In operation 405, the computing device obtains the operation included in the query plan. For example, continuing the example provided above, the computing device may obtain the operation to retrieve the "ApplicationSession" objects with "id" 1 and 2 (e.g., this operation is added to the query plan as part of executing operation 345).

[0069] In operation 410, the computing device determines whether the operation is marked as a sharded operation. In an embodiment, the operation is annotated with a Boolean parameter indicating whether the operation is a sharded operation, and the computing device determines whether the operation is marked as a sharded operation based on the value of the Boolean parameter. For example, if the operation is annotated with a "sharded" parameter set to the value "true", the computing device can determine that the operation is marked as a sharded operation, and if the operation is annotated with a "sharded" parameter set to the value "false" or is not annotated with a "sharded" parameter, the computing device can determine that the operation is not marked as a sharded operation. If the computing device determines that the operation is not marked as a sharded operation, then in operation 415, the computing device executes the operation normally. That is, the computing device executes the operation without performing shard discovery and sharded queries (e.g., splitting / routing queries to appropriate subgraph instances and aggregating results).

[0070] Returning to operation 410, if the computing device determines that the operation is marked as a sharding operation, then in operation 420, the computing device determines whether target sharding discovery information for the sharding object has already been obtained. The computing device may have already obtained the target sharding discovery information as part of executing one or more previous operations included in the query plan. For example, continuing the example provided above, the computing device may have executed a previous operation included in the query plan to obtain target sharding discovery information for the "ApplicationSession" object from the "PcfBinding { pcfFqdn}" field of the "ApplicationSession" object. If the computing device determines that target sharding discovery information for the sharding object has already been obtained, then in operation 425, the computing device obtains / accesses the (already obtained) target sharding discovery information for the sharding object.

[0071] In operation 430, the computing device determines a subgraph instance storing a shard object based on target shard discovery information for the shard object. In one embodiment, the computing device determines the subgraph instance by determining the address of the subgraph instance based on the target shard discovery information. In one embodiment, the target shard discovery information includes the address of the subgraph instance (e.g., FQDN). In this case, the computing device can directly extract the address of the subgraph instance from the target shard discovery information. In another embodiment, the target shard discovery information does not include the address itself, but includes information that can be used to derive the address of the subgraph instance. In this case, the computing device can apply a function / conversion to the target shard discovery information to derive the address of the subgraph instance. For example, the computing device can determine that the FQDN associated with the subgraph instance storing an "ApplicationSession" object with "id" 1 is "instance2.pcf.network", and the FQDN associated with the subgraph instance storing an "ApplicationSession" object with "id" 2 is "instance1.pcf.network".

[0072] In operation 435, the computing device retrieves shard objects from the determined subgraph instances. In an embodiment, the computing device retrieves shard objects from the determined subgraph instances based on sending a query to the determined subgraph instances (e.g., by addressing the query to the address of the subgraph instance). In an embodiment, shard objects are retrieved in parallel from the determined subgraph instances. For example, the computing device may send queries addressing FQDNs “instance1.pcf.network” and “instance2.pcf.network” to retrieve “ApplicationSession” objects with “id” of 1 and 2 from the corresponding subgraph instances associated with these FQDNs.

[0073] Returning to operation 420, if the computing device determines that target shard discovery information for the sharded object has not been obtained, then in operation 440, the computing device obtains complete shard discovery information for the sharded object of the object type. The computing device may have already obtained the complete shard discovery information as part of executing a previous operation included in the query plan. For example, the computing device may have executed a previous operation included in the query plan to obtain complete shard discovery information for the "ApplicationSession" object from the "PcfFqdns" field.

[0074] In operation 440, the computing device determines a list of subgraph instances based on complete shard discovery information. The list of subgraph instances may include all subgraph instances of sharded objects of storage object type. In an embodiment, the list of subgraph instances takes the form of a list of addresses (e.g., FQDNs) associated with the subgraph instances. For example, the computing device may determine that the list of subgraph instances includes "instance1.pcf.network" and "instance2.pcf.network".

[0075] In operation 445, the computing device queries all subgraph instances included in the subgraph instance list to locate the shard object. In an embodiment, subgraph instances are queried in parallel. For example, the computing device may send queries addressed to FQDNs “instance1.pcf.network” and “instance2.pcf.network” to search for the subgraph instance storing the requested “ApplicationSession” object. This is a broadcast method of querying all subgraph instances.

[0076] In operation 450, the computing device generates query results based on aggregated shard objects. For example, the computing device may generate query results that include the "afAppId" values ​​of "ApplicationSession" objects with "id" values ​​of 1 and 2.

[0077] In operation 455, the computing device provides the query results to the client.

[0078] Figure 5 This is a diagram illustrating query plans and query plans without shard discovery according to some embodiments.

[0079] The query 510 shown in the diagram queries the "afAppId" field of the "ApplicationSession" object associated with the IP address "10.0.0.3". For simplicity, query 510 queries a single field of the "ApplicationSession" object. However, it should be understood that query 510 can query additional fields of the "ApplicationSession" object.

[0080] Query plan 520 is an example of a query plan that the router would generate without using the native sharding discovery mechanism disclosed herein. As shown in the figure, query plan 520 includes separate "fetch" operations to attempt to fetch the requested object from each subgraph instance of subgraph B. Essentially, each subgraph instance of subgraph B is treated as a separate and independent subgraph and is queried separately. The client is responsible for aggregating the results.

[0081] Figure 6This is a diagram illustrating a query plan that includes sharding operations targeting specific subgraph instances, according to some embodiments.

[0082] The query plan 610 shown in the figure is an example of a query plan generated by a router that implements the native shard discovery mechanism disclosed in this paper.

[0083] Query plan 610 includes a first operation 620 that retrieves target sharding discovery information for the "ApplicationSession" object from the "PcfBinding" field. Query plan 610 also includes a second operation 630 marked as a sharding operation (the operation is commented with "sharded: true"). The second operation references the field used to store the target sharding discovery information for the "ApplicationSession" object, which in this example is the "applicationSession.PcfBinding.pcfFqdn" field.

[0084] During the execution of the query plan, the router may perform a first operation to obtain target fragmentation discovery information for the "ApplicationSession" object. The router may then perform a second operation to determine, based on the obtained target fragmentation discovery information, the FQDN associated with the subgraph instance storing the "ApplicationSession" object, and send a query addressing that FQDN to retrieve the "ApplicationSession" object from the subgraph instance associated with that FQDN.

[0085] Figure 7 This is a graph illustrating a query plan that includes sharding operations for all subgraph instances according to some embodiments.

[0086] The query plan 710 shown in the figure is an example of a query plan generated by a router that implements the native fragmentation discovery mechanism disclosed in this paper.

[0087] Query plan 710 includes a first operation 720 that retrieves complete sharding discovery information for the "ApplicationSession" object from the "PcfFqdns" field. Query plan 710 also includes a second operation 730 marked as a sharding operation (the operation is commented with "sharded: true"). The second operation references the field used to store the complete sharding discovery information for the "ApplicationSession" object, which in this example is the "applicationSession.PcfFqdns" field.

[0088] During the execution of the query plan, the router may perform a first operation to obtain complete fragmentation discovery information for the "ApplicationSession" object. The router may then perform a second operation to determine, based on the complete fragmentation discovery information, the FQDNs associated with all subgraph instances storing the "ApplicationSession" object, and send queries to these FQDNs to inquire about all subgraph instances for the "ApplicationSession" object.

[0089] Figure 8 This is a diagram illustrating a method for generating and executing a query plan that includes sharding operations, according to some embodiments. In these embodiments, the method is performed by a computing device (e.g., a computing device implementing a GraphQL router).

[0090] This method includes a query plan generation phase and a query plan execution phase. The query plan generation phase includes operations 810-840. The query plan execution phase includes operations 850-880.

[0091] In operation 810, the computing device receives a query from the client for one or more sharded objects of an object type.

[0092] In operation 820, the computing device, based on instructions associated with the object type, determines a set of one or more fields used to store target shard discovery information for a shard object of the object type. In an embodiment, the instructions associated with the object type include: an indication of a set of one or more fields used to store target shard discovery information for a shard object of the object type, an indication of whether sharding is forced, and an indication of a second set of one or more fields used to store complete shard discovery information for a shard object of the object type.

[0093] In operation 830, the computing device adds a first operation to the query plan to obtain target shard discovery information for one or more shard objects from a set of one or more fields of one or more shard objects. In an embodiment, the target shard discovery information for one or more shard objects includes addresses storing one or more subgraph instances of the one or more shard objects. In an embodiment, the addresses storing one or more subgraph instances of the one or more shard objects are FQDNs associated with storing one or more subgraph instances of the one or more shard objects. In an embodiment, the target shard discovery information for one or more shard objects includes information that can be used to derive the addresses storing one or more subgraph instances of the one or more shard objects.

[0094] In operation 840, the computing device adds a second operation to the query plan to retrieve one or more sharded objects. The second operation is marked as a sharding operation.

[0095] In operation 850, the computing device performs a first operation included in the query plan to obtain target shard discovery information for one or more shard objects from a set of one or more fields of one or more shard objects.

[0096] In operation 860, in response to determining that the second operation included in the query plan is a sharding operation, the computing device performs the second operation included in the query plan to identify one or more subgraph instances storing one or more shard objects based on target sharding discovery information for one or more shard objects, and retrieves one or more shard objects from the one or more subgraph instances storing one or more shard objects.

[0097] In Operation 870, the computing device generates query results for a query based on the aggregation of one or more sharded objects.

[0098] In operation 880, the computing device provides the client with the query results for the query.

[0099] In an embodiment, one or more fragment objects represent one or more application sessions in a mobile network, and a set of one or more fields of one or more fragment objects are included in a subgraph representing the BSF of the mobile network.

[0100] Figure 9 This is a diagram illustrating another method for generating and executing a query plan that includes sharding operations, according to some embodiments. In this embodiment, the method is performed by a computing device (e.g., a computing device implementing a GraphQL router). The method can be performed when sharding is not enforced.

[0101] This method includes a query plan generation phase and a query plan execution phase. The query plan generation phase includes operations 910-940. The query plan execution phase includes operations 950-980.

[0102] In Operation 910, the computing device receives a query from the client for one or more sharded objects of an object type.

[0103] In operation 920, the computing device, based on instructions associated with the object type, determines a set of one or more fields used to store complete shard discovery information for a sharded object of the object type. In an embodiment, the instructions associated with the object type include: an indication of a set of one or more fields used to store complete shard discovery information for a sharded object of the object type; an indication of another set of one or more fields used to store target shard discovery information for a sharded object of the object type; and an indication of whether sharding is enforced.

[0104] In an embodiment, the computing device, based on instructions associated with the object type, determines that a different set of one or more fields (one or more fields different from the set of one or more fields used to store complete shard discovery information) is used to store target shard discovery information for shard objects of the object type. The computing device can then determine whether the query plan includes an operation to retrieve the target shard discovery information for the one or more shard objects from the different set of one or more fields. In response to determining that the query plan does not include an operation to retrieve the target shard discovery information for the one or more shard objects from the different set of one or more fields, the computing device can determine whether sharding is forced based on instructions associated with the object type. If sharding is not forced, the computing device can perform operation 930.

[0105] In operation 930, the computing device adds a first operation to the query plan to obtain complete shard discovery information for sharded objects of an object type from a set of one or more fields. In an embodiment, the complete shard discovery information for sharded objects of an object type includes a list of subgraph instances storing objects of the object type.

[0106] In operation 940, the computing device adds a second operation to the query plan to retrieve one or more sharded objects. The second operation is marked as a sharding operation.

[0107] In operation 950, the computing device performs the first operation included in the query plan to obtain complete sharding discovery information for sharded objects of object type from a set of one or more fields.

[0108] In operation 960, in response to determining that the second operation included in the query plan is a sharding operation, the computing device performs the second operation included in the query plan to determine a list of subgraph instances based on complete sharding discovery information for sharded objects of object type, and queries all subgraph instances included in the list of subgraph instances to find one or more sharded objects.

[0109] In Operation 970, the computing device generates query results for a query based on the aggregation of one or more sharded objects.

[0110] In operation 980, the computing device provides the client with the query results for the query.

[0111] In an embodiment, one or more fragment objects represent one or more application sessions in a mobile network, and a set of one or more fields of one or more fragment objects are included in a subgraph representing the BSF of the mobile network.

[0112] Figure 10 The diagram illustrates connections between network devices (NDs) within a network, and three possible implementations of NDs, according to some embodiments of the present invention. Figure 10 The diagram illustrates NDs 1000A-H and their connections via lines between 1000A-1000B, 1000B-1000C, 1000C-1000D, 1000D-1000E, 1000E-1000F, 1000F-1000G, and 1000A-1000G, as well as between 1000H and each of 1000A, 1000C, 1000D, and 1000G. These NDs are physical devices, and the connections between them can be wireless or wired (often referred to as links). Additional lines extending from NDs 1000A, 1000E, and 1000F illustrate how these NDs act as entry and exit points for the network (and therefore, these NDs are sometimes referred to as edge NDs; while other NDs may be referred to as core NDs).

[0113] Figure 10 Two example ND implementations in the example ND implementations are: 1) a dedicated network device 1002 using a custom application-specific integrated circuit (ASIC) and a dedicated operating system (OS); and 2) a general-purpose network device 1004 using a common off-the-shelf (COTS) processor and a standard OS.

[0114] Dedicated network device 1002 includes networking hardware 1010, which includes a set of one or more processors 1012, forwarding resources 1014 (which typically include one or more ASICs and / or network processors), a physical network interface (NI) 1016 (through which network connections are made, such as those shown by the connection between ND 1000A-H), and a non-transitory machine-readable storage medium 1018 in which networking software 1020 is stored. During operation, networking software 1020 can be executed by networking hardware 1010 to instantiate a set of one or more networking software instances 1022. Each networking software instance 1022 and the portion of networking hardware 1010 that executes that networking software instance (hardware dedicated to that networking software instance and / or time slices of hardware shared by that networking software instance with other networking software instances 1022) form a separate virtual network unit 1030A-R. Each virtual network unit (VNE) 1030A-R includes a control communication and configuration module 1032A-R (sometimes referred to as a local control module or control communication module) and a forwarding table 1034A-R, such that a given virtual network unit (e.g., 1030A) includes the control communication and configuration module (e.g., 1032A), a set of one or more forwarding tables (e.g., 1034A), and the portion of the networking hardware 1010 that executes the virtual network unit (e.g., 1030A).

[0115] The dedicated network device 1002 is generally considered to include, physically and / or logically,: 1) an ND control plane 1024 (sometimes referred to as the control plane), which includes a processor 1012 that performs control communication and configuration modules 1032A-R; and 2) an ND forwarding plane 1026 (sometimes referred to as the forwarding plane, data plane, or media plane), which includes forwarding resources 1014 utilizing forwarding tables 1034A-R and physical NI 1016. For example, in the case where the ND is a router (or implements routing functions), the ND control plane 1024 (processor 1012 that performs control communication and configuration modules 1032A-R) is generally responsible for participating in how control data (e.g., packets) should be routed (e.g., the next hop of the data and the outgoing physical NI of the data) and storing that routing information in the forwarding table 1034A-R, while the ND forwarding plane 1026 is responsible for receiving the data on the physical NI 1016 and forwarding the data to the appropriate physical NI 1016 based on the forwarding table 1034A-R.

[0116] In one embodiment, software 1020 includes code such as sharding component 1023 that, when executed by networking hardware 1010, causes dedicated network device 1002 to perform operations of one or more embodiments disclosed herein (e.g., generating and / or executing a query plan that includes sharding discovery and sharding query capabilities, as described above).

[0117] The general-purpose network device 1004 includes hardware 1040, which includes one or more processors 1042 (typically COTS processors) and physical N1 1046, as well as non-transitory machine-readable storage 1048 where software 1050 is stored. During operation, the processors 1042 execute the software 1050 to instantiate one or more sets of one or more applications 1064A-R. Although one embodiment does not implement virtualization, alternative embodiments may use different forms of virtualization. For example, in one such alternative embodiment, virtualization layer 1054 represents the kernel of an operating system (or an adaptation layer (shim) executed on a base operating system) that allows the creation of multiple instances 1062A-R (referred to as software containers), each instance of which can be used to execute a set (or more sets) of applications 1064A-R; wherein the multiple software containers (also referred to as virtualization engines, virtual private servers, or isolated environments (jails)) are user spaces (typically virtual memory spaces) that are isolated from each other and from the kernel space in which the operating system runs; and wherein a set of applications running in a given user space cannot access the memory of other processes unless explicitly permitted. In another such alternative embodiment, virtualization layer 1054 represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor that executes on top of the host operating system, and each of the multiple sets of applications 1064A-R runs on top of an instance 1062A-R (referred to as a virtual machine, which in some cases can be considered a strictly isolated form of software container) within the hypervisor. The guest operating system and applications may not be aware that they are running on virtual machines rather than on “bare metal” host electronic devices, or through paravirtualization, the operating system and / or applications may be aware of the presence of virtualization for optimization purposes. In other alternative embodiments, one, some, or all of the applications are implemented as a monolithic kernel, which can be generated by compiling the application directly with only a limited set of libraries (e.g., from a Library Operating System (LibOS) that includes drivers / libraries for the OS services) that provide the specific OS services required by the application. Because a single kernel can be implemented to run directly on hardware 1040, directly on the hypervisor (in which case, the single kernel is sometimes described as running within the LibOS virtual machine), or in a software container, an embodiment can be implemented entirely by a single kernel running directly on the hypervisor represented by virtualization layer 1054, by a single kernel running within a software container represented by instances 1062A-R, or by a combination of a single kernel and the above techniques (e.g., a single kernel and a virtual machine both running directly on the hypervisor, a single kernel and multiple sets of applications running in different software containers).

[0118] The instantiation and virtualization (if implemented) of one or more groups of applications 1064A-R are collectively referred to as software instances 1052. Each group of applications 1064A-R, the corresponding virtualization construct (e.g., instance 1062A-R) (if implemented), and the portion of hardware 1040 that executes them (the hardware dedicated to that execution and / or the time slice of hardware shared in time) form a separate virtual network unit 1060A-R.

[0119] Virtual Network Unit 1060A-R performs similar functions to Virtual Network Unit 1030A-R, such as controlling the communication and configuration module 1032A and the forwarding table 1034A (this virtualization of hardware 1040 is sometimes referred to as Network Functions Virtualization (NFV)). Therefore, NFV can be used to integrate many network device types onto industry-standard high-capacity server hardware, physical switches, and physical storage devices that can reside in data centers, NDs, and Customer Premises Equipment (CPEs). Although embodiments of the invention are shown by way of each instance 1062A-R corresponding to a VNE 1060A-R, alternative embodiments may implement this correspondence at a finer granularity (e.g., line card virtualization of line cards, control card virtualization of control cards, etc.); it should be understood that the techniques described herein with reference to the correspondence between instance 1062A-R and VNE are also applicable to embodiments using such a finer granularity and / or a single core.

[0120] In a particular embodiment, the virtualization layer 1054 includes a virtual switch that provides forwarding services similar to those of a physical Ethernet switch. Specifically, the virtual switch forwards traffic between instance 1062A-R and physical NI 1046, and optionally between instances 1062A-R. Furthermore, the virtual switch can implement network isolation between VNE1060A-R that are not permitted to communicate with each other according to policy (e.g., by following Virtual Local Area Network (VLAN) rules).

[0121] In an embodiment, software 1050 includes code such as sharding component 1053 that, when executed by hardware 1040, causes general-purpose networking device 1004 to perform operations of one or more embodiments disclosed herein (e.g., generating and / or executing a query plan that includes sharding discovery and sharding query capabilities, as described above).

[0122] Figure 10The third example ND implementation is a hybrid network device 1006, which includes both a custom ASIC / dedicated OS and a COTS processor / standard OS in a single ND or a single card within an ND. In a particular embodiment of such a hybrid network device, a platform VM (i.e., a VM that implements the functionality of the dedicated network device 1002) can provide paravirtualization to the networking hardware present in the hybrid network device 1006.

[0123] Regardless of the example implementations of the ND described above, when considering a single VNE among multiple VNEs implemented by the ND (e.g., only one VNE among VNEs is part of a given virtual network), or in the case where only a single VNE is currently implemented by the ND, the abbreviation term Network Element (NE) is sometimes used to refer to that VNE. Furthermore, in all the example implementations described above, each VNE (e.g., the VNEs in VNE 1030A-R, VNE 1060A-R, and the hybrid network device 1006) receives data on a physical NI (e.g., 1016, 1046) and forwards that data to the appropriate physical NI (e.g., 1016, 1046). For example, a VNE that implements IP router functionality forwards IP packets based on some IP header information in the IP packets; where the IP header information includes the source IP address, destination IP address, source port, destination port (where “source port” and “destination port” refer to protocol ports in this document, not the physical ports of the ND), and transport protocol (e.g., User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Differential Service Code Point (DSCP) value).

[0124] A network interface (NI) can be physical or virtual; and in the context of IP, an interface address is an IP address assigned to an NI (whether physical or virtual). A virtual NI can be associated with a physical NI, associated with another virtual interface, or can exist independently (e.g., a loopback interface, a point-to-point protocol interface). NIs (physical or virtual) can be numbered (NIs with IP addresses) or unnumbered (NIs without IP addresses). A loopback interface (and its loopback address) is a specific type of virtual NI (and IP address) typically used for management purposes; such an IP address is called a node loopback address. The IP address of an NI assigned to an ND is called the IP address of that ND; at a finer granular level, the IP address assigned to an NI (which is assigned to an NE / VNE implemented on the ND) can be called the IP address of that NE / VNE.

[0125] Some parts of the previously described description have been provided based on the algorithms and symbolic representations of transactions concerning data bits within computer memory. These algorithmic descriptions and representations are the means by which those skilled in the art of data processing most effectively communicate the essence of their work to others skilled in the art. Here, an algorithm is generally considered to be a self-consistent sequence of transactions that lead to a desired result. These transactions are those that require physical manipulation of physical quantities. Typically, although not always necessary, these quantities take the form of electrical or magnetic signals that can be stored, transmitted, combined, compared, and otherwise manipulated. It has proven convenient, sometimes primarily for general reasons, to refer to these signals as bits, values, elements, symbols, characters, items, numbers, etc.

[0126] However, it should be remembered that all these and similar terms are to be associated with appropriate physical quantities and are merely convenient labels applied to those quantities. Unless otherwise explicitly stated from the above discussion, it will be understood that throughout the description, discussions using terms such as “processing” or “estimating” or “calculating” or “determining” or “displaying” refer to the actions and processes of a computer system or similar electronic computing device that manipulate data represented as physical (electronic) quantities within the computer system’s registers and memory and convert them into other data similarly represented as physical quantities within the computer system’s memory or registers or other such information storage, transmission, or display devices.

[0127] The algorithms and displays provided herein are not inherently related to any particular computer or other device. Various general-purpose systems can be used with the programs taught herein, or it may prove convenient to construct more specialized devices to perform the desired methodological transactions. The required structures for various systems will become apparent from the description above. Furthermore, embodiments are described without reference to any particular programming language. It will be understood that the teachings of the embodiments described herein can be implemented using various programming languages.

[0128] An embodiment may be an article of manufacture in which a non-transitory machine-readable storage medium (e.g., microelectronic memory) stores instructions (e.g., computer code) thereon that program one or more data processing components (generally referred to herein as a "processor") to perform the operations described above. In other embodiments, some of these operations may be performed by specific hardware components (e.g., dedicated digital filter blocks and state machines) containing hard-wired logic. Alternatively, these operations may be performed by any combination of programmed data processing components and fixed hard-wired circuit components.

[0129] Throughout this description, embodiments have been provided using flowcharts. It will be understood that the transactions and their order described in these flowcharts are intended for illustrative purposes only and are not intended to be limiting. Those skilled in the art will recognize that changes can be made to the flowcharts.

[0130] In the foregoing specification, embodiments have been described with reference to specific example embodiments. It will be apparent that various modifications can be made to the embodiments without departing from the broader spirit and scope of this disclosure. Therefore, the specification and drawings are to be considered illustrative rather than restrictive.

Claims

1. A method executed by a computing device to execute a query plan including sharding operations, the method comprising: Perform (850) a first operation included in the query plan to obtain target shard discovery information for the one or more shard objects from a first set of one or more fields of one or more shard objects of an object type; as well as In response to determining that the second operation included in the query plan is a sharding operation, (860) the second operation included in the query plan is performed to identify one or more subgraph instances storing the one or more shard objects based on the target sharding discovery information for the one or more shard objects, and to obtain the one or more shard objects from the one or more subgraph instances storing the one or more shard objects.

2. The method according to claim 1, further comprising: Receive (810) a first query for the one or more sharded objects from the client; Based on instructions associated with the object type, it is determined (820) that one or more fields in the first group are used to store target shard discovery information for sharded objects of the object type; Add (830) the first operation to the query plan, wherein the first operation references one or more fields of the first set used to store target shard discovery information for shard objects of the object type; and Add (840) the second operation to the query plan, wherein the second operation is marked as a sharding operation and references one or more fields of the first set used to store target sharding discovery information for sharded objects of the object type.

3. The method according to claim 2, further comprising: Based on the aggregation of the one or more sharded objects, generate (870) query results for the first query; as well as Provide the client with (880) the query results for the first query.

4. The method according to claim 2, wherein, The instructions associated with the object type include: an indication of one or more fields of a first set used to store target shard discovery information for shard objects of the object type, an indication of whether sharding is forced, and an indication of one or more fields of a second set used to store complete shard discovery information for shard objects of the object type.

5. The method according to claim 2, further comprising: Receive a second query for a second or more sharded objects of a second object type; Based on the instructions associated with the second object type, it is determined that one or more fields in a third group are used to store target shard discovery information for shard objects of the second object type; Determine whether the second query plan includes operations that retrieve target shard discovery information for the second or more shard objects from the third set of one or more fields of the second or more shard objects; In response to determining that the second query plan does not include the operation of obtaining target shard discovery information for the second or more shard objects from the third set of one or more fields of the second or more shard objects, it is determined whether sharding is forced based on the instruction associated with the second object type; In response to determining that sharding is not enforced, based on the instructions associated with the second object type, a fourth set of one or more fields is determined to be used to store complete sharding discovery information for sharded objects of the second object type; Add a third operation to the second query plan to obtain the complete shard discovery information for the shard objects of the second object type from one or more fields of the fourth group used to store the complete shard discovery information for the shard objects of the second object type; as well as A fourth operation is added to the second query plan to obtain the second or more shard objects, wherein the fourth operation is marked as a sharding operation and references the fourth set of one or more fields used to store complete sharding discovery information for shard objects of the second object type.

6. The method according to claim 5, further comprising: Perform the third operation included in the second query plan to obtain the complete shard discovery information for the sharded object of the second object type from one or more fields in the fourth group; as well as In response to determining that the fourth operation included in the second query plan is a sharding operation, the fourth operation included in the second query plan is performed to determine a list of subgraph instances based on the complete sharding discovery information for sharded objects of the second object type, and to query all subgraph instances included in the list of subgraph instances to find the second or more sharded objects.

7. The method according to claim 1, wherein, The target shard discovery information for the one or more shard objects includes the addresses of the one or more subgraph instances of the one or more shard objects.

8. The method according to claim 7, wherein, The address where the one or more subgraph instances of the one or more shard objects are stored is the fully qualified domain name (FQDN) associated with the one or more subgraph instances of the one or more shard objects.

9. The method according to claim 1, wherein, The target shard discovery information for the one or more shard objects includes information that can be used to derive the addresses of the one or more subgraph instances storing the one or more shard objects.

10. The method according to claim 1, wherein, The one or more shard objects represent one or more application sessions in a mobile network, and the first set of one or more fields of the one or more shard objects are included in a subgraph representing the Binding Support Function (BSF) of the mobile network.

11. A computing device (1004) for executing a query plan including sharding operations, the computing device comprising: One or more processors (1042); as well as A non-transitory machine-readable storage medium (1048) storing instructions that, when executed by the one or more processors, cause the computing device to perform the steps of the method according to any one of claims 1-10.

12. A machine-readable medium comprising computer program code, which, when executed by a computing device, performs the steps of the method according to any one of claims 1-10.

Images