Altibase Enables a Mega Telco to Have Big Data at Its Fingertips Through Its Cutting-Edge Scale-Out Technology, Sharding

Altibase Enables a Mega Telco to Have Big Data at Its Fingertips Through Its Cutting-Edge Scale-Out Technology, Sharding

A common belief is that relational databases lack horizontal scalability and have limitations in handling large data sets. Altibase has proven that this belief is no longer valid.

NEW YORKSept. 17, 2018 /PRNewswire/ — This September, Altibase announces that a mega telco with hundreds of millions of subscribers has recently adopted Altibase for its sharding.

The telco had reached the breaking point due to an ever-increasing influx of data as its subscribers were rising exponentially, and the company had to add more and more services to stay competitive.

The company once considered adding new, more powerful high-end servers, but soon abandoned the option because it would break the telco’s budget. Instead, the telco decided to scale out its databases with the addition of cheap/economical commodity servers.

However, this option posed a problem too. Very few database vendors provided sharding technologies. And those that did were not relational databases. The vast majority of the telco’s applications ran on relational databases.

Then, the telco found Altibase — a relational database providing sharding technology.

Using Altibase’s sharding, the telco kept its existing servers and just added inexpensive commodity servers as needed — at a small fraction of the cost of the first option’s expensive high-end servers.

And using Altibase’s sharding, the telco didn’t have to make any changes to its existing systems running on relational databases. The execution was easy and quick.

With Altibase, the telco experienced almost no coordinator-related bottlenecks. And no matter how many servers were added, linear performance enhancement was maintained.

In sharding, coordinators are needed to manage and administer nodes between servers. But coordinators themselves are often a bottleneck, and the performance deteriorates as a result. Altibase is designed to super-minimize the use of coordinators and thus can accelerate performance.

Thanks to Altibase, the telco got just what it needed: big data at its fingertips.

After nearly 20 years as a closed source database, Altibase is now open source — and that includes its state-of-the-art sharding.

Learn more about Altibase at https://youtu.be/pooexk0glK8, and download its open source database including sharding at http://altibase.com.

Altibase provides better safety than Oracle TimesTen with minimum exposure to database corruption

How does Altibase compare to Oracle TimesTen and other in-memory databases?

Sep 13, 2018

Untitled design (9)

Altibase provides superior performance in comparison to Oracle TimesTen and other in-memory DBMSs. Representative examples include 99.999% HA, horizontal and vertical scalability, hybrid DB technology and more. When compared against Oracle TimesTen, Altibase excels in overall performance and especially in complex queries, and its data durability in system failure situations is more stable.

Altibase provides various communication channels (TCP/IP, SSL/TLS, Unix Domain Socket, IPC and IPC-DA) to optimize performance.

Altibase’s IPC-DA and Oracle TimesTen’s DA are similar in that both allow applications to directly read and write data to shared memory, which minimizes memory access and maximizes access performance. However, Altibase’s IPC-DA compares favorably to Oracle TimesTen’s DA because the former is safer than the latter. With Altibase’s IPC-DA, a client program accesses only a communication buffer, not data itself, so that it is not possible for the data to be exposed to corruption whereas Oracle TimesTen’s DA accesses a database directly so that data in the database is always potentially exposed to corruption.

Altibase has competed neck and neck particularly with Oracle TimesTen. The following case studies include related stories.

Altibase vs. Other In-Memory Databases

Category

Items

Altibase

Oracle TimesTen

IBM SolidDB

SAP HANA

Communication Channel

Direct Access

Supported

Supported

Not Supported

Not Supported

Lock Mechanism

MVCC

Supported

Supported

Supported

Supported

Functionality

SQL

SQL92, SQL99

SQL92, SQL99

SQL92, SQL99, SQL2003

SQL92, SQL99

Replication

Supported

Supported

Supported

Supported

Performance

(Complex Queries)

TPC-H

High performance

Low performance

Low performance

High performance

Productivity

Development

Convenience

APRE, PSM(PL/SQL)

ProC, PL/SQL

SA API, procedure

Precompiler Not offered, stored procedure

Usability

Management Tools

Orange

Oracle Enterprise Manager

Solid console

SPS 07

Platforms

Fully supported

Fully supported

Fully supported

Fully supported

Interactive SQL Tool

Supported

Supported

Supported

Supported

Storage Management

On-Disk Table

Supported

Not supported

Not supported

Not supported

Multiple DB Files Configuration

Supported

Not supported

Not supported

Supported

DB Autoextend

Supported

Not supported

Not supported

Supported

Replication

1:N way

Supported

Supported

Supported

Supported

Replication b/t Heterogeneous Systems

Supported

Supported

Supported

Supported

Replication Unit

Table

Table, database

Table

Table

Offline Replication

Supported

Not supported

Not supported

Not supported

Transaction

Save-Point

Supported

Supported

Supported

Supported

Rollback

Supported

Supported

Supported

Supported

Stability

DB Backup

Offline, online, logical, incremental

Offline, online, logical, incremental

Offline, online, logical backup

Offline, online, logical backup

Range of Data Recovery

Transaction, media,
system failure

Transaction, media,
system failure

Transaction, media,
system failure

Transaction, media,
system failure

Interface

Embedded SQL

Supported

Supported

Supported

Supported

ODBC

Supported

Supported

Supported

Supported

JDBC

Supported

Supported

Supported

Supported

XA API

Supported

Supported

Supported

Not supported

SQLCLI

Supported

Supported

Supported

Not Supported

C API

Supported

Supported

Supported

Not Supported

Advanced SQL

SQL Plan Cache

Supported

Not supported

Not supported

Supported

Queue Table

Supported

Not supported

Not supported

Not supported

DB Link

Supported

Not supported

Not supported

Supported

 

Altibase – Downloading is Believing.

Altibase supports data partioning for easier management of a large dabase object

Does Altibase support data partitioning?

Yes. Data partitioning is the division of a large database object into several small pieces for easier management. Objects can be partitioned in three ways: list, range and hash.

Sep. 5. 2018

Altibase’s Partitioning Technology

These three ways of partitioning can be selectively used according to data size, data type, data usage, data density and other database requirements.

3 Types of Altibase’s Partitioning

 data-partitioning

Description:

  • List partitioning: Each partition is defined and selected based on the membership of the column value in one of lists composed of discrete values.
  • Range partitioning: Each partition contains rows for which the partitioning expression value lies within a given range.
  • Hash partitioning: Used to ensure an even distribution of data

 

Altibase scales vertically and horizontally. Altibase scales up via auto-extend in-memory tables and scales out via sharding

Does Altibase support vertical and horizontal scaling?

Sep. 4. 2018

Altibase can scale vertically and horizontally without any issues. Altibase can automatically account for the addition of new RAM and faster processors. In doing so, there will be an immediate performance increase. Altibase also can scale out horizontally via sharding. Please refer to the manual “Altibase Sharding Guide” for further information.

Vertical Scaling

Altibase’s products are designed for optimal vertical scalability. A key feature is Altibase’s ability to auto-extend in-memory tables.

10_How does Altibase handle scale-up and scale-out-1


Horizontal Scaling via Sharding 

  • Altibase sharding utilizes both of server-side and client-side sharding architecture.
    • Applications do not need to change anything.
    • Applications only need to know the IP and port of the meta DB of Altibase sharding.
  • Altibase sharding is fast.
    • A shard connection gives execution order of a distributed query directly to a shard node without any intervening middleware.
  • Altibase sharding supports SQL standard.
    • distributed query
    • non-distributed query

Sharding-Image-v1

Altibase – Downloading is Believing.

Altibase prevents data loss with 4 different durability levels so that users can control a balance between performance and durability

How does Altibase prevent data loss?

Aug. 30. 2018

Altibase provides multiple durability[1] levels so that a user can select an optimal durability with consideration of its business. For example, Altibase Enhanced Durability level guarantees no data loss with abnormal DBMS shutdown while Altibase Strict Durability level recovers 100% data without any data loss even with abnormal hardware shutdown including power failure.

Durability depends on how to write transaction redo log on disk. The four durability levels are decided on transaction redo log journal mechanism. The four durability levels are ‘No Durability’, ‘Relaxed Durability’, ‘Enhanced Durability’ and ‘Strict Durability’. With multiple durability levels, a user can control a balance between performance and durability.

No Durability

When a table is created in a volatile tablespace, this table works based on No Durability. A volatile tablespace is a kind of tablespaces Altibase supports in which all data is volatile so the data is not recoverable when Altibase restarts. No transaction redo log is written in No Durability. This shows the highest performance among the four durability levels.

Relaxed Durability

A transaction does not wait until logs have been written to disk and a memory log buffer is used

Set COMMIT_WRITE_WAIT_MODE and LOG_BUFFER_TYPE to 0 and 1, respectively. With this method, transactions store their update logs in a memory log buffer, and the log flush thread itself flushes the logs in the log buffer to the log file. Although there will be no data loss with normal shutdown, there could be a bounded data loss with abnormal DBMS shutdown using this durability level.

FAQ_Fig1

 

Enhanced Durability

A transaction does not wait until logs have been written to disk and a kernel log buffer is used.

Set COMMIT_WRITE_WAIT_MODE and LOG_BUFFER_TYPE to 0 and 0, respectively. With the default Altibase durability property settings, update logs are stored in the log buffer of the OS kernel area, and transactions do not wait until their update logs have been written to the log file. The Enhanced Durability level guarantees no data loss with abnormal DBMS shutdown, but there could be a bounded data loss when there is abnormal hardware shutdown such as power failure.

FAQ_Fig2

 

Strict Durability

A transaction waits until logs have been written to disk and a kernel log buffer is used.

Set COMMIT_WRITE_WAIT_MODE and LOG_BUFFER_TYPE to 1 and 0, respectively. With this method, transaction update logs are stored in the log buffer of the OS kernel area, and logs for committed transactions are written directly to a log file. The Strict durability level recovers all of data without any data loss even with abnormal hardware shutdown including power failure. This shows the lowest performance among the durability levels.

FAQ_Fig3

[1] Durability, which is one of the four properties of a transaction, means that after a transaction has been committed, the committed transaction must be guaranteed, even if a database failure occurs before the changed data are physically written to disk.

Altibase – Downloading is Believing.