Introduction to Table Partitions and Storage Groups
A table partition is an attribute that can be associated with an SQL table. The partition contains a subset of the row versions that are stored on and serviced by a storage group. The subset stored in the partition is governed by a partitioning policy. A partitioned table must contain at least one table partition and may contain multiple table partitions. Table partitions are associated with SQL tables by specifying partition criteria. Each partition within a table has a uniquely identified name that maps to one storage group.
NuoDB uses two levels of mapping between a version of a row in a horizontally partitioned table and physical storage. The first mapping level uses table partitioning which provides the ability to map a table partition, which contains a version of a row, to exactly one symbolic storage group name. The second mapping level assigns a storage group, a logical storage unit, to one or more SMs in the database.
A storage group represents a logical storage unit that can be serviced by multiple Storage Managers (SMs) in a database.
A storage group is referenced by a symbolic identifier that uniquely identifies a storage group within the database. These symbolic identifiers allow table partitioning policies to reference a symbolic name as opposed to a static storage location.
The storage group to SM assignments provide the flexibility to dynamically change the mapping to accommodate database operational requirements without a service interruption. The relationship between storage groups and SMs is a many-to-many mapping, that is, a storage group can be serviced by one or more SMs. In addition, an SM may service one or more storage groups.
For information on adding storage groups, see Managing Storage Groups.
The following are the two predefined storage groups:
UNPARTITIONEDstorage group is automatically created with the database and cannot be deleted. Every SM always services the
UNPARTITIONEDstorage group and this cannot be changed. Any table or a row in a table that does not have a partition defined, is stored in the
UNPARTITIONEDstorage group. Thus, if you do not partition your tables, all the data in the database will be stored in the
UNPARTITIONEDstorage group and any other storage groups that are created will have no data in them.
If an SM serves the
ALLstorage group then it automatically and unconditionally serves all storage groups. You cannot store a partition or table in the
Table partitions allow you to store the data being inserted in one or more storage groups in the database, based on the value of a column in that row.
For example, a simple table partitioning use case would be a table containing user data that is partitioned based on the user’s zip code column.
The inserted data is stored into table partitions that map to storage group names that represent the geographical storage location near the zip code of the row being inserted.
Then the storage groups are fulfilled by assigning SMs that are located in those geographical locations, for example, the
USWEST storage group is serviced by an SM located in San Diego, CA and the
USEAST storage group is serviced by an SM located in Cambridge, MA.
An unpartitioned table can be partitioned under the following circumstances:
1. Only range-style partitioning is supported.
2. All unique indexes must contain the partitioning column or an autogenerated column.
The resulting partitioned table will have a first partition that contains all the data from the original table, including existing indexes.
A table can be partitioned using the following syntax:
ALTER TABLE [table] MODIFY PARTITION BY RANGE (column_name) [STORE IN default_storage_group] PARTITION partition_name VALUES LESS THAN (literal | MAXVALUE) [STORE IN storage_group]
See ALTER TABLE for more information and examples.