Ancelus Scalability with Multi-Core CPUs

The performance of any software system is likely to be limited by the underlying database architecture used to implement the system. Large scale projects often encounter serious performance limitations during the migration from the prototype to production phase of the project.

Computer performance has made steady progress as CPUs became faster. Recently the gains have been achieved through the use of multiple cores rather than clock speed increases.  This has presented challenges for relational database systems. The RDBs are unable to take advantage of the additional CPU capacity in most real world applications.  The reason is that these systems are disk limited, and disk latency has improved only slightly in the past 30 years.

While transactions can multi-process in the multiple cores, it won’t improve a disk bound RDB. It doesn’t help to have more cores queued waiting for disk access.  All processes wait at the same speed.

Ancelus is able to make use of the multi-core architecture.  For the addition of N cores, Ancelus delivers about 0.95*N of additional performance.  There are several unique Ancelus features that make this scaling possible. 

Memory Primary – Disk Secondary Architecture: The first step needed to improve transaction rate is to reduce storage access latency. Relational systems use caching or RAID configurations.  If 100% of the RDB is cached in memory, the performance improvement is about 10X.  RAID configurations dramatically increase hardware cost. 

The unique Ancelus architecture delivers 10,000X improvement in typical applications. The radically different Ancelus approach uses the disk as a secondary storage to guarantee non-volatile data persistence. But no Ancelus function has the disk access on the critical path.

Column Centric Tables: Ancelus includes a table view abstraction for stored information. However, the columns in a table row are not stored contiguously if physical storage. Rather, each column in a table is maintained in separate storage and combined into the table view at query time. This approach provides significant performance improvements when accessing a few columns from a table having many columns. The data for an entire row is not required to access a subset of columns. Only the columns of interest are fetched. 

Column Level Locking: Column level locking is provided when updating (changing) a subset of columns in a table. Two processes (or threads) needing to update separate columns in a table do not block. On a multi-processor (multi-core) system, these two threads may proceed simultaneously for a 2X performance improvement. Processes that update separate tables do not block. On an N-core system the performance improvement for this type of activity will be very about 0.95* N times.

Read Locks Don't Block: Ancelus provides read/write locking. Two processes (threads) needing to access (read) the same or separate rows of a table will not block. On an N-core system the performance improvement for this type of activity will be very nearly N times.

Compact Storage Model: Ancelus implements Foreign Keys as links rather than data. Concatenated Keys are implemented as arrays of foreign keys. This can significantly reduce the storage space requirements and eliminates duplication of data. For example, a 40-byte foreign key is implemented as a 4-byte link for a 10X reduction in the foreign key storage space. The reduction in data storage requirements allows Ancelus to maintain full speed access to the database as storage requirements increase.

Ancelus provides a graceful migration path when improved performance is required. Adding more cores to a system design can be accomplished with reasonable cost. Single board computers are currently available with 24 cores and should provide vary nearly 24 times the performance of a single processor system.

An alternative approach to complete redevelopment of underperforming relational applications is to install Ancelus in Paired Operation Mode.  This approach lets Ancelus do the heavy lifting while preserving the investment in the user interface of the relational system.  See the application note on “Relational Accelerator.”