Method, system and electronic device for querying service association

Abstract

This application discloses a method, system, and electronic device for querying business relevance, enabling efficient multi-hop relational queries. The method for querying business relevance includes: when a business event is detected in a message queue, parsing and standardizing the business event to obtain a processing result; mapping the processing result to a graph model based on preset graph data transformation rules; storing the graph model in a native graph database, where the graph model is assigned a group identifier; when a query request for the relevance of a target transaction is received, if the query request contains a target group identifier, querying the graph model in the native graph database based on the target group identifier to obtain the query result; and / or if the query request contains business feature conditions, performing a graph traversal query in the native graph database based on the business feature conditions to obtain the query result.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, system, and electronic device for querying business relevance. Background Technology

[0002] Currently, the industry commonly employs relational database-based query methods, such as those used in MySQL and Oracle, to identify and analyze transaction-related risks. Specifically, this involves storing business elements like transaction entities, key personnel, addresses, and counterparties as records in relational tables, and establishing foreign key constraints between different tables using entity identifiers. During correlation analysis, the system primarily uses complex SQL statements and multi-table joins to trace and discover direct relationships between different entities. For deeper, indirect correlation networks, recursive database queries or pre-written stored procedures are needed to simulate graph traversal through iterative loops, ultimately grouping related entities into the same group.

[0003] However, the aforementioned relational database-based technical approach suffers from a sharp increase in query response time when dealing with complex, multi-level relationships, especially when handling recursive join queries with more than three levels of complexity. This is because the number of JOIN operations increases exponentially and a large number of intermediate result sets are generated, which can easily lead to database query timeouts. Summary of the Invention

[0004] To address the aforementioned technical issues, this application provides a method, system, and electronic device for querying business relevance, enabling efficient multi-hop relational queries.

[0005] The first aspect of this application provides a method for querying business relevance, including:

[0006] When a business event is detected in the message queue, the business event is parsed and standardized to obtain a processing result. The business event includes at least one type of business event. Based on preset graph data conversion rules, the processing result is mapped to a graph model, which includes at least two vertices and at least one edge connecting the vertices. Each vertex corresponds to each entity in the business event, and the edge corresponds to the business association relationship between the entities in the business event. The graph model is stored in a native graph database, and the graph model in the native graph database is assigned a group identifier; When a query request for the relevance of a target transaction is received, if the query request contains a target group identifier, the graph model in the native graph database is queried based on the target group identifier to obtain the query result; and / or if the query request contains business feature conditions, a graph traversal query is performed in the native graph database based on the business feature conditions to obtain the query result; the query request includes a single-level query request and / or a multi-level jump query request, and the query result includes at least one of the following: the business event, entity set, and business relationship corresponding to the relevance of the target transaction.

[0007] Optionally, the step of parsing and standardizing the business events to obtain the processing results includes: Parse the JSON format information of the business event and convert the JSON format message into the corresponding data transmission object; Based on the business type identifier in the business event, the data transmission object is distributed to the corresponding event handler, so that the corresponding event handler can perform business compliance verification on the data transmission object, and convert the data transmission object that passes the verification into a standard business object with a unified field structure, and use the standard business object as the processing result. The event handler corresponds to the business type identifier.

[0008] Optionally, mapping the processing result to a graph model based on preset graph data transformation rules includes: The corresponding event handler is invoked to create or update the corresponding vertices and their attributes in the graph model based on the entities in the standard business object. The corresponding vertex types include at least one of the following: transaction entity, key person, address, IP address, and transaction counterparty. The corresponding event handler is invoked to create or update the edges connecting the corresponding vertices and the attributes of the edges, based on the business relationships between entities in the standard business object.

[0009] Optionally, the step of persistently storing the graph model in the native graph database includes: The vertices and edges are stored in a native graph database, which is an indexless adjacency storage structure. Using the indexing mechanism of the native graph database, an edge pointer list and an inbound edge pointer list are created based on the attributes of the vertices, and a source vertex pointer and a target vertex pointer are created based on the attributes of the edges.

[0010] Optionally, after storing the graph model in the native graph database, the method further includes: Based on a preset community detection algorithm, group identifiers are assigned to the graph models in the native graph database.

[0011] Optionally, the process of assigning group identifiers to the graph model in the native graph database based on a preset community detection algorithm includes: According to a preset period or a trigger command, the target vertices and target edges in the native graph database are read, and an independent community is set for each target vertex; Based on a preset community detection algorithm, the modularity gain after moving the target vertex to the community of an adjacent vertex is calculated, and the community with the largest modularity gain is updated as the community affiliation of the target vertex. Repeat the above calculation steps until the modularity gain no longer increases, and merge the same communities into supernodes to build a new graph with multiple supernodes; Based on the new graph, repeat the above calculation steps until the modularity gain no longer increases, and assign a unique corresponding group identifier to each new community.

[0012] Optionally, if the query request contains a target group identifier, then querying the graph model in the native graph database based on the target group identifier to obtain the query results includes: Query the native graph database for the first query vertex corresponding to the target group identifier; Traverse the first query vertex to obtain the corresponding first query edge; The first associated vertex is obtained based on the first query edge; Extract the entity set, business relationship, and business event corresponding to the first query vertex, the first query edge, and the first associated vertex to form the query result.

[0013] Optionally, if the query request includes business characteristic conditions, then a graph traversal query is performed in the native graph database based on the business characteristic conditions to obtain the query results, including: In the native graph database, the second query vertex is queried based on the entity attribute conditions in the business feature conditions; A graph traversal query statement is constructed based on the query request. The graph traversal query statement defines the path rules, directions, and number of hops for traversing the native graph database. Starting from the second query vertex, execute the graph traversal query statement to traverse the second query edge and the second associated vertex corresponding to the second query vertex; Extract the entity set, business relationship, and business event corresponding to the second query vertex, the second query edge, and the second associated vertex to form the query result.

[0014] A second aspect of this application provides a system for querying business relevance, including: The processing unit is used to parse and standardize the business event when a business event is detected in the message queue, and obtain the processing result. The business event includes at least one type of business event. The mapping unit is used to map the processing result into a graph model based on a preset graph data conversion rule. The graph model includes at least two vertices and at least one edge connecting the vertices. Each vertex corresponds to each entity in the business event, and the edge corresponds to the business association relationship between the entities in the business event. A storage unit is used to store the graph model in a native graph database, wherein the graph model in the native graph database is assigned a group identifier; The query unit is configured to, when receiving a query request for the relevance of a target transaction, if the query request contains a target group identifier, query the graph model in the native graph database according to the target group identifier to obtain the query result; and / or if the query request contains business feature conditions, perform a graph traversal query in the native graph database according to the business feature conditions to obtain the query result; the query request includes a single-level query request and / or a multi-level jump query request, and the query result includes at least one of the following: business events, entity sets, and business relationships corresponding to the relevance of the target transaction.

[0015] A third aspect of this application provides an electronic device, the electronic device comprising: Processor, memory, input / output units, and bus; The processor is connected to the memory, the input / output unit, and the bus; The memory stores a program, which the processor invokes to execute the first aspect and any optional method of querying business relevance.

[0016] The fourth aspect of this application provides a computer-readable storage medium on which a program is stored, which, when executed on a computer, performs the method of querying business relevance as described in the first aspect and any optional method of the first aspect.

[0017] As can be seen from the above technical solutions, this application has the following beneficial effects: This application maps standardized business events into a graph model containing vertices and edges, stores it in a native graph database, and then assigns group identifiers to the graph model. For single-level and multi-level jump query requests, it directly matches based on the target group identifier or performs native graph traversal queries based on business feature conditions. This eliminates the need to rely on multi-table JOIN operations to simulate relationships, reducing the generation of a large number of intermediate result sets, significantly shortening the response time of multi-level join queries, and solving the problem that the number of JOIN operations increases exponentially with the increase of the join level. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A schematic flowchart of an embodiment of the method for querying business relevance provided in this application; Figure 2 A flowchart illustrating another embodiment of the method for querying business relevance provided in this application; Figure 3 A flowchart illustrating another embodiment of the method for querying business relevance provided in this application; Figure 4 A flowchart illustrating another embodiment of the method for querying business relevance provided in this application; Figure 5 A flowchart illustrating another embodiment of the method for querying business relevance provided in this application; Figure 6 A flowchart illustrating another embodiment of the method for querying business relevance provided in this application; Figure 7 A schematic diagram of an embodiment of the system for querying business relevance provided in this application; Figure 8 A schematic diagram of an embodiment of the electronic device provided in this application. Detailed Implementation

[0020] This application provides a method, system, electronic device, and storage medium for querying business relationships, enabling high-efficiency multi-hop relational queries.

[0021] It should be noted that the method for querying business relevance provided in this application can be applied to terminals, systems, and servers. For example, a terminal can be a smartphone, computer, tablet, portable computer, or a desktop computer, etc. For ease of description, this application uses a system as the execution subject.

[0022] It should also be noted that the terms "first," "second," etc., in the specification and drawings are used to distinguish similar objects and are not necessarily used to describe a specific order, sequence, or importance.

[0023] Please see Figure 1 This application first provides an embodiment of a method for querying business relevance, which includes: Step S101: When a business event is detected in the message queue, the business event is parsed and standardized to obtain the processing result. The business event includes at least one type of business event. Step S102: Based on the preset graph data conversion rules, the processing result is mapped to a graph model. The graph model includes at least two vertices and at least one edge connecting the vertices. Each vertex corresponds to each entity in the business event, and the edge corresponds to the business relationship between the entities in the business event. Step S103: Store the graph model in the native graph database. The graph model in the native graph database is assigned a group identifier. Step S104: When a query request for the relevance of a target transaction is received, if the query request contains a target group identifier, the graph model in the native graph database is queried according to the target group identifier to obtain the query result; and / or if the query request contains business feature conditions, a graph traversal query is performed in the native graph database according to the business feature conditions to obtain the query result; the query request includes a single-level query request and / or a multi-level jump query request, and the query result includes at least one of the following: the business event, entity set, and business relationship corresponding to the relevance of the target transaction.

[0024] In step S101 of the embodiment, the system can continuously monitor the business message queue through the event receiving module. When an event of a business type, such as a network access event, login event, payment transaction event, or collection transaction event, is detected, the original JSON format data of the business event is parsed into the corresponding data transmission object. Redundant fields are removed and the field names and data types are standardized. Subsequently, the corresponding data transmission object is subjected to business compliance verification, and invalid events such as missing entity identifiers and abnormal data formats are filtered out. Finally, the data transmission object that passes the verification is converted into a standard business object with a unified field structure. This standard business object is the processing result required in the step.

[0025] In step S102 of the embodiment, the preset graph data transformation rules can be implemented through an event processor cluster. This event processor cluster contains multiple processors adapted to different business types. All processors are automatically registered through a dependency injection mechanism and stored according to business type. Specifically, based on the business type corresponding to the processing result, the corresponding processor is matched. The processor extracts entity information from the standard business object, maps each entity to a vertex of the graph model, and assigns attributes such as entity identifier and risk level to the vertex. At the same time, the business relationships between entities are extracted, mapped to edges connecting the corresponding vertices, and the edges are assigned attributes such as association frequency, transaction amount, and association time. Finally, a graph model containing at least two vertices and at least one edge is constructed.

[0026] In step S103 of the embodiment, the system can persistently store the graph model containing all vertices and edges constructed in step S102. That is, according to the storage specifications of the native graph database, the entity information carried by the vertices and the association information carried by the edges are completely written into the native graph database, ensuring that the vertex structure, edge connection relationship and various attribute information in the graph model are stably stored, realizing the long-term retention and subsequent query access of graph data. Among them, based on the connection relationship and association strength of the vertices in the graph model, closely related entity clusters are identified; a unique group identifier is assigned to each related cluster, and the group identifier is bound to all vertices in the corresponding cluster, completing the group identifier assignment of each vertex in the graph model, realizing the cluster classification of related entities.

[0027] In step S104 of the embodiment, when a query request for the relevance of a target transaction is received at a single level and / or multiple levels, the corresponding query is executed according to the information carried in the query request. Specifically, if the query request contains a target group identifier, the gateway constructs a query, retrieves all vertices with the group identifier and their associated edges and points in the graph database, and returns the business events, entity sets, and business relationships corresponding to the vertices and their associated edges and points. If the query request contains business feature conditions, a graph traversal query statement is used to perform a one-hop or multi-hop traversal starting from a specified vertex according to the conditions; the graph database executes this traversal, directly accesses the corresponding vertex through pointers, obtains the associated edges, accesses the associated points according to the direction and path of the associated edges, and returns the business events, entity sets, and business relationships corresponding to the vertices and their associated edges and points.

[0028] The method for querying business relationships in this application maps standardized business events into a graph model containing vertices and edges, stores it in a native graph database, and then assigns group identifiers to the graph model. For single-level and multi-level jump query requests, it directly matches based on the target group identifier or performs native graph traversal queries based on business feature conditions. This eliminates the need to rely on multi-table JOIN operations to simulate relationships, reduces the generation of a large number of intermediate result sets, significantly shortens the response time of multi-level join queries, and solves the problem that the number of JOIN operations increases exponentially with the increase of the join level.

[0029] Reference Figure 2 According to some embodiments of this application, the parsing and standardization of business events in step S101 to obtain processing results, and the mapping of the processing results to a graph model based on preset graph data conversion rules in step S102, may specifically include, but are not limited to, the following: Step S201: Parse the JSON format information of the business event and convert the JSON format message into the corresponding data transmission object; Step S202: Based on the business type identifier in the business event, the data transmission object is distributed to the corresponding event handler so that the corresponding event handler can perform business compliance verification on the data transmission object and convert the data transmission object that passes the verification into a standard business object with a unified field structure. The standard business object is used as the processing result, and the event handler corresponds to the business type identifier. Step S203: Invoke the corresponding event handler, and create or update the corresponding vertices and their attributes in the graph model based on the entities in the standard business object. The corresponding vertex types include at least one of the following: transaction entity, key person, address, IP address, and transaction counterparty. Step S204: Invoke the corresponding event handler and create or update the edges connecting the corresponding vertices and their attributes based on the business relationships between entities in the standard business object.

[0030] In steps S201 to S204 of the embodiment, the JSON format information of the business event is first parsed, and the JSON format message is converted into a corresponding data transmission object. Then, according to the business type identifier in the business event, the data transmission object is distributed to the corresponding event handler so that the corresponding event handler can perform business compliance verification on the data transmission object and convert the data transmission object that passes the verification into a standard business object with a unified field structure. The standard business object is used as the processing result, and the event handler corresponds to the business type identifier. Next, the corresponding event handler is called to create or update the corresponding vertices and their attributes in the graph model according to the entities in the standard business object. The corresponding vertex types include at least one of the following: transaction entity, key person, address, IP address, and transaction counterparty. Then, the corresponding event handler is called to create or update the edges connecting the corresponding vertices and their attributes according to the business relationship between the entities in the standard business object. The JSON format information corresponding to the business event is obtained, and the JSON data is structured and parsed according to the preset parsing rules to extract the core business fields contained therein, such as entity identifier, association information, and event attributes. Then, according to the type of business event, the parsed fields are mapped to the predefined corresponding data transmission objects to ensure that each valid field in the JSON format corresponds one-to-one with the attribute of the data transmission object. The business type identifier is extracted from the business event. Based on this identifier, the corresponding event handler is matched in the pre-set set of event handlers. After the data transmission object is distributed to the matched event handler, the handler first performs business compliance verification on the fields in the data transmission object, checking the field integrity, data format validity, and compliance with business rules, and filtering out data that does not meet the verification requirements. For data transmission objects that pass the verification, the handler converts them into standard business objects according to a unified field structure specification. The standard business object is the processing result for subsequent processing.

[0031] Then, the corresponding event handlers are called to extract various entity information from the standard business objects, such as the ID and name of the transaction entity, the ID number and name of key personnel, and detailed information about their addresses. Based on the entity type, the graph model is checked to see if a vertex corresponding to that entity already exists. If no vertex exists, a new vertex of the corresponding type is created, and the entity's attribute information is assigned to the vertex. If a vertex already exists, its attributes are updated according to the latest information in the standard business objects. Next, the business relationships between entities in the standard business objects are analyzed, such as the transaction relationship between a transaction entity and its counterparty, and the login relationship between a transaction entity and its IP address. Based on these relationships, the graph model is checked to see if an edge connecting the corresponding vertex already exists. If no edge exists, an edge is created, and the relationship attributes are assigned to the edge, such as transaction amount, login count, and association time. If an edge already exists, its attributes are updated according to the latest association information in the standard business objects.

[0032] In this embodiment, the system first parses unstructured JSON-formatted business events into structured data transmission objects, unifying the format of the original data. Then, it distributes the data to the corresponding event handlers based on business type identifiers, achieving differentiated processing for events of different business types. Furthermore, based on standard business objects, it accurately creates or updates vertices and edges of corresponding types, as well as their attributes, ensuring that the graph model can completely and in real-time map entities and relationships in the business scenario. This replaces the tedious operation of manually maintaining multiple table structures and foreign key constraints in traditional relational databases, significantly improving the efficiency and accuracy of query processing.

[0033] Reference Figure 3 According to some embodiments of this application, storing the graph model to the native graph database in step S103 may specifically include, but is not limited to, the following: Step S301: Store the vertices and edges in the native graph database, which is an indexless adjacency storage structure; Step S302: Using the indexing mechanism of the native graph database, create an edge pointer list and an incoming edge pointer list based on the vertex attributes, and create a source vertex pointer and a target vertex pointer based on the edge attributes.

[0034] In steps S301 to S302 of this embodiment, vertices and edges are first stored in a native graph database, which is an indexless adjacency storage structure. Then, using the indexing mechanism of the native graph database, an edge pointer list and an incoming edge pointer list are created based on the vertex attributes, and a source vertex pointer and a target vertex pointer are created based on the edge attributes. The created or updated vertices and edges are completely written into the native graph database according to its storage specifications. This native graph database uses an indexless adjacency storage structure, eliminating the need to rely on traditional index tables to maintain the association between vertices and edges. It should be noted that the complete attributes of vertices and the core information of edges are directly retained during the storage process. Next, using the built-in indexing mechanism of the native graph database, based on the vertex attributes, a list of outgoing edge pointers and a list of incoming edge pointers are generated for each vertex. The list of outgoing edge pointers records the physical pointers of all edges from this vertex to other vertices, and the list of incoming edge pointers records the physical pointers of all edges from other vertices to this vertex. At the same time, based on the edge attributes, a source vertex pointer and a target vertex pointer are created for each edge. The source vertex pointer points to the physical address of the starting vertex of the edge, and the target vertex pointer points to the physical address of the ending vertex of the edge, thereby establishing a direct pointer association between vertices and edges.

[0035] In this embodiment, the system stores vertices and edges in a native graph database that uses an index-free adjacency storage structure, replacing the traditional relational database storage mode based on data tables and foreign key constraints. This significantly reduces query redundancy at the storage level. Furthermore, by utilizing the indexing mechanism of the native graph database, it creates an edge pointer list and an incoming edge pointer list for vertices, and a source vertex pointer and a target vertex pointer for edges. This allows vertices and edges to be directly associated through physical pointers. When traversing the association, there is no need to use index retrieval or table join operations as in traditional databases. Adjacent vertices and associated edges can be quickly located directly through pointers, greatly shortening the data access path and significantly improving the response speed of single-level and multi-level jump queries.

[0036] Reference Figure 4 According to some embodiments of this application, after storing the graph model in the native graph database, the method further includes assigning group identifiers to the graph models in the native graph database based on a preset community detection algorithm. Specific steps described above may include, but are not limited to, the following: Step S401: Read the target vertices and target edges from the native graph database according to the preset period or according to the trigger command, and set an independent community for each target vertex; Step S402: Based on the preset community detection algorithm, calculate the modularity gain after moving the target vertex to the community of the adjacent vertex, and update the community with the largest modularity gain as the community affiliation of the target vertex. Step S403: Repeat the above calculation steps until the modularity gain no longer increases, and merge the same communities into super nodes to build a new graph with multiple super nodes; Step S404: Based on the new graph, repeat the above calculation steps until the modularity gain no longer increases, and assign a unique corresponding group identifier to each new community.

[0037] In steps S401 to S404 of the embodiment, the target vertices and target edges in the native graph database are first read according to a preset period or a trigger command, and an independent community is set for each target vertex. Then, based on a preset community discovery algorithm, the modularity gain after moving the target vertex to the community of an adjacent vertex is calculated, and the community with the largest modularity gain is updated as the community affiliation of the target vertex. The above calculation steps are repeated until the modularity gain no longer increases, and the same communities are merged into super nodes, and a new graph is constructed with multiple super nodes. Based on the new graph, the above calculation steps are repeated until the modularity gain no longer increases, and a unique corresponding group identifier is assigned to each new community. The process is automatically triggered according to a preset time period or executed after receiving a trigger command from the staff. Through the query interface of the native graph database, all target vertices and target edges stored in the database are read, and the complete attribute and association data of the vertices and edges are obtained. Then, an independent community is set for each target vertex to ensure that the community affiliation of each vertex is unique and does not overlap in the initial state.

[0038] The pre-defined community discovery algorithm, which is a modularity optimization-based algorithm, is invoked to traverse each target vertex. Specifically, it identifies all neighboring vertices of the target vertex and obtains the community information to which each neighboring vertex currently belongs; for each neighboring vertex's community, it calculates the overall network modularity gain after moving the current target vertex to that community; it compares the modularity gain values ​​of all possible communities, selects the community with the largest modularity gain, and updates the target vertex's new community affiliation to that community, completing a single community affiliation optimization.

[0039] Repeatedly perform modularity gain calculation and community affiliation update operations, traversing all target vertices round by round, continuously optimizing the community affiliation of each vertex until no community move operation that can improve the overall modularity is found after traversing all vertices, at which point the current round of optimization stops; merge all target vertices belonging to the same community after the current round of optimization into a super node, retain the association relationships within the community and transform them into association relationships between super nodes, and construct a new graph based on all super nodes and the association relationships between nodes.

[0040] Based on the newly constructed graph, each super node is traversed, and the modularity gain after it moves to the community of the adjacent super node is calculated. The community affiliation is updated until the modularity gain no longer increases, thus completing the community optimization at the new graph level. When the modularity of the new graph is stable and no longer increases, all iterative calculations are stopped, and a unique group identifier is assigned to each independent community that is finally formed, ensuring that the group identifiers of different communities are not repeated, and that all original target vertices within the same community are associated with the group identifier.

[0041] In this embodiment, the system uses optimization logic based on modularity gain. It calculates the modularity gain after a vertex moves to an adjacent community and selects the optimal community. This process is repeated multiple times until the modularity gain no longer increases, ensuring that community partitioning accurately identifies closely related groups of transaction entities. Compared to traditional methods that group entities based solely on simple connectivity, this significantly improves the accuracy of identifying related groups. Furthermore, merging identical communities into supernodes to construct a new graph and iterating again effectively reduces computational complexity for large-scale graph data, improving the overall efficiency of community discovery. Simultaneously, assigning a unique group identifier to the final stable community ensures the real-time performance and accuracy of subsequent queries on transaction relationships.

[0042] Reference Figure 5 According to some embodiments of this application, if the query request contains a target group identifier, then the process of assigning a group identifier to the graph model based on a preset community detection algorithm in step S105 may specifically include, but is not limited to, the following: Step S501: Query the first query vertex corresponding to the target group identifier in the native graph database; Step S502: Traverse the first query vertex and obtain the corresponding first query edge; Step S503: Obtain the first associated vertex based on the first query edge; Step S504: Extract the entity set, business relationship and business event corresponding to the first query vertex, the first query edge and the first associated vertex to form the query result.

[0043] In steps S501 to S504 of the embodiment, firstly, the first query vertex corresponding to the target group identifier is queried in the native graph database; then, the first query vertex is traversed to obtain the corresponding first query edge; next, the first associated vertex is obtained based on the first query edge; finally, the entity set, business relationship, and business event corresponding to the first query vertex, the first query edge, and the first associated vertex are extracted to form the query result. Using the received target group identifier as the precise retrieval condition, the query interface of the native graph database is called to filter all vertices in the database whose "group identifier" field value in the vertex attribute is completely consistent with the target group identifier, i.e., the first query vertex; at the same time, all attribute information of the first query vertex is read and stored, including vertex type and entity core identifier, etc.

[0044] Each first query vertex is traversed one by one. Based on the indexless adjacency storage structure of the native graph database, the list of outgoing edge pointers and the list of incoming edge pointers associated with the first query vertex are directly read. All edges with the first query vertex as the source vertex or the target vertex are located through the pointer list. These edges are uniformly regarded as the corresponding first query edges, and the attributes of each first query edge are extracted.

[0045] For each first query edge, parse the corresponding source vertex pointer and target vertex pointer: if the source vertex pointer of the first query edge points to the first query vertex, then the vertex pointed to by the target vertex pointer of the edge is determined as the first associated vertex; if the target vertex pointer of the first query edge points to the first query vertex, then the vertex pointed to by the source vertex pointer of the edge is determined as the first associated vertex; process all first query edges one by one, summarize to obtain all first associated vertices, and simultaneously obtain the attribute information of these vertices.

[0046] Finally, extract the entity information corresponding to the first query vertex and the first associated vertex, and summarize them to form a complete entity set; extract the business association relationship corresponding to the first query edge; retrieve the original business events corresponding to the above vertices and edges; aggregate and organize the entity set, business association relationship, and business events according to the preset structured format, and finally form a complete query result.

[0047] In this embodiment, the system uses a preset target group identifier as the retrieval basis to directly and accurately locate the first query vertex in the native graph database, shortening the query entry path of the associated group and improving the accuracy and efficiency of the query. Furthermore, relying on the index-free adjacency storage and pointer association mechanism of the native graph database, the corresponding first query edge can be quickly obtained by traversing the first query vertex, and then the first associated vertex can be located directly through the pointer of the edge, without the need for multi-table JOIN or multiple index lookups, which significantly improves the speed of tracing the association relationship.

[0048] Reference Figure 6 According to some embodiments of this application, if the query request contains business characteristic conditions, then the assignment of group identifiers to the graph model based on a preset community detection algorithm in step S105 may specifically include, but is not limited to, the following: Step S601: In the native graph database, query the second query vertex based on the entity attribute conditions in the business feature conditions; Step S602: Construct a graph traversal query statement based on the query request. The graph traversal query statement defines the path rules, direction, and number of hops for traversing the original graph database. Step S603: Starting from the second query vertex, execute the graph traversal query statement to traverse the second query edge and the second associated vertex corresponding to the second query vertex; Step S604: Extract the entity set, business relationship and business event corresponding to the second query vertex, the second query edge and the second associated vertex to form the query result.

[0049] In steps S601 to S604 of the embodiment, firstly, the second query vertex is queried in the native graph database based on the entity attribute conditions in the business feature conditions; then, a graph traversal query statement is constructed according to the query request, defining the path rules, direction, and hop count for traversing the native graph database; next, starting from the second query vertex, the graph traversal query statement is executed to traverse the second query edge and the second associated vertex corresponding to the second query vertex; finally, the entity set, business association relationship, and business event corresponding to the second query vertex, the second query edge, and the second associated vertex are extracted to form the query result. The business feature conditions in the query request are parsed, and the entity attribute conditions are extracted; using these entity attribute conditions as the retrieval basis, the query interface of the native graph database is called to filter out all vertices in the database whose vertex attributes completely match the entity attribute conditions. These vertices are defined as the second query vertices, and all attribute information such as the type and core identifier of the second query vertices is retained as the starting node for subsequent graph traversal.

[0050] Based on the type of query request and the relational requirements in the business characteristics, construct a graph traversal query statement that conforms to the syntax of the native graph database. In this query statement, explicitly define the traversal path rules, traversal direction, and traversal jump number to ensure that the query statement accurately matches the traversal requirements of the query request.

[0051] Using the second query vertex as the starting node of the graph traversal, the graph traversal query statement is executed in the native graph database. According to the path rules, direction and hop count defined in the statement, all edges associated with each second query vertex are traversed in sequence, i.e., the second query edges. The source vertex pointer and target vertex pointer of the edge are used to locate all vertices that are associated with the second query vertex, i.e., the second associated vertices. At the same time, the attributes of the second query edges and the complete information of the second associated vertices are recorded.

[0052] Finally, all data of the second query vertex, the second query edge, and the second associated vertex are summarized; the entity information corresponding to these vertices is extracted and integrated into an entity set; the business associations corresponding to the second query edges are extracted, and the original business events corresponding to all vertices and edges are retrieved; the entity set, business associations, and business events are integrated according to a preset structured format to finally form a complete query result.

[0053] In this embodiment, the system accurately queries the second query vertex based on the entity attribute conditions in the business characteristic conditions, directly locking the starting node that meets the requirements, reducing the amount of invalid data processing, and improving the accuracy of the query entry point; it customizes the graph traversal statement according to the query request, clarifying the traversal path rules, direction, and number of jumps. Compared with the cumbersome mode of writing complex SQL recursive statements or stored procedures in traditional relational databases, it significantly improves the flexibility and adaptability of the query, and can quickly respond to diverse association query needs; relying on the index-free adjacency storage and pointer association mechanism of the native graph database, it performs traversal starting from the second query vertex, which can quickly locate the second query edge and the second associated vertex without relying on multi-table JOIN or multiple index lookups, ensuring query efficiency.

[0054] The above embodiments illustrate the method for querying business relevance provided in this application. The following describes the system, electronic device, and storage medium for querying business relevance provided in this application: Please see Figure 7 This application provides an embodiment of a system for querying business relevance, the system comprising: The processing unit 701 is used to parse and standardize the business event when a business event is detected in the message queue, and obtain the processing result. The business event includes at least one type of business event. The mapping unit 702 is used to map the processing result into a graph model based on a preset graph data conversion rule. The graph model includes at least two vertices and at least one edge connecting the vertices. Each vertex corresponds to each entity in the business event, and the edge corresponds to the business relationship between the entities in the business event. Storage unit 703 is used to store the graph model to the native graph database, where the graph model is assigned a group identifier; The query unit 704 is configured to, when receiving a query request for the relevance of a target transaction, if the query request contains a target group identifier, query the graph model in the native graph database based on the target group identifier to obtain the query result; and / or if the query request contains business feature conditions, perform a graph traversal query in the native graph database based on the business feature conditions to obtain the query result; the query request includes a single-level query request and / or a multi-level jump query request, and the query result includes at least one of the following: the business event, entity set, and business relationship corresponding to the relevance of the target transaction.

[0055] Optionally, the processing unit 701 is specifically used for: Parse the JSON format information of business events and convert the JSON format message into the corresponding data transmission object; Based on the business type identifier in the business event, the data transmission object is distributed to the corresponding event handler, so that the corresponding event handler can perform business compliance verification on the data transmission object, and convert the data transmission object that passes the verification into a standard business object with a unified field structure. The standard business object is used as the processing result, and the event handler corresponds to the business type identifier.

[0056] Optionally, the mapping unit 702 is specifically used for: Invoke the corresponding event handler to create or update the corresponding vertices and their attributes in the graph model based on the entities in the standard business object. The corresponding vertex types include at least one of the following: transaction entity, key person, address, IP address, and transaction counterparty. Invoke the corresponding event handler and, based on the business relationships between entities in the standard business object, create or update the edges connecting the corresponding vertices and their attributes.

[0057] Optionally, storage unit 703 is specifically used for: Vertices and edges are stored in a native graph database, which is an indexless adjacency storage structure. By utilizing the indexing mechanism of the native graph database, a list of edge pointers and a list of incoming edge pointers are created based on the attributes of the vertices, and a source vertex pointer and a destination vertex pointer are created based on the attributes of the edges.

[0058] Optionally, following storage unit 703, the following may also be included: The allocation unit 705 is used to allocate group identifiers to the graph model in the native graph database based on a preset community detection algorithm.

[0059] Optionally, the allocation unit 705 is specifically used for: According to a preset period or a trigger command, read the target vertices and target edges from the native graph database, and set up an independent community for each target vertex; Based on the preset community detection algorithm, the modularity gain after moving the target vertex to the community of the adjacent vertex is calculated, and the community with the largest modularity gain is updated as the community affiliation of the target vertex. Repeat the above calculation steps until the modularity gain no longer increases, and merge the same communities into supernodes to build a new graph with multiple supernodes; Based on the new graph, repeat the above calculation steps until the modularity gain no longer increases, and assign a unique corresponding group identifier to each new community.

[0060] Optionally, query unit 704 is specifically used for: Search the native graph database for the first vertex corresponding to the target group identifier; Traverse the first query vertex to obtain the corresponding first query edge; The first associated vertex is obtained based on the first query edge; Extract the entity set, business relationship, and business event corresponding to the first query vertex, the first query edge, and the first associated vertex to form the query result.

[0061] Optionally, query unit 704 is specifically used for: In the native graph database, the second query vertex is queried based on the entity attribute conditions in the business feature conditions; Construct a graph traversal query statement based on the query request. The graph traversal query statement defines the path rules, directions, and number of hops for traversing the native graph database. Starting from the second query vertex, execute the graph traversal query statement to traverse the second query edge and the second associated vertex corresponding to the second query vertex; Extract the entity set, business relationship, and business event corresponding to the second query vertex, the second query edge, and the second associated vertex to form the query result.

[0062] Please see Figure 8 This application also provides an electronic device, including: Processor 801, memory 802, input / output unit 803, bus 804; The processor 801 is connected to the memory 802, the input / output unit 803, and the bus 804; The memory 802 stores a program, and the processor 801 calls the program to execute it, such as... Figures 1 to 6 The method for querying business relevance as shown in any of the embodiments.

[0063] This application also relates to a computer-readable storage medium on which a program is stored, which, when run on a computer, causes the computer to perform actions such as... Figures 1 to 6 The method for querying business relevance as shown in any of the embodiments.

[0064] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0065] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0066] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0067] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0068] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for querying business relevance, characterized in that, The method includes: When a business event is detected in the message queue, the business event is parsed and standardized to obtain a processing result. The business event includes at least one type of business event. Based on preset graph data conversion rules, the processing result is mapped to a graph model, which includes at least two vertices and at least one edge connecting the vertices. Each vertex corresponds to each entity in the business event, and the edge corresponds to the business relationship between the entities in the business event. The graph model is stored in a native graph database, and the graph model in the native graph database is assigned a group identifier; When a query request for the relevance of a target transaction is received, if the query request contains a target group identifier, the graph model in the native graph database is queried based on the target group identifier to obtain the query result; and / or if the query request contains business feature conditions, a graph traversal query is performed in the native graph database based on the business feature conditions to obtain the query result; the query request includes a single-level query request and / or a multi-level jump query request, and the query result includes at least one of the following: the business event, entity set, and business relationship corresponding to the relevance of the target transaction.

2. The method according to claim 1, characterized in that, The process of parsing and standardizing the business events to obtain the processing results includes: Parse the JSON format information of the business event and convert the JSON format message into the corresponding data transmission object; Based on the business type identifier in the business event, the data transmission object is distributed to the corresponding event handler, so that the corresponding event handler can perform business compliance verification on the data transmission object, and convert the data transmission object that passes the verification into a standard business object with a unified field structure, and use the standard business object as the processing result. The event handler corresponds to the business type identifier.

3. The method according to claim 2, characterized in that, The process of mapping the processing result to a graph model based on preset graph data transformation rules includes: The corresponding event handler is invoked to create or update the corresponding vertices and their attributes in the graph model based on the entities in the standard business object. The corresponding vertex types include at least one of the following: transaction entity, key person, address, IP address, and transaction counterparty. The corresponding event handler is invoked to create or update the edges connecting the corresponding vertices and the attributes of the edges, based on the business relationships between entities in the standard business object.

4. The method according to claim 1, characterized in that, The step of storing the graph model into the native graph database includes: The vertices and edges are stored in a native graph database, which is an indexless adjacency storage structure. Using the indexing mechanism of the native graph database, an edge pointer list and an inbound edge pointer list are created based on the attributes of the vertices, and a source vertex pointer and a target vertex pointer are created based on the attributes of the edges.

5. The method according to claim 1, characterized in that, After storing the graph model in the native graph database, the method further includes: Based on a preset community detection algorithm, group identifiers are assigned to the graph models in the native graph database.

6. The method according to claim 5, characterized in that, The method for assigning group identifiers to the graph models in the native graph database based on the preset community detection algorithm includes: According to a preset period or a trigger command, the target vertices and target edges in the native graph database are read, and an independent community is set for each target vertex; Based on a preset community detection algorithm, the modularity gain after moving the target vertex to the community of an adjacent vertex is calculated, and the community with the largest modularity gain is updated as the community affiliation of the target vertex. Repeat the above calculation steps until the modularity gain no longer increases, and merge the same communities into supernodes to build a new graph with multiple supernodes; Based on the new graph, repeat the above calculation steps until the modularity gain no longer increases, and assign a unique corresponding group identifier to each new community.

7. The method according to any one of claims 1-6, characterized in that, If the query request contains a target group identifier, then the graph model in the native graph database is queried based on the target group identifier to obtain the query results, including: Query the native graph database for the first query vertex corresponding to the target group identifier; Traverse the first query vertex to obtain the corresponding first query edge; The first associated vertex is obtained based on the first query edge; Extract the entity set, business relationship, and business event corresponding to the first query vertex, the first query edge, and the first associated vertex to form the query result.

8. The method according to any one of claims 1-6, characterized in that, If the query request contains business characteristic conditions, then a graph traversal query is performed in the native graph database based on the business characteristic conditions to obtain the query results, including: In the native graph database, the second query vertex is queried based on the entity attribute conditions in the business feature conditions; A graph traversal query statement is constructed based on the query request. The graph traversal query statement defines the path rules, directions, and number of hops for traversing the native graph database. Starting from the second query vertex, execute the graph traversal query statement to traverse the second query edge and the second associated vertex corresponding to the second query vertex; Extract the entity set, business relationship, and business event corresponding to the second query vertex, the second query edge, and the second associated vertex to form the query result.

9. A system for querying business relevance, characterized in that, The system includes: The processing unit is used to parse and standardize the business event when a business event is detected in the message queue, and obtain the processing result. The business event includes at least one type of business event. The mapping unit is used to map the processing result into a graph model based on a preset graph data conversion rule. The graph model includes at least two vertices and at least one edge connecting the vertices. Each vertex corresponds to each entity in the business event, and the edge corresponds to the business association relationship between the entities in the business event. A storage unit is used to store the graph model in a native graph database, wherein the graph model in the native graph database is assigned a group identifier; The query unit is configured to, when receiving a query request for the relevance of a target transaction, if the query request contains a target group identifier, query the graph model in the native graph database according to the target group identifier to obtain the query result; and / or if the query request contains business feature conditions, perform a graph traversal query in the native graph database according to the business feature conditions to obtain the query result; the query request includes a single-level query request and / or a multi-level jump query request, and the query result includes at least one of the following: business events, entity sets, and business relationships corresponding to the relevance of the target transaction.

10. An electronic device, characterized in that, The electronic device includes: Processor, memory, input / output units, and bus; The processor is connected to the memory, the input / output unit, and the bus; The memory stores a program, which the processor calls to execute the method for querying business relevance as described in any one of claims 1 to 8.

Images