Identifier parsing in distributed knowledge graph

Abstract

The disclosed technology generally relates to identification parsing in a distributed knowledge graph. In one example of the techniques, a graph query is received. The metagraph includes identifier acceptance information associated with which of the data storage acceptance identifiers of the plurality of data stores, and identifier derivation information associated with which of the data storage derivation identifiers of the plurality of data stores. The meta-graph and cost information are used to select from among query paths a query path capable of implementing the graph query based on minimizing cost according to a cost metric. Upon determining that a failure has occurred in the selected query path, the selected query path is changed using the metagraph and the cost information. A response to the graph query is provided based on the selected query path.

Description

Background Art

[0001] Distributed knowledge graphs can be used to connect knowledge, resources, people, and more. In such a structure, entities are typically presented as nodes, and the relationships between these entities are presented as edges in a view of the distributed knowledge graph, which is maintained by a graph database distributed across multiple data stores. The distributed knowledge graph can be periodically queried by users via graph queries to understand the relationships between entities. For example, users can issue graph queries to find friends or contacts within a social network, documents with which a given user has interacted, users who have accessed a given document, entities that meet various search criteria, and so on. Summary of the Invention

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

[0003] Briefly, the disclosed technology is generally directed to identity resolution in a distributed knowledge graph, according to some examples as follows. A graph query is received. The graph query is associated with a distributed graph of a system. The system includes multiple data stores. The graph query includes a request for data. A metagraph is provided, such that the metagraph includes identifier information associated with identifiers. The identifier information includes identifier acceptance information associated with which of the identifiers are accepted by a data store from the multiple data stores, and the identifier information also includes identifier derivation information associated with which of the identifiers are derived by the data store from the multiple data stores. Cost information associated with a cost of a query path between the data stores is obtained based on at least a first cost metric. The metagraph and the cost information are used to select a query path from the query paths that can implement the graph query based on minimizing the cost according to the first cost metric. Upon determining that a failure has occurred in the selected query path, the selected query path is changed using the metagraph and the cost information. A response to the graph query is provided based on the selected query path. The response to the graph query includes the data.

[0004] Other aspects and applications of the disclosed technology will be understood upon reading and understanding the drawings and description. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Non-limiting and non-exhaustive examples of the present disclosure are described with reference to the following figures. In the figures, like reference numerals refer to like parts throughout the various figures unless otherwise indicated. The figures are not necessarily drawn to scale.

[0006] For a better understanding of the present disclosure, reference will be made to the following detailed description, which is to be read in conjunction with the accompanying drawings, in which:

[0007] Figure 1 is a block diagram illustrating an example of a network connection system;

[0008] Figure 2 is a block diagram illustrating an example of a system for identity resolution in a distributed knowledge graph;

[0009] Figure 3 is a flow chart illustrating an example process for identity resolution in a distributed knowledge graph;

[0010] Figure 4 is a block diagram illustrating one example of a suitable environment in which aspects of the present technology may be employed; and

[0011] Figure 5 is a block diagram illustrating one example of a suitable computing device in accordance with aspects of the disclosed technology. DETAILED DESCRIPTION

[0012] The productivity service may provide various services to users of the productivity service. For example, the productivity service may provide various services to users. These services may include cloud services, access to various applications, communication services, security services, device management services, file services that allow users to store, access, and share files, and the like.

[0013] Distributed knowledge graphs can be used to connect knowledge, resources, people, and more. In the structure of a distributed knowledge graph, entities are typically represented as nodes, and the relationships and actions between these entities are represented as edges. The graph can be periodically queried by users via graph queries to understand the relationships between entities. For example, a user can issue a graph query to find friends or contacts within a social network, documents with which a given user has interacted, users who have accessed a given document, entities that meet various search criteria, and so on. In some examples, the distributed knowledge graph can be used as follows.

[0014] The distributed knowledge graph maps data for multiple systems. The system includes a large number of heterogeneous data stores, each of which is built according to the specific requirements of the data hosted therein. The graph is used to locate entities modeled on the graph using identifiers that act as keys. The identifiers used to locate specific logical entities or edges to / from these nodes vary across data stores. For example, in some examples, the mail storage system is optimized to have data retrieved by email address, the directory system uses a globally unique ObjectId, and several other systems each use completely different identifiers (IDs). The metagraph is used to present data from different data stores, including heterogeneous data stores that use different identifiers as a single consistent logical graph. The metagraph enables data in a distributed graph structure to be uniquely identified while supporting the use of multiple different identifiers. The metagraph includes information about which identifiers the data store accepts and which identifiers the data store exports for each data store modeled in the graph.

[0015] When a graph query requesting data spans multiple stores that internally use different IDs for the same logical entity, the graph query can be satisfied as follows. The query planner identifies the data stores that must be accessed in order to retrieve the data. The query planner uses the metagraph to determine which identifiers those data stores accept when being queried. In this case, the query planner uses this information to determine possible query paths based on which identifiers the data stores accept and which identifiers the data stores export. The query path is the set of ID-resolutions / transformations that are traversed to satisfy the graph query.

[0016] The query planner then uses the cost information to automatically determine an optimal query path based on a specific cost metric (such as latency, freshness, CO2 emissions, monetary cost, or another suitable cost metric). In the event of a service interruption in the path determined as the optimal query path, the query planner determines a different query path instead. The determined query path is then executed to satisfy the graph query and provide the requested data in response to the graph query.

[0017] Exemplary System

[0018] Figure 1 is a block diagram illustrating an example of a system (100). Figure 1 and in the manual Figure 1 The corresponding description illustrates an example system for illustrative purposes and does not limit the scope of the present disclosure. System 100 includes a network 130, and client devices 151 and 152, graph server devices 161 and 162, and data storage devices 171, 172, and 173, all connected to network 130.

[0019] Each of the client devices 151 and 152, the map server devices 161 and 162, and the data storage devices 171, 172, and 173 includes Figure 5 FIG. 5 shows an example of a computing device 500. FIG. Each of server devices 161 and 162 and data storage devices 171, 172, and 173 is part of one or more distributed systems.

[0020] Data storage devices 171, 172, and 173 are part of one or more services provided on behalf of users. Users can access the services by communicating with the services via one or more devices (such as client device 151 and client device 152). Among them, the services may include cloud services, access to various applications, communication services, security services, device management services, file services including storage, access, and sharing of files by users, etc. The data associated with the services is stored in various data stores including data storage devices (including data storage devices 171, 172, and 173). In some examples, the data stores include a large number of heterogeneous data stores, each of which is built according to the specific requirements of the data hosted therein.

[0021] A graph server can use a distributed knowledge graph to connect knowledge, resources, people, and the like associated with a data store. The graph server includes devices such as graph server device 161 and graph server device 162. The graph server includes a query planner and creates and updates a metagraph. The metagraph enables the query planner to uniquely identify data in the graph structure while supporting the data store's use of multiple different identifiers.

[0022] The network 130 may include one or more computer networks, including wired and / or wireless networks, wherein each network may be, for example, a wireless network, a local area network (LAN), a wide area network (WAN) and / or a global network such as the Internet. On a group of LANs including those interconnected based on different architectures and protocols, a router acts as a link between the LANs so that messages can be sent from one to another. Similarly, the communication link within the LAN typically includes a twisted pair or coaxial cable, while the communication link between the networks may utilize an analog telephone line, a complete or partial dedicated digital line including T1, T2, T3 and T4, an integrated services digital network (ISDN), a digital subscriber line (DSL), a wireless link including a satellite link and / or other communication links known to those skilled in the art. In addition, remote computers and other related electronic devices may be remotely connected to the LAN or WAN via a modem and a temporary telephone link. The network 130 may include various other networks, such as one or more networks using local network protocols such as 6LoWPAN, ZigBee, etc. In essence, network 130 can include any suitable network-based communication method by which information can travel between client devices 151 and 152, image server devices 161 and 162, and data storage devices 171, 172, and 173. Although each device is shown as being connected to network 130, this does not necessarily mean that each device communicates with every other device shown. In some examples, some of the devices shown only communicate with some other devices / services shown via one or more intermediary devices. Furthermore, although network 130 is illustrated as one network, in some examples, network 130 may alternatively include multiple networks that may or may not be connected to each other, wherein some of the devices shown communicate with each other via one of the multiple networks, and other of the devices shown communicate with each other using different ones of the multiple networks instead.

[0023] System 100 may include Figure 1 More or fewer devices may be shown in the figure, which are shown only by way of example.

[0024] Figure 2 is a block diagram illustrating an example of a system (200). The system 200 may be Figure 1 The system 200 is described below according to some examples. The system 200 includes client devices 251 and 252, a graph server system 260, and data stores 271, 272, and 273. The graph server system 260 and the data stores 271, 272, and 273 can be or be included in one or more distributed systems.

[0025] Data stores 271, 272, and 273 are part of one or more services provided on behalf of users. Users can access the services by communicating with the services via one or more devices (such as client device 251 and client device 252). Among them, the services may include cloud services, access to various applications, communication services, security services, device management services, file services including storage, access, and sharing of files by users, etc. The data associated with the services is stored in various data stores including data stores (including data stores 271, 272, and 273). The data stores include a large number of heterogeneous data stores, each of which is built according to the specific requirements of the data hosted therein. In some examples, the graph server system 260 operates as follows.

[0026] The graph server system 260 uses a distributed knowledge graph to link together knowledge, resources, people, etc. associated with a system including data stores (e.g., data stores 271, 272, and 273). The distributed knowledge graph includes a graph structure description on a graph database residing on the graph server system 260. In various aspects, the graph database may include: a relational database, a non-structured query language (NoSQL) database, or another suitable database. In the structure of the distributed knowledge graph, entities are modeled as nodes. Entities modeled as nodes include users, documents, and other files, etc. Each of the nodes describes a corresponding entity and includes a set of accompanying attributes of the corresponding entity, such as name, title, age, address, etc. Each attribute can be considered as a key / value pair including the attribute name and its corresponding value.

[0027] In the structure of the distributed knowledge graph, relationships between entities and actions between entities are modeled as edges between those entities. For example, if a user modifies a document, this is represented in the graph structure using an edge between the user and the document, where the edge indicates that the user has modified the document. Similarly, a user's authorship of a document is represented in the graph structure as an edge between the user and the document, where the edge indicates authorship, and a user's viewing of a document can be represented in the graph structure as an edge indicating a document view.

[0028] The distributed graph stored in graph server system 260 is a logical schema that models entities as nodes, and the relationships and actions between nodes as edges. Graph system 260 includes a storage adapter that loads information about new data stores into the distributed graph. The storage adapter also updates the distributed graph for changes to nodes and edges and handles communication with the underlying data store.

[0029] The distributed graph can be periodically queried by users via graph queries to understand the relationships between entities. Graph queries enable users to query data associated with the distributed knowledge graph. For example, a user can issue a graph query to find friends or contacts within a social network, documents with which a given user has interacted, users who have accessed a given document, users who have accessed a given document within a specified timeframe, entities that meet various search criteria, and the like. Graph server 260 executes such graph queries submitted by users.

[0030] The distributed graph stored in the graph server system 260 is a logical schema that models entities as nodes and relationships and actions between nodes as edges, but the distributed graph itself does not store the data held in the data store 260. Therefore, execution of the graph query requires the graph server 260 to locate and communicate with the data store that holds the data. Using the graph to locate entities modeled on the graph utilizes identifiers that act as keys. The identifiers used to locate specific logical entities or edges to / from these nodes vary across the data store. In various examples, the data store may include a variety of different data stores, such as email storage systems, directory systems, document management systems, and various other types of data stores. In some examples, the email storage system is optimized to have data retrieved by email address, the directory system uses a globally unique ObjectId, and several other systems each use completely different IDs.

[0031] The graph server system 260 creates a metagraph that contains identifier information about how the data stores interact with identifiers. More specifically, for each data store modeled in the graph, the identifier information in the metagraph includes identifier acceptance information that indicates which identifiers, if any, the data store accepts. Additionally, for each data store modeled in the graph, the identifier information in the metagraph includes identifier export information that indicates which identifiers, if any, the data store exports—that is, which identifiers of entities the data store exports. In some examples, the metagraph is a graph that stores information about the data stores and corresponding identifier information as edges and nodes. In other examples, the metagraph provides identifier information in other ways. The metagraph may be interchangeably referred to as an ID resolution graph.

[0032] In some examples in which the metagraph is a graph that models information about the data store and corresponding identifier information as edges and nodes, the metagraph models the information as follows. The metagraph is a bipartite graph in which data stores are represented / modeled as nodes with the label system, and identifiers are modeled as nodes with the label identifier. Information about which identifiers are accepted by the data store is modeled as edges of type ACCEPTS in the metagraph, where the edges go from the identifier node of an identifier to the system node of the data store that accepted the identifier. Similarly, information about which identifiers are exported by the data store is modeled as edges of type EXPORTS in the metagraph, where the edges go from the identifier node of an identifier to the system node of the data store that exported the identifier.

[0033] A client device, such as client device 251, can send a graph query to graph server system 260. Upon receiving / accessing a graph query, the query planner running in graph server system 260 determines which data stores must be accessed to retrieve the data requested in the graph query. The query planner then accesses and uses the metagraph and cost information to determine possible query paths that satisfy the graph query.

[0034] An example of a graph query involving people data and spanning more than one data store is as follows:

[0035] MATCH(me)-[:Has_Contact]->(c:Contact)-[:Modified]->(doc:Document)

[0036] WHERE c.Name='Alice'

[0037] RETURN doc.Title

[0038] The example graph query is written in the language Cypher. In various other examples, any suitable language may be used, such as any suitable pattern matching language. The example graph query requests retrieval of documents where any contact of a user named "Alice" has modified the document. In the example graph query, "me" refers to the user making the graph query. "Has_Contact" refers to a relationship where one user has a contact with another user, and "Modified" refers to a relationship where a user has modified a document. For the example graph query, the contacts and the HasContact relationship are stored in the ContactStore data store. The ContactStore data store refers to the user's SMTP user. The Modified relationship and the document are stored in another data store: the DocumentGraph data store.

[0039] The DocumentGraph data store has user interactions with documents that are keyed by the user's object ID. However, using only the ContactStore data store and the DocumentGraph data store, there is no way to perform a distributed graph query because there is no translation from a contact's SMTP to its object ID, which is required for the second branch of the query. In order to complete the query, execution must utilize an alternative storage system that can parse or otherwise translate the user's SMTP into the user's object ID. For example, in some examples, the metagraph may instruct the directory data store to export both SMTP and ObjectId, and also accept both identifiers when queried. In these examples, the directory data store can be used to resolve SMTP to object ID.

[0040] The query planner determines which data stores must be accessed in order to fulfill the graph query and retrieve the data. For the example graph query given above, the query planner determines that ContactStore and DocumentGraph are the data stores that must be accessed to fulfill the graph query. The query planner uses the metagraph to determine the query path that will allow the graph query to be fulfilled. As discussed above, the execution must utilize an alternative storage system that can parse or otherwise convert SMTP to object IDs, and therefore the query path must include such parsing / conversion.

[0041] For example, in some examples, one of the possible query paths for the example graph query includes the following three steps. First, find each contact of the user with the name "Alice" in the data store ContactStore. The ContactStore data store will return the SMTP for each such contact. Next, use the SMTP retrieved from the ContactStore data store to resolve the object ID for each of those contacts. For example, in some examples, a directory data store can be used to resolve the SMTP retrieved from the ContactStore data store into an object ID for each of those contacts. Third, using these object IDs, look up the Modified relationship in the DocumentGraph data store, and then the documents that have been modified by those contacts. The graph server system 260 then returns the title of each of these documents to the client device 251 to fulfill the graph query.

[0042] The query planner uses the metagraph and cost information to determine the optimal query path based on a specific cost metric. For example, the specific cost metric can be latency, freshness, carbon emissions, monetary cost, minimum data storage accessed, or another suitable cost metric. "Freshness" refers to how recent the data is. The cost information includes information that can be used to determine the cost of each query path, allowing the costs of potential query paths to be compared. In some examples, the cost information is separate from the metagraph.

[0043] In other examples, the cost information is included in the nodes and edges of the metagraph. In these examples, having the cost information included in the nodes and edges of the metagraph allows the query planner to rely on conventional graph traversal algorithms for determining the set of ID resolutions that must occur - for example, a breadth-first search (BFS) algorithm, a depth-first search (DFS) algorithm, or a weighted traversal algorithm such as Dijkstra's algorithm. In some examples, even when cost metrics are included in the nodes and edges of the metagraph, some cost metrics are determined at runtime. For example, in some examples, latency is tracked at runtime.

[0044] The resulting path through the graph is then used as input by the query planner, which attempts to inject ID resolution steps at appropriate locations in the query path and optimize the complete set of steps that now include ID resolution / conversion. For example, specific ID resolution operations are performed in parallel with the execution of other parts of the query. The query planner uses a cache so that each time the query planner selects a query path, the query path is cached. In this way, if the same graph query is subsequently performed, the same query path is used. In addition, a relatively large number of nodes can be used to determine the query path in parallel.

[0045] In the event of a service outage or other failure in a query path determined to be optimal, the query planner determines a different query path instead. In this way, query planning does not use centralized points of failure. In the event of a service outage, the query planner uses an alternative, but suboptimal, path through the graph as a fallback to provide graceful degradation in the face of errors. After the query planner has determined the query path to use, the graph server system 260 executes the query using the determined query path and then retrieves the data that has been queried in the graph query.

[0046] The graph server system 260 executes the graph query by following the selected query path. For example, in some examples, an example graph query may be executed as follows. First, each contact of the user with the name "Alice" is found in the data store ContactStore. The ContactStore data store will return the SMTP for each such context. Next, using the SMTP retrieved from the ContactStore data store, the object ID for each of those contacts is resolved. For example, in some examples, a directory data store may be used to resolve the SMTP retrieved from the ContactStore data store into an object ID for each of those contacts. Third, using these object IDs, the Modified relationship is looked up in the DocumentGraph data store, and then the documents that have been modified by those contacts. The graph server system 260 then returns the title of each of these documents to the client device 251 to implement the graph query.

[0047] Although a small amount of data storage and a small number of identifiers are discussed above by way of example, many examples of system 200 include significantly more data storage and significantly more identifiers than in the examples illustrated above.

[0048] Whenever a new data store is added to the system 200, the storage adapter in the graph server system 260 updates the distributed graph and meta-graph. The storage adapter in the graph server system 260 also updates the distributed graph and meta-graph based on changes to the data store. The updates can be performed periodically based on receiving notification of changes, or based on a combination of the above.

[0049] Illustrative Process

[0050] Figure 3 is a diagram illustrating an example data flow for a process (390) for identity resolution in a distributed knowledge graph. In some examples, process 390 may be performed by Figure 1 An example of a graph server device in the graph server device 161 or 162, by Figure 2 An example of a graph server system 260, comprising Figure 5 In some examples, process 390 proceeds as follows.

[0051] Step 391 occurs first. At step 391, a graph query is received. The graph query is associated with a distributed graph of a system. The system includes a plurality of data stores. The graph query includes a request for data. As shown, step 392 then occurs. At step 392, a meta-graph is provided such that the meta-graph includes identifier information associated with identifiers. The identifier information includes identifier acceptance information associated with which of the identifiers are accepted by a data store in the plurality of data stores, and the identifier information also includes identifier derivation information associated with which of the identifiers are derived by a data store in the plurality of data stores.

[0052] As shown, step 393 occurs next. At step 393, cost information associated with the cost of the query path between the data stores is obtained based on at least a first cost metric. As shown, step 394 occurs next. At step 394, the metagraph and the cost information are used to select a query path from the query paths that can implement the graph query based on minimizing the cost based on the first cost metric. As shown, step 395 occurs next. At step 395, upon determining that a failure has occurred in the selected query path, the metagraph and the cost information are used to change the selected query path. As shown, step 396 occurs next. At step 396, a response to the graph query is provided based on the selected query path. The response to the graph query includes the data. The process can then proceed to a return block where other processing is resumed.

[0053] Exemplary Equipment / Operating Environment

[0054] Figure 4 4 is a diagram of an environment 400 in which aspects of the present technology may be practiced. As shown, the environment 400 includes a computing device 410 and a network node 420 connected via a network 430. Figure 4 Specific components of environment 400 are shown in FIG, but in other examples, environment 400 can also include additional and / or different components. For example, in certain examples, environment 400 can also include a network storage device, a maintenance manager, and / or other suitable components (not shown). Figure 4 The computing device 410 shown in can be in various locations, including a local computer, on-premises, in the cloud, etc. For example, the computer device 410 can be on the client side, on the server side, etc.

[0055] As in Figure 4, the network 430 can include one or more network nodes 420 that interconnect multiple computing devices 410 and connect the computing devices 410 to an external network 440 (e.g., the Internet or an intranet). For example, the network node 420 may include a switch, a router, a hub, a network controller, or other network elements. In a specific example, the computing devices 410 can be organized into racks, action zones, groups, sets, or other suitable divisions. For example, in the illustrated example, the computing devices 410 are grouped into three host sets that are individually identified as first, second, and third host sets 412a-112c. In the illustrated example, each host combination in the host combination 412a-112c is operably coupled to a corresponding network node 420a-120c, which is commonly referred to as a "top of rack" or "TOR" network node. TOR network nodes 420a-120c can then be operably coupled to additional network nodes 420 to form a computer network with a hierarchical, flat, mesh, or other suitable type of topology that allows communication between computing devices 410 and external networks 440. In other examples, multiple host sets 412a-112c can share a single network node 420. Computing devices 410 can be virtually any type of general-purpose or special-purpose computing device. For example, these computing devices can be user devices, such as desktop computers, laptop computers, tablet computers, display devices, cameras, printers, or smart phones. However, in a data center environment, these computing devices can be server devices, such as application server computers, virtual computing host computers, or file server computers. In addition, computing devices 410 can be individually configured to provide computing, storage, and / or other suitable computing services.

[0056] In some examples, one or more of computing devices 410 are devices configured as at least part of a system for identity resolution in a distributed knowledge graph.

[0057] Exemplary Computing Device

[0058] Figure 5 is a diagram illustrating one example of a computing device 500 in which aspects of the present technology may be practiced. Computing device 500 may be virtually any type of general-purpose or special-purpose computing device. For example, computing device 500 may be a user device, such as a desktop computer, a laptop computer, a tablet computer, a display device, a camera, a printer, or a smartphone. Similarly, computing device 500 may also be a server device, such as an application server computer, a virtual computing host computer, or a file server computer. For example, computing device 500 may be Figure 4Similarly, the computer device 500 may be any of the devices discussed above and in more detail below, a device within any of the distributed systems described, or a device illustrated or referenced in any of the figures above. Figure 5 As illustrated in FIG, the computing device 500 may include a processing circuit 510, an operating memory 520, a memory controller 530, a bus 540, a data storage memory 550, an input interface 560, an output interface 570, and a network adapter 580. Each of these aforementioned components of the computing device 500 includes at least one hardware element.

[0059] The computing device 500 includes at least one processing circuit 510 configured to execute instructions (such as instructions for implementing the workloads, processes, and / or techniques described herein). The processing circuit 510 may include a microprocessor, a microcontroller, a graphics processor, a coprocessor, a field programmable gate array, a programmable logic device, a signal processor, and / or any other circuit suitable for processing data. The aforementioned instructions and other data (e.g., data sets, metadata, operating system instructions, etc.) may be stored in operating memory during the runtime of the computing device 500. The operating memory 520 may also include any of a variety of data storage devices / components, such as volatile memory, semi-volatile memory, random access memory, static memory, cache, buffer, and / or other media for storing runtime information. In one example, when the computing device 500 is powered off, the operating memory 520 does not retain information. Instead, the computing device 500 may be configured to transfer instructions from non-volatile data storage components (e.g., data storage component 550) to the operating memory 520 as part of a boot or other loading process. In some examples, other forms of execution may be employed, such as executing directly from the data storage component 550 , eg, execute-in-place (XIP).

[0060] The operating memory 520 may include 4th generation double data rate (DDR4) memory, 3rd generation double data rate (DDR3) memory, other dynamic random access memory (DRAM), high bandwidth memory (HBM), hybrid memory cube memory, 3D stacked memory, static random access memory (SRAM), magnetoresistive random access memory (MRAM), pseudo random access memory (PSRAM), and / or other memory, and such memory may include one or more memory circuits integrated into a DIMM, SIMM, SODIMM, known good die (KGD), or other package. Such operating memory modules or devices may be organized according to channels, ranks, and banks. For example, the operating memory devices may be coupled to the processing circuitry 510 via a memory controller 530 in a channel. One example of the computing device 500 may include one or two DIMMs per channel and one or two ranks per channel. The operating memory within a rank may operate with a shared clock and a shared address and command bus. Similarly, the operating memory devices may be organized into several banks, where a bank can be considered an array addressed by rows and columns. Based on such an organization of the operating memory, a physical address within the operating memory can be referenced by a tuple of channel, stage, bank, row, and column.

[0061] Notwithstanding the above discussion, operational memory 520 specifically does not include or encompass communications media, any communications media, or any signals per se.

[0062] The memory controller 530 is configured to interface the processing circuit 510 to the operating memory 520. For example, the memory controller 530 can be configured to interface commands, addresses, and data between the operating memory 520 and the processing circuit 510. The memory controller 530 can also be configured to abstract or otherwise manage certain aspects of memory management from the processing circuit 510. Although the memory controller 530 is illustrated as a single memory controller separate from the processing circuit 510, in other examples, multiple memory controllers can be employed, one or more memory controllers can be integrated with the operating memory 520, etc. In addition, one or more memory controllers can be integrated into the processing circuit 510. These and other variations are possible.

[0063] In computing device 500, data storage memory 550, input interface 560, output interface 570, and network adapter 580 are interfaced to processing circuitry 510 via bus 540. Figure 5Bus 540 is illustrated as a single passive bus, but other configurations such as a collection of buses, a collection of point-to-point links, input / output controllers, bridges, other interface circuits, and / or any collection thereof may also be used, as appropriate, to interface data storage memory 550, input interface 560, output interface 570, and / or network adapter 580 to processing circuitry 510.

[0064] In computing device 500, data storage memory 550 is used for long-term, non-volatile data storage. Data storage memory 550 may include any of a variety of non-volatile data storage devices / components, such as non-volatile memory, a disk, a disk drive, a hard drive, a solid-state drive, and / or any other medium capable of non-volatile storage of information. However, data storage memory 550 specifically does not include or encompass communication media, any communication media, or any signals themselves. In contrast to operating memory 520, data storage memory 550 is used by computing device 500 for non-volatile, long-term data storage, rather than for runtime data storage.

[0065] Likewise, the computing device 500 may include or be coupled to any type of processor-readable media, such as processor-readable storage media (e.g., operating memory 520 and data storage memory 550) and communication media (e.g., communication signals and radio waves). Although the term processor-readable storage media includes operating memory 520 and data storage memory 550, the term "processor-readable storage media" (whether used in the singular or plural) throughout the specification and claims is defined herein such that the term "processor-readable storage media" specifically excludes and does not encompass communication media, any communication media, or any signal itself. However, the term "processor-readable storage media" includes processor cache, random access memory (RAM), register memory, and the like.

[0066] The computing device 500 also includes an input interface 560, which can be configured to enable the computing device 500 to receive input from a user or from other devices. In addition, the computing device 500 includes an output interface 570, which can be configured to provide output from the computing device 500. In one example, the output interface 570 includes a frame buffer, a graphics processor, a graphics processor or an accelerator, and is configured to render a display for presentation on a separate visual display device (such as a monitor, a projector, a virtual computing client computer, etc.). In another example, the output interface 570 includes a visual display device and is configured to render and present a display for viewing. In yet another example, the input interface 560 and / or the output interface 570 may include a universal asynchronous receiver / transmitter (UART), a serial peripheral interface (SPI), an internal integrated circuit (I2C), a general purpose input / output (GPIO), etc. In addition, the input interface 560 and / or the output interface 570 may include or be interfaced to any number or type of peripheral devices.

[0067] In the illustrated example, computing device 500 is configured to communicate with other computing devices or entities via network adapter 580. Network adapter 580 may include a wired network adapter, such as an Ethernet adapter, a token ring adapter, or a digital subscriber line (DSL) adapter. Network adapter 580 may also include a wireless network adapter, such as a Wi-Fi adapter, a Bluetooth adapter, a ZigBee adapter, a Long Term Evolution (LTE) adapter, SigFox, LoRa, Powerline, or a 5G adapter.

[0068] Although computing device 500 is illustrated as having specific components configured in a specific arrangement, these components and arrangements are merely one example of a computing device in which the described technology may be employed. In other examples, data storage memory 550, input interface 560, output interface 570, or network adapter 580 may be coupled directly to processing circuitry 510 or via an input / output controller, a bridge, or other interface circuitry. Other variations of the technology are possible.

[0069] Some examples of computing device 500 include: at least one memory (e.g., operating memory 520) having processor-executable code stored therein; and at least one processor (e.g., processing unit 510) adapted to execute the processor-executable code, wherein the processor-executable code includes processor-executable instructions that, in response to execution, enable computing device 500 to perform actions, wherein, in some examples, the actions may include actions for one or more processes described herein, such as in Figure 3The process shown in , as discussed in more detail above.

[0070] The above description provides specific details to provide a thorough understanding and enable description of various examples of the technology. Those skilled in the art will appreciate that the technology can be practiced without many of these details. In some cases, well-known structures and functions are not shown or described in detail to avoid unnecessarily obscuring the description of the examples of the technology. The terms used in this disclosure are intended to be interpreted in their broadest reasonable manner, even when used in conjunction with the detailed description of specific examples of the technology. Although specific terms may be emphasized below, any terms intended to be interpreted in any limited manner will be clearly and specifically defined in this detailed description. Throughout the specification and claims, unless the context indicates otherwise, the following terms will at least have the meanings expressly associated herein. The meanings identified below do not necessarily limit the terms but rather provide illustrative examples of the terms. For example, each of the terms "based on" and "based upon" is non-exclusive and equivalent to the term "based at least in part on," and includes options based on additional factors, some of which may not be described herein. As another example, the term "via" is non-exclusive and equivalent to the term "based at least in part on," and includes options based on additional factors, some of which may not be described herein. The meaning of "in" includes "in" and "on". As used herein, the phrases "in one embodiment" or "in an example" do not necessarily refer to the same embodiment or example, although they may refer to the same embodiment or example. The use of specific textual numerical indicators does not imply the presence of numerical indicators of smaller values. For example, the reference "a widget selected from the group consisting of a third foo and a fourth bar" does not itself mean that there are at least three foo elements, nor does it mean that there are at least four bar elements. . Unless multiple references are explicitly excluded, singular references are made for clarity of reading and include multiple references. Unless otherwise expressly stated, the term "or" is an inclusive "or" operator. For example, the phrase "A or B" means "A, B, or A and B". As used herein, the terms "component" and "system" are intended to cover various combinations of hardware, software, or hardware and software. Thus, for example, a system or component can be a process, a process executed on a computing device, a computing device, or a portion thereof. The term "cloud" or "cloud computing" refers to a shared pool of configurable computer system resources and higher-level services over a wide area network (usually the Internet). “Edge” devices refer to devices that are not themselves part of the cloud but serve as entry points into an enterprise or service provider’s core network.

[0071] in conclusion

[0072] Although the above detailed description describes specific examples of the technology and describes the expected optimal mode, no matter how the above detailed description appears in the text, the technology can be practiced in many ways. The details can vary in the implementation while still being covered by the technology described in this article. As mentioned above, the specific terms used when describing specific features or aspects of the technology should not be taken as implying that the terms are redefined in this article to be limited to any specific characteristics, features or aspects associated with the terms. In general, the terms used in the following claims should not be interpreted as limiting the technology to the specific examples disclosed in this article unless the specific embodiments expressly define such terms. Therefore, the actual scope of the technology covers not only the disclosed examples, but also all equivalent ways of practicing or implementing the technology.

Claims

1. A device comprising: A device comprising: at least one memory having processor-executable code stored therein, and at least one processor adapted to execute the processor-executable code, wherein the processor comprises a trusted execution environment, and wherein the processor-executable code comprises processor-executable instructions that, in response to execution, enable the device to perform actions comprising: receiving a graph query, wherein the graph query is associated with a distributed graph of a system, wherein the system includes a plurality of data stores, and wherein the graph query comprises a request for data; providing a metagraph such that the metagraph includes identifier information associated with identifiers, wherein the identifier information includes identifier acceptance information associated with which of the identifiers the data store in the plurality of data stores accepts, and the identifier information further includes identifier derivation information associated with which of the identifiers the data store in the plurality of data stores derives; obtaining cost information associated with a cost of a query path in the data store based on at least a first cost metric; selecting, from the query paths, a query path capable of fulfilling the graph query based on minimizing cost according to the first cost metric using the meta graph and the cost information; upon determining that a failure has occurred in the selected query path, changing the selected query path using the metagraph and the cost information; and A response to the graph query is provided based on the selected query path, wherein the response to the graph query includes the data.

2. The device according to claim 1, wherein Providing the response to the graph query includes executing the graph query based on the selected query path, and after executing the graph query, retrieving the data.

3. The device according to claim 1, wherein The metagraph is a bipartite graph that models the data stores of the plurality of data stores as nodes, the identifiers as nodes, the identifier acceptance information as edges, and the identifier derivation information as edges.

4. The apparatus according to claim 1, wherein the actions further comprise: The metagraph is updated based on changes in the plurality of data stores.

5. The apparatus according to claim 1, wherein the actions further comprise: A plurality of additional query paths for a plurality of additional graph queries are selected in parallel with selecting the query path.

6. The device according to claim 1, wherein The first cost metric includes at least one of: latency, carbon emissions, or freshness.

7. A method comprising: accessing a graph query, wherein the graph query is associated with a distributed knowledge graph of a system, wherein the system includes a plurality of data stores, and wherein the graph query comprises a request for data; obtaining an identification (ID) resolution graph, such that the ID resolution graph includes identifier information associated with identifiers, wherein the identifier information includes identifier acceptance information associated with which of the identifiers the data store accepts, and further includes identifier derivation information associated with which of the identifiers the data store derives; accessing cost information associated with a cost of a query path in the data store based on at least a first cost metric; selecting, based on the ID resolution graph and the cost information, a query path from the query paths that can satisfy the graph query based on optimization according to the first cost metric; When it is determined that a failure has occurred in the selected query path, changing the selected query path using the ID resolution graph and the cost information; and The graph query is responded to based on the selected query path.

8. A processor-readable storage medium having processor-executable code stored thereon, wherein the processor-executable code, when executed by at least one processor, performs actions, the actions comprising: selecting, from query paths, a query path capable of implementing a graph query based on minimizing a cost according to a first cost metric using a metagraph and cost information, wherein the graph query is associated with a distributed graph of a system, the system comprising a plurality of data stores, the graph query comprising a request for data, the metagraph comprising identifier information associated with identifiers, the identifier information comprising identifier acceptance information associated with which of the identifiers are accepted by the data stores of the plurality of data stores, and further comprising identifier export information associated with which of the identifiers are exported by the data stores of the plurality of data stores, and wherein the cost information is associated with a cost of the query path in the data stores according to at least the first cost metric; upon determining that a failure has occurred in the selected query path, changing the selected query path using the metagraph and the cost information; and A response to the graph query is provided based on the selected query path, wherein the response to the graph query includes the data.

9. The method according to claim 7, wherein: Responding to the graph query includes executing the graph query based on the selected query path, and retrieving the data after executing the graph query.

10. The method according to claim 7, wherein: The ID resolution graph is a bipartite graph that models the data stores of the plurality of data stores as nodes, the identifiers as nodes, the identifier acceptance information as edges, and the identifier derivation information as edges.

11. The method of claim 7, further comprising updating the ID resolution graph based on changes in the plurality of data stores.

12. The method of claim 7, further comprising selecting a plurality of additional query paths for a plurality of additional graph queries in parallel with selecting the query path.

13. The processor-readable storage medium of claim 8, wherein: Providing the response to the graph query includes executing the graph query based on the selected query path, and after executing the graph query, retrieving the data.

14. The processor-readable storage medium of claim 8, wherein: The metagraph is a bipartite graph that models the data stores of the plurality of data stores as nodes, the identifiers as nodes, the identifier acceptance information as edges, and the identifier derivation information as edges.

15. The processor-readable storage medium of claim 8, the actions further comprising: The metagraph is updated based on changes in the plurality of data stores.

16. The processor-readable storage medium of claim 8, the actions further comprising: A plurality of additional query paths for a plurality of additional graph queries are selected in parallel with selecting the query path.

17. The apparatus of claim 1, wherein the actions further comprise: The data store that must be accessed in order to retrieve the data is determined from the plurality of data stores.

18. The device according to claim 1, wherein Selecting the query path from the query paths using the metagraph and the cost information that can implement the graph query based on minimizing the cost according to the first cost metric is implemented using at least one of the following: a breadth-first search algorithm, a depth-first search algorithm, or a weighted traversal algorithm.

19. The apparatus of claim 1, the actions further comprising caching the selected query path.

20. The device according to claim 1, wherein The plurality of data stores store a plurality of documents; the distributed graph comprises at least one of a relational database or a non-Structured Query Language-only database, the distributed graph comprises nodes and edges, the edges of the distributed graph comprise information about relationships between the nodes, and wherein the nodes comprise: for each user in a first plurality of users, a node that models the user; and for each document in a plurality of documents stored in the plurality of data stores, a node that models the document.

Images