A CMDB multi-level resource association relationship query method and system

Abstract

The application provides a CMDB multi-level resource association relationship query method and system, the method comprising: determining a target resource instance according to a query request, and determining a target level number for multi-level association relationship query of the target resource instance; determining an association type filtering condition according to a context of the query request, and determining a life cycle filtering condition according to a query time parameter of the query request; performing hierarchical traversal query according to the target resource instance, the target level number, the association type filtering condition and the life cycle filtering condition, taking an association record meeting the association type filtering condition and the life cycle filtering condition as a valid association edge, and returning a target instance corresponding to the valid association edge layer by layer. The application improves the performance and result accuracy of multi-level topology query without introducing additional storage components and without performing full-amount topology pre-computation.

Description

Technical Field

[0001] This application belongs to the field of database management technology, and in particular relates to a method and system for querying multi-level resource association relationships in CMDB. Background Technology

[0002] The Configuration Management Database (CMDB) is a core component of enterprise IT operations, used to store and manage various IT resource instances and their interrelationships. In multi-level topology query scenarios, operations personnel often need to query the complete topology structure of a resource instance down to multiple levels, such as querying all clusters mounted under a business system, cloud hosts under the clusters, and elastic IPs bound to the cloud hosts. Existing technologies typically use preset association types for filtering to prune irrelevant association edges, but this pruning method can only exclude irrelevant edges from the business type dimension and cannot handle the large number of dynamic temporary associations existing in the cloud resource environment. In actual cloud resource management scenarios, operations such as binding and unbinding elastic IPs, creating and revoking temporary operation and maintenance authorizations, and elastic scaling during peak sales periods all generate temporary associations with clear effective time windows. These temporary associations become expired data outside the time window, but existing technologies lack the ability to automatically perceive and filter the timeliness of such association edges, resulting in a large number of expired and invalid associations mixed in with the query results. This not only reduces query performance but also seriously affects the accuracy of topology query results, potentially causing operations personnel to make misjudgments based on incorrect topology information. Summary of the Invention

[0003] This application aims to provide a method and system for querying multi-level resource relationships in a CMDB. In cloud resource management scenarios where there are a large number of time-sensitive temporary relationships in the CMDB, without introducing additional storage components or performing full topology pre-calculation, it can automatically filter out expired relationship records and temporary relationship records that have not taken effect at the query time to ensure the accuracy of multi-level topology query results. Furthermore, it can improve query efficiency by synchronously executing time-dimension validity filtering and business-dimension relationship type filtering in hierarchical traversal queries.

[0004] This application discloses a method for querying multi-level resource relationships in a CMDB, including: The target resource instance is determined based on the query request, and the target number of multi-level association queries is determined for the target resource instance. The association type filtering conditions are determined based on the context of the query request, and the lifecycle filtering conditions are determined based on the query time parameter of the query request. The lifecycle filtering conditions are used to filter association records in the association instance table whose lifecycle type is expired, and to filter association records in the association instance table whose lifecycle type is temporarily valid but whose query time parameter is not between the effective time and the expiration time. Based on the target resource instance, the target level, the association type filtering condition, and the lifecycle filtering condition, a hierarchical traversal query is performed. The association records that simultaneously satisfy the association type filtering condition and the lifecycle filtering condition are taken as valid association edges, and the target instances corresponding to the valid association edges are returned layer by layer.

[0005] Optionally, the query time parameter of the query request includes: a first type of parameter indicating the query of the currently effective topology, or a second type of parameter indicating the query of the topology at a historical time point.

[0006] Optionally, determining the lifecycle filtering conditions includes: When the query time parameter is the first type of parameter, the current system time is used as the query time point; When the query time parameter is the second type of parameter, the historical time point carried in the second type of parameter is obtained as the query time point; Generate the lifecycle filtering conditions, which are used to filter first-type association records in the association instance table whose lifecycle type is expired, and to filter second-type association records in the association instance table whose lifecycle type is temporarily valid, but whose query time is not between the effective time and the expiration time.

[0007] Optional, also includes: Obtain resource change events pushed by the cloud resource management layer, wherein the resource change events are used to indicate that the association between cloud resource instances has changed; Update the lifecycle type of the corresponding associated record in the associated instance table, as well as the corresponding effective time and / or expiration time, based on the resource change event.

[0008] Optionally, updating the lifecycle type of the corresponding associated record in the associated instance table based on the resource change event includes: When the resource change event is a resource mounting or authorization event, a corresponding association record is created in the association instance table, and the lifecycle type of the created association record is set to permanent or temporary. The temporary association record has a corresponding effective time and expiration time. When the resource change event is a resource unloading, unbinding, or expiration event, the lifecycle type of the corresponding associated record in the associated instance table is atomically updated to expired.

[0009] Optionally, determining the association type filtering conditions based on the context of the query request includes: Obtain at least one of the entry characteristics, initiating user characteristics, and query request characteristics of the query request, and identify the target business scenario corresponding to the query request; Query the mapping relationship between preset scenarios and association rules, and obtain the whitelist of association types corresponding to the target business scenario. The whitelist of association types contains at least one set of correspondences between source model codes, association type codes and target model codes. Use the whitelist of association types as the filtering condition for the association types.

[0010] Optionally, the hierarchical traversal query includes: Add the target resource instance as the starting node to the queue and set the current level to one. The following operations are performed repeatedly until the queue is empty or the current level exceeds the target level: Take the node of the current level out of the queue, and construct a query statement based on the instance identifier of the taken node, the association type filter condition and the life cycle filter condition, wherein the filter condition of the query statement includes both the association type filter condition and the life cycle filter condition. Execute the query statement, add the returned next-level target instance to the queue, and increment the current level by one.

[0011] Optionally, a composite covering index is established on the associated instance table. The index columns of the composite covering index include source instance identifier, source model code, association type code, target model code, lifecycle type, effective time, expiration time, and target instance identifier.

[0012] Optional, also includes: After the query is completed, a portion of the query requests are extracted and a full traversal query without filtering conditions is performed. The results of the full traversal query are then compared with the results of the current query. When the comparison result indicates that a core topology node is missing in this query, the filtering conditions of the association type are modified, or the lifecycle attributes of the corresponding association record in the association instance table are calibrated.

[0013] This disclosure also provides a query system for multi-level resource relationships in a CMDB, including: The request parsing module is used to determine the target resource instance based on the query request, and to determine the target level for multi-level association querying of the target resource instance; The rule generation module is used to determine the association type filtering conditions based on the context of the query request, and to determine the life cycle filtering conditions based on the query time parameter of the query request. The life cycle filtering conditions are used to filter association records in the association instance table whose life cycle type is expired, and to filter association records in the association instance table whose life cycle type is temporarily valid but whose query time parameter is not between the effective time and the expiration time. The hierarchical query module is used to perform hierarchical traversal query based on the target resource instance, the target level, the association type filtering condition, and the life cycle filtering condition. The module takes the association records that simultaneously satisfy the association type filtering condition and the life cycle filtering condition as valid association edges and returns the target instance corresponding to the valid association edge layer by layer.

[0014] As can be seen from the above technical solution, this application, through the refined definition of lifecycle types in the associated instance table, makes the timeliness of each associated record a data attribute that can be directly judged during querying, without relying on external systems to inform it of its validity. During query execution, the lifecycle filtering conditions automatically generated by the system based on the query time parameter can simultaneously execute the validity judgment of the time dimension—whether the query time point is between the effective time and the expiration time of the associated record—and the business dimension relevance judgment implemented by the association type filtering conditions. Since both types of filtering conditions exist in the form of predicates that can be recognized by the database, they can play a role at each level of hierarchical traversal query. This ensures that when expanding multi-level associated edges, only associated edges that simultaneously meet the business scenario relevance and are valid at the query time point will be selected and enter the next level of traversal. This mechanism of completing filtering at the source of traversal significantly reduces the number of associated edges that actually need to be traversed and processed, reducing query overhead from the perspective of data scanning volume. Thus, without introducing additional storage components or performing full topology pre-calculation, the performance and result accuracy of multi-level topology queries are improved. Attached Figure Description

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

[0016] Figure 1A flowchart illustrating an embodiment of the CMDB multi-level resource association query method provided in this application; Figure 2 A flowchart for determining association type filtering conditions based on the context of a query request, provided in this application; Figure 3 The flowchart for the execution hierarchy traversal query provided in this application; Figure 4 A flowchart of another embodiment of the CMDB multi-level resource association query method provided in this application; Figure 5 This is a structural block diagram of an embodiment of the CMDB multi-level resource association query system provided in this application. Detailed Implementation

[0017] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not limiting, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without such specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods are omitted so as not to obscure the description of this application with unnecessary detail.

[0018] This application aims to propose a query method for multi-level resource relationships in a configuration management database (CMDB).

[0019] The Configuration Management Database (CMDB), as a core component of enterprise IT service management, stores and manages various IT resource instances and the relationships between them. As enterprise IT architectures transform towards cloudification, cloud resources such as cloud servers, virtual private clouds, subnets, load balancers, and elastic public IPs have become important components of enterprise IT assets. The metadata of these cloud resource instances needs to be synchronized to the CMDB for unified management. After management, the CMDB automatically identifies and maintains the relationships between resource instances, forming a complete cloud resource topology view, providing data support for subsequent operation and maintenance management, fault location, and change impact analysis.

[0020] Through long-term practice and observation of existing CMDB multi-level relational query technologies, the inventors of this application discovered a generally overlooked technical problem. In cloud resource management scenarios, the relationships between resource instances are not always static. In routine operation and maintenance scenarios such as elastic scaling, temporary authorization, and large-scale promotional expansion, a large number of temporary relationships are generated. For example, temporarily attaching a cloud host to a maintenance personnel's permissions for troubleshooting, temporarily adding a batch of cloud hosts and load balancers to a business cluster to cope with traffic peaks, and dynamically binding and unbinding elastic public IPs between cloud hosts. These temporary relationships have clear effective and expiration times; once their effective time window has passed, they become expired data and should no longer appear in daily real-time topology query results.

[0021] However, existing technologies have significant shortcomings in handling such time-sensitive dynamic relationships. Current systems typically use only a single status field to mark the validity of a relationship, such as zero for invalid and one for valid. This approach cannot distinguish between permanently valid fixed topology relationships and temporarily valid dynamic operational relationships, nor can it automatically detect expired temporary relationships. Status changes rely on manual updates in the business code within specific operational logic. When an Elastic IP address is unbound from one cloud host and bound to another, developers need to manually update the status of the original relationship to zero in the unbinding code and create a new record with a status of one in the binding code. This manual coupling method is prone to errors due to code omissions or improper exception handling, resulting in a large number of expired valid relationships in the CMDB. When operations personnel execute multi-level topology queries, these expired relationship records are returned along with the data. The query results contain information such as unbound Elastic IP addresses and offline temporary hosts, potentially leading to misjudgments by operations personnel based on incorrect topology information.

[0022] The inventors of this application further recognize that the essence of the above-mentioned problem lies in the fact that existing technologies treat the relationships in the CMDB as static tuples, managing their state only with a simple valid or invalid flag, failing to recognize that in a cloud resource management scenario, the relationship itself is a dynamic entity with an independent lifecycle. The binding relationship between an elastic public IP and a cloud host, from the moment of binding to the moment of unbinding, has a clearly defined time boundary. Similarly, a temporary operation and maintenance authorization, from the moment the authorization takes effect to the moment the authorization expires, also has a clearly defined time window. If relationships are re-understood as such lifecycle-bound entities, then the data model needs corresponding attributes to characterize this lifecycle, the data maintenance layer needs corresponding mechanisms to automatically manage the state transitions of this lifecycle, and the data query layer needs corresponding logic to perceive this lifecycle and filter invalid data accordingly.

[0023] Based on the above understanding, this application proposes a technical solution whose core concept is to systematically redesign the data model, data maintenance and data query from three levels. The life cycle attributes of the relationship are introduced into the association instance table of the CMDB. The life cycle status is automatically maintained through linkage with the cloud resource management event flow. This life cycle information is then applied to the filtering logic when querying multi-level topology.

[0024] It should be noted that the technical solution proposed in this application is not a simple aggregation of existing technologies such as database optimization, event-driven architecture, and index design. Rather, based on an understanding of the dynamic changes in relationships within the business context, these technologies are organized according to specific logical relationships to form a complete closed loop, from data attribute definition to automated data state maintenance and intelligent data query filtering. Within this closed loop, each technical feature does not solve its own problem in isolation, but rather there are clear causal dependencies and logically progressive relationships between them. To facilitate understanding of this relationship, the following is a deductive explanation of how the various technical features in this application's technical solution interact to solve the technical problem.

[0025] The inventors of this application discovered in practice that the root cause of poor performance and inaccurate results in multi-level CMDB topology queries lies in the interference of invalid association edges on the query process. In cloud resource management scenarios, invalid association edges mainly come from two dimensions: first, association types that are not needed in the current query scenario at the business dimension, such as querying the association between resources and work orders when querying business topology; second, expired temporary associations at the time dimension, such as unbound elastic IP associations and expired temporary authorization associations. Existing technologies can solve the problem of the first dimension by using association type whitelists, but there has been a lack of effective means to deal with the problem of the second dimension. Conventional approaches may include adding scheduled tasks to periodically clean up expired association records, or adding time-based filtering logic for query results at the front-end application layer. However, the scheduled task approach has a cleanup time window, and expired associations still exist between two cleanups; the application layer filtering approach requires loading data from the database to the application layer before judgment, and the overhead of transmitting and processing invalid data still exists. Neither of these two methods addresses the essence of the problem, namely, how to enable the system to perceive at the data level whether an association record should exist at the current query time.

[0026] The technical solution of this application starts from this essence and adopts a different approach from existing technologies. Specifically, this application first adds three fields—lifecycle type, effective time, and expiration time—to the data structure of the associated instance table. This makes the timeliness of each associated record no longer a conclusion that needs to be provided by an external system, but rather an attribute carried by the associated record itself. The lifecycle type is used to distinguish whether the association is a permanent business topology relationship or a temporary operational relationship, while the effective time and expiration time are used to determine the effective time window of the temporary association. In this way, for any associated record, the system only needs to check its own lifecycle attribute and the current query time to independently determine whether the record is valid at the time of query, without relying on any external state or data from other tables. This modification changes the time validity judgment of associated records from a calculation that requires external logic to a comparison operation of the associated record's own attribute values, laying the foundation for subsequently pushing this judgment logic down to the database layer for execution.

[0027] Building upon this foundation, this application further designs an automated maintenance mechanism for lifecycle attributes. The inventors of this application observed that the creation and destruction of association relationships are almost always triggered by resource operation behaviors of cloud management platforms or other operation and maintenance systems. The creation of a cloud host leads to its affiliation with its virtual private cloud; the unbinding of an elastic public IP address leads to the destruction of its binding relationship with the cloud host; and the expiration of a temporary authorization leads to the termination of that authorization relationship. These resource operation behaviors are perceived and processed as events in the resource management layer of the CMDB. Therefore, this application causally anchors the maintenance of the lifecycle attributes of the associated instance table to the event flow of the resource management layer. When the resource management layer receives a resource mounting or authorization event, while creating the corresponding associated record, it automatically sets the lifecycle type of the associated record to permanently valid or temporarily valid based on the event type. For temporarily valid associated records, it also records their effective time and expiration time. When the resource management layer receives a resource unmounting, unbinding, or expiration event, it automatically updates the lifecycle type of the corresponding associated record to expired. The value of this design lies in transforming changes to the associated lifecycle state from an operation that relies on manual or business code maintenance into a deterministic behavior that is automatically triggered by upstream events, thereby ensuring the real-time nature and accuracy of lifecycle attributes during the data production process.

[0028] At the query execution level, this application integrates lifecycle awareness with business scenario tailoring and pushes the dual filtering conditions to the database index layer for execution. In each traversal of the multi-level topology query, the query engine automatically generates lifecycle filtering conditions based on the query time parameter carried in the query request. These conditions are used to filter related records with a lifecycle type of "expired" and to filter related records with a lifecycle type of "temporarily valid" but whose query time is not between the effective and expiration times. Simultaneously, the query engine automatically determines the association type filtering conditions based on the context information of the query request. These two types of filtering conditions are combined into the filtering predicate of the same database query statement and applied together to the query process of the related instance table. Because the related instance table has a composite covering index containing the source instance identifier, association type field, lifecycle type, effective time, expiration time, and target instance identifier, the database can complete the filtering of both types of conditions during the index scan phase when executing the query statement, returning only a very small number of index entries that fully meet the requirements as results, without needing to access the main table data. In this way, in each hierarchical traversal query of this application, only related records that simultaneously satisfy both business relevance and time validity are selected and enter the next level of traversal. Related records that are irrelevant to the business or have expired in time are excluded from the processing flow at the database index scan layer. This mechanism of filtering at the source of traversal significantly reduces the number of related edges that actually need to be traversed and processed, thereby reducing query overhead from the perspective of data scanning volume.

[0029] It can be seen that the technical features at these three levels constitute a complete causal chain. The newly added lifecycle attributes at the data model level provide a database-recognizable field basis for time-dimensional validity judgments. The event-driven automated maintenance mechanism ensures the real-time performance and accuracy of the lifecycle attributes, ensuring that filtering conditions during queries are applied to reliable data. The index pushdown mechanism at the query execution level moves the execution location of the dual filtering logic of business and time dimensions from the application layer to the database kernel layer, ensuring that invalid data removal occurs during data reading rather than data consumption. The causal relationship between these three is as follows: if only fields are added at the data model level without an automatic maintenance mechanism, the accuracy of the fields cannot be guaranteed, and the query filtering based on this cannot obtain accurate results; if only the data model and automatic maintenance mechanism exist without an index pushdown mechanism, the time filtering logic can only be executed at the application layer, and invalid edges are still loaded and transmitted, significantly reducing the performance optimization effect; if only index optimization is performed without data model-level modifications, time-dimensional filtering is simply impossible because the database lacks fields that can be used to determine timeliness. Therefore, the fast query speed and accurate results achieved by the technical solution of this application do not stem from the individual effect of a single technical feature, nor from the simple superposition of the effects of multiple technical features. Rather, they are the overall result of the synergistic effect of three technical features—data attribute definition, automated data state maintenance, and intelligent data query filtering—according to a defined causal logic. This conceptual approach, which reinterprets relationships from static tuples as dynamic entities with a lifecycle and systematically transforms the data model to the underlying query execution, has not been disclosed or inspired by existing technical literature in this field.

[0030] The technical solution of this application will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0031] Optional, please refer to Figure 1 , Figure 1 This is a flowchart of an embodiment of the CMDB multi-level resource association query method provided in this application. The method can be applied to a configuration management database system, which is responsible for storing and managing various information technology resource instances and their inter-relationships. It supports hierarchical traversal queries of multi-level relationships to meet the needs of operation and maintenance scenarios such as fault location, change impact analysis, and resource topology visualization.

[0032] like Figure 1 As shown, the method includes the following steps: S100, determine the target resource instance based on the query request, and determine the target level for multi-level association query for the target resource instance.

[0033] In this embodiment, the query request can be initiated by operations and maintenance personnel through the user interface of the CMDB system, or by other operations and maintenance systems by calling the application programming interface. The information carried in the query request may include the identifier of the target resource instance, the topology level depth to be queried, the time range intent of the query, and the context information of the request source.

[0034] The target resource instance can be any type of configuration item instance, such as a business system instance, a virtual private cloud instance, or a cluster instance, and its identifier is unique within the CMDB system. The target level number specifies the depth of the traversal from the target resource instance downwards or upwards. For example, a target level number of four indicates that all relationships within a range of four levels starting from the target resource instance need to be queried.

[0035] For example, in a fault location scenario, operations and maintenance personnel need to query the clusters associated with a certain business system, the cloud hosts under the clusters, and the elastic public IPs bound to the cloud hosts. In this case, the target resource instance is the business system instance, and the target hierarchy is four. In a change impact analysis scenario, operations and maintenance personnel need to query the virtual private clouds and business systems associated with a certain cloud host. In this case, the target resource instance is the cloud host instance, and the target hierarchy can be set according to actual needs. Those skilled in the art will understand that the type of target resource instance and the value of the target hierarchy depend on the specific operations and maintenance requirements, and this application does not specifically limit them.

[0036] S200, determine the association type filtering conditions based on the context of the query request, and determine the lifecycle filtering conditions based on the query time parameter of the query request. The lifecycle filtering conditions are used to filter association records in the association instance table whose lifecycle type is expired, and to filter association records in the association instance table whose lifecycle type is temporarily valid but whose query time parameter is not between the effective time and the expiration time.

[0037] In this embodiment, the associated instance table is used to store specific association records between resource instances. Each association record may include the following basic fields: source instance identifier, target instance identifier, source model code, target model code, association type code, lifecycle type, effective time, expiration time, and creation time. Among them, the lifecycle type is used to describe the timeliness characteristics of the association record.

[0038] In a specific example, the lifecycle type can take three values: a first value, a second value, and a third value. The first value indicates that the association record is permanently valid, such as a fixed topology relationship between a business system and a cluster. The second value indicates that the association record is temporarily valid, such as a dynamic binding relationship between an Elastic Public IP and a cloud host. This type of association record has a corresponding effective time and an expiration time. The third value indicates that the association record is expired, such as an unbound Elastic Public IP association or an expired temporary authorization association.

[0039] It should be noted that the above description of the lifecycle type value method is only an exemplary illustration. Those skilled in the art can adopt different value schemes according to the coding specifications of the actual system, such as using different numerical values ​​or codes to represent the three lifecycle types. This application does not make any specific limitations in this regard.

[0040] In this embodiment, the query time parameter of the query request is used to express the query intent of the query initiator regarding the time dimension of the relationship.

[0041] Optionally, the query time parameter may include a first type of parameter indicating the query of the currently active topology, or a second type of parameter indicating the query of the topology at a historical point in time.

[0042] The first type of parameter indicates that the queryer wants to obtain all relationships that are in effect at the current time. In this case, the query engine uses the current system time as the query time.

[0043] The second type of parameter indicates that the queryer wants to view a snapshot of the resource topology at a certain historical moment. In this case, the query engine extracts the specified historical time point from the second type of parameter as the query time point.

[0044] By distinguishing between these two types of query time parameters, the method of this application can simultaneously support real-time queries of the currently active topology and backtracking queries of historical topologies, thus meeting the differentiated needs of different operation and maintenance scenarios.

[0045] In some embodiments, the step of determining lifecycle filtering conditions based on query time parameters includes: When the query time parameter is a first type parameter, the current system time is used as the query time point; When the query time parameter is a second type of parameter, the historical time point carried in the second type of parameter is obtained as the query time point; Generate lifecycle filtering conditions, which are used to filter first-type associated records in the associated instance table whose lifecycle type is expired, and to filter second-type associated records in the associated instance table whose lifecycle type is temporarily valid, but whose query time is not between the effective time and the expiration time.

[0046] In a specific example, suppose the associated instance table contains a record binding a cloud server to an Elastic Public IP address, with a lifecycle type of the second value (temporarily valid), effective at 10:00 AM on May 12, 2025, and expiring at 2:00 PM on May 12, 2025. If the query time is 11:00 AM on May 12, 2025, which falls between the effective and expiration times, the associated record meets the lifecycle filtering condition and will appear in the query results. If the query time is 3:00 PM on May 12, 2025, which exceeds the expiration time, the associated record will be filtered by the lifecycle filtering condition and will not appear in the query results. Alternatively, suppose the associated instance table contains a record with a lifecycle type of the third value (expired), then regardless of the query time, this record will be filtered by the lifecycle filtering condition. Finally, suppose the associated instance table contains a record with a lifecycle type of the first value (permanently valid), then this record will always meet the lifecycle filtering condition and will not be filtered based on the query time.

[0047] In some embodiments, such as Figure 2 As shown, the steps for determining the association type filtering conditions based on the context of the query request include: S210, obtain at least one of the entry characteristics, initiating user characteristics, and query requirement characteristics of the query request, and identify the target business scenario corresponding to the query request; S220, query the mapping relationship between preset scenarios and association rules, and obtain the whitelist of association types corresponding to the target business scenario. The whitelist of association types contains at least one set of correspondence between source model code, association type code and target model code. S230, use the whitelist of association types as the filtering condition for association types.

[0048] In this embodiment, the determination of association type filtering conditions utilizes existing metadata in the CMDB system, eliminating the need for additional data collection or instrumentation. The entry characteristic of the query request can be the identifier of the functional module initiating the query, such as the module code of the fault location module or the module code of the resource inventory module. The initiating user characteristics can be the user's role information, tenant information, etc., which can be directly read from existing permission management or the user center. Query requirement characteristics can be parameters such as the hierarchy depth and latency requirements carried in the query request. These characteristics reflect the current business context of the querying party, allowing the system to automatically match the corresponding business scenario based on these characteristics, thereby determining the whitelist of association types to be queried in that business scenario.

[0049] For example, in fault location scenarios, operations and maintenance personnel typically only need to focus on the core topological relationships between resources, such as business systems containing clusters, clusters running cloud servers, and cloud servers bound to elastic public IPs, without needing to focus on the relationships between resources and work orders, resources and monitoring templates, or other operations and maintenance management-related relationships. Therefore, the whitelist of association types corresponding to fault location scenarios only includes combinations of association types related to the core topology. In resource inventory scenarios, a more comprehensive understanding of the complete context of resources may be required, so the corresponding whitelist may contain more types of association combinations. Through this scenario-aware approach, the system can automatically determine which types of association edges should be retained when a query is initiated, excluding irrelevant association edges at the business scenario level from the traversal process.

[0050] S300: Perform a hierarchical traversal query based on the target resource instance, the target level, the association type filtering conditions, and the lifecycle filtering conditions. The association records that simultaneously meet the association type filtering conditions and the lifecycle filtering conditions are taken as valid association edges, and the target instances corresponding to the valid association edges are returned layer by layer.

[0051] In practice, the hierarchical traversal query adopts a breadth-first traversal approach, starting from the target resource instance and expanding the query relationship layer by layer outward.

[0052] Optional, such as Figure 3 As shown, the specific process of performing a hierarchical traversal query includes the following steps: S310, add the target resource instance as the starting node to the queue, and set the current level to one; S320, perform the following operations repeatedly until the queue is empty or the current level exceeds the target level. The repeated operations include: retrieving a node of the current level from the queue; constructing a query statement based on the instance identifier, association type filter condition, and lifecycle filter condition of the retrieved node; executing the query statement; adding the returned next-level target instance to the queue; and incrementing the current level by one. The filter conditions of the query statement include both the association type filter condition and the lifecycle filter condition.

[0053] It's important to note that in each layer of the query, the filtering conditions include both association type filtering and lifecycle filtering conditions. This means that when the database executes the query, both filtering conditions are active simultaneously. Only association records that meet both the association type requirements of the business scenario and the timeliness requirements of the query time will be returned and proceed to the next layer of iteration. Association records that are whitelisted but have expired will be filtered out, as will those that are still valid in terms of time but do not belong to the type required by the current scenario. This dual filtering mechanism operates at the database query level, ensuring that the data received by the application layer is already trimmed and valid, eliminating the need for secondary filtering.

[0054] Optionally, a composite covering index is created on the associated instance table. The index columns of the composite covering index include the source instance identifier, source model code, association type code, target model code, lifecycle type, effective time, expiration time, and target instance identifier.

[0055] The design purpose of a composite covering index is to match the query structure in hierarchical traversal queries, allowing the database to directly locate records that meet the conditions during query execution and retrieve the target instance identifier directly from the index without needing to access the main table data of the associated instance table. During the index scan, the database matches from front to back according to the order of the index columns. First, it locates the index range that meets the filtering conditions of the associated type using the source instance identifier and each model and type field. Then, within this range, it further filters records that do not meet the timeliness requirements based on lifecycle type, effective time, and expiration time. After the scan is completed, it directly returns a list of target instance identifiers that meet all conditions. This approach significantly reduces the number of data pages that the database needs to access when executing queries, thereby reducing input / output overhead and CPU computational overhead.

[0056] It should be noted that the column composition and column order of the aforementioned composite covering index are a preferred scheme designed based on the query statement structure adopted in this application. Under different database systems or different data sizes, those skilled in the art can adjust the column composition or column order of the index according to the actual query pattern and execution plan analysis results to achieve query performance optimization. This application does not impose specific limitations on this.

[0057] In this embodiment of the application, the lifecycle attributes of each associated record in the associated instance table are not manually maintained by the user, but are managed automatically by the system through the event-driven mechanism of the cloud resource management layer.

[0058] Specifically, such as Figure 4 As shown, the method also includes: S410, retrieve resource change events pushed by the cloud resource management layer. Resource change events are used to indicate changes in the association between cloud resource instances. S420, Update the lifecycle type of the corresponding associated record in the associated instance table, as well as the corresponding effective time and / or expiration time, according to the resource change event.

[0059] In this embodiment, the acquisition and processing of resource change events can be completed in advance before the query request, ensuring that the lifecycle information in the associated instance table is in an accurate state synchronized with the actual state of the cloud environment at the time of the query. Resource change events can be generated by the resource management and orchestration layer in the CMDB system. When the cloud management platform creates, changes, or destroys a cloud resource instance, the resource management and orchestration layer will generate corresponding events and distribute them through the event bus.

[0060] In this embodiment, the event types of resource change events may include resource mounting events, resource unmounting events, resource authorization events, resource expiration events, resource unbinding events, etc.

[0061] Correspondingly, the steps for updating the lifecycle type of the corresponding record in the associated instance table based on the resource change event include: When a resource change event is a resource mounting or authorization event, a corresponding association record is created in the association instance table, and the lifecycle type of the created association record is set to permanent or temporary. The temporary association record has a corresponding effective time and expiration time. When a resource change event is a resource unloading, unbinding, or expiration event, the lifecycle type of the corresponding associated record in the associated instance table is atomically updated to expired.

[0062] For example, when a cloud management platform mounts a cloud host to a virtual private cloud (VPN), the resource management layer receives the resource mounting event. The system creates an association record in the associated instance table with the source instance being the cloud host, the target instance being the VPN, and the association type being ownership. Since the ownership relationship between the cloud host and the VPN is a fixed topology, the system automatically sets the lifecycle type of this association record to the first value, i.e., permanently valid. When an operations and maintenance (O&M) personnel apply for and receive authorization for a two-hour temporary login to a cloud host, the system receives a resource authorization event. It creates an association record in the associated instance table with the source instance being the cloud host, the target instance being the O&M personnel, and the association type being temporary authorization. The lifecycle type of this association record is set to the second value, i.e., temporarily valid, and the effective and expiration times are entered based on the time information in the authorization application. When the temporary authorization expires, the system receives a resource expiration event and automatically updates the lifecycle type of the association record from the second value to the third value, i.e., expired. When an Elastic Public IP address is unbound from a cloud host, the system receives a resource unloading event and automatically updates the lifecycle type of the binding association record between the Elastic Public IP address and the cloud host to the third value. All of the above lifecycle status changes are automatically completed by the system backend, requiring no manual intervention and eliminating the need for business developers to manually write status update logic in specific resource operation code.

[0063] Optionally, the method also includes a closed-loop verification step for query results, used to continuously monitor and automatically correct the accuracy of dynamic pruning rules. Specifically, after the query is completed, a portion of the query requests are extracted and a full traversal query without filtering conditions is performed. The results of the full traversal query are compared with the results of the current query. When the comparison result indicates that there are missing core topology nodes in the current query, the filtering conditions for association types are corrected, or the lifecycle attributes of the corresponding association records in the association instance table are calibrated.

[0064] It should be noted that the execution of this closed-loop verification step can be performed asynchronously as an asynchronous bypass task without blocking the main query process. The proportion of query requests extracted can be dynamically adjusted according to system load and verification requirements, for example, one percent of query requests can be extracted for verification. This application does not impose specific limitations on this. The criteria for determining the absence of core topology nodes can be configured according to the topology characteristics of different business scenarios. For example, in a resource topology query scenario, if the pruning result lacks any association at the level from the business system to the cluster, it can be determined that a core topology node is missing.

[0065] When the comparison results indicate the absence of a core topology node, the characteristics of the missing associated edges can be further analyzed. If the missing associated edge is of a valid type but not covered by the whitelist, this associated edge type is added to the whitelist for the corresponding business scenario, ensuring that subsequent queries for the same scenario will not miss associated edges of that type. If the lifecycle attribute of the missing associated edge does not match the actual situation—for example, a still-active associated record is marked as invalid—the lifecycle attribute of that associated record is calibrated to correct its lifecycle type to the correct value. Through this closed-loop verification mechanism, the accuracy of the query rules and the accuracy of the lifecycle attributes in the associated instance table can be continuously improved, forming a self-optimizing capability.

[0066] The technical solution of this application will be explained below with a specific application example.

[0067] In this example, a company's CMDB system manages over 120,000 cloud resource instances, and the associated instance table stores over six million related records. Due to frequent operational operations such as elastic scaling, temporary authorizations, and support during peak sales periods, approximately 28% of the related records in the associated instance table are expired temporary associations. These include temporary scaling associations created during past peak sales periods, unbound elastic public IP binding associations, and expired temporary operational authorization associations.

[0068] When operations and maintenance personnel are troubleshooting, they need to query the current active Layer 4 topology of a certain e-commerce business system. This includes the cluster associated with the business system, the cloud hosts under the cluster, and the elastic public IPs bound to the cloud hosts. The query latency must not exceed two seconds. The query request is initiated from the fault location function page, and the initiating user role is an operations and maintenance personnel.

[0069] After receiving the query request, the system identifies the target resource instance as the e-commerce business system instance, with a target hierarchy of four. Based on the query request's entry characteristics and the initiating user's characteristics, the system identifies the current target business scenario as a fault location scenario. It then retrieves a whitelist of association types corresponding to this scenario from a pre-defined scenario-association rule mapping relationship. This whitelist contains three sets of association types: business system associated with cluster, cluster associated with cloud host, and cloud host associated with elastic public IP. Based on the parameters in the query request indicating the current active topology to be queried, the system uses the current system time as the query time point to generate lifecycle filtering conditions. These conditions require that the lifecycle type of the associated record is not expired, and for associated records with a temporarily valid lifecycle type, the query time point should be between its effective time and expiration time.

[0070] The system performs hierarchical traversal queries. In each traversal, the query statement's filtering conditions include both a whitelist of association types and lifecycle filtering conditions. The database utilizes a composite covering index to perform filtering directly at the index level. Taking the first-level traversal as an example, when the system queries the clusters associated with a business system instance, existing methods would return all associated records for that business system instance, including dozens of records such as associated operations managers, associated historical work orders, and expired old cluster associations. The application layer would then filter out valid cluster associations from these. However, in the technical solution of this application, the database only scans the index entries that meet the criteria of the source instance being the business system instance, the association type being on the whitelist, and the lifecycle meeting the timeliness requirements, and directly returns the results. Since the whitelist only includes the business system associated cluster type, and expired old cluster associations are excluded by the lifecycle filtering conditions, the first-level traversal only returns the currently active cluster instance identifier.

[0071] Subsequent traversals are performed in the same manner. After all four levels of traversal are completed, the system returns the query results within the required latency time. The results do not include offline old host associations or unbound old elastic public IP associations.

[0072] Those skilled in the art will understand that the above application examples are only used to more clearly illustrate a specific application scenario of the technical solution of this application, and are not intended to limit the scope of protection of this application. Under different cloud resource scales, different association type definitions, and different topology layer depths, the technical solution of this application can be adjusted and implemented according to the actual situation, which will not be elaborated here.

[0073] Based on the same inventive concept, embodiments of this application also provide a query system for multi-level resource association relationships in a CMDB, such as... Figure 5 As shown, the system includes a request parsing module 10, a rule generation module 20, and a hierarchical query module 30.

[0074] The request parsing module 10 is used to determine the target resource instance based on the query request, and to determine the target level for multi-level association queries on the target resource instance.

[0075] The rule generation module 20 is used to determine the association type filtering conditions based on the context of the query request, and to determine the lifecycle filtering conditions based on the query time parameter of the query request. The lifecycle filtering conditions are used to filter association records in the association instance table whose lifecycle type is expired, and to filter association records in the association instance table whose lifecycle type is temporarily valid but whose query time parameter is not between the effective time and the expiration time.

[0076] The hierarchical query module 30 is used to perform hierarchical traversal queries based on the target resource instance, the target level, the association type filtering conditions, and the life cycle filtering conditions. It takes the association records that simultaneously meet the association type filtering conditions and the life cycle filtering conditions as valid association edges and returns the target instances corresponding to the valid association edges layer by layer.

[0077] In this embodiment, the query time parameter may include a first type of parameter indicating the query of the currently active topology, or a second type of parameter indicating the query of a topology at a historical time point. The process by which the rule generation module determines the lifecycle filtering conditions includes: when the query time parameter is a first type of parameter, using the current system time as the query time point; when the query time parameter is a second type of parameter, obtaining the historical time point carried in the second type of parameter as the query time point; generating lifecycle filtering conditions, which are used to filter first type of associated records in the associated instance table whose lifecycle type is expired, and to filter second type of associated records in the associated instance table whose lifecycle type is temporarily valid, but whose query time point is not between the effective time and the expiration time.

[0078] In this embodiment, the system further includes an event processing module 40. The event processing module 40 is used to acquire resource change events pushed by the cloud resource management layer. These resource change events indicate changes in the association relationships between cloud resource instances. Based on the resource change event, the module updates the lifecycle type, effective time, and expiration time of the corresponding associated record in the associated instance table. The process of updating the lifecycle type by the event processing module includes: when the resource change event is a resource mounting or authorization event, creating a corresponding associated record in the associated instance table and setting the lifecycle type of the created associated record to either permanently valid or temporarily valid, wherein the temporarily valid associated record has a corresponding effective time and expiration time; when the resource change event is a resource unmounting, unbinding, or expiration event, atomically updating the lifecycle type of the corresponding associated record in the associated instance table to expired.

[0079] In this embodiment of the application, the process of the rule generation module determining the association type filtering conditions includes: obtaining at least one of the entry characteristics, initiating user characteristics, and query requirement characteristics of the query request, and identifying the target business scenario corresponding to the query request; querying the mapping relationship between the preset scenario and the association rules, obtaining the association type whitelist corresponding to the target business scenario, wherein the association type whitelist contains at least one set of correspondences between the source model code, the association type code, and the target model code; and using the association type whitelist as the association type filtering condition.

[0080] In this embodiment, the hierarchical query module performs a hierarchical traversal query as follows: adding the target resource instance as the starting node to the queue and setting the current level to one; performing the following operations in a loop until the queue is empty or the current level exceeds the target level; retrieving the node of the current level from the queue and constructing a query statement based on the instance identifier, association type filter condition, and lifecycle filter condition of the retrieved node; executing the query statement, adding the returned next-level target instance to the queue, and incrementing the current level by one. A composite covering index is established on the associated instance table, and the index columns of the composite covering index include the source instance identifier, source model code, association type code, target model code, lifecycle type, effective time, expiration time, and target instance identifier.

[0081] In this embodiment of the application, the system further includes a verification module 50. The verification module 50 is used to extract a portion of the query request after the query is completed and perform a full traversal query without filtering conditions, and compare the result of the full traversal query with the result of the current query; when the comparison result indicates that there is a missing core topology node in the current query, the association type filtering conditions are corrected, or the lifecycle attributes of the corresponding association records in the association instance table are calibrated.

[0082] It should be noted that the specific implementation of the functions of each module in the above system embodiment is consistent with the implementation of the corresponding steps in the aforementioned method embodiment, and will not be repeated here.

[0083] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for querying multi-level resource associations in a CMDB, characterized in that, include: The target resource instance is determined based on the query request, and the target number of multi-level association queries is determined for the target resource instance. The association type filtering conditions are determined based on the context of the query request, and the lifecycle filtering conditions are determined based on the query time parameter of the query request. The lifecycle filtering conditions are used to filter association records in the association instance table whose lifecycle type is expired, and to filter association records in the association instance table whose lifecycle type is temporarily valid but whose query time parameter is not between the effective time and the expiration time. Based on the target resource instance, the target level, the association type filtering condition, and the life cycle filtering condition, a hierarchical traversal query is performed. The association records that simultaneously satisfy the association type filtering condition and the life cycle filtering condition are taken as valid association edges, and the target instances corresponding to the valid association edges are returned layer by layer. The step of determining the association type filtering conditions based on the context of the query request includes: Obtain at least one of the entry characteristics, initiating user characteristics, and query request characteristics of the query request, and identify the target business scenario corresponding to the query request; Query the mapping relationship between preset scenarios and association rules, and obtain the whitelist of association types corresponding to the target business scenario. The whitelist of association types contains at least one set of correspondences between source model codes, association type codes and target model codes. Use the whitelist of association types as the filtering condition for the association types; The execution hierarchy traversal query includes: Add the target resource instance as the starting node to the queue and set the current level to one. The following operations are performed repeatedly until the queue is empty or the current level exceeds the target level: Take the node of the current level out of the queue, and construct a query statement based on the instance identifier of the taken node, the association type filter condition and the life cycle filter condition, wherein the filter condition of the query statement includes both the association type filter condition and the life cycle filter condition. Execute the query statement, add the returned next-level target instance to the queue, and increment the current level by one.

2. The method according to claim 1, characterized in that, The query time parameters of the query request include: a first type of parameter indicating the query of the currently effective topology, or a second type of parameter indicating the query of the topology at a historical time point.

3. The method according to claim 2, characterized in that, The determination of lifecycle filtering conditions includes: When the query time parameter is the first type of parameter, the current system time is used as the query time point; When the query time parameter is the second type of parameter, the historical time point carried in the second type of parameter is obtained as the query time point; Generate the lifecycle filtering conditions, which are used to filter first-type association records in the association instance table whose lifecycle type is expired, and to filter second-type association records in the association instance table whose lifecycle type is temporarily valid, but whose query time is not between the effective time and the expiration time.

4. The method according to claim 1, characterized in that, Also includes: Obtain resource change events pushed by the cloud resource management layer, wherein the resource change events are used to indicate that the association between cloud resource instances has changed; Update the lifecycle type of the corresponding associated record in the associated instance table, as well as the corresponding effective time and / or expiration time, according to the resource change event.

5. The method according to claim 4, characterized in that, The step of updating the lifecycle type of the corresponding associated record in the associated instance table according to the resource change event includes: When the resource change event is a resource mounting or authorization event, a corresponding association record is created in the association instance table, and the lifecycle type of the created association record is set to permanent or temporary. The temporary association record has a corresponding effective time and expiration time. When the resource change event is a resource unloading, unbinding, or expiration event, the lifecycle type of the corresponding associated record in the associated instance table is atomically updated to expired.

6. The method according to claim 1, characterized in that, A composite covering index is established on the associated instance table. The index columns of the composite covering index include source instance identifier, source model code, association type code, target model code, lifecycle type, effective time, expiration time, and target instance identifier.

7. The method according to claim 1, characterized in that, Also includes: After the query is completed, a portion of the query requests are extracted and a full traversal query without filtering conditions is performed. The results of the full traversal query are then compared with the results of the current query. When the comparison result indicates that a core topology node is missing in this query, the filtering conditions of the association type are modified, or the lifecycle attributes of the corresponding association record in the association instance table are calibrated.

8. A query system for multi-level resource association relationships in a CMDB, characterized in that, include: The request parsing module is used to determine the target resource instance based on the query request, and to determine the target level for multi-level association querying of the target resource instance; The rule generation module is used to determine the association type filtering conditions based on the context of the query request, and to determine the life cycle filtering conditions based on the query time parameter of the query request. The life cycle filtering conditions are used to filter association records in the association instance table whose life cycle type is expired, and to filter association records in the association instance table whose life cycle type is temporarily valid but whose query time parameter is not between the effective time and the expiration time. The step of determining the association type filtering conditions based on the context of the query request includes: Obtain at least one of the entry characteristics, initiating user characteristics, and query request characteristics of the query request, and identify the target business scenario corresponding to the query request; Query the mapping relationship between preset scenarios and association rules, and obtain the whitelist of association types corresponding to the target business scenario. The whitelist of association types contains at least one set of correspondences between source model codes, association type codes and target model codes. Use the whitelist of association types as the filtering condition for the association types; The hierarchical query module is used to perform hierarchical traversal query based on the target resource instance, the target level, the association type filtering condition, and the life cycle filtering condition. The associated records that simultaneously satisfy the association type filtering condition and the life cycle filtering condition are taken as valid association edges, and the target instance corresponding to the valid association edge is returned layer by layer. The execution of hierarchical traversal query includes: Add the target resource instance as the starting node to the queue and set the current level to one. The following operations are performed repeatedly until the queue is empty or the current level exceeds the target level: Take the node of the current level out of the queue, and construct a query statement based on the instance identifier of the taken node, the association type filter condition and the life cycle filter condition, wherein the filter condition of the query statement includes both the association type filter condition and the life cycle filter condition. Execute the query statement, add the returned next-level target instance to the queue, and increment the current level by one.

Images