Release note for AP core features

This topic lists only the core capability changes related to real-time analytics. For more information about the full set of capabilities and iterations of OceanBase Database, see Release Note.

V4.4.2

Version information

• Release date: February 10, 2026
• Version number: V4.4.2

New features and enhancements

• Enhanced materialized view capabilities

  The V4.4.2 version continues to enhance the materialized view capabilities. It supports RENAME operations and adding columns to materialized view logs at the DDL level, and implements automatic creation, replacement, and background redundancy cleanup of MLOG tables. The incremental refresh capability has been significantly expanded, supporting complex query modes such as outer joins, UNION ALL, non-aggregated single-table queries, and aggregated queries with LEFT JOIN. The handling of MIN/MAX aggregate functions has been strengthened, supporting repeated SELECT items and GROUP BY columns, and adapting to scenarios without a primary key base table. The AS OF PROCTIME() syntax has been introduced to implement dynamic exemption refresh for dimension tables (supporting views that reference this syntax), and the cascading refresh mechanism for nested materialized views has been improved. At the same time, support for UDT/UDF, minimal mode, and the md5_concat_ws function has been enhanced, and the display of view content and creation error messages has been optimized, significantly improving the flexibility, performance, and usability of materialized views in complex queries, real-time analysis, and O&M management.

V4.4.1

Version information

• Release date: September 26, 2025
• Version number: V4.4.1

New features and enhancements

• Support for HMS Catalog

  V4.4.1 supports Iceberg, an open table format for data lakes, and allows querying external tables in Iceberg and Hive formats through HMS Catalog. HMS Catalog is introduced to build a unified metadata abstraction layer compatible with the HMS protocol. It automatically synchronizes metadata across different table formats, such as Hudi Timeline and Iceberg Snapshots, and seamlessly integrates with mainstream computing engines. This addresses metadata ambiguity across systems, serving as a key infrastructure for OceanBase to transition from "compute-storage separation" to "metadata-driven governance."

• Support for JDBC plugins in external tables

  OceanBase allows direct access to various external data sources through external tables, such as CSV files stored on OSS and ODPS tables. V4.4.1 introduces JDBC plugin capabilities, enabling integration with JDBC-compatible data sources. Currently, MySQL data sources are supported.

V4.4.0 Beta

Version information

• Release date: July 8, 2025
• Version number: V4.4.0

New features and enhancements

• Support for ODPS Storage API

  V4.4.0 introduces support for the ODPS Storage API, allowing ODPS external tables to directly access the underlying storage of ODPS. This eliminates the need for establishing independent sessions for each partition scan in the Tunnel API, reducing initialization latency from seconds to milliseconds. This significantly improves the performance of small and high-frequency queries while maintaining compatibility with the Tunnel API to meet diverse access requirements.

• SELECT INTO OUTFILE now supports HDFS paths

  V4.4.0 continues to enhance external table capabilities by supporting direct queries and imports from HDFS paths. The new version further integrates HDFS capabilities, allowing data to be directly exported to HDFS. It also supports Kerberos authentication for secure HDFS access.

V4.3.5 BP5

Version information

• Release date: November 17, 2025
• Version number: V4.3.5 BP5

New features and enhancements

• Materialized view functionality enhancement

  • Supports incremental refresh for materialized views with LEFT JOIN.
  • Supports nested materialized views based on incrementally materialized views without a primary key.
  • Supports setting parameters of MIN/MAX aggregate functions in incremental materialized views to non-basic columns.
  • Supports incremental materialized views with multiple tables connected that reference views declared as dimension tables (AS OF PROCTIME()).
  • Supports full refresh materialized views by referencing UDF.
  • Supports minimal refresh mode (incremental refresh DML only reads and writes the necessary data of the column store table) for incremental materialized views.
  • Supports materialized views to refresh using the session variables that are set to specific values.

• Delete-Insert table incremental data query supports Skip Index

  V4.3.5 BP5 introduced the Skip Index for pre-generated incremental data in the Delete-Insert table. When querying incremental data, the Skip Index allows for pre-trimming of data, significantly improving query efficiency. This capability is controlled by the tenant-level configuration item default_skip_index_level, which determines the scope of Skip Index coverage.

• Partition exchange functionality extended

  Prior to V4.3.5 BP5, a range/range columns partitioned table can be swapped with a non-partitioned table. Additionally, you can exchange a range/range columns partition of a subpartitioned table with a non-partitioned table. You can also exchange the primary partitions of a range/range columns partitioned table with those of a non-partitioned table. In addition to these features, V4.3.5 BP5 supports exchanging a list/list columns partition of a list/list columns partitioned table with that of a non-partitioned table.

V4.3.5 BP4

Version information

• Release date: September 10, 2025
• Version number: V4.3.5 BP4

New features and enhancements

• Enhanced materialized view capabilities

  V4.3.5 BP4 continues to enhance materialized view capabilities. From the perspective of functionality, it supports incremental refresh of materialized views without refreshing dimension tables. When creating a materialized view, you can use the new AS OF PROCTIME() syntax to specify tables that do not need to be refreshed. During the incremental refresh of a materialized view, the incremental data of these tables will not be refreshed. Single-table aggregation incremental refresh materialized views support the MIN() and MAX() aggregate functions. From the perspective of usability, it supports automatic management of MLOG tables. When creating an incremental refresh materialized view, the system automatically creates or replaces the required MLOG tables for the base table and periodically cleans up redundant MLOG tables in the background. It also optimizes the view content and error messages for creating materialized view.

• Disabled full bypass import by default for AP parameter templates.

V4.3.5 BP3

Version information

• Release date: July 21, 2025
• Version number: V4.3.5 BP3

New features and enhancements

External data source and integration optimization

• ODPS external table supports Storage API

  For an external table based on the Tunnel API, a session needs to be opened for each partition during execution. Opening a session requires a delay of several seconds. This causes some queries with very short execution times to spend a lot of time on session preparation. In addition to the Tunnel API, ODPS provides an open Storage API that allows direct access to the underlying storage of ODPS. This API provides more optimization strategies and better read performance. Therefore, the new version supports the ODPS Storage API to further improve the performance of external table access.

• Object storage supports Azure Blob

  The new version supports accessing Azure Blob storage objects using the Azure Blob protocol.

Enhanced materialized views

• Enhanced materialized view capabilities

  The new version continues to improve the capabilities of materialized views. This includes support for renaming materialized views, incremental refreshes for outer joins, UNION ALL, and non-aggregated single-table operations, support for adding columns to materialized view logs, and support for cascading refreshes in nested materialized views. It also fixes issues such as materialized view drop hangs, enhancing the stability of materialized views.

Storage and partition management optimization

• Support for swapping primary and secondary partitions

  The new version supports swapping primary partitions of secondary partitioned tables with primary partitions of primary partitioned tables.

Optimizer and query performance improvements

• Enhanced statistics collection

  In versions prior to V4.3.5 BP3, statistics collection required gathering aggregated data such as MIN, MAX, NULL COUNT, and NDV for each column at the partition and table levels, and estimating data distribution through sampling, which introduced significant errors. The new version leverages the Skip Index capability at the storage layer to collect more accurate column-level aggregated data at the block level for all columns in columnar storage. This helps the optimizer generate and optimize plans with greater accuracy. Additionally, the new version introduces a progressive statistics collection approach for partitions to address the issue of long collection times for large partitioned tables, improving system stability and data timeliness.

Accelerated data import

• Performance optimization for direct load

  The new version optimizes the execution logic of direct load, including sorting algorithms, vectorized paths for direct load, CSV parsing, column_conv expressions, and CS encoding. In non-partitioned heap tables in columnar storage, performance can improve by up to 10%.

V4.3.5 BP2

Version information

• Release date: May 15, 2025
• Version number: V4.3.5 BP2

Product forms

• Shared-Storage AP

Starting from V4.3.5 BP2, OceanBase Database in the Shared-Storage deployment mode can be used for AP workloads. The Shared-Storage AP form supports key AP features in the Shared-Nothing deployment mode, such as columnar tables, incremental direct load, materialized views, full-text indexes, and multi-value indexes. It also optimizes the I/O read method in the Shared-Storage deployment mode. The Shared-Storage AP form is recommended for AP workloads with data cold-warm characteristics that aim to reduce storage costs.

Feature enhancements

Enhanced data recovery capability

• Support for restoring columnar tables

  Before this version, the table-level recovery feature only supported restoring to row-based tables. In the new version, the table-level recovery feature is enhanced in the Shared-Nothing deployment mode to support restoring to columnar tables and hybrid row-columnar tables.

Performance optimization

• Optimized performance of direct load for heap tables

  The uniqueness check process during the creation of a unique index in the direct load for heap tables is optimized. The performance of full direct load for non-partitioned tables is not lower than that of index-organized primary key tables.

• Optimized performance of hard parsing

  In some AP scenarios or for some account sizes, turning off the plan cache and using hard parsing can reduce the use of suboptimal plans. However, turning off the plan cache increases the performance requirements for hard parsing. The new version optimizes the resolver stage by hot functions, replaces global cost verification with local cost verification in non-mandatory scenarios, reduces expression memory usage, and removes unnecessary expression type inference operations. These optimizations improve the performance of the optimizer in the resolve and rewrite stages.

Enhanced materialized views

• Support for creating materialized views based on external tables

  Before this version, OceanBase Database supported building materialized views based on user tables and materialized views. In the new version, in full-refresh scenarios, it also supports building materialized views based on external tables, expanding the applicable scenarios for materialized views.

• Enhanced diagnostics for materialized views

  The CDB/DBA_MVIEW_RUNNING_JOBS system view is added to display ongoing materialized view tasks, such as refresh tasks and MLOG cleanup tasks. The DBA_MVIEW_DEPS system view is added to display the dependency objects of materialized views. The CDB/DBA/ALL/USER_MVIEWS system view now records the refresh points and refresh delays of materialized views. The CDB/DBA/ALL/USER_MVIEW_LOGS view now records the parallelism and duration of MLOG cleanup.

• Resource isolation for materialized view tasks

  Refreshing and purging materialized views consume system resources, which may affect the performance of foreground tasks. The new version provides resource isolation capabilities for incremental refreshes and MLOG purges of materialized views based on Resource Manager. Users can set resource limits for materialized view tasks.

Partition management

• Dynamic partition management

  Businesses often use date or time as the RANGE partitioning key to divide data from different periods into different partitions. DBAs need to pre-create some future partitions regularly to meet data writing requirements. If DBAs forget to pre-create partitions for some reason, data may fail to be written due to the absence of partitions, affecting business operations. To address this, the new version introduces dynamic partition management. By specifying dynamic partition management attributes for a table, the kernel automatically pre-creates future partitions, reducing the burden on DBAs. Dynamic partition management also supports automatically deleting obsolete partitions that are no longer needed, saving storage space.

Indexes and query optimization

• NGRAM2 tokenizer for full-text indexes

  The new version introduces the built-in NGRAM2 tokenizer for full-text indexes, supporting NGRAM tokenization within the range specified by min_ngram_size to max_ngram_size. The NGRAM2 tokenizer is suitable for scenarios where performance and storage space are relatively insensitive, and different lengths of token need to be retrieved. For fixed-length token, the NGRAM tokenizer can be used.

Data types and storage optimization

• Map data type

  The Map data type is used to store unordered key-value pairs, such as {a:1, b:2, c:3}. Common use cases include storing configuration options, user attributes, and product information. OceanBase Database implements the Map data type based on the Array framework in version 4.3.5BP2, supporting Map constructors and functions and operators such as map_keys, map_values, =, and !=.

• MySQL-compatible mode JSON semi-structured storage

  Currently, semi-structured data is stored as binary strings, making it difficult to encode and compress using Encoding. Each data record redundantly stores some data metadata for self-explanation, resulting in a low compression rate. JSON is a typical semi-structured data type with strong structural characteristics. Theoretically, semi-structured data can be logically split into multiple base-type columns, with the non-decomposable parts stored in a Binary column. Structured columns can leverage Encoding to improve the compression rate, and the non-decomposable parts, by extracting data metadata, reduce space usage compared to before. This is referred to as "structured storage of semi-structured columns." OceanBase Database supports semi-structured storage of JSON data in version 4.3.5BP2, implementing corresponding encoding methods to reduce storage space usage and optimize query filtering performance for JSON sub-columns. However, since JSON data is stored as multiple sub-columns, frequent reads of the original JSON data may introduce merge overhead, leading to performance degradation. Whether to enable this feature depends on the business requirements.

Query execution

• Adaptive plan cache

  Plan Cache is crucial for TP scenarios and is enabled by default. In some AP scenarios, the execution time of a plan can be much longer than the generation time. In such cases, generating a new plan for each query may yield a better execution plan than reusing an existing one, leading to improved execution performance. In mixed HTAP workloads, it is necessary to provide a way for AP-biased SQL queries to use hard parsing while allowing TP-biased SQL queries to reuse plans to avoid the overhead of hard parsing. The new version introduces adaptive Plan Cache capabilities, allowing the system to decide whether to use the Plan Cache for a SQL query based on the execution time and distribution of the query's execution time.

Integration with external data sources

• MySQL mode ODPS (MaxCompute) Catalog

  To facilitate querying data stored in various external data sources, the new version supports the External Catalog framework and the ODPS Catalog feature. OceanBase Database's existing internal objects are managed under the Internal Catalog. Users can create External Catalogs to connect to external data sources and retrieve metadata. The new version supports direct querying of tables in External Catalogs, such as SELECT col1 FROM catalog1.database1.table1;. If permissions are met, it also supports cross-Catalog table joins. This eliminates the need for data imports or creating individual external tables, improving the ease of access to external data.

Data import

• Load Data import with URL CSV external table error tolerance mode

  When using the Load Data method to import data, errors such as data type incompatibility and precision mismatch will result in direct errors. The new version introduces the LOG ERRORS instruction for error-tolerant imports. In MySQL mode, failed rows are recorded, and users can view error data using SHOW WARNINGS for error diagnosis.

V4.3.5 BP1

Version information

• Release date: March 18, 2025
• Version number: V4.3.5 BP1

New features and enhancements

Data import and export

• Incremental direct load supports heap tables with unique indexes

  Direct load can be full or incremental. When data already exists in a table, incremental direct load performs better than full direct load. However, incremental direct load previously did not support importing data into heap tables with unique indexes. The new version supports incremental direct load for heap tables with a local unique index.

• Direct load supports HASH partitions and concurrent partition imports

  Starting from V4.3.5 BP1, direct load supports HASH partition-level imports. Additionally, incremental direct load now supports concurrent partition imports. However, if multiple import tasks have overlapping partitions, concurrent partition imports are not supported.

• Performance optimization for direct load

  Through vectorization optimization, streamlined temporary file processes, and performance improvements in each stage, the import performance of the clickbench table has improved by 17% compared to V4.3.5.

External data source integration

• Support for reading HDFS files from external tables

  HDFS is the most common storage medium in data lake architectures and serves as a platform for multi-engine data sharing. Therefore, the new version of OceanBase Database supports directly reading files from HDFS through external tables. It also supports connecting to HDFS clusters with Kerberos authentication through relevant configurations.

• Support for reading and writing data from / to MaxCompute (ODPS)

  The new version supports reading data from MaxCompute through external tables or URL external tables. It also supports writing data from OceanBase Database back to MaxCompute.

• URL external tables

  When accessing external data sources in OceanBase Database, you typically need to create an external table and then use SQL queries. The new version introduces URL external tables, allowing you to directly query external CSV, Parquet, ORC, and MaxCompute data using SELECT statements without creating an external table. Additionally, it extends the LOAD DATA syntax to directly reference URL external tables for data import, reducing the operational cost of data import.

Index optimization

• Enhancements to full-text indexing

  OceanBase Database V4.3.1 introduced full-text indexing in MySQL mode, and subsequent versions have added various features and extensions. V4.3.5 BP1 introduces the built-in Chinese IK tokenizer, supporting smart and max_word tokenization modes. It also allows adding new tokenizers as plugins. The new version supports the PARSER_PROPERTIES configuration at the table level for full-text indexes. In addition to the existing natural language mode for full-text index queries, it now supports the boolean mode, which can be enabled using the IN BOOLEAN MODE keyword in MATCH AGAINST. This mode supports boolean operators such as +, -, (), and no operator, as well as nested operations. Furthermore, full-text indexes can now participate in index merge, improving query performance through index union merge. The new version also optimizes the update and deletion scenarios for full-text indexes on the primary table, enhancing the performance of these operations.

Materialized view enhancements

• Enhancements to materialized views

  The parallelism of materialized view refreshes is closely related to the efficiency of incremental and full refreshes. The new version supports a complete parallelism control mechanism, allowing you to set the refresh parallelism using the mview_refresh_dop system variable, the DBMS_MVIEW.refresh stored procedure, or the PARALLEL option when creating a materialized view. The new version also supports the LOB data type for incremental materialized views and provides the ability to directly modify materialized views or materialized view logs. You can use the ALTER MATERIALIZED VIEW and ALTER MATERIALIZED VIEW LOG commands to modify the parallelism, background refresh task cycle, parallelism of the MLOG table, background cleanup task cycle of the MLOG table, and the inline storage length threshold for LOB in the MLOG. Additionally, when an MLOG is created on the base table, you cannot add columns to the base table. You must first delete the MLOG before performing DDL operations, which is complex. The new version supports adding columns to the MLOG base table, including adding columns at the end and in the middle. Furthermore, the new version improves the performance of MLOG cleanup and optimizes the error messages for incremental refreshes.

Table structure and storage optimization

• Heap table organization mode

  OceanBase Database uses a clustered index table model, which performs well in OLTP environments. It stores the primary key and primary table data in the same table, optimizing primary key query speed and uniqueness validation performance. However, this model has limitations in OLAP scenarios requiring efficient data import and complex data analysis. The import process requires sorting all data, and queries must perform primary key row fusion, which affects performance. The new version introduces the heap table organization mode, where the primary key is used for uniqueness constraints, and queries rely on the primary table. When user data is sorted by time, skip index can be more effectively utilized to improve query efficiency. Additionally, decoupling the primary key from the data eliminates the need to sort primary table data during import, enhancing import performance.

Data type and storage optimization

• New String data type in MySQL-compatible mode

  Some AP applications have a high tolerance for column length and often use variable-length string types to store data, which also need to be primary keys or index keys. In OceanBase Database, the char and varchar types can store strings and serve as primary keys or index keys, but they require specifying a length. The mediumtext and text types, which are LOB types, can store variable-length strings but cannot serve as primary keys or index keys. To better meet the needs of AP applications, the new String data type is introduced, which does not require specifying a length and has a default maximum length of 16 MB. When the column length is less than 16 KB and does not exceed the lob_inrow_threshold, it can serve as a primary key or index key.

• Enhancements to functions related to the ARRAY data type

  OceanBase Database V4.3.3 introduced the ARRAY data type and supported some common functions and operators. The new version further enhances these functions by adding support for array_prepend, array_concat, array_compact, array_filter, array_sort, array_sortby, array_length, array_range, array_sum, array_first, array_difference, array_min, array_max, array_avg, array_position, array_slice, and reverse.

Parallel query optimization

• Decoupling of PX computing nodes from data nodes

  In the current system architecture, storage and computing resources are highly coupled. The existing PX scheduling mechanism for Non-Leaf DFOs selects only the machines where data resides for computing task allocation. This tight coupling limits the full utilization of machine resources in certain scenarios. To enable large SQL queries to leverage more computing resources, the new version decouples PX computing nodes from data nodes. You can specify the candidate resource pools for Non-Leaf DFOs using configuration parameters or hints (PX_NODE_POLICY). Additionally, you can use hints (PX_NODE_ADDRS and PX_NODE_COUNT) to force the allocation of Non-Leaf DFOs to specific machines or a specific number of machines.

Query optimization and pushdown

• Support for query pushdown in rowstore data column addition scenarios

  During a rowstore SCAN, if there is no intersection between the major sstable and other rowids, the SCAN is pushed down to the storage layer. When new columns are added after the merge, the SCAN can theoretically be pushed down, but if the new columns fail to parse, the pushdown fails, and the system reverts to a less efficient row-by-row read. The new version optimizes this scenario by supporting query pushdown to the storage layer, thereby improving query performance.

Columnar storage optimization

• Optimizations for columnar replicas

  The columnar replica feature introduced in V4.3.3 had some limitations, such as supporting only a single C replica, not allowing direct full import of columnar data to C replicas, and lacking user-friendliness. The new version removes these limitations, allowing multiple C replicas to be specified in a cluster and supporting direct full import of columnar data to C replicas. It also introduces the system view CDB/DBA_OB_CS_REPLICA_STATS to display the progress of columnar replica conversion at the partition and log stream levels, making it easier for users to monitor columnar replica status.

Behavior changes

• Disable NLJ in AP mode

  After the optimizer generates a nested loop join plan, the plan is sensitive to the number of rows in the driving table. If the estimated number of rows in the driving table is too small, the actual execution performance of the plan may significantly degrade. In OLAP scenarios, the data volume is usually large, and the benefits of using a nested loop join plan are limited. Therefore, in AP scenarios, the default is to generate a hash join plan, and a nested loop join plan is only generated in non-equality join scenarios.

V4.3.5

Version information

• Release date: December 31, 2024
• Version number: V4.3.5

New features and enhancements

Enhanced materialized views

• Support for nested materialized views

  In versions earlier than V4.3.5, materialized views could only be created on regular user tables. In data warehouse scenarios, materialized views are used for data processing. To better support lightweight real-time data warehouses, V4.3.5 introduces nested materialized views, allowing new materialized views to be created based on existing ones. The refresh methods for nested materialized views are the same as those for non-nested ones, including full and incremental refreshes. Therefore, V4.3.5 supports creating materialized view logs based on materialized views. The freshness of data in nested materialized views depends on the base table's data freshness. To ensure the freshness of upper-level materialized views, users must refresh the underlying materialized views first.

  For more information, see the section on creating nested materialized views in Create a materialized view (MySQL-compatible mode) or Create a materialized view (Oracle-compatible mode).

Data import and export

• Support for specifying partitions for direct load

  Before V4.3.5, OBServer only supported full-table direct load for accelerating data import. If users wanted to import data from specific partitions, they had to use partition exchange. This involved importing partition data to a non-partitioned table via full direct load and then swapping the non-partitioned table with the target partition. This process was cumbersome. To better support partition-level data imports, V4.3.5 allows specifying partitions for direct load using the LOAD DATA and INSERT INTO SELECT syntax. However, it does not support specifying the last-level partition type as Hash/Key.

  For more information, see Full direct load or Incremental direct load.

• Enhancements to the select into outfile feature

  V4.3.5 enhances the select into export feature by supporting Parquet and ORC types, allowing users to specify compression algorithms when exporting CSV files, and introducing new syntax for select into.

  • Use the format syntax to set export options.
  • Specify compression algorithms when exporting CSV files.
  • Export Parquet files.
  • Export ORC files.

Index enhancements

• Enhancements to full-text indexing

  V4.3.5 continues to enhance the full-text indexing feature from V4.3.4, including:

  • Support for creating full-text indexes using CREATE FULLTEXT INDEX or ALTER TABLE ADD FULLTEXT INDEX.
  • Support for cost-based full-text index plan selection. For SQL statements with multiple filters containing MATCH AGAINST, it supports selecting the index with lower cost for scanning.
  • Support for Functional Lookup:
    • Support for multiple MATCH AGAINST expressions in query statements.
    • Support for using full-text indexes alongside other indexes.
    • Support for outputting MATCH AGAINST expressions without filter semantics as projected columns.
    • Support for filtering MATCH AGAINST expressions with filter semantics using <=/< operators.
    • Support for linking MATCH AGAINST expressions with filter semantics using AND/OR logic.

  For more information, see MATCH AGAINST.

External data source integration

• Enhancements to external tables

  In V4.3.5, external tables support reading ORC format files.

  For more information, see Create an external table (MySQL-compatible mode) or Create an external table (Oracle-compatible mode).

Columnar storage optimization

• Read-only columnar replicas

The read-only columnar replica feature introduced in V4.3.3 was an experimental feature. After iterations in V4.3.4 and V4.3.5, this feature has now reached GA requirements in V4.3.5.

• Support for asynchronous online DDL during row-to-column conversion

  V4.3.0 introduced three storage formats: rowstore, pure columnar, and hybrid row-column. Converting a rowstore table to a hybrid or columnar table is an offline DDL operation. To minimize the impact of offline DDL on customers, V4.3.5 supports asynchronous online DDL for row-to-column conversion. By specifying the delayed keyword during DDL execution, users can modify the table schema in real-time without blocking data writes, achieving an online effect. The baseline data reorganization for columnar storage is then asynchronously executed during baseline data compaction. V4.3.5 supports asynchronous online DDL for converting rowstore tables to columnar or hybrid row-column tables.

Performance optimization

• Vectorization in direct load write path

  Before V4.3.5, direct load did not use vectorization, and write functions processed data row by row, resulting in significant function call overhead. Additionally, writing to an sstable was a background process, and some operations lacked specific optimizations. V4.3.5 introduces vectorization in the direct load path and optimizes columnar encoding to enhance performance. Testing shows that direct load performance for tables without a primary key can be improved by about 2 times.

Data type and storage optimization

• Support for complex DML with JSON multi-value indexes

  V4.3.5 enhances support for complex DML statements with JSON multi-value indexes. It now supports multi-value predicates in update and delete statements and supports complex DML operations involving multi-value indexes.

• Support for more array expressions

  OceanBase Database introduced the ARRAY data type in V4.3.3. To better support business use of ARRAY types, V4.3.5 supports more array expressions to meet diverse business scenarios. New expressions include array_append, array_distinct, arrayMap, array_remove, cardinality, element_at, array_contains_all, array_overlaps, array_to_string, array_agg, unnest, and rb_build.

V4.3.4

Version information

• Release date: October 31, 2024
• Version number: V4.3.4

New features and enhancements

Storage architecture optimization

• Shared storage (experimental feature)

  To provide more cost-effective database services for users in public cloud environments, OceanBase Database V4.3.4 introduces the Shared-Storage Cluster architecture based on a general-purpose object storage. This architecture allows multiple tenants to share a baseline dataset and log data stored in a standard object storage. Hot data is stored in cloud disks or local SSDs, while cold data is stored in standard object storage. This approach reduces storage costs for databases. Each tenant's replicas cache only hot data and logs on local storage, enabling rapid scaling of compute nodes. The shared storage architecture is suitable for TP workloads with distinct hot and cold data, such as historical and backup databases, as well as key-value and time-series workloads.

  The Shared-Storage Cluster feature is defined as an experimental feature in V4.3.4 and will be further refined in future versions to become a production-ready feature.

Indexing enhancements

• Enhancements to full-text indexing

  OceanBase Database has supported full-text indexing since version 4.3.1. This feature preprocesses text content to build keyword indexes, significantly improving the efficiency of full-text searches. However, complex DML operations involving full-text indexes had some limitations, causing inconvenience for users. To better support business development, version 4.3.4 enhances complex DML operations, including INSERT INTO ON DUPLICATE KEY, REPLACE INTO, multi-table updates and deletions, and updatable views for tables with full-text indexes. Additionally, the new version optimizes full-text search performance using vector execution and extended TAAT processing strategies. It also removes the token number limit for the MATCH AGAINST predicate, allowing full-text indexes to be created on partitioned tables without a primary key. Furthermore, the new version supports the tokenize function to view tokenization results, aiding in debugging tokenization systems.

  For more information, see Create a multi-value index.

• Enhancements to multi-value indexing

  Currently, multi-value indexing only supports pre-created indexes, with some limitations in DML and DDL operations. To better support business use, V4.3.4 relaxes some of these limitations and enhances the feature. The main enhancement is the support for complex DML operations, including INSERT INTO ON DUPLICATE KEY, REPLACE INTO, multi-table updates/deletions, and updatable views.

Data import optimization

• Support for non-unique local indexes in incremental direct load

  OceanBase Database supports both full direct load and incremental direct load. When data already exists in a table, incremental direct load performs better than full direct load. Previously, incremental direct load did not support importing data into tables with indexes. V4.3.4 now supports importing data into tables with non-unique local indexes during incremental direct load.

• Performance optimization for direct load

  During direct load, if a table with a primary key requires sorting, the data is first written to a temporary file, then loaded into memory for sorting and merging, and finally written to an sstable. This approach divides the data import into two stages: data writing and sorting/merging. If the data is not fully written, the sorting/merging stage cannot begin. If the write I/O reaches a bottleneck, it indirectly limits the performance of direct load. V4.3.4 optimizes the data import process by directly writing data to memory instead of a temporary file, followed by sorting and merging. This optimization ensures a pipeline-style process for data import and sorting, avoiding the impact of one stage on the next. In primary key table scenarios, this optimization improves performance by 35% for 1TB of data. Larger memory and CPU resources result in greater performance improvements, making this optimization particularly suitable for large-scale tenants. For smaller tenants, the performance remains stable without significant degradation.

Data types and storage optimization

• Enhancements to bitmap functionality

  A bitmap, also known as a bitset, is a data structure used to efficiently store and process whether elements exist in a set. OceanBase Database V4.3.2 and V4.3.3 successively supported some features of RoringBitmap. V4.3.4 further enhances these features by adding the rb_iterate and rb_select expressions. The rb_iterate expression expands a roaringbitmap type into multiple rows based on the number of elements, while the rb_select expression filters elements from a roaringbitmap type based on conditions and returns a new roaringbitmap type.

V4.3.3

Version information

• Release date: September 30, 2024
• Version number: V4.3.3

New features and enhancements

Optimizations for Columnar Storage

• Read-only columnstore replica (Experimental)

  OceanBase Database V4.3.0 supports columnar storage. Users can create columnstore tables, rowstore tables, or hybrid columnstore/rowstore tables based on the specific business requirements. In a hybrid columnstore/rowstore table, the replica mode is consistent across zones within a tenant. For example, if a hybrid columnstore/rowstore table T1 is spread across three zones, it will have one columnstore replica and one rowstore replica in each zone. To meet the physical isolation requirements of TP and AP resources in hybrid HTAP workloads, OceanBase Database V4.3.3 introduces a new deployment mode. This mode allows you to expand a separate zone to host read-only columnstore replicas (Column Store Replica, C replica). All user tables in this zone are stored in columnar format. You can deploy an ODP independently for AP workloads. To access the columnstore replicas in this zone, you can set the ob_route_policy system variable at the session level to COLUMN_STORE_ONLY. This approach enables weak-consistency queries and analytics without affecting original TP workloads. Additionally, similar to the 3+1 zone deployment, this mode can save some storage costs compared to hybrid columnstore/rowstore tables. It must be used with ODP V4.3.2 or a later version. For more information, see Column Store Replica.

  The feature is defined as an experimental feature in version 4.3.3 and will be further refined as a production-ready feature in future versions.

Materialized view enhancements

• Enhanced materialized views

  To reduce manual rewrite costs for applications, OceanBase Database V4.3.1 supports rewriting queries by using materialized views. When the system variable QUERY_REWRITE_ENABLED is set to True, you can create a materialized view with the ENABLE QUERY REWRITE option enabled to use query rewriting capabilities. In this case, the system can convert queries on the original tables to queries on the materialized views. V4.3.1 supports rewriting queries that have a complete match in the FROM clause and partial match in the WHERE clause for non-aggregate materialized views. V4.3.3 further supports query rewriting of non-aggregate materialized views involving FROM clauses with JOIN statements, queries that include tables not present in the materialized views, and aggregate materialized views as well as rollup operations on aggregates.

  In V4.3.3, the Incremental Refresh and Real-Time Materialized Views feature also extends the supported SQL types for incremental refresh and real-time materialized views. Earlier versions of OceanBase Database supported incremental refresh and real-time querying for single-table aggregates and multi-table joins. V4.3.3 further extends this to support joins in aggregate scenarios. For more information, see Rewrite queries for materialized views (MySQL mode) and Rewrite queries for materialized views (Oracle mode).

  In addition, OceanBase Database V4.3.3 and later versions support columnar storage format materialized views in addition to the previous row-based storage format materialized views. This makes it possible to improve query performance in some complex analysis scenarios that involve referencing materialized views. For more information, see Create a materialized view (MySQL mode) and Create a materialized view (Oracle mode).

Data Import and Export Optimization

• Improve the performance of importing from an image

  V4.3.3 improves the execution performance for reading external table data in direct load mode by approximately 15% compared to the previous version.

• Improved INSERT OVERWRITE capability

  OceanBase Database V4.3.2 supports table-level overwrite operations (INSERT OVERWRITE) in atomic fashion. This feature allows you to clear old data and write new data in the same table to support AP scenarios such as periodic data refresh, conversion, and cleaning. However, OceanBase Database V4.3.2 supports only table-level overwrite operations, not partition-level or column-level overwrite operations. OceanBase Database V4.3.3 improves this feature. You can specify a partitioned table as the target table in an INSERT OVERWRITE statement and also specify part of the columns of the target table, thereby making the overwrite operations more flexible and adaptable to more scenarios.

• Support for loading compressed files for the Load Data/External Table feature

  Load Data is a commonly used method for data import, supporting scenarios such as standard server-side import, bypass import, and client-side import. It enables the import of text files in a specified format into a database. However, previous versions of Load Data supported only standard text files, meaning that compressed files like GZIP had to be decompressed before they could be imported, resulting in complex operations. Newer versions now support direct import of compressed files in GZIP, DEFLATE, and ZSTD formats. The import process involves loading, decompressing, and writing the data concurrently. In addition to this feature, CSV external tables have also been extended to support compressed files, allowing direct query of the data in these compressed formats through the external tables.

Data Types and Storage Optimization

• ARRAY data type

  ARRAY is a commonly used complex data type in the AP scenario. It can store multiple elements of the same type. It is a suitable option for managing and querying multi-valued attributes that cannot be effectively represented by relational data. OceanBase Database V4.3.3 supports the ARRAY type in MySQL mode. You can define a column as an array of numerical values or character values during table creation. You can also define a column as a nested array. OceanBase Database V4.3.3 supports expression-based array operations. You can use the array_contains expression or the ANY operator to check whether an element exists in an array. OceanBase Database V4.3.3 supports the +, -, =, and != operators to calculate and compare array elements.

• RoaringBitmap Performance Optimization

  V4.3.2 supports the RoaringBitmap data type and related expressions to meet the multidimensional analysis requirements in scenarios such as user profiling, personalized recommendation, and precision marketing. However, the performance in some scenarios is not optimal. This version focuses on analyzing the performance issues of RoaringBitmap calculations. It optimizes memory application and expression execution logic and reduces unnecessary performance overhead. As a result, the execution performance of cardinality, and/or/xor/andnot, and aggregation scenarios is improved by several times.

Resource management and isolation

• Resource group setup at query level

  OceanBase Database V4.3.3 has supported query-level resource group binding, which allows you to use the /*+ resource_group('group_name') */ hint in an SQL statement to specify a resource group to be used by the statement. The statement will use the specified resource group if it exists. Otherwise, it will use the default resource group. When you switch resource groups, the new resource group will be used for the session only after the session reconnects.

V4.3.2

Version information

• Release date: July 16, 2024
• Version number: V4.3.2 Beta

New features and enhancements

Optimizations for data import and export

• Enhancements to incremental direct load

  Starting from V4.3.1, incremental direct load is supported as an experimental feature. However, there are some limitations, such as the inability to import data with the outrow lob option and support for only incremental direct load with the load_mode set to inc_replace (i.e., replace semantics). V4.3.2 introduces the ability to perform incremental direct load on outrow lob data and extends the load_mode to include inc as a new option, with a default value of insert. When the ignore keyword is specified in an SQL statement, it will be treated as ignore semantics. This feature is now officially released. For more detailed usage information, see Use the LOAD DATA statement for direct load and Use the INSERT INTO SELECT statement for direct load.

• Performance optimization for full direct load

  In the new version, the performance of full direct load is improved by reducing column type conversion operations during data loading, lowering CPU usage for statistics collection, removing the generation of primary keys at the SELECT end in INSERT INTO SELECT statements, and disabling the sum skip index option by default for columnar storage (which pre-aggregates SUM values for specified columns within a range). Additionally, microblock verification is disabled by setting the configuration parameter micro_block_merge_verify_level to 0. These optimizations result in a performance improvement of approximately 20%.

• Partitioned export using SELECT INTO OUTFILE

  OceanBase Database currently supports exporting data to multiple files using the SELECT INTO OUTFILE statement, but it does not support exporting data by partition. V4.3.2 introduces the ability to export data by partition, resulting in a clearer directory structure. This feature also allows you to construct a file directory as a partitioned external table, improving query efficiency through partition path pruning.

Integration with external data sources

• Enhancements to external table functionality

  OceanBase Database has supported external tables in CSV format for a long time. However, as AP (Analytical Processing) workloads expand, there is a growing need to read Parquet-formatted external data sources in data lake scenarios. V4.3.2 introduces support for Parquet-formatted external tables. Users can import data from these files into internal tables in OceanBase Database or directly use external tables for cross-data source join queries and analysis. To ensure the timeliness of the file directories scanned by external tables, the new version includes an automatic file directory refresh feature. When creating an external table, you can specify the refresh method (manual, real-time, or periodic) using the AUTO_REFRESH option. You can also use the DBMS_EXTERNAL_TABLE.REFRESH_ALL_TABLE (with interval int) system package to manage scheduled refresh tasks. For more detailed usage information, see Create an external table.

Performance optimizations

• Performance optimization for typical AP scenarios

  V4.3.2 optimizes strategies for data block prefetching, vectorized batch processing, filter pushdown, comparison calculations, aggregation calculations, DTL shuffle, and monotonicity filters. In a 100 GB data volume scenario, the performance of benchmark tests such as TPCH, TPCDS, and ClickBench in AP scenarios is improved by approximately 10% to 15% compared to V4.3.1.

Data type and storage optimizations

• RoaringBitmap

  With the rise of big data, enterprises are increasingly focused on user data mining and analysis. RoaringBitmap, known for its space efficiency and computational efficiency, plays a significant role in scenarios such as user profiling, personalized recommendations, and precise marketing. OceanBase Database V4.3.2 introduces support for the RoaringBitmap data type in MySQL mode. By storing and operating on a set of unsigned integers, this feature enhances the performance of large-scale set calculations and deduplication. To meet multidimensional analysis needs, this version supports over 20 expressions for cardinality calculation, set operations, Bitmap judgment, Bitmap construction, Bitmap output, and aggregation operations.

Data operation optimizations

• Table-level overwrite write

  In data warehouses, scenarios such as regular data refreshes, data transformations, and data cleaning often require data overwrite writes. OceanBase Database V4.3.2 introduces the table-level overwrite write feature (INSERT OVERWRITE), which atomically clears old data and writes new data within a table. Leveraging the full direct load capability, INSERT OVERWRITE also demonstrates high execution performance. V4.3.2 supports the INSERT OVERWRITE tablename SELECT * FROM tablename syntax. However, partition-level overwrite write is not supported in this version and will be introduced in a future release.

Task scheduling and asynchronous execution

• Asynchronous task scheduling

  OceanBase Database currently supports various data import commands such as insert overwrite, insert select, create table as, and load data to enable real-time data ingestion. However, real-time import requires waiting for the import to complete and cannot be interrupted, making it less practical for large-scale data imports. V4.3.2 introduces asynchronous task scheduling based on DBMS_SCHEDULER. Users can create, query the status of, and cancel asynchronous import tasks using commands such as submit job, show job status, and cancel job.

V4.3.1

Version information

• Release date: May 17, 2024
• Version number: V4.3.1 Beta

New features and enhancements

Materialized view enhancements

• Materialized view enhancements

  OceanBase Database V4.3.0 supports the materialized view feature. By precomputing and storing the query results of a view, it reduces real-time computation and improves query performance. This feature simplifies complex query logic and supports AP scenarios. Based on this feature, V4.3.1 extends the support for real-time materialized views. This feature provides real-time computation capabilities based on both materialized view and MLOG data, suitable for analysis scenarios with high real-time requirements. V4.3.1 also adds a primary key constraint for materialized views, allowing users to specify a primary key for a materialized view to optimize single-row lookups, range queries, and join scenarios based on the primary key. Additionally, V4.3.1 extends the support for incremental updates of materialized views in inner join scenarios, improving the refresh performance of materialized views in these scenarios.

  In V4.3.0, when using materialized views, you need to manually replace the access to the original table in your business scripts with queries to the corresponding materialized view, introducing manual rewrite costs. V4.3.1 supports materialized view rewriting in some scenarios. When the system variable QUERY_REWRITE_ENABLED is set to True, you can specify ENABLE QUERY REWRITE when creating a materialized view to use the automatic rewrite feature. In this case, the system can rewrite queries to the original table into queries to the materialized view, reducing the amount of business modifications. For more information about automatic materialized view rewriting, see Materialized view query rewriting (MySQL mode) and Materialized view query rewriting (Oracle mode).

Data import and export optimizations

• Incremental direct load (Experimental)

  OceanBase Database V4.1.0 supports the direct load feature. This feature simplifies the execution path of data loading by skipping SQL, transactions, and memtables, and directly persists data as SSTables, significantly improving data import efficiency. However, in scenarios where a table needs to be imported multiple times, each import requires rewriting the existing data, which affects the performance of incremental imports. V4.3.1 optimizes incremental imports by eliminating the need to rewrite existing data. Instead, only new data is processed, allowing multiple imports to maintain high performance similar to the first import. You can specify whether to use the incremental direct load feature in LOAD DATA and INSERT INTO SELECT statements using the /*+ direct(need_sort, max_errors_allowed, load_mode)*/ hint. If load_mode is not specified or set to full, the full direct load method is used. If load_mode is set to inc_replace, the incremental direct load method is used. This feature is defined as an experimental feature in V4.3.1 and will be expanded and evolved into a production-ready feature in future versions. For more information about incremental direct load, see the Incremental direct load section in Direct load overview.

• SELECT INTO OUTFILE performance optimization

  The existing SELECT INTO OUTFILE feature supports parallel data reading but only serializes data writing to external files, creating a performance bottleneck for data export. V4.3.1 introduces parallel export capabilities, adding the single and max_file_size options to the SELECT INTO OUTFILE command to control data writing to external files. The single option allows exporting data to a single file or multiple files. When the parallelism is greater than 1 and single is set to false, data can be exported to multiple files, achieving parallel read and write. The max_file_size option controls the size of the exported files.

Index enhancements

• Full-text indexes (MySQL mode) (Experimental)

  In relational databases, indexes are typically used to accelerate queries based on exact value matching. However, standard B-Tree indexes are not suitable for scenarios involving large amounts of text data requiring fuzzy searches. In such cases, full-table scans are necessary to perform fuzzy queries on each row of data, which can be inefficient, especially when dealing with large text data and large datasets. Additionally, complex query scenarios such as approximate matching and relevance sorting are difficult to support through SQL rewriting.

  To address these issues, OceanBase Database V4.3.1 introduces the full-text index feature. This feature preprocesses text content to build keyword indexes, significantly improving the efficiency of full-text searches. This feature is defined as an experimental feature in V4.3.1 and will be expanded and evolved into a production-ready feature in future versions. The following features are included in this version:

  • The full-text index feature is supported in MySQL mode and is compatible with basic MySQL syntax.

  • Supports prebuilding full-text indexes for CHAR, VARCHAR, and TEXT columns during table creation.

  • Applies to partitioned tables.

  • Allows creating multiple full-text indexes for the main table.

  • Supports three built-in tokenizers: SPACE, NGRAM, and BENG (basic English).

  • Supports using a single MATCH AGAINST clause to perform full-text searches across multiple columns.

  • Supports the NATURAL LANGUAGE MODE.

Partition management

• Partition exchange

  Over time, tables may accumulate a large amount of historical data that is not frequently accessed but needs to be retained for compliance or historical analysis purposes. To improve query performance, businesses often need to differentiate between active and inactive data and archive the inactive data. While migrating data to a new table using SQL can address this scenario, performance may be suboptimal for large datasets. Therefore, OceanBase Database V4.3.1 introduces the partition exchange feature. This feature allows moving data from table A to a partition of table B by modifying the partition and table definitions in the data dictionary without physically copying the data, achieving nearly instantaneous data migration and significantly improving performance. The following features are included in this version:

  • Supports data exchange between a partition of a partitioned table and a non-partitioned table.
  • Supports first-level partitioned tables with RANGE (RANGE COLUMNS) partitioning.
  • Supports second-level partitioned tables with first-level partitioning of any type and second-level partitioning of RANGE (RANGE COLUMNS).
  • Supports the INCLUDING INDEXES behavior, where local indexes are also exchanged and remain available after the exchange.
  • Supports the WITHOUT VALIDATION mode, where users must ensure that the data conforms to the partition key range.

External data source integration

• Partitioned external tables

  OceanBase Database V4.2.0 supports external tables, but only for non-partitioned tables. When a large number of files are involved, but a query theoretically only needs to scan a subset of the files, non-partitioned external tables can only scan all files, leading to poor performance. V4.3.1 introduces the partitioned external table feature, supporting list partitioning similar to regular tables, with both automatic and manual partitioning syntax options. When automatic partitioning is specified, the system groups files by partition based on the defined partition key. When manual partitioning is specified, users must specify the subpaths for each partition. In this case, external table queries can perform partition pruning based on the partition conditions, reducing the number of scanned files and significantly improving query performance.

Data types and storage optimization

• MySQL JSON multi-value index (Experimental)

  MySQL 8.0 introduced support for multi-value indexes, which are useful for JSON documents and other collection data types. This feature allows users to build indexes on arrays or collections to efficiently retrieve elements. OceanBase Database V4.3.1 is compatible with this feature in MySQL mode, enabling the creation of efficient secondary indexes on JSON array fields containing multiple elements. This enhances the query capabilities of complex JSON data structures while maintaining the flexibility of the data model and ensuring high-performance data queries. This feature is defined as experimental in V4.3.1 and will be expanded and evolved into a production-ready feature in future versions. This version includes the following features:

  • Supports pre-creation of multi-value indexes and composite multi-value indexes;
  • Supports both unique and non-unique multi-value indexes;
  • Supports creating multi-value indexes with JSON array elements of types such as INT, UINT, DOUBLE, FLOAT, and CHAR;
  • Applies to partitioned tables;
  • Supports the use of multi-value indexes in functions such as MEMBER_OF(), JSON_CONTAINS(), and JSON_OVERLAPS().

• MySQL JSON partial update

  Some users store business data in JSON documents. When updating a document, the entire document must be read and then updated, which can be inefficient for large documents. OceanBase Database V4.3.1 introduces support for JSON partial updates. When users update specific fields in a JSON document using expressions such as json_set, json_replace, or json_remove, only the modified fields are updated, without the need to fully overwrite the document. This improves update performance. To enable this feature, set the log_row_value_options parameter.

Query execution and resource management

• SQL temporary result compression

  When the amount of data involved in SQL execution is too large, memory may be insufficient, requiring some operators to materialize temporary intermediate results. If the materialized data exceeds available disk space, SQL execution will fail. OceanBase Database V4.3.1 introduces SQL temporary result compression. You can specify whether to compress temporary results and the compression algorithm using the tenant-level parameter spill_compression_codec or an SQL-level hint (e.g., /*+opt_param('spill_compression_codec', 'lz4') */). Enabling temporary result compression reduces temporary disk space usage, supporting larger-scale query tasks.

V4.3.0 Beta

Version information

• Release date: March 22, 2024
• Version number: V4.3.0 Beta

New features

• Columnar storage engine

  In scenarios involving complex analysis of large-scale data or ad-hoc queries on massive data, columnar storage is a key capability of an AP database. Columnar storage is a data organization method that differs from row-based storage. In columnar storage, data in a table is physically arranged by columns. When data is stored in a columnar format, analytical queries can scan only the columns required for the query and computation, avoiding full-row scans. This reduces I/O and memory usage, thereby improving computational speed. Additionally, columnar storage inherently offers better data compression conditions, making it easier to achieve high compression ratios, which reduces storage space and network transmission bandwidth.

  However, traditional columnar storage engines often assume minimal random updates to maintain static data organization. When faced with frequent random updates, performance issues are inevitable. The OceanBase LSM-Tree architecture addresses this by separately handling baseline and incremental data. This allows for efficient management of dynamic data updates. Therefore, V4.3.0 extends support for columnar storage engines within the existing architecture. This enables integrated storage of both columnar and row-based data within a single codebase, architecture, and OBServer node, ensuring balanced performance for both TP and AP queries.

  To facilitate smooth migration for AP applications and ease of use for existing customers, various modules have been adapted and optimized around the columnar storage engine. These include the optimizer, executor, DDL operations, and transaction processing. Key enhancements include a new cost model based on columnar storage, a vectorized engine, extended query pushdown capabilities, Skip Index, new columnar encoding algorithms, and adaptive compaction.

  Users can flexibly configure tables as row-based, columnar, or hybrid (row-column redundant) based on their workload type. For more information about the columnar storage engine, see Columnar storage.

• New vectorized engine

  OceanBase has already implemented a vectorized engine based on the Uniform data description method in earlier versions, significantly improving performance compared to non-vectorized engines. However, in deep AP scenarios, there were still some performance limitations. V4.3.0 introduces the 2.0 version of the vectorized engine, which uses the Column data format description. This change eliminates the memory usage, serialization, and read/write access overhead associated with ObDatum maintenance. Based on the data format description, the new version has also re-implemented a batch of commonly used operators and expressions, including over 10 operators such as HashJoin, AGGR, HashGroupBy, and Exchange(DTL Shuffle), as well as over 20 MySQL expressions involving relational operations, logical operations, and arithmetic operations. In subsequent V4.3.x versions, the new vectorized engine will continue to be used to supplement and improve the implementation of other operators and expressions, aiming to achieve optimal performance in AP scenarios.

• Materialized views

  V4.3.0 introduces the Materialized View feature. Materialized views are a key capability for AP applications. They precompute and store query results, reducing the need for real-time computation to enhance query performance and simplify complex query logic. Materialized views are commonly used in scenarios requiring rapid report generation and data analysis.

  Since materialized views store query result sets to optimize query performance, and there is a data dependency between materialized views and base tables, the data in materialized views must be updated whenever the data in the base tables changes to maintain synchronization. Therefore, the new version introduces a materialized view refresh mechanism, including full refresh and incremental refresh strategies. Full refresh is a straightforward approach where, each time a refresh operation is executed, the system re-executes the corresponding query statements of the materialized view to completely calculate and overwrite the original view result data. This approach is suitable for scenarios with relatively small data volumes. In contrast, incremental refresh only processes the data that has changed since the last refresh. To achieve precise incremental refresh, OceanBase implements a feature similar to Oracle's Materialized View Log, tracking detailed incremental updates in the base tables through logs. This ensures that materialized views can perform fast incremental refreshes. The incremental refresh approach is particularly suitable for scenarios with large data volumes and frequent changes. For more information about materialized views, see Materialized views (MySQL mode) and Materialized views (Oracle mode).