CN116027982A - Data processing method, device and readable storage medium - Google Patents

Data processing method, device and readable storage medium Download PDF

Info

Publication number
CN116027982A
CN116027982A CN202310077005.3A CN202310077005A CN116027982A CN 116027982 A CN116027982 A CN 116027982A CN 202310077005 A CN202310077005 A CN 202310077005A CN 116027982 A CN116027982 A CN 116027982A
Authority
CN
China
Prior art keywords
priority
data
cache
request
layer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310077005.3A
Other languages
Chinese (zh)
Inventor
陈书宁
周元辉
刘瀚阳
唐刘
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Pingkai Star Beijing Technology Co ltd
Original Assignee
Pingkai Star Beijing Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Pingkai Star Beijing Technology Co ltd filed Critical Pingkai Star Beijing Technology Co ltd
Priority to CN202310077005.3A priority Critical patent/CN116027982A/en
Publication of CN116027982A publication Critical patent/CN116027982A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

The embodiment of the application provides a data processing method, data processing equipment and a readable storage medium, and relates to the technical field of information storage. The method comprises the following steps: receiving IO operations for data; determining a priority for the IO operation according to the type of the IO operation; adding the IO operation to a corresponding priority request queue according to the determined priority, and waiting for allocation of tokens; and after the IO operation acquires the token, executing the IO operation. According to the embodiment of the application, different priorities are given to different types of IO operations for data, the IO operations are added to the priority queues corresponding to the determined priorities to wait for allocation of tokens, and the IO operations are executed after the tokens are acquired, so that the problem that the delay of a read-write request is increased due to competition or congestion among different types of IO requests is avoided, the limited performance of cloud storage can be utilized more efficiently, and the average delay and the tail delay of the read-write request are remarkably reduced.

Description

Data processing method, device and readable storage medium
Technical Field
The present application relates to the field of information storage technologies, and in particular, to a data processing method, apparatus, and readable storage medium.
Background
In the big data age, various users show remarkable difference on storage requirements in the digitizing process, a large amount of unstructured data is generated, and the traditional relational storage is difficult to effectively cope with the unstructured data. The key value storage system searches the value directly through the key, well meets the storage requirement of unstructured data, and is widely and widely applied.
A Log Structured-Merge-Tree (LSM-Tree for short) is taken as one of representative structures of key value storage, and has excellent writing performance and poor reading performance.
Cloud storage is becoming more popular because of its easier management, better expansibility, reliability, and lower cost of use than traditional storage approaches. However, there are significant differences in latency of cloud storage volumes at different access loads. When the access load does not exceed the purchased IOPS (Input/Output Operations Per Second, per second IO operands), then the processing latency of each request is within the appropriate threshold. When the access load exceeds the purchased IOPS, the access delay per request increases dramatically. This latency characteristic severely affects the performance and tail latency of a log-structured merge tree based key-value storage system.
The key value storage system based on the log structure merging tree may access a plurality of disks when processing a read request, generate a plurality of IO operations, have the problem of read amplification, and the internal compression operation of the key value storage system also generates more IO operations to compete with the read request of a user for the cloud storage limited IOPS resources. Because of the limited IOPS of cloud storage, the data processing performance of a log-structured merge tree based key-value storage system is greatly limited, especially the average latency and tail latency of read-write requests are relatively high.
Disclosure of Invention
The application provides a data processing method, data processing equipment and a readable storage medium, which are used for solving the technical problems in the prior art.
In a first aspect, a data processing method is provided, the method comprising:
receiving IO operations for data;
determining a priority for the IO operation according to the type of the IO operation;
adding the IO operation to a corresponding priority request queue according to the determined priority, and waiting for allocation of tokens;
and after the IO operation acquires the token, executing the IO operation.
In one possible implementation manner, the determining the priority for the IO operation according to the type of the IO operation includes:
If the IO operation is a prefetching operation aiming at data, determining the IO operation as a first priority;
the performing the IO operation includes:
and after the IO operation obtains the token, sending a corresponding data reading request to the storage device so as to read a first data block and buffer the first data block into a first buffer, wherein the IO operation is added into a first priority request queue corresponding to the first priority to wait for the token to be allocated, and the first data block is determined based on the heat.
In another possible implementation, the determining the first data block includes:
acquiring access times of at least two data blocks read in a statistical period;
updating the heat of the corresponding data blocks according to the access times of the at least two data blocks;
and selecting the data block which has the highest heat degree in the at least two data blocks and is not cached in the first cache in the statistical period as the first data block.
In yet another possible implementation manner, the determining the priority for the IO operation according to the type of the IO operation includes:
if the IO operation is a read request for data, determining that the IO operation is a second priority;
the performing the IO operation includes:
After the IO operation obtains the token, a corresponding data reading request is sent to the storage device so as to read a second data block, and the second data block is cached in a second cache under the condition that the second cache is opened;
and adding the IO operation into a second request queue corresponding to a second priority, and waiting for allocation of tokens, wherein the second priority is higher than the first priority.
In yet another possible implementation manner, if the received IO operation is a read request for a second data block, the method further includes:
sequentially searching the second data block in the second cache and the first cache, returning if the second data block is found, and searching the second data block in the storage device if the second data block is not found;
the first cache manages a cache space by taking data blocks with a first granularity as a unit, and the second cache manages the cache space by taking data blocks with a second granularity smaller than the first granularity as a unit;
and if the IO number of the access storage equipment exceeds a first threshold value of the IOPS of the storage equipment, the second cache is started, otherwise, the first cache is started.
In yet another possible implementation, a sum of the buffer spaces of the first buffer and the second buffer remains unchanged, and the respective buffer space sizes can be dynamically changed.
In yet another possible implementation, the method further includes:
and if the heat of the fourth data block of the third data block in the second cache is higher than that of the coldest data block in the first cache, removing the coldest data block in the first cache and adding the released cache space into the second cache.
In yet another possible implementation manner, if the received IO operation is a write request for target data, the method further includes:
determining whether the IO operation is a write request for a lower brush or a compressed write request according to the source of the IO operation;
the write-in request of the lower brush is the lower brush operation of writing the SSTable of the ordering character string generated by the target data into the L0 layer of the log structure merging tree LSM-tree;
the compressed write request is an SSTable for a Li layer of the LSM-tree, and a compression operation between SSTable having a key value range overlapping with SSTable of the Li layer in an L (i+1) layer of the LSM-tree.
In yet another possible implementation manner, the determining the priority for the IO operation according to the type of the IO operation includes:
if the IO operation is a write-in request of the lower brush, determining that the IO operation is of a second priority;
The performing the IO operation includes:
after the IO operation obtains the token, writing the SSTable generated by the target data into the L0 layer, adding the IO operation into a second request queue corresponding to a second priority, and waiting for distributing the token, wherein the second priority is higher than the first priority.
In yet another possible implementation manner, the determining the priority for the IO operation according to the type of the IO operation includes:
if the IO operation is a compressed write request and the L (i+1) layer is the bottommost layer of the LSM-tree, determining that the IO operation is of a first priority;
if the IO operation is a compressed write request and the L (i+1) layer is not the bottommost layer of the LSM-tree, determining that the IO operation is of a third priority;
the performing the IO operation includes:
after the IO operation obtains the token, writing the SSTable generated by compression into the L (i+1) layer, wherein the IO operation is added into a first priority request queue corresponding to the first priority or a third priority request queue corresponding to the third priority to wait for the token to be allocated;
wherein the third priority is higher than the first priority and lower than the second priority.
In yet another possible implementation, the method further includes:
deleting SSTable of the Li layer, and SSTable of the L (i+1) layer overlapping with SSTable existence key value range of the Li layer.
In yet another possible implementation manner, the time window for allocating tokens of the priority request queue corresponding to the second priority, the third priority and the first priority is sequentially reduced.
In a second aspect, there is provided an electronic device comprising:
one or more processors;
a memory;
one or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, the one or more applications configured to: the data processing method shown in the first aspect described above is performed.
For example, in a second aspect of the present application, there is provided a computing device comprising: the device comprises a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface are communicated with each other through the communication bus;
the memory is configured to store at least one executable instruction, where the executable instruction causes the processor to perform operations corresponding to the data processing method according to the first aspect of the present application.
In a third aspect, there is provided a computer readable storage medium storing a computer program for causing a processor to execute the data processing method shown in the first aspect.
The beneficial effects that this application provided technical scheme brought are:
by giving different priorities to different types of IO operations of data, adding the IO operations to a priority queue corresponding to the determined priorities to wait for allocation of tokens, and executing the IO operations after obtaining the tokens, the problem that the delay of a read-write request is increased due to competition or congestion generated among different types of IO requests is avoided, the limited performance of cloud storage can be utilized more efficiently, and the average delay and tail delay of the read-write request are obviously reduced.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings that are required to be used in the description of the embodiments of the present application will be briefly described below.
Fig. 1 is a schematic flow chart of a data processing method according to an embodiment of the present application;
fig. 2 is a schematic diagram of a key value storage system constructed based on cloud storage according to an embodiment of the present application;
FIG. 3 is a schematic diagram of a data cache structure according to an embodiment of the present disclosure;
fig. 4 is a schematic diagram of an IO allocation structure provided in an embodiment of the present application;
FIG. 5 is a schematic diagram of a data prefetching method according to an embodiment of the present disclosure;
fig. 6 is a schematic diagram of a data read request processing method according to an embodiment of the present application;
FIG. 7 is a schematic diagram of a method for processing a data write request according to an embodiment of the present application;
fig. 8 is a schematic structural diagram of a data processing electronic device according to an embodiment of the present application.
Detailed Description
Embodiments of the present application are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals refer to the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by referring to the drawings are exemplary only for the purpose of illustrating the present application and are not to be construed as limiting the invention.
As used herein, the singular forms "a", "an", "the" and "the" are intended to include the plural forms as well, unless expressly stated otherwise, as understood by those skilled in the art. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. It will be understood that when an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or intervening elements may also be present. Further, "connected" or "coupled" as used herein may include wirelessly connected or wirelessly coupled. The term "and/or" as used herein includes all or any element and all combination of one or more of the associated listed items.
For the purpose of making the objects, technical solutions and advantages of the present application more apparent, the embodiments of the present application will be described in further detail below with reference to the accompanying drawings.
A Log-Structured-Merge-Tree (LSM-Tree for short) is one of the representative structures of key value storage, and has very wide application due to the characteristics of being friendly to write requests and the like. When data is inserted into the log structure merging tree, the data is firstly written into the memory buffer area, and then the memory buffer area is fully written and then is brushed into a disk by a background thread. When the log structure merging tree inserts data, the foreground thread only needs to write the data into the memory, and meanwhile, the log structure merging tree merges random writing into sequential writing, so that random writing operation on a disk is avoided, and therefore writing performance is excellent. When searching data, the log structure merging tree searches in the memory first and then searches in the disk file layer by layer, and the reading performance of the log structure merging tree is poor because multiple disk access operations can occur in the process. The log-structured merge tree structure is widely applied in non-relational databases (NoSQL) and is used as a key value database developed by a storage engine.
The cloud storage can provide the database with extremely large storage capacity and higher data reliability, and can effectively ensure that the database can obtain stable storage performance during capacity expansion, so that the development of cloud on the database is strongly promoted. In the big data age, cloud storage is becoming more popular because of more convenient management, better expansibility, reliability, and lower use cost than traditional storage methods. It is predicted that 75% of databases in the global database market will have completed migration to the cloud platform in 2023, with only 5% of the data still remaining in the local mode. However, how to select appropriate cloud storage resources to maximize performance and avoid paying additional costs is a significant challenge, existing research favors dynamic scaling nodes to achieve a balance of performance and cost, but scaling of multiple storage volumes can result in frequent migration overhead of data. While many cloud storage providers call elastic storage volumes adaptable to changing performance requirements, the expansion capabilities of these elastic storage volumes cannot accommodate the unavoidable flow fluctuations. For example, existing cloud storage volumes only support IOPS (Input/Output Operations Per Second, IO operands per second) for added purchases, which can take hours or even days to complete. Thus, it is impractical to rely on spring rolls to dynamically adjust for short-term workload variations.
In addition, there are significant differences in latency of cloud storage volumes under different access loads. When the access load does not exceed the purchased IOPS, then the processing delay for each request is within the appropriate threshold. However, when the access load exceeds the purchased IOPS, the access delay per request increases dramatically. This latency characteristic severely affects the performance and tail latency of a log-structured merge tree based key-value storage system. The key value storage system based on the log structure merging tree may access to a plurality of disks when processing a read request, and generate a plurality of IO operations, so that the problem of read amplification is solved; the internal compression operation can generate more IO operations to compete with the read request of the user for the IOPS resources with limited cloud storage. Because of the limited IOPS of cloud storage, the read performance of log-structured merge tree based key-value storage systems is greatly limited. Therefore, optimizing the LSM-tree storage architecture for the characteristics of cloud storage to balance its performance and cost is important, and the LSM-tree storage architecture takes precedence over avoiding severe tail delays.
Several terms which are referred to in this application are first introduced and explained:
a brush (Flush) operation: when the memory component in the LSM-tree is full, the data in the memory is written to the disk and organized into an SSTable structure, which is called a flush operation.
Compression (Compaction) operation in order to maintain the tree structure of the LSM-tree, when sstables of the Li layer are excessive, it is necessary to merge-sort sstables of the Li layer and sstables of the li+1 layer having overlapped key values while discarding some old key values, which is called a compression operation.
Description: if the Li layer and the Li+1 layer have no overlapped bonding value, the number of layers of the SSTable file is directly increased by 1.
When discarding old keys, the old value corresponding to the old key is discarded. Such as: the key value pair (k 1, v 1) is written first, and then the key value pair (k 1, v 2) is written, so that the LSM-tree stores the key value pair of two key positions k1, and the key value pair (k 1, v 1) is the old key value pair. Only new (k 1, v 2) is stored at this time.
The data processing method, the electronic device and the computer readable storage medium provided by the application aim to solve the technical problems in the prior art.
Specifically, the application provides a key value storage system constructed based on cloud storage, a data prefetching method, a data reading method and a data writing method based on the key value storage system, and aims to construct a fast and efficient LSM-tree storage architecture on the cloud storage, effectively cope with fluctuating workload, realize balance between performance and cost, fully exert the characteristic of the cloud storage and ensure that the LSM storage architecture has lower tail delay.
The following describes the technical solutions of the present application and how the technical solutions of the present application solve the above technical problems in detail with specific embodiments. The following embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.
An embodiment of the present application provides a data processing method, as shown in fig. 1, where the method includes:
s101, receiving IO operation for data;
s102, determining a priority for the IO operation according to the type of the IO operation;
s103, adding the IO operation into a corresponding priority request queue according to the determined priority, and waiting for allocation of tokens;
s104, after the IO operation acquires the token, executing the IO operation.
According to the data processing scheme, different priorities are given to different types of IO operations for data, the IO operations are added to the priority queues corresponding to the determined priorities to wait for allocation of tokens, and the IO operations are executed after the tokens are acquired, so that the problem that the delay of read-write requests is increased due to competition or congestion among different types of IO requests is avoided, and the limited performance of cloud storage can be utilized more efficiently.
In one possible implementation manner provided in the embodiment of the present application, step S102 may include:
if the IO operation is a prefetching operation aiming at data, determining the IO operation as a first priority;
step S104 may include:
and after the IO operation obtains the token, sending a corresponding data reading request to the storage device so as to read a first data block and buffer the first data block into a first buffer, wherein the IO operation is added into a first priority request queue corresponding to the first priority to wait for the token to be allocated, and the first data block is determined based on the heat.
Specifically, in this embodiment, the determining the first data block includes:
acquiring access times of at least two data blocks read in a statistical period;
updating the heat of the corresponding data blocks according to the access times of the at least two data blocks;
and selecting the data block which has the highest heat degree in at least two data blocks in the statistical period and is not cached in the first cache as the first data block.
The heat degree of the corresponding data block is updated according to the access times of the data block, which can be specifically: and calculating the new heat of the corresponding data block according to the historical heat of the last statistical period of at least two data blocks, the access times in the current statistical period, the attenuation coefficient and the weight coefficient.
The data processing scheme provided by the application reduces the pressure on cloud storage during high load by actively caching hot spot data during low load.
In one possible implementation manner provided in the embodiment of the present application, step S102 may include:
if the IO operation is a read request for a second data block, determining that the IO operation is a second priority;
step S104 may include:
after the IO operation obtains the token, a corresponding data reading request is sent to the storage device so as to read a second data block, and the second data block is cached in a second cache under the condition that the second cache is opened;
and adding the IO operation into a second request queue corresponding to a second priority, and waiting for allocation of tokens, wherein the second priority is higher than the first priority.
In one possible implementation, if the received IO operation is a read request for the second data block, before step S102, the method may further include:
sequentially searching the second data block in the second cache and the first cache, returning if the second data block is found, and searching the second data block in the storage device if the second data block is not found;
The first cache manages a cache space by taking data blocks with a first granularity as a unit, and the second cache manages the cache space by taking data blocks with a second granularity smaller than the first granularity as a unit;
and if the IO number of the access storage equipment exceeds a first threshold value of the IOPS of the storage equipment, the second cache is started, otherwise, the first cache is started.
That is, when reading the SSTable file, the SSTable file is first searched in the passive cache (corresponding to the second cache above) and the active prefetch cache (corresponding to the first cache above) in sequence, if not found, the SSTable file in the cloud storage is read, after the data block is read from the SSTable, if the passive cache is opened, the read data block is cached in the passive cache.
The passive cache manages the cache space by taking the data blocks with fine granularity (corresponding to the second granularity above) as a unit, and is opened under high load and closed under low load; the active cache manages the cache space in units of coarse-grained (corresponding to the first granularity above) EBS-blocks, and active prefetching is performed only under low load. The workload on a storage device is at a high load when the IO accessing the storage device exceeds 90% of the IOPS purchased by the storage device, and is at a low load otherwise.
In the above embodiment, the sum of the buffer spaces of the first buffer and the second buffer is kept unchanged, and the respective buffer space sizes can be dynamically changed.
In one possible implementation, if the heat of the fourth data block to which the third data block in the second cache belongs is higher than the heat of the coldest data block in the first cache, the coldest data block in the first cache is removed and the released cache space is added to the second cache.
That is, by removing the coldest data block in the cache, the cached data can be guaranteed to be the data block with high heat.
In an embodiment of the present application, if the received IO operation is a write request for target data, before step S102, a possible implementation manner may further include:
determining whether the IO operation is a write request for a lower brush or a compressed write request according to the source of the IO operation;
the write-in request of the lower brush is the lower brush operation of writing the SSTable of the ordering character string generated by the target data into the L0 layer of the log structure merging tree LSM-tree;
the compressed write request is an SSTable for a Li layer of the LSM-tree, and a compression operation between SSTable having a key value range overlapping with SSTable of the Li layer in an L (i+1) layer of the LSM-tree. Wherein i is a positive integer greater than or equal to 1.
In one possible implementation, step S102 may include:
if the IO operation is a write-in request of the lower brush, determining that the IO operation is of a second priority;
step S104 may include:
after the IO operation obtains the token, writing the SSTable generated by the target data into the L0 layer, adding the IO operation into a second request queue corresponding to a second priority, and waiting for distributing the token, wherein the second priority is higher than the first priority.
In another possible implementation, step S102 may include:
if the IO operation is a compressed write request and the L (i+1) layer is the bottommost layer of the LSM-tree, determining that the IO operation is of a first priority;
if the IO operation is a compressed write request and the L (i+1) layer is not the bottommost layer of the LSM-tree, determining that the IO operation is of a third priority;
step S104 may include:
after the IO operation obtains the token, writing the SSTable generated by compression into the L (i+1) layer, wherein the IO operation is added into a first priority request queue corresponding to the first priority or a third priority request queue corresponding to the third priority to wait for the token to be allocated;
Wherein the third priority is higher than the first priority and lower than the second priority.
That is, the purpose of the write request needs to be determined after the write request for data is received, the IO request is added to the corresponding priority queue based on the purpose of the write request, and the IO request is executed after the token is acquired. By giving different priorities to different types of read-write requests and then allocating different numbers of IOs, the purchased cloud storage performance can be fully and reasonably utilized.
The embodiment of the application provides a possible implementation manner, and the implementation manner may further include:
deleting SSTable of the Li layer, and SSTable of the L (i+1) layer overlapping with SSTable existence key value range of the Li layer.
In the above embodiment, the priority request queues corresponding to different priorities are allocated with time windows for allocating tokens of different lengths, and specifically, the time windows for allocating tokens of the priority request queues corresponding to the second priority, the third priority and the first priority are sequentially reduced.
In one possible implementation, the second priority request queue may be assigned tokens at all times, the third priority request queue may be assigned tokens for a smaller time window, and the first priority request queue may be assigned tokens for a minimum time window. The time window sizes of the third priority request queue and the first priority request queue are dynamically adjusted according to the number of tokens used in each second of history, and the time window sizes are obtained by multiplying the number of pre-allocated IOPS (input/output) by the lowest delay of each IO and performing corresponding coefficient amplification.
In the scheme of the embodiment, the time windows with different sizes are allocated to the prefetch queue under different loads, so that prefetching can only occur under low load, and further, the request under partial high load is transferred to the low load.
The following describes in detail the implementation of the solution provided in the present application with reference to fig. 2-7.
As shown in fig. 2, the present application provides a key value storage system, and the above scheme is implemented based on the key value storage system. The key value storage system is characterized in that the key value storage system is an LSM-tree storage architecture and comprises: a fluctuation-aware data caching module and a congestion-aware IO allocation module. The data caching module is divided into a passive cache with change perception and a prefetch cache (active cache) with hot spot perception, and is used for caching hot spot data and redirecting the read load of a user; the IO distribution module is divided into an IO delay stabilization module and an IO congestion control module, the IO quantity sent to the cloud storage volume (corresponding to the storage device in the above) per second is limited, different priorities are distributed according to different request types in the LSM-tree storage architecture, and therefore different quantities of cloud storage IOs are distributed.
The data caching module is used for redirecting partial read loads of users and can actively cache hot spot data during low loads, so that pressure on cloud storage during high loads is reduced. The IO distribution module more efficiently utilizes the limited performance of cloud storage by giving different priorities to different types of read and write requests. The key value storage system can fully utilize the performance of cloud storage, obviously reduce the average delay and tail delay of read-write requests and ensure the efficient reading and writing of data.
The LSM-tree storage architecture is formed by storing data in units of SSTable (Sorted String Table) and forming SSTable into a multi-layered tree structure, wherein each layer comprises a plurality of SSTable. In the LSM-tree storage architecture, the top is the uppermost L0 layer, which is sequentially increased to L1, L2, L3 to Ln layers. Except that the key value range is overlapped among the SSTable of the first layer, the data among the SSTable of the other layers are not overlapped, and the data quantity of each layer is exponentially increased layer by layer. For example: the SSTable bonds of the first layer may range from 1 to 100, 50 to 150, respectively, and the bonds of the second layer may range from 1 to 50, 50 to 100, 100 to 150, etc.
During a data write operation, the write operation is first logged to ensure that data is persisted when the key storage system fails, and then written to the memtable structure of the memory cache. When one of the memtable is full of data, the data is changed into one of the immutable memtable, and finally one of the SSTable is generated and written into the topmost L0 layer in batches. In order to maintain the tree structure of the LSM-tree, when a certain condition is reached (for example, but not limited to, when the data amount of a certain layer is large), the SSTable in the layer is brushed down to the next layer by merge ordering to form a new SSTable. Therefore, the latest data in the LSM-tree is always located at the upper layer, the data in the memory is accessed first when the data is read, and all SStables for searching the LSM-tree from top to bottom are not found until the result is obtained.
The data caching module is used for caching hot spot data and redirecting partial read requests, so that IO requests for cloud storage are reduced. The data caching module is located in the memory and is divided into a passive cache with change perception and an active prefetch cache with hot spot perception, as shown in fig. 3. The key value storage system can firstly search in the passive cache and the prefetch cache in sequence when the SSTable files are read, if the SSTable files are not hit (i.e. not searched), the key value storage system reads from the SSTable files in the cloud storage (searching in the SSTable files layer by layer, wherein the SSTable files in the first layer need to be searched one by one, the SSTable files in other layers need to be read only by using a dichotomy when the SSTable files in other layers are searched), and after the data blocks are read from the SSTable, the read data blocks are cached in the passive cache if the passive cache is started.
Wherein the passive cache caches the data blocks at a fine granularity (corresponding to the second granularity above), the data blocks in the passive cache being managed with an LRU (Least Recently Used ) algorithm. The prefetch cache divides the SSTable into EBS-blocks according to coarse granularity (corresponding to the first granularity and configured according to the characteristics of the cloud storage volumes), carries out heat statistics by taking the EBS-blocks as a unit, actively initiates a prefetch request to the block of the SSTable with the highest heat in the cloud storage, and carries out prefetch operation after the IO allocation module allocates the token.
The heat statistics can be realized based on a hash table, wherein keys of the hash table are SSTable numbers and offset addresses of the EBS-blocks, the values of the hash table are heat values of the EBS-blocks corresponding to the keys, the cache module counts the access times of the EBS-blocks in the passive cache, the data blocks in the prefetch cache and the EBS-blocks in the prefetch cache every second, and the heat values of the EBS-blocks are updated according to the access times of the data blocks so as to provide information for the prefetch operation of the prefetch cache.
The calculation mode of the heat value of the EBS-block is that the historical heat of the EBS-block is multiplied by a decay coefficient, and then the number of times of accessing the EBS-block in the past one second (corresponding to the statistical period above) is multiplied by a corresponding weight coefficient, and the sum of the two is the new heat value of the EBS-block, wherein the sum of the decay coefficient and the weight coefficient is 1. For example: heat of freshness = history heat 0.5+ number of accesses per second 0.5.
The sum of the sizes of the prefetch cache and the passive cache remains unchanged, and their respective sizes dynamically change. Under low load, passive caching is disabled, and active prefetching is only performed to utilize the IOPS that the cloud storage volume is idle; under high load, the passive cache is started, and the read data block is cached in the passive cache after the key value storage system finishes the read request, so that the process does not consume additional cloud storage volumes IOPS.
When the data block in the passive cache is eliminated, firstly checking the heat degree of the EBS-block (corresponding to the third data block) to which the eliminated data block (corresponding to the fourth data block) belongs, if the heat degree of the EBS-block is higher than the heat degree of the coldest EBS-block in the prefetched cache, not eliminating the data block, removing the coldest EBS-block in the prefetched cache and adding the released memory into the passive cache so as to ensure that the data cached by the data cache module is the data block or the EBS-block with high heat degree.
The IO distribution module ensures that the time delay of each IO request is lower by limiting the number of IO requests sent to cloud storage per second, and simultaneously distributes different priorities for different types of IO requests in the LSM-tree storage architecture to ensure that the IO requests in the LSM-tree storage architecture do not influence the read-write requests of users as much as possible, so that the time delay of the read-write requests of the users is prevented from being increased due to IO contention (the competition between the IO requests among multiple threads and the IO requests of different types) or congestion.
The IO distribution module is divided into an IO delay stabilizing module and an IO congestion control module. The IO delay stabilizing module controls the number of IO requests sent to the cloud storage volume per second so that the IO requests do not exceed the purchased cloud storage volume IOPS, and further, the delay of each IO sent to the cloud storage volume is ensured to be maintained at a lower level. The IO latency stabilization module uses a token bucket algorithm to strictly control the number of IOs sent to the cloud storage volumes and set different priorities for different IO requests, as shown in fig. 4. Each IO request for accessing the cloud storage volume firstly enters different request queues according to IO types, the IO request is sent to the cloud storage after the token is acquired, the number of tokens in the token bucket is reset to the number of IOPS of the cloud storage volume every second, and when no token exists in the token bucket, the request can wait in the request queues until the token is acquired.
The request queues are divided into three different priorities, high priority (corresponding to the second priority above), medium priority (corresponding to the third priority above) and low priority (corresponding to the first priority above), respectively. The IO closely related to the user request, such as a user's read request and a write-down request for writing data from the memory to the disk, enters a high priority queue (corresponding to the second priority queue above) and is executed first, so as to ensure that the user's read request is at the highest priority and avoid blocking the write request due to the full memory component. The read-write request for the compression operation of the middle layer will enter the middle priority queue (corresponding to the third priority queue above) because the short constraint deferring the compression operation will not have a significant impact. The priority of the read-write request of the prefetch operation and the compression operation of the lowest layer is the lowest, and the read-write request enters a low priority queue (corresponding to the first priority queue above) and is executed by using the idle resources.
Three priority queues are prioritized by assigning time windows of different lengths to which tokens may be assigned. Wherein high priority request queues may always be assigned tokens, medium priority request queues may be assigned tokens with a smaller time window, and low priority request queues may be assigned tokens with a minimum time window. The time window sizes of the medium priority request queue and the low priority request queue are dynamically adjusted according to the number of tokens used per second in history, and the time window sizes are obtained by multiplying the number of pre-allocated IOPS (input/output) by the lowest delay of each IO and performing corresponding coefficient amplification. For example, if the medium priority queue consumes less tokens within a given time window, the time window size of the medium priority queue is reduced, the time window size of the low priority queue is increased, and more prefetch operations are performed. In this case, the time window of the low priority queue is smaller than that of the medium priority queue even if it is increased.
As shown in fig. 5, the present application provides a data prefetching method based on a key value storage system of the present application, including:
1. counting the access times of all the EBS-blocks every second, and calculating and updating the heat of the EBS-blocks according to the access times of the EBS-blocks;
2. selecting an EBS-block (corresponding to the first data block above) which has highest heat and is not cached in the prefetch cache for prefetching, placing an IO request corresponding to the prefetching in a low-priority request queue, and waiting for allocation of tokens;
3. after the IO request obtains the token, transmitting a corresponding IO request to the cloud storage volume, and reading a target EBS-block;
4. and caching the read target EBS-block into a pre-fetching module.
As shown in fig. 6, the present application provides a data read request processing method based on the key value storage system of the present application, including:
1. the key value storage system receives a request for reading target data;
2. searching a target data block (corresponding to the second data block in the above) in a passive cache in the data cache module, returning the data if the target data block is found, and ending the searching;
3. if the target data block is not found in the passive cache, searching the target EBS-block in the prefetching cache in the data cache module, returning the data if the target EBS-block is found, and ending the searching;
4. If the target EBS-block is not found in the prefetching module, searching the data block corresponding to the SSTable in each layer from the L0 layer to the LSM-tree layer by layer to find target data, placing the IO request in the high-priority queue, and executing IO operation after waiting for allocation of tokens;
5. after the token is obtained from the IO request, sending a corresponding IO request to the cloud storage, reading a target data block, and returning data;
6. and if the passive cache is started, caching the target data block into the passive cache.
As shown in fig. 7, the present application provides a data write request processing method based on the key value storage system of the present application, including:
the key value storage system receives a writing request for writing one data and judges the purpose of the writing request;
the key value storage system receives the data writing request and judges the purpose of the data writing request.
If the data writing request is a write-down operation for writing the SSTable generated by the target data in the memory of the key-value storage system into the L0 layer of the LSM-tree storage architecture of the key-value storage system, the specific steps are as follows:
1. adding the IO request to a high-priority queue, and waiting for allocation of tokens;
2. and executing IO request after the token is allocated, and writing SSTable into the L0 layer.
If the data writing request is a compression operation between SSTable of Li layer of LSM-tree storage architecture of the key value storage system and SSTable of L (i+1) layer of LSM-tree storage architecture of the key value storage system, which has a key value range overlapping with SSTable of Li layer, the specific steps are:
(1) If (i+1) is the bottommost layer, adding the IO request into a low-priority queue, otherwise, adding the IO request into a medium-priority queue;
(2) Writing the new SSTable generated by the compression operation into an L (i+1) layer after obtaining the token;
(3) And deleting SSTable of the Li layer and SSTable of the L (i+1) layer, which are overlapped with the SSTable existence key value range of the Li layer.
In general, through the above technical scheme that this application provided, can obtain following beneficial effect:
(1) The key value storage system comprises an LSM tree storage architecture, a fluctuation-aware data caching module and a congestion-aware IO distribution module. According to the LSM-tree storage architecture, hot spot data is actively prefetched into the prefetching cache through the data caching module when in low load, purchased cloud storage resources are fully utilized, IO in the high load period is guided to be redirected to the caching device, and therefore access load of cloud storage volumes under the high load is reduced. And the IO distribution module is used for distributing different priorities of different types of IO requests so as to more effectively utilize the IOPS of the cloud storage priority, and simultaneously limiting the requests sent to the cloud storage to be in a given range so as to ensure that the processing delay of the cloud storage is maintained in a low-delay state.
(2) The application provides a data prefetching method for realizing a key value storage system with high performance and low delay based on cloud storage construction. The data prefetching module can continuously count and update the heat of the EBS-block and prefetch the EBS-block with high heat, and the prefetch is only performed under low load when the prefetch is realized through the time windows with different sizes distributed to the prefetching queue by the IO distributor under different loads, so that the request under partial high load is transferred to the low load.
(3) The application provides a data reading request and data writing request processing method for realizing a key value storage system with high performance and low delay based on cloud storage construction. By giving different priorities to different types of read-write requests and then allocating different numbers of IOs, the purchased cloud storage performance can be fully and reasonably utilized.
An embodiment of the present application provides an electronic device, including: a memory and a processor; at least one program stored in the memory for execution by the processor, which, when executed by the processor, performs: by giving different priorities to different types of IO operations of data, adding the IO operations to a priority queue corresponding to the determined priorities to wait for allocation of tokens, and executing the IO operations after obtaining the tokens, the problem that the delay of a read-write request is increased due to competition or congestion generated among different types of IO requests is avoided, the limited performance of cloud storage can be utilized more efficiently, the average delay and tail delay of the read-write request are obviously reduced, and efficient reading and writing of the data are ensured.
In an alternative embodiment, an electronic device is provided, as shown in fig. 8, the electronic device 40 shown in fig. 8 comprising: a processor 401 and a memory 403. Processor 401 is connected to memory 403, such as via bus 402. Optionally, the electronic device 40 may further include a transceiver 404, and the transceiver 404 may be used for data interaction between the electronic device and other electronic devices, such as transmission of data and/or reception of data, etc. It should be noted that, in practical applications, the transceiver 404 is not limited to one, and the structure of the electronic device 40 is not limited to the embodiment of the present application.
The processor 401 may be a CPU (Central Processing Unit ), general purpose processor, DSP (Digital Signal Processor, data signal processor), ASIC (Application Specific Integrated Circuit ), FPGA (Field Programmable Gate Array, field programmable gate array) or other programmable logic device, transistor logic device, hardware components, or any combination thereof. Which may implement or perform the various exemplary logic blocks, modules, and circuits described in connection with this disclosure. Processor 401 may also be a combination that implements computing functionality, such as a combination comprising one or more microprocessors, a combination of a DSP and a microprocessor, or the like.
Bus 402 may include a path to transfer information between the components. Bus 402 may be a PCI (Peripheral Component Interconnect, peripheral component interconnect standard) bus or EISA (Extended Industry Standard Architecture ) bus, among others. Bus 402 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown in fig. 8, but not only one bus or one type of bus.
The Memory 403 may be, but is not limited to, a ROM (Read Only Memory) or other type of static storage device that can store static information and instructions, a RAM (Random Access Memory ) or other type of dynamic storage device that can store information and instructions, an EEPROM (Electrically Erasable Programmable Read Only Memory ), a CD-ROM (Compact Disc Read Only Memory, compact disc Read Only Memory) or other optical disk storage, optical disk storage (including compact discs, laser discs, optical discs, digital versatile discs, blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer.
The memory 403 is used for storing application program codes for executing the present application and is controlled to be executed by the processor 401. The processor 401 is arranged to execute application code stored in the memory 403 for implementing what is shown in the foregoing method embodiments.
The present application provides a computer readable storage medium having a computer program stored thereon, which when run on a computer, causes the computer to perform the corresponding method embodiments described above. Compared with the prior art, the method has the advantages that different priorities are given to different types of IO operations for data, the IO operations are added to the priority queues corresponding to the determined priorities to wait for allocation of tokens, and the IO operations are executed after the tokens are acquired, so that the time delay rise of read-write requests caused by competition or congestion among different types of IO requests is avoided, the limited performance of cloud storage can be utilized more effectively, the average delay and tail delay of the read-write requests are obviously reduced, and the efficient reading and writing of the data are ensured.
The terms "first," "second," "third," "fifth," "1," "2," and the like in the description and in the claims of this application and in the above-described figures, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the present application described herein may be implemented in other sequences than those illustrated or otherwise described.
It should be noted that, in the embodiment of the present application, the division of the units is schematic, which is merely a logic function division, and other division manners may be implemented in actual practice. In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.
The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a processor-readable storage medium. Based on such understanding, the technical solution of the present application may be embodied in essence or a part contributing to the prior art or all or part of the technical solution, in the form of a software product stored in a storage medium, including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor (processor) to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.
It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, magnetic disk storage, optical storage, and the like) having computer-usable program code embodied therein.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-executable instructions. These computer-executable instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These processor-executable instructions may also be stored in a processor-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the processor-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These processor-executable instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
It should be understood that, although the steps in the flowcharts of the figures are shown in order as indicated by the arrows, these steps are not necessarily performed in order as indicated by the arrows. The steps are not strictly limited in order and may be performed in other orders, unless explicitly stated herein. Moreover, at least some of the steps in the flowcharts of the figures may include a plurality of sub-steps or stages that are not necessarily performed at the same time, but may be performed at different times, the order of their execution not necessarily being sequential, but may be performed in turn or alternately with other steps or at least a portion of the other steps or stages.
The foregoing is only a partial embodiment of the present invention, and it should be noted that it will be apparent to those skilled in the art that modifications and adaptations can be made without departing from the principles of the present invention, and such modifications and adaptations are intended to be comprehended within the scope of the present invention.

Claims (14)

1. A method of data processing, comprising:
receiving IO operations for data;
determining a priority for the IO operation according to the type of the IO operation;
adding the IO operation to a corresponding priority request queue according to the determined priority, and waiting for allocation of tokens;
and after the IO operation acquires the token, executing the IO operation.
2. The method of claim 1, wherein the prioritizing the IO operations according to the type of IO operation comprises:
if the IO operation is a prefetching operation aiming at data, determining the IO operation as a first priority;
the performing the IO operation includes:
and after the IO operation obtains the token, sending a corresponding data reading request to the storage device so as to read a first data block and buffer the first data block into a first buffer, wherein the IO operation is added into a first priority request queue corresponding to the first priority to wait for the token to be allocated, and the first data block is determined based on the heat.
3. The method of claim 2, wherein determining the first data block comprises:
acquiring access times of at least two data blocks read in a statistical period;
updating the heat of the corresponding data blocks according to the access times of the at least two data blocks;
and selecting the data block which has the highest heat degree in the at least two data blocks and is not cached in the first cache in the statistical period as the first data block.
4. A method according to any one of claims 1-3, wherein said prioritizing said IO operations according to the type of IO operation comprises:
if the IO operation is a read request for data, determining that the IO operation is a second priority;
the performing the IO operation includes:
after the IO operation obtains the token, a corresponding data reading request is sent to the storage device so as to read a second data block, and the second data block is cached in a second cache under the condition that the second cache is opened;
and adding the IO operation into a second request queue corresponding to a second priority, and waiting for allocation of tokens, wherein the second priority is higher than the first priority.
5. The method of claim 4, wherein if the IO operation received is a read request for data, the method further comprises:
sequentially searching the second data block in the second cache and the first cache, returning if the second data block is found, and searching the second data block in the storage device if the second data block is not found;
the first cache manages a cache space by taking data blocks with a first granularity as a unit, and the second cache manages the cache space by taking data blocks with a second granularity smaller than the first granularity as a unit;
and if the IO number of the access storage equipment exceeds a first threshold value of the IOPS of the storage equipment, the second cache is started, otherwise, the first cache is started.
6. The method of claim 5, wherein a sum of cache spaces of the first cache and the second cache remains unchanged, and respective cache space sizes are dynamically variable.
7. The method of claim 6, wherein the method further comprises:
and if the heat of the fourth data block of the third data block in the second cache is higher than that of the coldest data block in the first cache, removing the coldest data block in the first cache and adding the released cache space into the second cache.
8. The method of claim 1, wherein if the IO operation received is a write request for target data, the method further comprises:
determining whether the IO operation is a write request for a lower brush or a compressed write request according to the source of the IO operation;
the write-in request of the lower brush is the lower brush operation of writing the SSTable of the ordering character string generated by the target data into the L0 layer of the log structure merging tree LSM-tree;
the compressed write request is an SSTable for a Li layer of the LSM-tree, and a compression operation between SSTable having a key value range overlapping with SSTable of the Li layer in an L (i+1) layer of the LSM-tree.
9. The method of claim 8, wherein the prioritizing the IO operations according to the type of IO operation comprises:
if the IO operation is a write-in request of the lower brush, determining that the IO operation is of a second priority;
the performing the IO operation includes:
after the IO operation obtains the token, writing the SSTable generated by the target data into the L0 layer, adding the IO operation into a second request queue corresponding to a second priority, and waiting for distributing the token, wherein the second priority is higher than the first priority.
10. The method of claim 8, wherein the prioritizing the IO operations according to the type of IO operation comprises:
if the IO operation is a compressed write request and the L (i+1) layer is the bottommost layer of the LSM-tree, determining that the IO operation is of a first priority;
if the IO operation is a compressed write request and the L (i+1) layer is not the bottommost layer of the LSM-tree, determining that the IO operation is of a third priority;
the performing the IO operation includes:
after the IO operation obtains the token, writing the SSTable generated by compression into the L (i+1) layer, wherein the IO operation is added into a first priority request queue corresponding to the first priority or a third priority request queue corresponding to the third priority to wait for the token to be allocated;
wherein the third priority is higher than the first priority and lower than the second priority.
11. The method according to claim 10, wherein the method further comprises:
deleting SSTable of the Li layer, and SSTable of the L (i+1) layer overlapping with SSTable existence key value range of the Li layer.
12. The method of claim 10, wherein the time window for allocating tokens for the priority request queue corresponding to the second priority, the third priority, and the first priority decreases in sequence.
13. An electronic device, the electronic device comprising:
one or more processors;
a memory;
one or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, the one or more applications configured to: the data processing method according to any one of claims 1 to 12 being performed.
14. A processor-readable storage medium, characterized in that the processor-readable storage medium stores a computer program for causing a processor to execute the data processing method according to any one of claims 1 to 12.
CN202310077005.3A 2023-01-16 2023-01-16 Data processing method, device and readable storage medium Pending CN116027982A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310077005.3A CN116027982A (en) 2023-01-16 2023-01-16 Data processing method, device and readable storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310077005.3A CN116027982A (en) 2023-01-16 2023-01-16 Data processing method, device and readable storage medium

Publications (1)

Publication Number Publication Date
CN116027982A true CN116027982A (en) 2023-04-28

Family

ID=86091286

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310077005.3A Pending CN116027982A (en) 2023-01-16 2023-01-16 Data processing method, device and readable storage medium

Country Status (1)

Country Link
CN (1) CN116027982A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116225345A (en) * 2023-05-08 2023-06-06 珠海妙存科技有限公司 Data storage method, controller and readable storage medium of eMMC

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116225345A (en) * 2023-05-08 2023-06-06 珠海妙存科技有限公司 Data storage method, controller and readable storage medium of eMMC
CN116225345B (en) * 2023-05-08 2023-08-11 珠海妙存科技有限公司 Data storage method, controller and readable storage medium of eMMC

Similar Documents

Publication Publication Date Title
US10176057B2 (en) Multi-lock caches
US20220091739A1 (en) Write type based crediting for block level write throttling to control impact to read input/output operations
Li et al. {ElasticBF}: Elastic Bloom Filter with Hotness Awareness for Boosting Read Performance in Large {Key-Value} Stores
CN107066397B (en) Method, system, and storage medium for managing data migration
CN109446114B (en) Spatial data caching method and device and storage medium
JP2003337834A (en) Resizable cache sensitive hash table
US11314689B2 (en) Method, apparatus, and computer program product for indexing a file
US11093410B2 (en) Cache management method, storage system and computer program product
Viglas Adapting the B+-tree for asymmetric I/O
CN110688062B (en) Cache space management method and device
CN110795363B (en) Hot page prediction method and page scheduling method of storage medium
CN113835616A (en) Data management method and system of application and computer equipment
CN116027982A (en) Data processing method, device and readable storage medium
US11928061B2 (en) Cache management method and apparatus
CN112199304B (en) Data prefetching method and device
CN113094392A (en) Data caching method and device
CN114138840A (en) Data query method, device, equipment and storage medium
CN106537321B (en) Method, device and storage system for accessing file
US20130013824A1 (en) Parallel aggregation system
CN107577618A (en) A kind of balanced caching in three roads eliminates method and device
CN114461590A (en) Database file page prefetching method and device based on association rule
CN115509437A (en) Storage system, network card, processor, data access method, device and system
CN115080459A (en) Cache management method and device and computer readable storage medium
CN113297106A (en) Data replacement method based on hybrid storage, related method, device and system
US10169250B2 (en) Method and apparatus method and apparatus for controlling access to a hash-based disk

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination