History[06]

Altibase started off as an in-memory database research project at a government-funded research organization in Seoul, South Korea, in 1991. The research project began as an in-depth look at the effects of RAM on traditional relational databases. In 2000, its first version was released for commercial use and by 2003, it entered the Chinese market. In 2005, Altibase commercialized hybrid DBMS, which allowed various clients to utilize both RAM and disk as storage mediums. By 2015, Altibase introduced its scale-out technology, sharding, and three years later went open source. Altibase’s clients span from the telecommunications, finance, manufacturing and utilities sectors.

Altibase went open source in February 2018 and made the system available on GitHub. But the company then decided to remove the source code in March 2023.

Checkpoints[07]

Altibase uses fuzzy & ping-pong checkpoint methods to safely back up the most recent state of the database.

Concurrency Control[07]

Altibase has Multi-version Concurrency Control (MVCC) which provides high throughput with consistency and isolation. It is implemented in different ways for memory tablespaces and disk tablespaces. Altibase uses “Out Place MVCC” for memory tablespaces and “In-Place MVCC” for disk tablespaces. They both superficially appear similar, so there is no need for the user to distinguish between the two.

In Out-Place MVCC, a new version of a record is created and associated with previous versions of the record every time an update operation occurs. In In-Place MVCC, the contents of the columns that belong to the original records and the ones that are being changed, are written as “undo log records” to an undo page. These logs exist in undo tablespace, and the new data is written to the location of the original record.

Data Model[07]

Altibase is a relational database that is also ACID and SQL compliant. Atlibase is compatible and interoperable with Oracle and migrating from another database to Altibase is less complex than majority of other migrations. Altibase also uses sharding technology which allows minimal use of coordinators.

Foreign Keys[08]

Altibase allows for foreign keys.

Hardware Acceleration[08]

Altibase has less CPU utilization than most legacy databases.

Indexes[07]

Altibase supports two types of indexes: B-tree indexes and R-tree indexes. The R-tree index is a multi-dimensional index type for use with spatial queries.

Isolation Levels[07]

Altibase has “read committed” (0), “repeatable read” (1), and “no phantom read” (2), which can be selected appropriately depending on the user’s requirements. Each number refers to the level of which the transaction isolation levels succeeds. These levels are defined by the presence or absence of dirty reads (uncommitted data), non-repeatable reads, and phantom (initially unseen data).

Joins[09]

Although Altibase does not have any optimizations for joins, standard operations such as joins and outer-joins are supported. In addition, Altibase supports joins between memory tables and disk tables.

Logging[07]

Altibase keeps logs for changed database contents. Altibase optimizes the way logs are created in order to achieve the best possible replication performance. Specifically the way this works is that, when data is altered, a log of the transaction is written to a specified and reserved RAM space. These logs are flushed to disk periodically. After the logs surpass a certain size, as a second backup, a datafile is written.

Parallel Execution[10]

Altibase can scale vertically and horizontally via sharding. Altibase can automatically account for the addition of new RAM and faster processors which results in an immediate performance increase.

Query Compilation

Altibase creates service threads for query processing and put them in the Service Thread pool. For every user configuration when the server is started, a number of service threads increases.

Query Interface[07]

Altibase supports SQL92 and SQL99 standard, and also provides extended features. Altibase also supports ODBC, JDBC and C/C++ Precompiler.

Storage Architecture[07]

Altibase is a hybrid database. It can access both memory-resident and disk-resident tables. It offers ACID compliance and can support both synchronous and asynchronous replication.

Storage Organization[11]

Tables are ordered in regards to the node that created them along with the type of storage. Memory hash tables scan and save records in two methods - the bucket method or the partitioning method. The bucket method saves records in buckets in a list format, and scans the records through these buckets. On the other hand, the partitioning method keeps the records in a list, but scans records by partitions.

Stored Procedures[07]

Altibase supports stored procedures and triggers, which is automatically executed by the system in order to accomplish a particular task when data modified from a table.

System Architecture[07]

Altibase is a shared-nothing DBMS which provides sharding. It has a distributed architecture where all the nodes work independently of each other to satisfy a given query, and report back to the master node when done. The nodes don’t share any memory or disk space and the data within nodes are distributed across nodes through a distribution key.

Views[12]

In order to accelerate the performance and reduce the size of materialized views, columns that are not referenced by the user are excluded.