CUBRID ( "cube-rid") is an open-source SQL-based relational database management system (RDBMS) with object extensions developed by CUBRID Corp. for OLTP. The name CUBRID is a combination of the two words cube and bridge, cube standing for a space for data and bridge standing for data bridge.
License policy
CUBRID has a separate license for its server engine and its interfaces. The server engine adopts the Apache License 2.0, which allows distribution, modification, and acquisition of the source code. CUBRID APIs and GUI tools have the Berkeley Software Distribution license in which there is no obligation of opening derivative works. The reason of adopting two separate license systems is to provide complete freedom to Independent software vendors (ISV) to develop and distribute CUBRID-based applications.
Architecture
The feature that distinguishes CUBRID database from other relational database systems is its 3-tier client-server architecture which consists of the database server, the connection broker and the application layer.
Database server
The database server is the component of the CUBRID database management system which is responsible for storage operations and statement execution. A CUBRID database server instance can mount and use a single database, making inter-database queries impossible. However, more than one instance can run on a machine.
Unlike other solutions, the database server does not compile queries itself, but executes queries precompiled in a custom access specification language.
Connection broker
The CUBRID connection broker's main roles are: management of client application connections caching and relaying information (e.g. query results) query syntax analysis, optimization and execution plan generation
Also, a local object pool enables some parts of the execution to be deferred from the database server (e.g. tuple insertion and deletion, DDL statements), thus lowering the database server load.
Since the connection broker is not bound to the same machine as the database server, CUBRID can take advantage of the hardware resources of several machines while processing queries on a single database.
Application layer
Applications can use one of the available APIs to connect to a CUBRID connection broker.
Features
High Availability
CUBRID High Availability provides load-balanced, fault-tolerant and continuous service availability through its shared-nothing clustering, automated fail-over and manual fail-back mechanisms.
CUBRID's 3-tier architecture allows native support for High-Availability with two-level auto failover: the broker failover and server failover.
Broker failover
When connecting to a broker via a client API, users can specify, in the connection URL, a list of alternative hosts where brokers are listening for incoming requests. In case of a hardware, network, operating system or software failure on one of the hosts, the underlying client API automatically fails over to the next host that a user has provided.
Server failover
The High Availability environment can be built with 1:N master-slave server nodes. Each slave node communicates with the master via CUBRID Heartbeat protocol. When a master node is unresponsive, the first of the slave nodes will get promoted to a master role. Replication between nodes can be achieved in one of two modes: synchronous and asynchronous.
Administrators can specify a list of server hosts each broker can connect to and, in the event of a failure of the master node, another will be used.
Scalability and Maintainability
Backup
CUBRID supports online, offline and incremental backup.
Performance
API-level load balancing
Because a connection broker can be configured in four different modes (read-write, read-only, slave-only, preferred host read only), the list of alternative hosts which a user has provided via the connection URL can be used as a method to balance the load. When Load Balancing is used, the client API will randomly choose a host among those specified in the connection URL except the one which was used to connect to last time. If the chosen host is not available, the selection will continue until all the hosts are determined as unavailable. In such case, the driver will report an error.
Query plan caching
A query execution plan cache is implemented on the broker in order to skip most of the compilation steps on often used queries. Because the queries are parametrized during parsing, two queries that differ only by the values of literal constants share the same cache entry.