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.
NoteYou can increase the number of ODP nodes or modify the value of the |
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
NoteThe 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 |
|
| 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. |