Table model
In the table model, data is highly constrained by the schema, just like SQL tables.
You can execute a DDL statement to create a table. All types of partitioned tables of OceanBase Database are supported. The table must contain a primary key and several strongly-typed columns. You can also define secondary indexes and a UNIQUE constraint for the table.
OceanBase OBKV-Table provides table model-based API operations that can be seamlessly integrated or used with SQL statements in OceanBase Database. In addition to the query operations, table model-based API operations support data reads and writes by using the primary key.
Secondary index
You can create indexes for a table. Table indexes will be updated in all OBKV-Table operations.
The Query operation enables you to query and scan data based on secondary indexes. However, the regular KV model allows you to query data only by the primary key, which is not enough in many business circumstances. As a result, you must maintain an index table at the business layer if your applications use a database of the simple KV model that supports only primary key-based queries. This complicates the processing of business data and makes it difficult to ensure data consistency between the indexes and the primary table. In addition, reading and writing the index table require multiple interactions between the application and database, which results in high latency.
OceanBase OBKV-Table solves the preceding problems by providing native support for secondary indexes on the server side.
Security authentication
OBKV-Table operations are authenticated in the same way as in SQL mode. OBKV-Table allows you to execute SQL statements to manage tenants, users, and passwords.
Comparison with the SQL mode
OceanBase OBKV-Table provides table model-based API operations that can be seamlessly integrated or used with SQL statements in OceanBase Database. This section describes the advantages and disadvantages of OBKV-Table in comparison with the SQL mode.
Advantages
- OBKV-Table is designed based on a distributed storage layer, bringing shorter data access paths and better performance for equivalent functionality. Its simpler semantics make it easier to optimize, leading to more predictable performance.
- Batch operations have more flexible and efficient semantics when compared with the SQL mode. For example, a multi-get operation can select different columns for different rows.
- The API interface is straightforward, providing entity semantics directly without the need for complex ER mappings.
- It uses a simple RPC protocol, eliminating the need for reconnection that is typical with traditional JDBC/ODBC interfaces. It is also largely unrestricted by connection numbers (though currently limited by the RPC framework).
Disadvantages
- The query functionality of OBKV-Table does not match that of the SQL mode, offering limited features such as get, scan, and limit. For aggregation and sorting features, the SQL mode should be used.
- OBKV-Table does not provide interactive transactions or complex transaction capabilities. Unlike traditional relational databases, OceanBase Database itself operates as a feature-rich NewSQL relational database, where the consideration for using OBKV-Table is not solely based on its high scalability and availability.
- OBKV-Table does not support global indexes and therefore cannot operate on tables related to global indexes.
KV model
The KV model is essentially a simplified relational table model. When a table of the KV model is created, it has only two columns: K and V. This table is partitioned based on K or the prefix of K. Here is an example:
create table kv (
K varbinary(1024),
V varbinary(1024),
primary key(K)) partition by key(K) partitions 16;