System and methods to support scalability in a distributed online transactional processing database

Abstract

System and method are provided for data partitioning. The data on a data node is organized in Range Intervals of a fixed size, called partitions. The index and logging tables of the data node are unpartitioned. Processes for splitting partitions and moving partitions across nodes online and maximizing the data availability during partition operations such as split and move, by have read operations unaffected through the use of MVCC visibility rules are disclosed. A novel process for maximizing availability during split by allowing certain write operations to occur in partitions currently being split is also disclosed.

Description

SYSTEM AND METHODS TO SUPPORT SCALABILITY IN A DISTRIBUTED ONLINE TRANSACTIONAL PROCESSING DATABASETECHNICAL FIELD

[0001] The present invention pertains to the field of database systems, and more particularly to a system and methods for partitioning a distributed database to support online transaction processing.BACKGROUND

[0002] In the context of geographically distributed storage systems including, but not limited to, cloud native databases, dynamic cluster scaling is expected to support for dynamic workloads. To build scalable storage systems, data may be partitioned and stored on separate data nodes. When a workload of a given application changes, more compute and storage resources may be required. In such a situation, the system is required to adapt to a new workload and prevent customers from overpaying for the resources, which are no longer needed.

[0003] In a scalable system, changes in the needed storage resources may be addressed by changing the number of servers in the storage system. By adding or removing servers allocated to the storage of data, the system is able to adapt to different types of workloads. One challenge is to design a system having a plurality of member nodes that can support dynamic membership changes as well as transparent data rebalancing. Both changes to the membership of the system, and data rebalancing that is done to support these changes should be done without a noticeable impact to the ongoing workload. When a new server is added into the system, parts of the data on existing servers may have to be moved over to the new server to allow for a measure of load.

[0004] This may require the system is required to efficiently identify a portion of data that can be relocated to a new resource within the system. The movement of this identified data is preferably done transparently to a user in that this data transfer is done without negative impact to an ongoing workload. Dynamic membership and transparent data rebalancing capabilities of the system alleviate workload bottlenecks by dispersing so called “hot data” to different servers.

[0005] In database management systems, data may be partitioned across multiple different servers to improve the scalability of the system. This approach is employed in the shared-nothing architecture where data may be partitioned into static ranges. For example, FIG. 1 shows an example of a database cluster (or a data table) with three data nodes. Data in the  database cluster is partitioned and distributed across the three data nodes. Each record within the database is associated with an index value, also referred to as an id value. Data Node 1 contains 2 partitions. The first partition stores records associated with id values in the range of negative infinity to 250 (-inf, 250) . The second partition stores records associated with id values in the range of [250, 500) . Similarly, Data Node 2 has two data partitions. The first partition of Data Node 2 stores records associated with id values in the range of [500, 750) . The second partition of Data Node 2 stores records associated with id values in the range of [750, 1000) . Data Node 3 has one data partition storing records associated with id values ranging from 1000 to infinity. Partition boundaries of a static partition are typically defined when the database is brought online. With a static partition model, the boundaries cannot be modified throughout the lifetime of the database. A workload, which may involve the created database, is assumed to be static. When a new database (a new table) with a desired amount of partitions and boundaries is created, and all the data in the original database is then copied to the new database, the ongoing workload operations may be slowed down, and a final cost of the ongoing workload operations may be negatively affected: copying the data within a sufficiently large database will last a non-negligible amount of time, during which the performance of the system may be notably degraded.

[0006] Some other conventional database management systems may avoid this problem through over-partitioning data. Similar to previously discussed database systems with static range partitioning, the partition boundaries of an over-partitioned database system are declared when the table is created. The partition boundaries are fixed, but by creating a large number of small tables, it is easier to move entire tables, or sets of tables, to new data nodes to help reduce the processing load on each data node. For example, FIG. 2 shows an example of a database with a large number of partitions spread across Data Nodes 1 through 3. If the number of data nodes (servers) in the database cluster is changed, these partitions may be easily moved to conform to a new cluster size. Over partitioning simplifies the process needed to move data across different servers in the database cluster. However, it increases the overhead processing of table management when there is a small amount of data in the database. This increases the cost of running this type of database.

[0007] Some databases are designed to store records in a set of partitions that can be hosted in different data nodes. The data is stored across the partitions, and if any given partition exceeds a prescribed size, it can be split apart. The resulting partitions may be moved to different data nodes. The move operation can be achieved using replication. A destination data node is added into the replication group to accumulate data. Once the destination data  node has captured all the data, the destination data node is made the leader of the replication group, and the original leader may be removed from the replication group. Each partition may have a separate Write Ahead Logging (WAL) log table as illustrated in FIG. 3. If a transaction modifies data that spans across two or more partitions, the transaction can use a two-phase commit protocol to ensure correctness of the committed data in the event of a failure. A two-phase commit protocol records into two different WAL log tables, which can be used to ensure or verify accurate recording of data. Separate WAL log tables ensure that log table records cannot be coalesced, and, subsequently, incur false IO records. Even when two partitions physically reside on the same data node, the two-phase commit protocol may still be required.

[0008] A hash partitioning method is similar to range partitioning. Instead of using a data value in the record as an index, a hash function can be applied to data within the record to generat a hashed index. This hashed index can then be used to set the partition boundaries. This allows for even data distribution across data nodes without prior knowledge of the data distribution. However, assignments of the partitions to the data nodes are fixed. Hash partitioning combined with use of consistent hashing allows for automatic load balancing. Data records are assigned to the data nodes (the servers) based on the hashed partition key. A hash ring is formed from all the values in the hash space. A set of virtual nodes is also hashed to a location on the hash ring using a unique ID, for example, an IP address. Data are assigned to the virtual node where the hash of the partition key is closest to the hash of the unique ID of the virtual node, in a counterclockwise direction. This approach provides statistical guarantee that data is evenly balanced. Even when new data nodes are added to the ring, only a small portion of the total data is required to be relocated. If n is the number of nodes, approximately 1 / n of the total data will be assigned to each virtual node. Hash partitioning solves the problem of load balancing in the presence of cluster membership changes, but it does not necessarily address any of the other deficiencies experienced by other techniques discussed above. Adding data nodes or splitting partitions is still a process that generally results in increased data latency access.

[0009] Therefore, improvements are desirable to support online transaction processing in distributed databases.SUMMARY

[0010] According to embodiments of the present invention, there is provided a method for supporting scalability of a database. The method is executed by a data node (DN) of the  database. The method comprises determining that an existing partition should be split into two partitions, the existing partition including a set of records, at least one of the set of records having an associated record lock preventing execution of at least one operation by an entity other than an entity associated with the record lock, and at least one of the set of records having no associated record lock. The method further comprises copying each record without an associated record lock to a left partition or a right partition; copying each record not previously copied to the left partition or the right partition; prior to copying each record without the associated record lock, applying a shared partition lock to the existing partition to prevent execution of at least one of a partition move operation and a partition split operation on the existing partition; following said copying of each record without an associated record lock, replacing the shared partition lock with an exclusive partition lock to prevent execution of at least one operation in the existing partition by an entity other than the entity associated with the exclusive partition lock; and releasing the exclusive partition lock. In some embodiments of the method, the shared partition lock prevents execution of a partition move operation or a partition split operation by the entity other than the entity associated with the shared partition lock, and, subsequent to copying of each record without the associated record lock to the left partition or the right partition, at least one copied record may be associated to a respective record transfer link, an identification number (ID) of a respective record copying operation and a record transfer mark (RTM) . In some embodiments, the at least one copied record is an active record, and, subsequent to applying the shared partition lock, in the existing partition each record without the associated record lock is available to record read operations. In some embodiments, a record read operation of a first record with a snapshot preceding a first record copying operation reads a first record value on the existing partition; a record read operation of a second record with a snapshot following a second record copying operation reads a second record value in a location indicated by a second record transfer link; subsequent to copying each record not previously copied to the left partition or the right partition, at least one record not previously copied may be associated to a respective record transfer link, an ID of a respective record copying operation and a record transfer mark (RTM) ; and the at least one record not previously copied may be an active record. In some embodiments, determining that the existing partition should be split into two partitions includes comparing an amount of unoccupied space within the existing partition to a threshold value. In some embodiments, the method comprises defining the left partition and the right partition. In some embodiments, the existing partition has unoccupied free space, and the existing partition is available to record insert operations. The method may comprise  determining a split pivot value (SPV) having a value between a lowest record value and a highest record value within an ordering of the set of records within the existing partition. In some embodiments, the left partition has a range defined by a lower bound value of the existing partition and an upper bound value determined in accordance with the SPV, and a right partition has a range defined by a lower bound value determined in accordance with the SPV and an upper bound value of the existing partition. The method may include maintaining a logging table , and the logging table is a single logging table of the DN. In some embodiments, the method includes maintaining an index table, the index table is a single index table of the DN. The method may further include maintaining a block range map (BRM) , wherein the BRM associates each partition of the DN to a respective logical block range. In some embodiments, each record in the set of records is associated with an identification number (ID) of a respective record insert operation. In some embodiments, upon defining the left partition and the right partition, the BRM may be updated by associating the left partition and the right partition to respective logical block ranges. In some embodiments, at least one record in the set of records is associated with an ID of a respective record logical delete operation. In other embodiments, the method may further include receiving a request to provide data of the existing partition; initiating a discovery operation to discover active records of the set of records; when said discovery operation is successful: defining a set of active records; and sending a response, the response including information indicative of the set of active records. Each active record of the set of active records may be associated with an ID of a respective record logical insert operation, the respective record logical insert operation is committed, and each active record of the set of active records is not associated with an ID of a respective record logical delete operation or the respective record logical delete operation is aborted. Some embodiments may include one of: waiting for the respective record logical insert operation to commit, and waiting for the respective record logical delete operation to commit; or at least one of: waiting for the respective record logical delete operation to abort, and aborting the respective record logical delete operation. In some other embodiments the request to provide data is received from a coordinator node (CN) of the database, and the response is sent to the CN.

[0011] In some embodiments, the CN comprises a map, and the map of the CN associates the existing partition with the DN. In other embodiments the discovery operation comprises at least one of: waiting for the respective record logical insert operation to abort, and aborting the respective record logical insert operation. Each active record of the set of active records of the existing partition may be associated to a record moved mark (RMM) . In some  embodiments, following receipt of the request to provide data, in the existing partition each record without the associated record lock is available to record read operations. In some other embodiment of the method, a record read operation of a third record with a snapshot preceding the discovery operation reads a third record value on the DN, and a record read operation of a fourth record with a snapshot following the discovery operation reads a fourth record value on the DN or a fifth record value, a location of the fifth record value is indicated by the map. In some embodiments, the set of records is divided into two or more consecutive pages; each page on the existing partition has a respective offset, and copying the each record without the associated record lock and copying the each record not previously copied comprises page based record copying operations. In some embodiments each page on the existing partition may be copied to a respective destination page on a destination partition, wherein the respective destination page has the respective offset, and the destination partition is the first partition or the second partition. The method may include associating each page with a page split mark and an identification number (ID) of a respective page based record copying operation. In some embodiments, each page of the set of records is associated with an identification number (ID) of a respective page insert operation.

[0012] Another aspect of the disclosure provides a method for supporting scalability of a database. The database has a coordinator node (CN) operationally couple to a data node (DN) and a second DN. The method comprises receiving by the CN from the DN information indicative of a left partition and a right partition; and updating, by the CN, a map of the CN by associating the left partition and a right partition with the DN. The method may further comprise sending to the DN a request to provide data of an existing partition on the DN; and receiving a response to the request to provide data from the DN, the response including information indicative of a set of records. In some embodiments, the map of the CN associates the existing partition to the DN. In other embodiments, the method further comprises sending to the second DN a request to store data, the store request includes the information indicative of the set of records, and receiving from the second DN a response to the request to store data. In some other embodiments of the method, the response includes a confirmation of a successful receipt of the information indicative of the set of records and a range of a new partition on the second DN storing the information indicative of the set of records. The method may include updating the map of the CN by associating the new partition to the second DN.

[0013] Another aspect of the disclosure provides a method for supporting scalability of a database, where the database having a second data node (DN) operationally couple to a  coordinator node (CN) . The method comprises by the second DN of the database: receiving from a coordinator node (CN) of the database a request to store data, the request including information indicative of a set of records; storing the information indicative of the set of records; and sending to the CN a confirmation message, the confirmation message confirming a successful receipt of the information indicative of the set of records and a range of a new partition on the second DN storing the information indicative of the set of records. In some embodiments, the method may comprise updating a logging table of the second DN and an index table of the second DN. In some other embodiments of the method, the logging table of the second DN is a single logging table of the second DN and the index table of the second DN is a single index table of the second DN.

[0014] Another aspect of the disclosure provides a data node (DN) apparatus for supporting scalability of a database. The DN apparatus is integrated into infrastructure of the database, comprising processing electronics, and configured to: determine that an existing partition should be split into two partitions, the existing partition including a set of records, at least one of the set of records having an associated record lock preventing execution of at least one operation by an entity other than an entity associated with the record lock, and at least one of the set of records having no associated record lock; copy each record without an associated record lock to a left partition or a right partition; copy each record not previously copied to the left partition or the right partition; prior to copying each record without the associated record lock, apply a shared partition lock to the existing partition to prevent execution of at least one of a partition move operation and a partition split operation on the existing partition; following said copying of each record without an associated record lock, replace the shared partition lock with an exclusive partition lock to prevent execution of at least one operation in the existing partition by an entity other than the entity associated with the exclusive partition lock; and release the exclusive partition lock. In some embodiments, the DN apparatus may be configured to receive a request to provide data of the existing partition; and initiate a discovery operation to discover active records of the set of records. When the discovery operation is successful: define a set of active records; and send a response, the response including information indicative of the set of active records. Each active record of the set of active records is associated with an ID of a respective record logical insert operation, the respective record logical insert operation is committed, and each active record of the set of active records is not associated with an ID of a respective record logical delete operation or the respective record logical delete operation is aborted.

[0015] In some other embodiments of the DN apparatus the set of records is divided into two or more consecutive pages, each page on the existing partition has a respective offset, and the copying each record without the associated record lock and said copying the each record not previously copied comprise page based record copying operations.

[0016] Another aspect of the disclosure provides a coordinator node (CN) apparatus for supporting scalability of a database. The CN apparatus operationally coupled to a data node (DN) apparatus and a second DN apparatus. The CN apparatus is integrated into infrastructure of the database, comprising processing electronics, and configured to: receive from the DN apparatus information indicative of a left partition and a right partition; and update a map of the CN apparatus by associating the left partition and a right partition with the DN apparatus. In some embodiments the CN apparatus is further configured to send to the DN a request to provide data of an existing partition on the DN apparatus; and receive a response to the request to provide data from the DN apparatus, the response including information indicative of a set of records.

[0017] Another aspect of the disclosure provides a second data node (DN) apparatus for supporting scalability of a database. The second DN apparatus operationally is coupled to a coordinator node (CN) apparatus. The second DN apparatus is integrated into infrastructure of the database, comprising processing electronics, and configured to: receive from the CN apparatus a request to store data, the request including information indicative of a set of records; store the information indicative of the set of records; and send to the CN apparatus a confirmation message. The confirmation message is confirming a successful receipt of the information indicative of the set of records and a range of a new partition on the second DN apparatus storing the information indicative of the set of records.

[0018] Another aspect of the disclosure provides for a system for supporting scalability of a database. The system comprising a data node (DN) apparatus, a second DN apparatus, and a coordinator node (CN) apparatus. The DN apparatus, the second DN apparatus, and the CN apparatus are integrated into infrastructure of the database. In the system, the DN apparatus is configured to: determine that an existing partition should be split into two partitions, the existing partition including a set of records, at least one of the set of records having an associated record lock preventing execution of at least one operation by an entity other than an entity associated with the record lock, and at least one of the set of records having no associated record lock; copy each record without an associated record lock to a left partition or a right partition; copy each record not previously copied to the left partition or the right partition; prior to copying each record without the associated record lock, apply a shared  partition lock to the existing partition to prevent execution of at least one of a partition move operation and a partition split operation on the existing partition; following said copying of each record without an associated record lock, replace the shared partition lock with an exclusive partition lock to prevent execution of at least one operation in the existing partition by an entity other than the entity associated with the exclusive partition lock; and release the exclusive partition lock.

[0019] The CN apparatus of the system is configured to: receive from the DN apparatus information indicative of a left partition and a right partition; and update a map of the CN apparatus by associating the left partition and a right partition with the DN apparatus. The second DN apparatus of the system is configured to: receive from the CN apparatus a request to store data, the request including information indicative of a set of records; store the information indicative of the set of records; and send to the CN apparatus a confirmation message, the confirmation message confirming a successful receipt of the information indicative of the set of records and a range of a new partition on the second DN apparatus storing the information indicative of the set of records. In some embodiments of the system the CN apparatus is further configured to send to the DN apparatus a request to provide data of a partition on the DN apparatus; and receive a response to the request to provide data from the DN apparatus, the response including information indicative of a set of records.

[0020] Embodiments have been described above in conjunctions with aspects of the present invention upon which they can be implemented. Those skilled in the art will appreciate that embodiments may be implemented in conjunction with the aspect with which they are described, but may also be implemented with other embodiments of that aspect. When embodiments are mutually exclusive, or are otherwise incompatible with each other, it will be apparent to those skilled in the art. Some embodiments may be described in relation to one aspect, but may also be applicable to other aspects, as will be apparent to those of skill in the art.BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Further features and advantages of the present invention will become apparent from the following detailed description, taken in combination with the appended drawings, in which:

[0022] FIG. 1 illustrates an example of data, partitioned into static ranges.

[0023] FIG. 2 illustrates an example of over partitioning of the data.

[0024] FIG. 3 illustrates an example database cluster where each partition has a separate WAL log table.

[0025] FIG. 4 illustrates an example database with micro partitioning.

[0026] FIG. 5 illustrates an example of micro partitioning system components.

[0027] FIG. 6 illustrates an example DistMap of a coordination node.

[0028] FIG. 7 illustrates an example of a block range map (BRM) .

[0029] FIGs. 8A and 8B illustrate an example method of performing a split transfer of records.

[0030] FIG. 9 illustrates an example partition move flow diagram.

[0031] FIG. 10 illustrates an example partition move between two data nodes.

[0032] FIG. 11 illustrates an example page-transfer process.

[0033] FIG. 12 illustrates an example schematic diagram of an electronic device configured to perform any or all of operations according to embodiments of the present disclosure.

[0034] It will be noted that throughout the appended drawings, like features are identified by like reference numerals.DETAILED DESCRIPTION

[0035] Embodiments discussed below in the present disclosure may provide for a system and methods to support scalability in distributed databases, for example, in distributed Online Transactional Processing (OLTP) databases. The system and methods of the present disclosure use micro partitioning to ensure scalability of distributed databases. A micro partition is a small partition of the overall data that may contain data with a partition key within some partition boundaries. The size of the partition may be small, e.g., 64MB. Given the size constraint of the micro partition, the size of the data stored in the partition may eventually grow to be greater than 64MB. A transparent online partition-split procedure of the present disclosure may automatically split the data partition on a data node into two new partitions. The partition-split operation may keep the partition within the size constraint and may support online operations with minimal negative impact to the ongoing workloads. Embodiments of the present disclosure provide for transparent micro-partitions relocation to different servers with minimum negative impact to the ongoing workload.

[0036] Micro-partitioning may only partition the data layer and may not partition the index or the log tables. FIG. 4 shows a high-level overview of a database with micro partitioning. The database includes DN 401, DN 402, and DN 403. Data is partitioned according to each partition boundaries. For example, DN 401 has partition 431 and partition 441. Each  partition on the data node uses the same index table and the same Write Ahead Logging (WAL) table. For example, on DN 401, partition 431 and partition 441 share WAL log table 411. Partition 431 and partition 441 also share index table 421. Having a single WAL log table on a DN implies that when data from different partitions on that DN is modified in the same transaction, and the involving partitions reside on the same physical server, the two-phase commit protocol is not required. A single index table on a DN, e.g. Index table 421 of Data Node 401, may allow for efficient index access and improved index range scans. For read queries, the single index table may enable index access operations to bypass the micro partition layer and access the desired data directly without requesting and acquiring any locks to the partition layer. However, having all the partitions of the DN share the same index table may result in a significantly larger index table.

[0037] As previously mentioned, the size constraint applied to a data partition may necessitate splitting the data partition as the quantity of data increases. In the context of an OLTP system the splitting must be done while the partition remains online and accessible. When a data partition is identified for splitting, the record that forms the point at which the partition is split has to be identified. The identifier of the record forming the split point is referred to as a pivot value. Each partition resulting from the partition-split operation (sometimes referred to as child partitions) may contain approximately half of the data of the parent partition. The data may be divided by the median value of the partition key of the parent partition. When a partition fully filled is detected, a partition-split process is completed automatically by a background thread.

[0038] While the data is relocated during a partition-split, intermediary data (i.e. data added to the partition after the start of the partition-split) may be appended to the relocated data by other in-progress transactions. Visibility of the intermediary data may depend on the result of the transaction. Instead of forcibly aborting the “in doubt” transactions, the system, the apparatus, and the methods of the present disclosure allow these transactions to resolve. The data associated with the resolved partition will be accessible in a child partition resulting from the split operation. A concurrent write transaction that started prior the partition-split process of the data partition will avoid being rolled back. Although during a blocking split phase, future write transactions to the partition, started after the initiation of the partition-split process, may be blocked or buffered. Any transaction, requesting access to the data within a partition that is undergoing a split operation, may be blocked until the entire split process is completed. For example, transactions that require the latest version of data may be blocked, but a transaction that has a snapshot, predating the split operation, may still have read access  to those old versions of data. Fencing off the data partition from modifications during a blocking split phase may be detrimental to the performance of the ongoing workload. An early split procedure may reduce the amount of blocking time required for a split operation. The early split procedure may start a split process before the data partition is completely filled up, i.e. at some threshold value, e.g. 80%full. Moreover, instead of acquiring exclusive access to the data partition, the early split procedure may be performed using only shared access rights. For example, the data partition may be still available for certain update, delete, and insert queries while the data partition is being split.

[0039] A partition-split operation may have two phases: an early split phase and a blocking split phase. The early split phase may relocate all “cold” data within the data partition to a new partition while deferring “hot” data to the blocking split phase. Cold data can be considered to be records that no external entity is attempting to modify or add, while hot data may be considered to be records that are locked to allow for external modification or records that are being inserted into the table. For the blocking split phase, a small amount of data may be left in the partition (e.g. a record that was added during the transfer process) , therefore an exclusive access to the partition which can prevent external modification or addition of records may be required to finalize the split process.

[0040] Depending on the size of a record (a tuple) , when data is selected for to new partitions in a partition-split operation, the overhead of transferring records one by one may be significant. As was mentioned previously, a blocking split phase of the partition-split operation may block clients from modifying data in the partition. A page-based transfer procedure may reduce time required to transfer records to new data partitions, and, consequently, may reduce an overall time required to execute partition-split operations. In one example, the size of each data partition may be limited to a size no greater than 64MB, the time to relocate data partitions from one data node to another may be reduced.

[0041] The micro partitioning solutions disclosed in some embodiments may be implemented using a database management system known as GaussDB which is based on the open-source Postgres-XC system (which, in its turn, was originally based on PostgreSQL) . GaussDB has a “shared nothing” architecture, consisting of computing nodes that assume roles of coordinator nodes (CNs) and data nodes (DNs) . The responsibility of a CN is to handle SQL requests from clients, parse the requests and generate data access plans for the incoming query and communicate with the corresponding DNs for actual execution of the query. DNs are responsible for physically storing the data on storage devices and respond to data access requests from incoming query requests.

[0042] As previously mentioned, the micro partitioning solution may be applicable when the workload of the underlying application is a dynamic workload, or in situations when a cluster membership is required to adapt to a workload. In both scenarios, data relocation may be necessary to rebalance data load of each server in the database cluster. The micro partitioning method may provide a way to relocate data between the DNs (servers) with reduced negative impact on the on-going transaction processing workload.

[0043] To enable data movement across different data nodes (servers) in the cluster, a naming service may be required to map partition keys to data nodes in which they reside. In some embodiments two mapping services may be used to map partition keys within a database cluster. A coarse-grained mapping service may be located on a coordinator node (CN) . The coarse-grained mapping service is denoted as a distmap. The distmap may contain mappings from each partition interval to each data node. The distmap on the CN may be used for general data access plans, e.g. query plans, when the CN receives a request or query from a client. In some embodiment, these requests may be provided as a Structured Query Language (SQL) request. A naming service, denoted as a block range map, may be located on a data node (DN) . The block range map may map partition intervals to logical block numbers to which the data within the partition interval resides. It ensures that data with a given partition key is put into the correct location for future access. The naming services may support data relocation across different DN (servers) and ensure that the relocated data may be found later if required. FIG. 5 shows the database system which includes, besides DNs 401-403, two coordinator nodes (CNs) : Coordinator Node 501 and Coordinator Node 502. CN 501 has distmap table 511, and CN 502 has distmap table 522. The distmap is a many-to-one mapping between an interval (a range) of a data partition and the corresponding DN that stores the data partition. The contents of different distmap tables may differ, typically only by small amounts, and they may be updated over time to resolve these differences. Each block range map is specific to the particular data node on which it resides.

[0044] FIG. 6 shows DistMap 511 on CN 501. On the data node, there is a structure called the block range map, for example, Block Range Map (BRM) 451 on DN 401. The BRM 451 contains a list of block ranges, which is a structure containing meta data information of the corresponding data partitions. Given a partition key, the block range map is used to locate the corresponding block range that contains the partition key. Once the block range has been located, the actual data can be located and modified using the metadata information, such as the logical blocks that store the partition data.

[0045] When a partition is relocated or a partition-split operation is executed, it may change the block range map. A partition relocation may add a new active partition to the block range map of the destination server and remove one active partition from the source server. A partition-split operation may add two new active partitions to the block range map of the server containing the partition, and remove one active partition that is being split. FIG. 7 shows BRM 701. New partition 1 and new partition 2 ranges were added to BRM 701 after a successful execution of split operation 711 on partition 721. A BRM may be stored as an unsorted linear array. Look ups to the BRM involve finding a partition that contains a particular value. A binary search tree (BST) structure may use the partition range (i.e., [250, 500) ) as a key, to provide a fast look up for the particular partition.

[0046] When an online e-commerce business anticipates a significant increase in traffic and sales in near future, the e-commerce business may decide to add additional computing resources to its transaction processing system or storage system to support handling of the added load. With the addition of new data nodes (servers) to the database system, the data stored within the data nodes may have to be rebalanced in the database cluster. Micro partitioning, with data partitioned into relatively small 64MB partitions, may provide speedy data relocation during a split without significant negative impact on performance for the database system by reducing the likelihood that splitting or moving a partition will have large overhead.

[0047] When a user of an application travels abroad, the data access latency may be severely impacted if the data does not move with the user. For example, if the user travels from North America to Europe but the data remains in North America, then any data access request will be directed back to servers geographically located in North America. These data access requests will fetch the data from a server in North America and send the data to Europe. In such a situation, a high data access latency may occur as both the fetch command, and the transmission of data have to use higher latency connections. Moving the data closer to a geographic location, where data access requests are initiated, may significantly reduce the access latency.

[0048] Besides moving data partitions to different locations for better load balance and access latency, the database system can be designed to allow for execution of a partition relocation operation quickly and efficiently. Efficient partition-split operations with distmap and block range map structures may ensure speedy and efficient partition relocation.

[0049] The partition-split method of the present disclosure may ensure that write requests from in-progress transactions, that involve data on a splitting partition, are allowed to  complete and are not rolled back. Visibility and validity of data modifications from these in-progress transaction may dependent on the outcome of the transactions.

[0050] To determine whether a data element should be available to any specific query, a concurrency control protocol, such as a modified version of the multi-version concurrency control (MVCC) protocol from PostgreSQL Structured Query Language may be used. To maintain data consistency, each query may be associated with a “snapshot” of a current database state. This snapshot may describe a list of transactions (in the form of transaction identification numbers (IDs) , or xids) whose modifications should be seen by this query. Multiple concurrent queries (with varying ages of their snapshot) may be supported by having all the deleted data available: write operations make a new version of the data while storing the old version of the data. Queries may choose which version of the data is relevant to them based on their respective snapshots.

[0051] The table can be organized into rows. Each row of data (called a tuple or a record) may be associated with two Xids: the Xmin and the Xmax. The Xmin is the Xid of the transaction that creates the record (i.e. an insert operation) , and the Xmax is the Xid of a transaction that updates or deletes the record. The Xmax may be empty for a record that has not undergone any update or delete queries. A record, that was not previously updated or deleted, may be described as an active record. A transaction, engaging a record and still receiving inputs from the client, may be aborted. Aborting operations may be restricted to the transactions which are receiving or expecting inputs from the client. A transaction engaging a record, which is (the transaction) ready to commit and no longer requires inputs from the client, may have a waiting period to commit. A record that was updated or deleted may be described as an inactive record. When copying records from a parent partition to a child partition, the active record of the parent partition may have its Xmax changed, and its record location link (tuple location link) modified. A transaction accessing a particular record in the parent partition, which has been copied to the child partition (the particular record has a transfer flag, e.g., TUPLE_TRANSFERRED) , may trigger a next record fetch. The next record fetch may be triggered even if the respective Xmin is not committed, for example, when the in-progress transaction aborts. The next record fetch may be conditioned on successful outcome of a page split. If the in-progress transaction aborts, the fetched record may have a transfer flag and a record location link pointing to the child partition. A next record fetch via the transfer flag may dependent on the Xmax of the page and the page flag. If the page Xmax was aborted, indicating that the operation was invalid, record transactions in the parent partition may proceed as if no transferring (copying) to the child partition has  occurred. A record in the child partition, transferred (copied) from the parent partition may trigger a next record fetch even if its respective Xmin is not committed, for example when the in progress transaction aborts. A record may be visible to a query if its Xmin is visible to the query (according to the query’s snapshot) , and its Xmax (if applicable) is not visible to the query. An Xmin and an Xmax may be associated to a page of data (where the page is a collection of records) . The Xmin and Xmax may indicate whether the entire page should be visible or not, as a result of partition-split or partition-relocation operations.

[0052] The following discloses a blocking-split method that can be applied to an existing partition at a data node. In this embodiment, the existing partition may include a set of records. Each record within the set of records may have a respective partition key. The set of records may be divided into two or more consecutive pages. The process may include applying an exclusive lock to the existing partition and defining a left partition and a right partition. The left partition may have a range defined by a lower bound value of the existing partition and an upper bound value. The upper bound value of the left partition may be determined in accordance with a partition split pivot (PSP) value. The right partition has a range defined by a lower bound value and an upper bound value. The upper bound value of the right partition can be set as the upper bound value of the existing partition. The lower bound value may be determined in accordance with the PSP value, and is typically a function of the determined upper bound value of the left partition. The blocking-split method may further include applying an exclusive lock to each page of the set of records and copying each record of the page to the left partition or the right partition. Each record of the page, copied to the left partition, may have its respective partition key belonging to the range of the left partition. Each record of the page, copied to the right partition, may have its respective partition key belonging to the range of the right partition. Following said copying each record of the page to the left partition or the right partition, one or more records of the page may be associated with respective new record location links, identification numbers of respective record copying transactions (Xmax) and a record transfer mark (RTM) . Said one or more records of the page may be identified as active records of the page.. Following said copying each record of the page to the left partition or the right partition, Xmax of each page may be associated with an ID of a respective current transaction and a page split mark. The blocking-split method may further include releasing the exclusive lock to each page, releasing the exclusive lock of the existing partition, and associating the existing partition with a partition split mark. The blocking-split operation may traverse each page in a data partition and transfer each record to the new partitions. The particular partition that the record is transferred to  depends on the location of the record with respect to a split pivot. The split pivot may be a median value in the partition. Each transferred record may have a flag (e.g. TUPLE_TRANSFERRED) , the value of this flag can be used to indicate whether the record was transferred to a new partition. A record may be relocated regardless of whether the record was recently modified by an in-progress transaction. When future read queries see a record marked as transferred by its transfer flag value, these read queries may follow the link to the next record regardless of the transaction outcome on the record. FIG. 8A illustrates a partition split transfer from parent partition 801 with (–infinity, + infinity) range to child partition 802 with (-infinity, 2) range and child partition 803 with [2, +infinity) range Each record in parent partition 801 is moved to one of child partition 802 or child partition 803 . FIG. 8B illustrates a partition split flow diagram. At action 810, a data node, maintains a partition, e.g., parent partition 801. Parent partition 801 includes a set of records. At least one record of the set of records has an associated record lock preventing execution of at least one operation by an entity other than an entity associated with the record lock. At least one record of the set of records on parent partition 801 has no associated record lock. At action 820 of the process, a decision to split parent partition 801 was taken. At action 830, a shared partition lock is applied to parent partition 801. The shared lock may prevent execution of a partition move operation and / or a partition split operation on parent partition 801. At action 840, each record of parent partition 801 without the associated record lock is copied to child partition 802 or child partition 803. At action 850, the shared partition lock is replaced by an exclusive partition lock. The exclusive partition lock may prevent execution of at least one operation in parent partition 801 by an entity other than the entity associated with the exclusive partition lock. At action 860, each record of parent partition 801, not previously copied, is copied to child partition 802 or child partition 803. At action 870, the exclusive partition lock of parent partition 801 is released.

[0053] The early-split method of the present disclosure may use a two-phase approach to reduce the amount of blocking time in a partition-split operation. The early-split phase may only acquire a SHARED lock on a splitting data partition (referred to in the following discussion as a parent partition) . The lock level may not block other threads from modifying data in the parent partition. This means that while the data is being transferred to new partitions, there may be modification to the data. The early-split phase may try to move cold data to the new partitions. The cold data may be the majority of the data in the parent partition. Records in the parent partition , not associated with any locks indicative of possible edits or updates are referred to as cold data or cold records. When cold records are transferred  to the new partition, their respective xmax and transfer flag value may be updated to indicate that they were transferred due to the partition-split operation. Records in the new partition, transferred from the parent partition, may have their respective Xmax and transfer flag value marked as unavailable and / or set to zero.

[0054] Because the early-split method may be invoked before the partition is filled up with the data, the size constraint on the partition may not be of concern. If the partition is filled up with the data during its early split phase, then transactions trying to add data to the partition may have to wait until the partition split process is completed.

[0055] Hot data is defined by the ability for the partition-split process to acquire a lock on the particular record. A record that is identified as “hot” , will be skipped during an initial phase, as it may be subject to modification until the partition-split process can lock the record. Skipping hot records reduces the amount of blocking and contention. At the end of the early-split phase, there may be a small number of tuples that were skipped due to contention. Another phase of the split process may complete splitting the partition by addressing this hot data. An exclusive lock may be acquired on the partition to prevent future modifications. The partition may be scanned again for any record that was not previously copied or moved. These identified records may be transferred to the new partition using the blocking-split process.

[0056] In some embodiments, a partition relocation operation may be initiated by a coordinator node. When the partition-move operation is invoked, the data may be prepared for relocation to a new data node. Records, engaged by in-progress transactions, may not be relocated. In some embodiments, the in-progress transactions may be forcefully aborted. In other embodiments the partition-move operation may be halted to allow the in-progress transactions to commit or abort. For example, the coordinator may ask the source data node to fetch all the data that is required to be transferred to the new data node. FIG. 9 is a call flow diagram illustrating a partition move, particularly a two phase commit partition move. At action 901, CN 501 sends a request message to DN 401 to fetch partition data (for example, partition data of partition 442) . Responsive to the request message from CN 501, DN 401 fetches the partition data at action 902. At action 903, DN 401 send an acknowledgement message back to CN501. The acknowledgement message includes the partition data. At action 904, CN 501 send a store request to DN 402. The store request includes the partition data. Following receipt of the store request, at action 905, DN 402 stores the partition data in one of its partitions, for example it may be partition 442. At action 906, DN 402 may send a store acknowledgement message to CN 501.

[0057] Partition relocation operations may be treated as a logical delete instruction on the source data node and as a logical insert instruction on the destination data node. To ensure the validity of data being moved across data nodes, only active and visible tuples may be relocated. Active records are the records that are not associated with a valid Xmax value, i.e., a latest version of a record (a tuple) that is not deleted. Because a transaction outcome is stored locally on each data node, it may be very expensive to move data through network communications. When only active records are moved to the new data node, then we can treat all records as a new logical insert.

[0058] Both a source data node and a destination data node may have a copy of the partition. Consequently, while a partition relocation process is initiated and on-going, MVCC read transactions may not be blocked. For a read transaction that only requires the old version of the record, the old version’s snapshot may guide the read transaction to a data access on the source data node. Transactions that require a new version of the record may have to engage the destination data node. FIG. 10 illustrates a partition move between a source data node (DN 401) and a destination data node (DN 402) . Partition 441 with blocks 5 to 8 of DN 401 is moved to DN 402. On DN 402, blocks 5-8 are incorporated in partition 442. After the move, DN401 may eventually clear partition 441 once it has been determined that the data in partition 441 is invisible to everyone.

[0059] To reduce the time required to transfer tuples during a partition split operation some embodiments of this disclosure may use a page-transfer process, transferring data within a partition on the granularity of pages instead of tuples. The page-transfer process removes the overhead of adding records to a new partition one by one. All records offset on a page may be preserved. For example, records on page I of a source partition, transferred in the page-transfer process, will still be on the i-th page in a destination partition, maintaining the same byte offset on the page. Only destination partition numbers will be different between two records if they are on different side of the split pivot (the split median) .

[0060] The page-transfer process takes a copy of all the pages in the old partition and stores the data pages in the new partition. FIG. 11 illustrates a page-transfer between a source partition (partition 1101) and two destination partitions: partition 1102 and partition 1103. Records -42, 3, 0, 11, 2, 7, 5, 1 and -1 on partition 1101 are moved to partition 1102 and partition 1103, based on the split pivot value (the median value) . A partition frees up tuple slots if the tuples do not belong to it. For example, records -1 and -42 of partition 1101 are copied to partition 1102. Records 5 and 11 of partition 1101 are copied to partition 1103.  However, record (tuple) links are still required to be set up as they are critical to record (tuple) visibility resolution.

[0061] FIG. 12 is a schematic diagram of an electronic device 1200 that may perform any or all of operations of the above methods and features explicitly or implicitly described herein, according to different embodiments of the present disclosure. For example, a computer equipped with network function may be configured as an electronic device 1200. Such an electronic device may be used as part of one or more of: a controller, an edge server, a processing device, a bounding region module, an AV, an RSU, etc.

[0062] As shown, the device includes a processor 1210, such as a Central Processing Unit (CPU) or specialized processors such as a Graphics Processing Unit (GPU) or other such processor unit, memory 1220, non-transitory mass storage 1230, I / O interface 1240, network interface 1250, and a transceiver 1260, all of which are communicatively coupled via bi-directional bus 1270. According to certain embodiments, any or all of the depicted elements may be utilized, or only a subset of the elements. Further, the device 1200 may contain multiple instances of certain elements, such as multiple processors, memories, or transceivers. Also, elements of the hardware device may be directly coupled to other elements without the bi-directional bus. Additionally or alternatively to a processor and memory, other electronics, such as integrated circuits, may be employed for performing the required logical operations.

[0063] The memory 1220 may include any type of non`-transitory memory such as static random access memory (SRAM) , dynamic random access memory (DRAM) , synchronous DRAM (SDRAM) , read-only memory (ROM) , any combination of such, or the like. The mass storage element 1230 may include any type of non-transitory storage device, such as a solid state drive, hard disk drive, a magnetic disk drive, an optical disk drive, USB drive, or any computer program product configured to store data and machine executable program code. According to certain embodiments, the memory 1220 or mass storage 1230 may have recorded thereon statements and instructions executable by the processor 1210 for performing any of the aforementioned method operations described above.

[0064] It will be appreciated that, although specific embodiments of the technology have been described herein for purposes of illustration, various modifications may be made without departing from the scope of the technology. The specification and drawings are, accordingly, to be regarded simply as an illustration of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present invention. In particular, it is within the scope of the technology to provide a computer program product or program  element, or a program storage or memory device such as a magnetic or optical wire, tape or disc, or the like, for storing signals readable by a machine, for controlling the operation of a computer according to the method of the technology and / or to structure some or all of its components in accordance with the system of the technology.

[0065] Acts associated with the method described herein can be implemented as coded instructions in a computer program product. In other words, the computer program product is a computer-readable medium upon which software code is recorded to execute the method when the computer program product is loaded into memory and executed on the microprocessor of the wireless communication device.

[0066] Further, each operation of the method may be executed on any computing device, such as a personal computer, server, PDA, or the like and pursuant to one or more, or a part of one or more, program elements, modules or objects generated from any programming language, such as C++, Java, or the like. In addition, each operation, or a file or object or the like implementing each said operation, may be executed by special purpose hardware or a circuit module designed for that purpose.

[0067] Through the descriptions of the preceding embodiments, the present invention may be implemented by using hardware only or by using software and a necessary universal hardware platform. Based on such understandings, the technical solution of the present invention may be embodied in the form of a software product. The software product may be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM) , USB flash disk, or a removable hard disk. The software product includes a number of instructions that enable a computer device (personal computer, server, or network device) to execute the methods provided in the embodiments of the present invention. For example, such an execution may correspond to a simulation of the logical operations as described herein. The software product may additionally or alternatively include number of instructions that enable a computer device to execute operations for configuring or programming a digital logic apparatus in accordance with embodiments of the present invention.

[0068] Although the present invention has been described with reference to specific features and embodiments thereof, it is evident that various modifications and combinations can be made thereto without departing from the invention. The specification and drawings are, accordingly, to be regarded simply as an illustration of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present invention.

Claims

1.A method for supporting scalability of a database, for execution by a data node (DN) of the database, the method comprising:determining that an existing partition should be split into two partitions, the existing partition including a set of records, at least one of the set of records having an associated record lock preventing execution of at least one operation by an entity other than an entity associated with the record lock, and at least one of the set of records having no associated record lock;copying each record without an associated record lock to a left partition or a right partition;copying each record not previously copied to the left partition or the right partition;prior to copying each record without the associated record lock, applying a shared partition lock to the existing partition to prevent execution of at least one of a partition move operation and a partition split operation on the existing partition;following said copying of each record without an associated record lock, replacing the shared partition lock with an exclusive partition lock to prevent execution of at least one operation in the existing partition by an entity other than the entity associated with the exclusive partition lock; andreleasing the exclusive partition lock.2.The method of claim 1, wherein the shared partition lock prevents execution of a partition move operation or a partition split operation by the entity other than the entity associated with the shared partition lock.3.The method of claim 1 to claim 2 further comprising:subsequent to copying of each record without the associated record lock to the left partition or the right partition, associating at least one copied record to a respective record transfer link, an identification number (ID) of a respective record copying operation and a record transfer mark (RTM) .4.The method of claim 3, wherein the at least one copied record is an active record.5.The method of claim 3,wherein, subsequent to applying the shared partition lock, in the existing partition each record without the associated record lock is available to record read operations.6.The method of claim 5,wherein a record read operation of a first record with a snapshot preceding a first record copying operation reads a first record value on the existing partition, andwherein a record read operation of a second record with a snapshot following a second record copying operation reads a second record value in a location indicated by a second record transfer link.7.The method of claim 1 or claim 2 further comprising:subsequent to copying each record not previously copied to the left partition or the right partition, associating at least one record not previously copied to a respective record transfer link, an ID of a respective record copying operation and a record transfer mark (RTM) .8.The method of claim 7, wherein the at least one record not previously copied is an active record.9.The method of claim 1, wherein determining that the existing partition should be split into two partitions includes comparing an amount of unoccupied space within the existing partition to a threshold value.10.The method of claim 9,wherein the existing partition has unoccupied free space, andwherein the existing partition is available to record insert operations.11.The method of claim 1 further comprising:defining the left partition and the right partition.12.The method of claim 1 to claim 2 further comprisingdetermining a split pivot value (SPV) having a value between a lowest record value and a highest record value within an ordering of the set of records within the existing partition.13.The method of claim 12,wherein the left partition has a range defined by a lower bound value of the existing partition and an upper bound value determined in accordance with the SPV, anda right partition has a range defined by a lower bound value determined in accordance with the SPV and an upper bound value of the existing partition.14.The method of claim 1 further comprising:maintaining a logging table,wherein the logging table is a single logging table of the DN.15.The method of claim 14 further comprising:maintaining an index table,wherein the index table is a single index table of the DN.16.The method of claim 1 further comprising:maintaining a block range map (BRM) ,wherein the BRM associates each partition of the DN to a respective logical block range.17.The method of claims 16 further comprising:upon defining the left partition and the right partition, updating the BRM by associating the left partition and the right partition to respective logical block ranges.18.The method of claim 1, wherein each record in the set of records is associated with an identification number (ID) of a respective record insert operation.19.The method of claim 18, wherein at least one record in the set of records is associated with an ID of a respective record logical delete operation.20.The method of claim 1 further comprising:receiving a request to provide data of the existing partition;initiating a discovery operation to discover active records of the set of records;when said discovery operation is successful:defining a set of active records; andsending a response, the response including information indicative of the set of active records,wherein each active record of the set of active records is associated with an ID of a respective record logical insert operation, the respective record logical insert operation is committed, andwherein each active record of the set of active records is not associated with an ID of a respective record logical delete operation or the respective record logical delete operation is aborted.21.The method of claim 20, wherein the discovery operation comprises one of:waiting for the respective record logical insert operation to commit, and waiting for the respective record logical delete operation to commit.22.The method of claim 20, wherein the discovery operation comprises at least one of:waiting for the respective record logical delete operation to abort, and aborting the respective record logical delete operation.23.The method of claim 20,wherein the request to provide data is received from a coordinator node (CN) of the database, andwherein the response is sent to the CN.24.The method of claim 23,wherein the CN comprises a map, andwherein the map of the CN associates the existing partition with the DN.25.The method of claim 20, wherein the discovery operation comprises at least one of:waiting for the respective record logical insert operation to abort, and aborting the respective record logical insert operation.26.The method of claim 20 further comprising:associating the each active record of the set of active records of the existing partition to a record moved mark (RMM) .27.The method of claim 24, wherein, following receipt of the request to provide data, in the existing partition each record without the associated record lock is available to record read operations.28.The method of claim 27,wherein a record read operation of a third record with a snapshot preceding the discovery operation reads a third record value on the DN, andwherein a record read operation of a fourth record with a snapshot following the discovery operation reads a fourth record value on the DN or a fifth record value, a location of the fifth record value is indicated by the map.29.The method of claim 1,wherein the set of records is divided into two or more consecutive pages,wherein each page on the existing partition has a respective offset, andwherein said copying the each record without the associated record lock and said copying the each record not previously copied comprises page based record copying operations.30.The method of claim 29,wherein the each page on the existing partition being copied to a respective destination page on a destination partition, the respective destination page has the respective offset, andwherein the destination partition is the first partition or the second partition.31.The method of claim 30 further comprising:associating the each page with a page split mark and an identification number (ID) of a respective page based record copying operation.32.The method of claim 31, wherein the each page of the set of records is associated with an identification number (ID) of a respective page insert operation.33.A method for supporting scalability of a database, the database having a coordinator node (CN) operationally couple to a data node (DN) and a second DN, the method comprising:by the CN:receiving from the DN information indicative of a left partition and a right partition; andupdating a map of the CN by associating the left partition and a right partition with the DN.34.The method of claim 33 further comprising:sending to the DN a request to provide data of an existing partition on the DN; andreceiving a response to the request to provide data from the DN, the response including information indicative of a set of records.35.The method of claim 34, wherein the map of the CN associates the existing partition to the DN.36.The method of claim 34 further comprising:sending to the second DN a request to store data, the store request includes the information indicative of the set of records, andreceiving from the second DN a response to the request to store data.37.The method of claim 36,wherein the response includes a confirmation of a successful receipt of the information indicative of the set of records and a range of a new partition on the second DN storing the information indicative of the set of records.38.The method of claim 36 further comprising:updating the map of the CN by associating the new partition to the second DN.39.A method for supporting scalability of a database, the database having a second data node (DN) operationally couple to a coordinator node (CN) , the method comprising:by the second DN of the database:receiving from a coordinator node (CN) of the database a request to store data, the request including information indicative of a set of records;storing the information indicative of the set of records; andsending to the CN a confirmation message, the confirmation message confirming a successful receipt of the information indicative of the set of records and a range of a new partition on the second DN storing the information indicative of the set of records.40.The method of claim 39 further comprising:updating a logging table of the second DN and an index table of the second DN.41.The method of claim 40, wherein the logging table of the second DN is a single logging table of the second DN and the index table of the second DN is a single index table of the second DN.42.A data node (DN) apparatus for supporting scalability of a database, the DN apparatus integrated into infrastructure of the database, comprising processing electronics, and configured to:determine that an existing partition should be split into two partitions, the existing partition including a set of records, at least one of the set of records having an associated record lock preventing execution of at least one operation by an entity other than an entity associated with the record lock, and at least one of the set of records having no associated record lock;copy each record without an associated record lock to a left partition or a right partition;copy each record not previously copied to the left partition or the right partition;prior to copying each record without the associated record lock, apply a shared partition lock to the existing partition to prevent execution of at least one of a partition move operation and a partition split operation on the existing partition;following said copying of each record without an associated record lock, replace the shared partition lock with an exclusive partition lock to prevent execution of at least one operation in the existing partition by an entity other than the entity associated with the exclusive partition lock; andrelease the exclusive partition lock.43.The DN apparats of claim 42 further configured to:receive a request to provide data of the existing partition;initiate a discovery operation to discover active records of the set of records;when said discovery operation is successful:define a set of active records; andsend a response, the response including information indicative of the set of active records,wherein each active record of the set of active records is associated with an ID of a respective record logical insert operation, the respective record logical insert operation is committed, andwherein each active record of the set of active records is not associated with an ID of a respective record logical delete operation or the respective record logical delete operation is aborted.44.The DN apparatus of claim 42 or claim 43,wherein the set of records is divided into two or more consecutive pages,wherein each page on the existing partition has a respective offset, andwherein said copying the each record without the associated record lock and said copying the each record not previously copied comprise page based record copying operations.45.A coordinator node (CN) apparatus for supporting scalability of a database, the CN apparatus operationally coupled to a data node (DN) apparatus and a second DN apparatus, the CN apparatus integrated into infrastructure of the database, comprising processing electronics, and configured to:receive from the DN apparatus information indicative of a left partition and a right partition; andupdate a map of the CN apparatus by associating the left partition and a right partition with the DN apparatus.46.The CN apparatus of claim 45 further configured to:send to the DN a request to provide data of an existing partition on the DN apparatus; andreceive a response to the request to provide data from the DN apparatus, the response including information indicative of a set of records.47.A second data node (DN) apparatus for supporting scalability of a database, the second DN apparatus operationally coupled to a coordinator node (CN) apparatus, the second DN apparatus integrated into infrastructure of the database, comprising processing electronics, and configured to:receive from the CN apparatus a request to store data, the request including information indicative of a set of records;store the information indicative of the set of records; andsend to the CN apparatus a confirmation message, the confirmation message confirming a successful receipt of the information indicative of the set of records and a range of a new partition on the second DN apparatus storing the information indicative of the set of records.48.A system for supporting scalability of a database, the system comprising a data node (DN) apparatus, a second DN apparatus, and a coordinator node (CN) apparatus, the DN apparatus, the second DN apparatus, and the CN apparatus are integrated into infrastructure of the database,the system, wherein:the DN apparatus is configured to:determine that an existing partition should be split into two partitions, the existing partition including a set of records, at least one of the set of records having an associated record lock preventing execution of at least one operation by an entity other than an entity associated with the record lock, and at least one of the set of records having no associated record lock;copy each record without an associated record lock to a left partition or a right partition;copy each record not previously copied to the left partition or the right partition;prior to copying each record without the associated record lock, apply a shared partition lock to the existing partition to prevent execution of at least one of a partition move operation and a partition split operation on the existing partition;following said copying of each record without an associated record lock, replace the shared partition lock with an exclusive partition lock to prevent execution of at least one operation in the existing partition by an entity other than the entity associated with the exclusive partition lock; andrelease the exclusive partition lock;the CN apparatus is configured to:receive from the DN apparatus information indicative of a left partition and a right partition; andupdate a map of the CN apparatus by associating the left partition and a right partition with the DN apparatus;the second DN apparatus is configured to:receive from the CN apparatus a request to store data, the request including information indicative of a set of records;store the information indicative of the set of records; andsend to the CN apparatus a confirmation message, the confirmation message confirming a successful receipt of the information indicative of the set of records and a range of a new partition on the second DN apparatus storing the information indicative of the set of records.49.The system of claim 48, wherein the CN apparatus is further configured to:send to the DN apparatus a request to provide data of a partition on the DN apparatus; andreceive a response to the request to provide data from the DN apparatus, the response including information indicative of a set of records.

Images