CN115543992A - Operation request processing method and related device - Google Patents

Operation request processing method and related device Download PDF

Info

Publication number
CN115543992A
CN115543992A CN202110732615.3A CN202110732615A CN115543992A CN 115543992 A CN115543992 A CN 115543992A CN 202110732615 A CN202110732615 A CN 202110732615A CN 115543992 A CN115543992 A CN 115543992A
Authority
CN
China
Prior art keywords
target
extension
address
block
extent
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
CN202110732615.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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies 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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202110732615.3A priority Critical patent/CN115543992A/en
Priority to PCT/CN2022/101768 priority patent/WO2023274197A1/en
Publication of CN115543992A publication Critical patent/CN115543992A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2282Tablespace storage structures; Management thereof
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • G06F16/2246Trees, e.g. B+trees
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0602Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0614Improving the reliability of storage systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0628Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638Organizing or formatting or addressing of data
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0628Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638Organizing or formatting or addressing of data
    • G06F3/0644Management of space entities, e.g. partitions, extents, pools
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0668Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671In-line storage system
    • G06F3/0673Single storage device
    • G06F3/0679Non-volatile semiconductor memory device, e.g. flash memory, one time programmable memory [OTP]

Abstract

The embodiment of the application provides an operation request processing method, which is applied to a hard disk controller and comprises the following steps: obtaining a target operation request, wherein the target operation request comprises a target logic address, and the target logic address is used for indicating a target block in a plurality of blocks; and determining a target physical address of the target block according to the target logical address and the address mapping relation, and performing data operation on a storage space where the target physical address is located. The method and the device reduce invasive modification of the original codes, greatly reduce the risk of software development, and are easy to realize in a database system based on PG.

Description

Operation request processing method and related device
Technical Field
The present application relates to the field of computers, and in particular, to an operation request processing method and a related apparatus.
Background
The present application relates to storage formats in database storage engines. Currently, postgreSQL (hereinafter referred to as PG) and PG-based databases use page-type heap storage. Each table, partition, or index has a separate physical file. This is simple to implement and makes it easier to manage the metadata of the heap, such as the free space map. However, if the number of tables and partitions is too large, the number of physical files will also increase.
To address the problem of physical file proliferation, segment paged storage may be used. The segment paged storage means that all tables and indexes are stored in the same file(s), the data of each table and index is a segment (segment), and each segment is further divided into a plurality of data page blocks.
However, the data storage mode belongs to the lowest layer design in the database software. The PG code, starting from the executor, defaults to the underlying storage, is exclusive to one physical file per table, and can access table data with consecutive page numbers starting from 0. Directly in a mature database system, a segment page type storage mode is introduced, so that the structure of a software system is damaged, and the compatibility is difficult.
Disclosure of Invention
In a first aspect, an embodiment of the present application provides an operation request processing method, where the method is applied to a hard disk controller, where the hard disk controller may be a controller implemented based on a PG;
the hard disk controller is used for allocating a logical address to a storage space of a hard disk, wherein the logical address comprises a target segment, the target segment is divided into a plurality of regions, and each region is divided into a plurality of blocks;
one segment may correspond to one object, such as an index or a data table, and one segment may be divided into a plurality of extensions, and each extension may include a continuous block. Optionally, the size of the storage space corresponding to one block may be 8KB;
the method comprises the following steps: obtaining a target operation request, wherein the target operation request comprises a target logical address, and the target logical address is used for indicating a target block in the plurality of blocks;
on a conventional storage system implemented based on PG, an operation of performing a data operation (e.g., a read/write operation) on a physical file may be performed through a sgr (storage manager) layer. The data block can represent the position of the block by the relfilename and the block number of the information "segment", wherein the relfilename is the file name of the file corresponding to the segment, and the block number is the offset of the data block in the segment. Therefore, if the data block in the file needs to be read and written, the storage engine may transfer < relfile, block number > to the smgr layer, and the smgr layer invokes a related system call. For example, when a sequential scan is performed, the storage engine will traverse the block number from 0 to read all the data blocks of the segment.
And determining a target physical address of the target block according to the target logical address and an address mapping relation, and performing data operation on a storage space where the target physical address is located.
In a database system implemented based on PG, because each physical file corresponds to a segment, an addressing mode of a physical address can be directly adopted, the physical address can include a file name and a physical number in a segment corresponding to the file name, the file name can directly correspond to a specific segment, the physical number is the position of a block in the segment, and because only one physical file corresponds to the segment, the segment segments can be sequentially traversed from 0 to the physical number; in the existing manner, in order to introduce section page storage into a PG implementation database, a large amount of codes need to be modified in an smgr layer, so that after a physical number is obtained, traversal cannot be performed from 0, but the starting position of a physical file corresponding to the physical number in a section segment needs to be determined, and then traversal is performed from the starting position until the block corresponding to the physical number, where the block corresponds to the physical number, and the codes above need to be modified in a large amount. In the embodiment of the application, addressing is not directly carried out based on physical numbers, but a logical address is configured as an intermediate address, a large number of codes do not need to be modified in an smgr layer, only the physical numbers originally provided in the smgr layer need to be changed into the logical address, the logical address can indicate the specific position of the block in the segment, addressing is carried out based on mapping from the logical address to the logical address, specifically, addressing can be carried out based on the target logical address of the target block and mapping from the target logical address to the physical address, namely, the physical address of the target block can be determined based on the target logical address, and data operation is carried out.
In one possible design, the target logical address includes first indication information and second indication information, where the first indication information is used to indicate the target segment, and the second indication information is used to indicate a location of the target block in the target segment, where the first indication information may include a relfilenamede field, and the second indication information may include a logical page number of the target block in the target segment.
Specifically, each segment still monopolizes one file from the view of the upper layer, and the block number of a data block is from 0 to n-1, where n is the total number of data blocks of the segment. The storage engine still passes < relfilename, block number > to the smgr layer, where the page number may be referred to as a logical page number. The storage manager can translate the logical page number into a specific physical address to perform data operation, does not need to modify the data format of the operation request, improves the compatibility, and is easy to realize in a database system based on PG.
In a possible implementation, the determining, according to the target logical address and through an address mapping relationship, a target physical address of the target block includes: determining a target extent in the plurality of extents and an offset of the target block in the target extent relative to an initial block of the target extent according to the logical page number, acquiring a first physical address of the initial block of the target extent through an address mapping relation according to the target extent, and acquiring a target physical address of the target block according to the first physical address and the offset.
Wherein, the extension mode of the extension in the segment is fixed. Thus, given a logical page number of a target extent, the corresponding extent and the offset in that extent (i.e. the offset of the target block in the target extent relative to the starting block of the target extent) can be calculated from the logical page number. For example, taking the extension allocation rule described in table 1 as an example, if the logical page number of the target extension is 516, the target extension belongs to Group 2 between 128 and 16384, and Group 1 occupies 128 page numbers in total, so the target extension belongs to the (516-128)/128 =3 (counted from 0) extensions in Group 2, and the offset is (516-128)% 128=4, where the "/" indicates rounding the division result and the "%" indicates remainder.
In the embodiment of the present application, the corresponding extent and the offset in the extent can be calculated according to the logical page number of the target extent. Therefore, the conversion from the logical page number to the physical page number can be realized only by finding the first physical address of the start block of each extent, i.e. constructing an address mapping relationship from the extent ID to the physical address (e.g. the physical page number). Alternatively, this address mapping relationship may be implemented based on an array, where the extent id is an index of the array, and the first physical address of the start block of the extent is a value of the array. After a first physical address of an initial block of the target extent and an offset of the target block relative to the initial block of the target extent in the target extent are obtained, a target physical address of the target block can be obtained according to the first physical address and the offset.
In one possible design, the address mapping may include a first level mapping and a second level mapping; according to the target extension, a target extension group to which the target extension belongs and a second-level mapping relation corresponding to the target extension group can be determined through the first-level mapping relation; the first-level mapping relation is used for indicating a plurality of extension groups and a second-level mapping relation corresponding to each extension group, and determining a first physical address of an initial block of a target extension according to the target extension and the second-level mapping relation corresponding to the target extension group; the second-level mapping relation is used for indicating the physical address of the starting block of each extent in the target extent group.
In order to store the physical address of the start block of each extension, a certain size of storage space (e.g. 4 Byte) is required, and taking the Segment shown in table 1 as an example, the total number of the three extensions of 64K, 1M and 8M is 255, so that the three extensions can be directly stored in the Header page of the Segment, and the size of the metadata is 255 × 4Byte =1kb. There is no upper limit to the number of extensions for 64MB. Assuming that the size of the single table is 32TB, about 32TB/64mb =512k extensions are needed, the size of the metadata is 2MB, the single segment head page cannot be stored, and the space reserved in advance is wasted. Therefore, the address mapping relationship may be stored in a form of a two-layer index tree (BMT), where the two-layer index tree may include a first-Level mapping relationship (also referred to as a Level0 index page in this embodiment) and a second-Level mapping relationship (also referred to as a Level1 index page in this embodiment). Each unit in the Level0 index page corresponds to the starting physical address of an extent. Each Level0 index page may be stored in one physical page, and taking 4Byte occupied by each starting physical address as an example, one physical page may store 8K/4=2k elements, where the operation symbol "/" represents division, it should be understood that the physical page herein may also be directly referred to as a Level0 index page. Because there are 512K extensions at most, the Level1 index page only needs 512K/2k =256 slots, wherein the operation symbol "/" represents division, and then can be stored in the physical page of the segment header, when the extensions in the segment are expanded to exceed the space size of the currently allocated segment header, the number of the physical pages of the segment header can be expanded, and it is not necessary to reserve more segment headers in advance, thereby reducing the waste of resources.
In one possible implementation, the plurality of extensions includes a first extension and a second extension, the first extension being closer to a start block of the target segment than the second extension, the first extension being a free extension, the second extension being an occupied extension; the method further comprises the following steps:
and modifying the physical address of the starting block of the first extent into the physical address of the starting block of the second extent in the address mapping relation.
Among them, one problem of the segmented page storage is that holes are easy to occur, even if the data table is deleted (e.g., based on a drop operation or a truncate operation), the occupied file storage space is not released. If the physical space is required to be recycled, the data block which is still used needs to be moved to the head of the segment page file, then the operation of changing the file size (ftrunate) is executed, and the unused part of the segment tail is released. In the embodiment of the application, because the upper layer sees all the logical addresses, and the logical addresses can be kept unchanged in the moving process, only the extensions close to the tail of the segment need to be moved to the head of the file, and the address mapping relationship needs to be updated. Specifically, the extent near the segment tail may be a second extent, where the first extent is a free extent, that is, the first extent is a free extent to which a physical file is not allocated (for example, physical data of the extent is deleted), and the extent may be moved with a granularity, and the second extent is moved to the first extent, that is, a logical address of the first extent is not changed, but a physical address of a starting block of the first extent in the address mapping relationship is modified to a physical address of a starting block of the second extent.
In a possible implementation, the storage space corresponding to each segment is used for storing a plurality of physical files, the storage spaces corresponding to M extensions in the plurality of extensions are used for storing target physical files, and the sizes of the storage spaces corresponding to the M extensions are the same.
Among them, segment-page storage is prone to fragmentation of free space due to allocation of extents of different sizes in the same physical file. For example, an existing database system based on PG may divide a segment into extensions of 64KB, 1MB, 8MB, and 64MB, and require the same segment, with the later extension size being greater than or equal to the previous extension. There is a high probability that there will be a large number of free extents in the file with a size of 64KB, but no extents with a contiguous size of 64MB can be allocated. In the embodiment of the application, only extensions with the same specification size are allocated to one physical file, so that the number of fragments in the free space can be reduced.
In one possible implementation, the data operations include at least one of the following types of operations: add operations, delete operations, modify operations, and query operations.
In a second aspect, the present application provides an operation request processing apparatus, where the apparatus is applied to a hard disk controller, where the hard disk controller is configured to allocate a logical address to a storage space of a hard disk, where the logical address includes a target segment, the target segment is divided into a plurality of regions, each region is divided into a plurality of blocks, and the apparatus includes:
an obtaining module, configured to obtain a target operation request, where the target operation request includes a target logical address, and the target logical address is used to indicate a target block in the multiple blocks;
the determining module is used for determining a target physical address of the target block according to the target logical address through an address mapping relation;
and the data operation module is used for performing data operation on the storage space where the target physical address is located.
In one possible implementation, the target logical address includes first indication information and second indication information, where the first indication information is used to indicate the target segment, and the second indication information is used to indicate a position of the target block in the target segment.
In one possible implementation, the first indication information includes a relfilenode field.
In one possible implementation, the second indication information includes a logical page number of the target block in the target segment.
In a possible implementation, the determining module is specifically configured to determine, according to the logical page number, a target extent in the multiple extents, and an offset of the target block in the target extent with respect to a starting block of the target extent;
acquiring a first physical address of an initial block of the target extend through an address mapping relation according to the target extend;
and acquiring a target physical address of the target block according to the first physical address and the offset.
In one possible implementation, the address mapping relationship includes a first level mapping relationship and a second level mapping relationship; the determining module is specifically configured to determine, according to the target extent, a target extent group to which the target extent belongs and a second-level mapping relationship corresponding to the target extent group through the first-level mapping relationship; the first-level mapping relation is used for indicating a plurality of extension groups and a second-level mapping relation corresponding to each extension group;
determining a first physical address of an initial block of the target extension according to the target extension and a second-level mapping relation corresponding to the target extension group; the second level mapping relation is used for indicating the physical address of the starting block of each extension in the target extension group.
In one possible implementation, the plurality of extensions includes a first extension and a second extension, the first extension being closer to a start block of the target segment than the second extension, the first extension being a free extension, the second extension being an occupied extension; the device further comprises:
and the address modification module is used for modifying the physical address of the starting block of the first extent into the physical address of the starting block of the second extent in the address mapping relation.
In one possible implementation, the storage space corresponding to each segment is used for storing a plurality of physical files.
In one possible implementation, storage spaces corresponding to M extensions of the plurality of extensions are used for storing the target physical file, and the size of the storage spaces corresponding to the M extensions is the same.
In one possible implementation, the data operations include at least one of the following types of operations: add operations, delete operations, modify operations, and query operations.
In a third aspect, the present application provides an operation request processing apparatus, which may include a processor, a memory coupled to the processor, the memory storing program instructions, and the program instructions stored in the memory when executed by the processor implement the first aspect and any one of the methods described above. For steps executed in each possible implementation manner of the first aspect, the processor may refer to the first aspect specifically, and details are not described here.
In a fourth aspect, the present application provides a computer readable storage medium having stored thereon a computer program which, when run on a computer, causes the computer to perform the method of any of the first aspects described above.
In a fifth aspect, the present application provides circuitry comprising processing circuitry configured to perform the method of the first aspect and any of the above.
In a sixth aspect, the present application provides a computer program which, when run on a computer, causes the computer to perform the method of any of the first aspects described above.
In a seventh aspect, the present application provides a chip system comprising a processor for implementing the functions referred to in the above aspects, e.g. transmitting or processing data and/or information referred to in the above methods. In one possible design, the system-on-chip further includes a memory for storing program instructions and data necessary for the server or the communication device. The chip system may be formed by a chip, or may include a chip and other discrete devices.
The embodiment of the application provides an operation request processing method, which is applied to a hard disk controller, wherein the hard disk controller is used for allocating a logical address to a storage space of a hard disk, the logical address comprises a target segment, the target segment is divided into a plurality of region extensions, and each extension is divided into a plurality of blocks; the method comprises the following steps: obtaining a target operation request, wherein the target operation request comprises a target logical address, and the target logical address is used for indicating a target block in the plurality of blocks; and determining a target physical address of the target block according to the target logical address and an address mapping relation, and performing data operation on a storage space where the target physical address is located. The method and the device address based on the target logical address of the target block and the mapping from the target logical address to the physical address, namely the physical address of the target block can be determined based on the target logical address, and data operation is carried out, codes above an smgr layer do not need to be modified or have small modification amplitude, the invasive modification of original codes is reduced, the risk of software development is greatly reduced, the page format does not need to be modified, the compatibility problem is avoided, and the method and the device are easy to realize in a database system based on PG
Drawings
FIG. 1A is a schematic diagram of an architecture of a database system;
fig. 1B is a schematic diagram of an architecture of a distributed database system according to an embodiment of the present application;
fig. 1C is a schematic diagram of another architecture of a distributed database system according to an embodiment of the present application;
fig. 1D is a schematic diagram of an application architecture provided in the embodiment of the present application;
FIG. 1E is a system schematic provided by an embodiment of the present application;
fig. 2 is a flowchart illustrating an operation request processing method according to an embodiment of the present application;
FIG. 3 is a schematic diagram of a segment provided in an embodiment of the present application;
FIG. 4 is a structural illustration of a segment provided in an embodiment of the present application;
fig. 5 is a schematic diagram of an address mapping relationship shown in an embodiment of the present application;
fig. 6 is a schematic diagram of a shrink operation according to an embodiment of the present disclosure;
fig. 7 is a schematic structural diagram of an operation request processing apparatus provided in the present application;
FIG. 8 is an illustration of a computer-readable storage medium provided herein;
fig. 9 is an illustration of a computer device provided herein.
Detailed Description
Embodiments of the present application will be described with reference to the accompanying drawings, and it is to be understood that the described embodiments are only some embodiments of the present application, and not all embodiments of the present application. As can be known to those skilled in the art, with the development of technology and the emergence of new scenarios, the technical solution provided in the embodiments of the present application is also applicable to similar technical problems.
The terms "first," "second," and the like in the description and in the claims of the present application and in the above-described drawings are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It will be appreciated that the data so used may be interchanged under appropriate circumstances such that the embodiments described herein may be practiced otherwise than as specifically illustrated or described herein. Moreover, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or modules is not necessarily limited to those steps or modules explicitly listed, but may include other steps or modules not expressly listed or inherent to such process, method, article, or apparatus. The naming or numbering of the steps appearing in the present application does not mean that the steps in the method flow must be executed according to the chronological or logical sequence indicated by the naming or numbering, and the named or numbered steps of the flow may be executed in a changed order according to the technical purpose to be achieved, as long as the same or similar technical effects are achieved.
The method provided by the embodiment of the present application can be applied to a database system (database system) 100 shown in fig. 1A, where the database system 100 is communicatively connected to an application server 300 to provide a database service for the application server 300. The application server 300 is communicatively connected to a client 200, the client 200 typically being an application program deployed on a user device, and the client 200 performs a specific function, such as downloading or uploading data, by initiating a service request to the application server 300. How the application server 300 needs to operate the data related to the client 200 (such as querying data, adding data, updating data, deleting data, and the like) in response to the service request of the client 200 can be realized by sending an operation request to the database system 100.
Fig. 1A shows a typical logical architecture of a database system 100, and according to fig. 1A, the database system 100 includes a database 110 and a database management system (DBMS) 130.
Among other things, database 110 is an organized collection of data stored in a data store (data storage) 120, i.e., an associated collection of data that is organized, stored, and used according to a particular data model. Data can be classified into various types, such as relational data, graph data, time series data, and the like, according to a data model used to organize the data. Relational data is data modeled using a relational model, usually represented as a table, with rows in the table representing sets of related values for an object or entity. Graph data, referred to simply as "graphs," is used to represent relationships, such as social relationships, between objects or entities. Time series data, which is time series data for short, is a data column recorded and indexed in time order and is used to describe state change information of an object in a time dimension.
The database management system 130 is the core of the database system and is the system software used to organize, store, and maintain the data. Clients 200 may access database 110 through database management system 130, through which database administrators also perform database maintenance work. The database management system 130 provides a variety of functions for the client 200 to create, modify and query the database, wherein the client 200 may be an application or a user device running an application. The functionality provided by the database management system 130 may include, but is not limited to, the following: (1) A data definition function, in which the database management system 130 provides a Data Definition Language (DDL) to define the structure of the database 110, the DDL is used to delineate the database framework and can be stored in the data dictionary; (2) A data access function, in which the database management system 130 provides a Data Manipulation Language (DML) to implement basic access operations on the database 110, such as retrieval, insertion, modification, and deletion; (3) A database operation management function, wherein the database management system 130 provides a data control function to effectively control and manage the operation of the database 110 so as to ensure that the data is correct and effective; (4) The establishment and maintenance functions of the database comprise the functions of loading initial data of the database, dumping, recovering and reorganizing the database, monitoring and analyzing the system performance and the like; (5) The transmission of the database, and the transmission of the processing data provided by the database management system, to achieve communication between the client and the database management system, is usually done in coordination with the operating system.
Database storage 120 includes, but is not limited to, solid State Drives (SSDs), disk arrays, cloud storage, or other types of non-transitory computer-readable storage media.
In the embodiment of the present application, the client 200 may initiate a service request to the application server 300, and a data service is deployed in the application server 300 for responding to the service request initiated by the client 200. In one embodiment, the data service deployed on the application server 300 may check the validity of the access of the client 200, and after the check passes, record a session, and convert a service request initiated by the client 200 into a data operation request, such as a query statement, for the database 110. Further, the data service can perform real-time statistics and control on system resources occupied by different clients 200.
It should be understood that one skilled in the art will appreciate that a database system may include fewer or more components than are shown in FIG. 1A, or different components than are shown in FIG. 1A, with FIG. 1A only showing components more relevant to the disclosed implementation of embodiments of the invention.
An embodiment of an application server 300 provided by the present application is described below with reference to fig. 1B.
The functions performed by the application server 300 may include, but are not limited to, access control, session management, data management, resource monitoring, storage management, and the like. The access control can control the legality and bandwidth of the client access. And session management, namely performing session management on the client with successful access. And data management, which can convert the service request of the client into an operation request for the database. And the resource monitoring can be used for carrying out real-time statistics and control on system resources occupied by different clients. Storage management may convert an operation request for a database into an operation request supported or executable by a database system, such as a database query statement (abbreviated as "query"), where the query may be a Structured Query Language (SQL) query. It should be noted that, the application server 300 converts the service request into a query supported or executable by the database system, and the query may be completed once or multiple times, and the specific conversion process belongs to the prior art in the field.
The database system provided in the embodiment of the present application may be a distributed database system (DDBS), for example, a database system with a Massively Parallel Processing (MPP) architecture. The DDBS is described below in conjunction with fig. 1C and 1D.
Fig. 1C is a schematic diagram of a distributed database system using a shared-storage architecture, which includes one or more Coordinator Nodes (CN), a plurality of Data Nodes (DN), and of course, the DDBS may also include other components, such as: the CN and the DN communicate with each other through a network channel. The CN may generate an execution plan corresponding to the query according to the received query, such as the query from the application server, and distribute the query to the corresponding DN for execution based on the execution plan. The CN may also generate a query result based on the execution result of the DN. In one embodiment, the network channel may be composed of network devices such as switches, routers, and gateways. The CN and the DN jointly realize the function of the database management system and provide services of retrieval, insertion, modification, deletion and the like of the database for the client. In one embodiment, a database management system is deployed on each CN and DN. The shared data memory stores data shared by a plurality of DN, and DN can execute read-write operation to data in the data memory through network channel. The shared data storage may be a shared disk array. The CN and DN in the distributed database system may be physical machines, such as database servers, or Virtual Machines (VMs) or containers (containers) running on abstract hardware resources. In one embodiment, the CN and DN are virtual machines or containers, and the network channel is a virtual switch network that includes a virtual switch. The database management system deployed in the CN and the DN is a DBMS instance (instance), which may be a process or a thread, and these DBMSs cooperate to complete the function of the database relational system. In another embodiment, the CN and the DN are physical machines, the network channel includes one or more switches, and the switches are Storage Area Network (SAN) switches, ethernet switches, fabric switches, or other physical switching devices.
Fig. 1D is a schematic diagram of a distributed database system using shared-nothing (shared-nothing) architecture, where each DN has its own hardware resource (e.g., CPU, memory, data storage, etc.), and the CN and the DN communicate with each other through a network channel, which can be understood by referring to the corresponding description in fig. 1C. Under the system, data are distributed to each DN according to a database model and application characteristics, a query task is divided into a plurality of parts by CN, the parts are executed in parallel on a plurality of DNs and are calculated in cooperation with each other to provide database service as a whole, and all communication functions are realized on a high-broadband network interconnection system. As with the distributed database system of the shared-storage architecture depicted in fig. 1C, the CN and the DN may be physical machines or virtual machines.
In all embodiments of the present application, the data storage of the database system includes, but is not limited to, a Solid State Drive (SSD), a disk array, or other types of non-transitory computer readable media. Although the database is not shown in fig. 1C-1D, it should be understood that the database is stored in a data store. Those skilled in the art will appreciate that a database system may include fewer or more components than are shown in fig. 1A-1D, or different components than are shown in fig. 1A-1D, with fig. 1A-1D merely illustrating components more relevant to the implementations disclosed in embodiments of the present application. It will be understood by those skilled in the art that a distributed database system may include any number of CNs and DNs. The database management system functions of each CN and DN may be implemented by a suitable combination of software, hardware, and/or firmware running on each CN and DN, respectively.
In this embodiment of the application, the distributed database system may provide a deployment service for an application program (APP) for an application developer, specifically, the application program may be deployed in a node in the distributed database system, such as a virtual machine, the virtual machine may include one or more data nodes DN and a corresponding data storage (for example, the shared data storage in fig. 1C or the data storage in fig. 1D), the application program may send a service request to an application server, and the application server processes the service request, for example, converts the service request of the application program into one or more data operation requests (abbreviated as "operation requests") supported or executable by the database system, and sends the data operation requests to the distributed database system. And responding to the data operation request, and operating the data in the data storage by the DN corresponding to the application program in the distributed database system.
Fig. 1E illustrates a server provided in the embodiment of the present application, specifically, as shown in fig. 1E, the operation request processing method in the embodiment of the present application may be stored in a storage engine module (specifically, the segment page type storage module in fig. 1E) of a database system in the form of program codes, and in the embodiment of the present application, the storage engine module may be referred to as a hard disk controller. In operation, program code may be run in the host memory of the server to manage the database system's access to data on the physical files. The segment page type storage module can receive a file read-write request of the smgr layer, translate a logical address (such as a logical page number) into a physical address (such as a physical page number), and read and write a physical file at the corresponding physical address. Meanwhile, the segment page type storage module can also utilize buffer, xlog and checkpoint modules in the existing storage engine to realize the persistence and consistency of metadata in the segment page type module.
Fig. 2 is a flowchart illustrating an operation request processing method provided in an embodiment of the present application, and as shown in fig. 2, the operation request processing method provided in the embodiment of the present application includes:
201. obtaining a target operation request, wherein the target operation request comprises a target logical address, and the target logical address is used for indicating a target block in the plurality of blocks.
The embodiment of the present application may be applied to a hard disk controller, where the hard disk controller may be a controller implemented based on PG, and the hard disk controller is configured to allocate a logical address to a storage space of a hard disk, where the logical address may be divided into a plurality of segment segments (including a target segment), each segment of the plurality of segment segments may be divided into a plurality of extensions, and each extension is divided into a plurality of blocks.
Referring to fig. 3, fig. 3 is a schematic diagram of logical address division of a storage space, where one segment may correspond to an object, such as an index or a data table, and one segment may be divided into a plurality of extensions, and each extension may include a continuous block. A block may correspond to a memory size of 8KB. Because there may be discontinuities between extensions, linked list pointers may be placed on pages to concatenate different extensions of the same segment (e.g., the pointers may be left and right siblings of the B + tree) to support sequential scanning.
The above segment is described next in connection with the creation process of the data table by the storage manager:
when creating a data table, the storage manager allocates a data block to the data table as a segment header of the data table, and a block number of the data block is recorded in the system table and plays a role of relfilecode. Each time data is inserted into the data table, a free data block is searched as an insertion object, if the free data block cannot be found, a new extension is allocated and mounted on the segment of the data table. When the data table is just created, the number of data blocks included in the corresponding segment is 0. At the beginning, the extension extended in the segment is small, for example, 64KB; as the table increases, the size of each new extension increases.
Referring to fig. 4, fig. 4 is a schematic structure of a segment of the present application, wherein the segment is divided into extensions of four size levels, wherein the first 16 extensions of the segment may have a size of 64K, the last 127 extensions may have a size of 1M, the last 112 extensions may have a size of 8M, and the last extensions may have a size of 64M. A specific allocation strategy can be shown in table 1 below, where an extent count refers to the several extents in a segment, the first 16 extents belong to Group 1 (Group 1), each size is 64KB, the total size is 1M, the 17 th to 143 th extents belong to Group 2 (Group 2), the size is 1MB, the 144 th to 255 th extents belong to Group 3 (Group 3), and the size is 8M; extensions starting from the 256-th extension belong to Group 4 (Group 4) and are all 64MB in size. This has the advantage that a good balance between space utilization and allocation frequency can be achieved. If a large extent is initially allocated, this results in a waste of storage space. If the late table is large, the extension is too small, which causes frequent allocation of the extension and reduces efficiency. And large extensions, also in favor of sequential I/O.
TABLE 1
Group Extent size Extent count range Total size
1 64K [1,16] 1M
2 1M [17,143] 128M
3 8M [144,255] 1G
4 64M [256,…]
In this embodiment, a storage controller may obtain a target operation request, where the target operation request is used to indicate a block (target block) to be subjected to a data operation.
On a conventional storage system implemented based on PG, an operation of performing a data operation (e.g., a read/write operation) on a physical file may be performed through a sgr (storage manager) layer. The data block can represent the position of the block by 'refill, block number' of segment, where refill is the file name of the file corresponding to the segment, and block number is the offset of the data block in the segment, and since each segment monopolizes a physical file in the existing storage system implemented based on PG, block number is the physical address of the data block. Therefore, if the data block in the file needs to be read and written, the storage engine may transmit < relfilemode, block number > to the smgr layer, and the smgr layer calls the related system call. For example, when doing sequential scan, the storage engine would traverse the block number from 0 to read all the data blocks of the segment.
In the embodiment of the application, the target operation request includes a target logical address, the target logical address is used for indicating a target block in the blocks, the physical address of the target block can be determined based on the target logical address, and data operation is performed, all modifications are concentrated under the smgr layer, and damage to an existing PG related code structure is small.
In one possible design, the target logical address includes first indication information and second indication information, where the first indication information is used to indicate the target segment, and the second indication information is used to indicate a location of the target block in the target segment, where the first indication information may include a relfilenamede field, and the second indication information may include a logical page number of the target block in the target segment.
Specifically, each segment still monopolizes one file from the view of the upper layer, and the block number of a data block is from 0 to n-1, where n is the total number of data blocks of the segment. The storage engine still passes < relfilename, block number > to the smgr layer, where the page number may be referred to as a logical page number. The memory manager may translate logical page numbers to specific physical addresses for data operations.
The embodiment of the application adopts a logical address mode for addressing, codes above a smgr layer do not need to be modified, the invasive modification of original codes is reduced, the risk of software development is greatly reduced, the page format does not need to be modified, the compatibility problem is avoided, and the implementation in a database system based on PG is easy.
202. And determining the target physical address of the target block according to the target logical address and through an address mapping relation.
In one possible design, a target extent of the plurality of extents and an offset of the target block in the target extent relative to a starting block of the target extent may be determined based on the logical page number.
In the embodiment of the present application, the extension mode in the segment is fixed. Therefore, given a logical page number of a target extent, a corresponding extent and an offset in the extent (that is, an offset of a target block in the target extent relative to a starting block of the target extent) can be calculated according to the logical page number. For example, taking the extension allocation rule described in table 1 as an example, if the logical page number of the target extension is 516, the target extension belongs to Group 2 between 128 and 16384, and Group 1 occupies 128 page numbers in total, so the target extension belongs to the (516-128)/128 =3 (counted from 0) extensions in Group 2, and the offset is (516-128)% 128=4, where the "/" indicates rounding the division result and the "%" indicates remainder.
In a possible design, a first physical address of a start block of the target extent may be obtained through an address mapping relationship according to the target extent.
In the embodiment of the present application, the corresponding extent and the offset in the extent can be calculated according to the logical page number of the target extent. Therefore, the conversion from the logical page number to the physical page number can be realized only by finding the first physical address of the start block of each extent, i.e. constructing an address mapping relationship from the extent ID to the physical address (e.g. the physical page number). Alternatively, this address mapping relationship may be implemented based on an array, where the extent id is an index of the array, and the first physical address of the start block of the extent is a value of the array.
In the embodiment of the application, the first physical address of the starting block of the target extent and the offset of the target block relative to the starting block of the target extent in the target extent are obtained, and then the target physical address of the target block can be obtained according to the first physical address and the offset.
Next, a storage manner of the address mapping relationship is described:
in one possible design, the address mapping may include a first level mapping and a second level mapping; according to the target extension, a target extension group to which the target extension belongs and a second-level mapping relation corresponding to the target extension group can be determined through the first-level mapping relation; the first-level mapping relation is used for indicating a plurality of extension groups and a second-level mapping relation corresponding to each extension group, and determining a first physical address of an initial block of a target extension according to the target extension and the second-level mapping relation corresponding to the target extension group; the second-level mapping relation is used for indicating the physical address of the starting block of each extent in the target extent group.
In order to store the physical address of the start block of each extension, a certain size of storage space (e.g. 4 Byte) is required, and taking the Segment shown in table 1 as an example, the total number of the three extensions of 64K, 1M and 8M is 255, so that the three extensions can be directly stored in the Header page of the Segment, and the size of the metadata is 255 × 4Byte =1kb. There is no upper limit to the number of extensions of 64MB. Assuming that the size of the single table is 32TB, about 32TB/64mb =512k extensions are needed, the metadata size is 2MB, the single segment head page cannot be stored, and the space reserved in advance is wasted. Therefore, the address mapping relationship may be stored in the form of a two-Level index tree (BMT), where the two-Level index tree may include a first-Level mapping relationship (also referred to as a Level0 index page in this embodiment) and a second-Level mapping relationship (also referred to as a Level1 index page in this embodiment). Each unit in the Level0 index page corresponds to the initial physical address of an extent. Each Level0 index page may be stored in one physical page, and taking 4Byte occupied by each starting physical address as an example, one physical page may store 8K/4=2k elements, where the operation symbol "/" represents division, it should be understood that the physical page herein may also be directly referred to as a Level0 index page. Because 512K extensions exist at most, level1 index pages only need 512K/2k =256 slots, wherein the operation symbol "/" represents division, and then can be stored in the physical pages of segment headers, when the extensions in the segments are expanded to exceed the space size of the currently allocated segment headers, the number of the physical pages of the segment headers can be expanded, and more segment headers do not need to be reserved in advance, so that the waste of resources is reduced.
Referring to fig. 5, fig. 5 is a storage manner of address mapping relationship for segment in table 1, wherein the starting physical addresses of 8K, 16K and 8M extensions are directly obtained from a Level0 index table stored in a segment header, and 64M extensions need to be mapped from the Level1 index table to the Level0 index table to find the starting physical address of the extension. Thus, up to two layers of addressing are required to locate the starting physical address of the extension.
The plurality of extensions comprise a first extension and a second extension, the first extension is closer to the starting block of the target section segment than the second extension, the first extension is an idle extension, the second extension is an occupied extension, and when the index reduction shrink operation is carried out, the physical address of the starting block of the first extension in the address mapping relation can be modified into the physical address of the starting block of the second extension.
Among them, one problem of the segmented page storage is that holes are easy to occur, even if the data table is deleted (e.g., based on a drop operation or a truncate operation), the occupied file storage space is not released. If the physical space is required to be recycled, the data block which is still used needs to be moved to the head of the segment page file, then the operation of changing the file size (ftrunate) is executed, and the unused part of the segment tail is released. In the embodiment of the application, because the upper layer sees all the logical addresses, and the logical addresses can be kept unchanged in the moving process, only the extensions close to the tail of the segment need to be moved to the head of the file, and the address mapping relationship needs to be updated. Specifically, the extent near the segment tail may be a second extent, where the first extent is a free extent, that is, the first extent is a free extent to which a physical file is not allocated (for example, physical data of the extent is deleted), and the extent may be moved with a granularity, and the second extent is moved to the first extent, that is, a logical address of the first extent is not changed, but a physical address of a starting block of the first extent in the address mapping relationship is modified to a physical address of a starting block of the second extent.
In a possible design, the storage space corresponding to each segment may be used to store a plurality of physical files, the storage spaces corresponding to M extensions in the plurality of extensions in the target segment are used to store the target physical files, and the sizes of the storage spaces corresponding to the M extensions are the same.
Among them, segment-page storage is prone to fragmentation of free space due to allocation of extents of different sizes in the same physical file. For example, an existing database system based on PG may divide a segment into extensions of 64KB, 1MB, 8MB, and 64MB, and require the same segment, with the later extension size being greater than or equal to the previous extension. Then there is likely to be a large number of free extents in the file that are 64KB in size, but no extents can be allocated that are contiguous 64MB in size. In the embodiment of the application, only extensions with the same specification size are allocated to one physical file, so that the number of fragments in the free space can be reduced.
203. And performing data operation on the storage space where the target physical address is located.
In one possible implementation, the data operations include at least one of the following types of operations: add operations, delete operations, modify operations, and query operations.
The comparison of the results of the present application compared to the prior art can be seen in table 2:
TABLE 2
Prior Art The embodiments of the present application
For existing code modifier (prediction) >50,000 <1000
Whether to modify page format Is that Whether or not
Granularity of data relocation in Shrink Watch (CN) Data block
Whether to rebuild the index when Shrink Is that Whether or not
The embodiment of the application provides an operation request processing method, which is applied to a hard disk controller, wherein the hard disk controller is used for allocating a logical address to a storage space of a hard disk, the logical address comprises a target segment, the target segment is divided into a plurality of region extensions, and each extension is divided into a plurality of blocks; the method comprises the following steps: obtaining a target operation request, wherein the target operation request comprises a target logical address, and the target logical address is used for indicating a target block in the plurality of blocks; and determining a target physical address of the target block according to the target logical address and an address mapping relation, and performing data operation on a storage space where the target physical address is located. In a database system implemented based on PG, because each physical file corresponds to a segment, an addressing mode of a physical address can be directly adopted, the physical address can include a file name and a physical number in a segment corresponding to the file name, the file name can directly correspond to a specific segment, the physical number is the position of a block in the segment, and because only one physical file corresponds to the segment, the segment segments can be sequentially traversed from 0 to the physical number; in the existing manner, in order to introduce segment page storage into a PG implementation database, a large number of codes need to be modified in an smgr layer, so that after a physical number is obtained, traversal cannot be performed from 0, but a start position of a physical file corresponding to the physical number in a segment needs to be determined, and then traversal is performed from the start position to a block corresponding to the physical number, where the codes need to be modified in a large number. In the embodiment of the application, addressing is not directly performed based on a physical number, but a logical address is configured as an intermediate address, a large number of codes do not need to be modified in an smgr layer, only the physical number originally provided in the smgr layer needs to be changed into the logical address, the logical address can indicate the specific position of the block in the segment, addressing is performed based on mapping from the logical address to the logical address, specifically, addressing can be performed based on the target logical address of the target block and mapping from the target logical address to the physical address, that is, the physical address of the target block can be determined based on the target logical address, and data operation is performed, all modifications can be concentrated under the smgr layer, the modification amplitude of the codes above the smgr layer is small, that is, damage to the existing code structure related to PG is small, invasive modification of the original codes is reduced, the risk of software development is greatly reduced, the page format does not need to be modified, compatibility is improved, and the implementation in a database system based on PG is easy.
The operation request processing method provided by the embodiment of the present application is described in detail above with reference to fig. 2 to 6, and the operation request processing apparatus provided by the embodiment of the present application is described below from the perspective of the functional unit with reference to the drawings.
Referring to fig. 7, fig. 7 is a schematic structural diagram of an operation request processing apparatus according to an embodiment of the present application, where the apparatus 700 may be applied to a hard disk controller, and the hard disk controller is configured to allocate a logical address to a storage space of a hard disk, where the logical address includes a target segment, the target segment is divided into a plurality of region extensions, and each extension is divided into a plurality of blocks, and the apparatus includes:
an obtaining module 701, configured to obtain a target operation request, where the target operation request includes a target logical address, and the target logical address is used to indicate a target block in the multiple blocks;
for a detailed description of the obtaining module 701, reference may be made to the description of step 201 in the foregoing embodiment, which is not described herein again.
A determining module 702, configured to determine, according to the target logical address, a target physical address of the target block through an address mapping relationship;
for a detailed description of the determining module 702, reference may be made to the description of step 202 in the foregoing embodiment, which is not described herein again.
The data operation module 703 performs data operation on the storage space where the target physical address is located.
For a detailed description of the data operation module 703, reference may be made to the description of step 203 in the foregoing embodiment, which is not described herein again.
In one possible implementation, the target logical address includes first indication information and second indication information, where the first indication information is used to indicate the target segment, and the second indication information is used to indicate a location of the target block in the target segment.
In one possible implementation, the first indication information includes a relfilenode field.
In one possible implementation, the second indication information includes a logical page number of the target block in the target segment.
In a possible implementation, the determining module 702 is specifically configured to determine, according to the logical page number, a target extent in the multiple extents, and an offset of the target block in the target extent relative to a starting block of the target extent;
acquiring a first physical address of an initial block of the target extension through an address mapping relation according to the target extension;
and acquiring a target physical address of the target block according to the first physical address and the offset.
In one possible implementation, the address mapping relationship includes a first level mapping relationship and a second level mapping relationship; the determining module is specifically configured to determine, according to the target extent and through the first-level mapping relationship, a target extent group to which the target extent belongs and a second-level mapping relationship corresponding to the target extent group; the first-level mapping relation is used for indicating a plurality of extension groups and a second-level mapping relation corresponding to each extension group;
according to the target extensions, determining a first physical address of an initial block of the target extensions through a second-level mapping relation corresponding to the target extension group; the second-level mapping relation is used for indicating the physical address of the starting block of each extent in the target extent group.
In one possible implementation, the plurality of extensions includes a first extension and a second extension, the first extension being closer to a start block of the target segment than the second extension, the first extension being a free extension, the second extension being an occupied extension; the device further comprises:
an address modification module 704, configured to modify a physical address of the start block of the first extent in the address mapping relationship to a physical address of the start block of the second extent.
In one possible implementation, the storage space corresponding to each segment is used for storing a plurality of physical files.
In one possible implementation, storage spaces corresponding to M extensions of the plurality of extensions are used for storing the target physical file, and the size of the storage spaces corresponding to the M extensions is the same.
In one possible implementation, the data operations include at least one of the following types of operations: add operations, delete operations, modify operations, and query operations.
With reference to fig. 8, the present application further provides a computer-readable storage medium, and in some embodiments, the method disclosed in fig. 2 above may be embodied as computer program instructions encoded on the computer-readable storage medium in a machine-readable format or on other non-transitory media or articles of manufacture. Fig. 8 schematically illustrates a conceptual partial view of an example computer program product comprising a computer program for executing a computer process on a computing device, arranged in accordance with at least some embodiments presented herein. In one embodiment, the example computer program product 800 is provided using a signal bearing medium 801. The signal bearing medium 801 may include one or more program instructions 802 that, when executed by one or more processors, may provide the functions or portions of the functions described above with respect to fig. 2. Thus, for example, referring to the embodiment shown in fig. 2, one or more features of steps 201-203 may be undertaken by one or more instructions associated with the signal bearing medium 801. Further, program instructions 802 in FIG. 8 also describe example instructions.
In some examples, signal bearing medium 801 may include a computer readable medium 803, such as, but not limited to, a hard disk drive, a Compact Disc (CD), a Digital Video Disc (DVD), a digital tape, a Memory, a Read-Only Memory (ROM), a Random Access Memory (RAM), or the like. In some implementations, the signal bearing medium 801 may include a computer recordable medium 804 such as, but not limited to, a memory, a read/write (R/W) CD, a R/W DVD, and so forth. In some implementations, the signal bearing medium 801 may include a communication medium 805 such as, but not limited to, a digital and/or analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link, etc.). Thus, for example, the signal bearing medium 801 may be conveyed by a wireless form of communication medium 805 (e.g., a wireless communication medium that complies with the IEEE 802.11 standard or other transport protocol). The one or more program instructions 802 may be, for example, computer-executable instructions or logic-implementing instructions. In some examples, a computing device of the computing device may be configured to provide various operations, functions, or actions in response to program instructions 802 conveyed to the computing device by one or more of a computer readable medium 803, a computer recordable medium 804, and/or a communications medium 805. It should be understood that the arrangements described herein are for illustrative purposes only. Thus, those skilled in the art will appreciate that other arrangements and other elements (e.g., machines, interfaces, functions, orders, and groupings of functions, etc.) can be used instead, and that some elements may be omitted altogether depending upon the desired results. In addition, many of the described elements are functional entities that may be implemented as discrete or distributed components or in conjunction with other components, in any suitable combination and location.
Fig. 9 is a schematic diagram illustrating a possible logical structure of a computer device 90 according to the foregoing embodiments provided for an embodiment of the present application, where the computer device 90 may be the operation request processing apparatus in fig. 8. The computer device 90 may include: a processor 901, a communication interface 902, a memory 903, and a bus 904. The processor 901, the communication interface 902, and the memory 903 are connected to each other by a bus 904. In the embodiment of the present application, the processor 901 is configured to perform the steps from step 201 to step 203 in the embodiment of fig. 2. The communication interface 902 is used to support the computer device 90 for communication, such as: the communication interface 902 may perform steps related to receiving or transmitting in the above-described method embodiments. A memory 903 for storing program codes and data of the database server.
The processor 901 may be a central processing unit, a general purpose processor, a digital signal processor, an application specific integrated circuit, a field programmable gate array or other programmable logic device, a transistor logic device, a hardware component, or any combination thereof. Which may implement or perform the various illustrative logical blocks, modules, and circuits described in connection with the disclosure. A processor may also be a combination of computing functions, e.g., a combination of one or more microprocessors, a digital signal processor and a microprocessor, or the like. The bus 904 may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in FIG. 9, but this does not indicate only one bus or one type of bus.
In another embodiment of the present application, a chip system is further provided, where the chip system includes a processor, and the apparatus for supporting injection of time series data or the apparatus for querying time series data implements the operation request processing method described in the embodiment of fig. 2. In one possible design, the system-on-chip may further include a memory storing program instructions and data necessary for the means for managing data of the application. The chip system may be constituted by a chip, or may include a chip and other discrete devices.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the embodiments of the present application.
It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
In the several embodiments provided in the embodiments of the present application, it should be understood that the disclosed system, apparatus, and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, a division of a unit is only a logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
Units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.
The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application, which essentially or partly contribute to the prior art, may be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the methods of the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.
The above description is only a specific implementation of the embodiments of the present application, but the scope of the embodiments of the present application is not limited thereto, and any person skilled in the art can easily conceive of changes or substitutions within the technical scope of the embodiments of the present application, and all the changes or substitutions should be covered by the scope of the embodiments of the present application. Therefore, the protection scope of the embodiments of the present application shall be subject to the protection scope of the claims.

Claims (23)

1. An operation request processing method is applied to a hard disk controller, and the hard disk controller is used for allocating a logical address for a storage space of a hard disk, wherein the logical address comprises a target segment, the target segment is divided into a plurality of region extensions, each extension is divided into a plurality of blocks, and the method comprises the following steps:
obtaining a target operation request, wherein the target operation request comprises a target logical address, and the target logical address is used for indicating a target block in the plurality of blocks;
determining a target physical address of the target block according to the target logical address through an address mapping relation;
and performing data operation on the storage space where the target physical address is located.
2. The method of claim 1, wherein the target logical address comprises first indication information and second indication information, the first indication information indicating the target segment, and the second indication information indicating a location of the target block in the target segment.
3. The method of claim 2, wherein the first indication information comprises a relfilenode field.
4. A method according to claim 2 or 3, wherein the second indication information comprises a logical page number of the target block in the target segment.
5. The method of claim 4, wherein determining the target physical address of the target block according to the target logical address through an address mapping relationship comprises:
determining a target extent in the plurality of extents and an offset of the target block in the target extent relative to a starting block of the target extent according to the logical page number;
acquiring a first physical address of an initial block of the target extend through an address mapping relation according to the target extend;
and acquiring a target physical address of the target block according to the first physical address and the offset.
6. The method of claim 5, wherein the address mapping comprises a first level mapping and a second level mapping; the obtaining a first physical address of an initial block of the target extent according to the target extent through an address mapping relationship includes:
according to the target extensions, determining a target extension group to which the target extensions belong and a second-level mapping relation corresponding to the target extension group through the first-level mapping relation; the first-level mapping relation is used for indicating a plurality of extent groups and a second-level mapping relation corresponding to each extent group;
determining a first physical address of an initial block of the target extension according to the target extension and a second-level mapping relation corresponding to the target extension group; the second level mapping relation is used for indicating the physical address of the starting block of each extension in the target extension group.
7. The method of claim 5 or 6, wherein the plurality of extensions comprises a first extension and a second extension, the first extension being closer to a start block of the target segment than the second extension, the first extension being a free extension, the second extension being an occupied extension; the method further comprises the following steps:
and modifying the physical address of the starting block of the first extent into the physical address of the starting block of the second extent in the address mapping relation.
8. The method according to any of claims 1 to 7, wherein the storage space corresponding to each segment is used for storing a plurality of physical files.
9. The method according to any one of claims 1 to 8, wherein storage spaces corresponding to M extensions of the plurality of extensions are used for storing the target physical file, and the storage spaces corresponding to the M extensions have the same size.
10. The method of any of claims 1 to 9, wherein the data operations comprise at least one of the following types of operations: add operations, delete operations, modify operations, and query operations.
11. An operation request processing apparatus applied to a hard disk controller, the hard disk controller being configured to allocate a logical address to a storage space of a hard disk, wherein the logical address includes a target segment, the target segment is divided into a plurality of regions, each region is divided into a plurality of blocks, and the apparatus includes:
an obtaining module, configured to obtain a target operation request, where the target operation request includes a target logical address, and the target logical address is used to indicate a target block in the multiple blocks;
the determining module is used for determining a target physical address of the target block according to the target logical address through an address mapping relation;
and the data operation module is used for performing data operation on the storage space where the target physical address is located.
12. The apparatus of claim 11, wherein the target logical address comprises first indication information and second indication information, the first indication information indicating the target segment, the second indication information indicating a location of the target block in the target segment.
13. The apparatus of claim 12, wherein the first indication information comprises a relfilenode field.
14. The apparatus of claim 12 or 13, wherein the second indication information comprises a logical page number of the target block in the target segment.
15. The apparatus according to claim 14, wherein the determining module is specifically configured to determine, according to the logical page number, a target extent of the plurality of extents, and an offset of the target block from a starting block of the target extent in the target extent;
acquiring a first physical address of an initial block of the target extension through an address mapping relation according to the target extension;
and acquiring a target physical address of the target block according to the first physical address and the offset.
16. The apparatus of claim 15, wherein the address mapping comprises a first level mapping and a second level mapping; the determining module is specifically configured to determine, according to the target extent, a target extent group to which the target extent belongs and a second-level mapping relationship corresponding to the target extent group through the first-level mapping relationship; the first-level mapping relation is used for indicating a plurality of extension groups and a second-level mapping relation corresponding to each extension group;
according to the target extensions, determining a first physical address of an initial block of the target extensions through a second-level mapping relation corresponding to the target extension group; the second level mapping relation is used for indicating the physical address of the starting block of each extension in the target extension group.
17. The apparatus of claim 15 or 16, wherein the plurality of extensions comprises a first extension and a second extension, the first extension being closer to a start block of the target segment than the second extension, the first extension being a free extension, the second extension being an occupied extension; the device further comprises:
and the address modification module is used for modifying the physical address of the starting block of the first extent into the physical address of the starting block of the second extent in the address mapping relation.
18. The apparatus according to any one of claims 11 to 17, wherein the storage space corresponding to each segment is used for storing a plurality of physical files.
19. The apparatus according to any of the claims 11 to 18, wherein the storage spaces corresponding to M extensions of said plurality of extensions are used for storing the target physical file, and the size of the storage spaces corresponding to the M extensions is the same.
20. The apparatus of any of claims 11 to 19, wherein the data operations comprise at least one of the following types of operations: add operations, delete operations, modify operations, and query operations.
21. An operation request processing apparatus, characterized in that the apparatus comprises at least one processor, a memory and instructions stored on the memory and executable by the at least one processor, characterized in that the at least one processor executes the instructions to implement the steps of the method of any one of claims 1 to 10.
22. A computer-readable storage medium, characterized in that a computer program is stored which, when executed by a computer, carries out the method of any one of claims 1 to 10.
23. A computer program product comprising computer readable instructions which, when run on a computer, cause the computer to perform the method of any one of claims 1 to 10.
CN202110732615.3A 2021-06-29 2021-06-29 Operation request processing method and related device Pending CN115543992A (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202110732615.3A CN115543992A (en) 2021-06-29 2021-06-29 Operation request processing method and related device
PCT/CN2022/101768 WO2023274197A1 (en) 2021-06-29 2022-06-28 Operation request processing method and related device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110732615.3A CN115543992A (en) 2021-06-29 2021-06-29 Operation request processing method and related device

Publications (1)

Publication Number Publication Date
CN115543992A true CN115543992A (en) 2022-12-30

Family

ID=84690119

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110732615.3A Pending CN115543992A (en) 2021-06-29 2021-06-29 Operation request processing method and related device

Country Status (2)

Country Link
CN (1) CN115543992A (en)
WO (1) WO2023274197A1 (en)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10114829B1 (en) * 2015-06-26 2018-10-30 EMC IP Holding Company LLC Managing data cache for file system realized within a file
CN106326134B (en) * 2015-06-30 2019-10-01 华为技术有限公司 The method and device of FTL address of cache
CN106354431A (en) * 2016-08-26 2017-01-25 浪潮(北京)电子信息产业有限公司 Data storage method and device
CN111177252B (en) * 2019-11-26 2023-07-25 腾讯云计算(北京)有限责任公司 Service data processing method and device
CN112463077B (en) * 2020-12-16 2021-11-12 北京云宽志业网络技术有限公司 Data block processing method, device, equipment and storage medium

Also Published As

Publication number Publication date
WO2023274197A1 (en) 2023-01-05

Similar Documents

Publication Publication Date Title
CN103186350B (en) The moving method of mixing storage system and hot spot data block
CN107423422B (en) Spatial data distributed storage and search method and system based on grid
CN104346357B (en) The file access method and system of a kind of built-in terminal
US10331641B2 (en) Hash database configuration method and apparatus
CN105320775A (en) Data access method and apparatus
JP2015512604A (en) Cryptographic hash database
US20080155171A1 (en) File system, and method for storing and searching for file by the same
US10649967B2 (en) Memory object pool use in a distributed index and query system
CN110968269A (en) SCM and SSD-based key value storage system and read-write request processing method
Amur et al. Design of a write-optimized data store
JPH11154155A (en) File managing method
CN1255748C (en) Metadata hierarchy management method and system of storage virtualization system
CN116662019B (en) Request distribution method and device, storage medium and electronic device
CN116756253B (en) Data storage and query methods, devices, equipment and media of relational database
CN108804571B (en) Data storage method, device and equipment
CN103810114A (en) Method and device for distributing storage space
CN115543992A (en) Operation request processing method and related device
CN113326262B (en) Data processing method, device, equipment and medium based on key value database
RU2621628C1 (en) Way of the linked data storage arrangement
CN111427862B (en) Metadata management method for distributed file system in power grid dispatching control system
CN116737664B (en) Efficient index organization method of object-oriented embedded database
CN117725095B (en) Data storage and query method, device, equipment and medium for data set
CN115374127B (en) Data storage method and device
CN116595015B (en) Data processing method, device, equipment and storage medium
US8200920B2 (en) Systems and methods for storing and accessing data stored in a data array

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