Open Source RDBMS - Seamless, Scalable, Stable and Free

한국어 | Login |Register

Versions available for this page: CUBRID 8.2.1 |  CUBRID 8.3.0 |  CUBRID 8.3.1 |  CUBRID 8.4.0 | 

CUBRID Features

Transaction Support

CUBRID supports the following features to completely ensure the atomicity, consistency, isolation and durability in transactions.

  • Supporting commit, rollback, savepoint per transaction
  • Ensuring transaction consistency in the event of system or database failure
  • Ensuring transaction consistency between replications
  • Supporting multiple granularity locking of databases, tables and records
  • Resolving deadlocks automatically
  • Supporting distributed transactions (two-phase commit)
Database Backup and Restore

A database backup is the process of copying CUBRID database volumes, control files and log files; a database restore is the process of restoring the database to a certain point in time using backup files, active logs and archive logs copied by the backup process. For a restore, there must be the same operating system and the same version of CUBRID installed as in the backup environment.
The backup methods which CUBRID supports include online, offline and incremental backups; the restore methods include restore using incremental backups as well as partial and full restore.

Table Partitioning

Partitioning is a method by which a table is divided into multiple independent logical units. Each logical unit is called a partition, and each partition is divided into a different physical space. This will lead performance improvement by only allowing access to the partition when retrieving records. CUBRID provides three partitioning methods:

  • Range partitioning: Divides a table based on the range of a column value
  • Hash partitioning: Divides a table based on the hash value of a column
  • List partitioning: Divides a table based on the column value list
HA Functionalities

High Availability (HA) refers to ability to minimize system down time while continuing normal operation of server in the event of hareware, software, or network failure; that is, the CUBRID HA is functionality that is applied to CUBRID. The CUBRID HA feature has a shared-nothing architecture. The CUBRID performs realtime monitoring for system and CUBRID state with the CUBRID Heartbeat. Then in case of system failure, it automatically performs failover. It follows the two steps below to synchronize data from the master to the slave database servers.

  • A transaction log multiplication step where the transaction log created in the database server is replicated in real time to another node
  • A transaction log reflection step where data is applied to the slave database server through the analysis of the transaction log being replicated in real time
Replication

Replication is a technique that duplicates data from one database to other databases to improve performance and increase server availability by distributing requests from applications that use the same data into multiple databases. Currently, CUBRID supports replication only on Linux and UNIX. The CUBRID replication system runs based on transaction logs, and it provides real-time replication and ensures transaction consistency/schema independence of the slave database. Additionally, it offers a feature for a master database to be minimally affected by replication. The replication feature consists of the following components:

  • Master database: The source database that becomes the target to be replicated. All operations including a read and write operations are performed in this database. Since the replication is performed asynchronously, there will be no effect on the master database administration. Replication logs are created in the master server, which are sent to the slave server via the replication server and the replication agent.
  • Slave database: The database replicated from the source database. It allows a client a read operation only in the salve database. If a write operation occurs in the master database, the transaction is automatically replicated to multiple-slave databases, so read operations can be distributed on multiple databases.
  • Distribution database: Saves the information about the master and the slave databases. It ensures transaction consistency and effects replication to be distributed.
  • Replication server: The replication server runs on the master system and transfers a transaction log in the master database to the replication agent.
  • Replication agent: The replication agent is a process that runs on the slave system and performs the actual replication tasks by analyzing and applying the transferred replication log to the slave database server.
Java stored procedure

A stored procedure is a method to decrease the complexity of applications and to improve the reusability, security and performance through the separation of database logic and middleware logic. A stored procedure is written in Java (generic language), and provides Java stored procedures running on the Java Virtual Machine (JVM). To execute Java stored procedures in CUBRID, the following steps should be performed:

  1. Install and configure the Java Virtual Machine
  2. Create Java source files
  3. Compile the files and load Java resources
  4. Publish the loaded Java classes so they can be called from the database
  5. Call the Java stored procedures
Click Counter

In the Web, it is a common scenario to count and keep the number of clicks to the database in order to record retrieval history.

The above scenario is generally implemented by using the SELECT and UPDATE statements; SELECT retrieves the data and UPDATE increases the number of clicks for the retrieved queries.

This approach can cause significant performance degradation due to increased lock contention for UPDATE when a number of SELECT statements are executed against the same data.

To address this issue, CUBRID introduces the new concept of the click counter that will support optimized features in the Web in terms of usability and performance, and provides the INCR function and the WITH INCREMENT FOR statement.

Extending the Relational Data Model

Collection

For the relational data model, it is not allowed that a single column has multiple values. In CUBRID, however, you can create a column with several values. For this purpose, collection data types are provided in CUBRID. The collection data type is mainly divided into SET, MULTISET and LIST; the types are distinguished by duplicated availability and order.

  • SET : A collection type that does not allow the duplication of elements. Elements are stored without duplication after being sorted regardless of their order of entry.
  • MULTISET : A collection type that allows the duplication of elements. The order of entry is not considered.
  • LIST : A collection type that allows the duplication of elements. Unlike with SET and MULTISET, the order of entry is maintained.

Inheritance

Inheritance is a concept to reuse columns and methods of a parent table in those of child tables. CUBRID supports reusability through inheritance. By using inheritance provided by CUBRID, you can create a parent table with some common columns and then create child tables inherited from the parent table with some unique columns added. In this way, you can create a database model which can minimize the number of columns.

Composition

In a relational database, the reference relationship between tables is defined as a foreign key. If the foreign key consists of multiple columns or the size of the key is significantly large, the performance of join operations between tables will be degraded. However, CUBRID allows the direct use of the physical address (OID) where the records of the referred table are located, so you can define the reference relationship between tables without using join operations.

That is, in an object-oriented database, you can create a composition relation where one record has a reference value to another by using the column displayed in the referred table as a domain (type), instead of referring to the primary key column from the referred table.