Partition recognition method, storage system, electronic device, and storage medium

Abstract

Provided in the embodiments of the present disclosure are a partition recognition method, a storage system, an electronic device, and a storage medium. In the embodiments of the present disclosure, access operation types supported by a plurality of data partitions in a distributed storage system and a plurality of pieces of access feature data generated thereby are both taken into consideration; then, on the basis of the plurality of pieces of collected access feature data respectively generated by the plurality of data partitions and the collected access operation types supported thereby, access popularity data of the plurality of data partitions in the access operation types is generated; and on the basis of the access popularity data, a target data partition meeting access popularity requirements is selected. Therefore, access feature data and access operation types are taken into comprehensive consideration during recognition of a hotspot partition, thereby improving the precision of hotspot partition recognition.

Description

Partition identification method, storage system, electronic device and storage medium

[0001] This disclosure claims priority to the Chinese patent application filed with the China Patent Office on December 4, 2023, with application number 202311650510.9 and application name “Partition Identification Method, Storage System, Electronic Device and Storage Medium”, the entire contents of which are incorporated by reference in this disclosure. Technical Field

[0002] The present disclosure relates to the field of storage technology, and in particular to a partition identification method, a storage system, an electronic device, and a storage medium. Background Art

[0003] The emergence of non-relational (Not Only SQL, NoSQL) databases addresses the challenges posed by large-scale data sets and diverse data types. Table storage, a type of NoSQL database, provides table storage services for structured data in scenarios such as massive billing, instant messaging, the Internet of Things (IoT), the Internet of Vehicles (IoV), risk control, and recommendations.

[0004] In Table Store, data is organized in tables. Data sharding is used to divide a table into multiple partitions, and load balancing is used to dispatch these partitions to different storage devices for external services. To achieve optimal table access performance, the read and write traffic and data volume across these partitions should be distributed as evenly as possible. In practice, data skew often occurs, where some partitions are accessed much more frequently than others due to various reasons, resulting in suboptimal access performance.

[0005] Some existing solutions prevent data skew caused by hotspot partitions by rationally designing table structures or partitioning tables. However, due to the varying levels of user experience in table creation and the high volatility of access, preventing hotspot partitions through table design and pre-partitioning is difficult. This makes it crucial to dynamically address hotspot partitions during access. However, accurately identifying hotspot partitions is crucial in dynamically addressing hotspot partitions.

[0006] Summary of the Invention

[0007] Various aspects of the present disclosure provide a partition identification method, a storage system, an electronic device, and a storage medium, for improving the accuracy of identifying hotspot partitions in the process of dynamically solving hotspot partition problems.

[0008] An embodiment of the present disclosure provides a partition identification method, comprising: collecting multiple access feature data generated by each of multiple data partitions in a distributed storage system, where the multiple access feature data are feature data generated by access operations performed on the data partitions; generating access heat data for the multiple data partitions under each access operation type based on the multiple access feature data generated by each of the multiple data partitions and the supported access operation types; and identifying a target data partition whose access heat meets the requirements based on the access heat data for the multiple data partitions under each access operation type.

[0009] An embodiment of the present disclosure also provides a storage system, including at least one storage node, on which at least one data partition from at least one data table is stored; the storage system also includes: a partition identification node; the partition identification node is used to collect multiple access feature data generated by each of multiple data partitions in the distributed storage system, the multiple access feature data being feature data generated by access operations performed on the data partitions; based on the multiple access feature data generated by each of the multiple data partitions and the supported access operation types, access heat data of the multiple data partitions under each access operation type is generated; based on the access heat data of the multiple data partitions under each access operation type, a target data partition whose access heat meets the requirements is identified.

[0010] An embodiment of the present disclosure further provides an electronic device, comprising: a memory and a processor; the memory is used to store a computer program; the processor is coupled to the memory and is used to execute the computer program to implement the steps in the above method.

[0011] The embodiments of the present disclosure further provide a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the processor is caused to implement the steps in the above method.

[0012] The embodiment of the present disclosure further provides a computer program product, including a computer program, which implements the steps in the above method when executed by a processor.

[0013] The technical solution provided by the embodiments of the present disclosure collects access feature data generated by each of the multiple data partitions in a distributed storage system, generates access heat data of the multiple data partitions under each access operation type based on the multiple access feature data generated by each of the collected multiple data partitions and the access operation types supported, and based on this, selects a target data partition that meets the access heat requirements based on the access heat data of the multiple data partitions under each access operation type, and comprehensively considers the access feature data and the access operation type when identifying the hotspot partition, thereby improving the accuracy of identifying the hotspot partition. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The drawings described herein are used to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The exemplary embodiments of the present disclosure and their descriptions are used to explain the present disclosure and do not constitute an improper limitation of the present disclosure. In the drawings:

[0015] FIG1a is a schematic structural diagram of a distributed storage system provided by an embodiment of the present disclosure;

[0016] FIG1b is a schematic structural diagram of another distributed storage system provided by an embodiment of the present disclosure;

[0017] FIG1c is a schematic structural diagram of another distributed storage system provided by an embodiment of the present disclosure;

[0018] FIG2 is a schematic diagram of table partitioning provided by an embodiment of the present disclosure;

[0019] FIG3 is a schematic diagram of a hotspot partitioning process provided by an embodiment of the present disclosure;

[0020] FIG4 is a schematic diagram of a flow chart of a partition identification method provided by an embodiment of the present disclosure;

[0021] FIG5 is a schematic flow chart of another partition identification method provided by an embodiment of the present disclosure;

[0022] FIG6 is a schematic structural diagram of a partition identification device provided in an embodiment of the present disclosure;

[0023] FIG7 is a schematic diagram of the structure of a storage system provided by an embodiment of the present disclosure;

[0024] FIG8 is a schematic structural diagram of an electronic device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0025] To make the objectives, technical solutions, and advantages of the present disclosure more clear, the technical solutions of the present disclosure will be clearly and completely described below in conjunction with the specific embodiments of the present disclosure and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present disclosure.

[0026] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0027] In the process of dynamically solving the hotspot partition problem, how to accurately identify the hotspot partition becomes a key issue that needs to be solved urgently. In the embodiment disclosed herein, the access operation types supported by multiple data partitions in the distributed storage system and the access feature data generated are considered simultaneously; by collecting the access feature data generated by each of the multiple data partitions, according to the multiple access feature data generated by each of the collected multiple data partitions and the access operation types supported, the access heat data of the multiple data partitions under each access operation type is generated. Based on this, the target data partition that meets the access heat requirements is selected, and the access feature data and access operation type are comprehensively considered when identifying the hotspot partition, thereby improving the accuracy of identifying the hotspot data partition.

[0028] The technical solutions provided by various embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0029] Figures 1a-1c illustrate a framework diagram of a distributed storage system provided by an embodiment of the present disclosure. In the embodiments of the present disclosure, the product implementation form of the distributed storage system is not limited. For example, it can be implemented as various non-relational database products, and further implemented as, but not limited to, a distributed table storage system, a remote dictionary server (Remote Dictionary Server, Redis) system, or a column-oriented database system. As shown in Figures 1a-1c, regardless of the specific storage product implemented, the distributed storage system can include proxy nodes 11, master nodes 12, and storage nodes 13.

[0030] The proxy node 11 serves as an interactive interface between the user and the distributed storage system, and may be, for example, an Application Programming Interface (API) or a Software Development Kit (SDK) of the distributed storage system. The proxy node 11 is responsible for receiving various user demands for the distributed storage system, such as receiving user requests to create data tables and receiving user demands to access data tables, and providing the user's various demands to the master node 12 in the distributed storage system so that the master node 12 can respond to the user's various demands and provide corresponding services to the user, such as creating data tables for the user and providing read and write services for the data tables. In this embodiment, the user refers to the user of the distributed storage system, and may be, for example, an individual user, a company, or various institutions, and the user of the distributed storage system may be one or more of the user's applications, application systems, or a functional module in the application system, etc.

[0031] It should be noted that the proxy node 11 is an optional component. The distributed storage system may not include the proxy node 11, but the user directly interacts with the master node 12.

[0032] The master node 12 is the node responsible for scheduling in the distributed storage system. On the one hand, it is responsible for receiving various user requirements for the distributed storage system provided by the client 11 or directly provided by the user, such as the requirement to create a data table and read and write requests for the data table; on the other hand, it is responsible for responding to various user requirements and scheduling the corresponding storage nodes 13 to provide users with data storage and read and write services. For example, when the master node 12 receives a requirement to create a data table, it can create a data table for the user, and the data table has a unique identifier. For another example, when the master node 12 receives a read and write request for a data table, it can provide the read and write request to the corresponding storage node 13, and the storage node 13 performs the data read and write operation and returns the data read and write result to the user. In actual applications, one or more master nodes 12 can be deployed in a distributed storage system. For example, when multiple master nodes 12 are deployed, three can be deployed, but this is not limited to this.

[0033] Storage nodes 13 are responsible for data storage in a distributed storage system. They store data and respond to user read and write requests, executing read and write operations based on those requests and returning read and write results. Storage nodes 13, also known as worker nodes, are relatively numerous compared to master nodes 12. The specific number depends on the scale of the distributed storage system and can range from dozens to hundreds or even thousands, though this is not a limitation.

[0034] In the distributed storage system provided in this embodiment, partitioning technology can be used, that is, the overall data can be divided into multiple data partitions (referred to as partitions for short). Under the scheduling of the master node 12, these partitions are dispersed and stored on different storage nodes 13, which is conducive to improving the concurrent access capability of the distributed storage system, and thus improving the overall service capability of the distributed storage system. Depending on the different product implementation forms of the distributed storage system, the implementation form of the overall data will also be different. For example, in a table storage system or a column-oriented database product, data is stored in the form of data tables, and the overall data that can be partitioned can specifically be a data table, that is, a data table can be divided into multiple partitions. In this embodiment, the partitioning operation can be performed by the master node 12, and the master node 12 can divide the overall data into multiple partitions according to the data range, and schedule these partitions to different storage nodes 13 for storage according to a certain scheduling strategy.

[0035] Furthermore, as shown in Figures 1a-1c, the distributed storage system also includes a load balancing node 14, which is used to assist the master node 12 in distributing the workload of the distributed storage system to different storage nodes, thereby improving the service performance and reliability of the distributed storage system. For example, the load balancing node 14 can distribute the multiple partitions divided by the master node 12 to different storage nodes 13 for storage, or can distribute user read and write requests to different storage nodes 13. In this way, if a storage node 13 fails, the data distributed on other storage nodes can still be accessed normally, which is beneficial to improving the service performance and reliability of the distributed storage system.

[0036] Among them, according to the different product implementation forms of the distributed storage system, the way in which the master node 12 divides the overall data into multiple partitions will also be different. Taking table storage as an example, as shown in Figure 2, in table storage, each data table includes multiple rows (row) and multiple columns (column), and each data table includes one or more primary key columns (Primary Key) and ordinary columns (Column). In the embodiment of the present disclosure, a column of the primary key column is defined as a sharding key (Partition Key). In Figure 2, the first column in the primary key column is defined as the sharding key. When splitting the partitions, the partitioning can be performed according to the sharding key. Data with the same sharding key is split into the same partition. Of course, the sharding keys of data on the same partition can be different. As shown in Figure 2, the data table is divided into three partitions: Partition A, Partition B, and Partition C.

[0037] In practical applications, it's common to encounter situations where user access requests are concentrated on a certain data range. That is, the data requested by users is concentrated on certain shard keys. Specifically, this means that the user's access requests are concentrated on one or a few partitions. If the access volume is large enough, it can easily exceed the capacity limit of a single partition or a single storage node, resulting in access errors. This phenomenon is called hot spot access, and the partition being accessed is called a hot spot partition. The access imbalance caused by hot spot partitions is called data skew. For example, in the e-commerce field, products participating in flash sales will receive a large number of visits, which will lead to a large number of visits to the partition containing the product information. With a large number of users requesting access to this partition, this partition will become a hot spot partition and, in turn, a performance bottleneck for the entire system, affecting system performance.

[0038] In order to solve the data skew problem caused by hotspot partitions, in the embodiments of the present disclosure, at least one of the following methods can be used:

[0039] Method 1: During data table design, properly design the table structure, such as properly designing the primary key column and shard key, to reduce the probability of hotspot partitions.

[0040] Method 2: After creating the table, partition the data table appropriately to distribute popular data to different partitions as much as possible to reduce the probability of hotspot partitions.

[0041] Method 3: During dynamic access, dynamically identify hot partitions and split them to promptly detect and process them, reducing data skew caused by them.

[0042] Methods 1-3 described above can be implemented at different stages. In practical applications, one or more can be selected, or a combination of two or more can be used. This is not a limitation. Considering that data tables are constructed by users, who may not have in-depth professional knowledge, method 1 can be flexibly selected based on their expertise and capabilities. Method 2 can only estimate data popularity in advance and partition it as reasonably as possible. However, since user access behavior changes dynamically and unpredictably with application needs, it can only reduce the probability of hotspot partitions to a certain extent. Method 3, on the other hand, can dynamically and promptly discover and process hotspot partitions, making it a primary means of resolving hotspot partitioning issues.

[0043] In this embodiment, a hotspot partition detection service can be deployed in a distributed storage system, and the hotspot partition detection service can solve the hotspot partition problem during the dynamic access process of the distributed storage system. In this embodiment, the deployment implementation method of the hotspot partition detection service is not limited. As shown in Figure 1a, the hotspot partition detection service can be deployed on the master node, or as shown in Figure 1b, the hotspot partition detection service can also be deployed on the load balancing node, or as shown in Figure 1c, the hotspot partition detection service can also be independently deployed as a new functional node. Regardless of the system architecture, the principles and processes of the hotspot partition detection service when performing hotspot partition identification are the same. In the following embodiments, the process of the hotspot partition detection service solving the hotspot partition problem will be described in conjunction with Figure 3.

[0044] As shown in Figure 3, no matter how the hotspot partition detection service is deployed and implemented, when solving the hotspot partition problem, multiple access feature data generated by each data partition distributed on each storage node can be collected. These access feature data are feature data generated by access operations on data partitions; then, at least the hotspot partitions are identified based on these access feature data; then, corresponding splitting or migration plans are given for the identified hotspot partitions and splitting or migration operations are performed according to the splitting or migration plans. Among them, how to accurately identify hotspot partitions is the key to solving the hotspot partition problem in the dynamic access process. In the embodiment of the present disclosure, in order to improve the accuracy of identifying hotspot partitions, a hotspot partition identification scheme based on comprehensive indicators is proposed, which can efficiently and accurately identify hotspot partitions, provide a basis for the subsequent automatic or manual splitting of hotspot partitions, assist downstream splitting operations in a timely and accurate manner, and can effectively reduce the errors and performance losses caused by hotspot partition problems, and cope with the challenges brought by hotspot partition problems. In the following embodiments, the hotspot partition identification process will be described in detail with reference to the accompanying drawings.

[0045] FIG4 is a flow chart of a partition identification method provided in an embodiment of the present application. As shown in FIG4 , the method includes:

[0046] 401. Collect multiple access feature data generated by multiple data partitions in a distributed storage system, where the multiple access feature data are feature data generated by access operations performed on the data partitions.

[0047] 402. Generate access popularity data for the multiple data partitions under each access operation type based on the multiple access feature data generated by each of the multiple data partitions and the access operation types supported;

[0048] 403. According to the access popularity data of the plurality of data partitions under various access operation types, a target data partition whose access popularity meets the requirements is identified.

[0049] In this embodiment, the distributed storage system includes at least one storage node. One storage node can store at least one data partition from at least one data table. In other words, one storage node stores one or more data partitions. These data partitions can come from the same data table or from multiple different data tables. Furthermore, these data tables can come from the same user or from different users.

[0050] In this embodiment, multiple data partitions in a distributed storage system can be identified to identify a target data partition whose access popularity meets the requirements. In this embodiment, both a highly popular data partition and a less popular data partition can be identified as the target data partition. In short, both popular and unpopular data partitions can be identified, depending on the partition identification requirements.

[0051] In this embodiment, the data partitions involved in partition identification are not limited. For example, all data partitions in the distributed storage system can be included, or some of them can be included, and the identification can be flexibly determined based on application requirements. In an optional embodiment, partition identification requirement information can be obtained, and based on the partition identification requirement information, multiple data partitions in the distributed storage system that require partition identification can be determined. Depending on the partition identification requirements, the multiple data partitions determined will also vary.

[0052] For example, in some application scenarios, it is necessary to identify the data partitions on each storage node. In this case, the data partitions distributed on the same storage node can be used as multiple data partitions that need to be identified. Then, from the dimension of each storage node, the target data partitions on each storage node whose access heat meets the requirements can be identified.

[0053] In other application scenarios, it is necessary to identify data partitions on specific storage nodes. Data distributed on a specific storage node can be grouped as multiple data partitions requiring partition identification. This allows the identification of target data partitions on the specific storage node that meet the required access popularity. The specific storage node can be flexibly determined based on application requirements. For example, it can be a heavily loaded storage node, a storage node storing specific user data, or a storage node distributed in a specific availability zone.

[0054] In some other application scenarios, it is necessary to identify data partitions in the same data table. The data partitions from the same data table can be used as multiple data partitions that need to be identified, and then the target data partitions in the same data table whose access popularity meets the requirements can be identified based on the dimensions of the data table.

[0055] In some other application scenarios, it is necessary to identify data partitions in the data tables of one or more specific tenants. The data partitions from the data tables of one or more specific tenants can be used as multiple data partitions that need to be partitioned. Then, from the dimension of the specific tenant, the target data partitions in the data tables of the specific tenants whose access popularity meets the requirements can be identified.

[0056] In this embodiment, accessing a data partition generates various access characteristic data. These access characteristic data are characteristic data generated by accessing a data partition, including but not limited to: the number of read operations on the data partition, the amount of data read each time, the sum of the amount of data read by all read operations, and the number of write operations on the data partition, the amount of data written each time, the sum of the amount of data written by all write operations, etc. Among them, accessing a data partition can generate a large amount of access characteristic data. In this embodiment, multiple access characteristic data suitable for partition identification can be selected from them, and then the selected multiple access characteristic data suitable for partition identification can be collected. Among them, the access characteristic data suitable for partition identification are characteristic data that can reflect the consumption or occupation of storage node resources when accessing a data partition, mainly including access characteristic data related to the number of read and write operations and access characteristic data related to the amount of read and write data. Depending on the different product forms of the distributed storage system, these access characteristic data will have different names or definitions, which will be illustrated in the subsequent embodiments.

[0057] In this embodiment, multiple access feature data may change over time. In order to ensure the timeliness of multiple access feature data of multiple data partitions, multiple access feature data generated by multiple data partitions in the distributed system can be collected. In this embodiment, the implementation method of collecting multiple access feature data generated by multiple data partitions is not limited. For example, a plug-in, API or SDK with data collection function can be deployed on each storage node, and multiple access feature data generated by the corresponding data partition on the storage node can be collected through the plug-in, API or SDK. In this embodiment, multiple access feature data generated by multiple data partitions in the distributed storage system can be periodically collected, and the length of the collection period is not limited. The collection period is generally in seconds or finer granularity, for example, it can be 1s or 0.5s, etc., which can be flexibly determined according to application requirements. Of course, multiple access feature data generated by multiple data partitions in the distributed storage system can also be continuously collected. Furthermore, no matter which collection method is adopted, the collected access feature data can also be stored.

[0058] In this embodiment, multiple data partitions can support multiple access operation types, and the multiple access operation types include at least two major types: read operations and write operations; further optionally, read operations and write operations can be subdivided according to application requirements to obtain more fine-grained access operation types. There is no limitation on the method of subdividing read operations and write operations. In an optional embodiment, read operations can be further divided according to the attribute information of the read operation, and the attribute information of the read operation includes but is not limited to the object read, the time of reading, and the method of reading. Correspondingly, write operations can also be further divided according to the attribute information of the write operation, and the attribute information of the write operation includes but is not limited to the object written, the time of writing, and the method of writing. Among them, according to the attribute information of the read operation, the read operation can be further divided into read operation 1, read operation 2, read operation 3, or more types of read operations; similarly, according to the attribute information of the write operation, the write operation can be further divided into write operation 1, write operation 2, write operation 3, or more types of write operations.

[0059] For example, write operations can be further subdivided into batch writes and non-batch writes based on the write operation method. Batch writes refer to writing multiple data items to a data partition simultaneously; non-batch writes refer to writing one data item to a data partition at a time. Similarly, read operations can be further subdivided into cell-granularity reads and row-granularity reads based on the object of the read operation. Cell-granularity reads refer to reading data from one or more cells; row-granularity reads refer to reading one or more rows of data.

[0060] Wherein, when performing access operations on data partitions, the data partitions will generate multiple access characteristic data under various access operation types according to different access operation types. Wherein, the types of access characteristic data generated by the same data partition under different access operation types may be the same or different, and different data partitions will generate the same type of access characteristic data under the same access operation. In an optional embodiment, the access characteristic data generated by performing access operations on data partitions can be divided into two categories, one is read characteristic data, and the other is write characteristic data. Wherein, the read characteristic data is characteristic data generated by performing at least one read operation on the data partition, and the write characteristic data is characteristic data generated by performing at least one write operation on the data partition. Based on this, an implementation method for collecting multiple access characteristic data generated by multiple data partitions in a distributed system includes: collecting multiple read characteristic data and multiple write characteristic data generated by each of the multiple data partitions.

[0061] In an embodiment of the present disclosure, when collecting multiple access feature data generated by multiple data partitions in a distributed storage system, access popularity data for each of the multiple data partitions under each access operation type can be generated based on the multiple access feature data generated by each of the multiple data partitions and the access operation types supported. Specifically, by analyzing the access popularity data for each of the multiple access operation types for the same data partition, the access popularity of the data partition can be more accurately identified, which facilitates more accurately identifying a target data partition whose access popularity meets the requirements.

[0062] In the embodiment of the present disclosure, access heat data of multiple data partitions under each access operation type can be periodically generated based on multiple access feature data and the supported access operation types generated by each of the multiple data partitions, and the access heat data of the data partition under each access operation type can be analyzed to accurately identify the target data partition whose access heat meets the requirements, which is referred to as periodically executing the identification operation of the target data partition. This embodiment does not limit the period length of the periodic execution of the identification operation of the target data partition. The execution period is generally in the order of minutes or seconds. For example, the identification operation of the target data partition can be executed once every 10 minutes, 10 seconds or 1 second. Of course, in addition to periodically executing the identification operation of the target data partition, the user can also issue an instruction to perform target data partition identification when target data partition identification is required according to the partition identification requirements, and execute the identification operation of the target data partition according to the instruction; or, a trigger event for triggering the execution of the identification operation of the target data partition can be pre-set, and the identification operation of the target data partition can be executed when the trigger event occurs.

[0063] Optionally, whether the target data partition identification operation is performed periodically, upon receiving a user instruction, or upon a preset trigger event, each time the target data partition identification operation is performed, access feature data within a specified time period can be obtained from the access feature data that has been collected and stored. Based on the access feature data within the specified time period and the supported access operation types, access popularity data for multiple data partitions under each access operation type is generated. The access popularity data for the data partition under each access operation type is analyzed to accurately identify the target data partition whose access popularity meets the requirements. The embodiments of the present disclosure do not limit the length of the specified time period. Compared with the collection period and the execution period, the time granularity of the specified time period is much larger, for example, it can be 1 week, 10 days, 15 days, 1 month, or longer in the recent period.

[0064] Further optionally, considering that the designated time period is relatively long, a relatively large amount of access feature data collected during this period will be collected. In order to reduce the amount of access feature data processed when identifying the target data partition, the access feature data within the designated time period can be downsampled, and the downsampled access feature data can be used to identify the target hotspot partition. Based on this, in an embodiment of the present disclosure, the access feature data used in the process of generating access heat data for multiple data partitions under each access operation type can be the access feature data of each data partition within the designated time period, or the access feature data after downsampling the access feature data of each data partition within the designated time period. In an optional embodiment, based on the multiple access feature data generated by each of the multiple data partitions and the supported access operation types, access heat data for the multiple data partitions under each access operation type is generated, including: for any access operation type, from the multiple access feature data generated by each of the multiple data partitions, obtaining at least one access feature data generated by each of the multiple data partitions under any access operation type; further, based on the at least one access feature data generated by each of the multiple data partitions under any access operation type, generating access heat data for the multiple data partitions under any access operation type.

[0065] In this embodiment, considering that the connection between each access operation type is relatively weak, each access operation type can be processed separately, and the access popularity data of the data partition under each access operation type can be calculated. By reflecting the access popularity of the data partition from the perspective of different access operations, the access popularity of the data partition can be reflected more comprehensively, objectively and accurately.

[0066] Optionally, for any access operation type, access heat data of multiple data partitions under any access operation type is generated based on at least one access feature data generated by each of the multiple data partitions under any access operation type, including: for any data partition, calculating at least one resource consumption ratio corresponding to any data partition under any access operation type based on at least one access feature data generated by any data partition and other data partitions under any access operation type; generating access heat data of any data partition under any access operation type based on at least one resource consumption ratio corresponding to any data partition under any access operation type.

[0067] In this embodiment, the implementation method of calculating at least one resource consumption ratio corresponding to any data partition under any access operation type based on at least one access characteristic data generated by any data partition and other data partitions under any access operation type is not limited. In an optional embodiment, at least one resource consumption ratio corresponding to any data partition under any access operation type is calculated based on at least one access characteristic data generated by any data partition and other data partitions under any access operation type, including: for any access characteristic data, calculating the mean data of any access characteristic data generated by other data partitions under any access operation type; calculating the ratio of any access characteristic data generated by any data partition under any access operation type to the mean data as a resource consumption ratio corresponding to any data partition under any access operation type. Among them, the number of resource consumption ratios corresponding to each data partition under each access operation type can be determined according to the number of access characteristic data corresponding to the data partition under the access operation type, and one resource consumption ratio can be calculated for one access characteristic data.

[0068] Taking a read operation type C1 as an example, a data partition A1 will generate multiple read feature data under read operation type C1. Correspondingly, other data partitions will also generate the same type of read feature data. Then, for any read feature data B1, the mean value of the feature data B1 generated by other data partitions except data partition A1 can be calculated. A ratio is calculated based on the read feature data B1 generated by data partition A1 and the mean value. This ratio can be used as a resource consumption ratio corresponding to data partition A1 under read operation type C1. Similarly, for read feature data B2, B3...Bn, the same method can be used to obtain a resource consumption ratio corresponding to data partition A1 under the read operation type. Thus, at least one resource consumption ratio corresponding to data partition A1 under the read operation type C1 is obtained. For other data partitions, a method similar to that of data partition A1 can also be used to calculate at least one resource consumption ratio corresponding to other data partitions under the read operation type C1. Similarly, for other read operation types and various write operation types, a method similar to read operation type C1 can be used to obtain at least one resource consumption ratio corresponding to each data partition under each access operation type. Of course, the above method of calculating a resource consumption ratio corresponding to data partition A1 based on the average data of the read feature data B1 generated by data partition A1 and the read feature data B1 generated by other data partitions is only an example and is not limited to this. Any method that can calculate a resource consumption ratio corresponding to data partition A1 based on the read feature data B1 generated by data partition A1 and the read feature data B1 generated by other data partitions is applicable to the embodiments of the present disclosure.

[0069] In an optional embodiment, based on at least one resource consumption ratio corresponding to any data partition under any access operation type, access heat data of any data partition under any access operation type is generated, including: based on at least one resource consumption ratio corresponding to any data partition under any access operation type, selecting a resource ratio that meets the requirements from at least one resource consumption ratio as the access heat data of the current data partition under the current access operation type. Alternatively, based on at least one resource consumption ratio corresponding to any data partition under any access operation type, selecting the resource ratio with the largest resource ratio from at least one resource consumption ratio as the access heat data of the current data partition under the current access operation type. Alternatively, based on at least one resource consumption ratio corresponding to any data partition under any access operation type, calculating the mean of at least one resource ratio, and using the mean as the access heat data of the current data partition under the current access operation type. Alternatively, based on at least one resource consumption ratio corresponding to any data partition under any access operation type, calculating the weighted average of at least one resource ratio, and using the weighted average as the access heat data of the current data partition under the current access operation type.

[0070] Continuing with the above example, still taking a read operation type C1 and data partition A1 as an example, assuming that when a read operation corresponding to read operation type C1 is performed on data partition AI, 4 corresponding read feature data can be generated, and then the 4 resource consumption ratios corresponding to data partition A1 can be calculated based on the 4 read feature data. Based on this, the ratio that meets the resource ratio requirements can be selected from the 4 resource consumption ratios as the access popularity data of data partition A1 under read operation type C1. Optionally, the largest resource consumption ratio can be selected as the access popularity data of data partition A1 under read operation type C1; or, the average of the 4 resource consumption ratios can be used as the access popularity data of data partition A1 under read operation type C1; or, the weighted sum of the 4 resource consumption ratios can be used as the access popularity data of data partition A1 under read operation type C1.

[0071] Furthermore, after obtaining the access heat data of any data partition under any access operation, the target data partition whose access heat meets the requirements can be identified based on the access heat data of multiple data partitions under each access operation type. Optionally, global access heat data of multiple data partitions can be generated based on the access heat data of multiple data partitions under each access operation type; and the target data partition whose global access heat meets the requirements can be identified based on the global access heat data of multiple data partitions. Alternatively, the target access operation type can be determined based on the access heat data of multiple data partitions under each access operation type, and the target data partition whose access heat meets the requirements can be identified based on the access heat data of multiple data partitions under the target access operation type.

[0072] Further optionally, global access heat data of multiple data partitions is generated based on the access heat data of multiple data partitions under each access operation type, including: for any data partition, according to the weight corresponding to each access operation type, the access heat data of any data partition under each access operation type is weighted summed to obtain the global access heat data of any data partition; wherein the weight corresponding to each access operation type is a preset value, or is dynamically determined based on the size relationship between at least part of the access feature data corresponding to each access operation type.

[0073] Optionally, the weight corresponding to each access operation type is dynamically determined based on the size relationship between at least part of the access feature data corresponding to each access operation type, including: when the number of read operations in multiple access feature data is greater than the number of write operations, the weight corresponding to the read operation type is greater than the weight corresponding to the write operation type; or, when the amount of data involved in the read operation in multiple access feature data is greater than or equal to a set multiple of the amount of data involved in the write operation, the weight corresponding to the read operation type is greater than the weight corresponding to the write operation type.

[0074] Furthermore, after obtaining the global access heat data of multiple data partitions, the target data partition whose global access heat meets the requirements can be identified based on the global access heat data of the multiple data partitions. However, for a storage node, there may be a situation where the storage node does not actually contain a hotspot partition, but the access heat data according to this embodiment is determined to have a hotspot partition. In order to avoid such a misjudgment, the multiple data partitions can be filtered according to some access feature data; then, based on the global access heat data of the data partitions remaining after multiple considerations, the target data partition whose global access heat meets the requirements can be identified. Specifically, before identifying the target data partition based on the global access heat data of the multiple data partitions, filter the multiple data partitions whose access feature data does not meet the preset value, and select the target data partition from the retained data partitions, wherein the preset value can be set according to the demand or an empirical threshold.

[0075] Based on the above analysis, in an optional embodiment, based on the global access heat data of multiple data partitions, a target data partition whose global access heat meets the requirements is identified, including: selecting respective reference access operation data from the multiple access feature data generated by each of the multiple data partitions; filtering the multiple data partitions according to the respective reference access feature data of the multiple data partitions to obtain candidate data partitions; and identifying the target data partition whose global access heat meets the requirements according to the global access heat data of the candidate data partitions. For example, the reference access feature data can be the number of read operations, the number of write operations, the amount of data for read operations and / or the amount of data for write operations, etc. Based on this, data partitions in which the number of read operations is less than the corresponding preset value, the amount of data for read operations is less than the corresponding preset value, the number of write operations is less than the corresponding preset value, and / or the amount of data for write operations is less than the corresponding preset value can be filtered out. Among them, for different types of access feature data, the corresponding preset values ​​will be different.

[0076] Furthermore, after identifying the target data partition, if the target data partition is a hotspot partition, the target data partition can be split or migrated to reduce the data skew problem caused by the hotspot partition and improve the access efficiency and service performance of the entire system. Among them, the method of splitting the target data partition includes but is not limited to automatic splitting or manual splitting, which is not limited to. Splitting the target data partition refers to splitting the target data partition into two or more data partitions to reduce the access volume of each data partition. Migrating the target data partition refers to migrating part of the data in the target data partition to other storage nodes, or migrating the entire target data partition from the current storage node to a storage node with higher performance and resource specifications, so as to improve the access efficiency of the data partition and the service performance that can be improved by the data partition.

[0077] In this embodiment, the target data partition may be one or more. In the case where there are multiple target data partitions, how to arrange the order of splitting or migrating the multiple target data partitions is a key issue. In this regard, in the case where there are multiple target data partitions, the order of splitting or migrating the multiple target data partitions is determined according to the load growth degree of the multiple target data partitions within the set time period; the multiple target data partitions are split or migrated in this order. Preferably, the target data partition with a greater load growth degree can be split or migrated first. The load growth degree can be reflected by the growth ratio of the access volume of the data partition within the set time period. For example, the greater the growth ratio of the access volume of the data partition within the set time period, the greater the load growth degree. The set time period can be a relatively short period, such as within the last 1 minute or 1 hour, and there is no limitation on this. Optionally, the set time period is greater than the collection period and can include one or more collection periods.

[0078] At this point, the partition identification method is completed. In this embodiment, multiple data partitions in the distributed storage system support various access operation types, and under each access operation type, multiple data partitions will respectively generate multiple access feature data; then, based on the multiple access feature data generated by each of the collected multiple data partitions and the supported access operation types, multiple access heat data of the multiple data partitions under each access operation type are generated. For example, the larger the access heat data, the higher the access heat of the corresponding data partition; based on this, from the multiple access heat data, the data partition corresponding to the target access heat data that meets the access heat requirements is selected as the target data partition, such as the data partition corresponding to the maximum access heat is selected as the target data partition, thereby improving the accuracy of identifying hotspot partitions.

[0079] For ease of understanding, the following uses a table storage system as an example to illustrate the technical solution provided by the embodiment of the present disclosure. As shown in Figure 5, the process of identifying hotspot partitions for a table storage system includes the following steps:

[0080] Step 1: Monitor the working status of each storage node in the table storage system to identify the storage node that is suspected of having hot data partition issues.

[0081] For example, if the overall access volume of a storage node is detected to be high, or the access volume of a data partition on the storage node is detected to be high, or the access volume of a storage node or a data partition on the storage node increases rapidly within a short period of time, it can be determined that the storage node is suspected of having a hot data partition problem. The number of storage nodes suspected of having a hot data partition problem can be one or more.

[0082] Step 2: Based on user instructions or preset judgment conditions, determine whether it is necessary to process the storage node suspected of having hot data partition problems; if the judgment result is no, the execution process ends; if the judgment result is yes, continue to execute steps 3-9.

[0083] In an optional embodiment, when a storage node suspected of having a hot data partition problem is determined, it can be determined based on preset judgment conditions whether the storage node suspected of having a hot data partition problem needs to be processed. In the embodiment of the present disclosure, the preset judgment conditions are not limited and can be flexibly set according to application requirements. For example, the maximum number of storage nodes allowed to be processed simultaneously can be preset. If the number of storage nodes currently being processed does not reach the maximum number, the storage node suspected of having a hot data partition problem can be processed; otherwise, no processing is performed. For another example, a working status threshold that requires processing of a storage node can be preset, such as an access volume threshold. If the access volume of a storage node suspected of having a hot data partition problem is greater than the access volume threshold, it means that the storage node has a high risk of having a hot data partition problem, and the storage node can be processed; otherwise, no processing is performed.

[0084] In another optional embodiment, when a storage node suspected of having a hot data partition problem is determined, confirmation information can be output to the user, such as sending an in-application message to the user, or sending an email to the user, or sending a short message to the user, so that the user can confirm whether to process the storage node suspected of having a hot data partition problem; in response to the user's confirmation message to process the storage node suspected of having a hot data partition problem, the storage node is processed; otherwise, no processing is performed.

[0085] Step 3: Obtain access characteristic data of each data partition in the storage node suspected of having a hot data partition problem, and proceed to step 4.

[0086] In this embodiment, hotspot data partitions are identified at the storage node level. Therefore, when a storage node suspected of having a hotspot data partition issue is determined to be processed, multiple access feature data for each data partition stored on the storage node can be periodically collected. The multiple access feature data here refers to a portion of access feature data that is selected from a large amount of access feature data and is suitable for hotspot partition identification.

[0087] In this embodiment, taking Table Store as an example, we can focus on some access feature data related to read operations and some access feature data related to write operations. The read operations here include various subdivided read operations, and correspondingly, the read operations include various subdivided write operations. Among them, some access feature data related to read operations (referred to as read feature data for short) includes but is not limited to the following examples: the total number of read operations accessing block cache during the acquisition cycle, which can be expressed as total_block_cache_io_cnt; the data size of invalid data columns read by read operations during the acquisition cycle, which can be expressed as invalid_cell_size; the number of invalid data columns read by read operations during the acquisition cycle, which can be expressed as invalid_cell_cnt; the number of files read by read operations during the acquisition cycle, which can be expressed as read_file_cnt; the total amount of data scanned by read operations during the acquisition cycle (the scanned data may not be read, only part of the data will be read), which can be expressed as scan_data_size; the size of raw data read and returned to the user during the acquisition cycle, which can be expressed as resp_return_raw_data_size; the number of requests that have errors during the acquisition cycle, which can be expressed as fail_req_cnt; the total number of read requests received during the acquisition cycle, which can be expressed as total_req_cnt and other feature data. Among them, a read request will be converted into one or more read operations. Among them, some access characteristic data related to write operations (referred to as write characteristic data for short) include but are not limited to the following examples: the total number of rows involved in write operations during the collection cycle, which can be expressed as total_row_count; the write throughput involved in write operations during the collection cycle, which can be expressed as write_size; the read throughput involved in write operations during the collection cycle, which can be expressed as read_size; the number of rows successfully written by write operations during the collection cycle, which can be expressed as successful_row_count and other characteristic data. Among them, some write operations require reading data first and then writing the data, so read throughput is involved.

[0088] It should be noted that the read feature data and write feature data in the above examples are part of the feature data applied to table storage. Their definitions and names are not limited to other storage systems. These feature data depend on the specific situation.

[0089] In this step, multiple access feature data generated by each of the multiple data partitions can be periodically collected based on the access feature data discussed above. This embodiment does not limit the length of the collection period; the collection period is generally in seconds or finer granularity, such as 1 second or 0.5 seconds. Of course, multiple access feature data generated by each of the multiple data partitions can also be collected continuously. Furthermore, regardless of the collection method used, the collected access feature data can also be stored.

[0090] Step 4: Count the resource usage of each of the multiple data partitions according to the access operation type to obtain access popularity data of the multiple data partitions under each access operation type, and then proceed to step 5.

[0091] In the disclosed embodiments, the hotspot partition detection service mentioned in the above embodiments can be periodically executed to collect statistics on the resource usage of multiple data partitions based on access operation types. The period here is generally in the order of minutes or seconds, for example, the hotspot data partition identification operation can be performed once every 10 minutes, 10 seconds, or 1 second.

[0092] In this embodiment, resource occupancy of multiple data partitions may be counted based on access operation type. The resource occupancy of each data partition reflects, to a certain extent, the access popularity data of the data partition under the corresponding access operation type.

[0093] In this embodiment, access operation types are divided into at least two categories: read operations and write operations. Furthermore, read operations and write operations can be further subdivided to obtain multiple types of read operations and multiple types of write operations. Taking table storage as an example, read operations are further divided into get_range (cell read operation) and get_row (row read operation). Correspondingly, write operations are further divided into batch_modify (batch modification operation) and modify (modification operation), but are not limited to this. Among them, get_range means locking the cell range in the data table and then reading the data in the cells within the cell range; get_row means reading a row of data from the data table. batch_modify means batch modifying the attribute values ​​of fields in the data table; modify means modifying the attribute values ​​of fields in the data table.

[0094] For the access operation type get_range, the resource occupancy of each data partition is counted to obtain the access popularity data of each data partition under the access operation type get_range; for the access operation type get_row, the resource occupancy of each data partition is counted to obtain the access popularity data of each data partition under the access operation type get_row; for the access operation type batch_modify, the resource occupancy of each data partition is counted to obtain the access popularity data of each data partition under the access operation type batch_modify; and for the access operation type modify, the resource occupancy of each data partition is counted to obtain the access popularity data of each data partition under the access operation type modify. Among them, for each access operation type, the process of counting the resource occupancy of each data partition to obtain the access popularity data of each data partition under the access operation type is the same or similar, so the process is described in detail below using the access operation type get_range as an example.

[0095] Specifically, for the access operation type get_range, multiple access feature data collected within a specified time period can be obtained from the multiple access feature data collected for each data partition, and then the read feature data of each data partition can be obtained from the multiple access feature data collected within the specified time period; for each data partition, the resource ratio of the data partition under each read feature data is calculated, and then the resource ratio that meets the requirements is selected from the resource ratio of the data partition under the multiple read feature data as the resource ratio of the data partition under the access operation type get_range, and the resource ratio is used as the access popularity data of the data partition under the access operation type get_range. The embodiment of the present disclosure does not limit the length of the specified time period. Compared with the collection cycle and the execution cycle, the time granularity of the specified time period is much larger, for example, it can be 1 week, 10 days, 15 days, 1 month or longer in the recent period. Of course, here, multiple access feature data collected within the specified time period are used, but it is not limited to this. The latest collected multiple access feature data can also be used, or all the access feature data that have been collected can also be used. The specific calculation can be based on the computing power of the method execution subject.

[0096] Furthermore, for each data partition, when calculating the resource share of the data partition under each read feature data, the ratio of the read feature data to the average data of the same type of read feature data of other data partitions can be calculated for each read feature data as the resource share of the data partition under the read feature data. For example, taking the read feature data total_block_cache_io_cnt as an example, for a data partition, the average data of the total_block_cache_io_cnt of other data partitions can be calculated, and then the ratio of the total_block_cache_io_cnt of the data partition to the average data of the total_block_cache_io_cnt of other data partitions can be calculated as the resource share of the data partition under total_block_cache_io_cnt.

[0097] Similarly, for the access operation type get_range, you can refer to the above method to calculate the resource share of each data partition under invalid_cell_size, invalid_cell_cnt, read_file_cnt, scan_data_size, resp_return_raw_data_size, fail_req_cnt, and total_req_cnt. Among them, the resource share of a data partition under a certain read characteristic data (such as invalid_cell_size) indicates the resources consumed by the read characteristic data (such as invalid_cell_size) when executing the corresponding access operation type (such as get_range) on the data partition.

[0098] Finally, for the access operation type get_range, for each data partition, a resource proportion that meets the requirements can be selected from the resource proportions of the data partition under total_block_cache_io_cnt, invalid_cell_size, invalid_cell_cnt, read_file_cnt, scan_data_size, resp_return_raw_data_size, fail_req_cnt, and total_req_cnt to serve as the resource proportion for the data partition under the access operation type get_range. For example, the largest resource proportion can be selected as the resource proportion for the data partition under the access operation type get_range; alternatively, a resource proportion within a set range can be selected as the resource proportion for the data partition under the access operation type get_range; or alternatively, the smallest resource proportion can be selected as the resource proportion for the data partition under the access operation type get_range. There is no limitation on this; the same selection method can be used for all data partitions. At this point, the resource proportion for each data partition under the access operation type get_range is obtained.

[0099] Using a similar approach, you can determine the resource usage of each data partition for the get_row access operation, the batch_modify access operation, and the modify access operation. The resource usage of each data partition for a particular access operation type indicates the resources consumed when executing that access operation (e.g., get_range, get_row, batch_modify, or modify) on that data partition.

[0100] Step 5: Comprehensively process the resource consumption of multiple data partitions between various access operation types to obtain global access popularity data of multiple data partitions.

[0101] In the above steps, the resource consumption of multiple data partitions is counted according to the access operation type. However, when determining whether a data partition is a hot data partition, the resource consumption of the data partition under various access operation types can be comprehensively considered, and the resource consumption of multiple data partitions can be comprehensively sorted to consider the access popularity of multiple data partitions.

[0102] Optionally, for each data partition, a weighted sum of the resource proportions of the data partition under various access operation types can be performed to obtain the overall resource situation consumed when the data partition is accessed, and the overall resource situation reflects the global access popularity of the data partition. For example, the resource proportions of each data partition under the access operation type get_range, the resource proportions under the access operation type get_row, the resource proportions under the access operation type batch_modify, and the resource proportions under the access operation type modify can be weighted summed to obtain the overall resource situation consumed when the data partition is accessed, which serves as the global access popularity data of the data partition.

[0103] Optionally, multiple data partitions can be sorted based on the global access popularity data of each data partition. For example, they can be sorted from large to small according to the global access popularity data, or from small to large according to the global access popularity. There is no limitation on this.

[0104] Step 6: Filter the false hotspot data partitions in the multiple data partitions to obtain candidate data partitions, and execute step 7.

[0105] In this embodiment, filtering out false hotspot data partitions from among multiple data partitions includes: selecting reference access operation data from multiple access feature data generated by each of the multiple data partitions; and filtering the multiple data partitions based on the reference access feature data of each of the multiple data partitions to obtain candidate data partitions. For example, access operation data such as total_block_cache_io_cnt, resp_return_raw_data_size, total_row_count, and / or write_size can be selected as reference access operation data, and the reference access operation data can be compared with corresponding thresholds to filter out data partitions whose reference access operation data is lower than the corresponding thresholds.

[0106] Step 7: Determine the hot data partition based on the global access popularity data of the candidate data partition, and proceed to step 8.

[0107] Step 8: Split or migrate the hotspot data partition.

[0108] In this embodiment, when there are multiple hot data partitions, the order in which the hot data partitions are split or migrated can be determined based on the load growth of the multiple hot data partitions within a set period. The hot data partitions are then split or migrated according to this order. This completes the process of identifying hot data partitions in the table storage system.

[0109] It should be noted that the above steps 4 to 8 can be executed periodically, or can be executed on demand according to the user's requirements for hotspot partition identification instructions, or can be executed on demand according to event triggers, that is, the above-mentioned hotspot data partition identification process is executed when the set trigger event occurs. The trigger event here refers to the event that will trigger the hotspot data partition identification.

[0110] FIG6 is a schematic diagram of the structure of a partition identification device provided by an embodiment of the present disclosure. As shown in FIG6 , the device includes:

[0111] A data collection module 61 is used to collect multiple access feature data generated by multiple data partitions in the distributed storage system, where the multiple access feature data are feature data generated by access operations performed on the data partitions;

[0112] The data generation module 62 is configured to generate access popularity data of the plurality of data partitions under each access operation type based on the plurality of access feature data generated by each of the plurality of data partitions and the access operation types supported;

[0113] The partition identification module 63 is configured to identify a target data partition whose access heat meets the requirements based on the access heat data of multiple data partitions under various access operation types.

[0114] In an optional embodiment, when the data acquisition module 61 is used to collect multiple access feature data generated by multiple data partitions in a distributed system, it is specifically used to: collect multiple read feature data and multiple write feature data generated by each of the multiple data partitions; wherein the multiple read feature data are feature data generated by performing at least one read operation on the data partition, and the multiple write feature data are feature data generated by performing at least one write operation on the data partition; wherein the access operation type includes at least one read operation and at least one write operation.

[0115] In an optional embodiment, when the data generation module 62 is used to generate access heat data of multiple data partitions under each access operation type based on multiple access feature data generated by each of the multiple data partitions and the supported access operation types, it is specifically used to: for any access operation type, obtain at least one access feature data generated by each of the multiple data partitions under any access operation type from the multiple access feature data generated by each of the multiple data partitions; generate access heat data of the multiple data partitions under any access operation type based on at least one access feature data generated by each of the multiple data partitions under any access operation type.

[0116] Optionally, when the data generation module 62 is used to generate access heat data of multiple data partitions under any access operation type based on at least one access feature data generated by each of the multiple data partitions under any access operation type, it is specifically used to: for any data partition, calculate at least one resource consumption ratio corresponding to any data partition under any access operation type based on at least one access feature data generated by any data partition and other data partitions under any access operation type; generate access heat data of any data partition under any access operation type based on at least one resource consumption ratio corresponding to any data partition under any access operation type.

[0117] Among them, when the data generation module 62 is used to calculate at least one resource consumption ratio corresponding to any data partition under any access operation type based on at least one access characteristic data generated by any data partition and other data partitions under any access operation type, it is specifically used to: calculate the mean data of any access characteristic data generated by other data partitions under any access operation type for any characteristic access data; calculate the ratio of any access characteristic data generated by any data partition under any access operation type to the mean data, as a resource consumption ratio corresponding to any data partition under any access operation type.

[0118] In this embodiment, when the partition identification module 63 is used to identify the target data partition whose access heat meets the requirements based on the access heat data of multiple data partitions under each access operation type, it is specifically used to: generate global access heat data of multiple data partitions based on the access heat data of multiple data partitions under each access operation type; and identify the target data partition whose global access heat meets the requirements based on the global access heat data of multiple data partitions.

[0119] Optionally, when the partition identification module 63 is used to generate global access heat data of multiple data partitions based on the access heat data of multiple data partitions under each access operation type, it is specifically used to: for any data partition, according to the weight corresponding to each access operation type, perform weighted summation of the access heat data of any data partition under each access operation type to obtain the global access heat data of any data partition; wherein the weight corresponding to each access operation type is a preset value, or is dynamically determined based on the size relationship between at least part of the access feature data corresponding to each access operation type.

[0120] Among them, when the number of read operations in multiple access feature data is greater than the number of write operations, the weight corresponding to the read operation type is greater than the weight corresponding to the write operation type; or, when the amount of data involved in the read operation in multiple access feature data is greater than or equal to a set multiple of the amount of data involved in the write operation, the weight corresponding to the read operation type is greater than the weight corresponding to the write operation type.

[0121] Optionally, when the partition identification module 63 is used to identify a target data partition whose global access heat meets the requirements based on the global access heat data of multiple data partitions, it is specifically used to: select respective reference access operation data from multiple access feature data generated by each of the multiple data partitions; filter the multiple data partitions based on the respective reference access feature data of the multiple data partitions to obtain candidate data partitions; and identify the target data partition whose global access heat meets the requirements based on the global access heat data of the candidate data partitions.

[0122] Furthermore, before the data acquisition module 61 collects multiple access feature data generated by multiple data partitions in the distributed storage system, it also includes: a partition determination module, which is used to determine multiple data partitions that need to be partitioned in the distributed storage system based on partition identification requirement information; wherein, the multiple data partitions are data partitions distributed on the same storage node in the distributed storage system, or, the multiple data partitions are data partitions distributed on multiple specific storage nodes in the distributed storage system, or, the multiple data partitions are data partitions from the same data table in the distributed storage system, or, the multiple data partitions are data partitions in the data table from one or more specific tenants in the distributed storage system.

[0123] Furthermore, it also includes: a sequence determination module, which is used to determine the order of splitting or migrating multiple target data partitions according to the load growth degree of the multiple target data partitions within a set time period when there are multiple target data partitions; and splitting or migrating the multiple target data partitions in accordance with the order of priority.

[0124] It should be noted that the detailed implementation and beneficial effects of each module in the device of this embodiment have been described in detail in the aforementioned embodiments and will not be elaborated on here.

[0125] Figure 7 is a schematic diagram of the storage system provided by this embodiment. As shown in Figure 7, the storage system includes at least one storage node 71, each storing at least one data partition from at least one data table; and a partition identification node 72.

[0126] The partition identification node 72 is used to collect multiple access feature data generated by each of the multiple data partitions in the distributed storage system, where the multiple access feature data are feature data generated by access operations performed on the data partitions; based on the multiple access feature data generated by each of the multiple data partitions and the supported access operation types, generate access heat data for the multiple data partitions under each access operation type; based on the access heat data for the multiple data partitions under each access operation type, identify the target data partition whose access heat meets the requirements.

[0127] In an optional embodiment, when the partition identification node 72 is used to collect multiple access feature data generated by multiple data partitions in a distributed system, it is specifically used to: collect multiple read feature data and multiple write feature data generated by each of the multiple data partitions; wherein the multiple read feature data are feature data generated by performing at least one read operation on the data partition, and the multiple write feature data are feature data generated by performing at least one write operation on the data partition; wherein the access operation type includes at least one read operation and at least one write operation.

[0128] In an optional embodiment, when the partition identification node 72 is used to generate access heat data of multiple data partitions under each access operation type based on multiple access feature data generated by each of the multiple data partitions and the supported access operation types, it is specifically used to: for any access operation type, obtain at least one access feature data generated by each of the multiple data partitions under any access operation type from the multiple access feature data generated by each of the multiple data partitions; generate access heat data of the multiple data partitions under any access operation type based on at least one access feature data generated by each of the multiple data partitions under any access operation type.

[0129] Optionally, when the partition identification node 72 is used to generate access heat data of multiple data partitions under any access operation type based on at least one access feature data generated by each of the multiple data partitions under any access operation type, it is specifically used to: for any data partition, calculate at least one resource consumption ratio corresponding to any data partition under any access operation type based on at least one access feature data generated by any data partition and other data partitions under any access operation type; generate access heat data of any data partition under any access operation type based on at least one resource consumption ratio corresponding to any data partition under any access operation type.

[0130] Among them, when the partition identification node 72 is used to calculate at least one resource consumption ratio corresponding to any data partition under any access operation type based on at least one access characteristic data generated by any data partition and other data partitions under any access operation type, it is specifically used to: calculate the mean data of any access characteristic data generated by other data partitions under any access operation type for any characteristic access data; calculate the ratio of any access characteristic data generated by any data partition under any access operation type to the mean data, as a resource consumption ratio corresponding to any data partition under any access operation type.

[0131] In this embodiment, when the partition identification node 72 is used to identify a target data partition whose access heat meets the requirements based on the access heat data of multiple data partitions under each access operation type, it is specifically used to: generate global access heat data of multiple data partitions based on the access heat data of multiple data partitions under each access operation type; and identify a target data partition whose global access heat meets the requirements based on the global access heat data of multiple data partitions.

[0132] Optionally, when the partition identification node 72 is used to generate global access heat data of multiple data partitions based on the access heat data of multiple data partitions under each access operation type, it is specifically used to: for any data partition, according to the weight corresponding to each access operation type, perform weighted summation of the access heat data of any data partition under each access operation type to obtain the global access heat data of any data partition; wherein the weight corresponding to each access operation type is a preset value, or is dynamically determined based on the size relationship between at least part of the access feature data corresponding to each access operation type.

[0133] Among them, when the number of read operations in multiple access feature data is greater than the number of write operations, the weight corresponding to the read operation type is greater than the weight corresponding to the write operation type; or, when the amount of data involved in the read operation in multiple access feature data is greater than or equal to a set multiple of the amount of data involved in the write operation, the weight corresponding to the read operation type is greater than the weight corresponding to the write operation type.

[0134] Optionally, when the partition identification node 72 is used to identify a target data partition whose global access heat meets the requirements based on the global access heat data of multiple data partitions, it is specifically used to: select respective reference access operation data from multiple access feature data generated by each of the multiple data partitions; filter the multiple data partitions based on the respective reference access feature data of the multiple data partitions to obtain candidate data partitions; and identify the target data partition whose global access heat meets the requirements based on the global access heat data of the candidate data partitions.

[0135] Furthermore, before the partition identification node 72 collects multiple access feature data generated by multiple data partitions in the distributed storage system, it is also used to determine multiple data partitions in the distributed storage system that need to be partitioned identified based on the partition identification requirement information; wherein the multiple data partitions are data partitions distributed on the same storage node in the distributed storage system, or, the multiple data partitions are data partitions distributed on multiple specific storage nodes in the distributed storage system, or, the multiple data partitions are data partitions from the same data table in the distributed storage system, or, the multiple data partitions are data partitions in the data table from one or more specific tenants in the distributed storage system.

[0136] Furthermore, the partition identification node 72 is also used to determine the order of splitting or migrating the multiple target data partitions according to the load growth degree of the multiple target data partitions within a set time period when there are multiple target data partitions; and split or migrate the multiple target data partitions in order.

[0137] It should be noted that the detailed implementation and beneficial effects of each node and each step in the storage device of this embodiment have been described in detail in the aforementioned embodiments and will not be elaborated here.

[0138] Figure 8 is a schematic diagram of the structure of an electronic device provided by an embodiment of the present disclosure. As shown in Figure 8, the electronic device includes: a memory 80a and a processor 80b; the memory 80a is used to store a computer program; the processor 80b is coupled to the memory 80a and is used to execute the computer program to implement the following steps:

[0139] Collect multiple access feature data generated by multiple data partitions in a distributed storage system, where the multiple access feature data are feature data generated by access operations on the data partitions; generate access heat data of the multiple data partitions under each access operation type based on the multiple access feature data generated by the multiple data partitions and the supported access operation types; and identify target data partitions whose access heat meets the requirements based on the access heat data of the multiple data partitions under each access operation type.

[0140] In an optional embodiment, when the processor 80b is used to collect multiple access feature data generated by multiple data partitions in a distributed system, it is specifically used to: collect multiple read feature data and multiple write feature data generated by each of the multiple data partitions; wherein the multiple read feature data are feature data generated by performing at least one read operation on the data partition, and the multiple write feature data are feature data generated by performing at least one write operation on the data partition; wherein the access operation type includes at least one read operation and at least one write operation.

[0141] In an optional embodiment, when the processor 80b is used to generate access heat data of multiple data partitions under each access operation type based on multiple access feature data generated by each of the multiple data partitions and the supported access operation types, it is specifically used to: for any access operation type, obtain at least one access feature data generated by each of the multiple data partitions under any access operation type from the multiple access feature data generated by each of the multiple data partitions; generate access heat data of the multiple data partitions under any access operation type based on at least one access feature data generated by each of the multiple data partitions under any access operation type.

[0142] Optionally, when the processor 80b is used to generate access heat data of multiple data partitions under any access operation type based on at least one access feature data generated by each of the multiple data partitions under any access operation type, it is specifically used to: for any data partition, calculate at least one resource consumption ratio corresponding to any data partition under any access operation type based on at least one access feature data generated by any data partition and other data partitions under any access operation type; generate access heat data of any data partition under any access operation type based on at least one resource consumption ratio corresponding to any data partition under any access operation type.

[0143] Among them, when the processor 80b is used to calculate at least one resource consumption ratio corresponding to any data partition under any access operation type based on at least one access characteristic data generated by any data partition and other data partitions under any access operation type, it is specifically used to: calculate the mean data of any access characteristic data generated by other data partitions under any access operation type for any characteristic access data; calculate the ratio of any access characteristic data generated by any data partition under any access operation type to the mean data, as a resource consumption ratio corresponding to any data partition under any access operation type.

[0144] In this embodiment, when the processor 80b is used to identify a target data partition whose access heat meets the requirements based on the access heat data of multiple data partitions under each access operation type, it is specifically used to: generate global access heat data of multiple data partitions based on the access heat data of multiple data partitions under each access operation type; and identify a target data partition whose global access heat meets the requirements based on the global access heat data of multiple data partitions.

[0145] Optionally, when the processor 80b is used to generate global access heat data of multiple data partitions based on the access heat data of multiple data partitions under each access operation type, it is specifically used to: for any data partition, according to the weight corresponding to each access operation type, perform weighted summation of the access heat data of any data partition under each access operation type to obtain the global access heat data of any data partition; wherein the weight corresponding to each access operation type is a preset value, or is dynamically determined based on the size relationship between at least part of the access feature data corresponding to each access operation type.

[0146] Among them, when the number of read operations in multiple access feature data is greater than the number of write operations, the weight corresponding to the read operation type is greater than the weight corresponding to the write operation type; or, when the amount of data involved in the read operation in multiple access feature data is greater than or equal to a set multiple of the amount of data involved in the write operation, the weight corresponding to the read operation type is greater than the weight corresponding to the write operation type.

[0147] Optionally, when the processor 80b is used to identify a target data partition whose global access heat meets the requirements based on the global access heat data of multiple data partitions, it is specifically used to: select respective reference access operation data from multiple access feature data generated by each of the multiple data partitions; filter the multiple data partitions based on the respective reference access feature data of the multiple data partitions to obtain candidate data partitions; and identify the target data partition whose global access heat meets the requirements based on the global access heat data of the candidate data partitions.

[0148] Furthermore, before the processor 80b collects the multiple access feature data generated by each of the multiple data partitions in the distributed storage system, it is also used to determine the multiple data partitions that need to be partitioned identified in the distributed storage system based on the partition identification requirement information; wherein the multiple data partitions are data partitions distributed on the same storage node in the distributed storage system, or the multiple data partitions are data partitions distributed on multiple specific storage nodes in the distributed storage system, or the multiple data partitions are data partitions from the same data table in the distributed storage system, or the multiple data partitions are data partitions in the data table from one or more specific tenants in the distributed storage system.

[0149] Furthermore, the processor 80b is also used to determine the order of splitting or migrating the multiple target data partitions according to the load growth degree of the multiple target data partitions within a set time period when there are multiple target data partitions; and split or migrate the multiple target data partitions in the order of priority.

[0150] It should be noted that the detailed implementation and beneficial effects of each node and each step in the storage device of this embodiment have been described in detail in the aforementioned embodiments and will not be elaborated here.

[0151] 8 , the electronic device further includes other components such as a communication component 80c, a display 80d, a power supply component 80e, and an audio component 80f. FIG8 only schematically illustrates some components, which does not mean that the electronic device only includes the components shown in FIG8 .

[0152] The embodiments of the present disclosure also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to implement the steps in the above method.

[0153] It should be noted that the detailed implementation and beneficial effects of each step in the storage medium of this embodiment have been described in detail in the aforementioned embodiments and will not be elaborated here.

[0154] The present disclosure also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the above method. The detailed implementation and beneficial effects of each step have been described in detail in the above embodiments and will not be elaborated on here.

[0155] The above-mentioned memory can be implemented by any type of volatile or non-volatile memory device or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0156] The above-mentioned communication component is configured to facilitate wired or wireless communication between the device where the communication component is located and other devices. The device where the communication component is located can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G / LTE, 5G and other mobile communication networks, or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0157] The above-mentioned display includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor can not only sense the boundary of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation.

[0158] The power supply assembly provides power to various components of the device in which the power supply assembly is located. The power supply assembly may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply assembly is located.

[0159] The above-mentioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC), and when the device where the audio component is located is in an operating mode, such as call mode, recording mode, and voice recognition mode, the microphone is configured to receive external audio signals. The received audio signal can be further stored in a memory or sent via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0160] Those skilled in the art will appreciate that the embodiments of the present disclosure may be provided as methods, systems, or computer program products. Therefore, the present disclosure may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present disclosure may take the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to magnetic disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

[0161] The present disclosure is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present disclosure. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0162] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0163] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0164] In a typical configuration, a computing device includes one or more processors (Central Processing Unit, CPU), input / output interfaces, network interfaces, and memory.

[0165] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0166] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be used to store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media such as modulated data signals and carrier waves.

[0167] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0168] The above are merely examples of the present disclosure and are not intended to limit the present disclosure. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present disclosure are intended to be included within the scope of the claims of the present disclosure.

Claims

1. A partition identification method, wherein: include: Collecting a plurality of access characteristic data generated by each of a plurality of data partitions in a distributed storage system, wherein the plurality of access characteristic data are characteristic data generated by performing access operations on the data partitions; Generate access popularity data of the multiple data partitions under each access operation type according to the multiple access feature data generated by each of the multiple data partitions and the access operation types supported; According to the access heat data of the multiple data partitions under each access operation type, a target data partition whose access heat meets the requirements is identified.

2. The method according to claim 1, wherein: Collect multiple access feature data generated by multiple data partitions in a distributed system, including: Collecting a plurality of read characteristic data and a plurality of write characteristic data generated by each of the plurality of data partitions; wherein the plurality of read characteristic data are characteristic data generated by performing at least one read operation on the data partitions, and the plurality of write characteristic data are characteristic data generated by performing at least one write operation on the data partitions; The access operation type includes at least one read operation and at least one write operation.

3. The method according to claim 1, wherein: Generating access heat data of the multiple data partitions under each access operation type according to the multiple access feature data generated by each of the multiple data partitions and the access operation types supported, including: For any access operation type, obtaining, from the plurality of access feature data respectively generated by the plurality of data partitions, at least one access feature data respectively generated by the plurality of data partitions under the any access operation type; Access popularity data of the multiple data partitions under any access operation type is generated according to at least one access feature data generated by each of the multiple data partitions under any access operation type.

4. The method according to claim 3, wherein: Generating access heat data of the multiple data partitions under any access operation type according to at least one access feature data generated by each of the multiple data partitions under any access operation type, including: For any data partition, according to at least one access characteristic data generated by the any data partition and other data partitions under any access operation type, calculate at least one resource consumption ratio corresponding to the any data partition under any access operation type; According to at least one resource consumption ratio corresponding to any one of the data partitions under any one of the access operation types, access popularity data of any one of the data partitions under any one of the access operation types is generated.

5. The method according to claim 4, wherein: Calculating at least one resource consumption ratio corresponding to any one data partition under any one access operation type according to at least one access feature data generated by any one data partition and other data partitions under any one access operation type, including: For any type of access characteristic data, calculate the mean value data of any type of access characteristic data generated by other data partitions under any type of access operation; A ratio of any one of the access characteristic data generated by any one of the data partitions under any one of the access operation types to the mean data is calculated as a resource consumption ratio corresponding to any one of the data partitions under any one of the access operation types.

6. The method according to claim 1, wherein: According to the access heat data of the plurality of data partitions under each access operation type, identifying a target data partition whose access heat meets the requirements, including: Generate global access heat data of the multiple data partitions according to the access heat data of the multiple data partitions under each access operation type; According to the global access heat data of the multiple data partitions, a target data partition whose global access heat meets the requirements is identified.

7. The method according to claim 6, wherein: Generating global access heat data of the multiple data partitions according to the access heat data of the multiple data partitions under each access operation type includes: For any data partition, according to the weights corresponding to the respective access operation types, weighted sum is performed on the access heat data of the any data partition under the respective access operation types, so as to obtain the global access heat data of the any data partition; The weight corresponding to each access operation type is a preset value, or is dynamically determined according to the size relationship between at least part of the access feature data corresponding to each access operation type.

8. The method according to claim 7, wherein: When the number of read operations in the multiple access feature data is greater than the number of write operations, the weight corresponding to the read operation type is greater than the weight corresponding to the write operation type; or, when the amount of data involved in the read operation in the multiple access feature data is greater than or equal to a set multiple of the amount of data involved in the write operation, the weight corresponding to the read operation type is greater than the weight corresponding to the write operation type.

9. The method according to claim 6, wherein: According to the global access heat data of the multiple data partitions, identifying a target data partition whose global access heat meets the requirements, including: selecting respective reference access operation data from a plurality of access characteristic data generated by respective ones of the plurality of data partitions; filtering the plurality of data partitions according to the respective reference access characteristic data of the plurality of data partitions to obtain candidate data partitions; According to the global access heat data of the candidate data partitions, a target data partition whose global access heat meets the requirements is identified.

10. The method according to any one of claims 1 to 9, wherein: Before collecting a plurality of access feature data generated by each of a plurality of data partitions in the distributed storage system, the method further includes: Determining, according to the partition identification requirement information, a plurality of data partitions that need to be partition identified in the distributed storage system; The multiple data partitions are data partitions distributed on the same storage node in the distributed storage system, or the multiple data partitions are data partitions distributed on multiple specific storage nodes in the distributed storage system, or the multiple data partitions are data partitions from the same data table in the distributed storage system. or, the multiple data partitions are data partitions in a data table from one or more specific tenants in the distributed storage system.

11. The method according to any one of claims 1 to 9, wherein: Also includes: In the case where there are multiple target data partitions, determining the order of splitting or migrating the multiple target data partitions according to the load growth degree of the multiple target data partitions within a set period of time; The multiple target data partitions are split or migrated in the order.

12. A storage system, wherein: comprising at least one storage node, wherein at least one data partition from at least one data table is stored on one storage node; The storage system further includes: a partition identification node; The partition identification node is used to collect multiple access feature data generated by each of the multiple data partitions in the distributed storage system, where the multiple access feature data are feature data generated by access operations performed on the data partitions; based on the multiple access feature data generated by each of the multiple data partitions and the supported access operation types, generate access heat data of the multiple data partitions under each access operation type; based on the access heat data of the multiple data partitions under each access operation type, identify the target data partition whose access heat meets the requirements.

13. An electronic device, wherein: include: Memory and processor; The memory is used to store computer programs; The processor, coupled to the memory, is configured to execute the computer program to implement the steps in the method according to any one of claims 1 to 11.

14. A computer-readable storage medium storing a computer program, wherein: When the computer program is executed by a processor, the processor is caused to implement the steps in the method according to any one of claims 1 to 11.

15. A computer program product, comprising a computer program, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 11.

Images