Relational Accelerator



Ancelus as a Relational Database Accelerator

Paired Operation Mode


Ancelus can operate as either a stand-alone database system or as an accelerator engine paired with a relational database.  In the latter mode Ancelus serves as a high performance index engine for the RDB, but without the heavy overhead burden incurred with indexing in relational systems.

Application: The usual reasons for the use of Ancelus Paired Operation (APO) mode rather than stand alone mode include the desire to avoid either the application conversion cost or the development staff training costs when introducing a new technology. In some cases the justification is more severe, as when a newly-developed application fails to perform when scaled from the prototype to production environment.

Configuration and Installation: Installing Ancelus as a "front end" for an existing application involves intercepting the incoming data stream and query stream of the application, and then resolving the transaction in Ancelus. Any necessary updates to the RDB are executed as a background task with less concern for the inherent RDB delays.  For transactions not configured in Ancelus, the transaction is routed directly to the RDB.

The configuration of APO mode involves selecting the tables to be duplicated in Ancelus (an Ancelus utility aids this task).  In addition the transaction override feature in the RDB is set up with the comparable Ancelus calls.  From that point on the operation is completely transparent.

Security: In most examples of APO mode, the RDB is the master data repository with Ancelus serving as a sophisticated version of cache memory.  The journaling functions of the RDB are the primary security function for data in transit.  For critical data applications a replicate version of the Ancelus database can serve to assure near absolute data integrity of data-in-transit during hardware of power failures. 

Advantages: The primary advantage of APO mode is the increase in response time and throughput of the Anclelus database.  Transaction latency of 6 microseconds and throughput measured in hundreds of thousands of transactions per second (100 million row table keyed insert benchmark) exceed relational systems capability by two to four orders of magnitude. This usually means that exotic hardware is no longer required to tackle the most demanding applications.

Another important capability that Ancelus APO mode delivers is the full utilization of multi-core CPUs.  Relational systems are inherently restricted to single core operation by the table structure -  a defining characteristic of all RDBs. Ancelus is able to take full advantage of multi-core CPUs and will scale at 95% utilization for additional cores.  For each additional core added to the hardware, Ancelus delivers 95% incremental performance (PerfMultiplier=kn where k=0.95 and n=number of cores).

Supported by the extreme speed, multi-core scaling, column level locking and patented indexing process, Ancelus application scale-up is virtually assured. 

Some Ancelus performance features are not available in APO operation. One obvious example is dataspace compression. The Ancelus dataspace is an incremental addition to the RDB dataspace. And of course the performance improvements apply only to those tables and queries that have been configured to operate in APO mode.

The following table provides an overview of relative performance on a PC platform.

Relational Database Comparison

SQL range select

Table 1: 200 million rows, 2 columns

Table 2: 1 million rows, 2 columns

Table 3: 100,000 rows, 2 columns

12,000 hits in range

Three Table Join Results

Benchmark

RDB

Ancelus

Ratio

First Return

230 sec

270 micro sec

850,000:1

Full List

230 sec

33 milli sec

7,000:1

Insert Transaction Latency


6 micro sec

7,000:1

Transactions / Second

53 T/s

371,000 T/s

7,000:1

$/Trans/Second (hardware)

$2,264

$0.32

7,000:1

Transactions / Second (Dual Core)

53 T/s

722,000 T/s

13,000:1

$/Trans/Second (hardware)

$2,264

$0.17

13,000:1

Add Column

3,940 sec

800 milli sec

5,000:1

Lock time

3,940 sec

<100 nano sec

4x10^13:1

Out of Service

3,940 sec

0

NA

Dataspace Compression



14.1  GB

3.2 GB

77%

Until Ancelus the normal method for improving RDB application performance has been to lock a portion of the RDB in memory, or to use one of the available memory-resident databases.  This approach achieves a typical 10x improvement in performance by eliminating most "prime-time" disk access transactions.  But the inherent limitations caused by the table structure remain.  Large dataspace (now in memory), complex query structure (SQL), and the inability to make use of multi-core computers. 

Ancelus eliminates all the patches in one step.