A cloud-edge collaborative query method and system for edge nodes

Abstract

The present application relates to the field of electronic digital processing technology, and in particular, to a method and system for collaborative querying of edge nodes based on cloud-edge collaboration. The method comprises: storing the data in the data set into each edge node respectively according to the size of the data in the data set and the correlation between the data; performing data backup, data removal or data migration on each edge node according to the historical data access frequency of each edge node and the correlation between the data; decomposing complex queries to obtain subqueries, and assigning the subqueries to edge nodes that match the data required by the subqueries; determining the performance score of the edge node running the subquery based on the workload of the edge node and the coverage of the local data and the feature set of the subquery; and unloading the subquery if the performance score does not meet the requirements. The present application significantly reduces communication overhead and improves reasoning efficiency through dynamic data placement, caching and task division.

Description

Technical Field

[0001] This application relates to the field of electronic digital processing technology, and more specifically, to an edge node collaborative query method and system based on cloud-edge collaboration. Background Technology

[0002] With the development of the Internet, the scale of data generated by the Semantic Web has expanded unprecedentedly, which places higher demands on the performance of ontology reasoning systems. Existing ontology reasoning systems have been studied for the reliability, completeness, and efficiency of reasoning results, and have achieved good results on small-scale ontology systems. However, there is a lack of design and development for large-scale ontology systems, and there is a lack of effective means to meet the requirements of large-scale ontology reasoning.

[0003] Large-scale ontology reasoning tasks mainly encounter the following problems: Edge nodes have limited physical storage resources, making it impossible to store large-scale data and perform computations. Furthermore, knowledge graphs are complete connected graphs, resulting in rules and data being distributed across different nodes in cloud-edge scenarios, posing a significant challenge to the reliability and completeness of ontology reasoning results. Simultaneously, complex queries require more rules and data to perform reasoning tasks, and the rules and data on a single node cannot meet the demands of complex queries. Therefore, it is necessary to request rules and data from other nodes or utilize the computing resources of other nodes for collaborative query computation, which poses a significant challenge to the efficiency of ontology reasoning.

[0004] In view of the above, this application is hereby submitted. Summary of the Invention

[0005] The purpose of this application is to provide a cloud-edge collaborative query method and system for edge nodes, which significantly reduces communication overhead and improves inference efficiency through dynamic data placement, caching and task partitioning.

[0006] To achieve the above objectives, this application adopts the following technical solution:

[0007] Firstly, this application provides a cloud-edge collaborative query method for edge nodes, including:

[0008] Based on the size of the data in the dataset and the correlation between the data, the data in the dataset are stored in each edge node respectively;

[0009] Based on the historical data access frequency and the correlation between data of each edge node, perform data backup, data removal or data migration for each edge node;

[0010] Complex queries are decomposed into subqueries, and the subqueries are assigned to edge nodes that match the data required by the subqueries.

[0011] The performance score of the edge node running the subquery is determined based on the workload of the edge node and the coverage of the feature set of the local data with the subquery.

[0012] If the performance score does not meet the requirements, then the subquery is unloaded.

[0013] Secondly, this application provides an edge node collaborative query system based on cloud-edge collaboration, including:

[0014] The cloud storage stores the data in the dataset into each edge node according to the size of the data in the dataset and the correlation between the data;

[0015] For each edge node, based on the historical access frequency of data and the correlation between data, data backup, data removal, or data migration are performed on each edge node;

[0016] In the cloud, complex queries are decomposed into subqueries, and the subqueries are assigned to edge nodes that match the data required by the subqueries.

[0017] For each edge node, a performance score is determined for running the subquery based on the edge node's workload and the coverage of local data with the feature set of the subquery; if the performance score does not meet the requirements, the subquery is unloaded.

[0018] Compared with the prior art, the beneficial effects of this application are as follows:

[0019] By analyzing data correlation and historical data access frequency, combined with dynamic caching and task partitioning mechanisms, the storage limitations and communication overhead in large-scale ontology reasoning can be solved, significantly improving reasoning efficiency and reducing network load, making it suitable for scenarios such as smart IoT. Attached Figure Description

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

[0021] Figure 1 This is a flowchart illustrating an edge node collaborative query method based on cloud-edge collaboration provided in an embodiment of this application. Detailed Implementation

[0022] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0023] Figure 1 This is a flowchart illustrating an edge node collaborative query method based on cloud-edge collaboration provided in this application embodiment. This embodiment is applicable to scenarios involving inference tasks in large-scale ontologies, specifically to scenarios such as the intelligent Internet of Things. See also Figure 1 This embodiment includes the following operations:

[0024] S110. Based on the size of the data in the dataset and the correlation between the data, store the data in the dataset into each edge node.

[0025] This step is executed in the cloud. First, data needs to be written to each edge node to complete the initial data storage. Considering the relationships between classes and attributes and the limited storage space of edge nodes, a balanced data storage method based on data correlation is proposed. This balances the storage load on edge nodes and effectively reduces data requests and data transfers between edge nodes during inference, thereby alleviating network bandwidth pressure. Specifically, this includes steps S111 to S112.

[0026] S111. When storing data at each edge node, select the data from the largest file in the current dataset for storage.

[0027] Each edge node stores data in the dataset sequentially, ensuring that each data point is stored at at least one edge node. For example, the data is organized as files. When edge node i stores data for the first time, it first selects the largest file A in the current dataset for storage. Then, edge node i+1 selects the largest file B in the current dataset (including only unstored data) for storage. This process continues, with all edge nodes sequentially and cyclically selecting the largest file from the current dataset for storage. Simultaneously, the remaining storage space for each edge node is calculated in real time.

[0028] S112. If the remaining storage space is less than the set space threshold, select data from the current dataset for storage in descending order of relevance to the stored data.

[0029] After several rounds of storage at edge node i, if the remaining storage space is less than the set space threshold for the first time, the correlation between the stored data and the unstored data in the current dataset is calculated, including: class correlation, attribute correlation, and class-attribute correlation.

[0030] First, define the degree of association between classes, attributes, and classes and attributes in the data. 1) Class association: A class is a subclass or equivalent class of another class, or classes appear in the same axiom; 2) Attribute association: An attribute is a sub-attribute, equivalent attribute, or inverse attribute of another attribute, or attributes appear in the same axiom; 3) Attribute association: A class is the domain or range of an attribute, or classes and attributes appear in the same axiom. Based on the above definitions, iterate through all axioms in the dataset and calculate the degree of association between classes, attributes, and classes and attributes. For example, the more times an attribute appears in the same axiom, the higher the degree of association, thus obtaining the degree of association between the data.

[0031] Select data that is highly correlated with the already stored data for storage.

[0032] This embodiment analyzes the centralized classes, attributes, and their relationships within a dataset, storing highly correlated data on the same edge node to reduce the frequency of cross-node data requests. Optimizing edge node storage is crucial for improving inference efficiency; this embodiment further reduces network bandwidth usage through correlation analysis. This embodiment dynamically adjusts data distribution, initially selecting the largest file to quickly fill node capacity, and subsequently prioritizing the storage of highly correlated data to avoid storage resource fragmentation and better adapt to heterogeneous storage environments on edge nodes. This embodiment supports large-scale ontology inference: overcoming the limitations of traditional methods in small-scale ontology scenarios, it optimizes data distribution through correlation analysis, supporting efficient inference scenarios for ultra-large-scale knowledge graphs.

[0033] S120. Based on the historical access frequency of each edge node and the correlation between data, perform data backup, data removal, or data migration for each edge node.

[0034] Because some data stored on edge nodes may be irrelevant to queries, and this data occupies the limited storage space of the edge nodes, edge nodes cannot store data that needs to be frequently requested from other nodes. Based on this, S120 proposes a dynamic caching strategy based on access frequency to maintain the data storage of edge nodes, based on the workload of edge node query processing. By analyzing the historical query load of edge nodes, it determines whether data on edge nodes should be retained, migrated to other edge nodes, or backed up on other edge nodes, thereby reducing the load on edge nodes and data transmission.

[0035] Optionally, S120 includes S121, S122 and S123.

[0036] S121. Based on the historical access frequency of data for each edge node, determine the high-frequency data list and low-frequency data list for each edge node. The high-frequency data list includes multiple high-frequency data items, and the low-frequency data list includes multiple low-frequency data items.

[0037] For an edge node, first calculate the ratio of the number of times each data was accessed in the past (e.g., the previous inference cycle) to the total number of data accesses, to obtain the historical access frequency of each data point:

[0038] ;

[0039] in, It is the historical access frequency of each data point obtained at time t+1. , These are the data at time t of the previous inference cycle. The number of visits to the data and the total number of visits to the data.

[0040] The historical access frequency of each data item in the edge node is sorted from high to low, and the data is added to the high-frequency data list in descending order until the total amount of added data exceeds the storage space of the edge node. The remaining data is then stored in the low-frequency data list.

[0041] S122. Traverse the high-frequency data list. If the edge node does not store high-frequency data, request the high-frequency data and data whose correlation with the high-frequency data exceeds a set value from other edge nodes.

[0042] This step backs up high-frequency data that is not stored on this edge node, as well as its associated data, by requesting this data from other edge nodes. Specifically, it calculates the correlation between high-frequency data and other data, and identifies data with a correlation exceeding a set value as its associated data.

[0043] S123. Traverse the low-frequency data list. If the edge node stores low-frequency data, determine the number of replicas of the low-frequency data. If the number of replicas is 1, migrate the low-frequency data to other edge nodes. If the number of replicas is greater than 1, remove the low-frequency data.

[0044] When migrating low-frequency data to other edge nodes, it is necessary to select appropriate edge nodes. Optionally, the used storage space, total storage space, and CPU utilization of each other edge node are obtained; based on the used storage space, total storage space, and CPU utilization, the space health of each other edge node is calculated. See the following formula:

[0045] ;

[0046] in, It is the central processing unit utilization rate. This is the used storage space. This refers to the total storage space.

[0047] The spatial health of other edge nodes in the system is calculated and sorted. The edge node with the highest spatial health will be selected as the object of data migration in order to maintain the integrity of the system.

[0048] In this embodiment, high- and low-frequency data are dynamically divided based on access frequency. High-frequency data and its highly correlated components are prioritized for caching to improve cache hit rate. Redundant transmission is further reduced through correlation expansion. A node space health metric (a comprehensive assessment of storage utilization and CPU load) is introduced to optimize the selection strategy for low-frequency data migration targets, significantly reducing node overload risk and ensuring system stability. Dynamic operations for data backup, removal, and migration adapt to scenarios with changing query loads, and automated processes improve storage resource utilization.

[0049] S130. Decompose the complex query to obtain subqueries, and assign the subqueries to edge nodes that match the data required by the subqueries.

[0050] Given a complex SPARQL query, the complex query is first decomposed into subtasks. Then, appropriate nodes are selected to offload the inference subtasks based on workload and edge node data coverage.

[0051] SPARQL is a query language for querying RDF (Resource Description Framework) data. It supports various query types and allows users to retrieve data using pattern matching, filtering constraints, aggregate functions, and nested queries. When decomposing complex SPARQL queries, they can be broken down into multiple subqueries with the same subject. For example, a complex query aims to retrieve information on all publishers, where each publisher's name and address come from a different namespace. This complex query can be decomposed into two subqueries, one retrieving the publisher's name and the other retrieving their address, both with "publisher" as their subject.

[0052] Optionally, this step includes S131 to S135.

[0053] S131. Based on the feature set of the complex query, the complex query is decomposed into multiple sub-queries.

[0054] S132. Add the triplet patterns involved in the subject variable of each subquery to the feature set of the corresponding subquery.

[0055] In Semantic Web and SPARQL queries, a feature set refers to the collection of triple patterns associated with a specific subject variable. These triple patterns are the basic units that constitute a SPARQL query (subject-verb-object, including class and attribute in this embodiment). For example, when a query needs to retrieve all attributes of a subject, all triple patterns related to that subject (i.e., combinations of subject, verb, and object) are considered a feature set. This decomposition helps break down complex queries into smaller subqueries, facilitating optimization and processing.

[0056] Specifically, given a complex query Q, we first iterate through the triple patterns in Q, classify the triple patterns according to the subject variable to obtain multiple feature sets, and add them to the corresponding subqueries. Thus, a subquery includes the feature set of the same specific subject variable.

[0057] S133. Cluster the feature sets of multiple subqueries to obtain feature sets of multiple center points and subqueries; the number of center points is the same as the number of edge nodes.

[0058] Select a number of edge nodes and centroids from the feature sets of multiple subqueries; calculate the coverage ratio between the feature set of each subquery and the feature sets of each centroid, and add each subquery and its feature set to the centroid with the highest coverage ratio. Assuming there are 10 subqueries and 4 edge nodes, select the feature sets of 4 centroids from the feature sets of the 10 subqueries, and then classify the feature sets of the remaining 6 subqueries into the feature sets of the 4 centroids.

[0059] Specifically, from the feature sets of all subqueries, the feature set of the first centroid (any feature set of a subquery) is randomly determined. Then, the feature set of the second centroid, which is furthest from the first centroid, is selected, and so on, selecting feature sets of multiple centroids sequentially based on the number of edge nodes. The distance between centroid feature sets can be determined based on the correlation between them (lower correlation results in greater distance) or semantic similarity. Then, the remaining subqueries are traversed, and the coverage ratio between the feature set of each remaining subquery and the feature set of each centroid is calculated. Each subquery and its feature set are added to the centroid with the highest coverage ratio. The coverage ratio between two feature sets can be obtained using the following formula:

[0060] ;

[0061] in, It is the coverage of two feature sets. It is the data in the feature set of the subquery. This represents the total amount of data in this feature set. It is the data set of features of the center point. This indicates the number of identical data points contained in the two feature sets. Thus, a feature set with four centroids is obtained, which may include feature sets from multiple subqueries.

[0062] S134. Based on the semantic similarity or coverage of the feature set of each center point and the data of each edge node, determine the edge nodes that match the feature set of each center point.

[0063] S135. Assign the feature set and subquery of each center point to the matching edge nodes.

[0064] The feature set of the centroid originates from the decomposition of complex queries and the triple patterns involved in the subject variables, clearly reflecting the query intent of the centroid (including multiple subqueries). The semantic similarity or coverage rate between the data of each edge node and the centroid feature set is calculated. For example, the cosine of the angle between any data point on an edge node and any triple pattern on the centroid is calculated, yielding the cosine value of any data point and triple pattern. The average of these cosine values ​​yields the semantic similarity between the centroid feature set and the edge nodes. The centroid feature set and its subqueries are then assigned to the edge nodes with the highest semantic similarity. Calculating semantic similarity helps identify the edge nodes that best match the data required by the centroid. For example, the data list of each edge node is queried, and the coverage rate between the centroid feature set and the data list is calculated. Referring to the formula above, the numerator is the number of data points in the intersection of the two sets, and the denominator is the total number of data points in the data list. The edge node to which the data list with the highest coverage rate belongs is determined.

[0065] For edge nodes, calculate the pairwise semantic similarity between all assigned subquery feature sets. When the semantic similarity of subquery feature sets sent to the same edge node is high, merge the feature sets of the subqueries (which may come from different center points) to avoid redundant reasoning calculations.

[0066] S140. Determine the performance score of the edge node running the subquery based on the workload of the edge node and the coverage of the feature set of the local data with the subquery.

[0067] S150. If the performance score does not meet the requirements, then unload the subquery.

[0068] In distributed computing, "offloading" is a specialized term referring to transferring computing tasks from resource-constrained devices (edge ​​nodes) to resource-rich devices (other nodes / the cloud). Here, "offloading a subquery" means that when an edge node determines, based on its performance score, that it cannot effectively run a certain subquery, it removes that subquery from its task queue, so that the current edge node no longer processes that subquery task.

[0069] When the feature sets of multiple subqueries are sent to edge nodes that are not related to the data required by the subqueries, the edge nodes need to frequently request a large amount of data from other nodes for query processing, which will consume a lot of network bandwidth and cause network congestion. Therefore, it is necessary to consider sending the subqueries to edge nodes that match the data they need, so as to minimize the number of data requests.

[0070] This embodiment offloads subquery tasks based on data coverage and workload. Optionally, the performance score for running subqueries on edge nodes is calculated according to the following formula:

[0071] ;

[0072] in, It is the performance score of running subquery j at edge node i. is a hyperparameter, It is the coverage ratio of the local data of edge node i to the feature set of subquery j. It is the CPU utilization of edge node i.

[0073] The workload of edge nodes affects their inference efficiency, while data coverage affects data transmission between nodes. Therefore, a hyperparameter was designed. This is used to maintain the relationship between workload and data transmission impact on system performance. As data volume increases, data transmission will have a greater impact on the performance of edge nodes, and therefore should be increased. The value should be reduced; conversely, it should be decreased. The value of this parameter takes into account the impact of workload on system performance. This invention adaptively calculates the performance score of subqueries run by edge nodes; this value varies with the dataset size, and is a hyperparameter. Calculate using the following formula:

[0074] ;

[0075] in, It is the total size of the data stored in edge node i. It is the memory size of edge node i.

[0076] If the performance score is less than the threshold, it means that the edge node i cannot run the subquery j. Subquery j needs to be unloaded, and the subquery j and its feature set need to be migrated to other edge nodes. The performance score of the migrated edge node running the subquery j should meet the requirements.

[0077] This embodiment has the following technical effects: 1) Task partitioning and load balancing: It selects offloading targets by combining data coverage and node load. Task offloading needs to consider data locality; this strategy reduces cross-node data transmission volume through subquery partitioning and cluster analysis. 2) Dynamic parameter adaptive adjustment: It introduces hyperparameters to dynamically balance the impact of data coverage and load based on dataset size and node resources, significantly improving system robustness. 3) Efficient processing of complex queries: Through subquery merging and centroid selection mechanisms, it avoids repetitive inference calculations, effectively reducing the response time of complex queries.

[0078] Optionally, this embodiment also provides an edge node collaborative query system based on cloud-edge collaboration, including a cloud and multiple edge nodes that are communicatively connected to the cloud;

[0079] In the cloud, based on the size of the data in the dataset and the correlation between the data, the data in the dataset is stored in each edge node respectively;

[0080] For each edge node, based on the historical access frequency of data and the correlation between data, data backup, data removal, or data migration are performed on each edge node;

[0081] In the cloud, complex queries are decomposed into subqueries, and the subqueries are assigned to edge nodes that match the data required by the subqueries.

[0082] For each edge node, a performance score is determined for running the subquery based on the edge node's workload and the coverage of local data with the feature set of the subquery; if the performance score does not meet the requirements, the subquery is unloaded.

[0083] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired means, such as coaxial cable, optical fiber, digital subscriber line (DSL), or wireless means, such as infrared, wireless, microwave, etc. The computer-readable storage medium can be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium, or a semiconductor medium, etc. It is worth noting that the computer-readable storage medium mentioned in the embodiments of this application can be a non-volatile storage medium, in other words, it can be a non-transient storage medium.

[0084] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.

[0085] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A collaborative query method for edge nodes based on cloud-edge collaboration, characterized in that, include: Based on the size of the data in the dataset and the correlation between the data, the data in the dataset are stored in each edge node respectively; Based on the historical data access frequency and the correlation between data of each edge node, perform data backup, data removal or data migration for each edge node; Complex queries are decomposed into subqueries, and the subqueries are assigned to edge nodes that match the data required by the subqueries. The performance score of the edge node running the subquery is determined based on the workload of the edge node and the coverage of the feature set of the local data with the subquery. If the performance score does not meet the requirements, then the subquery is unloaded; Specifically, based on the historical data access frequency and the correlation between data at each edge node, data backup, data removal, or data migration is performed on each edge node, including: Based on the historical access frequency of each edge node's data, a high-frequency data list and a low-frequency data list are determined for each edge node; the high-frequency data list includes multiple high-frequency data items, and the low-frequency data list includes multiple low-frequency data items. Traverse the high-frequency data list. If the edge node does not store high-frequency data, request the high-frequency data and data whose correlation with the high-frequency data exceeds a set value from other edge nodes. Traverse the list of low-frequency data. If the edge node stores low-frequency data, determine the number of replicas of the low-frequency data. If the number of replicas is 1, migrate the low-frequency data to other edge nodes. If the number of replicas is greater than 1, remove the low-frequency data.

2. The edge node collaborative query method based on cloud-edge collaboration according to claim 1, characterized in that, Based on the size of the data in the dataset and the correlation between the data, the data in the dataset is stored in each edge node, including: When storing data at each edge node, the data from the largest file in the current dataset is selected for storage; the current dataset only includes data that has not yet been stored. If the remaining storage space is less than the set space threshold, select data from the current dataset for storage in descending order of relevance to the already stored data. The degree of association includes class association, attribute association, and class-attribute association.

3. The edge node collaborative query method based on cloud-edge collaboration according to claim 1, characterized in that, Migrating the low-frequency data to other edge nodes includes: Obtain the used storage space, total storage space, and CPU utilization of each other edge node; The space health of each of the other edge nodes is calculated based on the used storage space, total storage space, and CPU utilization. The low-frequency data is migrated to other edge nodes with the highest spatial health.

4. The edge node collaborative query method based on cloud-edge collaboration according to claim 1, characterized in that, Decomposing complex queries into subqueries and assigning the subqueries to edge nodes that match the data required by the subqueries includes: Based on the feature set of the complex query, the complex query is decomposed into multiple sub-queries; Add the triplet patterns involved in the subject variable of each subquery to the feature set of the corresponding subquery; Clustering is performed on the feature sets of multiple subqueries to obtain feature sets of multiple centroids and subqueries; the number of centroids is the same as the number of edge nodes. Based on the similarity between the feature set of each center point and the data of each edge node, determine the edge nodes that match the feature set of each center point; Assign the feature set and subquery of each center point to the matching edge nodes.

5. The edge node collaborative query method based on cloud-edge collaboration according to claim 4, characterized in that, Clustering the feature sets of multiple subqueries yields feature sets and subqueries with multiple centroids, including: Select the number of edge nodes and center points from the feature set of multiple subqueries; Calculate the coverage ratio of the feature set of each subquery to the feature set of each centroid, and add each subquery and feature set to the centroid with the highest coverage ratio.

6. The edge node collaborative query method based on cloud-edge collaboration according to claim 5, characterized in that, Based on the workload of the edge node and the coverage of local data with the feature set of the subquery, a performance score for the edge node running the subquery is determined, including: Calculate the performance score of the edge node running the subquery according to the following formula: Among them, Score ij It is the performance score of running subquery j at edge node i, where α is a hyperparameter, and Coverage is the performance score. ij It is the coverage ratio of the local data of edge node i to the feature set of subquery j. It is the CPU utilization of edge node i.

7. The edge node collaborative query method based on cloud-edge collaboration according to claim 6, characterized in that, The hyperparameter α is calculated using the following formula: Among them, DataSet size It is the total size of the data stored in edge node i. memory It is the memory size of edge node i.

8. An edge node collaborative query system based on cloud-edge collaboration, characterized in that, include: The cloud and multiple edge nodes that communicate with the cloud; The cloud storage stores the data in the dataset into each edge node according to the size of the data in the dataset and the correlation between the data; For each edge node, based on the historical access frequency of data and the correlation between data, data backup, data removal, or data migration are performed on each edge node; In the cloud, complex queries are decomposed into subqueries, and the subqueries are assigned to edge nodes that match the data required by the subqueries. For each edge node, a performance score is determined for running the subquery based on the edge node's workload and the coverage of local data with the feature set of the subquery. If the performance score does not meet the requirements, then the subquery is unloaded; Specifically, based on the historical data access frequency and the correlation between data at each edge node, data backup, data removal, or data migration is performed on each edge node, including: Based on the historical access frequency of each edge node's data, a high-frequency data list and a low-frequency data list are determined for each edge node; the high-frequency data list includes multiple high-frequency data items, and the low-frequency data list includes multiple low-frequency data items. Traverse the high-frequency data list. If the edge node does not store high-frequency data, request the high-frequency data and data whose correlation with the high-frequency data exceeds a set value from other edge nodes. Traverse the list of low-frequency data. If the edge node stores low-frequency data, determine the number of replicas of the low-frequency data. If the number of replicas is 1, migrate the low-frequency data to other edge nodes. If the number of replicas is greater than 1, remove the low-frequency data.

Images