An openGauss database space management and data layout method and device

Abstract

The application relates to an openGauss database space management and data layout method and device. The method comprises the following steps: storing a plurality of data objects in a database in a size class file and recording the page usage of the data objects by using metadata; adopting a progressive space expansion strategy, expanding a small page at the beginning, doubling the number of page expansions with the increase of data, and reaching a maximum expansion space threshold; returning the space applied by a deleted object to the corresponding size class, and updating the related markers for subsequent reuse. The method can maximally reduce the number of file objects, simplify management, improve the space allocation and recovery efficiency, significantly improve the database performance, and has a significant advantage for large-scale data storage and frequent operation scenarios.

Description

Technical Field

[0001] This application relates to the field of database operation technology, and in particular to an openGauss database space management and data layout method, apparatus and electronic device. Background Technology

[0002] openGauss uses a method called paged storage to manage data space, such as... Figure 1 As shown, each data object (table, index, sequence, temporary table, temporary space used for sorting, etc.) occupies a file. Each file is further divided into pages (hereinafter referred to as pages). Each page corresponds to a page number. For example, Page 0 corresponds to data offsets from 0 to 8191, Page 1 corresponds to data offsets from 8192 to 16383, and so on.

[0003] Page-based space management solutions have advantages such as simplicity of implementation and ease of addressing; however, this type of space management also has the following obvious drawbacks: (1) When using traditional page-based space management, as the data in the data table grows (especially with the creation of large partition tables), a large number of file objects will appear inside the database, and the number of file handles required by the database will increase exponentially, which can easily lead to problems such as too many open files.

[0004] (2) Using traditional page-based space management, each page expansion can only add 1 page (i.e. 8Kb). For scenarios with a large amount of data import, the page expansion speed is slow, which becomes a bottleneck for system performance.

[0005] (3) When using traditional page-based space management, temporary tables, temporary sorting spaces, etc. will frequently create, expand, and delete file objects, which can easily lead to a decline in database performance.

[0006] Furthermore, although new data file management methods are constantly being developed, such as the Chinese patent application "A Smart Card File System Management Method" (CN101593193A) which uses a DAT (Data Allocation Table) to manage the internal space of a smart card, this method still has many shortcomings. These include: low file management flexibility; dividing the file system into multiple fixed areas, with different data or files occupying discontinuous clusters, making it difficult to store multiple data objects in a single file; increased management complexity as the number of files increases; inconvenient space expansion using fixed-size clusters; low efficiency in space reclamation and utilization; high addressing complexity due to the need to look up the cluster occupied by the file in the DAT table; poor data read / write continuity due to files being stored in a chained manner in discontinuous clusters; and limited applicability and scalability.

[0007] To solve the above problems, we need a new space management and data layout solution. Summary of the Invention

[0008] To address the aforementioned problems of traditional page-based space management, this invention proposes a novel openGauss database space management and data layout method.

[0009] Figure 2 The diagram shows the overall architecture of this invention. This invention primarily employs the following technical strategies: (1) Data object co-storage strategy: Instead of using separate files for each data object in traditional page-based space management, different data objects are co-stored in a size class file, such as... Figure 2 As shown, object1 shares the size class file with other data objects. Metadata is used to accurately record the pages used by each data object in the size class file, enabling efficient storage and management of multiple data objects under a unified file. This effectively reduces the number of file objects generated and simplifies the file management structure.

[0010] (2) Progressive Space Expansion Strategy: To address the limitation of traditional page-based space management, which can only expand one page (8Kb) of space at a time, this solution adopts a progressive expansion approach. In the initial stage, smaller page units are expanded as needed. As the data volume increases, the number of pages expanded each time is dynamically increased. Specifically, every 8 expansions, the size class number is incremented by 1, and the number of pages contained in a class increases by a doubling rule. This achieves reasonable space expansion according to the data growth trend, reduces the overhead of frequent expansion operations, and improves system performance, especially in scenarios such as data import.

[0011] (3) Efficient space reclamation and reuse strategy: Unlike traditional page-based space management, which directly deletes the corresponding file and page space when deleting a table, this solution returns the allocated space to the system when deleting a table. Subsequent data objects can reuse this reclaimed space, optimizing the space allocation process, improving the space utilization efficiency of the database system, and further enhancing the overall performance of the database.

[0012] Specifically, this application provides the following technical solutions: A first aspect of this application provides a method for space management and data layout of an OpenGauss database, the method comprising: S1. Data Object Creation: Store various data objects (including tables, temporary tables, sequences, indexes, sorting spaces, etc.) within the database in the size class file, and use metadata to record the page usage of each data object in the size class file; S2. Space allocation and page expansion: Based on the size class usage of the data object, space expansion is carried out according to a progressive space expansion strategy. The number of pages expanded each time doubles as the size class number increases, until the preset expansion space threshold is reached. S3. Data object deletion: Return the space requested by the deleted object to the corresponding size class and update the relevant markers for subsequent reuse.

[0013] Furthermore, in the progressive space expansion strategy described in step S2 of this application, the sizeclass number is incremented by 1 every 8 expansions, and the page size of sizeclass(M) is expanded by 2 pages per expansion. M The expanded space size is 8Kb×2 M It also stipulates that the space can be expanded by a maximum of 64Mb at a time, that is, when M = 13, the space will no longer increase.

[0014] Furthermore, the method of this application also includes: setting an FSM page at the head of each size class to record the space usage of the current size class; when the page is expanded, it first searches for free space in the FSM and allocates it; if there is no free space in the FSM, it expands from the tail of the size class and updates the usage markers and the metadata page records corresponding to the objects in the FSM.

[0015] Furthermore, in the method of this application, each data object corresponds to a metadata page, which is used to store all the class spaces requested by the data object. It can store up to 227 SizeClassBMS, that is, a data object can use up to 227 size classes and up to 100G of space.

[0016] Furthermore, the formula for calculating the physical location of the class space in the method of this application is as follows: pageNo = 10 + P + (x–total_size_class(M - 1))% 2 M Formula explanation: pageNo is the physical location of page(x); 10 is a fixed value because the size class always starts with 10 pages for FSM management; x is the logical number of the page; total_size_class(M - 1) represents the total number of pages allocated to all size classes up to M.

[0017] Furthermore, the specific process for creating the data object in step S1 of this application is as follows: Search for unused pages in the metadata header. If no free pages are found, expand the metadata with new pages from the end. Initialize the metadata page of the newly created data object, recording the data space used by the object. The size class of the newly created data object is initially empty.

[0018] Furthermore, the specific process of space allocation and page expansion described in step S2 of this application is as follows: In the metadata page, query the size class usage of the object to determine the initial size class for expansion; Based on the number of times N the current object is expanded in size class(M), if N is less than 8, then the next time the space class(N+1) is expanded in size class(M); if N equals 8, then the next time the space class(1) is expanded in size class(M+1). The page size expanded by size class(M) is 2. M The page is expanded according to the rules until the preset expansion space threshold is reached.

[0019] Furthermore, the specific process for deleting the data object in step S3 of this application is as follows: Read the metadata page, return all class space requested by the current object to the corresponding size class, and mark the class space as free in the FSM corresponding to the size class; The metadata page is returned to the metadata page, and the metadata page corresponding to the deleted object is marked as idle in the header page.

[0020] Furthermore, in the method of this application, (1) The specific steps of the page application process are as follows: Read the metadata page of this object; Calculate the size class of the page that the object needs to apply for based on the metadata; Find the FSM corresponding to the size class, request an available class space, and set the corresponding bit in the FSM to 1 to indicate that it is in use. At this time, multiplying the bit by 8 gives the class space address. Record the location of the class in the metadata; (2) The specific steps of the page addressing process are as follows: Read the metadata page of this object; Get the class space address; Based on pageNo = 10 + P + (x – total_size_class(M - 1)) % 2 M The formula calculates the physical location of the page, and the page content is retrieved from that location; (3) The specific steps for deleting the corresponding page and returning the result are as follows: Read the metadata page of this object; Iterate through all class space addresses requested by all objects, divide the class space address by 8 to get the FSM bit, and set the bit to 0 to indicate that the class is free; Return the metadata page to the metadata file.

[0021] A second aspect of this application provides an openGauss database space management and data layout apparatus, the apparatus comprising: Data object creation module: used to store multiple data objects from within the database in a size class file, and to use metadata to record the page usage of each data object in the size class file; Space application and page expansion module: It is used to expand space according to the size class usage of data objects and follow a progressive space expansion strategy. The number of pages expanded each time doubles as the size class number increases until the preset expansion space threshold is reached. Data object deletion module: used to return the space requested by the deleted object to the corresponding size class and update the relevant tags for subsequent reuse.

[0022] The device implements the steps of the aforementioned openGauss database space management and data layout method during operation.

[0023] A third aspect of this application provides an electronic device, including: a memory and a processor; Memory: Used to store computer programs; Processor: Used to execute the computer program to implement the steps of the aforementioned openGauss database space management and data layout method.

[0024] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the aforementioned openGauss database space management and data layout method.

[0025] In summary, the present invention has the following technical advantages: (1) Integrated storage: By designing a unique space management and data layout scheme, multiple data objects can be stored in one file, including tables, indexes, sequences, temporary files, etc. This effectively avoids the problem of generating a large number of file objects due to the separate storage of each data object in the traditional scheme, simplifies the file management structure, and improves storage efficiency.

[0026] (2) Gradual expansion: Abandoning the traditional model of expanding only one page at a time, a gradual expansion strategy is adopted. In the initial stage, smaller page units are expanded as needed. As the data volume grows, the number of pages expanded each time is gradually increased, realizing dynamic expansion of space according to the data growth trend, reducing frequent expansion operations, and significantly improving performance in scenarios such as data import.

[0027] (3) Efficient space reclamation and reuse: After table deletion, temporary table cleanup and sorting are completed, the generated free space can be reclaimed in a timely and efficient manner. In addition, when the table is created and sorting begins, space can be requested from the free space and reused first, which optimizes the space allocation process and greatly improves the space utilization efficiency and overall performance of the database system.

[0028] Other features and advantages of the present invention will be set forth in detail in the following description, or may be learned by practicing the relevant technical solutions of this application. The objectives and other advantages of this application can be achieved by the technical features and means clearly pointed out in the description, claims and drawings, and obtained through the implementation of these technical contents. Attached Figure Description

[0029] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings involved in the description of the embodiments will be briefly introduced below. It should be noted that the accompanying drawings only show some embodiments of this application. For those skilled in the art, other related drawings can be derived from these drawings without creative effort.

[0030] Figure 1 Architecture diagram for traditional page-based space management.

[0031] Figure 2This is a diagram of the overall design architecture of the present invention.

[0032] Figure 3 This is a flowchart illustrating the overall implementation of the openGauss database space management and data layout method of the present invention.

[0033] Figure 4 An example diagram is created for the data objects in the method of this invention.

[0034] Figure 5 This is an example diagram illustrating space allocation and page expansion in the method of the present invention.

[0035] Figure 6 This is a structural diagram of the device of the present invention.

[0036] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be noted that the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the protection scope of this application.

[0038] In this document, the term "comprising" and any variations thereof (such as "including," "including," etc.) are open-ended expressions and should be understood as "including but not limited to," meaning that the listed content is not exhaustive and may include other content not explicitly mentioned. The term "based on" should be understood as "at least partially based on," meaning that the basis or condition referred to may not be the only factor and may involve other relevant factors. The term "one embodiment" should be understood as "at least one embodiment," meaning that the described embodiment is not the only possible implementation, and other similar embodiments may exist.

[0039] In this application, the terms "a" and "a plurality of" are used to modify related elements or features, and their expression is illustrative rather than restrictive. Unless otherwise expressly stated in the context, "a" should be understood as "at least one," and "a plurality of" should be understood as "at least two." Those skilled in the art should reasonably interpret these terms based on the semantic and logical relationships of the context to ensure that they cover the possibility of "one or more."

[0040] Figure 3 The diagram shows the overall implementation flow of the openGauss database space management and data layout method provided in this application, including the following steps: S1. Data Object Creation: Store various data objects (including tables, temporary tables, sequences, indexes, sorting spaces, etc.) within the database in the size class file, and use metadata to record the page usage of each data object in the size class file; S2. Space allocation and page expansion: Based on the size class usage of the data object, space expansion is carried out according to a progressive space expansion strategy. The number of pages expanded each time doubles as the size class number increases, until the preset expansion space threshold is reached. S3. Data object deletion: Return the space requested by the deleted object to the corresponding size class and update the relevant markers for subsequent reuse.

[0041] To more clearly illustrate the technical solution of this application, the following will provide further explanation through specific scenario embodiments.

[0042] The specific implementation process of the method of the present invention is as follows: (a) Data object creation Data objects refer to various objects within a database that require space to store data, including tables, temporary tables, sequences, indexes, and sorting spaces. For example... Figure 4 As shown, the process for creating the data object object1 is as follows: 1. Find an unused page in the metadata header. If there is no free page, start a new page from the end of the metadata to store it.

[0043] 2. Initialize the object1 metadata page; object1 will be used to record which data spaces this object uses. The newly created data object has an empty size and class; see [link / reference]. Figure 4 .

[0044] (ii) Space application and page expansion like Figure 5 As shown, the data object1 requests new storage space (also known as page expansion), and the process is as follows: 1. In the metadata page, query the size class usage of the object. The newly created table `sizeclass(0)` begins to expand. Every 8 expansions, the size class number increments by 1. That is, `size class(0)` expands 8 times, then `size class(1)` expands 8 times, then `size class(2)` expands 8 times, and so on. See... Figure 5The current object has been expanded N times in size class(M). If N is less than 8, the next expansion will be in size class(M) in space class(N+1). If N is equal to 8, the next expansion will be in size class(M+1) in space class(1).

[0045] This solution specifies that the page size for each expansion of size class(M) is 2. M The expanded space size is 8Kb×2 M As the data volume increases, the number of expanded pages grows exponentially, thus avoiding frequent page expansion. Simultaneously, to avoid allocating too much space at once, this scheme specifies a maximum expansion of 64Mb at a time; that is, when M=13, the expansion space will not increase further. The table below shows the relationship between M, the number of expanded pages, and the size of the expansion space:

[0046] (iii) Each size class has an FSM (free space map) page at the beginning, which records the space usage of the current size class. When the page expands, it first searches for free space in the FSM. If there is no free space, it expands from the end of the size class. Then, the newly allocated class is marked as used in the FSM, and the space of this newly allocated class is recorded in the metadata page (object1 page) of the object.

[0047] (iv) Deletion of data objects The deletion process is as follows: 1. Read the metadata page, return all class space requested by the current object to the corresponding size class, and mark the class space as free in the FSM corresponding to the size class. This class space can be reassigned to other data objects for reuse later.

[0048] 2. Return the metadata page to metadata. Mark the metadata page corresponding to the deleted object as idle in the header page so that it can be reassigned to other objects later.

[0049] The following examples illustrate the specific implementation process of page return when requesting, addressing, or deleting objects under this solution architecture.

[0050] (a) FSM free space management Each size class header contains a fixed-size FSM page used to mark whether a class space has been allocated to an object file. When a class needs to be allocated, the FSM first searches for free space. If there is free space, it is allocated directly from the FSM. If there is no free space in the FSM, a new class space is allocated from the end of the size class, and the newly allocated class space is marked as being in use in the FSM.

[0051] The FSM occupies 10 pages, with a total size of 80KB. Internally, the FSM uses a bitmap structure, where 1 bit represents whether class(N) is free. The FSM can mark a maximum of 655360 classes (8 * 80KB). Since this scheme specifies that a sizeclass can be expanded a maximum of 8 times, the maximum number of objects that a sizeclass can allocate is calculated to be: 655360 / 8 = 81920. This means that this scheme limits the creation of a maximum of 81920 data objects per database, which is sufficient for most production environments.

[0052] In addition, the method for managing free space in metadata is the same as that in FSM.

[0053] (ii) Object metadata page and class space storage Each data object has a corresponding metadata page that stores all the class spaces allocated for that object. The structure of the object metadata page is shown in the following code:

[0054] 1. Use a 32-bit unsigned integer to identify the address of the class, see the bms member of SizeClassBMS.

[0055] 2. According to the page expansion rules, a size class can be allocated a maximum of 8 class spaces.

[0056] 3. To store the ObjectHeadPage structure within a single page (i.e., limiting its size to no more than 8KB), this structure can hold a maximum of 227 SizeClassBMS, meaning a single data object can use a maximum of 227 size classes. Based on page expansion rules, it can be calculated that a single data object can use up to 100GB of space, which should meet the needs of most production environments.

[0057] (iii) Obtaining the location of the class space Traditional page-based space management uses a dedicated data file for each data object. The page addressing scheme is relatively straightforward; to obtain the data for page(x), the offset of the page within the physical file is 8 * 8KB. This scheme, however, requires multiple files to share a size class file. Therefore, it needs to obtain the size class and class space location of the page through the size class information recorded in the metadata page.

[0058] Since the size and number of times class space is allocated for each size class are fixed, as shown in the table below, we can calculate how many pages are allocated for an object when it is expanded to size class (M):

[0059] Taking page(50) as an example, according to the table above, the size class of page(50) is 2, that is, M=2.

[0060] Since size class(2) requests 2 pages each time... 2 =4, then the class number of page(50) is: N = 50 % ×4 = 2.

[0061] Therefore, the class space address = ObjectHeadPage.classes[M].bms[N].

[0062] (iv) Mapping from class address to file physical location In the aforementioned scheme, we calculated the class address (denoted as P). In this section, we use the class address to obtain the physical page number where page(x) is located. The calculation formula is as follows: pageNo = 10 + P + (x–total_size_class(M - 1))% 2 M Formula explanation: 10 is a fixed value because the size class starts with a fixed distribution of 10 pages for FSM management.

[0063] x is the logical number of the page, and the physical number of the page is calculated using a formula.

[0064] `total_size_class(M - 1)` represents the total number of pages allocated across all size classes preceding M. Specifically, when M is 0, `total_size_class(M - 1)` is 0, indicating that no pages are allocated before size class (0).

[0065] The current size class allocates 2 at a time M Pages, divided by 2 M Take the remainder to get the relative position of the physical page corresponding to x within the current class.

[0066] Finally, the physical location of page(x) is: pageNo * 8Kb. By reading the offset, the content of page x can be determined.

[0067] (v) Implementation steps of each process 1. Application process on the webpage: Read the object's metadata page; Calculate the size class of the page that the object needs to apply for based on the metadata; Find the FSM of the size class, request an available class space, set the corresponding bit in the FSM to 1 to indicate that it is in use, and multiply the bit by 8 to get the class space address; Record the location of the class in the metadata.

[0068] 2. Page addressing process: Read the object's metadata page; The class space address is obtained using the aforementioned method; The physical location of the page can be determined using the aforementioned method, and the page content can be obtained by reading that location.

[0069] 3. Deleting the corresponding page and returning the process: Read the object's metadata page; Iterate through all class space addresses allocated by all objects. The class space address divided by 8 is the FSM bit. Setting the bit to 0 indicates that the class is free. The metadata page returns the metadata file in the same way.

[0070] Figure 6 The diagram shows an openGauss database space management and data layout apparatus according to this application. The apparatus includes: Data object creation module: used to store multiple data objects from within the database in a size class file, and to use metadata to record the page usage of each data object in the size class file; Space application and page expansion module: It is used to expand space according to the size class usage of data objects and follow a progressive space expansion strategy. The number of pages expanded each time doubles as the size class number increases until the preset expansion space threshold is reached. Data object deletion module: used to return the space requested by the deleted object to the corresponding size class and update the relevant tags for subsequent reuse.

[0071] When the above-mentioned device is in operation, it implements the steps of the openGauss database space management and data layout method disclosed in this application.

[0072] The flowcharts and block diagrams in the accompanying drawings illustrate possible implementations of apparatus, methods, and computer program products according to various embodiments of this application, including architecture, functionality, and operation. In these figures, each block may represent a module, program segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should be noted that each block in the block diagrams and / or flowcharts, and combinations thereof, can be implemented using either a dedicated hardware-based system or a combination of dedicated hardware and computer instructions to achieve the specified function or operation.

[0073] like Figure 7 As shown, embodiments of this application also disclose an electronic device, including: a processor 310, a communication interface 320, a memory 330 for storing a processor-executable computer program, and a communication bus 340. The processor 310, communication interface 320, and memory 330 communicate with each other via the communication bus 340. The processor 310 executes the executable computer program to implement the steps of the aforementioned openGauss database space management and data layout method.

[0074] It is understood that, in addition to memory and a processor, this electronic device may also include input devices (such as a keyboard), output devices (such as a display), and other communication modules. These input devices, output devices, and other communication modules all communicate with the processor through I / O interfaces (i.e., input / output interfaces).

[0075] The operations described in this application can be implemented by writing computer program code using one or more programming languages ​​or a combination thereof. The programming languages ​​include, but are not limited to, the following types: Object-oriented programming languages, such as Java, Smalltalk, C++, etc. Conventional procedural programming languages, such as "C" or similar programming languages.

[0076] The execution methods of program code include, but are not limited to: It runs entirely on the user's computer; Part of it executes on the user's computer, and part of it executes on a remote computer; Execute as a standalone software package; It is executed entirely on a remote computer or server.

[0077] In scenarios involving remote computers, the remote computer can connect to the user's computer via any type of network, including but not limited to local area networks (LANs) or wide area networks (WANs). Furthermore, the remote computer can also connect to external computers through an internet service provider, for example, by utilizing the internet for connection.

[0078] Furthermore, this application also discloses a computer-readable storage medium, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform the various steps of the openGauss database space management and data layout method disclosed in this application.

[0079] In the context of this application, a computer-readable storage medium refers to a tangible medium capable of storing computer program code and related data. Specific examples include, but are not limited to, the following: (1) Portable computer disk: such as floppy disks and other removable magnetic storage media.

[0080] (2) Hard disk: including mechanical hard disks and solid-state hard disks and other fixed storage devices.

[0081] (3) Random Access Memory (RAM): A volatile storage medium used for temporary storage of data and program code.

[0082] (4) Read-only memory (ROM): a non-volatile storage medium used to store fixed programs and data.

[0083] (5) Erasable programmable read-only memory (EPROM) or flash memory: non-volatile storage media that supports multiple erasures and reprogrammings.

[0084] (6) Fiber optic storage devices: storage media based on fiber optic technology.

[0085] (7) Portable compact disc read-only memory (CD-ROM): a read-only medium that stores data in the form of an optical disc.

[0086] (8) Optical storage devices: such as DVDs, Blu-ray discs and other storage media based on optical principles.

[0087] (9) Magnetic storage devices: such as magnetic tapes, disks and other storage media based on magnetic principles.

[0088] (10) Any suitable combination of the above: for example, combining multiple storage media to meet different storage needs.

[0089] These computer-readable storage media can be used to store the program code and related data described in this application to support program execution and persistent data storage.

[0090] Specifically, according to embodiments of this application, the processes described in the flowcharts can be implemented as computer software programs. For example, embodiments of this application relate to a computer program product comprising a computer program carried on a non-transitory computer-readable medium. This computer program includes program code for executing the openGauss database space management and data layout methods disclosed in this application. When the computer program is executed by a processing device, it can achieve the functions defined in the embodiments of this application.

[0091] While the foregoing discussion contains several specific implementation details, these details should not be construed as limiting the scope of this application. The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this application is not limited to technical solutions formed by specific combinations of the above-described technical features. Furthermore, this application should also cover other technical solutions formed by any combination of the above-described technical features or their equivalents without departing from the foregoing disclosed concept.

[0092] Those skilled in the art should also understand that modifications can be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features, without departing from the spirit and scope of the technical solutions of the embodiments of this application. These modifications or substitutions will not cause the essence of the corresponding technical solutions to deviate from the core spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for space management and data layout in an OpenGauss database, characterized in that, The method includes: S0. Set an FSM page at the beginning of each size class to record the space usage of the current size class. When the page expands, first look for free space in the FSM and allocate it. If there is no free space in the FSM, expand from the end of the size class and update the usage flags and the corresponding metadata page records in the FSM. S1. Data Object Creation: Multiple data objects from within the database are stored together in a size class file, and metadata is used to record the page usage of each data object within the size class file. Specifically, this includes: Search for unused pages in the metadata header. If no free pages are found, expand the metadata with new pages from the end. Initialize the metadata page of the newly created data object to record the data space used by the object. The sizeclass of the newly created data object is initially empty. S2. Space Allocation and Page Expansion: Based on the size class usage of the data objects, space expansion is performed according to a progressive space expansion strategy. The number of pages expanded each time doubles as the size class number increases, until a preset expansion space threshold is reached. Specifically, this includes: In the metadata page, query the size class usage of the object to determine the initial size class to be extended; M is the size class number, and the initial value of M is 0 when a new data object is created; Based on the number of times N the current object is expanded in size class(M), if N is less than 8, then the next time the space class(N+1) is expanded in size class(M); if N equals 8, then the next time the space class(1) is expanded in size class(M+1). The page size expanded by size class(M) is 2. M The page is expanded according to the rules until the preset expansion space threshold is reached; S3. Data Object Deletion: Return the space allocated by the deleted object to the corresponding size class and update the relevant markers for future reuse. Specifically, this includes: Read the metadata page, return all class space requested by the current object to the corresponding size class, and mark the class space as free in the FSM corresponding to the size class; The metadata page is returned to the metadata page, and the metadata page corresponding to the deleted object is marked as idle in the header page.

2. The method according to claim 1, characterized in that, In the progressive space expansion strategy described in step S2, the size class number is incremented by 1 every 8 expansions, and the page size of size class (M) is 2 per expansion. M The expanded space size is 8Kb×2 M It also stipulates that the space can be expanded by a maximum of 64Mb at a time, that is, when M = 13, the space will no longer increase.

3. The method according to claim 1, characterized in that, In the method, each data object corresponds to a metadata page, which is used to store all the class spaces requested by the data object. It can store up to 227 SizeClassBMS, that is, a data object can use up to 227 size classes and up to 100G of space.

4. The method according to claim 1, characterized in that, The formula for calculating the physical location of the class space in the method is as follows: ； Formula explanation: pageNo is the physical location of page(x); P is the address of the class space; 10 is a fixed value because the size class always starts with 10 pages for FSM management; x is the logical number of the page; total_size_class(M - 1) represents the total number of pages allocated to all size classes up to M.

5. The method according to claim 1, characterized in that, In the method, (1) The specific steps of the page application process are as follows: Read the metadata page of this object; Calculate the size class of the page that the object needs to apply for based on the metadata; Find the FSM corresponding to the size class, request an available class space, and set the corresponding bit in the FSM to 1 to indicate that it is in use. At this time, multiplying the bit by 8 gives the class space address. Record the location of the class in the metadata; (2) The specific steps of the page addressing process are as follows: Read the metadata page of this object; Let P be the address of the class space. according to The formula calculates the physical location of the page, and the page content is retrieved from that location; (3) The specific steps for deleting the corresponding page and returning the result are as follows: Read the metadata page of this object; Iterate through all class space addresses requested by all objects, divide the class space address by 8 to get the FSM bit, and set the bit to 0 to indicate that the class is free; Return the metadata page to the metadata file.

6. An openGauss database space management and data layout device, characterized in that, The apparatus, when operating, implements the steps of the openGauss database space management and data layout method as described in any one of claims 1 to 5, the apparatus comprising: Data object creation module: used to store multiple data objects from within the database in a size class file, and to use metadata to record the page usage of each data object in the size class file; Space application and page expansion module: It is used to expand space according to the size class usage of data objects and follow a progressive space expansion strategy. The number of pages expanded each time doubles as the size class number increases until the preset expansion space threshold is reached. Data object deletion module: used to return the space requested by the deleted object to the corresponding size class and update the relevant tags for subsequent reuse.

Images