Relation density isolation storage method and query method for multi-tenant graph database

Abstract

The application discloses a relationship density isolation storage method and a query method for a multi-tenant graph database, and the method for isolating and storing a target tenant comprises the following steps: calculating a relationship density score corresponding to the target tenant, and determining a storage container type of the target tenant based on the relationship density score; identifying a hot spot entity in the tenant, and when the hot spot entity exists, taking a preset hot spot entity isolation strategy as a target layout strategy, wherein the hot spot entity isolation strategy is a physical rearrangement operation of performing bucket storage on the associated edges of the hot spot entity in the storage container where the tenant is located; isolating and storing the target tenant based on the obtained storage container type and / or the target layout strategy, and updating a density isolation index based on the isolation storage result. The application arranges tenants based on relationship density grading, combines hot spot entity edge bucketing, forms double-layer isolation, and avoids resource conflicts and access skew.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a relation density-isolated storage method and query method for multi-tenant graph databases. Background Technology

[0002] As cloud graph databases are increasingly used in scenarios such as financial risk control, social relationship analysis, knowledge graphs, supply chain tracking, cybersecurity, and enterprise master data management, cloud service platforms typically need to host data from multiple tenants within the same graph database cluster. The data scale, number of entities, relationship types, number of edges, and access patterns vary significantly among different tenants. For example, some tenants may have a small number of entities but extremely dense relationships, some tenants may have a huge number of edges connecting hot entities, and some tenants may generate a large number of new edges or high-frequency adjacency expansion queries in a short period of time.

[0003] Existing multi-tenant graph databases typically employ the following methods for isolation and storage: logical isolation by tenant ID, which involves adding tenant identifiers to nodes and edges, and distinguishing different tenants through query conditions or namespaces; database-level or graph space-level isolation by tenant, which involves assigning different graph spaces, database instances, or partitions to different tenants; sharding by vertex hash or edge hash, which involves distributing data across multiple storage shards based on vertex ID, edge ID, or simple hash rules; expansion or migration based on capacity thresholds, which involves data migration or replication expansion when the capacity of a shard exceeds a threshold; and caching optimization for hot vertices, which involves caching nodes or adjacency lists that are accessed frequently. Summary of the Invention

[0004] This invention addresses the shortcomings of existing technologies, such as coarse isolation granularity failing to reflect differences in graph relation structure, simple hash sharding disrupting the locality of high-density relations, hot entities causing local storage and computational skew, implicit performance interference between multi-tenants, and the lack of dynamic reordering mechanisms. It provides a relation density isolation storage method for multi-tenant graph databases.

[0005] To solve the above-mentioned technical problems, the present invention provides the following technical solution: Firstly, a relation density isolation storage method for multi-tenant graph databases includes the following steps for isolating and storing target tenants: Calculate the relation density score corresponding to the target tenant, and determine the storage container type of the target tenant based on the relation density score; the relation density score is used to characterize the overall graph structure density; the storage container type includes shared ordinary area, independent logical area and high-density isolation area; Identify hot entities among the tenants. When a hot entity exists, use a preset hot entity isolation strategy as the target layout strategy. The hot entity isolation strategy is to perform a physical rearrangement operation of bucket storage for the associated edges of the hot entity within the storage container where the tenant is located. Based on the obtained storage container type and / or target layout strategy, target tenants are isolated for storage, and the density isolation index is updated based on the isolation storage results. The obtained density isolation index includes a tenant density index for recording the location of each tenant's storage container and a hot entity index for recording the location of hot entity side buckets.

[0006] This application classifies tenants based on the density of their internal relationships and places them in shared general areas, independent logical areas, or high-density isolated areas to determine the basic storage partitions of tenants. Based on this, we further identify hot entities within the tenant and perform physical rearrangement of their associated edges in bucket storage to avoid the huge adjacency lists of super nodes being concentrated in a single shard or a single storage block, thereby reducing the pressure of single-point access.

[0007] Existing technologies often perform static isolation based on business attributes or tenant IDs, without considering the characteristics of the graph structure. Problems in the query phase are often solved by query layer optimization solutions, such as cache reading and task splitting, without changing the physical layout of the storage layer. This application proposes dynamic isolation of the storage layer based on graph structure characteristics (density / hot spots / edge explosion risk), which overcomes the technical biases of those skilled in the art and creatively proposes to proactively perceive the graph structure and intervene in advance at the storage layer, reducing the pressure of single-point access while isolating data between tenants.

[0008] As one possible implementation method: The relation density score of the target tenant is calculated based on the global relation density, the maximum value of the type relation density, the maximum value of the local subgraph density, and the edge growth rate. The obtained relation density score can accurately assess the density of different graph structure forms, such as overall sparse but locally extremely dense and overall dense but evenly distributed, avoiding misjudgment of storage container type due to local hotspots being masked by the global average value.

[0009] The global relation density is determined by the ratio of the actual number of edges of the target tenant to the theoretical maximum number of connections, and is used to reflect the overall edge connection density. The type relation density corresponds one-to-one with the relation types contained in the target tenant, and the corresponding type relation density is determined based on the ratio of the actual number of edges corresponding to the relation type to the theoretical maximum number of connections; The density of the local subgraph corresponds one-to-one with the set of local nodes contained in the target tenant, and is determined based on the ratio of the actual number of edges corresponding to the set of local nodes to the theoretical maximum number of connections.

[0010] As one possible implementation method: The hotspot entity score corresponding to the target entity is calculated based on the entity degree, adjacent edge access frequency, path query participation frequency, associated edge write strength, and cache miss rate.

[0011] Target entities whose hot entity scores exceed a preset hot entity threshold are designated as hot entities.

[0012] As one possible implementation method: When the entity degree, adjacent edge access frequency, or edge growth rate of the target entity exceeds the corresponding mandatory threshold, the target entity is designated as a hotspot entity.

[0013] As one possible implementation, before isolating storage for the target tenant based on the obtained storage container type and / or target layout strategy, the following steps are also performed: Perform edge explosion risk identification on the target tenant and obtain the corresponding risk identification results; Based on the risk identification results, risk objects are determined, and the risk isolation strategy corresponding to the risk objects is obtained as the target layout strategy. The risk isolation strategy is used to establish a risk isolation zone inside the storage container where the target tenant is located, and to perform physical rearrangement for the corresponding risk objects.

[0014] To address the issues of edge explosion problems in existing technologies, such as the inability to isolate edge explosion risks in advance, this application introduces an edge explosion risk identification mechanism. This mechanism determines corresponding risk isolation strategies for risk objects of different granularities within a tenant (tenant as a whole, relationship type, entity, path pattern), establishes a risk isolation zone within the storage container where the tenant resides, and performs physical rearrangement to isolate risks in advance and prevent the occurrence of edge explosion problems.

[0015] As one possible implementation method, edge explosion risk identification includes tenant-level edge explosion risk identification, specifically: The tenant-level edge explosion risk score is calculated based on the target tenant's global relation density, average number of adjacent extended edges, historical path query candidate edge amplification factor, historical query timeout or truncation ratio, and edge burst enhancement degree. When the tenant-level edge explosion risk score exceeds the tenant risk threshold, the risk object is determined to be the target tenant.

[0016] As one possible implementation method, edge explosion risk identification includes relation-level edge explosion risk identification, specifically: For each relation type in the target tenant, calculate the relation-level edge explosion risk score corresponding to the relation type based on the number of edges of the relation type, the relation density, the number of times the relation type is queried and hit, and the average amplification factor of the relation type in multi-hop expansion; When the risk score of edge explosion at the relation level exceeds the relation risk threshold, the risk object is determined to be the corresponding relation type.

[0017] As one possible implementation method, edge explosion risk identification includes entity-level edge explosion risk identification, specifically: For each entity in the target tenant, calculate the entity-level edge explosion risk score based on the entity degree, outgoing edge expansion quantity, path query participation frequency, and edge growth rate. When the entity-level edge explosion risk score exceeds the entity risk threshold, the risk object is determined to be the corresponding entity.

[0018] As one possible implementation method, edge explosion risk identification includes path-level edge explosion risk identification, specifically: For each path pattern in the target tenant, a path-level edge explosion risk score is calculated based on the average path expansion factor, candidate edge expansion factor, query timeout or truncation ratio, and query hit frequency of the path pattern. When the path-level edge explosion risk score exceeds the path risk threshold, the risk object is determined to be the corresponding path pattern.

[0019] Secondly, this invention discloses a query method, comprising the following steps: Based on the query statement, a query is performed in the density-isolated index to obtain the target index, which includes the corresponding tenant density index and the corresponding hotspot entity index; the density-isolated index is the density-isolated index generated by any of the above methods. The query is performed based on each target index to obtain the corresponding query results.

[0020] This invention, by adopting the above technical solutions, has significant technical effects: This invention determines the storage container type corresponding to a tenant based on the density of relationships within the tenant, and adopts a differentiated physical storage layout within the tenant container based on the identification of hot entities and edge explosion risks. This transforms the passive handling of problems that occur during the query phase, such as the problem of excessive single-point access pressure caused by hot entities, into active isolation during query execution, thus solving the technical problem that existing static isolation and query layer optimization cannot cope with the performance interference of graph structures. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention 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 only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart illustrating a relation density isolation storage method for multi-tenant graph databases according to the present invention. Detailed Implementation

[0023] The present invention will be further described in detail below with reference to the embodiments. The following embodiments are explanations of the present invention, but the present invention is not limited to the following embodiments.

[0024] The existing technical solutions have the following main drawbacks: The coarse granularity of isolation cannot reflect the differences in graph relationship structure: Traditional isolation methods based on tenant ID, database instance or namespace can only identify which tenant it belongs to, but cannot identify whether the internal relationships of the tenant are dense, whether hot entities are concentrated, or whether adjacency expansion is prone to edge explosion. As a result, although different tenants are logically isolated, they may still interfere with each other in the underlying storage, caching and query execution. Simple hash sharding disrupts the locality of high-density relationships: Graph queries typically rely on adjacency traversal and multi-hop expansion. If vertex or edge hash sharding is used, high-density relationship subgraphs may be scattered across multiple physical shards, causing a single adjacency query to require access across multiple shards, increasing network communication, random read / write operations, and query latency. Hot entities can easily cause localized storage and computational skew: In graph scenarios such as financial accounts, corporate entities, products, users, and devices, some entities may be connected by a large number of edges, becoming super nodes or hot entities. Existing solutions mostly cache at the query layer, lacking a mechanism at the storage layer to split, rearrange, and hierarchically store the edges associated with hot entities, which can easily lead to excessive load on individual shards; Lack of early identification and isolation of edge explosion risk: Multi-hop graph queries may cause a sharp increase in the number of candidate edges due to certain relation types or entity combinations, i.e., "edge explosion". Existing solutions usually only discover the result explosion during query execution, lacking the ability to identify and isolate the risk in advance during the storage stage based on edge growth trends, relation density, and historical path expansion. Implicit performance interference exists among multiple tenants: when a high-density tenant or a hot tenant performs large-scale adjacency queries, batch imports, or path expansions, it may consume shared shard cache, I / O, and computing resources, thus affecting the query stability of other low-density tenants. Traditional multi-tenant isolation focuses more on permissions and data visibility, and does not fully address the performance isolation issues caused by graph relationship structures. Lack of dynamic reordering mechanism: The relationship density and hot entities in the tenant graph data are not static. As business grows, some tenants may change from low density to high density, and some ordinary entities may gradually become hot entities. The existing static sharding method is difficult to adapt to this change in a timely manner.

[0025] To address the aforementioned shortcomings, this application proposes a relation density-based isolated storage method for multi-tenant graph databases. Instead of simply partitioning by tenant ID or data capacity, it constructs a relation density profile for each tenant and, combined with hotspot entity identification results and edge explosion risk scoring, divides the tenant graph data into low-density areas, regular-density areas, high-density isolated areas, hotspot entity isolated areas, and edge explosion risk isolated areas. The system further employs differentiated physical storage layouts, adjacency list rearrangements, edge bucketing, hot and cold caching, and migration strategies for different areas, thereby achieving multi-tenant isolated storage based on relational structure characteristics in the cloud graph database.

[0026] like Figure 1 As shown, the method for isolating storage for target tenants includes the following steps: S100, Obtain the graph data feature vector of the target tenant; In this embodiment, graph data, query logs, write logs and system monitoring data of multiple tenants in the corresponding cloud graph database are collected, and feature vectors of graph data for each tenant are extracted. In the cloud map database, periodic or incremental statistics are performed on the map data of each tenant. The statistical window is denoted as W=[t0, t1], and the window duration is denoted as Δt=t1-t0. Graph data feature vectors include: basic scale features, relation density features, hotspot entity features, edge explosion risk features, and resource consumption features; This specification refers to tenant T. i As the target tenant, the basic scale characteristic is the number of tenant nodes collected |V i | Number of edges|E i | Number of relation types | R i | Node label count, edge attribute field count, data growth rate, storage space usage, shard I / O usage, query CPU consumption, cache usage, cross-shard access count, average query latency, P95 latency, and P99 latency; The number of nodes, edges, and relation types mentioned above are derived from the graph data directory, node table, edge table, and relation type dictionary; the data growth rate is derived from the write log or incremental log; and resource usage is derived from runtime monitoring of the storage engine, cache manager, and query executor.

[0027] S120, Relationship Density Characteristics; The relation density features include global relation density, type relation density, and local subgraph density. The density index is calculated by the system at the tenant dimension, relation type dimension, and local subgraph dimension, respectively. Specifically: S121, Global Relation Density; The global relation density is determined by the ratio of the actual number of edges of a tenant to the theoretical maximum number of connections: ; Among them, PC i For tenant T i The total theoretical maximum number of connections under graph pattern constraints; To prevent extremely small positive numbers with a denominator of 0; Among them, PC i The specific calculation method is as follows: The system reads the set S of source labels from the tenant graph schema that are allowed to establish relationships. r Target label set O r directional constraints and constraints on whether self-loops are allowed; For each relation type r, calculate its theoretical maximum allowed number of connections PC. i,r Summing these values ​​yields the theoretical maximum number of connections (PCs) corresponding to each tenant. i : ; If relation type r allows from source label L s Connect to target label L o ,but: ; Among them, V i (L) represents tenant T i The set of nodes with the label L; If the tenant does not explicitly configure the graph pattern, the system can estimate based on the upper limit of a directed graph or an undirected graph, and deduct the label pairs that the system prohibits from connecting; The specific calculation method for the upper limit of a directed graph is as follows: ; The specific calculation method for the upper bound of an undirected graph is as follows: .

[0028] S122, Type Relationship Density; The type relation density refers to the type relation density D for a given relation type r. i,r The number of edges is determined by the ratio of the actual number of edges in the relation type to the theoretical maximum number of connections that the relation type is allowed to form with the number of source label nodes and the number of target label nodes. The specific calculation method is as follows: ; Among them, |E i,r |For tenant T i The actual number of edges of relation type r in the relation; To prevent extremely small positive numbers with a denominator of 0; Here, the source label refers to the label of the starting node of relation type r, and the target label refers to the label of the ending node of relation type r. The two are determined by the endpoint constraints in the graph pattern. The source label and the target label together define the range of the node set in relation type r that can be used to construct edges. For example, if the TRANSFER relationship allows Account -> Account, then both the source and target labels are Account; If the BUY relationship allows User -> Product, then the source tag is User and the target tag is Product.

[0029] S123, Local Subgraph Density; A local node set U is obtained by sampling the k-hop neighborhood or sliding time window of communities, tag combinations, and hotspot candidate entities. The corresponding local subgraph density LD(U) is calculated based on the actual number of edges corresponding to the local node set and the theoretical maximum number of edges. The specific calculation method is as follows: ; Among them, E i (U) represents the set of actual edges within the local node set U or related to the path pattern; PC i (U) represents the maximum number of edges that can theoretically be formed under the condition that the intrinsic graph pattern of the local node set allows; To prevent extremely small positive numbers with a denominator of 0.

[0030] In this embodiment, if only the edges within the local set are calculated, then PC i (U) Refer to the global theoretical maximum connection number formula, and V i (L) is replaced with U∩V i (L); If we calculate the outward edge expansion centered on the candidate entity, then PC i (U) can be the maximum allowed number of outgoing edges from the candidate entity set to the target label set; The system can take the maximum value, mean value, or P95 value of each local density as the local density feature of the tenant, denoted as LD. i,max LD i,avg or LD i,p95 .

[0031] S130, Hotspot Entity Characteristics; The hotspot entity features are quantitative judgment indicators used for hotspot entity identification. Hotspot entity identification traverses all entities and candidate entity sets under the tenant, extracts hotspot entity features in a unified manner, and then combines comprehensive scores and judgment thresholds to identify hotspot entities. The characteristics of hot entities include: entity in-degree, out-degree, total degree, frequency of access to adjacent edges, number of times entity path queries are participated, growth rate of entity associated edges, cache hit rate, and cache eviction frequency. Specifically, the data sources for each feature are as follows: In-degree, out-degree, and total degree: taken from adjacency table metadata or edge index statistics; Adjacent edge access frequency: The access count of adjacency list scan, single-point query, and path expansion operations is counted by the query executor. Entity path query count: Statistics based on the matching hit records of the start point, end point, and intermediate nodes in the query log; Entity-related edge growth rate: calculated based on the incremental writing to the log and the total number of newly added, deleted, and updated edges within a unit time window; Cache hit rate and cache eviction frequency: The cache management module outputs statistics on cache hits, misses, and cache evictions.

[0032] The edge explosion risk characteristics are obtained by query execution statistics, path expansion sampling, and incremental log writing. They are collected at four granularities: tenant level, relationship level, entity level, and path pattern level. They can be used to describe global risks or local risks of specified relationship types, specified nodes, or specified path patterns. S140, characteristics of edge explosion risk; Edge explosion risk characteristics include average number of expanded edges per hop, average number of expanded edges per multi-hop, path expansion factor, expansion factor of candidate edges in query history, number of newly added edges per unit time, and number of multi-hop query timeouts or truncations. Specifically: S141, the average number of single-hop expanded edges is the average number of edges actually scanned or returned from an entity along a specified relation type r during query execution, AvgExpand(r).

[0033] S142. The average number of expanded edges in a multi-hop path query q is denoted as In, where In is the number of candidate edges for the h-th hop input. q,h The number of candidate edges output in the h-th hop is denoted as Out. q,h The specific calculation method for the average number of multi-hop extended edges in this query is as follows: .

[0034] S143. The path inflation factor is the weighted average of the inflation factors of each hop for the overall path inflation factor of the query. The specific calculation method is as follows: ; Where k is the actual number of hops executed for the path query or the maximum number of hops defined by the path pattern; ω hThe weight of the h-th hop can be set to 1 in this embodiment, or it can be set according to the time consumption of the h-th hop, the number of scanned edges, or the memory usage. The hop expansion factor is as follows: For a path query q, the hop expansion factor of the h-th hop is the ratio of the number of candidate edges to the number of candidate edges in the previous hop. The specific calculation method is as follows: ; Among them, Out q,h Output the number of candidate edges for the h-th hop; In q,h The h-th hop inputs the number of candidate edges; To prevent extremely small positive numbers with a denominator of 0.

[0035] S144. The historical candidate edge magnification factor is the ratio of the estimated number of candidates for the execution plan to the final number of results or the number of filtered results. When there are multiple candidate execution plans in a single query, only the plan actually used is included in the statistics. For a single query q, the estimated number of candidate edges in the execution plan is denoted as EstCand(q), and the number of filtered results or the final returned results is denoted as Res(q). Then: ; EstCand(q) is estimated by the query optimizer when generating the execution plan based on the average degree of the relation type and the number of path hops. It is used to represent the number of candidate edges that the query is expected to expand or scan before actual execution. To prevent extremely small positive numbers with a denominator of 0.

[0036] S145. The number of newly added edges per unit time is aggregated from the log entries by tenant, relation type, and entity. The number of new edges added to entity v is denoted as Add. v The number of edges deleted is denoted as Del. v The number of updated edges is denoted as Upd. v ; The specific formula for calculating the new rate is as follows: ; The specific formula for calculating the growth rate is as follows: ; The specific formula for calculating write strength is as follows: .

[0037] S146. The number of timeouts or truncations is the record truncated by the query executor when a timeout, memory threshold, or maximum expansion threshold is reached. The timeout rate can be expressed as: ; Among them, Timeout i Truncate is the number of times the timeout occurs.i QueryCount represents the number of times data is truncated. i This represents the number of queries.

[0038] S150, Resource Consumption Characteristics; The resource usage characteristics include: storage space usage, shard I / O usage, query CPU consumption, cache usage, cross-shard access count, average query latency, and P95 / P99 latency.

[0039] S200. Based on the graph data feature vector, calculate the relation density score corresponding to the target tenant, and determine the storage container type of the target tenant based on the relation density score; The relation density score is used to characterize the density of the overall graph structure. In this embodiment, based on the relation density score, the storage container type corresponding to the target tenant is determined according to the preset isolation rules. The specific steps are as follows: S210. Calculate the target tenant T based on graph data feature vectors. i Relationship Density Score (RDS) i ; Relationship Density Score (RDS) i The specific calculation method is as follows: ; Among them, D i D represents the global relation density. i,max LD represents the maximum type relation density. i,max G represents the density of the highest local subgraph. i is the edge growth rate; w(*) is the weight parameter, which can be configured by those skilled in the art based on actual needs; norm is the normalization function.

[0040] S220, RDS scoring based on relation density i Determine the relationship density level of the target tenant; The relation density level is used to characterize the overall graph structure density and also to indicate the storage container type of the target tenant; In practical applications, those skilled in the art can set the number of levels of relation density and the corresponding grading conditions (the range of relation density scores) according to actual needs. In this embodiment, relation density levels include low density (0-30), normal density (30-60) and high density (60-100).

[0041] S230. Determine the storage container type of the target tenant based on the relationship density level; In this embodiment, the storage container types include shared general areas, independent logical areas, and high-density isolated areas; When the relation density level is low, it means that there are few relations. The corresponding storage container type is a shared ordinary area, which means that it shares the same physical partition with other low-density tenants. In this case, tenant ID, namespace or graph space is used for logical isolation.

[0042] When the relationship density level is a regular density tenant, it means that the relationship scale and access pattern are stable. The corresponding storage container type is an independent logical area. Each tenant has an independent namespace / graph space. The data is completely isolated at the logical level (not visible to each other). It has an independent logical graph space and can share underlying physical resources with other tenants.

[0043] When the relation density level is high-density tenant, it means that the number of edges, the type relation density, or the local subgraph density is significantly high, and it needs to be isolated independently. Therefore, the corresponding storage container type is high-density isolation zone. The high-density isolation zone is an independent or semi-independent physical shard, thereby reducing its interference with the storage and querying of other tenants.

[0044] As one possible implementation, the relation density level also includes an abnormal surge level, and the storage container type includes an isolation buffer, which can be set on the physical shard corresponding to the high-density isolation area. That is, the relation density level is low density or normal density, but when the edge growth rate exceeds the preset growth threshold, the corresponding tenant is assigned to the isolation buffer to reduce its impact on the tenants in the area. When the edge growth rate is lower than the preset stable threshold and the relation density level is continuously determined to be the same level, isolation storage is performed based on the current relation density level.

[0045] As one possible implementation, based on graph data feature vectors, a hotspot entity score is calculated for each entity in the tenant, and the presence of a hotspot entity in the tenant is determined based on the hotspot entity score; a corresponding data layout strategy is determined based on the hotspot entity identification result. The data layout strategy is used to indicate the special storage sub-area established within the storage container where the tenant is located, and the corresponding physical rearrangement operation, which includes a hotspot entity isolation strategy. The specific steps are as follows: S310. Based on graph data feature vectors, for tenant T i For each entity v in the dataset, calculate the hotspot entity score HES(v); The hotspot entity score corresponding to the target entity is calculated based on the entity degree, adjacent edge access frequency, path query participation frequency, associated edge write strength, and cache miss rate. The specific calculation method is as follows: ; Where deg(v) is the entity degree; AF(v) is the access frequency of adjacent edges; PH(v) is the participation frequency of path queries; EG(v) is the write strength of associated edges; CM(v) is the cache miss rate; and a(*) is the weight parameter. The specific calculation method for entity degree deg(v) is as follows: ; Where inDeg(v) is the number of in-degrees; outDeg(v) is the number of out-degrees.

[0046] The specific calculation method for the adjacent edge visit frequency AF(v) is as follows: ; Where AdjAccess(v) is the total number of accesses to the adjacency list of entity v under the statistics window; Δt is the window duration.

[0047] The specific calculation method for the path query participation frequency PH(v) is as follows: ; Where PathHit(v) is the total number of times entity v is hit in various path queries under the statistics window; Δt is the window duration.

[0048] The specific calculation method for the associated edge write strength EG(v) is as follows: ; Among them, Add v This represents the number of newly added edges; Del v Upd represents the number of edges deleted. v The number of edges is updated; Δt is the window duration.

[0049] The cache miss rate CM(v) is calculated as follows: ; Among them, CacheHit v CacheMiss is the number of cache hits. v This represents the number of cache misses.

[0050] S320. When the hotspot entity score HES(v) exceeds the preset hotspot threshold TH hot If any single indicator among entity degree, adjacent edge access frequency, or edge growth rate exceeds the corresponding mandatory threshold, the corresponding entity will be marked as a hot entity.

[0051] S330. When a hotspot entity exists, invoke the preset hotspot isolation strategy; The hotspot entity isolation strategy involves performing a physical rearrangement operation of bucket storage on the associated edges of the hotspot entity within the storage container where the tenant is located.

[0052] Furthermore, this embodiment can classify hotspot entities into read hotspot entities, write hotspot entities, extended hotspot entities, and super node entities according to machine-executable conditions, and generate different isolation tags for different types of hotspot entities. Specifically: Reading hot entities refers to entities that are frequently queried but have slow edge growth; When the entity hotspot score HES(v) is not lower than the hotspot threshold TH hot And at the same time, the adjacent edge access frequency AF(v) is higher than the read threshold TH. read The write strength EG(v) of the associated edge is lower than the write threshold TH write Or the cache miss rate CM(v) exceeds the cache exception threshold TH. cache When this happens, it can be determined as a hotspot entity; These types of entities primarily cause read amplification and cache pressure.

[0053] Hotspot entities refer to entities that are frequently added, deleted, or updated with edges; When the entity hotspot score HES(v) is not lower than the hotspot total score threshold TH hot And the associated edge write strength EG(v) is higher than the write threshold TH. write If the number of any type of edge change (addition, deletion, or update) of an entity's associated edges within a unit of time reaches the P95 percentile or above within a tenant, it can be determined as a write hotspot entity. These entities primarily cause write amplification and storage rearrangement pressure; that is, any change type of addition, deletion, or update that is above P95 within a tenant can trigger a forced write hotspot.

[0054] Extended hotspot entities refer to entities that frequently cause candidate edge expansion in multi-hop path queries; When the entity hotspot score HES(v) is not lower than the hotspot total score threshold TH hot Furthermore, the path query participation frequency PH(v) is higher than the path expansion hotspot threshold TH. path Or, the ratio of the average k-hop candidate edges originating from entity v to the final number of query results exceeds the expansion bloat threshold TH. expand When this happens, it can be identified as an extended hotspot entity; Such entities are prone to causing candidate edge inflation in path queries; In this embodiment, k does not need to be manually set to a fixed value, and the maximum number of jumps in the query path mode is used first. If the query statement is a variable-length path, for example, the query statement is "MATCH (n)-[*1..3]-(m) RETURN", then k=3; If the system needs to have a unified observation caliber, a default k value can also be configured, such as 2 or 3.

[0055] A super node entity is an entity whose degree is much higher than the average degree or quantile threshold of entities within a tenant. If the entity degree deg(v) is not less than the absolute degree threshold TH degree The larger of the two values, P99 (deg) and the 99th percentile of the tenant entity degree, or the ratio of entity degree deg (v) to the average tenant degree AvgDeg (t), exceeds the supernode multiple threshold TH. super If so, it is determined to be a supernode entity; The large size of the adjacent edges of such entities can easily lead to problems such as data sharding skew and overloaded adjacency list scanning.

[0056] In this embodiment, the types of hot entities are divided and marked. In the actual isolated storage process, for a hot entity v of a tenant, all its adjacent edges are no longer stored as a single adjacency table. Instead, they are split into multiple edge buckets according to relationship type, edge access frequency, target node community, time window, and path query hit mode. The master record of the hot entity itself remains in the original tenant node storage area, and the entity is not detached from the tenant; the system only splits the entity's adjacency edge or adjacency table reference to the hot entity's side bucket. The original adjacency table location retains a lightweight pointer, version number, and bucket directory. When a query hits the entity, it first reads the bucket directory, and then accesses the corresponding side bucket according to the relationship type, access frequency, target community, or time window.

[0057] As one possible implementation method, based on graph data feature vectors, the edge explosion risk of the tenant itself, as well as each relationship type, each path pattern, and each entity within the tenant, is identified, and the corresponding data layout strategy is determined based on the edge explosion risk identification results. The specific steps are as follows: S410. Calculate edge explosion risk score based on graph data feature vectors; The edge explosion risk assessment includes: tenant-level edge explosion risk assessment, relationship-level edge explosion risk assessment, entity-level edge explosion risk assessment, and path-level edge explosion risk assessment, specifically: Tenant-level edge explosion risk score BRS(T) i ); The tenant-level edge explosion risk score is calculated based on the target tenant's global relationship density, average number of adjacent extended edges, historical path query candidate edge amplification factor, historical query timeout or truncation ratio, and edge burst enhancement strength. The specific calculation method is as follows: ; Where Di is the global relation density corresponding to the target tenant; AvgExpand i The average number of adjacency expansion edges corresponding to the target tenant is derived from query execution logs, query execution plan statistics, and adjacency table scan counts; CandAmp i The scaling factor for candidate edges in historical path queries corresponding to the target tenant is derived from path query execution logs, query optimizer estimation information, and query runtime path expansion statistics; TimeoutRate i The historical query timeout or truncation percentage for the target tenant is derived from query audit logs, slow query logs, and timeout controller records; Burst i b is the edge enhancement degree corresponding to the target tenant, used to identify whether there is batch import, sudden business event or abnormal relationship expansion; b(*) is the weight parameter.

[0058] Among them, the edge enhancement degree Burst i The specific calculation method is as follows: ; Among them, W short For short statistical windows, such as 5 minutes or 1 hour; W base For historical baseline windows, such as the past 7 days or 30 days; To prevent extremely small positive numbers with a denominator of 0; If Burst i If the value is greater than 1 and exceeds the threshold, it indicates that the current rate of adding edges is higher than the historical average.

[0059] Relationship-level edge explosion risk score BRS(r); For each relation type in the target tenant, calculate the relation-level edge explosion risk score corresponding to the relation type based on the number of edges of the relation type, the relation density, the number of times the relation type is queried and hit, and the average amplification factor of the relation type in multi-hop expansion; The specific calculation method is as follows: ; Among them, E r D is the number of edges of relation type r; r For type relation density; QueryHit r This represents the number of times this relation type has been hit by queries; Expand r c is the average amplification factor of this relation type in multi-hop expansion; c(*) is the weight parameter.

[0060] Among them, the average magnification factor Expand rThe calculation is performed by the query executor after recording the number of input and output candidates for each hop. The specific calculation method is as follows: ; Among them, In q,h,r To query the number of input candidate entities for q before the h-th hop and along relation type r expansion; out q,h,r To query the number of candidate edges generated by q after the h-th hop and along relation type r expansion; k q To query the actual path hop count of q; Q r This is a collection of all historical queries involving relation type r within the statistics window.

[0061] Entity-level edge explosion risk score BRS(v): For each entity in the target tenant, an entity-level edge explosion risk score is calculated based on the entity's entity degree, outgoing edge expansion quantity, path query participation frequency, and edge growth rate. The specific calculation method is as follows: ; Where deg(v) is the entity degree; outExpand(v) is the number of outgoing edges expanded; PH(v) is the frequency of path query participation; edgeGrowth(v) is the edge growth rate used for edge explosion risk; d(*) is the weight parameter; and norm is the normalization function.

[0062] The outgoing edge expansion quantity outExpand(v) is calculated as follows: ; Where outDeg(v) is the degree of the outgoing edge adjacency list; AvgScanOut(v) is the average number of actual edges scanned in the path query; MaxRelOut(v) is the maximum number of outgoing edges under the relation type; α(*) is the weight parameter.

[0063] The edge growth rate edgeGrowth(v) used for edge explosion risk prioritizes the statistics of newly added edges related to high-risk relationship types or outgoing edge expansion, emphasizing the candidate edge expansion risk caused by newly added outgoing edges or high-risk relationship edges. The specific calculation formula is as follows: ; Among them, AddOut v AddRiskRel to the number of new outgoing edges associated with v. v η represents the number of new edges related to v and belonging to the high-risk relationship type; η is the risk relationship weight; Δt is the window duration.

[0064] In the Path-Level Edge Explosion Risk Score (BERS(P)), the path pattern P is a query pattern composed of a sequence of relation types, direction, hop count range, and a summary of filtering conditions, such as the path "Account-[:TRANSFER*1..3]->Account".

[0065] For each path pattern in the target tenant, a path-level edge explosion risk score is calculated based on the average path expansion factor, candidate edge expansion factor, query timeout or truncation ratio, and query hit frequency of the path pattern. The specific calculation method is as follows: ; Where PathAmp(P) is the average path expansion factor of path pattern P within the statistical window; CandAmp(P) is the candidate edge expansion factor of path pattern; TimeoutRate(P) is the query timeout or truncation ratio of path pattern P; QueryHit(P) is the query hit frequency of path pattern P; and e(*) is the weight parameter.

[0066] The query hit frequency QueryHit(P) is the number of times or frequency that the path pattern is queried within the statistical window Δt. The specific calculation method is as follows: .

[0067] S420. Determine the risk object based on the obtained edge explosion risk score, and obtain the risk isolation strategy corresponding to the risk object; The data layout strategy includes a risk isolation strategy that corresponds one-to-one with the risk object. The risk isolation strategy is used to establish a risk isolation zone inside the storage container where the target tenant is located, and to perform physical rearrangement for the corresponding risk object. In this embodiment, when a risk of side explosion occurs, a risk isolation zone is established, and differentiated control strategies are implemented for different levels of risk targets: When the tenant-level edge explosion risk score is BRS(T) i Exceeding the tenant risk threshold TH risktenant When this occurs, all high-risk relationship types and high-risk path patterns under the tenant are uniformly included in the risk isolation zone and judged as tenant-level risks. The risk object is the tenant. Those skilled in the art can adopt control strategies such as adjusting the tenant logical isolation strategy, restricting path concurrent expansion, and migrating all high-risk relationship edges within the tenant. This specification does not limit them in detail. When the relation-level edge explosion risk score BRS(r) exceeds the relation risk threshold TH riskrelWhen the relationship type is identified as a relationship-level risk, the edges are bucketed by source entity or target community and an independent edge index is created. The risk object is the corresponding relationship type. At this time, a control strategy is adopted, which is to build an independent relationship edge index, store the relationship edges in buckets, and configure a relationship-specific scanning threshold. When the entity-level edge explosion risk score BRS(v) exceeds the entity risk threshold TH riskentity When the corresponding entity is identified as a risk object, the high-expansion side bucket associated with the entity is moved into the risk isolation zone or a risk sub-bucket is set in the hot entity side bucket. That is, it is identified as an entity-level risk and a control strategy of configuring an entity-specific risk side bucket, super node bucketing, and setting an upper limit for entity path expansion is adopted. When the path-level edge explosion risk score BRS(P) exceeds the path risk threshold TH riskpath When the corresponding path pattern is identified as a risk object, a pre-pruning index is created for the corresponding path pattern P, recording the expandable relationship of each hop, the set of necessary edges, the set of pruning edges, the filtering selection rate, and the maximum expansion threshold. It is identified as a path pattern-level risk, and a control strategy is adopted to generate a path pre-pruning index, allocate hop-by-hop expansion resource quotas, and return the results of candidate paths in batches.

[0068] Those skilled in the art can set the physical rearrangement of each risk object in the risk isolation zone according to actual needs, and the specification does not limit it in detail. S500 isolates target tenants based on storage container type and / or data layout strategy, and establishes density isolation index and access routing table based on the isolation storage results; The density isolation index includes: a tenant density index for recording the location of each tenant's storage container, a hot entity index for recording the location of hot entity edge buckets, and an edge explosion risk index for recording the location of the corresponding risk isolation zone; The physical routing table records logical isolation zones, fragment numbers, storage block addresses, bucket numbers, version numbers, and migration status.

[0069] In summary, this invention not only isolates tenants by identity but also provides structured isolation based on relation density, hot entities, and edge explosion risk, reducing resource interference from high-density tenants to ordinary tenants. By bucketing, layering, and storing hot entity-related edges independently, it avoids the massive adjacency lists of supernodes from being concentrated in a single shard or storage block. By identifying edge explosion risks in advance and establishing risk isolation zones and pre-pruned indexes, it reduces candidate edge expansion during multi-hop expansion. Through relation density awareness and relation co-occurrence rearrangement, it ensures that frequently accessed edges and entities are physically close together, reducing cross-shard access. Furthermore, in this invention, low-density tenants can be stored together, while high-density tenants can be isolated independently, avoiding resource waste caused by all tenants using dedicated storage; it can also dynamically adjust the isolation level and physical layout according to the growth of tenants, changes in hot entities, and query access patterns, making it suitable for long-term operation scenarios of cloud map databases.

[0070] This application also proposes a query method for directly routing queries to the corresponding locations based on query statements, density-isolated indexes, and access routing tables, generating corresponding retrieval results. Specifically, the method includes the following steps: S610. Based on the query statement, query the density isolation index to obtain the target index. The target index includes the corresponding tenant density index, as well as the corresponding hot spot entity index and / or edge explosion risk index. After receiving the query statement, the cloud database parses the query statement and extracts the tenant ID, starting entity, relationship type, path hop count, path pattern and filtering conditions.

[0071] The corresponding tenant density index is queried based on the tenant ID to locate the storage location of the corresponding tenant, i.e., the basic storage partition; When the starting entity is marked as a hot entity, the corresponding hot entity index is queried to locate the hot entity side bucket corresponding to the starting entity. When a relationship type or path pattern is marked as having edge explosion risk, query the corresponding edge explosion risk index to locate and access the tenant's risk isolation zone; S620. Based on the query results and access routing table of each index in the target index set, the query statement is routed to the corresponding target storage location to perform data reading and obtain the query results.

[0072] Given the density isolation index and access routing table, those skilled in the art can easily query the data.

[0073] As one possible implementation method, the total number of edge extensions for this query is estimated based on a hop-by-hop iterative approach according to the preset edge quantity estimation rules. If the estimated total exceeds the system's preset threshold, the path pre-pruning strategy is automatically activated to intercept invalid and low-value extension branches in advance. Among them, the edge quantity prediction rule is that the first hop expansion quantity is taken as the actual number of outgoing edges or the average number of outgoing edges under the correspondence of the starting entity; the k-th hop expansion quantity is the total number of candidate entities in the previous hop multiplied by the average expansion coefficient of the correspondence.

[0074] As an example, the relation density isolation storage method and query method disclosed above will be described in detail: 100. Generate logical isolation strategies based on the relationship density score, hotspot entity score, and / or edge explosion risk score corresponding to the tenant; Among them, the relation density score reflects the density of the overall tenant graph structure, the hot spot entity score is used to identify super nodes and frequently accessed entities within the tenant, and the edge explosion risk score is used to indicate the probability of candidate edge expansion in multi-hop queries.

[0075] The hotspot entity score includes the score of each entity in the tenant. If the hotspot entity score of any entity exceeds the corresponding hotspot score threshold, it is determined to be a hotspot. The edge explosion risk score includes tenant-level edge explosion risk score, relationship-level edge explosion risk score, entity-level edge explosion risk score, and path-level edge explosion risk score. If the edge explosion risk score of any entity exceeds the corresponding risk score threshold, it is determined to be an edge explosion risk.

[0076] In this embodiment, the judgment threshold corresponding to each score can be dynamically adjusted according to the cluster size, business scenario and historical percentile. Logical isolation strategies include data storage strategies and data layout strategies. The data storage strategy indicates the type of storage container corresponding to the tenant, and the data layout strategy indicates the physical rearrangement operation performed within the storage container corresponding to the tenant. Data storage strategies include: shared general isolation strategy, tenant-independent logical isolation strategy, and high-density tenant isolation strategy; Data layout strategies include: hotspot entity isolation strategy and edge explosion risk isolation strategy; Tenants can satisfy multiple logical isolation strategies at the same time, such as simultaneously satisfying the high-density tenant isolation strategy and the hotspot entity isolation strategy.

[0077] Specifically: When the relation density level is low, a shared ordinary isolation strategy is adopted; the data is stored in the shared ordinary area. At this time, multiple low-density tenants share the same physical partition, and logical isolation is achieved by tenant ID, namespace, or graph space.

[0078] When the relation density level is normal density, a tenant-independent logical isolation strategy is adopted; storage is carried out in an independent logical area. Such tenants have independent logical graph space and can share underlying physical resources with other tenants.

[0079] When the relation density level is high, a high-density tenant isolation strategy is adopted, and the data is stored in a high-density isolation area. Independent or semi-independent physical shards are allocated to such tenants to reduce their interference with the storage and querying of other tenants.

[0080] When there are hot entities but no risk of edge explosion, a hot entity isolation strategy is adopted. The hot entities and their associated edges of such tenants are separated from the ordinary adjacency area, and the hot entity adjacency edges are stored separately. The bucketing and caching strategies are used to physically rearrange them in the storage container.

[0081] When there is a risk of edge explosion, an edge explosion risk isolation strategy is adopted; this means that for tenants, relationship types or path patterns that are prone to edge explosion in multi-hop queries, high-risk relationship edges are independently and physically rearranged within the storage container of their respective tenants, providing risk warnings, pre-pruning indexes and extended rate limiting basis to the query execution layer.

[0082] In practical applications, edge explosion risk isolation strategies take precedence over hotspot entity isolation strategies.

[0083] 200. Based on the logical isolation strategy, perform physical rearrangement on the graph data to obtain the physically rearranged graph data and the updated physical routing table; The system performs physical rearrangement of graph data based on a logical isolation strategy. In actual use, the overall physical storage is divided into only two basic areas: a shared ordinary area and an independent logical area as the first physical area, and a high-density isolation area as the second physical area. Hotspot entity isolation and edge explosion risk isolation do not require separate independent physical areas. Both are dedicated storage sub-areas and differentiated physical rearrangement strategies configured for different risk objects within the high-density isolation area. As an example, the physical rearrangement strategies include low-density tenant merged storage, high-density tenant independent storage, hot entity adjacency edge binning storage, independent rearrangement while facing explosion risk, and relational locality enhancement rearrangement. Specifically: Low-density tenant consolidation storage refers to merging and storing the data of multiple low-density tenants in a shared general area, relying on tenant IDs, permission mechanisms, and query contexts to achieve logical isolation between tenants. This mode supports multi-tenant shared storage blocks, builds lightweight edge indexes based on tenant IDs, and uses compressed storage for infrequent adjacent edges, effectively avoiding the resource idleness and waste caused by small tenants monopolizing physical resources.

[0084] Independent storage for high-density tenants refers to migrating high-density tenant data to a high-density isolation zone and allocating independent physical shards or shard groups to the tenant graph data. During storage, priority is given to ensuring the physical continuity of high-density relationship types, while local clustering optimization is performed on the associated edges corresponding to high-frequency query paths, significantly reducing the cross-shard adjacency traversal overhead during path querying and improving query efficiency.

[0085] Hotspot entity adjacency edge binning storage refers to the approach of storing hotspot entities in a single adjacency table. Instead of centralized storage, it splits and stores their adjacency edges into multiple independent buckets based on relationship type, edge access frequency, target node community, time window, and path query hit pattern. During optimization, tenant core data is not stripped; the core master record of the hotspot entity remains in the original tenant node storage area. Only the entity's adjacency edges and adjacency table references are binned. Lightweight pointers, version numbers, and bucket directory information are retained in the original adjacency table location. When a query hits the hotspot entity, the system prioritizes reading the bucket directory and then matches the corresponding dimensions according to the query requirements to accurately access the target bucket data.

[0086] The edge explosion risk independent rearrangement refers to the system separating the associated edges, edge bucket directories and path pre-pruning indexes of tenants, relationship types, entities or path patterns with high edge explosion risk from the regular adjacency storage and storing them uniformly in the edge explosion risk isolation area, and binding the tenant ID and risk object ID for identification.

[0087] The aforementioned edge explosion risk isolation zone is not a unified storage pool shared by all tenants, but rather achieves logical isolation based on tenant ID, risk type, and risk object ID. At the physical level, it can be deployed using independent sharding, independent sharding groups, or a shared risk sharding pool. If a shared sharding pool is used, the pool will still be divided into dedicated namespaces, permission boundaries, and routing prefixes based on tenant IDs to achieve tenant data isolation.

[0088] Within the risk isolation zone, the system can store three types of edges: mandatory edges, trimmable edges, and candidate edges. Specifically: The required edges refer to those edges with a high selectivity rate (exceeding the preset first selectivity rate threshold) in historical queries and that meet business constraints, and these edges are expanded first. Edges that can be clipped are those with low selection rates (below the preset second selection rate threshold) or those that have been excluded by filtering conditions multiple times in history (e.g., the number of exclusions exceeds the preset filtering threshold). By default, they are either extended later or clipped when the threshold is exceeded. Candidate edges refer to edges that need further judgment based on the current filtering conditions, and are scanned in batches after being sorted by risk score and access frequency.

[0089] In this embodiment, differentiated control strategies are implemented for different levels of risk objects: When the tenant-level edge explosion risk score is BRS(T) i ) Reaching the tenant risk threshold TH risktenant When this occurs, all high-risk relationship types and high-risk path patterns under the tenant are uniformly included in the risk isolation zone, judged as tenant-level risks, and control strategies such as adjusting tenant logical isolation strategies, restricting path concurrent expansion, and migrating all high-risk relationship edges within the tenant are adopted.

[0090] When the relation-level edge explosion risk score BRS(r) reaches the relation risk threshold TH riskrel When the relationship type is identified as a relationship-level risk, the edges are bucketed by source entity or target community and an independent edge index is created. The control strategy of building an independent relationship edge index, storing the relationship edges in buckets, and configuring a relationship-specific scanning threshold is adopted. When the entity-level edge explosion risk score BRS(v) reaches the entity risk threshold TH riskentity When the entity is identified as an entity-level risk, the high-expansion side bucket associated with it will be moved into the risk isolation zone or a risk sub-bucket will be set in the hot entity side bucket. The control strategy of configuring an entity-specific risk side bucket, super node bucketing, and setting the upper limit of the entity path expansion will be adopted. When the path-level edge explosion risk score BERS(P) reaches the path risk threshold TH riskpath When a path pattern P is identified as a path pattern, a pre-pruning index is created, recording the expandable relationship, the set of necessary edges, the set of pruning edges, the filtering selection rate, and the maximum expansion threshold for each hop. If the path pattern is identified as a path pattern-level risk, a control strategy is adopted, which involves generating a path pre-pruning index, allocating hop-by-hop expansion resource quotas, and returning candidate path results in batches.

[0091] During the query execution process, the system first locates the basic storage partition by tenant ID, and then matches the corresponding risk isolation area or risk sub-bucket according to the risk label to prevent cross-tenant risk edge mixed scanning.

[0092] The relation locality enhancement rearrangement refers to constructing a relation co-occurrence matrix for entities and edges accessed collaboratively within the same tenant, and physically clustering and rearranging the graph edge data based on the object co-occurrence frequency. For edges and entity clusters that frequently appear in query scenarios, the system tries to normalize them to adjacent storage blocks or the same shard group, effectively reducing the frequency of cross-shard access and lowering the network and I / O overhead of path queries. The specific steps are as follows: A100, co-occurrence data extraction; The system traverses the query logs, extracts entities, relation types, and edge buckets that are commonly hit within the same query, the same path pattern, or the same transaction, and generates object co-occurrence records as the basic data for locality analysis.

[0093] A200, Constructing the co-occurrence matrix: Construct a co-occurrence matrix M using entity clusters, relation types, or edge buckets as rows and columns, where M ij This represents the number of times or weighted frequency of objects i and j being accessed together within the statistics window. The specific calculation method is as follows: ; Where I(*) is the indicator function; weight(q) is the weight of a single query, which can be dynamically configured based on the number of queries, query time, total number of scanned edges, or business priority; QW For the statistical set of queries within window W, the window granularity can be configured to 5 minutes, 1 hour, or 1 day; q represents Q. W A query in the middle.

[0094] A300, cross-access cost calculation; Define the cost of cross-shard comprehensive access between object i and object j. ij The cost consists of cross-shard network cost and random read I / O cost, and the specific calculation method is as follows: ; Among them, CrossCount ij This counts the number of cross-shard accesses when accessing 'i' and 'j' within a given window; NetCost represents the network cost of a single cross-shard access, which can be estimated based on network latency, RPC call cost, or cross-node transmission cost; RandomRead... ij The number of random reads generated when accessing i and j; IOCost is the I / O cost of a single random read.

[0095] A400, Clustering Benefit Determination; The system calculates the cost-benefit of aggregating objects i and j into the same shard group or adjacent storage blocks, using the difference between the cost savings and the migration cost as the basis for clustering benefit. The specific formula for calculating clustering benefit is as follows: ; Among them, SavedCost ij MoveCost represents the expected savings in access costs after clustering. ij The overhead incurred for data migration.

[0096] When clustering gains Gain ij Not less than the rearrangement payoff threshold TH gain If the cluster rearrangement is deemed to have positive benefits, the system will include object i and object j in the same rearrangement task.

[0097] A500, Reordering Execution and Verification; Within the preset migration window, the system will migrate the associated edge buckets to adjacent storage blocks, the same shard group, or a unified cache partition. After the migration is completed, the physical routing table will be updated synchronously, and the consistency of the number of edges, version numbers, and query results before and after the migration will be verified through an incremental log verification mechanism to ensure that the data is intact and the business is not abnormal.

[0098] 300. Based on the logical isolation strategy and physical rearrangement results, establish a density isolation index and access routing table; In this embodiment, based on the logical isolation strategy and the physical rearrangement results, the system establishes a density isolation index and an access routing table for different isolation regions; The density isolation index mentioned above includes: tenant density index, hotspot entity index, and edge explosion risk index; The physical routing table records logical isolation zones, fragment numbers, storage block addresses, bucket numbers, version numbers, and migration status.

[0099] When a query request arrives, the query executor looks up the access routing table based on the tenant ID, entity ID, relationship type, and path pattern, and routes the query directly to the corresponding normal zone, high-density isolation zone, hotspot entity isolation zone, or edge explosion risk isolation zone.

[0100] 400. Based on density-isolated indexes and access routing tables, implement isolated access and risk-aware scheduling during query execution; After receiving a tenant's query request, the Cloud Atlas Database completes query scheduling with isolation and risk awareness based on the density isolation index and access routing table. The specific steps are as follows: B100, Query statement parsing and key parameter extraction; Parse the query statement to extract tenant ID, starting entity, relationship type, path hop count, path pattern, and filtering conditions.

[0101] B200, tenant logical isolation policy matching; Retrieve the preset tenant density isolation index to determine the data layout strategy involved in the tenant's base storage partition.

[0102] B300, hotspot entity side bucket targeted routing access; Verify the attributes of the starting entity for the query. If the starting entity is a hot entity, skip the ordinary adjacency storage area and access the dedicated hot entity side bucket of that entity to read the adjacency data.

[0103] B400, high-risk relationship determination and risk isolation zone routing access; Identify whether the query matches a high-risk relationship type. If the high-risk criteria are met, route the query to the corresponding edge explosion risk isolation zone to access the data.

[0104] The query is considered to involve a high-risk relationship type if any of the following conditions are met: The query resolves to the set of relation types where r exists and BERS(r) ≥ TH. riskrel ; The query path pattern hits a high-risk path pattern index, and BERS(P) q )≥TH riskpath ; Although the query does not explicitly specify the relation type, the query optimizer expands it to include high-risk relation types or combinations of high-risk relation types; The relationship type is in the edge explosion risk index, and the current tenant ID is consistent with the tenant ID in the risk index.

[0105] B500, Path Expansion Edge Quantity Prediction and Pre-Pruning Strategy Trigger; The total number of edges in the path expansion for this query is estimated based on a hop-by-hop iterative approach. If the estimated total exceeds the system's preset threshold, a path pre-pruning strategy is automatically initiated to intercept invalid and low-value expansion branches in advance. Among them, the edge quantity prediction rule is that the first hop expansion quantity is taken as the actual number of outgoing edges or the average number of outgoing edges under the correspondence of the starting entity; the k-th hop expansion quantity is the total number of candidate entities in the previous hop multiplied by the average expansion coefficient of the correspondence.

[0106] As mentioned above, edges in the risk isolation zone are classified and stored. Among them, pruning edges are used for delayed expansion or pruning when the threshold is exceeded. When the path pre-pruning strategy is triggered, the corresponding pruning edges will be collected.

[0107] In practical applications, those skilled in the art can also set resource control rules based on actual needs to indicate the execution resources corresponding to the tenant's basic storage partition and the risk level involved in this query, such as CPU, memory, query concurrency and path extension quotas, to achieve differentiated resource control for high-priority and high-risk queries.

[0108] B600, Result Return and Risk Information Push; After execution, standardized query results are returned. At the same time, based on the risk identification of this query, extended information such as query risk warnings and performance optimization tips are attached as needed to support upper-level business monitoring and query optimization.

[0109] In this embodiment, the query statement “MATCH p=(a:Account)-[:TRANSFER*1..3]->(b:Account) WHERE a.id = 'A001' RETURN p” is used as an example: If entity A001 is marked as a super node and the TRANSFER relationship is marked as an edge-explosion risk relationship, then the system adopts an overlay routing strategy: First, locate the tenant's basic storage partition using the tenant density index, and then route to the hot entity side bucket of A001 based on the hot entity index. If the side bucket contains high-risk relationships, it will further access the risky sub-buckets within the bucket or jump to the tenant's independent TRANSFER risk isolation zone.

[0110] Hotspot entity isolation and edge explosion risk isolation are cumulative, not mutually exclusive. The routing priority to hotspot entity edge buckets only represents the first-level access path. If high-risk relationships or path patterns exist within the bucket, risk isolation reading, edge pre-pruning, and path expansion rate limiting will still be performed. The system relies on the path risk index to filter low-value edges that can be pruned, and only expands related edges that meet the filtering conditions. When the candidate path size exceeds the limit, the system controls query overhead by returning in batches or directly terminating path expansion.

[0111] In practical applications, the monitoring and feedback module continuously monitors various indicators and triggers recalculation in the following two ways: one is periodic triggering, that is, automatically recalculating tenant relationship density, hot spot entity score and edge explosion risk score every set time window; the other is event triggering, that is, triggering recalculation immediately when the system detects a specific change in operating status. The event-triggered conditions include: The number of tenant edges has increased beyond the threshold; An entity's degree exceeds the supernode threshold; The expansion factor of a query for a certain relation type exceeds a threshold; A tenant's P99 query latency continues to rise; An abnormal eviction rate or I / O usage is detected in a certain shard cache. A tenant moved from low-density to high-density; If the popularity of a certain hot entity decreases, the hot entity label will be removed, and it needs to be moved back to the ordinary area.

[0112] When any of the above triggering conditions are met, the system performs the following actions: Update tenant isolation levels; Generate a migration plan; Migrate the relevant nodes, edges, or edge buckets to the target isolation zone; Update the access routing table; maintain dual-write or incremental log synchronization during migration; Switch read / write routes after migration is complete; Clean up old storage container types.

[0113] As an example, taking a multi-tenant scenario of a cloud graph database as an example, the cloud graph database platform serves three tenants simultaneously: Tenant A: Financial risk control tenant, with approximately 1 million nodes and 80 million edges, and a large number of account transfer relationships, with a relationship density level of high density; Tenant B: Enterprise knowledge graph tenant, with approximately 5 million nodes and 12 million edges. The relationships are relatively sparse, with a low density level. There are no hotspot entities and no risk of edge explosion. Tenant C: Social recommendation tenant, with approximately 3 million nodes and 300 million edges. It has a large number of friends, followers, and interactions, and its relationship density level is high.

[0114] At this point, the following processing will be performed: Tenant B will be classified as a low-density shared general area; Tenants A and C will be relocated to a high-density segregation area. Create a hotspot entity side bucket for the high-frequency account entities in tenant A that are hotspot entities; For the super user entities in tenant C that are hotspot entities, perform adjacency edge bucketing based on relationship type, access frequency, and target community; Establish corresponding risk isolation zones for the relationships in tenant A and tenant C; When executing a query, if a hot entity or high-risk relationship type is hit, the corresponding isolation zone is accessed instead of scanning the ordinary adjacency zone.

[0115] This application also provides a relation density isolated storage system for multi-tenant graph databases; The system includes the following modules: Tenant Graph Profile Collection Module: Used to collect the number of nodes, number of edges, relationship type, edge growth rate, query access frequency, adjacency expansion scale, and resource usage of each tenant.

[0116] Relationship density calculation module: used to calculate tenant-level, relationship-level, and local subgraph-level relationship density scores, and output tenant density levels.

[0117] Hotspot Entity Identification Module: Used to identify hotspot entities, super nodes, and extended hotspot entities based on entity degree, access frequency, path hit rate, edge growth rate, and cache hit status.

[0118] Edge explosion risk assessment module: used to calculate edge explosion risk score based on multi-hop expansion multiple, candidate edge amplification multiple, query timeout records, type relationship density, and edge burst situation.

[0119] Logical isolation decision module: used to determine the storage location and data layout of tenants, entities, relationship types and path patterns based on relation density score, hot entity score and edge explosion risk score.

[0120] Physical rearrangement execution module: used to perform low-density tenant merged storage, high-density tenant independent storage, hot entity side-by-side bucketing, independent rearrangement while facing explosion risk, and relational locality clustering.

[0121] Density Isolation Index Management Module: Used to maintain tenant density index, hotspot entity index, edge explosion risk index, and physical access routing table.

[0122] The query routing and scheduling module is used to route requests to the corresponding isolation zone based on tenant ID, entity ID, relationship type, and path pattern during query execution, and to perform risk-aware scheduling.

[0123] Dynamic migration and consistency maintenance module: used to perform data migration, route switching, dual-write synchronization and consistency verification when tenant density level changes, hotspot entities change or edge explosion risk changes.

[0124] The monitoring and feedback module is used to monitor query latency, shard load, cache hit rate, cross-shard access count, and migration effect, and to use the feedback results for the next round of scoring and reordering.

[0125] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0126] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0127] This invention is described with reference to flowchart illustrations and / or block diagrams of the method, terminal device (system), and computer program product according to the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0128] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0129] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0130] It should be noted that: The phrase "an embodiment" or "an embodiment" used in this specification means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. Therefore, the phrase "an embodiment" or "an embodiment" appearing in various places throughout the specification does not necessarily refer to the same embodiment.

[0131] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments.

[0132] Furthermore, it should be noted that the specific embodiments described in this specification may differ in the shape and name of their components. All equivalent or simple variations made to the structure, features, and principles described in this patent concept are included within the scope of protection of this patent.

Claims

1. A relation density-isolated storage method for multi-tenant graph databases, characterized in that, The method for isolating storage for target tenants includes the following steps: Calculate the relation density score corresponding to the target tenant, and determine the storage container type of the target tenant based on the relation density score; the relation density score is used to characterize the overall graph structure density; the storage container type includes shared ordinary area, independent logical area and high-density isolation area; Identify hot entities among the tenants. When a hot entity exists, use a preset hot entity isolation strategy as the target layout strategy. The hot entity isolation strategy is to perform a physical rearrangement operation of bucket storage for the associated edges of the hot entity within the storage container where the tenant is located. Based on the obtained storage container type and / or target layout strategy, target tenants are isolated for storage, and the density isolation index is updated based on the isolation storage results. The obtained density isolation index includes a tenant density index for recording the location of each tenant's storage container and a hot entity index for recording the location of hot entity side buckets.

2. The relation density isolation storage method for multi-tenant graph databases according to claim 1, characterized in that: The relation density score of the target tenant is calculated based on the target tenant's global relation density, the maximum value of the type relation density, the maximum value of the local subgraph density, and the edge growth rate. The global relation density is determined by the ratio of the actual number of edges of the target tenant to the theoretical maximum number of connections; The type relation density corresponds one-to-one with the relation types contained in the target tenant, and the corresponding type relation density is determined based on the ratio of the actual number of edges corresponding to the relation type to the theoretical maximum number of connections; The density of the local subgraph corresponds one-to-one with the set of local nodes contained in the target tenant, and is determined based on the ratio of the actual number of edges corresponding to the set of local nodes to the theoretical maximum number of connections.

3. The relation density isolation storage method for multi-tenant graph databases according to claim 1, characterized in that: The hotspot entity score corresponding to the target entity is calculated based on the entity degree, adjacent edge access frequency, path query participation frequency, associated edge write strength, and cache miss rate. Target entities whose hot entity scores exceed a preset hot entity threshold are designated as hot entities.

4. The relation density isolation storage method for multi-tenant graph databases according to claim 3, characterized in that: When the entity degree, adjacent edge access frequency, or edge growth rate of the target entity exceeds the corresponding mandatory threshold, the target entity is designated as a hotspot entity.

5. The relation density isolation storage method for multi-tenant graph databases according to any one of claims 1-4, characterized in that, Before isolating storage for the target tenant based on the obtained storage container type and / or target layout strategy, the following steps are also performed: Perform edge explosion risk identification on the target tenant and obtain the corresponding risk identification results; Based on the risk identification results, risk objects are determined, and the risk isolation strategy corresponding to the risk objects is obtained as the target layout strategy. The risk isolation strategy is used to establish a risk isolation zone inside the storage container where the target tenant is located, and to perform physical rearrangement for the corresponding risk objects.

6. The relation density isolation storage method for multi-tenant graph databases according to claim 5, characterized in that, Edge explosion risk identification includes tenant-level edge explosion risk identification, specifically: The tenant-level edge explosion risk score is calculated based on the target tenant's global relation density, average number of adjacent extended edges, historical path query candidate edge amplification factor, historical query timeout or truncation ratio, and edge burst enhancement degree. When the tenant-level edge explosion risk score exceeds the tenant risk threshold, the risk object is determined to be the target tenant.

7. The relation density isolation storage method for multi-tenant graph databases according to claim 5, characterized in that, Edge explosion risk identification includes relation-level edge explosion risk identification, specifically: For each relation type in the target tenant, calculate the relation-level edge explosion risk score corresponding to the relation type based on the number of edges of the relation type, the relation density, the number of times the relation type is queried and hit, and the average amplification factor of the relation type in multi-hop expansion; When the risk score of edge explosion at the relation level exceeds the relation risk threshold, the risk object is determined to be the corresponding relation type.

8. The relation density isolation storage method for multi-tenant graph databases according to claim 5, characterized in that, Side-explosion risk identification includes entity-level side-explosion risk identification, specifically: For each entity in the target tenant, calculate the entity-level edge explosion risk score based on the entity degree, outgoing edge expansion quantity, path query participation frequency, and edge growth rate. When the entity-level edge explosion risk score exceeds the entity risk threshold, the risk object is determined to be the corresponding entity.

9. The relation density isolation storage method for multi-tenant graph databases according to claim 5, characterized in that, Side-explosion risk identification includes path-level side-explosion risk identification, specifically: For each path pattern in the target tenant, a path-level edge explosion risk score is calculated based on the average path expansion factor, candidate edge expansion factor, query timeout or truncation ratio, and query hit frequency of the path pattern. When the path-level edge explosion risk score exceeds the path risk threshold, the risk object is determined to be the corresponding path pattern.

10. A query method, characterized in that, Includes the following steps: Based on the query statement, a query is performed in the density isolation index to obtain the target index, which includes the corresponding tenant density index and the corresponding hotspot entity index; the density isolation index is the density isolation index generated by any one of the methods in claims 1-9. The query is performed based on each target index to obtain the corresponding query results.

Images