Note Check the solidDB Release Notes for any limitations that are associated with using a grid in the current release.
By partitioning tables across multiple servers, you increase the ability for data to be accessed concurrently and so exceed the scalability that is provided by a single database server.
Partitioning means that the table is split into multiple partitions, which are distributed between the grid nodes. Replica copies of the partition (replication units) are stored on different nodes in the grid. The replication units for a partition form a replication group. One replication unit in the group is the primary replication unit where all updates to tables are performed. The other replication units can service only read operations.
When a row is inserted into a partitioned table, the grid-aware driver resolves the target partition for the row and stores the row in the node that hosts the primary replication unit for that partition, see Determining where the data is stored.
A partitioned table is created by defining a replication factor and partitioning key for the table.
Replication factor
The number of replication units in a replication group is controlled by the replication factor.
For example, with a replication factor of 3, there are three replication units in each replication group, meaning that each table partition is available on three nodes in the grid.
Partitioning key
The partitioning key is an attribute that determines the partition in which each row is stored. Although you cannot specify the nodes on which a specific partition is hosted, rows that have the same partitioning key value are stored in the same partition.
A table can have only one partitioning key, which is defined in the following way:
▪ If the table does not have a primary key, any column or combination of columns can be used as the partitioning key.
▪ If the table does have a primary key, the partitioning key must be the primary key or the first attribute or attributes (in order of precedence with no attributes missing) of the primary key.
For example:
CREATE TABLE MYTABLE ( ci VARCHAR NOT NULL, i INTEGER NOT NULL, j INTEGER NOT NULL, data VARCHAR, PRIMARY KEY (ci, i, j)) PARTITION BY (ci, i) REPLICATION FACTOR 3;
Note that PARTITION BY (ci) or PARTITION BY (ci, i, j) would also be valid definitions for a partitioning key for the specified table definition, but PARTITION BY (ci, j), or PARTITION BY (i, ci) would not be valid.
Although it is possible to use a non-unique table column as the partitioning key, or even a column that allows NULL values, this could lead to a non-uniform data distribution if the partitioning key column has only a few different values. For example, table rows that have NULL values in the partitioning key would all be stored in the same partition.
If you are partitioning parent and child tables, you can configure the tables so that the child rows are stored in the same partition as the parent row, see Keeping related data on the same grid node.