Notice
The columnstore replica feature is still under experiment. We recommend that you do not use it in a production environment, to avoid impact on system stability.
A columnstore replica is similar to a read-only replica. It does not participate in leader election or log voting and consists of an SSTable, commit logs (clogs), and a MemTable. In a columnstore replica, the baseline data of the user table is stored in columnar storage mode. Here, the user table can be a replicated table, but not an index table, internal table, or system table.
A columnstore replica has the following characteristics:
Contains full logs, a MemTable, and an SSTable.
Cannot join a Paxos group or participate in log voting as a member of the Paxos group. Instead, it works as a listener that synchronizes logs from the Paxos group members and then locally replays the logs. It does not act as a voting member and therefore causes no latency in transaction commits.
Provides read-only services if an application does not require strong-consistency reads.
Stores user tables in the same log stream in columnar storage mode at the major SSTable layer.
Cannot be converted into a replica of another type.
The following table describes more features of such a replica.
| Feature | Description |
|---|---|
| Replica name and abbreviation | COLUMNSTORE (C) |
| Whether logs are contained | It has asynchronous logs. It is only a listener instead of a member of the Paxos group (ASYNC_CLOG). |
| Whether a MemTable is contained | Yes (WITH_MEMSTORE) |
| Whether an SSTable is contained | Yes (WITH_SSSTORE) |
| Data security | Medium |
| Time to become the leader | Not supported |
| Resource cost | High |
| Service | Supports non-consistent read. |
| Limitations on replica type conversion | Cannot be converted into a replica of another type |
Considerations
Take note of the following considerations when you use columnstore replicas:
We recommend that you do not deploy more than one columnstore replica.
For your query to be routed to a columnstore replica, set ob_route_policy to
COLUMN_STORE_ONLYand configure weak-consistency read for the corresponding session or query. Otherwise, an error occurs.For more information about how to configure weak-consistency read, see Weak-consistency read.
Accessing a columnstore replica requires an independent OceanBase Database Proxy (ODP). Therefore, we recommend that you deploy only columnstore replicas in a zone with columnstore replicas.
Queries to a full-featured or read-only replica cannot be forwarded to a columnstore replica. Queries to a user table in a columnstore replica cannot be forwarded to a full-featured or read-only replica either. Otherwise, an error occurs.
In a cluster with a columnstore replica, DDL operations affect the usage of resources such as CPU, memory, disk, and I/O.
The major compaction of columnstore replicas is slower than that of full-featured or read-only replicas. You cannot initiate a new round of tenant-level major compaction until the major compaction of columnstore replicas is completed. Before manually initiating a major compaction, check the CDB_OB_ZONE_MAJOR_COMPACTION or DBA_OB_ZONE_MAJOR_COMPACTION view to confirm whether the previous round of major compaction of all replicas is completed.
For more information, see View major compaction information.
Physical restore does not support columnstore replicas. If you specify a columnstore replica in the locality of a tenant, the restore fails.
If no columnstore replica is deployed for the primary database, we recommend that you do not deploy a columnstore replica for the standby database.