Multi-version management method for database fixed-length fields, medium and product

Abstract

The invention provides a multi-version management method for database fixed-length fields, a medium and a product. The multi-version management method for the database fixed-length fields comprises the steps of configuring a preset shadow version number for target fixed-length fields or target fixed-length field groups in a database table; constructing a shadow column set for the target fixed-length field or the target fixed-length field group in the row of the database table; constructing a plurality of shadow versions in the shadow column set into an end-to-end circular queue, and setting an identifier to record a serial number of a current writable version in the circular queue; and in response to a data read-write request, performing read-write operation on the shadow version in the circular queue based on the visibility auxiliary information corresponding to the shadow version, the serial number of the writable version and a preset visibility judgment rule, thereby realizing multi-version management of the target fixed-length field or the target fixed-length field group. According to the scheme, the method is adaptive to a specific scene in which the fixed-length fields are frequently updated and only a limited historical version is needed; and constant storage occupation and stable read-write performance are ensured.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a method, medium, and product for managing multiple versions of fixed-length fields in a database. Background Technology

[0002] The database uses Multi-Version Concurrency Control (MVCC) technology to store multiple versions of a single row of data, achieving concurrency control and ensuring that each read request can read the expected version, thus guaranteeing effective lock resource control for update and delete operations. In the PostgreSQL series databases, the Heap engine stores multiple rows of data, each row identified by a different version based on its transaction ID. The algorithm is simple and intuitive, and the logical Heap data is illustrated in Table 1.

[0003] Table 1 Table 1 stores five versions of a single row of data. Each version has a row header, including the creation version number (xmin), the deletion / modification version number (xmax), and the transaction ID (cmdid) of the modification SQL. Data read requests generate corresponding snapshots, which typically contain elements such as the current minimum active transaction ID (xmin), the current minimum active transaction ID (xmax), and the current transaction SQL row number (cmdid). During the scan and read process, a complex algorithm uses the snapshot and row header visibility information to determine the visibility of each row, skipping invisible rows and reading visible ones. From the perspective of the latest time, rows 1 to 4 of Table 1 are historical versions, or dead tuples, while row 5 contains the latest data.

[0004] As the number of data deletions and updates increases, the proportion of historical versions gradually increases. When the proportion of historical versions increases to a certain threshold, the database will start the Vacuum process to clean up expired historical versions. Otherwise, it will occupy extra space, resulting in a decrease in space utilization, and the query performance will be reduced due to scanning useless rows.

[0005] Oracle and MySQL databases implement an in-place update engine. Instead of storing multiple versions in data blocks, they store the latest version or the version being modified within each data block. UNDO data stores rows before modification by transaction, with each row having a unique identifier composed of specific data. A historical version chain is built between UNDO records from different transactions for each row. When a historical version needs to be read, the latest version and the historical version chain determine the correct version to retrieve. In frequently updated TP (Transaction Processing) applications, often one or two historical versions are read, and decoding historical data from UNDO data each time incurs performance overhead.

[0006] For Heap engines like PostgreSQL, prior to Vacuum, multiple historical versions of a single row of data led to space bloat and reduced query efficiency until Vacuum cleaned up historical versions. This caused fluctuations in space usage and query performance metrics. Furthermore, when the Heap engine has a very large data volume, Vacuum may not be able to clean up historical data in time, inevitably causing a series of stability issues. In-place update engines like those in Oracle and MySQL databases, MVCC version control requires an additional UNDO management mechanism, and in frequently updated business scenarios, query efficiency is also affected by the version chain.

[0007] In scenarios like the following: some fields in a database table do not need to be modified, while non-primary key and non-unique constraint fields may be modified frequently, and the maximum length of the modified fields is predictable with a strong emphasis on real-time performance. In other words, particularly old historical versions are generally not a concern, and 1 to 3 historical versions are usually sufficient. In scenarios such as using a database to implement a payment or consumption function for a specific account, whether using the industry-leading multi-version style of PostgreSQL or the UNDO data historical version chain style of Oracle, a large accumulation of historical versions will occur, resulting in wasted space and reduced query efficiency. Summary of the Invention

[0008] One object of the present invention is to provide a multi-version management method for fixed-length fields in a database that can solve any of the above problems.

[0009] A further objective of this invention is to address the performance fluctuations and space waste issues of existing database multi-version management schemes, and to adapt to specific scenarios where fixed-length fields are frequently updated and only a limited number of historical versions are required.

[0010] Another further objective of this invention is to achieve low-overhead multi-version management of fixed-length fields / field groups by using an in-row circular queue-style shadow column set to ensure constant storage usage and stable read / write performance without the need for additional cleanup processes or UNDO mechanisms.

[0011] Specifically, this invention provides a method for managing multiple versions of a fixed-length field in a database, comprising: configuring a preset number of shadow versions for a target fixed-length field or a group of target fixed-length fields in a database table; constructing a set of shadow columns for the target fixed-length field or a group of target fixed-length fields within a row of the database table; constructing multiple shadow versions in the set of shadow columns into a circular queue with the head and tail connected, and setting an identifier to record the sequence number of the currently writable version in the circular queue; and responding to data read / write requests, performing read / write operations on the shadow versions in the circular queue based on the visibility auxiliary information corresponding to the shadow version, the sequence number of the writable version, and a preset visibility judgment rule, thereby realizing multi-version management of the target fixed-length field or a group of target fixed-length fields.

[0012] Optionally, the target fixed-length field is a field that is not a primary key, has no unique constraint, and has a predictable maximum length. The target fixed-length field group consists of multiple target fixed-length fields. The shadow column set contains multiple shadow versions corresponding to the preset number of shadow versions, and each shadow version is configured with independent visibility auxiliary information.

[0013] Optionally, visibility assistance information includes the transaction ID that created the shadow version, the SQL statement number within the transaction, and the transaction ID that indicates the version has expired.

[0014] Optionally, configuring a preset shadow version number for a target fixed-length field or target fixed-length field group in a database table includes: specifying a preset shadow version number for the target fixed-length field or target fixed-length field group through a table definition statement when creating the database table; if not specified, the preset shadow version number takes the default value of 0, and the target fixed-length field or target fixed-length field group is treated as a regular field.

[0015] Optionally, the operations in response to a data write request include: when the write request is read for the first time, retrieving data from the latest readable version in the circular queue; determining the target write position based on the sequence number of the writable version, writing the updated data to the shadow version corresponding to the target write position, and updating the visibility auxiliary information of the shadow version; if the transaction corresponding to the write request is committed, updating the sequence number of the writable version to the next sequence number in the circular queue; if the transaction is rolled back, marking the shadow version corresponding to the target write position as obsolete, and setting the latest readable version to the previous sequence number in the circular queue.

[0016] Optionally, the operation in response to a data read request includes: traversing each shadow version starting from the latest readable version in the circular queue; performing a visibility judgment on the traversed shadow version; if the preset visibility judgment rule is met, returning the data of that shadow version; if the preset visibility judgment rule is not met even after traversing to the last shadow version in the circular queue or empty data, returning the oldest shadow version data and a specific identifier, the specific identifier being used to indicate that the version corresponding to the read request is too old.

[0017] Optionally, the target fixed-length field can be of the following types: numeric, time, and fixed-length character.

[0018] Optionally, the sequence number of the shadow versions in the circular queue is advanced according to the update sequence. When all the shadow versions in the circular queue are occupied, the new update operation overwrites the oldest shadow version, thus realizing version cyclic reuse.

[0019] According to another aspect of the present invention, a computer-readable storage medium is also provided, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps of the multi-version management method for fixed-length fields in a database as described above.

[0020] According to another aspect of the present invention, a computer program product is also provided, comprising a computer program, characterized in that, when the computer program is executed by a processor, it implements the steps of the multi-version management method for fixed-length fields in a database as described above.

[0021] The multi-version management method for fixed-length fields in the database of this invention solves the core pain point of the traditional MVCC mechanism at its root by constructing a circular queue of shadow columns for fixed-length fields or field groups within the database table rows. By pre-setting a fixed number of shadow versions, the space usage remains constant, eliminating the need for Vacuum processes or third-party plugins for fragmentation cleanup, completely avoiding dead tuple accumulation and storage space waste, while also saving the IO overhead and business blocking risks caused by version cleanup. By directly storing a limited number of versions within the original row and combining visibility auxiliary information to achieve fast version determination, the performance consumption of version chain decoding and log reading is significantly reduced, resulting in a significant improvement in the response efficiency of read and write operations.

[0022] Furthermore, the multi-version management method for fixed-length fields in the database of the present invention achieves dual optimization of concurrency performance and scenario adaptability by virtue of flexible version configuration and precise visibility control. Different fixed-length fields or field groups can be configured with independent shadow version numbers, which can accurately match the update frequency and historical version requirements of different businesses, avoiding resource redundancy or functional insufficiency caused by unified configuration. At the concurrency processing level, the circular queue structure design allows write operations to quickly obtain the write position without waiting for historical version cleanup, and read operations can efficiently locate the target version by traversing the latest readable version and judging by visibility rules, achieving a concurrency control effect where read and write operations do not block each other. For extreme scenarios where the version is too old, the design of returning the oldest version data and a specific identifier further improves the stability and reliability of multi-version management while ensuring business continuity.

[0023] The above and other objects, advantages and features of the present invention will become more apparent to those skilled in the art from the following detailed description of specific embodiments of the invention in conjunction with the accompanying drawings. Attached Figure Description

[0024] The following sections will describe some specific embodiments of the invention in a detailed manner by way of example and not limitation, with reference to the accompanying drawings. The same reference numerals in the drawings denote the same or similar parts or portions. Those skilled in the art should understand that these drawings are not necessarily drawn to scale. In the drawings: Figure 1 This is a diagram illustrating the existing technology of updating multiple engine versions in situ. Figure 2 This is a schematic flowchart of a multi-version management method for fixed-length fields in a database according to an embodiment of the present invention; Figure 3This is a schematic diagram of a computer program product according to an embodiment of the present invention; Figure 4 This is a schematic diagram of a computer-readable storage medium according to an embodiment of the present invention; and Figure 5 This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0025] Those skilled in the art should understand that the embodiments described below are merely a part of the embodiments of the present invention, and not all of the embodiments of the present invention. These partial embodiments are intended to explain the technical principles of the present invention and are not intended to limit the scope of protection of the present invention. Based on the embodiments provided by the present invention, all other embodiments obtained by those skilled in the art without creative effort should still fall within the scope of protection of the present invention.

[0026] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0027] Figure 1 This is a diagram illustrating the existing technology of updating multiple engine versions in-situ. Figure 1 This demonstrates the relationship between transactions and data versions in traditional database multi-version management, highlighting the version diffusion characteristic of traditional solutions. Starting with "r1 latest version," transaction 1 updates it, generating "r1 historical version," and also producing additional historical versions such as r2 and r3. Transaction 2, based on the output of transaction 1, further generates r4 historical version and a new r1 historical version. Transaction 3, based on transaction 2, further derives r1 historical version and r5 historical version. Figure 1 This clearly reflects the core problem of traditional multi-version management: versions spread in a chain / tree-like manner along the transaction chain, causing the number of historical versions to increase linearly with the number of transactions, ultimately leading to storage redundancy and complex version positioning issues.

[0028] This embodiment provides a multi-version management method for fixed-length fields in a database, which can solve the performance fluctuation and space waste problems of existing database multi-version management solutions, and is suitable for specific scenarios where fixed-length fields are frequently updated and only a limited number of historical versions are needed. It achieves low-overhead multi-version management of fixed-length fields / field groups, and ensures constant storage usage and stable read and write performance through an in-row circular queue-style shadow column set, without the need for additional cleanup processes or UNDO mechanisms. Figure 2 This is a schematic flowchart of a multi-version management method for fixed-length fields in a database according to an embodiment of the present invention, such as... Figure 2 As shown, the multi-version management method for fixed-length fields in a database generally includes the following steps: Step S202: Configure a preset shadow version number for the target fixed-length field or target fixed-length field group in the database table.

[0029] Step S204: Construct a set of shadow columns for the target fixed-length field or target fixed-length field group within the rows of the database table.

[0030] Step S206: Construct multiple shadow versions in the shadow column set into a circular queue with the head and tail connected, and set an identifier to record the sequence number of the currently writable version in the circular queue.

[0031] Step S208: In response to the data read / write request, based on the visibility auxiliary information corresponding to the shadow version, the sequence number of the writable version, and the preset visibility judgment rules, read / write operations are performed on the shadow version in the circular queue to realize multi-version management of the target fixed-length field or the target fixed-length field group.

[0032] Specifically, in step S202, the target fixed-length field is a field that is not a primary key, has no unique constraint, and whose maximum length is predictable. The target fixed-length field group consists of multiple target fixed-length fields.

[0033] It should be noted that column groups are similar to column families in analytical databases. They are a solution that combines multiple related columns together to reduce the fixed storage and access overhead of each column, thereby improving database query performance, storage efficiency, and data management capabilities.

[0034] Specifically, in step S204, the shadow column set contains multiple shadow versions corresponding to a preset number of shadow versions, and each shadow version is configured with independent visibility assistance information.

[0035] It should be noted that a shadow column refers to storing multiple versions of a field or group of fields in a single row, similar to creating a series of shadows in a time tunnel. Read requests will select a suitable shadow in chronological order.

[0036] Specifically, visibility assistance information includes the transaction ID that created the shadow version, the SQL statement number within the transaction, and the transaction ID that indicates the version has expired.

[0037] Specifically, step S202, configuring a preset shadow version number for a target fixed-length field or target fixed-length field group in a database table, may include: specifying a preset shadow version number for the target fixed-length field or target fixed-length field group through a table definition statement when creating the database table; if not specified, the preset shadow version number takes the default value of 0, and the target fixed-length field or target fixed-length field group is treated as a regular field.

[0038] Specifically, the operations in response to a data write request may include: when the write request is read for the first time, retrieving data from the latest readable version in the circular queue; determining the target write position based on the sequence number of the writable version, writing the updated data to the shadow version corresponding to the target write position, and updating the visibility auxiliary information of the shadow version; if the transaction corresponding to the write request is committed, updating the sequence number of the writable version to the next sequence number in the circular queue; if the transaction is rolled back, marking the shadow version corresponding to the target write position as obsolete, and setting the latest readable version to the previous sequence number in the circular queue.

[0039] Specifically, the operation in response to a data read request may include: traversing each shadow version starting from the latest readable version in the circular queue; performing a visibility check on the traversed shadow version, and if the preset visibility check rule is met, returning the data of that shadow version; if the preset visibility check rule is not met even after traversing to the last shadow version in the circular queue or empty data, returning the oldest shadow version data and a specific identifier, the specific identifier being used to indicate that the version corresponding to the read request is too old.

[0040] Specifically, the target fixed-length fields can be of various types, including numeric, time, and fixed-length character types. The number of preset shadow versions configured for different target fixed-length fields or groups of target fixed-length fields can be different. Alternatively, the number of preset shadow versions configured for different target fixed-length fields or groups of target fixed-length fields can be the same.

[0041] Specifically, the sequence number of the shadow versions in the circular queue advances according to the update sequence. When all the shadow versions in the circular queue are occupied, the new update operation overwrites the oldest shadow version, thus achieving version reuse.

[0042] It's important to note that when a row of data in a data page changes, if the new data length meets the pre-allocated length, theoretically it can be updated in-place without needing to allocate additional space. However, if other requests are reading the same row at the same time, a read-write conflict will occur, requiring one side to wait for the current transaction to complete, thus reducing concurrency. Furthermore, if the update operation's transaction terminates, the original data is corrupted, making it unavailable for subsequent read requests. Therefore, a read version of the field must be provided for each read request, and at least one readable version must be available from the time the record is created until it is deleted.

[0043] The multi-version management method for fixed-length fields in this embodiment stores multiple versions of a field in a single row, similar to forming a series of shadows in a time tunnel. The multiple versions construct a circular queue with the head and tail connected, and are eliminated from newest to oldest as the update sequence progresses.

[0044] Each version of the field has independent visibility auxiliary information, such as the transaction ID (xmin) that created the shadow version, the transaction ID (xmax) that identified the version as invalid, and the SQL statement number within the transaction (cmdid).

[0045] Add a flag to the circular queue to record the sequence number of the currently writable position in the queue. Calculate the sequence number of the latest readable version in the queue as follows: if the transaction at the write position has been committed, then this version is the latest version, and the writable version is the next sequence number in the queue, which is not available for reading; if the transaction is rolled back, then this version is obsolete, and the latest field is the previous sequence number in the circular queue.

[0046] Read requests traverse from the latest version. If the visibility algorithm is satisfied, the request returns. Otherwise, it continues until the last version is read. At this point, the request returns regardless of whether the visibility algorithm is satisfied. However, if the visibility is not satisfied, a specific flag is returned to indicate that the read request is for data that is too old. Whether to restart the transaction or accept this version of the data is decided by the upper-level caller.

[0047] A write request is an update request. The first read reads data from the latest version, performs calculations, and then stores the data at the write version location. Subsequent reads in a write request transaction read the version from the write location.

[0048] As shown above, this completes the storage of multiple versions of a field within a single row of data and provides the ability to read and write concurrently. The number of versions for each field is specified based on business characteristics when the table is created.

[0049] Furthermore, if multiple fields in a table provide update capabilities, and each field provides multiple versions, there will be some space waste due to the additional data for visibility. We can group multiple fields into a similar column group to provide a unified multiple version identifier, thereby further reducing space waste.

[0050] To increase business flexibility, when creating a table, you can specify different numbers of versions for each field and field group.

[0051] Although the multi-version management method for fixed-length fields in the database in this embodiment also involves multiple versions occupying space, the space occupied is constant. Unlike conventional solutions, it does not cause space and performance fluctuations as the business runs for a long time, resulting in more stable performance.

[0052] It should be emphasized that the multi-version management method for fixed-length fields in the database in this embodiment is mainly aimed at the following scenarios: updating non-primary key columns and non-unique constraint columns in the row storage engine; the storage length of the column meets the maximum pre-allocated length, such as numeric types, char(n) types, etc.; the column is updated frequently, the real-time requirements for column reading are strong, and the number of historical versions is generally limited, such as counters, transportation cards, and consumer card balances, and older historical versions are meaningless.

[0053] This embodiment of the database fixed-length field multi-version management method allows you to specify the number of shadow versions for a specific field when creating a table. If not specified, the default value is 0, meaning it's a regular field. A value greater than 0 means multiple versions of the field are stored in a single row, forming a shadow column. The length of the specific field is fixed, such as numeric, time, or char(n). Different fields can have different numbers of versions.

[0054] When creating a table, you can specify the number of shadow versions for a specific group of fields. If not specified, the default value is 0 (regular fields). A value greater than 0 means multiple versions of that field group are stored in a single row, forming a shadow field group. All fields within a field group must be of fixed length, such as numeric, time, or char(n). Different field groups can have different numbers of versions.

[0055] Each shadow in the shadow column and shadow field group has visibility-determining attributes, such as xmin indicating which transaction added the data, cmdid indicating the SQL statement number within the transaction, and xmax indicating the combined transaction, etc.

[0056] Multiple versions are used to build a circular queue, and an identifier is added to store the sequence number of the writable version.

[0057] If the required transaction flag is 0, then the corresponding data is empty, and write operations will directly overwrite it; it will be ignored when reading the version.

[0058] If the required transaction identifier is committed, then the corresponding data is the latest data. The write operation is the next sequence number. When writing, the transaction number is first set to the current transaction number. When reading the version, read backwards from this sequence number until empty data or a writable sequence number is reached.

[0059] If the corresponding transaction identifier is rolled back, then the corresponding position is writable. When writing, first set the transaction number to the current transaction number; when reading a version, read backwards from the previous version number until empty data or a writable sequence number is reached.

[0060] The read operation determines visibility based on the field version information. The algorithm is similar to traditional row visibility. If all versions are not visible, the oldest version is selected and returned along with a specific identifier indicating that the read request is too old.

[0061] The multi-version management method for fixed-length fields in this embodiment saves storage space and ensures stable query performance. For data tables with frequently updated non-primary keys, non-unique constraints, maximum fixed-length columns, and fixed-length field groups, the number of MVCC versions in this embodiment is constant, much smaller than the historical version number of existing solutions. Query and update performance will not deteriorate or become unstable as business operations continue for a long time.

[0062] MVCC, as a mechanism for handling high-concurrency transactions in databases, allows multiple transactions to be processed without blocking and solves data consistency issues through version control. Specifically, in terms of storage, each data row has multiple historical versions, each version corresponding to a timestamp or transaction ID. Dependencies between different versions are managed through pointers or links to generate a version chain, facilitating rapid access to the required data.

[0063] The multi-version management method for fixed-length fields in the database described in this embodiment is particularly suitable for scenarios such as using TP database to implement counters, locks, transportation card recharge and consumption, and consumer card recharge and consumption.

[0064] The following example, using transportation card top-ups and spending, illustrates the changes in data stored internally.

[0065] The simplified transportation card data table consists of the card number and the current balance, with the card number as the primary key and the balance changing with top-ups and transactions. It should be noted that "write no" in the following table refers to "writable flag: unused".

[0066] 1. Create a table. Create Table subwaycard(card int primary key, balance numeric(10,2)not null shadows=2 check(balance >= 0)); 2. Deposit 100 yuan to activate the card. If the data is read and the version data is successfully submitted, the latest version is number 0, and the transportation card balance is 100.

[0067] 3. Spend 1 yuan. If the data is read and the version data is successfully submitted, the latest version is number 1, and the transportation card balance is 99.

[0068] If the data is read before submission, the latest version is number 0, and the transportation card balance is 100.

[0069] 4. Purchase 2 yuan. If the data is read and the version data is successfully submitted, the latest version is number 2, and the transportation card balance is 98.

[0070] 5. The version with a 3 yuan purchase option is flipped. If the data is read and the version data is successfully submitted, the latest version is number 0, and the transportation card balance is 95.

[0071] 6. I recharged 100, but the recharge failed for other reasons. If the data read and write version data submission fails, the latest version is number 0, the transportation card balance is 95, and the oldest version is 98 yuan.

[0072] 7. Recharged 50, but failed for other reasons. If the data is read and the version data is successfully submitted, the latest version is number 1, and the transportation card balance is 145.

[0073] In summary, multiple versions form a version chain within the line, which is cyclical and reused, ensuring at least one readable version is maintained, space is controllable, and query and update efficiency is stable.

[0074] This embodiment's method for managing multiple versions of fixed-length fields in databases addresses the competitive challenges posed by database architectures similar to Heap engines and in-place update engines. It stores multiple versions in a single row, balancing space usage, query efficiency, and cleanup costs. In business scenarios involving fixed-length field updates, it eliminates the need for historical version cleanup processes and reading the UNDO historical version list, enabling rapid updates and queries with minimal additional space usage, tailored to specific business needs.

[0075] It's important to note that Oracle's UNDO data management is the core mechanism for achieving transaction consistency and supporting high-concurrency operations. By recording the data state before a transaction's modification (UNDO data), it ensures that transactions can be rolled back correctly and provides other transactions with a consistent data view (multi-version concurrency control).

[0076] In this embodiment, by constructing a circular queue of shadow columns for fixed-length fields or field groups within the database table rows, the core pain point of the traditional MVCC mechanism is fundamentally solved. By pre-setting a fixed number of shadow versions, the space usage remains constant, eliminating the need for Vacuum processes or third-party plugins for fragmentation cleanup. This completely avoids dead tuple accumulation and storage space waste, while also eliminating the IO overhead and business blocking risks associated with version cleanup. By directly storing a limited number of versions within the original rows and combining visibility auxiliary information to achieve rapid version determination, the performance consumption of version chain decoding and log reading is significantly reduced, resulting in a significant improvement in the response efficiency of read and write operations.

[0077] With flexible version configuration and precise visibility control, it achieves dual optimization of concurrency performance and scenario adaptability; different fixed-length fields or field groups can be configured independently with different shadow version numbers, which can accurately match the update frequency and historical version requirements of different businesses, avoiding resource redundancy or functional deficiencies caused by unified configuration; at the concurrency processing level, the circular queue structure design allows write operations to quickly obtain the write position without waiting for historical version cleanup, and read operations can efficiently locate the target version by traversing the latest readable version and judging by visibility rules, achieving a concurrency control effect where read and write operations do not block each other; for extreme scenarios with excessively old versions, by returning the oldest version data and a specific identifier, the stability and reliability of multi-version management are further improved while ensuring business continuity.

[0078] The flowcharts provided in the above embodiments are not intended to indicate that the operations of the method will be performed in any particular order, or that all operations of the method are included in all every case. Furthermore, the method may include additional operations. Within the scope of the technical concept provided by the methods in the above embodiments, additional variations can be made to the methods.

[0079] This embodiment also provides a computer program product, a computer-readable storage medium, and a computer device. Figure 3 This is a schematic diagram of a computer program product 500 according to an embodiment of the present invention. Figure 4 This is a schematic diagram of a computer-readable storage medium 300 according to an embodiment of the present invention. Figure 5 This is a schematic diagram of a computer device 400 according to an embodiment of the present invention.

[0080] Computer program product 500 includes computer program 310, which, when executed by processor 410, implements the steps of the multi-version management method for fixed-length database fields described above. Computer-readable storage medium 300 stores the aforementioned computer program 310, which, when executed by processor 410, implements the steps of the multi-version management method for fixed-length database fields described above. Computer device 400 may include memory 420, processor 410, and computer program 310 stored in memory 420 and running on processor 410.

[0081] The computer program 310 used to perform the operations of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, status setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages ​​and procedural programming languages.

[0082] Computer program 310 may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0083] In some embodiments, in order to perform aspects of the present invention, electronic circuits including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs) or programmable logic arrays (PLAs) can execute computer-readable program instructions to personalize the electronic circuits by utilizing state information of computer-readable program instructions.

[0084] For the purposes of this embodiment, computer program product 500 is a related product containing computer program 310. For the purposes of this embodiment, computer-readable storage medium 300 is a tangible device capable of holding and storing computer program 310, and can be any device capable of containing, storing, communicating, propagating or transmitting computer program 310 for use by or in conjunction with an instruction execution system, apparatus or device.

[0085] More specific examples (a non-exhaustive list) of computer-readable storage media 300 include the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, and any suitable combination of the foregoing.

[0086] Computer device 400 may include memory 420, processor 410 and computer program 310 stored on memory 420 and running on processor 410, and processor 410 executes computer program 310 to implement the steps of the multi-version management method for fixed-length fields of database in any of the above embodiments.

[0087] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any machine-readable storage medium for use by, or in conjunction with, instruction execution systems, apparatuses or devices (such as computer-based systems, processor-based systems or other systems that can fetch and execute instructions from, or instruction execution systems, apparatuses or devices).

[0088] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system.

[0089] Computer device 400 can be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, computer device 400 can be a cloud computing node. Computer device 400 can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. Computer device 400 can be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can reside on local or remote computing system storage media, including storage devices.

[0090] Computer device 400 may include a processor 410 adapted to execute stored instructions and a memory 420 that provides temporary storage space for the operation of instructions during operation. The processor 410 may be a single-core processor, a multi-core processor, a computing cluster, or any other configuration. The memory 420 may include random access memory (RAM), read-only memory, flash memory, or any other suitable storage system.

[0091] The processor 410 can be connected via a system interconnect (e.g., PCI, PCI-Express, etc.) to an I / O interface (input / output interface) suitable for connecting the computer device 400 to one or more I / O devices (input / output devices). I / O devices may include, for example, a keyboard and indicating devices, where indicating devices may include a touchpad or touchscreen, etc. I / O devices may be built into the computer device 400 or may be external devices connected to the computing device.

[0092] The processor 410 may also be linked via a system interconnect to a display interface suitable for connecting the computer device 400 to a display device. The display device may include a display screen as a built-in component of the computer device 400. The display device may also include an external computer monitor, television, or projector connected to the computer device 400. Furthermore, a network interface controller (NIC) may be adapted to connect the computer device 400 to a network via a system interconnect. In some embodiments, the NIC may use any suitable interface or protocol (such as an Internet Minicomputer System Interface) to transmit data. The network may be a cellular network, a radio network, a wide area network (WAN), a local area network (LAN), or the Internet, etc. Remote devices may connect to the computing device via the network.

[0093] Therefore, those skilled in the art should recognize that although numerous exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications conforming to the principles of the present invention can be directly determined or derived from the disclosure of the present invention without departing from the spirit and scope of the invention. Thus, the scope of the present invention should be understood and construed as covering all such other variations or modifications.

Claims

1. A method for managing multiple versions of a fixed-length field in a database, comprising: Configure a preset number of shadow versions for a target fixed-length field or a group of target fixed-length fields in a database table; Construct a set of shadow columns for the target fixed-length field or group of target fixed-length fields within the rows of the database table; Construct multiple shadow versions from the shadow column set into a circular queue with the head and tail connected, and set an identifier to record the sequence number of the currently writable version in the circular queue; as well as In response to data read / write requests, based on the visibility assistance information corresponding to the shadow version, the sequence number of the writable version, and the preset visibility judgment rules, read / write operations are performed on the shadow version in the circular queue to realize multi-version management of the target fixed-length field or target fixed-length field group.

2. The method according to claim 1, wherein, The target fixed-length field is a field that is not a primary key, has no unique constraint, and has a predictable maximum length; the target fixed-length field group consists of multiple target fixed-length fields. The shadow column set contains multiple shadow versions corresponding to the preset number of shadow versions, and each shadow version is configured with independent visibility assistance information.

3. The method according to claim 2, wherein, The visibility assistance information includes the transaction ID that created the shadow version, the SQL statement number within the transaction, and the transaction ID that indicates the version has expired.

4. The method according to claim 1, wherein the step of configuring a preset shadow version number for a target fixed-length field or a group of target fixed-length fields in a database table includes: When creating the database table, the preset shadow version number is specified for the target fixed-length field or target fixed-length field group through the table definition statement; If not specified, the preset shadow version number takes the default value of 0, and the target fixed-length field or target fixed-length field group is processed as a regular field.

5. The method of claim 1, wherein the operation in response to a data write request comprises: When a write request is read for the first time, data is retrieved from the latest readable version of the circular queue; The target write position is determined based on the sequence number of the writable version. The updated data is written to the shadow version corresponding to the target write position, and the visibility assistance information of the shadow version is updated. If the transaction corresponding to the write request is committed, the sequence number of the writable version is updated to the next sequence number of the circular queue; if the transaction is rolled back, the shadow version corresponding to the target write position is marked as obsolete, and the latest readable version is the previous sequence number of the circular queue.

6. The method of claim 1, wherein the operation in response to a data read request comprises: Iterate through the shadow versions starting from the latest readable version in the circular queue; Perform a visibility check on the traversed shadow versions. If the preset visibility check rule is met, return the data of the shadow version. If the preset visibility judgment rule is still not met when traversing to the last shadow version or empty data in the circular queue, the oldest shadow version data and a specific identifier are returned. The specific identifier is used to indicate that the version corresponding to the read request is too old.

7. The method according to claim 1, wherein, The target fixed-length field can be of the following types: numeric, time, and fixed-length character.

8. The method according to claim 1, wherein, The sequence number of the shadow versions in the circular queue advances according to the update sequence. When all the shadow versions in the circular queue are occupied, the new update operation overwrites the oldest shadow version, thus realizing version cyclic reuse.

9. A computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor to implement the steps of the multi-version management method for fixed-length fields in a database as described in any one of claims 1 to 8.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the multi-version management method for fixed-length database fields as described in any one of claims 1 to 8.

Images