Double-read double-write access to graph database

Abstract

A method for operating a graph database includes receiving, by a computer system, a query for a particular graph database, the query identifying a plurality of vertices in the particular graph database. The method further includes performing, by the computer system, a hash operation on two or more vertices of the plurality of vertices to generate respective hash values, and partitioning the query into a plurality of sub-queries using the respective hash values, each sub-query corresponding to a subset of the plurality of vertices. The method also includes sending, by the computer system, a sub-query of the plurality of sub-queries to a plurality of database repositories of the particular graph database.

Description

Technical Field

[0001] The embodiments described herein relate to the field of graph database management, and more particularly, to techniques for storing and retrieving data in and from a graph database. Background Art

[0002] A graph database is a database that uses a graph structure (e.g., vertices and edges) to store database items to track relationships with other database items. A vertex may represent a given item, and one or more edges may then be determined to indicate links to other vertices with a given similarity. For example, a particular graph database may store user information for multiple users in corresponding vertices. One or more types of edges may be used to track corresponding similarities between vertices. One type of edge may be the type of web browser used. A corresponding edge may be identified between two vertices that have used the same web browser. Other edge types may include an Internet Service Provider (ISP), the type of computer hardware used, or essentially any piece of information available within a given vertex.

[0003] Graph databases can be used to collect data associated with relationships between vertices. For example, a graph database that includes ISPs as edges between vertices representing users can easily process queries that identify all users who use the same ISP. Graph databases may also be useful for processing more complex queries. For example, a query can be generated to identify users who use the same ISP and similar computer hardware.

[0004] A graph database may be managed by an entity that allows online subscribers to access some or all of the information stored in the graph database. As a result, such a graph database may have periods of high demand when many subscribers generate queries simultaneously. Furthermore, the information stored in the graph database may be collected from online usage by subscribers and / or other users of the entity's services, which results in a large amount of data being captured every day. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The following detailed description refers to the accompanying drawings, which are now briefly described:

[0006] Figure 1 A block diagram of an embodiment of a graph data server that processes queries is shown.

[0007] Figure 2 Two block diagrams of embodiments of a graph data server with redundant database repositories are shown.

[0008] Figure 3 A block diagram of an embodiment of a graph data server maintaining two versions of a database repository for respective groups of users is described.

[0009] Figure 4 A flow chart of an embodiment of a method for processing a user's query to a graph data server is shown.

[0010] Figure 5 A flow chart of an embodiment of a method for handling an unavailable database repository is shown.

[0011] Figure 6 A flow chart of an embodiment of a method for processing queries from two different groups of users is described.

[0012] Figure 7 A flow chart of an embodiment of a method for storing and verifying new records to respective copies of a graph database is shown.

[0013] Figure 8 A block diagram of an embodiment of a computer system is depicted that may be used to implement one or more embodiments of the disclosed system. DETAILED DESCRIPTION

[0014] A graph database can be used to collect and track various information as individual vertices linked by various related edges. For example, an online service may have multiple clients that perform electronic exchanges between each other and / or other entities. The online service can track individual clients as vertices in a graph database, with various electronic exchanges generating edges between pairs of vertices. Such exchanges can take place at any time on any day. Thus, the process for capturing and storing new records corresponding to the exchanges performed can be continuously efficient.

[0015] In some cases, an online service may provide access to a graph database to multiple users. The multiple users may include users internal to the online service, clients of the service, subscribers to the database, and the like. The online service may divide the users into two or more groups, each of which is assigned a specific set of restrictions and / or permissions. To protect certain database information, one or more groups may be restricted from accessing specific types of information, such as specific types of vertices or edges, or specific pieces of information contained within a given vertex or edge. One technique for protecting such data may include maintaining separate copies of the graph database, allowing a set of user groups to access corresponding copies of the database. In this case, the copy for the user group with restrictions may exclude the restricted information. In other cases, the concern of the online service may be that users of the restricted group may attempt to destroy information in the graph database, for example, as part of a fraudulent campaign. In these cases, the various copies of the graph database may be identical, but separate to avoid destruction of information for all groups.

[0016] Maintaining multiple copies of a graph database while keeping vertices and edges in the multiple copies synchronized with recent client activity can be challenging. Furthermore, when a large number of queries are generated, meeting a certain level of guaranteed quality of service can be challenging. Therefore, the inventors propose techniques for operating a graph database that can reduce the amount of time used to execute queries and can reduce the amount of time used to update records across multiple copies of a graph database repository.

[0017] A proposed technique includes a computer system receiving a query for a particular graph database stored in a plurality of database repositories. The query identifies a plurality of vertices in the particular graph database. The computer system may perform a hash operation on two or more of the plurality of vertices to generate corresponding hash values. The computer system may then use the corresponding hash values ​​to divide the query into a plurality of sub-queries, each of the sub-queries corresponding to a subset of the plurality of vertices. The sub-queries of the plurality of sub-queries may then be sent by the computer system to a plurality of database repositories storing one or more copies of the particular graph database.

[0018] Another proposed technique includes a computer system storing copies of a disclosed specific graph database in different multiple database repositories. For example, one graph database repository may be accessible by a first group of users classified as risk, while a copy of the graph database may be accessible by a second group of users classified as non-risk. The copy graph database repository may not be accessible to the first group. In order to store new records in both the specific graph database repository and the copy graph database repository at the same time, the computer system may use corresponding data storage engines for the specific graph database and the copy graph database. The computer system may then verify the storage of new records to the specific graph database and the copy graph database by reading corresponding copies of the new records from the specific graph database and the copy graph database, and comparing the corresponding copies with the copies of the new records stored in the computer system.

[0019] Such graph database operation techniques can reduce the latency between receiving a query and sending a response, thereby improving the quality of service (QoS) associated with processing queries. In addition, these techniques can improve the accuracy of information stored within multiple copies of a graph database repository by updating multiple copies simultaneously.

[0020] Figure 1A block diagram of an embodiment of a graph data server is shown in . As shown, the graph data server 100 includes a computer system 101, which also includes database repositories 150a and 150b (collectively referred to as 150). In various embodiments, the computer system 101 can be implemented as, for example, a single computer system, multiple computer systems in a data center, multiple computer systems in multiple data centers, and other such embodiments. In some embodiments, the server computer system 101 can be implemented as one or more virtual computer systems hosted by one or more server computer systems. The computer system 101 receives a query 110, for example, via a connected computer network (such as the Internet), which is then divided into sub-queries 115a and 115b (collectively referred to as 115).

[0021] As shown, computer system 101 is configured to maintain graph database 155 in database repository 150. In various embodiments, graph database 155a and graph database 155b may be identical copies of graph database 155, or may be corresponding portions of graph database 155. Graph database 155 may capture any suitable information that may be stored as a plurality of vertices, each vertex having one or more connections (e.g., edges) to other vertices. For example, graph database 155 may track users of an online service, with each vertex 112 representing a corresponding user. Edges between vertices in vertices 112 are determined based on information associated with corresponding vertices in vertices 112. A given edge may correspond to multiple pieces of data associated with a user, such as an address, interests, hobbies, etc. Other edges may be associated with specific actions taken by a user. For example, if an online service facilitates electronic exchanges between users, information about the exchanges may be used to determine edges between vertices 112. For example, if a user represented by vertex 112a performs an electronic exchange with a user represented by vertex 112c, the exchange may result in an edge between vertex 112a and vertex 112c. The details of the exchange, such as whether the exchange was successful or resulted in a complaint, may form an additional edge between vertex 112a and vertex 112c.

[0022] Computer system 101 is also configured to receive a query 110 for graph database 155, query 110 identifying a plurality of vertices 112 (shown as vertices 112a through 112d) of graph database 155. For example, processor circuitry of computer system 101 may execute instructions included in memory circuitry that, when executed by the processor circuitry, cause computer system 101 to perform operations such as receiving and processing the query for graph database 155. To reduce the amount of time to process query 110, computer system 101 is configured to divide query 110 into sub-queries 115a and 115b.

[0023] In order to partition the query 110, the computer system 101 is configured to generate corresponding hash values ​​113a-113d (collectively referred to as 113) for a subset of the vertices 112. It should be noted that in some embodiments, the subset may include all vertices 112. As shown, four hash values ​​113 are generated, one hash value 113 for each of the vertices 112. Generating the hash values ​​113 may include performing a hash operation 120 on one or more values ​​included in each vertex 112. For example, each vertex 112 may include a user identification (ID), a user name, an address, contact information, etc. The hash operation 120 may be used to generate the hash value 113a using the user ID value included in the vertex 112a. Similarly, the hash values ​​113b-113d may respectively represent a hash code generated by the hash operation 120 based on the user ID from each of the vertices 112b-112d. As a different example, the hash value 113 may be generated by performing a hash operation 120 on information related to an electronic exchange associated with a vertex in the vertices 112. Such information may include the type of exchange (e.g., non-fungible token, data file, media file), the time and date of the exchange, the parties involved in the exchange, etc. In other embodiments, hash operation 120 may be performed on any suitable value in the vertex stored in vertices 112.

[0024] As shown, computer system 101 is also configured to use corresponding hash values ​​113 to distribute vertices 112 in subqueries 115a and 115b. Any suitable technique for distributing hash values ​​113 between subqueries 115a and 115b can be used. For example, hash values ​​113 with odd values ​​can be mapped to subquery 115a, while hash values ​​113 with even values ​​are mapped to subquery 115b. In other embodiments, thresholds can be used for distribution. Hash values ​​113 less than the threshold are mapped to subquery 115a, while hash values ​​113 greater than or equal to the threshold are mapped to subquery 115b. In this embodiment, multiple thresholds can be used to map hash values ​​113 to more than two different subqueries. Vertex 112 is placed in the subquery 115 of its corresponding hash value 113. Hash operation 120 can be used to evenly distribute the obtained hash values ​​across the mapped subqueries so that subqueries 115a and 115b will each include a similar number of vertices on average. As shown, vertices 112a and 112d are mapped to sub-query 115a, and vertices 112b and 112c are mapped to sub-query 115b.

[0025] As shown, the subqueries in subquery 115 are sent to the corresponding repositories of database repositories 150a and 150b. As described above, each of the database repositories 150 may include a corresponding copy of the graph database 155, or may include a corresponding portion. As shown, the computer system 101 is configured to send subquery 115a to database repository 150a to execute subquery 115a on graph database 155a. Similarly, subquery 115b is sent to database repository 150b to execute subquery 115b on graph database 155b. The corresponding subquery results can then be returned from each of the database repositories 150 to the computer system 101, where the corresponding results can then be combined into a response to the query 110. By dividing the query 110 into multiple subqueries 115 and sending the subqueries 115 to different database repositories 150, the processing time of the query 110 can be reduced, and the workload introduced by the query 110 can be distributed across multiple database repositories 150. In some cases, the reduction in response time can enable computer system 101 to meet specific quality of service (QoS) goals for executing queries. Such QoS goals can be included in the client contract, and thus meeting these goals can avoid client dissatisfaction.

[0026] It should be noted that Figure 1 As shown, the graph data server 100 is only an example. Figure 1 101. The computer system 101 has been simplified to highlight features relevant to the present disclosure. In other embodiments, additional elements not shown may be included, and / or a different number of the elements shown may be included. For example, while two database repositories are shown for clarity, any suitable number of repositories may be included. While shown as included within the computer system 101, one or both of the database repositories 150 may be implemented external to the computer system 101.

[0027] Figure 1 The illustrated embodiment describes sending a subquery to a corresponding database repository. In some cases, a given repository may be unavailable. Unavailable repositories can be managed using a variety of techniques. Two examples of managing unavailable repositories are as follows: Figure 2 shown.

[0028] Go to Figure 2 , two block diagrams of embodiments of a graph data server including redundant database repositories are shown, each including a respective copy of a graph database. As shown, the graph data server 200 includes a primary database repository 250 and redundant database repositories 251a and 251b. The graph data server receives a query 210 and generates subqueries 215a-215c (collectively 215).

[0029] The graph data server 200 includes multiple repositories in which a graph database 255 is stored. In some embodiments, portions of the graph database 255 may be stored across multiple repositories such that only some individual repositories, or in some cases no individual repositories, store a complete copy of the graph database 255. However, as shown, the primary database repository 250 includes a primary copy of the graph database 255, and each of the redundant database repositories 251a and 251b stores a corresponding redundant copy of the graph database 255. Thus, any of the copies of the graph database 255 may be used to perform a query, such as query 210. It should be noted that as new records are added and / or existing records are modified, the individual copies of the graph database 255 may have temporary differences as record changes propagate to all copies.

[0030] As described above, the computer system (e.g., Figure 1 The computer system 101 receives a query and divides the query into a plurality of sub-queries. Figure 2 , query 210 (including six vertices 212a-212f) is received and divided into sub-queries 215a-215c. Graph data server 200 sends sub-queries in multiple sub-queries 215 to corresponding database repositories in primary database repository 250 and redundant database repository 251. Sub-query 215a includes vertices 212a and 212e and is sent to primary database repository 250. Sub-query 215b includes vertices 212b and 212d and is sent to redundant database repository 251a, while sub-query 215c includes vertices 212c and 212f and is sent to redundant database repository 251b.

[0031] In various situations, one or more of the database repositories may be unable to process a received query. Figure 2 As shown in Examples (EX) 1 and 2, redundant database repository 251a is unavailable. For example, redundant database repository 251a may be offline for maintenance, or may be down due to hardware or software issues. In some embodiments, redundant database repository 251a may currently be experiencing a large number of queries and / or other tasks that reduce processing bandwidth, thereby delaying the response to subquery 215b. Graph data server 200 can be used to manage such situations where repository is unavailable using various techniques.

[0032] In Example 1, the graph data server 200 receives an indication that the redundant database repository 251a is unavailable and therefore cannot execute subquery 215b in a timely manner that meets a particular QoS objective. In response to the indication, the graph data server 200 distributes vertices 212b and 212d included in subquery 215b to the remaining subqueries 215a and 215c. As shown, vertex 212b is added to subquery 215a and vertex 212d is added to subquery 215c. In some embodiments, the reallocation can be based on a previously generated hash value to assign the two vertices to subquery 215b. In other embodiments, a new hash value can be generated and then used for the reallocation. In some embodiments, new hash values ​​can be generated for all six vertices 212 to increase the likelihood that the six vertices are evenly distributed among the remaining subqueries 215.

[0033] In Example 2, the graph data server 200 receives an indication that the redundant database repository 251a is unavailable. In response to the indication, the graph data server 200 reallocates the subquery 215b intended for the unavailable redundant database repository 251b to an available one of the remaining database repositories. As shown in Example 2, the subquery 215b is reallocated to the redundant database repository 251b. In some embodiments, the redundant database repository 251b may be selected based on having more available bandwidth than the primary database repository 250. For example, in response to sending each subquery in the subqueries 215, the respective database repositories may reply with an indication of the currently available bandwidth, an indication of the estimated response time, and / or other information that enables the graph data server to determine which database repositories are able to execute the corresponding subqueries and which subqueries should be reallocated.

[0034] It should be noted that Figure 2 The embodiments shown are merely examples that demonstrate the disclosed concepts. In other embodiments, different combinations of blocks may be included. For example, in the illustrated embodiment, three database repositories are shown. In other embodiments, any suitable number of database repositories may be included in the graph data server. Although the database repositories are shown as being included within the graph data server 200, in other embodiments, one or more of the repositories may be external to the graph data server 200. For example, the database repository may include server storage rented from a third party.

[0035] Figure 1 and Figure 2 Techniques for processing queries to a graph database are shown. The graph database is described as being maintained across multiple database repositories, each of which can be used to execute at least a portion of a received query. Other schemes for maintaining a graph database can be considered. Figure 3An example of another technique for managing a graph data server is provided.

[0036] Go to Figure 3 , a block diagram of an embodiment of a system for maintaining separate copies of a graph database for different groups of users is shown. As shown, a graph data server 300 includes a risk group repository 350, a non-risk group repository 360, and a graph data processing server 320. The graph data server 300 uses a server process 304 to provide services to risk users 370 and uses a server process 308 to provide services to non-risk users 375. It is worth noting that risk and non-risk user groups are used as non-limiting examples of maintaining separate copies of a graph database. Other examples for maintaining separate copies can be considered. For example, separate copies can be used to serve different geographic regions, different political boundaries / borders, different client service agreements, etc.

[0037] As shown, the graph data server 300 includes a risk group repository 350 that stores a copy of a graph database 355. In some embodiments, the risk group repository 350 may include multiple database repositories, such as Figure 2 . In addition to the copy of the graph database 355 stored in the risk group repository 350, the graph data server 300 also stores a copy of the graph database 355 in the non-risk group repository 360. In a similar manner to the risk group repository 350, the non-risk group repository 360 may include different multiple database repositories. The copy of the graph database 355 in the risk group repository 350 is accessible to a first group of users (risk users 370). The copy of the graph database 355 in the non-risk group repository 360 is accessible to a second group of users (non-risk users 375), but not to risk users 370.

[0038] The graph data server 300 can support a wide variety of users who subscribe to services provided by the graph data server 300. As shown, the graph data server 300 classifies the various users into one of two groups, namely, "risk" users or "non-risk" users. The classification can be based on various attributes of the respective users, including attributes that can provide an indication of whether a particular user is associated with a threshold level of risk. Risky users 370 can include users associated with previous suspicious activity, such as potential fraudulent activity, activity that resulted in complaints or claims being filed, and / or activity associated with hacker attacks. In this case, the known behavior may not be sufficient to ban the user or terminate their subscription. In some cases, users who are associated with other users involved in such suspicious behavior may be included in the risky users 370. New subscribers who do not have a history that can be tracked by the graph data server 300 may also be included in the risky users 370.

[0039] Users who do not meet the risk threshold level may be placed in non-risk users 375. Non-risk users 375 may include users who have subscribed to the services of graph data server 300 for a specific amount of time without engaging in any suspicious behavior. In some cases, non-risk users may include users associated with a trusted entity. For example, a user employed by a company that has a long-term trust relationship with graph data service 300 may be placed in non-risk users 375 even if the particular user does not have a personal history with graph data server 300.

[0040] The determination of the appropriate user group for a given user may be accomplished by a computer system within the graph data server 300. For example, a new user with no available activity history may be placed in the risk users 370 by default. A process running in the graph data server 300 may monitor some or all activity associated with accounts assigned to risk users 370. A determination may then be made as to whether any monitored activity is associated with undesirable behavior (e.g., matching a known fraud pattern, making electronic transfers to accounts that have been flagged for fraudulent activity, activity that disrupts the performance of the graph data server 300 or other services associated with the graph data server 300, etc.). If, after a particular amount of time and / or activity, it is determined that the new user account exhibits little or no undesirable behavior, the new user account may be reassigned to a non-risk user 375.

[0041] Similarly, account activity of non-risk users 375 may also be monitored by one or more processes running within the graph data server 300. If, after a certain amount of time and / or activity, a particular non-risk user account is determined to exhibit an amount of undesirable behavior that exceeds a threshold limit, the particular non-risk user account may be reassigned to a risky user 370.

[0042] By independently managing access to each repository, dividing each graph database 355 into a risk group repository 350 and a non-risk group repository 360 can provide increased security for non-risk users 375. As shown, the graph data server 300 uses different processes to interact with risk users and non-risk users. For example, the graph data server 300 uses a computer system (e.g., Figure 1 The graph data server 300 may also use a server process 308 running on the computer system 101 to receive a second query from a user of a non-risk user 375. The server processes 304 and 308 may use a query such as described above with respect to Figure 1 and Figure 2The described techniques are used to execute the first query and the second query received respectively. The server process 304 utilizes the risk group repository 350 to execute the first query, while the server process 308 utilizes the non-risk group repository 360 to execute the second query.

[0043] As shown, server processes 304 and 308 are isolated from each other. During processing of the first query and the second query, and at other times, server process 304 does not communicate with server process 308, and vice versa. Therefore, if a user in risky users 370 engages in undesirable activities (e.g., unauthorized access to server process 304), the user cannot interfere with or access server process 308 or non-risk group repository 360. Therefore, non-risk users 375 can access non-risk group repository 360 with little threat of damage from risky users 370.

[0044] In order to provide independent services to risk users 370 and non-risk users 375, separate copies of the graph database 355 are maintained in each of the risk group repository 350 and the non-risk group repository 360. However, maintaining separate repositories may pose challenges in keeping the two copies of the graph database 355 synchronized with equivalent information. To address these challenges, the graph data server 300 utilizes the graph data processing server 320 to store copies of the graph database 355 by using corresponding data storage engines 325a and 325b for the risk group repository 350 and the non-risk group repository 360 to simultaneously send new records (e.g., new records 340) to corresponding copies of the graph database 355 in the risk group repository 350 and the non-risk group repository 360.

[0045] The graph data processing server 320 includes a data processing engine 380 that can monitor system activity 390. System activity 390 can include any suitable type of activity associated with the operation of the graph data server 300 or different systems associated with the graph data server 300. In some embodiments, the graph data server 300 can be part of an online entity that provides a variety of services to users. For example, the online entity can provide various services related to performing electronic exchanges between users. In such an embodiment, system activities can include users logging into their accounts, identifying other users with whom to perform electronic exchanges, and performing exchanges. The data processing engine 380 can generate a new record corresponding to each activity, or generate corresponding new records for each individual step of a given activity. Performing an electronic exchange can include verifying the identity of the parties involved in the exchange, performing a risk assessment on each identified party, verifying the electronic items to be exchanged, and achieving the transfer of ownership of each item. New records can be generated for each party at each step. The new record 340 can correspond to one of these new records.

[0046] After the new record 340 is created by the data processing engine 380, the graph data processing server 320 sends a copy of the new record 340 to each of the data storage engines 325a and 325b. The data storage engines 325a and 325b operate independently of each other, sending their corresponding copies of the new record 340 to the risk group repository 350 and the non-risk group repository 360, respectively. Although the storage of the copies of the new record 340 to the various repositories may not begin and end at exactly the same time, the concurrent operation of the data storage engines 325a and 325b can reduce the amount of time during which the various copies of the graph database 355 in the risk group repository 350 and the non-risk group repository 360 are different.

[0047] After the data storage engines 325a and 325b complete their respective storage operations, as shown, the graph data processing server verifies the storage of the new record 340 to the risk group repository 350 and the non-risk group repository 360 using the data verification engine 330. The data verification engine 330 reads the respective copies of the new record 340 from the risk group repository 350 and the non-risk group repository 360. The data verification engine 330 can then compare each of the respective read copies of the new record 340 with the copy of the new record 340 stored by the graph data processing server 320 (e.g., in the memory circuit of the computer system 101). By reading the respective copies and comparing the plurality of read copies with the original copy stored in the computer memory, the data verification engine 330 can verify whether each repository has successfully stored a copy of the new record 340, and whether the same information is stored in the respective copies of the graph database 355 in each of the risk group repository 350 and the non-risk group repository 360.

[0048] It should be noted that Figure 3 The systems shown are merely examples that demonstrate the concepts disclosed. Some components are not shown to improve the clarity of the diagram. For example, the graph data server 300 may include multiple computer systems to implement the various processes and engines described. In some embodiments, for example, the server process 304 may be implemented on one or more computer systems that are different from the one or more computer systems used to implement the server process 308. In other embodiments, the server processes 304 and 308 may be executed on the same or overlapping groups of computer systems.

[0049] As described above, risk user groups and non-risk user groups are used as non-limiting examples of maintaining two or more separate copies of a graph database in each respective repository. In other embodiments, by maintaining separate database repositories, any suitable set of requirements may be advantageously served. For example, geopolitical boundaries may require separation of database repositories. Specific countries may implement standards for accessing specific types of information stored in a database. By maintaining multiple repositories with corresponding server processes to perform queries in different repositories, server processes may be implemented to meet local country standards. In such embodiments, new user accounts are assigned to the user's respective groups based on the country of origin in which the account is set up, or in some cases based on the country in which a given user is currently determined to be located.

[0050] At the same time, a single graph data processing server (or multiple graph data processing services communicating with each other) may be able to maintain an acceptable level of synchronization between multiple repositories. For example, various data processing engines may be running to collect system activity from multiple different countries, and each data processing engine may be used to comply with local country data collection standards. The collected data may then be collected in a centralized graph data processing server, where one or more new records may be created based on the collected activity. The new records may then be distributed simultaneously to various regional repositories using, for example, a corresponding data storage engine for each repository. These corresponding data storage engines may operate from a centralized location of a graph data processing server, based on computer systems across multiple regions, or a combination thereof.

[0051] As another example embodiment, separate graph database repositories may be maintained to support different client service agreements. For example, new clients may be provided with the option of subscribing to a basic, intermediate, or premium service level, each of which provides a specific set of features. In addition, each service level may have a respective quality of service agreement, which includes a corresponding guaranteed maximum delay for receiving responses to queries executed. In such an embodiment, new users are assigned to the user group to which they subscribe. By maintaining a separate repository for each service level, each repository may be equipped and configured to support the corresponding features and query response times corresponding to the corresponding service level. Thus, a basic service may be provided in which the features and query response times are limited by the current bandwidth of the corresponding repository, despite the increase in the number of current basic-level subscribers. However, premium services may limit the number of subscriptions so that even if all premium subscribers use the system at the same time, there is no risk that the quality of service is below the guaranteed level. In such an embodiment, adding a new user to the premium level may result in adding or upgrading equipment to the premium-level repository to ensure a guaranteed quality of service.

[0052] As described for the geopolitical example, a centralized graph data processing server can collect system activity and distribute newly created records across various repositories simultaneously to maintain an acceptable level of consistency across the various replicas of the graph database. Keeping the graph database consistent across multiple repositories reduces the risk of receiving different results from two queries submitted simultaneously by users at two different subscription levels.

[0053] Figures 1 to 3 Various aspects of the disclosed technology for operating a graph data server are described. Various methods may be employed to perform the operation of a graph data server. Figures 4 to 7 A variety of such methods for operating a graph data server are described in .

[0054] Now go to Figure 4 , a flowchart of an embodiment of a method for generating a smart agreement executed on a blockchain platform is shown. The method 400 can be performed by a computer system (e.g. Figure 1 For example, the computer system 101 may include (or may have access to) a non-transitory computer-readable medium having program instructions stored thereon, the program instructions being executable by the computer system 101 to cause the reference Figure 4 The following operation is used Figure 1 The method 400 is described using the graph data server 100 as an example. Figure 1 References to elements in are included as non-limiting examples.

[0055] The method 400 begins at block 410 by receiving, by a computer system, a query for a particular graph database that identifies a plurality of vertices in the particular graph database. For example, the computer system 101 receives a query 110 that includes four vertices (vertex 112a to vertex 112d). The query 110 may be received from an authorized user of the graph data server 100. In various embodiments, the query 110 may include a request to identify any or all edges between any two of the included vertices 112, a request to identify edges to other vertices common to any two or more of the vertices 112, or other similar requests. In some embodiments, the graph data server 100 may be part of a larger online service, and the graph database 155 may include a collection of information associated with users and user activities from the larger online service operation.

[0056] At 420, method 400 continues by performing, by the computer system, a hash operation on two or more vertices of the plurality of vertices to generate corresponding hash values. Figure 1In the example of , hash operation 120 is performed on two or more vertices 112 of query 110. As shown, four hash values ​​113 are generated, for example, one hash value for each of vertices 112. Hash operation 120 may use any suitable type of hash algorithm that produces a balanced distribution of hash value outputs from vertex inputs.

[0057] Method 400 continues at 430 by dividing, by the computer system, the query into a plurality of sub-queries using corresponding hash values, each sub-query corresponding to a subset of the plurality of vertices. Figure 1 As shown, computer system 101 uses hash value 113 to assign vertices 112a and 112d to subquery 115a, and assigns vertices 112b and 112c to subquery 115b. In some embodiments, the number of subqueries 115 can be determined by hash value 113. For example, the possible values ​​of hash value 113 can be between 1 and 100. Subranges can be mapped to specific subqueries, for example, hash values ​​of 1-25 are mapped to subquery 115a, hash values ​​of 26-50 are mapped to subquery 115b, hash values ​​of 50-57 are mapped to subquery 115c (not shown), and hash values ​​of 76-100 are mapped to subquery 1152 (not shown). Therefore, hash values ​​113a and 113d can fall within the range of 1-25, while hash values ​​113b and 113c fall within the range of 26-50. In other embodiments, the number of available database repositories 150 can determine the number of subqueries to be generated. The mapping from hash values ​​113 to sub-queries 115 may be set dynamically based on a number of desired sub-queries.

[0058] At 440, method 400 continues by sending, by the computer system, a subquery of the plurality of subqueries to a plurality of database repositories of a particular graph database. For example, subquery 115 may be mapped to a corresponding database repository in database repository 150. Subquery 115 is sent to the corresponding database repository 150 to be executed using a corresponding copy of graph database 155. Request information associated with each vertex 112 included in each subquery 115 may be collected and returned to computer system 101. Computer system 101 may then analyze the returned information using parameters included in query 110 to generate a graph representation indicating edges associated with vertex 112. The graph representation may then be provided to a user who sent query 110.

[0059] It is worth noting that by dividing the query into multiple subqueries, the load resulting from processing the query can be balanced across multiple database repositories. This load balancing can distribute the workload across the database repositories in a way that reduces the peak traffic to any given one repository. Using multiple subqueries can also reduce the amount of time to produce query results, thereby meeting established QoS that may apply to a particular user.

[0060] It should be noted that Figure 4 The method includes elements 410-440. Method 400 may end in block 440, or some or all of the blocks of the method may be repeated. For example, method 400 may return to box 410 to receive a subsequent query. In some embodiments, blocks 420 and 430 may be repeated to generate a satisfactory number of sub-queries. For example, a first hash operation that does not fully distribute vertices in the sub-query may be used. Block 420 may be repeated using a different seed value for the hash operation or using a different hash operation to generate a new set of hash values. Multiple instances of method 400 may be executed simultaneously in the graph data server 100 to execute different queries. For example, the computer system 101 may execute multiple processes for receiving multiple queries from one or more users.

[0061] Now go to Figure 5 , a flow chart of a method for managing an unavailable database repository is shown. In a manner similar to method 400, method 500 may be performed by a computer system (such as Figure 1 For example, the computer system may include (or may have access to) a non-transitory computer-readable medium having program instructions stored thereon, the program instructions being executable by the computer system to cause the reference Figure 5 In some embodiments, some or all of the operations of method 500 may correspond to actions that occur as part of block 440 in method 400. Figure 2 The method 500 is described using the graph data server 200 as an example. Figure 2 References to elements in are included as non-limiting examples.

[0062] Method 500 begins at 510 by sending, by a computer system, a particular subquery to a corresponding one of a plurality of database repositories. For example, Figure 2 The query 210 in is divided into sub-queries 215. A particular sub-query, such as sub-query 215b, is sent to redundant database repository 251a.

[0063] At 520, method 500 continues by receiving, by the computer system, an indication that a particular one of the plurality of database repositories is unavailable. Figure 2As shown in the example of , the redundant database repository 251a is unavailable. In some embodiments, the unavailability may be due to all or a portion of the redundant database repository 251a being down for maintenance or a hardware or software problem. In other embodiments, the redundant database repository 251a may be operating normally, but a bandwidth threshold level may have been reached, resulting in the redundant database repository 251a being unable to receive additional workload. The indication may include a message from a computer system associated with the redundant database repository 251a, which alerts that the graph data server is unavailable. In other embodiments, the indication may be in the form of a lack of a reply (e.g., an acknowledgment) from the redundant database repository 251a in response to sending the subquery 215b.

[0064] In various embodiments, method 500 may be performed using one of a variety of techniques. In some embodiments, method 500 continues at 530a by distributing, by the computer system, vertices included in the particular subquery intended for the unavailable database repository into the remaining plurality of subqueries. Figure 2 As shown in Example 1 of , portions of subquery 215b may be distributed to one or more other subqueries. A portion of subquery 215b associated with vertex 212b is added to subquery 215a, while a different portion of subquery 215b associated with vertex 212d is added to subquery 215c. Subqueries 215a and 215c may be resent to primary database repository 250 and redundant database repository 251b, respectively, after the respective portions of subquery 215b have been added. In other embodiments, additional portions may be distributed to primary database repository 250 and redundant database repository 251b after the original subqueries 215a and 215c have been sent.

[0065] In other embodiments, method 500 continues at 530b by reallocating, by the computer system, the particular subquery intended for the unavailable database repository to an available one of the plurality of database repositories. Figure 2 As shown in Example 2, the subquery 215b body remains intact as a single subquery and is sent to one of the remaining available repositories, such as redundant database repository 251b. The available database repositories can be selected using any suitable technique, such as round-robin selection, random (or pseudo-random) selection, or based on current bandwidth levels.

[0066] It should be noted that method 500 includes elements 510-530b. Method 500 may end in one of blocks 530a or 530b, or some or all of the blocks of the method may be repeated. For example, if one of the other database repositories is also unavailable, method 500 may return to block 520. As with method 400, method 500 may be executed concurrently with other instantiations of the method. For example, different queries may be processed concurrently so that more than one subquery is sent to the same unavailable database repository.

[0067] Now go to Figure 6 , which shows a flow chart of a method for maintaining a graph data server. In a manner similar to methods 400 and 500, method 600 may be performed by a graph data server (such as Figure 3 For example, such a computer system may include (or have access to) a non-transitory computer-readable medium having program instructions stored thereon, the program instructions being executable by the computer system to cause the reference Figure 6 The following operation is used Figure 3 The method 600 is described using the graph data server 300 as an example. Figure 3 References to elements in are included as non-limiting examples.

[0068] The method 600 begins at 610 by storing, by a computer system, a particular graph database and a copy of the particular graph database in different multiple database repositories. For example, the graph data server 300 includes a risk group repository 350 and a non-risk group repository 360. A corresponding copy of the graph database 355 is stored in each of these repositories. The risk group repository 350 is accessible by a first group of users (risk users 370) classified as risk, while the non-risk group repository 360 is accessible by a second group of users (non-risk users 375) classified as non-risk. One or more policies of the entity that owns and / or manages the graph data server 300 may require separation between risk users 370 and non-risk users 375. Therefore, the non-risk group repository 360 is not accessible to risk users 370. In addition, these policies can prevent links between the copies of the graph database 355 in the risk group repository 350 and the non-risk group repository 360.

[0069] As described above, risk users 370 may include users who have been associated with suspicious activity, such as potential fraud, activity associated with filed complaints or claims, and / or activity related to unauthorized access to a computer system. In this case, the activity may not be sufficient to ban the user or terminate their subscription. In some cases, users associated with other users involved in such suspicious behavior may be included in risk users 370. New subscribers who do not have a history that can be tracked by the graph data server 300 may also be included in risk users 370. However, users who are not associated with suspicious activity and / or are not associated with trusted entities may be placed in non-risk users 375.

[0070] Method 600 continues at 620 by receiving a first query from a first group of users using a first process running on a computer system, wherein the first group of users is classified as a risk. Figure 3 In the example of , a first query is received by a server process 304 running on a computer system of a graph data server 300 from a first user of risk users 370 . The first query may identify one or more vertices included in a graph database 355 .

[0071] At 630, method 600 continues by processing the first query using only a particular graph database. As shown, for example, server process 304 utilizes only a copy of graph database 355 in risk group repository 350. Risk group repository 350 may include multiple database repositories, such as a master repository and one or more replica repositories. Thus, server process 304 may utilize the above description of Figure 1 and Figure 2 The described techniques and methods 400 and 500 use only the risk group repository 350 to perform the first query.

[0072] The method 600 continues at 640 by receiving a second query from a second group of users using a second process running on a computer system, wherein the second group of users is classified as non-risk, and wherein the first and second processes do not communicate with each other. For example, the second query is received by a server process 308 running on a computer system of a graph data server 300 from a second user of a non-risk user 375. As with the first query, the second query may also identify one or more vertices included in the graph database 355. According to a policy associated with the graph data server 300, the server process 304 and the server process 308 do not communicate with each other. Such process separation between the risk user 370 and the non-risk user 375 can reduce the risk that a malicious user of the risk user 370 can confuse and / or corrupt the information used to perform the second query. Such corruption or confusion would potentially enable a malicious user to prevent the second user from accessing accurate information using the second query, which, for example, would cause the second user to be vulnerable to fraudulent activity.

[0073] At 650, method 600 continues by processing a second query using only the replicated graph database. Figure 3 , the server process 308 utilizes only the copy of the graph database 355 in the non-risk group repository 360. Like the risk group repository 350, the non-risk group repository 360 may also include multiple database repositories, including a master repository and one or more replica repositories. Similarly, the server process 308 may utilize the techniques disclosed herein to perform the second query using only the non-risk group repository 360.

[0074] It should be noted that method 600 includes elements 610-650. Method 600 may end in block 650, or some or all blocks of the method may be repeated. For example, method 600 may return to blocks 620 and / or 640 to receive additional queries from users of risk groups and non-risk groups, respectively. As with method 400, method 600 may be executed simultaneously with other instantiations of the method. In addition, blocks within method 600 may be executed in different orders, including, for example, concurrent execution. For example, blocks 620 and 630 may be executed in an overlapping manner with blocks 640 and 650.

[0075] Go to Figure 7 , which shows a flow chart of a method for adding a new record to a corresponding copy of a graph database. The method 700 can be performed by a graph data server (such as Figure 3 In some embodiments, the method 700 may correspond to actions that occur as part of block 610 in the method 600. Figure 3 The graph data server 300 is used as an example for executing the method 700 in the following paragraphs. Figure 3 References to elements in are included as non-limiting examples.

[0076] The method 700 begins at block 710 by sending a new record to a specific graph database and a replicated graph database simultaneously using respective data storage engines for the specific graph database and the replicated graph database by a computer system. Figure 3As shown, the graph data processing server 320 uses the data storage engine 325a to store a copy of the new record 340 in the risk group repository 350, and uses the independent data storage engine 325b to store another copy of the new record 340 in the non-risk group repository 360. As disclosed herein, the graph data processing server 320 is a process running in the graph data server 300 for maintaining the graph database 355 in both the risk group repository 350 and the non-risk group repository 360. The maintenance of the graph database 355 includes observing system activities 390 using the data processing engine 380, and generating new records based on the system activities 390 to be stored in the two copies of the graph database 355. In order to reduce the chance that the two copies of the graph database 355 have any differences at a given point in time, the graph data processing server 320 uses the independent data storage engines 325a and 325b to store the new record 340 in both the risk group repository 350 and the non-risk group repository 360 at the same time. Due to various circumstances (e.g., current workload, hardware availability, etc.), storing new records 340 into each of the graph databases 355 may not begin and / or end at exactly the same point in time. However, concurrent use of data storage engines 325a and 325b can reduce the amount of time during which new records 340 are available to queries in one repository but not to queries in other repositories.

[0077] At 720, method 700 continues by verifying the storage of the new record to the specific graph database and the different graph database. For example, after the operation of block 710 is completed, the data verification engine 330 verifies whether the new record 340 has been successfully stored in both the risk group repository 350 and the non-risk group repository 360. As shown, the verification includes the following two sub-blocks.

[0078] Block 720 includes sub-block 730, where method 700 continues by reading respective copies of the new record from the particular graph database and the replicated graph database. As shown, data validation engine 330 reads a new stored copy of new record 340 from each copy of graph database 355. Figure 3 As shown in FIG, communication is not allowed between the risk group repository 350 and the non-risk group repository 360. Therefore, the data verification engine 330 issues a separate read request to each repository.

[0079] Block 720 also includes sub-block 740, where the method 700 continues by comparing the corresponding copy with the copy of the new record stored in the computer system. For example, the data verification engine 330 receives a copy of the new record 340 provided by the data processing engine 380. The data verification engine 330 compares the original copy with the copies received from each of the risk group repository 350 and the non-risk group repository 360. If the copy of the new record 340 from either the risk group repository 350 and the non-risk group repository 360 does not match the copy of the new record 340 from the data processing engine 380, then the storage request is resent using an appropriate one of the data storage engines 325 to correct the unsuccessfully stored copy of the new record 340.

[0080] It should be noted that method 700 includes elements 710-740. Method 700 may end in sub-block 740, or some or all of the blocks of the method may be repeated. For example, some or all of the blocks of method 700 may be repeated in response to failure to successfully verify the stored copy of new record 340. It is contemplated that in an embodiment of a graph data server, some or all of methods 400, 500, 600, and 700 (or portions thereof) may be performed simultaneously. In other embodiments, portions of a given one of the disclosed methods may be included with other methods of the methods.

[0081] exist Figure 1-Figure 7 In the description, various computer systems for implementing the disclosed technology have been disclosed, such as Figure 1 In addition, any of the server processes 304 and 308, the graph data processing server 320, and the disclosed repositories (150, 250, 251, 350, and 360) can be implemented using one or more computer systems. These computer systems can be implemented in various ways. Figure 8 Examples are provided of computer systems that may correspond to one or more of the disclosed systems.

[0082] Reference now Figure 8, a block diagram of an example computer system 800 is shown. In various embodiments, the computer system 800 may implement one or more of the disclosed computer systems, such as the computer system 101 and / or any disclosed storage repositories. The computer system 800 includes a processor subsystem 820 coupled to a system memory 840 and (one or more) I / O interfaces 860 via an interconnect 880 (e.g., a system bus). The (one or more) I / O interfaces 860 are coupled to one or more I / O devices 870. The computer system 800 may be any of a variety of types of devices, including, but not limited to, a server computer system, a personal computer system, a desktop computer, a laptop or notebook computer, a mainframe computer system, a server computer system operating in a data center facility, a tablet computer, a handheld computer, a smart phone, a workstation, a network computer, a networked vehicle, etc. Although for convenience, the computer system 800 is not limited to a server computer system, a personal computer system, a desktop computer, a laptop or notebook computer, a mainframe computer system, a server computer system operating in a data center facility, a tablet computer, a handheld computer, a smart phone, a workstation, a network computer, a networked vehicle, etc. Figure 8 Although a single computer system 800 is shown in FIG. 8 , computer system 800 may also be implemented as two or more computer systems operating together, such as as a virtual computer system.

[0083] Processor subsystem 820 may include one or more processor circuits. In various embodiments of computer system 800, multiple instances of processor subsystem 820 may be coupled to interconnect 880. In various embodiments, processor subsystem 820 (or each processor unit within 820) may contain a cache or other form of onboard memory.

[0084] The system memory 840 may be used to store program instructions that may be executed by the processor subsystem 820 to cause the computer system 800 to perform various operations described herein, including, for example, any of the methods 400-700. The system memory 840 may be implemented using any suitable type of memory circuit, including, for example, different physical, non-transitory, computer-readable media, such as hard disk memory, floppy disk memory, removable disk memory, flash memory, random access memory (RAM-SRAM, EDO RAM, SDRAM, DDR SDRAM, LPDDR SDRAM, etc.), read-only memory (PROM, EEPROM, etc.), etc. The memory circuit in the computer system 800 is not limited to main memory, such as the system memory 840. Instead, the computer system 800 may also include other forms of memory, such as cache memory in the processor subsystem 820 and auxiliary memory (e.g., hard disk drive, storage array, etc.) in the I / O device 870. In some embodiments, these other forms of memory may also store program instructions that may be executed by the processor subsystem 820.

[0085] According to various embodiments, the I / O interface 860 can be any of a variety of types of interfaces configured to couple to and communicate with other devices. In one embodiment, the I / O interface 860 is a bridge chip (e.g., a south bridge) from a front-side bus to one or more back-side buses. The I / O interface 860 can be coupled to one or more I / O devices 870 via one or more corresponding buses or other interfaces. Examples of I / O devices 870 include storage devices (hard drives, optical drives, removable flash drives, storage arrays, SANs, or their associated controllers), network interface devices (e.g., to a local area network or wide area network), or other devices (e.g., graphics, user interface devices, etc.). In one embodiment, the I / O device 870 includes a network interface device (e.g., configured to communicate via a Ethernet, etc. for communication), and the computer system 800 is coupled to the network via a network interface device.

[0086] This disclosure includes references to "an embodiment" or groups of "embodiments" (e.g., "some embodiments" or "various embodiments"). Embodiments are different implementations or instances of the disclosed concepts. References to "an embodiment," "one embodiment," "a particular embodiment," etc. do not necessarily refer to the same embodiment. A large number of possible embodiments are contemplated, including those specifically disclosed as well as modifications or alternatives that fall within the spirit or scope of the disclosure.

[0087] The present disclosure may discuss potential advantages that may be generated by the disclosed embodiments. Not all implementations of these embodiments will necessarily exhibit any or all potential advantages. Whether an advantage is achieved for a particular implementation depends on many factors, some of which are outside the scope of the present disclosure. In fact, there are multiple reasons why an implementation that falls within the scope of the claims may not exhibit some or all of any of the disclosed advantages. For example, a particular implementation may include other circuits outside the scope of the present disclosure, which, in combination with one of the disclosed embodiments, negate or reduce one or more of the disclosed advantages. In addition, suboptimal design execution of a particular implementation (e.g., implementation techniques or tools) may also negate or reduce the disclosed advantages. Even assuming a skilled implementation, the realization of the advantages may still depend on other factors, such as the environmental conditions in which the implementation is deployed. For example, the input provided to a particular implementation may prevent one or more problems solved in the present disclosure from occurring on a particular occasion, with the result that the benefits of its solution cannot be realized. In view of the existence of possible factors outside the present disclosure, it is explicitly intended that any potential advantages described herein should not be interpreted as claim limitations that must be met to prove infringement. Instead, the confirmation of these potential advantages is intended to illustrate the type of (one or more) improvements that are available to designers who benefit from the present disclosure.

[0013] Such permissive descriptions of advantages (eg, stating that a particular advantage "may occur") are not intended to cast doubt on whether such advantages can actually be achieved, but rather to recognize that achievement of such advantages often depends on technical realities of additional factors.

[0088] Unless otherwise stated, the embodiments are non-limiting. That is, the disclosed embodiments are not intended to limit the scope of claims drafted based on the present disclosure, even if only a single example is described with respect to a particular feature. The disclosed embodiments are intended to be illustrative and not restrictive, and there is no statement to the contrary in the present disclosure. Thus, the present application is intended to allow claims covering the disclosed embodiments, as well as such substitutions, modifications, and equivalents that are apparent to those skilled in the art having the benefit of the present disclosure.

[0089] For example, features in this application may be combined in any suitable manner. Thus, during the examination of this application (or an application claiming priority thereto), new claims may be formulated to any such combination of features. In particular, with reference to the appended claims, features of dependent claims may be combined with features of other dependent claims, including claims that are dependent on other independent claims, where appropriate. Similarly, features from individual independent claims may be combined where appropriate.

[0090] Thus, while the appended dependent claims may be drafted such that each dependent claim is dependent on a single other claim, additional dependencies are also contemplated. Any combination of features in the dependent claims consistent with the present disclosure is contemplated and may be claimed in this or another application. In short, the combinations are not limited to those specifically listed in the appended claims.

[0091] It is also contemplated that claims drafted in one format or legal type (eg, apparatus) are intended to support corresponding claims in another format or legal type (eg, method), where appropriate.

[0092] In the present disclosure, various "processes" and "engines" are operable to perform specified functions as shown and described in detail (e.g., server processes 304 and 308, data storage engines 325a and 325b, data verification engine 330, etc.). As used herein, "processes" and "engines" refer to software and / or hardware that are operable to perform a specified set of operations. A process / engine may refer to a set of software instructions that can be executed by a computer system to perform the set of operations. A process / engine may also refer to hardware configured to perform the set of operations. For example, a hardware engine may constitute general-purpose hardware and a non-transient computer-readable medium storing program instructions, or special-purpose hardware such as a custom ASIC. Therefore, a process / engine described as "executable" to perform an operation refers to a software module, while a process / engine described as "configured" to perform an operation refers to a hardware module. A module described as "operable" to perform an operation refers to a software module, a hardware module, or some combination thereof. Furthermore, for any discussion herein involving modules “executable” to perform certain operations, it should be understood that in other embodiments, these operations may be implemented by hardware modules “configured” to perform these operations, and vice versa.

[0093] Because this disclosure is a legal document, various terms and phrases may be subject to administrative and judicial interpretation. It is hereby notified that the definitions provided in the following paragraphs as well as throughout this disclosure will be used to determine how to interpret claims drafted based on this disclosure.

[0094] Unless the context clearly indicates otherwise, reference to an item in the singular (i.e., a noun or noun phrase beginning with "a," "an," or "the") is intended to mean "one or more." Thus, reference to "an item" in a claim does not exclude additional instances of that item in the absence of accompanying context. A "plurality" item refers to a collection of two or more items.

[0095] The word "may" is used herein in a permissive sense (ie, having the potential to, being able to), rather than in the mandatory sense (ie, must).

[0096] The terms "including" and "comprising" and forms thereof are open ended and mean "including, but not limited to."

[0097] When the term "or" is used in this disclosure with respect to a list of options, it will generally be understood to be used in an inclusive sense unless the context provides otherwise. Thus, a recitation of "x or y" is equivalent to "x or y, or both," thereby covering 1) x but not y, 2) y but not x, and 3) both x and y. On the other hand, a phrase such as "either x or y, but not both" makes it clear that "or" is used in an exclusive sense.

[0098] The recitation of "w, x, y, or z, or any combination thereof" or "at least one of . . . w, x, y, and z" is intended to cover all possibilities involving a single element up to the total number of elements in the set. For example, given the set [w, x, y, z], these phrases cover any single element of the set (e.g., w but no x, y, or z), any two elements (e.g., w and x but no y or z), any three elements (e.g., w, x, and y but no z), and all four elements. Thus, the phrase "at least one of . . . w, x, y, and z" refers to at least one element in the set [w, x, y, z], thereby covering all possible combinations in the list of elements. The phrase should not be interpreted as requiring the presence of at least one instance of w, at least one instance of x, at least one instance of y, and at least one instance of z.

[0099] In this disclosure, various "labels" may precede a noun or noun phrase. Unless the context provides otherwise, different labels for a feature (e.g., "first circuit," "second circuit," "particular circuit," "given circuit," etc.) refer to different instances of the feature. Additionally, unless otherwise stated, the labels "first," "second," and "third" do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) when applied to features.

[0100] The phrase "based on" is used to describe one or more factors that influence a determination. This term does not exclude the possibility that additional factors may influence a determination. That is, a determination may be based only on specified factors, or on specified factors and other unspecified factors. Consider the phrase "A is determined based on B." This phrase states that B is a factor used to determine A or influences the determination of A. This phrase does not exclude that the determination of A may also be based on some other factor, such as C. The phrase is also intended to cover embodiments in which A is determined based only on B. As used herein, the phrase "based on" is synonymous with the phrase "based at least in part on."

[0101] The phrases "in response to" and "in response to..." describe one or more factors that trigger an effect. The phrase does not exclude the possibility that additional factors may influence or otherwise trigger the effect in conjunction with or independently of the specified factors. That is, the effect may be responsive only to these factors, or may be responsive to the specified factors as well as other unspecified factors. Consider the phrase "in response to B, A is executed." The phrase specifies that B is a factor that triggers the execution of A or triggers a specific result of A. The phrase does not exclude that the execution of A may also be responsive to some other factor, such as C. The phrase also does not exclude that the execution of A may be jointly responsive to B and C. The phrase is also intended to cover embodiments in which A is executed only in response to B. As used herein, the phrase "in response to" is synonymous with the phrase "at least partially responsive to." Similarly, the phrase "in response to..." is synonymous with the phrase "at least partially responsive to."

[0102] Within the present disclosure, different entities (which may be variously referred to as "units," "circuits," other components, etc.) may be described or claimed as being "configured" to perform one or more tasks or operations. This expression—"[the entity] is configured to [perform one or more tasks]"—is used herein to refer to a structure (i.e., something physical). More specifically, this expression is used to indicate that the structure is arranged to perform one or more tasks during operation. A structure may be said to be "configured to" perform a task even if the structure is not currently being operated. Thus, an entity described or stated as "configured to" perform a task refers to something physical, such as a device, a circuit, a memory having a processor unit and storing program instructions executable to implement the task, etc. The phrase is not used herein to refer to something intangible.

[0103] In some cases, various units / circuits / components may be described herein as performing a set of tasks or operations. It should be understood that these entities are "configured to" perform these tasks / operations, even if not specifically stated.

[0104] The term "configured to" is not intended to mean "configurable to". For example, an unprogrammed FPGA would not be considered to be "configured to" perform a particular function. However, the unprogrammed FPGA may be "configurable to" perform that function. After appropriate programming, the FPGA may then be said to be "configured to" perform a particular function.

[0105] For purposes of a U.S. patent application based on the present disclosure, reciting in a claim that a structure is “configured to” perform one or more tasks is expressly not intended to invoke 35 U.S.C. § 112(f) for that claim element. If the applicant wishes to invoke § 112(f) during prosecution of a U.S. patent application based on the present disclosure, it would use the “means for [performing the function]” construction to recite the claim element.

Claims

1. A method comprising: Receiving, by a computer system, a query for a particular graph database, the query identifying a plurality of vertices in the particular graph database; performing, by the computer system, a hash operation on two or more vertices of the plurality of vertices to generate corresponding hash values; using the corresponding hash values, the computer system to divide the query into a plurality of sub-queries, each sub-query corresponding to a subset of the plurality of vertices; and Subqueries of the plurality of subqueries are sent, by the computer system, to a plurality of database repositories of the particular graph database. 2 . The method of claim 1 , wherein the plurality of database repositories comprises a primary copy of the particular graph database and one or more redundant copies of the particular graph database.

3. The method according to claim 1, further comprising: receiving, by the computer system, an indication that a particular one of the plurality of database repositories is unavailable; and Vertices included in a subquery intended for the unavailable database repository are distributed, by the computer system, to remaining subqueries of the plurality of subqueries.

4. The method according to claim 1, further comprising: receiving, by the computer system, an indication that a particular one of the plurality of database repositories is unavailable; and The subquery intended for the unavailable database repository is reallocated, by the computer system, to an available one of the plurality of database repositories.

5. The method according to claim 1, further comprising: storing, by the computer system, copies of the specific graph database in different multiple database repositories; wherein the specific graph database is accessible to a first group of users classified as risky; and Wherein the replicated graph database is accessible to a second group of users classified as non-risk and is inaccessible to the first group.

6. The method according to claim 5, further comprising: receiving a first query from a user of the first group using a first process running on the computer system; and A second query is received from users of the second group using a second process running on the computer system, wherein the first process and the second process do not communicate with each other.

7. The method according to claim 5, wherein storing the specific graph database and the replicated graph database includes the computer system using the corresponding data storage engines of the specific graph database and the replicated graph database to send new records to the specific graph database and the replicated graph database at the same time.

8. The method according to claim 7, further comprising verifying the storage of the new record to the specific graph database and the replicated graph database by the following steps: reading respective copies of the new record from the specific graph database and the replicated graph database; and The corresponding copy is compared with a copy of the new record stored in the computer system.

9. A computer-readable non-transitory memory comprising instructions that, when executed by a computer system within a computer network, cause the computer system to perform operations comprising: Maintaining specific graph databases in multiple database repositories; receiving a query to the particular graph database, the query identifying a plurality of vertices in the particular graph database; Generating corresponding hash values ​​for a subset of the plurality of vertices; Distributing the plurality of vertices among a plurality of subqueries using the corresponding hash values; and A subquery of the plurality of subqueries is sent to a corresponding repository of the plurality of database repositories.

10. The computer-readable non-transitory memory of claim 9, wherein generating the corresponding hash value comprises performing a hash operation on user identification information associated with vertices in the subset of vertices.

11. The computer-readable non-transitory memory of claim 9, further comprising, in response to an indication that a particular one of the plurality of database repositories is unavailable, distributing vertices included in a sub-query intended for the unavailable database repository to remaining sub-queries of the plurality of sub-queries.

12. The computer-readable non-transitory memory of claim 9, further comprising, in response to an indication that a particular one of the plurality of database repositories is unavailable, reallocating a subquery intended for the unavailable database repository to an available one of the plurality of database repositories.

13. The computer-readable non-transitory memory according to claim 9, further comprising: storing copies of the specific graph database in different multiple database repositories; wherein the particular graph database is accessible to a first group of users; and The replicated graph database is accessible to a second group of users but not to the first group.

14. The computer-readable non-transitory memory of claim 13, further comprising: receiving a first query from a user of the first group using a first process running on the computer system; and A second query is received from the second group of users using a second process running on the computer system, wherein the first process and the second process are isolated from each other.

15. The computer-readable non-volatile memory of claim 13, wherein storing the specific graph database and the replicated graph database comprises using corresponding data storage engines of the specific graph database and the replicated graph database to simultaneously send new records to the specific graph database and the replicated graph database.

16. A system comprising: processor circuit; and a memory circuit comprising instructions that, when executed by the processor circuit, cause the system to perform operations comprising: receiving a query for the particular graph database, the query identifying a plurality of vertices of the particular graph database; Generating corresponding hash values ​​for a subset of the plurality of vertices; Distributing the plurality of vertices among a plurality of subqueries using the corresponding hash values; and A subquery of the plurality of subqueries is sent to a corresponding repository of the plurality of database repositories.

17. The system of claim 16, wherein the plurality of database repositories includes a primary copy of the particular graph database and one or more redundant copies of the particular graph database.

18. The system of claim 16, wherein generating the corresponding hash value comprises performing a hash operation on information related to electronic exchanges associated with vertices in the subset of vertices.

19. The system of claim 16, wherein the operations further comprise: receiving an indication that a particular one of the plurality of database repositories is unavailable; and Vertices included in the subquery intended for the unavailable database repository are distributed to remaining subqueries of the plurality of subqueries.

20. The system of claim 16, wherein the operations further comprise: storing copies of the specific graph database in different multiple database repositories; wherein the particular graph database is accessible to a first group of users; and The replicated graph database is accessible to a second group of users but not to the first group.

Images