Skip to main content
When setting up an System, a storage cluster represents a set of Foundation Nodes in the system. A storage space is a set of parameters within a storage cluster that defines how the system administers data and fault tolerance. Creating a storage space is an important step for launching an Ocient System that must be done after installing hardware and bootstrapping nodes, but before you start loading and querying data. To see how creating a storage space fits into the Ocient installation process, see Ocient Application Configuration. This tutorial explains how to set up and configure storage spaces to meet the needs of your Ocient System.
OcientAIQ Unified Data Platform contains Foundation Nodes in segments grouped into segment groups that are grouped into storage clusters. Tables in schemas with metadata are stored in segments.
When an Ocient System starts, the system automatically creates a default system storage space for persistent metadata, such as system catalog tables. This default storage space is immutable, meaning you cannot delete or modify it.The name of the metadata storage space is systemStorageSpace in the sys.storage_spaces system catalog table.

​
User-Defined Storage Spaces

For storage other than metadata, you must create one or more separate storage spaces. The creation of storage spaces is necessary before loading data or performing other operations. User-defined storage spaces are configurable for extra resiliency or storage based on your system needs. A storage space represents how the storage cluster spreads data across Foundation Nodes to balance storage and fault tolerance. In general terms, the storage cluster configuration defines how the storage cluster behaves for these attributes: You can configure a storage space to assign nodes to these job roles by using DDL statements (see CREATE STORAGESPACE). Planning out your storage space carefully is important because you cannot change a storage space configuration after creation.

​
Segment Group Width

Storage space parameter: WIDTH The Segment Group Width determines the number of segments that comprise a segment group. Functionally, this setting defines how many Foundation Nodes perform read and write operations for a segment group. Within a Segment Group, the system assigns each segment to a different node. Hence, the Segment Group Width cannot exceed the number of nodes in your system. In most circumstances, Segment Group Width should comprise most of your Foundation Nodes. On system startup, the default Segment Group Width is three, which is the minimum number of nodes required for an Ocient System.

​
Parity Width

Storage space parameter: PARITY_WIDTH You can assign a subset of the Segment Group Width to Parity Width. The Parity Width of a storage space determines its fault tolerance, defining the number of parity coding bits to use for each segment group. This number determines how many nodes can fail before the cluster is disabled. Parity Width protects system querying capabilities. If any nodes fail, the system can execute and complete queries as long as the number of failed nodes is less than or equal to the Parity Width. When deployed in conjunction with overprovisioned nodes, Parity Width also provides fault tolerance for loading operations. The PARITY WIDTH requires additional storage overhead, which is calculated by the formula (PARITY WIDTH) / (SEGMENT GROUP WIDTH - PARITY WIDTH).

​
Overprovision

The Ocient System overprovisions any Foundation Nodes in the cluster in excess of the Segment Group Width by default. These nodes can include any nodes not configured in the storage space or any nodes added later. Overprovisioned nodes protect loading operations from node failure, although they must be used in conjunction with Parity Width. In the event of node failures, loading operations can continue as long as the number of failed nodes does not exceed the Parity Width nodes or the number of overprovisioned nodes. For this reason, providing fault tolerance for loading requires a balance of Parity Width and overprovisioned nodes. Unlike Segment Group Width and Parity Width, you do not explicitly define a value for overprovisioning. Instead, any Foundation Nodes in the cluster in excess of the number allocated toward Segment Group Width or Parity Width become overprovisioned by default.

​
Storage Space Configuration Examples

This section demonstrates different configurations for storage spaces. The examples each go through different scenarios for node failures to show the fault tolerance of each setup. For information on the syntax for storage spaces, see CREATE STORAGESPACE.

​
10-Node Cluster

This example assumes you have a storage cluster of 10 Foundation Nodes.
SQL
CREATE STORAGESPACE ocient WIDTH = 10, PARITY_WIDTH = 2;
  • The WIDTH = 10 parameter means the system stores a segment group on 10 different nodes.
  • The PARITY_WIDTH = 2 parameter means each segment in the group contains enough parity bits to restore lost data for up to two nodes. In effect, this means parity bits comprise 20 percent of storage.
Tolerance Scenarios This storage space setup has no overprovisioning, making loading operations less resilient. This setup results in these outcomes if nodes become disabled:
  • If one node fails, loading fails, and querying can continue.
  • If two nodes fail, loading fails, and querying can continue.
  • If three nodes fail, loading and querying both fail.

​
12-Node Cluster

This example assumes a storage cluster of 12 Foundation Nodes.
SQL
CREATE STORAGESPACE ocient WIDTH = 10, PARITY_WIDTH = 2;
Note that this DDL statement is the same as the 10-Node Cluster Example, but the cluster in this example has two additional nodes.
  • The WIDTH = 10 parameter means the system stores a segment group on 10 of the 12 nodes.
  • The two remaining nodes are overprovisioned.
  • The PARITY_WIDTH = 2 parameter means each segment in the group contains enough parity bits to restore lost data for up to two nodes. In effect, this means parity bits comprise 16.6 percent of storage.
Tolerance Scenarios This setup provides a level of resiliency for both querying and loading. The setup results in these outcomes if nodes become disabled:
  • If one node fails, loading and querying continues.
  • If two nodes fail, loading and querying continues.
  • If three nodes fail, loading and querying both fail.

​
12-Node Cluster with More Parity Width

This example assumes a storage cluster of 12 Foundation Nodes with more nodes allocated to parity.
SQL
CREATE STORAGESPACE ocient WIDTH = 10, PARITY_WIDTH = 3;
  • The WIDTH = 10 parameter means the system stores a segment group on 10 of the 12 nodes.
  • The two remaining nodes are overprovisioned.
  • The PARITY_WIDTH = 3 parameter means each segment in the group contains enough parity bits to restore lost data for up to three nodes. In effect, this means parity bits comprise 42 percent of storage.
Tolerance Scenarios This setup provides resiliency for loading and especially for querying. The setup results in these outcomes if nodes become disabled:
  • If one node fails, both loading and querying continue.
  • If two nodes fail, both loading and querying continue.
  • If three nodes fail, loading fails, and querying continues.
  • If four nodes fail, both loading and querying fail.

​
15-Node Cluster

This example assumes a cluster of 15 Foundation Nodes. The configuration in this setup includes five overprovisioned nodes, exceeding the Parity Width nodes. This number of overprovisioned nodes would be inefficient and unable to provide the full benefit in a real system, but this example demonstrates what happens if you added extra nodes at a later time to a cluster, which the storage space would recognize as overprovisioned.
SQL
CREATE STORAGESPACE ocient WIDTH = 10, PARITY_WIDTH = 3;
  • The WIDTH = 10 parameter means the system stores a segment group on 10 of the 15 nodes.
  • The five remaining nodes are overprovisioned.
  • The PARITY_WIDTH = 3 parameter means each segment in the group contains enough parity bits to restore lost data for up to three nodes. In effect, this means parity bits comprise 20 percent of storage.
Tolerance Scenarios This setup provides resiliency for both querying and loading, but having more than three overprovisioned nodes provides no benefit because it exceeds three Parity Width nodes. This setup results in these outcomes if nodes become disabled:
  • If one node fails, loading and querying continue.
  • If two nodes fail, loading and querying continue.
  • If three nodes fail, loading and querying continue.
  • If four nodes fail, loading and querying both fail because this breaches the Parity Width tolerance.
Core Elements of an Ocient System Cluster and Node Management

​

Last modified on May 27, 2026