Machine specifications of a single OBServer node
The following table describes the machine specifications of a single OBServer node that ensures the stability of the cluster.
| Configuration |
Maximum requirement |
Minimum requirement |
| CPU |
512 cores |
4 cores |
| Memory |
1 TB |
16 GB |
Cluster name length
| Item |
Maximum length |
| Cluster name |
128 bytes |
Identifier length
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 |
| Item |
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 |
Number of tenants can be created on a single OBServer node
| Item |
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. |
OceanBase Database Proxy (ODP) connections
Maximum number of connections
| Item |
Maximum limit |
| Number of connections per ODP node |
The maximum number of connections is 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 of the cluster.
|
Connections of a single OBServer node
| Item |
Maximum limit |
| Number of connections per OBServer node |
256K |
Number of partition replicas
| Item |
Maximum limit |
| Number of partition replicas per OBServer node |
No strict limit
Note
The number of partition replicas per OBServer node can be estimated based on the tenant memory size. For example, 1 GB of memory can support about 20,000 tablets.
|
Single table
| Item |
Maximum limit |
| Row length |
1.5M bytes |
| Number of columns |
4,096 columns |
| Number of indexes |
128 indexes |
| Total number of columns in a single index |
64 columns |
| Index length |
16 KB |
| Total number of columns in a primary key |
64 columns |
| Length of a primary key |
16 KB |
| Number of partitions |
- In Oracle-compatible mode: 65,536 partitions
- In MySQL-compatible mode: 8,192 to 65,536 partitions
Note
In MySQL-compatible mode, the maximum number of partitions for a single table is specified by the tenant-level parameter max_partition_num. The default value is 8,192.
|
| Maximum amount of data supported by a single table |
OceanBase Database does not have a limit on the amount of data it can support. According to best practices, we recommend 50 million rows for general scenarios. For wide tables with 100 to 200 columns, we recommend up to 10 million rows. |
Single column
| Item |
Maximum limit |
| Length of a single column in an index |
16 KB |
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 |
Transaction size
Theoretically, OceanBase Database supports unlimited transaction sizes, restricted only by the available storage space.
Weak consistent read latency
The weak consistency read latency supported by OceanBase Database is controlled by the tenant-level parameter max_stale_time_for_weak_consistency. The default value is 5s, meaning the latest data can be read with a minimum latency of 5s.
Clogs
| Item |
Limit |
| Size of a single clog log |
3.5 MB |
| Maximum network latency for clog log synchronization |
The maximum network latency for clog log synchronization is 1 second, but the one-way network latency between the arbitration service and the OceanBase cluster nodes is less than or equal to 800 ms. |
Feature usage
Shared storage
In the current version, for OceanBase clusters in shared-storage (SS) mode, 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 lists the limitations on physical standby databases.
| Item |
Description |
| Maximum number of standby tenants supported by a single primary tenant |
The number of standby tenants supported by a single primary tenant is not limited at the product level. However, since standby tenants consume CPU, memory, I/O resources, and network bandwidth from the primary tenant, it is recommended to determine the number of standby tenants based on the resource usage of the source tenant and actual business needs. |
| Whether the primary and standby tenants require identical resources |
The primary and standby tenants do not require identical resources. It is recommended to use the same resource specifications for the primary and standby tenants. |
| Parameters |
The parameters of the primary and standby tenants are independent and are not physically synchronized. If the parameters of the primary tenant are modified, assess whether the same parameters of the standby tenant need to be modified. |
| System variables |
The system variables of the primary and standby tenants are physically synchronized. If the system variables of the primary tenant are modified, the system will synchronize the same system variables to the standby tenant. |
| Users and passwords |
Users can only be created and passwords can only be modified on 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 |
Minor compactions of the primary and standby tenants are relatively independent.
The standby tenant synchronizes major compaction information from the primary tenant and does not support independent major compactions. |
| 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. |
