Method for implementing unique constraints on mpp databases using ao tables that satisfy aci d properties

Abstract

The application discloses a method for realizing unique constraint of AO table on MPP database satisfying ACID characteristics, which comprises the following steps: creating a unique index on the AO table, updating existing data on the AO table with the unique index, and then deleting the existing data on the AO table; importing new data into the current AO table row by row, and sending each row of data to the corresponding data node according to the distribution strategy of the current AO table, and writing the data into the independent buffer area of the AO table; then constructing an index tuple of the new data row TID and the index column of the current AO table, and inserting the index tuple into the shared buffer area of the current index, and the like. By creating a unique index, importing new data into the AO table based on the unique index, and judging the conflict by constructing an index tuple, the current transaction is rolled back when the conflict occurs, thereby solving the AO table unique constraint problem on the basis of the solution of the heap table unique constraint, and not bringing negative influence to the unique constraint implementation of the heap table.

Description

TECHNICAL FIELD

[0001] The present application relates to a unique constraint method of AO table, and more particularly, to a unique constraint implementation method of AO table satisfying ACID characteristics on MPP database. BACKGROUND

[0002] With the development of database to NewSQL era, MPP architecture database also uses row storage table for transaction query, which supports transaction, MVCC and other row level concurrency control technology to improve concurrency. AO table is designed for analysis scene, and ACID characteristics and UDI operation are designed and implemented for user friendliness and transparency. Due to the row level conflict judgment of unique constraint, and the reasons of block level compression, block level concurrency control, block level index information construction and block level RowID information batch compression storage of AO table, most MPP databases fail to implement unique constraint of AO table, and other analytical engines also fail to implement unique constraint of AO table.

[0003] Heap table refers to row storage table suitable for OLTP, and each row head stores a large amount of additional information such as transaction information, MVCC control information, column null value information and column offset. The heap table and its index use shared cache page, and any insertion, update and deletion operation on the page by the user can be immediately perceived by other users. When potential unique conflict occurs, that is, the same index column value is found in the index page, the transaction information of the corresponding table head is read through the TID in the index row under the concurrency control of MVCC and lock, and the following judgment can be easily made: whether the transaction corresponding to the current potential conflict row has ended, if not, wait for it to end. If the transaction is committed, the conflict occurs. Whether the current potential conflict row has been deleted, if it has been deleted, there is no unique conflict. Whether the current potential conflict row is being deleted by other transactions. If it is not deleted, a unique conflict occurs, otherwise, rejudge after the transaction ends.

[0004] Due to the design of heap table, the storage is significantly enlarged, the data is irregular, the compression rate is low, the row level concurrency control such as row lock MVCC leads to low batch data processing performance, the column offset is not fixed and the offset needs to be calculated every time, which leads to poor performance of large query, and vector technology cannot be used for batch processing of columns, which is not suitable for OLAP scene application. AO table solves the problems of storage performance, data compression ratio and association performance in OLAP scene by column storage, large block IO read and write and reducing IO cost, but it brings challenges to the implementation of unique constraint. Therefore, it is necessary to study and improve the unique constraint implementation method of AO table on MPP database. SUMMARY

[0005] One of the purposes of the present application is to provide an implementation method of AO table unique constraint on MPP database satisfying ACID characteristics in order to solve the technical problems that MPP database fails to implement AO table unique constraint and other analytical engines also fail to implement AO table unique constraint in the prior art.

[0006] To solve the above technical problems, the present application adopts the following technical solutions:

[0007] The implementation method of AO table unique constraint on MPP database satisfying ACID characteristics provided by the present application comprises the following steps.

[0008] Step A, creating a unique index on the AO table, updating the existing data on the AO table with the unique index, and then deleting the existing data on the AO table.

[0009] Step B, importing new data into the current AO table row by row, and sending each row of data to the corresponding data node according to the distribution strategy of the current AO table, and writing the data into the independent buffer area of the AO table; then constructing an index tuple of the new data row TID and the index column of the current AO table, and inserting it into the shared buffer area of the current index.

[0010] Step C, judging whether the index tuple exists in the data row of the current AO table by the following steps: judging whether the TID conflicts from the Block block being constructed in the current AO table, if the result is yes, it is confirmed that the conflict occurs, otherwise the next step is executed to continue to judge.

[0011] Continue to query the summary information of the Block block containing the TID corresponding row of the potential conflict row obtained according to the index in the ao_blockdir auxiliary table according to the segment number and the row number in the TID of the potential conflict row obtained according to the index; if the summary information is successfully queried, it is further judged whether the TID corresponding row of the potential conflict row obtained according to the index is deleted, if it is deleted, it is inserted successfully, otherwise it is confirmed that the conflict occurs; if the summary information cannot be queried, the table lock of the current AO table is upgraded to an exclusive lock by the current transaction, and after confirming the end of the previous transaction, if the previous transaction is in a commit state, it is confirmed that the conflict occurs, if the previous transaction is in a rollback state, the current transaction is inserted successfully; when the conflict is confirmed, the current transaction is rolled back.

[0012] Step D, when the data volume of the new data imported into the current AO table reaches the preset threshold of the AO table independent buffer area, the current data is compressed and written to the end of the data file of the AO table, and the Block summary information is generated and written into the ao_blockdir auxiliary table, and the AO table independent buffer area is reset.

[0013] As preferred, the further technical solution is that the method further comprises: step E, querying the index tuple satisfying the current query request condition in the unique index, if no index tuple is queried, the query ends and an empty result is returned; otherwise, it is further judged whether the current index tuple is valid; if yes, the table is back-tabled through the TID in the index tuple and it is judged whether the row on the table is visible; if yes, the current row is the data row satisfying the query request condition and the query result is returned.

[0014] The further technical solution is that in the method, it is judged whether the row corresponding to the TID of the potential conflict row obtained according to the index is deleted, and the judgment is made in a memory Map composed of TIDs of deleted rows; if there is a TID in the Map, the potential conflict row is deleted and the current row is inserted successfully; otherwise, it is further judged whether the row is deleted according to the deletion mark stored in the ao_visibilitymap table, if the row is deleted, the insertion is successful, otherwise, it is confirmed that a conflict occurs.

[0015] The further technical solution is that when there is a possibility of unique conflict, the table lock of the current AO table is upgraded to an exclusive lock by the current transaction, and if the exclusive lock is upgraded successfully, it is determined that it is a non-concurrent scenario, at this time, the previous transaction has ended (i.e. the previous transaction may be rolled back or successfully committed and ended); if the exclusive lock is not upgraded successfully, it is determined that it is a concurrent scenario, and the current transaction waits until the exclusive lock is upgraded successfully, and then the previous transaction ends, and it is further judged whether the previous transaction ends in a rollback or a commit.

[0016] The further technical solution is that the method further comprises performing a Vaccum operation on the AO table, and the index is reconstructed by the Vaccum operation to physically delete the residual or deleted index tuple.

[0017] Compared with the prior art, one of the beneficial effects of the present application is that by creating a unique index, importing new data into the AO table based on the unique index, and judging the conflict by constructing the index tuple, when a conflict occurs, the current transaction is rolled back, thereby solving the AO table unique constraint problem on the basis of the solution of the heap table unique constraint, and not bringing negative effects to the unique constraint implementation of the heap table; the user uses the heap table to process the OLTP business and uses the AO table to process the OLAP business under the same set of databases, and the use mode of the unique constraint is the same. BRIEF DESCRIPTION OF DRAWINGS

[0018] Figure 1 FIG. 1 is a flowchart for explaining the unique constraint AO table data deletion process in one embodiment of the present application.

[0019] Figure 2 FIG. 3 is a flowchart for explaining the AO table overall import process in one embodiment of the present application. DETAILED DESCRIPTION

[0020] The application belongs to the application technology of MPP architecture NewSQL relational database, and an analytic business scenario pays more attention to database batch data warehousing performance, data compression ratio, and performance of multi-table association of fact table and latitude table. An AO table is designed for this scenario, different concurrent import methods, column storage block-level compression, and block-level concurrent control technology are adopted. The AO table refers to an append-only table, which does not support delete and update operations. After improvement, it currently supports delete and update operations, and is also called an append-optimized table. The AO table adopts a completely different design scheme from the heap table to adapt to the OLAP scenario. Although the AO table also supports row storage, the AO column storage table is particularly suitable for the OLAP scenario. The application only introduces the AO table in the column storage mode.

[0021] The size of each block of the AO column storage table is 32K by default, and many column values are continuously stored in the middle of the block header and the block tail, which increases the compression ratio of the compression algorithm. The compression ratio will be more optimal by selecting a suitable compression algorithm according to the data type and characteristics of different columns. In order to enhance the concurrent import performance of the AO table, the write and read of the AO table do not use a shared buffer, but exclusively apply for the required memory. When concurrently importing into the same AO table, data is concurrently written into different files without affecting each other. The AO table is not suitable for frequent updates of small data volumes, and Delete and Update are exclusive locks of the table, which causes Delete and Update to be unable to operate concurrently. The creation of the AO table and the update of data thereon will generate some additional metadata information and control information, which will be stored in the associated auxiliary table. The auxiliary table is a heap table type, and the ACID characteristics of the auxiliary table indirectly realize the ACID characteristics of the AO table.

[0022] The AO table must use a shared memory buffer to cache the update and read-write of the index page of the unique index, otherwise the concurrent import scenario cannot perceive the risk of unique constraint conflict when the same index key value exists. Since the transaction information and deletion mark of the AO table row or column are encoded and stored in blocks, the implementation of the unique constraint must also be designed based on blocks. Compared with the unique index of the heap table, the AO table faces new problems in implementing the unique constraint, which are:

[0023] 1. How to locate the specific position of the row in the AO table through the TID in the index item. The page of the heap table is fixed in size, and the offset of the page in the file can be calculated by multiplying the page number by the page size. The size of the block of the AO table is uncertain. The aforementioned TID is Tuple ID, which is the ID number of the row in the AO table, and each row has a unique ID number.

[0024] 2. If the two rows that conflict uniquely in a transaction fall into the same block, how to determine the conflict. After inserting a row into the block, the corresponding index tuple needs to be inserted into the index page immediately, the purpose is to find the possibility of unique conflict in time. At this time, since the block is in the construction process and has not yet generated block summary information, it is not possible to obtain transaction information by back table through TID, and transaction information is not stored in the index item, so it is not possible to determine that the conflict item is generated by the transaction itself.

[0025] 3. Update non-unique index column, how to determine that no unique conflict occurs. Since the update is a non-unique index column, the index key value is unchanged, and there must be an index tuple with the same index key on the index page. How to determine that the same index tuple corresponds to the row that the Update operation just deleted, and has been deleted by the transaction. Because the delete flag has not been written into the ao_visibilitymap auxiliary table at this time.

[0026] 4. There are the same unique values in the index page, how to determine whether it is a rolled back transaction or a concurrent transaction. Suppose that two transactions T1 and T2 insert the same row in turn, when T2 inserts the index tuple on the index page, it needs to accurately determine whether there is a unique conflict. Based on the design of the AO table, T2 cannot accurately determine the following two scenarios:

[0027] Transaction T1 has been rolled back. At this time, the block summary information written by T1 into the ao_blockdir auxiliary table is not visible to transaction T2, or it has not written the ao_blockdir auxiliary table and has been rolled back. However, the index tuple is left on the index page.

[0028] Transaction T1 is in execution. The block where the conflicting row is located is in the construction process, and the summary information of the block has not been written into the ao_blockdir auxiliary table, even if it is written, it is not visible to transaction T2 under the read committed isolation level.

[0029] The database provides the following different operations for users using the AO table: (1) creating a unique index on the AO table; (2) deleting existing data on the AO table; (3) updating existing data on the AO table; (4) inserting or batch importing new data into the AO table; (5) executing query operations on the AO table; (6) performing maintenance operations on the AO table, such as Vacuum operation.

[0030] The method described in the application will be further described in conjunction with the accompanying drawings.

[0031] One embodiment of the application is an implementation method of AO table satisfying ACID characteristics on MPP database unique constraint, the method realizes the unique constraint of AO table on MPP database through the following steps and operation modes.

[0032] 1. Create unique constraints or unique indexes on the AO table. Index pages are cached in a shared memory cache on the compute nodes. Each index uses a separate set of files (if the data volume is large enough, the files will be split into multiple files) to store the index data. Updates to the index cache pages are guaranteed by WAL (Write-Ahead Log). When a transaction commits, the index tuples do not need to be written to the file immediately; a background thread is responsible for writing them to the file.

[0033] The creation steps are:

[0034] a) Scan all data rows in the table, extract only the column values ​​of the unique index key and TID from the rows to form the index sorted tuple, that is: the row of the index object.

[0035] b) After sorting all index tuples, construct a B+ tree index and finally store it in the index file.

[0036] c) If there are duplicate data with index keys in the table, the duplicate data will be adjacent after sorting, making it easy to determine if there is a unique conflict.

[0037] 2. Updating existing data in a uniquely constrained AO table. Updating a single row of data is equivalent to deleting an existing row and then inserting the updated row within the same transaction.

[0038] 3. Delete existing data on the unique constraint AO table. The deletion process is as follows: Figure 1 As shown. Because the deletion process does not perform any additional operations on the unique index tuple, the deletion flowchart does not show index-related content. Later, when "data import requires checking for unique conflicts" or "the index scan finds the index tuple corresponding to the deleted row," the row is checked back through the TID in the index tuple to confirm that it has been deleted, and then the deleted row is marked on this index tuple. Next time, a table lookup is not needed to determine if the index tuple is invalid. Rows of data deleted before a transaction commits are not physically deleted but marked for deletion. All deletion marks are compressed and written to the ao_visibilitymap auxiliary table only when a threshold is reached or the transaction commits.

[0039] IV. Importing new data into the unique constraint AO table. The data cache in the AO table uses a dedicated memory cache. During concurrent or parallel imports, data in the AO table is written to different data files, and the unique index key or constraint key must contain the table's distribution key. This ensures that when a uniqueness conflict occurs in the MPP cluster, the conflicting index tuples will always fall on the same single node instance. Only then do concurrent or parallel operations need to interact to avoid breaking the unique constraint. Furthermore, during concurrent or parallel data imports, all index tuples are stored in the same file. The aforementioned single concurrent import process is as follows:

[0040] When data is imported, each row of data is sent to the corresponding data node instance according to the distribution strategy of the table. The data is imported row by row in units of rows. Specifically, a row of data is first written into the independent buffer area of the AO table (to facilitate subsequent construction of the Block block), and the TID of the row is generated at the same time. (During the process of importing data into the AO table, the newly added row is assigned an incremental row number, which ensures that the TIDs of the rows in the same block are also in an incremental relationship. When a block is constructed, the summary information of the block is generated and stored in the ao_blockdir auxiliary table. The size of the block of the AO table is not fixed, and the summary information of the block needs to be saved: the specific value of the file offset of the block; the row number of the first row of data in the block; and the file to which the block belongs, i.e., the segment number).

[0041] Then the TID and the index column are immediately constructed into an index tuple and inserted into the shared buffer area of the index. The index tuple insertion process is a process of searching (to find whether the same index key tuple exists) and sorting from the root to the leaf of the B+ tree. If the same index key exists in the B+ tree index, there is a possibility of unique conflict. This requires a back-table query by obtaining the TID in the existing index tuple to determine whether the row in the corresponding table actually exists. This is further divided into the following steps.

[0042] a) The two rows that may conflict are in the same Block block, and the summary information of the block has not been generated. Therefore, the TIDs are first compared to determine whether they exist in the Block being constructed. If they exist, a conflict occurs. Otherwise, the following step b is continued.

[0043] This step is to solve the above problem 2. The specific solution is to open a new memory on the Plan tree to save the TIDs of all rows in the currently constructed block, and to search for the TID in the potential unique conflict index tuple in this memory. If there is a unique conflict, the conflict occurs. When the block is constructed, the block is written into the data file, and the block summary information is written into the ao_blockdir auxiliary table. After that, the memory needs to be reset in time to avoid occupying too much memory space. How to determine the conflict when the two rows that conflict in the same transaction span multiple blocks. Although the transaction has not been committed, the block summary information written by the transaction in the ao_blockdir auxiliary table is visible to the transaction, as shown in the following step b.

[0044] b) Continue to find the Block block containing the row corresponding to the TID in the ao_blockdir table by segment number and row number in the TID. If found (the case of not found is described in the following step c), it is necessary to continue to determine whether the row has been deleted. If deleted, the insertion can be successful, otherwise a conflict occurs. The determination of whether to delete is further divided into two cases (i.e. the solution to problem 3 described above): (1) first determine whether to delete in the memory Map composed of "TIDs of deleted rows". If there is a TID in the Map, it means that it has been deleted, and there is no conflict, otherwise continue to determine. (2) Then determine whether to delete according to the deletion flag stored in the ao_visibilitymap table. If deleted, no conflict occurs, otherwise a unique conflict occurs.

[0045] c) If the TID cannot find the Block block meta information in the ao_blockdir table, it is also divided into two cases:

[0046] c1) The previous transaction T1 is rolled back, and the Block block summary information has not been written into the ao_blockdir table (even if it is successfully written, it cannot be seen because the transaction is finally rolled back), but the index tuple remains in the index page.

[0047] c2) Concurrent transactions T1 and T2 are imported at the same time, and the concurrent transaction T1 has not written the Block block summary information into the ao_blockdir auxiliary table (even if it is successfully written, it cannot be seen because the transaction has not ended), and the transaction T2 finds the index tuple with the same index key in the index B+ tree.

[0048] This case is the problem to be solved in the above-mentioned problem 4, and the root cause is that the index tuple does not contain any transaction information, which needs to be obtained by the TID in the index item. The solution is that T2 attempts to upgrade the table lock of the AO table to an exclusive lock (or additionally add an exclusive lock). (1) If the lock upgrade (or add exclusive lock) is successful, it can be determined as a non-concurrent scenario, indicating that transaction T1 has ended, and the index item written by transaction T1 is marked as invalid and ignored. (2) If the lock upgrade (or add exclusive lock) is not successful, it is determined as a concurrent scenario and needs to be waited until the lock upgrade is successful (a timeout time can also be set, and T2 is rolled back after the timeout). After the lock upgrade is successful, it indicates that T1 has ended, and then it is determined whether T1 is in a commit state or a rollback state. If T1 is committed, a unique conflict occurs, otherwise it indicates that T1 has been rolled back and T2 can continue to execute the insertion.

[0049] Note: The table lock mentioned above is the table lock on the computing node, and there is no need to lock upgrade on the management node, which requires that the deadlock detection can handle the scenario of table lock upgrade on the computing node.

[0050] d) If the row data does not conflict, the index tuple is inserted into the B+ tree, and the TID of the new row is added to the memory space opened in the Plan tree, which is used to determine the conflict of the subsequently inserted data, that is, the new memory space opened in the above problem 2.

[0051] The above process fails when there is only one conflict, and the transaction is rolled back. Otherwise, the above steps are repeated to continue importing subsequent data rows.

[0052] When the amount of imported data reaches a certain threshold in the memory cache area exclusively used by the AO table, a Block block is constructed: (1) compress the data and write it to the end of the data file of the AO table. (2) Generate Block summary information and write it to the ao_blockdir auxiliary table. (3) Reset the buffer for constructing the next Block block.

[0053] The overall import process of the above AO table with unique constraints is shown in Figure 2 .

[0054] Five, the method called in this embodiment can also be implemented on the AO table to perform a query operation. If the query specifies a query condition of the index key (such as an equal or greater than condition), and the total number of rows that meet the condition is relatively small. At this time, the unique index scan can be optimized first, and the index is used to locate the index tuples that meet the condition, because the B+ tree has a sorting feature and is very efficient. The query process is:

[0055] Query the index tuples that meet the conditions in the index. If not, the query ends and returns an empty result to the user.

[0056] Determine whether the index tuple is invalid. If it is invalid, continue to obtain other index tuples that meet the condition and determine the validity of the index tuple.

[0057] If it is valid, the TID in the index tuple is back-tabled to determine whether the row on the table is visible (if the transaction that inserted or deleted the row is in a rollback state, it means that it is not visible. The back-table step of the TID is the same as the back-table step of the TID in the above insertion operation, which will not be repeated here), and if it is not visible, mark the index tuple as invalid and ignore the row.

[0058] If it is visible, this row is one of the rows returned to the user.

[0059] Loop to the first step to continue to find the index tuples that meet the conditions in the index. Until all data rows that meet the query conditions are returned to the user.

[0060] Six, Vaccum operation on the AO table. During the operation and maintenance time, the Vaccum operation will rebuild the index to physically delete the residual or deleted index tuples.

[0061] From the above embodiment, it can be seen that the application meets the scene requirement of OLAP by designing the AO table function, but cannot distinguish the repeated data when warehousing. If the unique constraint is implemented on the AO table, the above four problems need to be solved, and cannot cause the performance attenuation of the AO table in all aspects. A specific method is designed so that the AO table can implement the unique constraint in the MPP database.

[0062] In addition, it should be noted that the "one embodiment", "another embodiment", "embodiment" and the like mentioned in the specification refer to the specific features, structures or characteristics described in conjunction with the embodiment, which are included in at least one embodiment generally described in the application. The same expression appears in many places in the specification does not necessarily refer to the same embodiment. Further, when a specific feature, structure or characteristic is described in conjunction with any embodiment, it is claimed that the implementation of such feature, structure or characteristic in conjunction with other embodiments also falls within the scope of the application.

[0063] Although the application is described herein with reference to a number of illustrative embodiments of the application, it should be understood that various other modifications and implementations could be devised by those skilled in the art without departing from the principles disclosed herein. More particularly, many variations and modifications will be apparent to those skilled in the art from the foregoing description, which is to be considered in all respects only as illustrative. For example, specific shapes, configurations, and features of the subject combination layout can be varied and are contemplated in the scope of the disclosure. In addition to variations and modifications of the combination layout, other applications will become apparent from this disclosure.

Claims

1. A method for implementing unique constraints on an MPP database using AO tables satisfying ACID properties, characterized in that The method comprises the following steps: Creating a unique index on the AO table, updating existing data in the AO table with the unique index, and then deleting the existing data on the AO table; Importing new data into the current AO table row by row, and sending each row of data to the corresponding data node according to the distribution strategy of the current AO table, and writing the data into the independent buffer area of the AO table; then constructing an index tuple of the TID and the index column of the new data row of the current AO table, and inserting it into the shared cache area of the current index; Determine whether the index tuple exists in the data row of the current AO table by the following steps: Determine whether the TID conflicts from the Block block being constructed in the current AO table, if the result is yes, it is confirmed that a conflict occurs, otherwise, the next step is executed to continue to determine; Continue to query the summary information of the Block block containing the corresponding row of the TID of the potential conflict row obtained according to the index in the ao_blockdir auxiliary table according to the segment number and the row number in the TID of the potential conflict row obtained according to the index; If the summary information is successfully queried, it is further determined whether the corresponding row of the TID of the potential conflict row obtained according to the index is deleted, if it is deleted, the insertion is successful, otherwise, it is confirmed that a conflict occurs; If the summary information cannot be queried, the table lock of the current AO table is upgraded to an exclusive lock by the current transaction, and after confirming the end of the previous transaction, if the previous transaction is in a commit state, it is confirmed that a conflict occurs, if the previous transaction is in a rollback state, the current transaction is inserted successfully; When the conflict is confirmed, the current transaction is rolled back; When the amount of data imported into the current AO table reaches the preset threshold of the independent buffer area of the AO table, the current data is compressed and written to the end of the data file of the AO table, and the Block summary information is generated and written into the ao_blockdir auxiliary table to construct the current Block block, and then the independent buffer area of the AO table is reset.

2. The method for implementing the unique constraint of the AO table satisfying the ACID characteristics on the MPP database according to claim 1, wherein The method further comprises: querying the index tuple satisfying the current query request condition in the unique index, if not queried, the query ends and an empty result is returned; otherwise, it is further determined whether the current index tuple is valid; If it is valid, the TID in the index tuple is back-tabled and it is determined whether the row on the table is visible; if it is visible, the current row is the data row satisfying the query request condition, and the query result is returned.

3. The method of claim 1, wherein the ACID properties satisfied by the AO table implementation of unique constraints on MPP databases is characterized in that In the method, it is determined whether the corresponding row of the TID of the potential conflict row obtained according to the index is deleted, first in the memory Map composed of the TIDs of the deleted rows; if there is a TID in the Map, the potential conflict row is deleted, the current row is inserted successfully, otherwise, it is further determined whether it is deleted according to the deletion mark stored in the ao_visibilitymap table, if it is deleted, the insertion is successful, otherwise, it is confirmed that a conflict occurs.

4. The method of claim 1, wherein the ACID properties satisfied by the AO table implementation of unique constraints on MPP databases is characterized in that: In the method, the table lock of the current AO table is upgraded to an exclusive lock by the current transaction, and if the upgrade to the exclusive lock is successful, it is determined that the non-concurrent scenario, and the previous transaction has ended; if the upgrade to the exclusive lock fails, it is determined that the concurrent scenario, and waiting until the upgrade to the exclusive lock is successful, the previous transaction ends, and then it is further determined whether the previous transaction ends in a rollback or a commit.

5. The method of claim 1, wherein the ACID properties satisfied by the AO table implementation of unique constraints on MPP databases is characterized in that The method further comprises performing a Vaccum operation on the AO table, and performing physical deletion of residual or deleted index tuples by rebuilding the index through the Vaccum operation.

Images