Specifications of a single OBServer node
The following table describes the specifications of a single OBServer node that ensures the stable operation of the cluster:
| Configuration |
Maximum requirement |
Minimum requirement |
| CPU |
512C |
4C |
| Memory |
1 TB |
16 GB |
Cluster name length limit
| Item |
Maximum length |
| Cluster name |
128 bytes |
Identifier length limit
MySQL-compatible mode
Oracle-compatible mode
| Item |
Maximum length |
| Username |
64 bytes |
| Tenant name |
63 bytes |
| Database name |
128 characters |
| Table name |
64 characters |
| Partition name |
64 characters |
| Column name |
128 characters |
| Index name |
64 characters |
| View name |
64 characters |
| Alias |
255 characters |
| Table group name |
127 bytes |
| User-defined variable |
64 characters |
| Type |
Maximum length |
| Username |
64 bytes |
| Table name |
128 bytes |
| Column name |
128 bytes |
| Partition name |
64 bytes |
| Index name |
128 bytes |
| View name |
128 bytes |
| Alias |
128 bytes |
| Object name |
128 bytes |
| Table group name |
127 bytes |
Limit on the number of tenants that can be created on a single OBServer node
| Type |
Maximum limit |
| Number of tenants that can be created on a single OBServer node |
The number of tenants is affected by the cluster deployment architecture and hardware. OceanBase Database supports a minimum of 4 GB of memory per tenant. You can calculate the number of tenants based on 4 GB per tenant. |
Limit on the number of connections to OceanBase Database Proxy (ODP)
Maximum number of connections
| Type |
Maximum limit |
| Number of connections to a single ODP |
Controlled by the client_max_connections parameter of ODP. The default value is 8192.
Note
You can increase the number of ODP nodes or modify the value of the client_max_connections parameter to increase the maximum number of connections to the cluster.
|
Limit on the number of connections to a single OBServer node
| Type |
Maximum limit |
| Number of connections to a single OBServer node |
256K |
Limit on the number of replicas of a partition
| Type |
Maximum limit |
| Number of replicas of a partition on each OBServer node |
No strict limit
Note
The number of replicas of a partition on each OBServer node can be estimated based on the tenant memory size. For example, 1 GB of memory supports about 20,000 tablets.
|
Limit on a single table
| Type |
Maximum limit |
| Row length |
1.5M bytes |
| Number of columns |
4096 columns |
| Number of indexes |
128 indexes |
| Total number of columns in a single index |
64 columns |
| Index length |
16K |
| Total number of columns in a primary key |
64 columns |
| Length of a primary key |
16K |
| Number of partitions |
- Oracle-compatible mode: 65536 partitions
- MySQL-compatible mode: 8192 to 65536 partitions
Note
The maximum number of partitions allowed for a single table in MySQL-compatible mode is controlled by the tenant-level parameter max_partition_num. The default value is 8192.
|
| Maximum amount of data supported by a single table |
OceanBase Database supports an unlimited amount of data. According to best practices, we recommend 50 million rows for general scenarios. For wide tables with 100 to 200 columns, we recommend 10 million rows. |
Limit on a single column
| Type |
Maximum limit |
| Length of a single column in an index |
16K |
Limitations on string types
MySQL-compatible mode
Oracle-compatible mode
| Type |
Maximum length |
CHAR |
256 characters |
VARCHAR |
262144 characters |
BINARY |
256 bytes |
VARBINARY |
1048576 bytes |
TINYBLOB |
255 bytes |
BLOB |
65535 bytes |
MEDIUMBLOB |
16777215 bytes |
LONGBLOB |
536870910 bytes |
TINYTEXT |
255 bytes |
TEXT |
65535 bytes |
MEDIUMTEXT |
16777215 bytes |
LONGTEXT |
536870910 bytes |
| Type |
Maximum length |
CHAR |
2000 bytes |
NCHAR |
2000 bytes |
VARCHAR |
32767 bytes |
VARCHAR2 |
32767 bytes |
NVARCHAR2 |
32767 bytes |
BLOB |
536870910 bytes |
CLOB |
536870910 bytes |
Limitations on transaction size
OceanBase Database supports transactions of any size, provided that there is enough storage space.
Limitations on weakly consistent read latency
The weakly consistent read latency supported by OceanBase Database is controlled by the tenant-level parameter max_stale_time_for_weak_consistency. The default value is 5 seconds. The minimum latency is 5 seconds, which allows you to read the latest data.
Limitations on clogs
| Type |
Limit |
| Size of a single clog entry |
3.5 MB |
| Maximum network latency for clog synchronization |
The maximum network latency for clog synchronization is 1 second. The one-way network latency between the arbitration service and the OceanBase cluster nodes is less than or equal to 800 ms. |
Limitations on feature usage
Shared storage
For OceanBase clusters in Shared-Storage (SS) mode in the current version, the following limitations apply:
- Multi-region deployment is not supported.
- Columnar storage engine is not supported.
- Physical standby databases are not supported.
- Shrinking the data_disk_size of a tenant is not supported.
- The number of partitions cannot exceed 100,000.
Physical standby databases
The following table describes the limitations on physical standby databases.
| Limitation |
Description |
| Maximum number of standby tenants supported by a primary tenant |
The number of standby tenants supported by a primary tenant is not limited in the product. However, the synchronization of standby tenants consumes CPU, memory, I/O resources, and network bandwidth of the primary tenant. Therefore, we recommend that you determine the number of standby tenants based on the resource usage of the source tenant and the actual business requirements. |
| Whether the primary and standby tenants must have the same resource specifications |
The primary and standby tenants do not need to have the same resource specifications. We recommend that you use the same resource specifications for the primary and standby tenants. |
| Parameters |
The parameters of the primary and standby tenants are independent of each other and are not physically synchronized. If you modify the parameters of the primary tenant, you need to evaluate whether to modify the same parameters of the standby tenant. |
| System variables |
The system variables of the primary and standby tenants are physically synchronized. If you modify the system variables of the primary tenant, the system will synchronize the modification to the standby tenant. |
| Users and passwords |
You can create users and modify user passwords only in the primary tenant. The updated information will be synchronized to the standby tenant. |
| Read and write operations |
The standby tenant supports read operations but does not support write operations. |
| Minor compactions and major compactions |
The minor compactions of the primary and standby tenants are relatively independent.
The standby tenant synchronizes the major compaction information from the primary tenant. Independent major compactions are not supported. |
| Switchover limitations |
All replicas of the standby tenant's log stream must be online. |
| Failover limitations |
All replicas of the standby tenant's log stream must be online. |
| Optimizer statistics |
The standby tenant does not collect statistics. The statistics of the standby tenant are synchronized from the primary tenant. |
