Graph database index configuration method, apparatus and device, and readable storage medium

Abstract

The invention relates to the technical field of data processing, and discloses a graph database index configuration method, device and equipment and a readable storage medium. According to the graph database index configuration method, index configuration parameters input by a user are obtained in a visual configuration interface; generating a graph query condition according to the index configuration parameter, performing path identification on the graph query condition, extracting path characteristics, and determining an index template corresponding to the index configuration parameter based on the path characteristics; generating an index query statement executed in the graph database based on the graph query condition and the index template; and executing the index query statement in the graph database, and performing aggregation processing on the query result to obtain an index result. According to the method and the device, an automatic processing flow from index configuration to query execution is realized, and the flexibility and standardization degree of index configuration are improved. Compared with a traditional mode, the method has the advantages that the development threshold is lowered, the online period is shortened, and the maintainability and expansibility of index calculation are improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a graph database index configuration method, apparatus, device, and readable storage medium. Background Technology

[0002] With the rapid growth of enterprise data assets, graph databases are widely used in scenarios such as relational analysis, risk penetration, and knowledge graphs. Currently, various indicators are typically implemented by developers through writing graph query statements in the system code. Each new or modified related indicator requires code development, testing, and deployment. Because indicator definitions involve multi-dimensional elements such as nodes, edges, attributes, and paths, the development process is complex, the version release cycle is long, and it is difficult to support the business needs for flexible querying and rapid verification.

[0003] However, in the existing technology system, each development of related metrics requires system modifications by R&D personnel. Business personnel cannot independently define and publish metrics through configuration, resulting in excessively long collaboration cycles between R&D and business. On the other hand, different business scenarios have varying requirements for metric paths, aggregation logic, and template structures. Existing systems lack a unified metric configuration and reuse mechanism, making it impossible to achieve template-based modeling and visual configuration. This creates a technical contradiction between low development efficiency, long deployment cycles, and slow business response. Summary of the Invention

[0004] In view of this, embodiments of this application provide a graph database indicator configuration method, apparatus, device, and readable storage medium, which can effectively solve the problems in the prior art such as the need for system code modification to configure related indicators and the inability of business personnel to configure indicators independently.

[0005] In a first aspect, embodiments of this application provide a graph database metric configuration method, including: Obtain the indicator configuration parameters input by the user in the visual configuration interface; Graph query conditions are generated based on the indicator configuration parameters. Path identification is performed on the graph query conditions, path features are extracted, and an indicator template corresponding to the indicator configuration parameters is determined based on the path features. Generate an indicator query statement for execution in the graph database based on the graph query conditions and the indicator template; The indicator query statement is executed in the graph database to obtain the query results, which are then aggregated to obtain the indicator results.

[0006] In some embodiments, the method further includes: In response to the change release operation of the indicator configuration parameters, the updated indicator configuration parameters are written to the database, and the updated indicator configuration parameters are reloaded through a message queue or scheduled task for updating. The message queue is used to send an update message to a preset topic after the indicator configuration parameters are updated, and to continuously monitor the preset topic through a listening module. When the update message is received, the indicator configuration parameters are read from the database to perform the update. The scheduled task is used to periodically read the indicator configuration parameters from the database to synchronize the latest configuration.

[0007] In some embodiments, obtaining the indicator configuration parameters input by the user in the visual configuration interface includes: Receive the indicator identifier, node field, and edge field parameters input by the user in the visual configuration interface; Parse the node field and edge field parameters to generate the corresponding field mapping data structure; The indicator identifier is combined with the field mapping data structure to form the structured indicator configuration parameters.

[0008] In some embodiments, the step of generating graph query conditions based on the indicator configuration parameters, identifying paths in the graph query conditions, extracting path features, and determining an indicator template corresponding to the indicator configuration parameters based on the path features includes: Based on the starting node, target node, and type and attribute parameters of the connecting edges defined in the indicator configuration parameters, the attribute conditions corresponding to each node and edge are generated sequentially using a stack structure. The attribute conditions are connected according to logical operators to form graph query conditions that cover multi-hop paths; Path identification is performed on the graph query conditions, and path features corresponding to the graph query conditions are extracted; Based on the path characteristics, an indicator template corresponding to the indicator configuration parameters is determined.

[0009] In some embodiments, generating an indicator query statement for execution in a graph database based on the graph query conditions and the indicator template includes: Obtain the graph query language statement template pre-associated with the indicator template; the graph query language is a declarative query language suitable for graph databases; The starting node identifier, edge identifier, and ending node identifier are obtained by parsing the graph query conditions. Replace each identifier and the corresponding attribute condition in the graph query condition with the corresponding placeholder in the graph query language statement template in sequence to generate the index query statement.

[0010] In some embodiments, executing the indicator query statement in the graph database, obtaining the query results, and performing aggregation processing to obtain indicator results includes: Run the indicator query statement in the graph database to obtain the query result set; Based on the preset aggregation type in the indicator template, perform aggregation calculations on the target fields in the query result set to generate the indicator results.

[0011] In some embodiments, determining the indicator template corresponding to the indicator configuration parameters based on the path characteristics includes: When the path feature contains an edge that connects two nodes, the indicator template is determined to be a first-degree association template; When the path feature contains two edges and connects three nodes, the indicator template is determined to be a second-degree association template.

[0012] Secondly, embodiments of this application provide a graph database index configuration device, comprising: The data acquisition module is used to acquire the indicator configuration parameters input by the user in the visual configuration interface; The data processing module is used to generate graph query conditions according to the indicator configuration parameters, identify the path of the graph query conditions, extract path features, and determine the indicator template corresponding to the indicator configuration parameters based on the path features. The statement generation module is used to generate an indicator query statement for execution in the graph database based on the graph query conditions and the indicator template. The aggregation processing module is used to execute the indicator query statement in the graph database, obtain the query results, and perform aggregation processing to obtain the indicator results.

[0013] Thirdly, embodiments of this application provide a terminal device, the terminal device including a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the graph database index configuration method of the first aspect described above.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium, wherein when the computer program is executed on a processor, it implements the graph database index configuration method of the first aspect described above.

[0015] The embodiments of this application have the following beneficial effects: This application obtains the indicator configuration parameters input by the user through a visual configuration interface; generates graph query conditions based on the indicator configuration parameters; identifies the path of the graph query conditions, extracts path features, and determines the corresponding indicator template based on the path features; generates indicator query statements for execution in the graph database based on the graph query conditions and indicator templates; executes the indicator query statements in the graph database; and aggregates the query results to obtain the indicator results. The entire process realizes the full-link from indicator configuration input and query condition construction to statement execution and result aggregation. Among them, the indicator parameter configuration is realized through a visual interface, allowing business personnel to directly complete indicator definition and modification without system code modification, significantly shortening the indicator development and deployment cycle; the templated statement generation mechanism can automatically match template types for different associated paths, improving the efficiency and accuracy of statement generation; finally, the aggregation calculation process supports multiple result processing methods, realizing unified output and flexible expansion of indicator results, and improving the overall flexibility, maintainability, and system response speed of indicator configuration. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This paper illustrates a flowchart of a database index configuration method according to an embodiment of the present application. Figure 2 Another flowchart of the database index configuration method in this application is shown; Figure 3 This illustration shows a structural diagram of a database index configuration method according to an embodiment of this application. Detailed Implementation

[0018] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0019] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0020] In the following text, the terms "comprising," "having," and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as primarily excluding the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more combinations thereof. Furthermore, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0021] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0022] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0023] Considering the problems in existing technologies, such as the need to modify system code for related indicators and the inability of business personnel to configure indicators independently, this application proposes a graph database indicator configuration method. Through a visual configuration interface, templated statement generation, and aggregation calculation mechanism, the configuration and automation of related indicators are realized.

[0024] The following examples illustrate the method for configuring metrics in this graph database.

[0025] Figure 1 A flowchart illustrating a graph database metric configuration method according to an embodiment of this application is shown. Exemplarily, the graph database metric configuration method includes the following steps: Step S100: Obtain the indicator configuration parameters input by the user in the visual configuration interface.

[0026] The visual configuration interface refers to the interactive interface used for defining and editing metrics, supporting form-based input and dynamic concatenation. This interface allows users to interactively enter metric configuration parameters, thereby generating structured metric configuration data. Metric configuration parameters are the collection of all structured input information required to fully define a graph database-related metric. For example, metric configuration parameters include, but are not limited to, metric identifiers, node field parameters, edge field parameters, and their combined logic. The configured parameters serve as the intermediate data carrier between user operations and the automatic generation of backend query statements, enabling business personnel to create, verify, deploy, and save metrics without relying on code development, thus decoupling the configuration layer from the execution layer. In other words, it can transform the content and business requirements entered into this interface into structured configuration data that can be processed by a computer, providing a source for the generation of subsequent graph query statements (such as NGQL).

[0027] In an optional embodiment, step S100 includes the following sub-steps: S101 receives the indicator identifier, node field, and edge field parameters entered by the user in the visual configuration interface.

[0028] The indicator identifier is used to uniquely identify the indicator (such as indicator name, ID, or code); the node field parameters are used to describe the entity type and its attribute conditions in the graph (such as the labels and filtering conditions of the starting node, intermediate node, and ending node); the edge field parameters are used to describe the relationship type, direction, and attribute constraints (such as the conditions for investment edge and appointment edge). For example, users can enter "enterprise equity penetration rate" as the indicator identifier in the configuration interface, and select the node fields "enterprise number" and "shareholder number", as well as the edge field parameter "investment ratio ≥ 50%". The system will package these input items to form the initial configuration data for the indicator.

[0029] S102, parse the node field and edge field parameters to generate the corresponding field mapping data structure.

[0030] The field mapping data structure refers to converting the node fields, edge fields, and attribute conditions input by the user into a recognizable key-value mapping table for subsequent template replacement and condition concatenation processing.

[0031] For example, after parsing user input, "enterprise node" is mapped to node variable n1, "shareholder node" is mapped to n2, and "investment relationship" is mapped to edge variable e1. The condition "investment ratio ≥ 50%" is then converted into the normalized conditional expression properties(e1).con_prop>=50. The parsing results are stored in a JSON structure, as shown in the example below: { "nodes":{"n1":"t_enterprise","n2":"t_element_person"}, "edges":{"e1":"e_shareholder_invest"}, "conditions":["properties(e1).con_prop>=50"] } S103 combines indicator identifiers with field mapping data structures to form structured indicator configuration parameters.

[0032] The structured indicator configuration parameters refer to a unified data object that encapsulates the user-input indicator identifiers with the parsed and generated field mapping data. For example, the field mapping table and indicator identifiers are integrated into a JSON structure according to a preset format, as shown in the following example: { "indicator_id":"Number of companies with first-level equity penetration", "nodes":["n1","n2"], "edges":["e1"], "conditions":["properties(e1).con_prop>=50"] }; In an extended embodiment, if a user needs to define the "number of companies with second-degree equity penetration" indicator, the system will add an intermediate node field and a second edge field under the same process, generating field mapping data containing n1, n2, n3 and e1, e2, thereby forming a structured indicator configuration parameter that supports two-hop relationships.

[0033] In other implementations, the visual configuration interface can also support users to input native NGQL statements. After receiving the statement, it is directly stored as indicator configuration parameters without the need for node and edge field parsing, which is suitable for advanced users or complex query scenarios.

[0034] Step S200: Generate graph query conditions based on indicator configuration parameters, identify paths in the graph query conditions, extract path features, and determine the indicator template corresponding to the indicator configuration parameters based on the path features.

[0035] Among them, graph query conditions refer to the set of conditions that can be used for graph database queries, consisting of the attribute constraints of the starting node, intermediate nodes, ending nodes and their connecting edges. They are usually used as the content of the WHERE clause in NGQL statements. Indicator templates refer to the set of query statement skeletons pre-placed in the template library. Each type of template corresponds to a specific association depth (such as first degree, second degree) and return form (such as count, details), which are used to generate complete executable query statements later.

[0036] In the implementation process, the indicator configuration parameters are first parsed in a structured manner, and the nodes, edges and attribute parameters are extracted to form a set of candidate conditions. Then, the attribute conditions corresponding to each node and edge are generated in sequence and combined into complete graph query conditions. Finally, the path structure reflected by the conditions is used to identify the path, extract the path features, and select the most matching indicator template from the template library accordingly.

[0037] In one alternative embodiment, such as Figure 2 As shown, step S200 includes the following sub-steps: S201, based on the starting node, target node, and the type and attribute parameters of the connecting edges defined in the indicator configuration parameters, uses a stack-like structure to sequentially generate the attribute conditions corresponding to each node and edge.

[0038] The starting node and target node identify the two endpoints of the query path; the type and attribute parameters of the connecting edges define the relationship type and metric threshold between nodes; and the stack structure is used to push and manage condition fragments in the order of the path. For example, the node and edge fields in the indicator configuration parameters are read: the starting node is mapped to n1, the target node to n2, and the connecting edge to e1. ​​The edge attribute threshold (e.g., "investment ratio ≥ 50%)" is then normalized into the condition expression properties(e1).con_prop>=50. Subsequently, following the order of "starting node-edge-target node," the attribute conditions of the nodes / edges are pushed onto the stack in sequence, forming a condition fragment stack: [{cond(n1)},{cond(e1)},{cond(n2)}]; if there is an intermediate node and a second edge, the fragments {cond(e2)}, {cond(n3)}, etc., are pushed onto the stack in the same order.

[0039] S202 connects the attribute conditions according to logical operators to form graph query conditions that cover multi-hop paths.

[0040] The logical operators include Boolean operators such as AND and OR, used to establish Boolean connections between conditional fragments. Covering multi-hop path relationships means that when a path contains two or more edges, the condition must completely correspond to the node and edge of each hop. For example, fragments are popped from the stack in the order they were pushed onto the stack and connected using the AND operator to obtain a unified conditional clause, for example: cond(n1) AND properties(e1).con_prop>=50 AND cond(n2); If it is a two-hop path, then AND cond(e2) AND cond(n3) are concatenated on the basis of the above clauses to finally generate a complete graph query condition object, which is used as the content of the WHERE clause of the NGQL statement.

[0041] S203, perform path identification on the graph query conditions and extract the path features corresponding to the graph query conditions.

[0042] Path identification refers to the extraction and summarization of structural information of nodes and edges in graph query conditions. Path features include at least the number of nodes (|V|), the number of edges (|E|), and the edge direction sequence (dir_seq). For example, the graph query condition objects are traversed, and feature triples <|V|,|E|,dir_seq> are obtained: when |V|=2 and |E|=1, it is recorded as a single-hop path; when |V|=3 and |E|=2, it is recorded as a double-hop path. Simultaneously, the direction of each edge and the labels of the involved nodes are extracted to form a feature vector for template determination, such as <3,2,[in,out]>. For instance, if a condition set containing "shareholder relationship (e1)" and "appointment relationship (e2)" has been generated in S201 / S202, it will be identified as a two-hop path feature of "two edges and three nodes" in this step.

[0043] S204. Based on path characteristics, determine the indicator template corresponding to the indicator configuration parameters.

[0044] Among them, the indicator template refers to the set of pre-set templates that match the path features, including first-degree association templates, second-degree association templates, and corresponding count / detail return formats. Various types of templates are pre-loaded into the template library during the initialization phase. Each type of template contains a fixed statement skeleton and replaceable placeholders (such as {n1}, {e1}, {conditions}), which are used to dynamically populate the actual parameters later.

[0045] For example, when the path feature is a single-hop path (two nodes on one side), select the "first-degree association template"; when the path feature is a double-hop path (three nodes on both sides), select the "second-degree association template"; if the indicator configuration parameter is specified as a count type, bind the count return fragment (such as RETURN count(DISTINCT…)); if it is specified as a detail type, bind the return field fragment.

[0046] In detail, a first-degree association template refers to a graph query template with only one edge and two nodes in the path structure, used to describe a single-hop relationship; a second-degree association template refers to a template with two edges and three nodes in the path structure, used to describe a two-hop relationship. These templates are pre-installed in the template library during the initialization phase. Each type of template contains a fixed statement skeleton and replaceable nodes, edges, and condition placeholders.

[0047] For example, if the node set {n1, n2} and the edge set {e1} are detected, a first-degree association template is matched; if the node set {n1, n2, n3} and the edge set {e1, e2} are detected, a second-degree association template is matched. After matching, the path features are bound to the template structure to generate a template identifier; for example: The system generates either “INDICATOR_TEMPLATE_1D” or “INDICATOR_TEMPLATE_2D” and stores it in a configuration object for subsequent statement generation.

[0048] In a specific application scenario, when a user configures the indicator "number of equity penetration enterprises", the system identifies two edges (investment relationship e1 and control relationship e2) and three nodes (shareholder n1, invested enterprise n2, and ultimate enterprise n3) in the path identification. The corresponding path feature is "two edges and three nodes", thus determining that the indicator template is a second-degree association template, which is used to generate NGQL query statements for two-hop paths.

[0049] In other implementations, if the indicator configuration parameter is marked as "native statement template", this step directly maintains the template identifier and uses it for subsequent statement replacement without performing degree determination.

[0050] In another implementation, if the path features exceed two hops (e.g., a relationship of three degrees or more), it can be extended to a multi-degree template structure, and the corresponding template definition can be automatically generated based on the number of nodes and edges, thereby maintaining the scalability of the template system.

[0051] Step S300: Generate an indicator query statement for execution in the graph database based on the graph query conditions and indicator template.

[0052] The graph query statement refers to a declarative query script generated based on graph query conditions and indicator templates, which can be executed in the graph database to achieve graph data matching and result retrieval. This step is used to bind and replace logical conditions with structured templates to form an executable statement that conforms to the syntax rules of the graph database, thereby realizing the execution of the indicator query task.

[0053] In an optional embodiment, step S300 includes the following sub-steps: S301, retrieve the graph query language statement template that is pre-associated with the indicator template.

[0054] The graph query language statement template refers to the pre-defined NGQL (Nebula Graph Query Language) statement skeletons in the system, corresponding to different types of indicator templates. It predefines the positions of nodes, edges, and condition placeholders for dynamically filling in actual parameters. The graph query language is a declarative query language suitable for graph databases, preferably NGQL.

[0055] As an example, when the indicator template is determined to be a first-degree correlation template, the following preset template is invoked: MATCH(n1%s)%s[e1%s]%s(n2%s) WHERE%s RETURN count(DISTINCT id(%s)) If the template type is a second-degree association template, then the template is invoked: MATCH(n1%s)%s[e1%s]%s(n2%s)%s[e2%s]%s(n3%s) WHERE%s RETURN count(DISTINCT id(%s)) The aforementioned templates are loaded into memory from the configuration repository during system initialization, ensuring syntactic consistency and execution efficiency of NGQL statements across different path depths. By calling the corresponding templates, a foundation of statement structures that can be used for subsequent replacements is established.

[0056] For example, when the metric corresponding to the configuration parameter is "number of companies with second-degree equity penetration", the system automatically selects the second-degree association template as the basic statement skeleton for subsequent replacement.

[0057] S302, based on the graph query conditions, the starting node identifier, edge identifier, and ending node identifier are obtained.

[0058] The start node identifier, edge identifier, and end node identifier correspond to the syntax identifiers of the node and edge fields in the graph query conditions, respectively, and are used as placeholders in the template. By parsing the structural information of the graph query conditions, the types and attribute constraints of each node and edge are extracted, and a mapping table from logical entities to template placeholders is constructed.

[0059] As an example, in the graph query conditions, if the starting node n1 (enterprise node), edge e1 (investment relationship), and ending node n2 (shareholder node) are defined, a mapping table will be extracted: { "n1":"t_enterprise", "e1":"e_shareholder_invest", "n2":"t_element_person" }; If the conditions also include intermediate node n3 and the second edge e2, then the corresponding entries are added to the mapping table for template multi-hop replacement.

[0060] For example, when the indicator is configured as "number of second-degree related enterprises", the node identifiers n1, n2, and n3 and the edge identifiers e1 and e2 are parsed, and a sequence [n1–e1–n2–e2–n3] is established according to the path order to ensure that the replacement order is consistent with the query semantics.

[0061] S303, replace the corresponding attribute conditions in each identifier and graph query condition with the corresponding placeholders in the graph query language statement template in sequence to generate the indicator query statement.

[0062] Placeholders refer to symbol fields in the statement template that are dynamically replaced, including node label placeholders, edge type placeholders, direction placeholders, and condition placeholders (such as %s). The system fills the template with the actual values ​​from the mapping table according to a preset order or naming rules.

[0063] For example, for a first-degree related template, the following is generated after performing the replacement: MATCH(n1:t_enterprise)-[e1:e_shareholder_invest]-(n2:t_element_person) WHERE properties(e1).con_prop>=50 RETURN count(DISTINCT id(n2)) For the second-degree template, the replacement result is: MATCH(n1:t_enterprise)-[e1:e_shareholder_invest]-(n2:t_element_person)-[e2:e_control]-(n3:t_enterprise) WHERE properties(e1).con_prop>=50 AND properties(e2).ctrl_prop>=30 RETURN count(DISTINCT id(n3)) If the indicator template is a details-based template, replace the RETURN clause with a field return expression during the replacement process, for example: RETURN id(n1),name(n1),properties(e1).con_prop,id(n3) After the replacement is complete, the generated NGQL statement undergoes syntax validation to verify its compliance with the syntax rules of the graph database. If the validation passes, the final executable query statement is passed to the query execution module; if the validation fails, an error message is returned and the user is prompted to correct the configuration.

[0064] In other implementations, if the indicator template type is "native statement template", the template replacement process is skipped, and the user-inputted NGQL script is directly used as the graph query statement for subsequent execution, thereby supporting advanced users to customize complex query logic.

[0065] Step S400: Execute the indicator query statement in the graph database, obtain the query results, and perform aggregation processing to obtain the indicator results.

[0066] Here, a graph database refers to a database system that uses a graph structure to store data and supports the retrieval of node and edge relationships. Preferred examples include distributed graph databases such as Nebula Graph, Neo4j, or JanusGraph, which support complex graph traversal. The metric query statement refers to an executable NGQL statement. In this step, the database engine is invoked to execute the metric query statement, obtaining a raw query result set containing node identifiers, edge attributes, and return fields. The result set is then processed based on the preset aggregation rules in the metric template to ultimately generate structured metric results.

[0067] In other implementations, if multiple graph spaces exist in the graph database, the target graph space can be selected and the query executed based on the graph space identifier in the indicator configuration parameters, thereby adapting to application environments with multiple services, multiple tenants, or cross-domain data isolation.

[0068] In an optional embodiment, step S400 includes the following sub-steps: S401, run the indicator query statement in the graph database and obtain the query result set.

[0069] The graph database contains multiple graph spaces, which are namespaces used in the graph database to logically isolate datasets. Each graph space corresponds to an independent set of nodes, edges, and attributes. The query result set refers to the set of records returned by the database after executing the metric query statement, usually organized in tabular form, with each row representing a matching path. This application embodiment supports multiple databases, and the corresponding graph space or graph database will be selected during metric configuration.

[0070] As an example, the target graph space is determined based on the database identifier defined in the indicator configuration parameters, such as `space_finance_risk` or `space_invest_relation`, and then NGQL statements are executed in that space. The execution process is handled by the graph database's computation engine, and the returned result set typically includes node IDs, edge attributes, and return fields, for example: {"n1.id":"10001", "e1.con_prop":60, "n2.id":"20005"} If the template type is a two-degree association template, the result set will include information about the second hop node and edges, such as: {"n1.id":"10001", "e1.con_prop":60, "n2.id":"20005", "e2.ctrl_prop":40, "n3.id":"30012"} In a specific application scenario, when executing the "number of companies with second-degree equity penetration" indicator, the system runs the corresponding statement in the space_invest_relation graph space, and the result set returns all node combinations that meet the threshold conditions of investment ratio and control relationship.

[0071] S402: Based on the preset aggregation type in the indicator template, perform aggregation calculations on the target fields in the query result set to generate indicator results.

[0072] Among them, the aggregation type is the aggregation method defined in the indicator template, which is used to specify the type of statistical operation to be performed on the query result set. Common examples include counting and summing. The target field is the field on which the aggregation operation is performed, such as node ID or edge attribute field.

[0073] For example, when the aggregation type of the indicator template is "count", a deduplication counting operation is performed on the target node ID in the query result set, i.e., count(DISTINCT id(n)), and the number of unique entities is output; when the aggregation type is "sum", an accumulation operation such as sum(properties(e).amount) is performed and the total value is output.

[0074] After aggregation, the system encapsulates the results into standardized metric result objects, as shown in the example below: { "indicator_id":"Number of companies with second-degree equity penetration", "result_value":125, "timestamp":"2025-10-17T10:00:00+08:00" } This result object can be used to write to the indicator result table, push to the cache layer, or be called in real time by the front-end display module.

[0075] In other implementations, if the indicator template is a detail-type template (such as "first-degree association details" or "second-degree association details"), the aggregation stage is skipped, and the query result set is directly returned as detailed data to support interactive application scenarios such as penetration analysis and list export.

[0076] In addition, in batch processing mode, this step can be periodically triggered by a timer to achieve automated updates and persistent storage of metrics.

[0077] In an optional embodiment, the method further includes the following sub-steps: In response to changes in metric configuration parameters, the updated metric configuration parameters are written to the database, and then reloaded via a message queue or scheduled task.

[0078] Understandably, this mechanism ensures that the execution engine can promptly detect and apply the latest configuration when metric configurations change, avoiding service restarts or manual intervention, thereby achieving "hot loading" of configurations and seamless business updates. Specifically, the system employs a dual-channel mechanism to guarantee the reliability and real-time performance of configuration synchronization, including: (1) Real-time update mechanism based on message queue Message queues are message middleware used for asynchronous communication between distributed systems, including but not limited to Apache Kafka and RocketMQ. Their core components include: Topic: A logical channel used to carry configuration update events, for example, the default topic name is indicator_config_update; Message Producer: After the user completes the configuration changes and clicks "Publish", the configuration management service sends the update event to this topic; Message Listener Module: Deployed on the execution engine side, it continuously listens to the specified topic. Once an update message is received, it immediately triggers the full configuration reload process.

[0079] For example, when a user modifies the template type of the "Number of Companies with Second-Degree Equity Penetration" indicator to a detail template and publishes it, the system persists the new configuration to the database table `indicator_config`. Simultaneously, the producer sends a lightweight notification message to the topic `indicator_config_update`. After the listening module captures this message, it proactively reads all indicator configuration data from the database and refreshes the local cache, ensuring the new configuration takes effect immediately in the next query request.

[0080] (2) Periodic synchronization mechanism based on timed tasks Scheduled tasks are background task processes that are periodically triggered by the scheduler to ensure eventual consistency of configurations even in failure scenarios such as message queue anomalies, network partitions, or message loss.

[0081] For example, you can configure a scheduled task (CronJob) to automatically perform a configuration synchronization operation every 10 minutes. During task execution, the execution engine retrieves all metric configuration data from the configuration database and compares it with the version currently in the memory cache. If any metric's version number or update time has changed, it is replaced with the latest version, completing the cache update.

[0082] In other implementations, the execution interval of the scheduled task can be flexibly configured according to the system size or business needs. For example, it can be set to synchronize once every 5 minutes in scenarios where indicators are frequently updated, and extended to 30 minutes in low-frequency scenarios.

[0083] The dual-channel mechanism described above enables high availability synchronization of configuration changes: the message queue provides second-level response capability under normal circumstances, while the scheduled task serves as a fallback strategy to ensure the robustness of the system and data consistency.

[0084] Figure 3 A schematic diagram of a graph database index configuration device according to an embodiment of this application is shown. Exemplarily, the graph database index device 100 includes: The data acquisition module 110 is used to acquire the indicator configuration parameters input by the user in the visual configuration interface; The data processing module 120 is used to generate graph query conditions according to the indicator configuration parameters, perform path identification on the graph query conditions, extract path features, and determine the indicator template corresponding to the indicator configuration parameters based on the path features. The statement generation module 130 is used to generate an indicator query statement that can be executed in the graph database based on the graph query conditions and the indicator template. The aggregation processing module 140 is used to execute the indicator query statement in the graph database and perform aggregation processing on the query results to obtain indicator results.

[0085] It is understood that the apparatus of this embodiment corresponds to the method of the above embodiments, and the options in the above embodiments are also applicable to this embodiment, so they will not be described again here.

[0086] This application also provides a terminal device, exemplary of which includes a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to enable the terminal device to perform the functions of the various modules in the above-described method or apparatus.

[0087] The processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Network Processor (NP), Digital Signal Processor (DSP), Application-Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0088] The memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory is used to store computer programs, and the processor can execute the computer programs accordingly after receiving execution instructions.

[0089] This application also provides a computer-readable storage medium for storing the computer program used in the aforementioned terminal device. For example, the computer-readable storage medium may include, but is not limited to, various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0090] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that, in alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0091] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0092] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they 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 a 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 smartphone, 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.

[0093] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for configuring metrics in a graph database, characterized in that, The method includes: Obtain the indicator configuration parameters input by the user in the visual configuration interface; Graph query conditions are generated based on the indicator configuration parameters. Path identification is performed on the graph query conditions, path features are extracted, and an indicator template corresponding to the indicator configuration parameters is determined based on the path features. Generate an indicator query statement for execution in the graph database based on the graph query conditions and the indicator template; The indicator query statement is executed in the graph database to obtain the query results, which are then aggregated to obtain the indicator results.

2. The graph database indicator configuration method according to claim 1, characterized in that, The method further includes: In response to the change release operation of the indicator configuration parameters, the updated indicator configuration parameters are written to the database, and the updated indicator configuration parameters are reloaded through a message queue or scheduled task for updating. The message queue is used to send an update message to a preset topic after the indicator configuration parameters are updated, and to continuously monitor the preset topic through a listening module. When the update message is received, the indicator configuration parameters are read from the database to perform the update. The scheduled task is used to periodically read the indicator configuration parameters from the database to synchronize the latest configuration.

3. The graph database indicator configuration method according to claim 1, characterized in that, The process of obtaining the indicator configuration parameters input by the user in the visual configuration interface includes: Receive the indicator identifier, node field, and edge field parameters input by the user in the visual configuration interface; Parse the node field and edge field parameters to generate the corresponding field mapping data structure; The indicator identifier is combined with the field mapping data structure to form the structured indicator configuration parameters.

4. The graph database indicator configuration method according to claim 1, characterized in that, The step of generating graph query conditions based on the indicator configuration parameters, identifying paths in the graph query conditions, extracting path features, and determining the indicator template corresponding to the indicator configuration parameters based on the path features includes: Based on the starting node, target node, and type and attribute parameters of the connecting edges defined in the indicator configuration parameters, the attribute conditions corresponding to each node and edge are generated sequentially using a stack structure. The attribute conditions are connected according to logical operators to form graph query conditions that cover multi-hop paths; Path identification is performed on the graph query conditions, and path features corresponding to the graph query conditions are extracted; Based on the path characteristics, an indicator template corresponding to the indicator configuration parameters is determined.

5. The graph database indicator configuration method according to claim 1, characterized in that, The step of generating an indicator query statement for execution in the graph database based on the graph query conditions and the indicator template includes: Obtain the graph query language statement template pre-associated with the indicator template; the graph query language is a declarative query language suitable for graph databases; The starting node identifier, edge identifier, and ending node identifier are obtained by parsing the graph query conditions. Replace each identifier and the corresponding attribute condition in the graph query condition with the corresponding placeholder in the graph query language statement template in sequence to generate the index query statement.

6. The graph database indicator configuration method according to claim 1, characterized in that, The process of executing the indicator query statement in the graph database, obtaining the query results, and performing aggregation processing to obtain the indicator results includes: Run the indicator query statement in the graph database to obtain the query result set; Based on the preset aggregation type in the indicator template, perform aggregation calculations on the target fields in the query result set to generate the indicator results.

7. The graph database indicator configuration method according to claim 4, characterized in that, The step of determining the indicator template corresponding to the indicator configuration parameters based on the path characteristics includes: When the path feature contains an edge that connects two nodes, the indicator template is determined to be a first-degree association template; When the path feature contains two edges and connects three nodes, the indicator template is determined to be a second-degree association template.

8. A graph database index configuration device, characterized in that, include: The data acquisition module is used to acquire the indicator configuration parameters input by the user in the visual configuration interface; The data processing module is used to generate graph query conditions according to the indicator configuration parameters, identify the path of the graph query conditions, extract path features, and determine the indicator template corresponding to the indicator configuration parameters based on the path features. The statement generation module is used to generate an indicator query statement for execution in the graph database based on the graph query conditions and the indicator template. The aggregation processing module is used to execute the indicator query statement in the graph database, obtain the query results, and perform aggregation processing to obtain the indicator results.

9. A terminal device, characterized in that, The terminal device includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the graph database index configuration method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed on a processor, implements the graph database index configuration method according to any one of claims 1-7.

Images