WO2017101478A1

WO2017101478A1 - Postgresql block storage device read-write module

Info

Publication number: WO2017101478A1
Application number: PCT/CN2016/095367
Authority: WO
Inventors: 朱晓伟
Original assignee: 深圳市华讯方舟软件技术有限公司; 华讯方舟科技有限公司
Priority date: 2015-12-17
Filing date: 2016-08-15
Publication date: 2017-06-22
Also published as: CN105630879A; CN105630879B

Abstract

A PostgreSQL block storage device read-write module, the PostgreSQL block storage device read-write module being a PostgreSQL block storage device read-write module that manages PostgreSQL blocks in a PostgreSQL block storage device, and the PostgreSQL block storage device read-write module being constructed on a PostgreSQL database system. The PostgreSQL block storage device read-write module manages, by means of a idle PostgreSQL block table and a table of mapping relationships between PostgreSQL blocks and data tables, the PostgreSQL blocks in the PostgreSQL block storage device. The PostgreSQL block storage device read-write module will perform more secure data reading and writing operations to the database. The data in the database will be saved into the block device according to an established rule, such that the data is more secure in terms of security. Moreover, due to the use of distributed storage, the data can be saved in slices and multiple copies thereof are saved in different data nodes, and thus the security is more than a hundred times higher than that of a single disk.

Description

A PostgreSQL block storage device read/write module

Technical field

The invention relates to a PostgreSQL database storage device, in particular to a PostgreSQL block storage device read/write module.

Background technique

With the development of the Internet, the mobile Internet and the Internet of Things, we are ushered in an era of massive data, and the data stored in the database is increasing, and the query time we need is getting smaller and smaller. Many application scenarios today require background storage with high concurrency, high capacity, and high response. High-speed inbound demand forces us to abandon real-time indexing, and large data volumes are limited by I/O on the storage side. In today's PostgreSQL database system, high-concurrency multi-database scanning needs to be basically random read, while at the same time, the throughput of ordinary disks can no longer meet the demand.

In order to adapt to the application scenario of large data volume, the officially launched PostgreSQL-XC and PostgreSQL-XL two MPP databases are not mature yet, and there are still many security problems. The traditional speed-up solution only uses the high I/O (input/output) of centralized storage to improve the whole system to some extent. But this kind of improvement still has a lot of waste of resources.

As shown in Figure 1, the original PostgreSQL database system's underlying storage architecture is on the file system. From the table to the disk, the four layers of the tablespace, file system, logical volume, and disk are finally written to the physical disk.

Such an architecture will first cause the I/O of the disk to form attenuate. The final disk I/O utilization can only reach about 80% or even lower. Secondly, when there are a large number of small tables in the database table, it will inevitably increase the pressure on the file system. Moreover, for database operations, the write and read of the table are relatively random, which is very likely to cause disk fragmentation, and a large number of random reads and writes will also make the read and write performance of the entire data degrade. For small data volumes, the existing shortcomings may not be obvious. But now more usage scenarios are big data volumes, high concurrency, and high I/O. These shortcomings will greatly affect database performance in these usage scenarios. In addition, very complex database migration operations are required in different operating system migrations.

Ordinary disks have low I/O speeds, and the traditional solution is to use centralized storage (that is, disk arrays). This method is simply to increase the I/O speed of the disk, and the cost is extremely high, which has certain limitations.

As shown in Figure 2 and Figure 3, the existing backend storage architecture of the PostgreSQL database system:

The data manipulation of the database has several primary identifiers for each record. Table ID, the black id of the record, the file type, and the identifier corresponding to the row record. Existing PostgreSQL database system read and write table operations need to:

a Find the tablespace of this table based on the table ID, and then locate the location of the tablespace in the file system.

bAcquire the specified table file according to the file type. Usually a table will contain 3 types of files.

Fsm file: It stores information about the free space in the data table file.

Vm file: A tuple that marks which file blocks in the data table file are not invalid.

Table data file: This file is mainly used to store data, but the file size will be limited. Normally, 2G will be saved. Files larger than 2G will be saved in files.

c Position the page based on the record number and the fsm file.

The general operating system has a limit on the number of files that can be opened. The PostgreSQL database system internally uses its own virtual file management to manage file handles to ensure that many tables can be opened at the same time. For the database, there may be many tables at the same time, and the PostgreSQL database system uses one table and multiple files to save data. When you open a file, you will first find in the file handle management whether there is a file handle that has been opened. Set the offset according to the file handle.

d Take the corresponding page from the file and take the corresponding row.

Locate the file according to the recorded blockid and read the block of the specified size. These records are saved in the page.

In the prior art, centralized storage is employed as the database backend.

1. Use centralized storage (disk array, etc.) as the storage backend. Mount the disk provided by the centralized storage to the machine installed on the PostgreSQL database system. And formatted into different file systems according to different operating systems.

2. Assign the data in the database to the disk provided by the centralized storage.

This method only hardly improves the I/O throughput of the back end, and does not improve the utilization of the underlying I/O in principle. And in terms of security, this method does not protect the data at any level, and still exposes the data. It can only achieve the speedup of the database system to a certain extent. But for the high security and high performance requirements, we can't just rely on this pure hardware acceleration and ignore the optimization of the software itself.

The above is the original PostgreSQL database system storage architecture. The above structure has the following disadvantages:

First, the database data files are directly exposed in the operating system, the data has security risks, and the data security is not guaranteed. It is a great security vulnerability for some environments with high security requirements.

Second, the use of the disk must pass through the file system layer.

For the more popular file system under Linux system, 64-bit space is used to record the number of blocks and the number of i-nodes. For database systems, there may be a large number of tables, and each table may have at least 3 files. , resulting in a lot of files in a folder.

When the file system performs block allocation, it is basically allocated in a 4K block mode. At the same time, our database application is applied in 8K units. This means that the blocks allocated by the system are always smaller than the blocks of our table. The direct problem with this is that the database's business blocks are cluttered to disk. The direct problem is that the disk seek time is long and the read and write speed is slowed down.

If there is a huge table in our database, the file system is extremely inefficient at processing. For example, a 100MB file in an ext3 file system would require nearly 25,600 data blocks. For the PostgreSQL database system, table processing that meets or exceeds the GB level is common and is random read and write.

Third, the expansion of the file system is also very troublesome. In addition to the very few known commercial file systems, other file system expansions will require a shutdown of the database.

Fourth, the database is migrated between different systems and its complexity, and the professional knowledge of the operators is relatively high.

Summary of the invention

The technical problem to be solved by the present invention is to provide a PostgreSQL block storage device read/write module, through which the read and write modules of the PostgreSQL block storage device read and write, the database data file does not Direct exposure to the operating system eliminates the security risks of data, and data security is guaranteed. It eliminates a huge security hole for some environments with high security requirements.

In order to solve the above technical problem, the PostgreSQL block storage device read/write module of the present invention is a PostgreSQL block storage device read/write module for managing a PostgreSQL block in a PostgreSQL block storage device, and the PostgreSQL block storage device read/write module is architected in a PostgreSQL database. On the system.

The PostgreSQL block storage device read/write module manages PostgreSQL blocks in the PostgreSQL block storage device through a mapping relationship table between PostgreSQL block-data tables and an idle PostgreSQL block table.

The mapping relationship table between the PostgreSQL block and the data table includes fields Relfilenode, Reltablespace, Forknum, Blockid, Blockno, and the free PostgreSQL block table includes fields Blockid, Isfree, Dev.

The PostgreSQL block storage device read and write module has the following submodules:

Allocating submodules of the PostgreSQL block,

Reclaim the submodules of the PostgreSQL block,

Locate the submodule of the PostgreSQL block,

Read the submodule of the data in the PostgreSQL block,

A submodule that writes data in a PostgreSQL block.

The sub-module that allocates the PostgreSQL block allocates a PostgreSQL block to the PostgreSQL data table by using a nearby allocation policy or a hot-hot data hierarchical allocation policy, and the nearby allocation strategy is a PostgreSQL block nearest allocation policy or an idle PostgreSQL block table recording nearest allocation policy. The hot-cold data table hierarchical allocation strategy is a common data table allocation strategy or a recently used data table allocation strategy. The PostgreSQL block nearest allocation strategy is to find an idle PostgreSQL block to be assigned to the data table before and after the last allocated PostgreSQL block of the data table. The free PostgreSQL block table record near allocation strategy is to find the first free PostgreSQL block from the idle PostgreSQL block table record, the commonly used data table allocation strategy is to preferentially allocate the data table to the faster PostgreSQL block device. The recently used data table allocation strategy is to prioritize the recently used data table to a faster PostgreSQL block device for a PostgreSQL block device having two or more different read and write speeds. Upper

The submodule of the Recycled PostgreSQL block is used to reclaim the PostgreSQL block that is no longer used by the data table, and the corresponding PostgreSQL block record is deleted from the mapping relationship table between the PostgreSQL block and the data table, and the record of the corresponding PostgreSQL block is sent to the free table. Set to idle;

The sub-module for locating the PostgreSQL block is used to locate a page in the data table to a location specified by the PostgreSQL block device;

The submodule for reading data in the PostgreSQL block is used to read data of a specified size in a specified position in the specified block;

The sub-module that writes the data in the PostgreSQL block is used to write data of a specified size within a specified location within the specified block.

The submodule that writes the data in the PostgreSQL block writes the data to the PostgreSQL block in an encrypted manner; accordingly,

The sub-module that reads the data in the PostgreSQL block reads the data back to the database business layer in a decrypted manner.

The encryption method is a method of performing storage encryption on the user password and data XOR;

The decryption method is a method of encrypting the user password with the data read from the PostgreSQL block and then returning it to the database service layer.

The Dev field in the idle PostgreSQL block table identifies different storage devices to implement capacity expansion.

Copying the mapping relationship table between the PostgreSQL block-data table and the free PostgreSQL block table from the original library to the new library, and migrating the PostgreSQL block storage device from the computer where the original library is located to the computer where the new library is located.

The PostgreSQL block is a minimum unit allocated to a data table in a PostgreSQL database system, the storage capacity of the PostgreSQL block is greater than 4 KB, and the PostgreSQL block storage device read/write module is configured by a data read/write method based on a PostgreSQL block storage device. PostgreSQL blocks are read and written.

The storage capacity of the PostgreSQL block is a positive integer multiple of 8 KB.

The storage capacity of the PostgreSQL block is a natural multiple of 8 KB of 2 KB.

The storage capacity of the PostgreSQL block is 1 MB, 2 MB, 4 MB, 8 MB, 16 MB, 32 MB, 64 MB, 128 MB, 256 MB, 512 MB or 1024 MB.

A data read/write method based on a PostgreSQL block storage device, which reads and writes a PostgreSQL block as described above by using a PostgreSQL block storage device read/write module as described above.

A. In the database background driver layer, the driver of the PostgreSQL block storage device read/write module completes the operation of the block file, and its main tasks are:

a, through the file handle manager to manage the upper and lower services read and write interfaces of the underlying device, to achieve a high concurrent read and write interface;

b. Implementing overwrite writing to the PostgreSQL block storage device, directly positioning to a specified location of the PostgreSQL block storage device, and writing data of a specified length;

B. According to the mapping relationship table oid between the PostgreSQL block and the data table, the table space is located to a specified position of the specified block device, and a certain offset of the block device is located by the pageid of the table.

Each table in the PostgreSQL database system is assigned at least one of the PostgreSQL blocks, and the PostgreSQL block can be dynamically allocated incrementally;

Each PostgreSQL block can write to 512 8-KB PostgreSQL block database system pages. A block device can contain an infinite number of tables. A table can contain an unlimited number of PostgreSQL blocks. These block file information is stored in PostgreSQL block-data. The mapping relationship between the tables;

The information of all the PostgreSQL blocks of a data table can be obtained by one oid, and the PostgreSQL block information will sequentially form the entire PostgreSQL block-data table file. The pageid*8k of this table is the internal bias of the table. Move, and at the same time be able to determine the first block of this block file, and thus get the position of the page we want to get in the block device.

The PostgreSQL block device read/write storage module of the present invention has the following advantageous effects compared with the prior art.

1) The data in the database will be more secure. The data in the database will be saved to the block device according to the rules we have established, which is more secure in terms of security. Moreover, due to the use of distributed storage, the data will be saved in pieces and saved in multiple copies to different data nodes, which is more than 100 times more secure than a single disk.

2) The query speed and read/write speed can be greatly improved, and the speed can be increased by 10% to 20% under the same back-end storage. This improvement is very impressive for the database.

3) Database business and data separation. As long as it is the same version of the database, it can be freely migrated in different operating systems. As long as you can pass the verification code set at the head of the data block, Can achieve direct mount of the database. It is free to migrate from different versions of Linux, and can also migrate with the Windows operating system platform.

4) The database is migrated between different systems and is simple, and the requirements of the operator's professional knowledge are not high.

DRAWINGS

The PostgreSQL block, the PostgreSQL block device read and write storage module, and the data read and write method based on the PostgreSQL block storage device of the present invention are further described in detail below with reference to the accompanying drawings and specific embodiments.

FIG. 1 is a schematic diagram of a file system read and write hierarchical structure of an operating system in the prior art.

2 is a schematic diagram of a file system storage space allocation structure of an operating system in the prior art.

FIG. 3 is a schematic diagram of the principle of read and write of a file system head of an operating system in the prior art.

4 is a schematic diagram showing the structure and principle of a PostgreSQL block, a PostgreSQL block device read/write memory module, and a data read/write method based on a PostgreSQL block storage device.

detailed description

Embodiment 1:

As shown in FIG. 4, the PostgreSQL block of the present invention is the smallest unit allocated to the data table in the PostgreSQL database system, and the storage capacity of the PostgreSQL block is equal to 4 MB.

Of course, it is also possible that the storage capacity of the PostgreSQL block is greater than 4 KB.

It is also possible that the storage capacity of the PostgreSQL block is a positive integer multiple of 8 KB.

Alternatively, the storage capacity of the PostgreSQL block is a natural multiple of 8 KB of 2 KB.

More preferably, the storage capacity of the PostgreSQL block is 1 MB, 2 MB, 8 MB, 16 MB, 32 MB, 64 MB, 128 MB, 256 MB, 512 MB or 1024 MB.

Embodiment 2:

As shown in FIG. 4, the PostgreSQL block storage device read/write module of the present invention is a PostgreSQL block storage device read/write module for managing a PostgreSQL block as described above in a PostgreSQL block storage device.

The PostgreSQL block storage device read/write module can be architected on a PostgreSQL database system.

The PostgreSQL block storage device read and write module passes the PostgreSQL block-data table mapping table and the idle PostgreSQL block table to the PostgreSQL block storage device. PostgreSQL blocks are managed.

Allocating submodules of the PostgreSQL block,

Reclaim the submodules of the PostgreSQL block,

Locate the submodule of the PostgreSQL block,

Read the submodule of the data in the PostgreSQL block,

A submodule that writes data in a PostgreSQL block.

The sub-module that allocates the PostgreSQL block allocates a PostgreSQL block to the PostgreSQL data table by using a nearby allocation policy or a hot-hot data hierarchical allocation policy, and the nearby allocation strategy is a PostgreSQL block nearest allocation policy or an idle PostgreSQL block table recording nearest allocation policy. The hot-cold data table hierarchical allocation strategy is a common data table allocation strategy or a recently used data table allocation strategy. The PostgreSQL block nearest allocation strategy is to find an idle PostgreSQL block to be assigned to the data table before and after the last allocated PostgreSQL block of the data table. The free PostgreSQL block table record near allocation strategy is to find the first free PostgreSQL block from the idle PostgreSQL block table record, the commonly used data table allocation strategy is to preferentially allocate the data table to the faster PostgreSQL block device. The recently used data table allocation strategy is to prioritize the recently used data table to a faster PostgreSQL block device for a PostgreSQL block device having two or more different read and write speeds. on;

The decryption method is a method of deciphering the user password and the data read from the PostgreSQL block and then deciphering it to the database service layer.

Embodiment 3:

As shown in FIG. 4, the present invention is based on a data read/write method of a PostgreSQL block storage device, and reads and writes a PostgreSQL block as described above by using a PostgreSQL block storage device read/write module as described above.

Each PostgreSQL block can write to 512 8-KB PostgreSQL block database system pages. A block device can contain an infinite number of tables. A table can contain an unlimited number of PostgreSQL blocks. These block file information is stored in PostgreSQL block-data. Mapping between tables Within the relationship table;

As shown in Figure 4, the detailed design is as follows:

Create a PostgreSQL block-to-data table mapping table and a free PostgreSQL block table.

Table 1: PostgreSQL block-data table mapping table

	字段Field	类型Types of	描述 description
11	Relfilenode(表编号)Relfilenode (table number)	oid Oid		表IDTable ID
22	Reltablespace(表空间编号)Reltablespace (table space number)	oidOid	表空间ID Table space ID
33	Forknum(文件类型)Forknum (file type)	Int2Int2	表fork类型 Table fork type
44	Blockid(块编号)Blockid (block number)	oidOid	表所占用的块IDThe block ID occupied by the table
55	Blockno(块位置)Blockno (block location)	oidOid	被占用的块所在数据表中的位置The location in the data table where the occupied block is located

Table 2: Idle PostgreSQL Block Table

	字段Field	类型Types of	描述 description
11	Blockid(块编号)Blockid (block number)	oid Oid		块IDBlock ID
22	Isfree(占用标识)Isfree (occupation mark)	boolBool	是否被使用Is it used?
33	Dev(设备标识)Dev (device identification)	stringString	块设备标识Block device identification

A First, we logically partition the PostgreSQL block storage device into N PostgreSQL blocks in units of 4MB.

In general, we split the PostgreSQL block storage device by 4MB. We only need to calculate the total number of PostgreSQL block storage devices by dividing the total capacity of the PostgreSQL block storage device by the capacity of a PostgreSQL block. This does not require scanning the PostgreSQL block storage device. This allocation time is extremely short. For example, the 2T PostgreSQL block storage device only needs to be divided into 524288 PostgreSQL blocks. We only need to add 524288 records to the free PostgreSQL block table, and the blockid can be incremented from 0--524287. Also mark isfree as true.

B. The storage space of the data table is allocated in units of 4 MB.

According to the process of the PostgreSQL database system, the actual occupied space of a table is allocated on demand. We modify the PostgreSQL database system background driver file storage / smgr / smgr.c type typedef struct f_smgr required method to rewrite.

include{

Mdinit,

Mdclose,

Mdcreate,

Mdexists,

Mdunlink,

Mdextend,

Mdprefetch,

Mdread,

Mdwrite,

Mdnblocks,

Mdtruncate,

Mdimmedsync,

Mdpreckpt,

Mdsync,

Mdpostckpt

}

The specific implementation of these methods is in the md.c file. (Other methods in this file should also be modified)

Modify the MdfdVec involved in each method.

The main ideas of the revision are:

The original SMgrRelation reln, ForkNumber forknum two parameters are located to the file system's table file modified to locate the offset of the block device. We can get relfilenode, reltablespace, forknum according to reln. We can locate the data occupied by our table from the mapping table between PostgreSQL block and data tables. Guarantee (pageno+1)*4*1024KB>reln.pageid*8KB>pageno*4*1024KB.

If the mapping between the PostgreSQL block and the data table does not exist, we need to add a PostgreSQL block to the data table. At this point, we can directly use a block device that is not used from the free PostgreSQL block table. Directly avoid the complicated allocation process of the file system when processing large files.

If the PostgreSQL block-data table exists in the mapping table, we can directly locate the PostgreSQL block storage device to pageno*4*1024KB+(reln.pageid%512)*8KB. Read this 8K data.

The intermediate process of PostgreSQL database business to disk and its simplicity. Disk utilization is extremely high.

C. Expansion of the PostgreSQL block storage device.

When our PostgreSQL block storage device is not large enough, our distributed storage can be easily expanded. Just add a new entry to the free PostgreSQL block table. There are two ways to expand capacity: one is to expand the original block device; the other is to add a new block device. For the former we update the mapping table between PostgreSQL block and data tables, for example, from 2TB to 4TB, we only need to insert 524288 new records, 524288-1048575 increments. For the latter, for example, adding a 2T block device. We added 524,287 records, the blockid is incremented from 0-524287, and dev can be located.

D, database migration.

The database business layer is separated from the data layer. Mount the block device directly to the new node. This upper level system error does not affect the underlying data.

E, data security.

PostgreSQL block storage device selection rules can be customized. In step B, we are the choice of order. We can also add some rules to our selection method (for example, we can insert a consistent hash algorithm in it) to disrupt our database. Storage rules to ensure data security.

The key points of the present invention are as follows.

1) PostgreSQL database system background storage is stored on a bare disk basis.

2) Cross-OS direct migration of PostgreSQL database system migration, and verification.

3) Direct support for the distributed file system (ceph) block device by the PostgreSQL database system.

The advantageous effects of the present invention are as follows in comparison with the prior art.

1) Insert and query faster.

2) Migration is more flexible.

3) The data is more secure.

4) PostgreSQL database system business and data storage are separated.

It should be noted that the various embodiments described above with reference to the accompanying drawings are only to illustrate the invention and not to limit the scope of the invention, and those of ordinary skill in the art should understand that without departing from the spirit and scope of the invention Modifications or equivalents to the invention are intended to be included within the scope of the invention. In addition, unless the context indicates otherwise, words in the singular include plural and vice versa. In addition, all or a portion of any embodiment can be used in combination with all or a portion of any other embodiment, unless otherwise stated.

Claims

A PostgreSQL block storage device read/write module, characterized in that: the PostgreSQL block storage device read/write module is a PostgreSQL block storage device read/write module that manages a PostgreSQL block in a PostgreSQL block storage device, and the PostgreSQL block storage device The read/write module architecture is on the PostgreSQL database system.
The PostgreSQL block storage device read/write module according to claim 1, wherein: said PostgreSQL block storage device read/write module passes a PostgreSQL block-data table mapping table and an idle PostgreSQL block table to a PostgreSQL block storage device. The PostgreSQL block is managed.
The PostgreSQL block storage device read/write module according to claim 2, wherein the mapping relationship table between the PostgreSQL block and the data table includes fields Relfilenode, Reltablespace, Forknum, Blockid, Blockno, and the free PostgreSQL block table. Includes fields Blockid, Isfree, Dev.
The PostgreSQL block storage device read/write module according to claim 3, wherein the PostgreSQL block storage device read/write module has the following submodules:

Allocating submodules of the PostgreSQL block,

Reclaim the submodules of the PostgreSQL block,

Locate the submodule of the PostgreSQL block,

Read the submodule of the data in the PostgreSQL block,

A submodule that writes data in a PostgreSQL block.
The PostgreSQL block storage device read/write module according to claim 4, wherein:

The sub-module that allocates the PostgreSQL block allocates a PostgreSQL block to the PostgreSQL data table by using a nearby allocation policy or a hot-hot data hierarchical allocation policy, and the nearby allocation strategy is a PostgreSQL block nearest allocation policy or an idle PostgreSQL block table recording nearest allocation policy. The hot-cold data table hierarchical allocation strategy is a common data table allocation strategy or a recently used data table allocation strategy. The PostgreSQL block nearest allocation strategy is to find an idle PostgreSQL block to be assigned to the data table before and after the last allocated PostgreSQL block of the data table. The free PostgreSQL block table record near allocation strategy is to find the first idle from the idle PostgreSQL block table record PostgreSQL block, the common data table allocation strategy is that the frequently used data table is preferentially allocated to the faster PostgreSQL block device, and the recently used data table allocation strategy is to prioritize the recently used data table to the faster PostgreSQL block device. The hot-cold data table hierarchical allocation strategy is used on a PostgreSQL block device having two or more different read/write speeds;

The submodule of the Recycled PostgreSQL block is used to reclaim the PostgreSQL block that is no longer used by the data table, and the corresponding PostgreSQL block record is deleted from the mapping relationship table between the PostgreSQL block and the data table, and the record of the corresponding PostgreSQL block is sent to the free table. Set to idle;

The sub-module for locating the PostgreSQL block is used to locate a page in the data table to a location specified by the PostgreSQL block device;

The submodule for reading data in the PostgreSQL block is used to read data of a specified size in a specified position in the specified block;

The sub-module that writes the data in the PostgreSQL block is used to write data of a specified size within a specified location within the specified block.
The PostgreSQL block storage device read/write module according to claim 5, wherein:

The submodule that writes the data in the PostgreSQL block writes the data to the PostgreSQL block in an encrypted manner; accordingly,

The sub-module that reads the data in the PostgreSQL block reads the data back to the database business layer in a decrypted manner.
The PostgreSQL block storage device read/write module according to claim 6, wherein:

The encryption method is a method of performing storage encryption on the user password and data XOR;

The decryption method is a method of encrypting the user password with the data read from the PostgreSQL block and then returning it to the database service layer.
The PostgreSQL block storage device read/write module according to claim 7, wherein the Dev field in the free PostgreSQL block table identifies different storage devices to implement capacity expansion.
The PostgreSQL block storage device read/write module according to claim 7, wherein the mapping relationship table between the PostgreSQL block and the data table and the idle PostgreSQL The block table is copied from the original library to the new library, and the PostgreSQL block storage device is migrated from the computer where the original library is located to the computer where the new library is located.
The PostgreSQL block storage device read/write module according to any one of claims 1 to 9, wherein the PostgreSQL block is a minimum unit allocated to a data table in a PostgreSQL database system, and is characterized in that: the PostgreSQL block is stored. The capacity is greater than 4 KB, and the PostgreSQL block storage device read/write module reads and writes the PostgreSQL block through a data read/write method based on the PostgreSQL block storage device.