FAQs

Frequently asked questions about the architecture and features of the product

Do I need one or multiple instances?

If multiple subsystems are deployed and they do not interact at the database level, it is recommended to use different instances for the subsystems.

How do users access OceanBase Database?

OceanBase Database provides an SQL interface. Users can access and operate the database through SQL statements.

Does OceanBase Database support Java Persistence API (JPA)?

Java Persistence API (JPA) is a set of Object Relational Mapping (ORM) specifications in Java standards. With JPA, you can describe the mappings between objects and relational tables through annotations or XML files, and persist entity objects to a database (which means mapping the Object Model to the Data Model). OceanBase Database is a native distributed relational database independently developed by Alibaba and Ant Group. It does not build on any open-source product. Therefore, there is no conflict between OceanBase Database and JPA.

What level of database management do data files belong to?

At present, OceanBase Database has two types of data files, both of which belong to the cluster level:

• Data files: These files store data of all partitions, including the checkpoint data of all partitions.
• clog-related files: These files contain clogs (also known as redo logs or write-ahead logs, or WAL logs) and their index files.

How does OceanBase Database support HTAP?

OceanBase Database has a distributed computing engine that allows multiple computing nodes to run OLTP applications and complex OLAP applications simultaneously. This enables OceanBase Database to use one computing engine to support mixed workloads. With OceanBase Database, you can use one system to resolve 80% of your issues and make full use of your computing resources, thus avoiding the need to purchase additional hardware resources or software licenses.

What are instances and tenants, and what is the relationship between them?

OceanBase Database is a multi-tenant system. An instance is a tenant in OceanBase Database. Data cannot be accessed between tenants.

What is the relationship between the number of servers and the performance of OceanBase Database?

The TPC-C report of OceanBase Database shows that the system performance generally improves linearly with an increase in the number of servers.

What should I pay attention to when I use OceanBase Database for development?

Here are some points to consider during development:

• Pay special attention to memory usage when importing a large amount of data.
• If you want the index to take effect quickly, we recommend that you include the index statement when you create a table.
• We recommend that you use mysql-connector-java 5.1.30 or later.
• When you modify the column type, keep the length of the varchar type the same or increase it.
• If a connection is idle for more than 15 minutes, the server will proactively disconnect the connection. When you use a connection pool, set the maximum idle time of a connection. For example, in the minEvictableIdleTimeMillis configuration of the Druid connection pool, set this parameter to less than 15 minutes.

How does OceanBase Database achieve higher compression and lower space usage compared with traditional databases?

OceanBase Database uses data encoding, a compression technique that is tailored for data. Data encoding generates a series of encoding methods based on the value ranges and types of fields in a relational table in the database. These encoding methods enable higher compression efficiency for the database.

How much data is required for AP capabilities of OceanBase Database?

The amount of data is not limited. You can apply AP to scenarios involving 100 GB or several PB of data. AP is an ability provided by OceanBase Database. You can configure a smaller degree of parallelism for a smaller amount of data and a larger degree of parallelism for a larger amount of data. This way, parallelism can adapt to different data scales without limiting the maximum data scale.

What level of standard SQL support does OceanBase Database have in the latest version?

Most business applications in MySQL mode can be smoothly migrated with no modifications or only slight modifications. Oracle mode of OceanBase Database supports most basic Oracle features. You can smoothly migrate your applications from Oracle databases to OceanBase Database with slight modifications.

What is the cost of migrating business running on MySQL databases to OceanBase Database?

OceanBase Database is compatible with general MySQL features and frontend and backend protocols. Therefore, you can migrate your business from MySQL databases to OceanBase Database with zero or slight modifications.

How is the AP computing capability of OceanBase Database?

AP in OceanBase Database uses hybrid row-column storage, compilation-based execution, vectorized processing, cost-based query rewriting, and optimization. In addition, OceanBase Database boasts excellent scalability. These advantages endow OceanBase Database with outstanding real-time analysis capabilities in AP. For offline big data processing, Spark and other big data solutions are a better choice.

When you connect a business application to OceanBase Database as a distributed database, is it different from connecting to a traditional database?

As a distributed database, OceanBase Database can deploy multiple replicas across servers. To minimize cross-server data access, OceanBase Database provides obproxy. As a dedicated reverse proxy server for OceanBase Database, obproxy offers high-performance and high-accuracy routing and forwarding services to frontend user requests and provides high availability and scalability to backend servers. Compared with proxy servers in other databases, obproxy adopts an asynchronous framework and stream-based forwarding based on the characteristics of standalone environments and multi-cluster deployment of OceanBase Database. Additionally, obproxy uses a memory solution based on FastParse and LockFree, which means it can process millions of QPS with limited resources and offers convenient O&M support with extensive deployment.

What are the technical features of OceanBase Database's architecture?

As a native distributed database, OceanBase Database has the following technical features:

• Elastic scaling

  OceanBase Database supports online elastic scaling. When the storage capacity or processing capability of a cluster is insufficient, you can add new OBServer nodes to the cluster. The system automatically migrates data and distributes appropriate partitions to the new nodes based on the processing capability of each node. Similarly, when the system capacity and processing capability are abundant, you can remove nodes to reduce costs. For example, during the Double 11 Grand Sale, the database can provide excellent elastic scaling capabilities.

• Load balancing

  OceanBase Database manages multiple OBServer nodes in an OBServer cluster to provide data services to multiple tenants. All OBServer nodes managed by OceanBase Database can be regarded as a large "resource cake". Resources are allocated to the tenants as needed from the resource pool. The load balancing feature of OceanBase Database ensures that resources are occupied relatively evenly among multiple tenants in the OBServer cluster. Even in dynamic scenarios, such as the addition or deletion of OBServer nodes or tenants or data partition imbalances during partition addition or deletion, the load balancing algorithm can still balance resources among existing nodes.

  OceanBase Database uses the Root Service to manage the load balancing among nodes. Different types of replicas have different resource requirements. When the Root Service performs partition management operations, it considers the CPU, disk, memory, and IOPS usage of each OBServer node. The Root Service ensures that partitions are not all allocated to a few OBServer nodes, leaving other OBServer nodes idle. Moreover, the Root Service aims to put memory-consuming replicas and memory-efficient replicas on the same OBServer node and to put disk-space-consuming replicas and disk-space-efficient replicas on the same OBServer node. After load balancing, the various types of resources on all OBServer nodes are relatively balanced, making full use of all resources on each OBServer node.

• Distributed transaction ACID feature

  The ACID feature of transactions in OceanBase Database is implemented as follows:

  • Atomicity: The snapshot transaction's atomicity is ensured by the two-phase commit protocol.
  • Consistency: The consistency of the transaction is ensured.
  • Isolation: The concurrency is controlled by the MVCC mechanism.
  • Durability: The transaction logs use the Paxos protocol to synchronize data to multiple replicas.

• High availability

  Each partition in OceanBase Database maintains multiple replicas. Log synchronization between these replicas is achieved through the Paxos protocol. Each partition and its replicas form an independent Paxos group, with one of the replicas serving as the leader and the others as followers. Some partitions of an OBServer node serve as leaders, and the remaining partitions serve as followers. If the OBServer node fails, the partitions that serve as followers are not affected. The write service of the partitions that serve as leaders is interrupted for a short time. Then, a follower is elected as the new leader through the Paxos protocol. This process takes no more than 30s. The Paxos protocol ensures high availability and performance in scenarios of data consistency.

  In addition to the Paxos protocol, OceanBase Database also supports the primary/standby database architecture. The multi-replica mechanism of an OceanBase cluster provides disaster recovery capabilities at the node, Internet data center (IDC), and region levels. In the case of failures at the node, IDC, or region level, the system automatically switches to a standby IDC or region without losing data (RPO = 0). If the primary cluster becomes unavailable due to planned or unplanned outages (failure of the majority of replicas), the standby cluster takes over the services. It offers lossless switchover (RPO = 0) and lossy switchover (RPO > 0) disaster recovery capabilities to minimize the service interruption time.

  OceanBase Database allows you to create, manage, and monitor one or more standby clusters. A standby cluster is a hot backup of the production database. You can allocate resource-intensive reporting operations to a standby cluster to improve system performance and resource utilization.

• Efficient storage engine

  The storage engine of OceanBase Database is built on the LSM-tree architecture. Data in the storage engine is stored in MemTables (also known as MemStores) and SSTables. MemTables are read/write, whereas SSTables are read-only. User-inserted/deleted/updated data is first written to MemTables. Transactions are ensured by redo logs. Paxos is used to synchronize redo logs among three replicas. When a server node fails, the data integrity is ensured by Paxos, and the high availability of data is ensured by a short recovery time.

  When the size of a MemTable exceeds the specified threshold, the data in the MemTable is flushed to a Mini SSTable to release the memory space. This process is called a mini compaction. As user data is written, the number of Mini SSTables increases. When the number of Mini SSTables exceeds the specified threshold, the system automatically triggers a minor compaction in the background. A mini compaction generates a new Mini SSTable. A major compaction is initiated when the number of mini compactions exceeds the specified threshold or during off-peak hours of a day. In a major compaction, the baseline SSTables (Major SSTables) and incremental SSTables (Mini/Minor SSTables) are merged into a new Major SSTable. OceanBase Database optimizes the data storage space through mini and major compactions, providing efficient read and write services, ensuring transactionality, and data integrity.

• Multi-tenant

  OceanBase Database is a distributed database that supports the multi-tenant feature. One cluster can serve multiple business systems.

  The multi-tenant architecture makes it possible to make full use of system resources. The same resources can serve more business lines. Business systems with different resource requirements can be deployed in one cluster. This ensures the isolation between tenants in applications and prevents data access across tenants, thus protecting user data assets from leakage. In addition, front-end applications that use the same tenant have consistent response time and transaction processing capacity (TPS/QPS), regardless of the load on other tenants.

• Oracle and MySQL compatibility

  OceanBase Database supports Oracle-compatible mode and MySQL-compatible mode. You can choose the appropriate mode based on your business needs.

Memory FAQs

What memory areas are included in OceanBase Database?

OceanBase Database includes the following memory areas:

• kv cache: the cache for SSTables and database tables in the LSM-tree.
• memory store: the memory of MemStores in the LSM-tree.
• sql work area: the memory used by operator work areas during SQL execution. When the memory is insufficient, the data is written to disk.
• system memory: memory reserved for network I/O, disk I/O, elections, load balancing, and other purposes.

Which resources in a tenant are shared and which are not?

In a tenant, the sql work area, memory store, and kv cache are dedicated resources; the system memory is shared among tenants. The sql worker threads are isolated between tenants; the net I/O, disk I/O, and clog writer threads are shared among tenants.

What are the memory usage characteristics of OceanBase Database?

When OceanBase Database starts, it needs to load about several GB of memory. During operation, it gradually requests more memory as needed until the memory_limit is reached. After an OBServer node requests memory from the OS, the memory is typically not released back to the OS even if it is not used, but is maintained in the used memory list and Free List for memory management. This memory management mechanism is designed in OceanBase Database.

Is it normal for the memory usage of OceanBase Database to approach memory_limit after it has run for a while?

If an OceanBase cluster runs for a long time, it is expected that the memory usage will approach and stay around the memory_limit value.

One exception is that if the parameter memory_chunk_cache_size is set, the OBServer node will attempt to return memory chunks exceeding memory_chunk_cache_size in the Free List to the OS. This increases the reuse rate of the Free List within OceanBase Database and reduces the risk of RPC timeouts caused by slow memory operations. Generally, there is no need to configure memory_chunk_cache_size. In specific scenarios, it is necessary to conduct a scenario analysis with OceanBase Database support to determine whether dynamic adjustment of memory_chunk_cache_size is required.

Can the memory upper limit of an OBServer node be dynamically adjusted?

Yes. You can dynamically adjust the memory_limit or memory_limit_percentage to change the memory upper limit of an OBServer node. However, before you adjust the parameters, make sure that the available memory resources are sufficient and the target memory upper limit is not lower than the total memory allocated (at the time of tenant creation) to all tenants and 500 tenants. The unit of memory_limit is MB. For example, to set the memory upper limit of an OBServer node to 64 GB, you can use the memory_limit ='64G' or memory_limit = 67108864 parameter setting.

If you set the memory_limit to 0, you can use the memory_limit_percentage to flexibly limit the memory usage of the OBServer node in percentage.

Is memory overallocation allowed when you define resource units and a resource pool in OceanBase Database?

In OceanBase Database, the Root Service is responsible for allocating resources (units). When the Root Service allocates a unit, it determines whether to overallocate memory based on the resource_hard_limit parameter (resource_hard_limit indicates the percentage of memory overallocation. A value greater than 100 indicates that overallocation is allowed). The Root Service then allocates resources to the unit based on the defined resource units.

However, if the resources are relatively tight, the system allows controlled resource contention among different tenants. When you configure a tenant, CPU resources can be overallocated. If CPU overallocation takes effect, when the workload of the OceanBase cluster increases, load overruns can occur, causing competition for CPU resources among tenants. The result is that the business scenarios of tenants slow down. If memory is overallocated, the total memory of the tenants can exceed the memory_limit when the tenants are created. However, the memory usage of the OceanBase database is still constrained by the memory_limit. For example, if the total memory of running tenants exceeds memory_limit, the tenants will encounter memory overrun errors, or the processes will directly experience OOM.

What checks does OceanBase Database perform during a memory allocation?

The OceanBase database kernel limits the size of a single memory allocation to 4 GB, which is an internal restriction to avoid unreasonable memory allocation. Each time the kernel allocates memory, it also performs the following checks. If any of the corresponding errors occur, analyze the issue based on the error information:

What are the KV caches in OceanBase Database, and what are their purposes?

You can query the GV$OB_KVCACHE view for the KV caches in OceanBase Database. Generally, there are the following types:

• BloomFilter Cache: OceanBase Database's Bloom filter is built on macroblocks. It is built automatically on demand. When the number of missed queries exceeds the specified threshold on a macroblock, a Bloom filter is automatically built and cached on this macroblock.
• Row Cache: caches specific data rows. During a get or multi-get query, the corresponding data rows are often cached into the Row Cache to significantly boost the performance of hot row queries.
• Block Index Cache: caches the indexes of microblocks. Similar to the intermediate layer of a B-tree, the Block Index Cache has a high hit ratio because the intermediate layer is usually not large.
• Block Cache: OceanBase Database's Buffer Cache. It caches specific data blocks. In fact, microblocks are cached in the Block Cache after they are decompressed.
• Partition Location Cache: caches the location information of partitions to help route a query.
• Schema Cache: caches the metadata of data tables for execution plan generation and subsequent queries.
• clog Cache: caches clog data to accelerate the pulling of Paxos logs in some scenarios.

How does KV Cache achieve dynamic scaling, and what are the eviction rules?

The main part of dynamically scalable memory is the KV cache. OceanBase Database manages most caches in the KV format centrally in the KV cache.

Generally, you do not need to configure the KV cache. In special scenarios, you can set the priority for different types of KV. KVs with a higher priority are more likely to be retained in the cache. If you want to change the default priorities of the KV cache, contact OceanBase Database technical support.

What common memory issues may occur in OceanBase Database, and what are the possible causes?

OceanBase Database may encounter the following common memory issues:

• Out of memory in the work area

  The memory for the work area limit = tenant memory * ob_sql_work_area_percentage (default 5%). If a large number of concurrent requests each occupy a substantial amount of memory in the work area, an error may occur indicating that the work area is full. This error commonly occurs in scenarios involving operations such as union, sort, and group by.

  You can increase the work area system variable, for example, set global ob_sql_work_area_percentage = 10, to avoid this issue.

• Insufficient tenant memory

  An error "Over tenant memory limits" (error code 4013) is returned to the client, indicating that the tenant memory is insufficient. Generally, you need to analyze the current memory usage to identify the cause.

  You can query the GV$OB_MEMORY view or check the observer.log file to see whether a particular module consumes a significantly large proportion of the memory.

• MemStore memory exhausted

  If the write speed exceeds the dump speed, the MemStore is exhausted. For example, in large-scale data import with high concurrency, the MemStore writes data too fast. If the system cannot dump the MemStore in time, the MemStore will be exhausted, and an error 4030 will be returned to the user.

  You can identify and resolve this issue by analyzing the bottleneck of the slow dump speed, increasing the dump speed, or decreasing the write speed.

• Overall memory usage exceeds the limit on the OBServer node

  When the OBServer node process starts, it calculates the maximum physical memory that the process can use based on the specified parameters. If the memory_limit parameter is set, the maximum physical memory that the OBServer node can use is the value of memory_limit. If the memory_limit parameter is set to 0, the maximum physical memory that the OBServer node can use is calculated as physical memory * memory_limit_percentage.

  If you find that the memory on an OBServer node exceeds the limit, you can query the _all_virtual_server_stat view to obtain the actual memory limit on the OBServer node and then check whether the memory_limit and memory_limit_percentage parameters are correctly set. If the memory continues to exceed the limit in an increasing trend, it may indicate a memory leak. In this case, contact OceanBase Database technical support.

Frequently asked questions about multi-tenant threads

Is OceanBase Database a single-process or multi-process database?

OceanBase Database is a single-process database. The main threads in the runtime of OceanBase Database are as follows:

• election worker: the election thread.
• net io: the network I/O thread.
• disk io: the disk I/O thread.
• clog writer: the clog writing thread.
• misc timer: multiple background timer threads that are mainly responsible for resource cleanup.
• compaction worker: the minor merge and major merge threads.
• sql worker and transaction worker: the SQL and transaction request processing threads.

What are the background threads in an OBServer node, and what are they used for?

Generally, you do not need to be concerned about the implementation details of background threads. They may change in future versions of OBServer nodes.

The following table lists some common background threads in an OBServer node and describes their features.

How does an OBServer node implement CPU resource isolation in a multi-tenant architecture?

In the current versions of OBServer nodes, the node controls the number of active threads (threads that actually consume CPU resources) to control CPU usage. When a tenant is created, you can specify the tenant resource pool. The max_cpu parameter in the resource pool definition specifies the maximum number of active threads allowed at the tenant level, thereby isolating CPU usage among tenants. In the latest version of OBServer nodes, the kernel implements cgroup to effectively control and limit CPU, memory, and resource usage.

How can I read the number of worker threads of an OBServer worker thread? Does an OBServer node dynamically start new threads to handle loads when it is under high load?

In the log fragment with dump tenant info as the keyword in the observer.log file, the current and maximum values of the worker threads are described. Specifically:

tocken_count = allocated_cpu_count (>min_cpu&&<max_cpu)  _cpu_quota_concurrency.

For example, in a server running OceanBase Database, the tenant T1 is configured with unit_min_cpu = 2, unit_max_cpu=8. However, the CPU resources on the server are oversold. Only 5 CPU cores are actually allocated to T1. In this case, token_count = 5_ cpu_quota_concurrency.

What is the principle of CPU resource allocation for large queries? Will CPU resources be preempted when both OLAP and OLTP are running?

You can configure the large_query_threshold parameter in OceanBase Database to define a query execution time threshold. A query exceeding the threshold is considered a large query. If both large queries and small queries are running in the system, OceanBase Database allocates some CPU resources to the large queries and limits the maximum number of active threads that a tenant can have for the large queries through the large_query_worker_percentage parameter (default value: 30%).

OceanBase Database restricts the CPU resources used by large queries by limiting the number of active worker threads available to tenants for such queries. This ensures that the system retains sufficient CPU resources to handle OLTP (e.g., transactional small workloads). By doing so, it guarantees that latency-sensitive OLTP workloads receive adequate CPU resources to be executed promptly. Additionally, it is important to note that while OceanBase Database can allocate resources between large queries and OLTP workloads, the large_query_threshold parameter should be set within a reasonable range and not to an excessively high value. Otherwise, large queries may easily consume excessive CPU resources, potentially causing slow OLTP response times or even request backlogs.