Multi-core CPU scalability
The problem
Computer performance has made steady progress as CPUs become faster. Recent gains have used multiple cores rather than clock speed increases.
This has presented challenges for relational database systems. In most real world applications they are unable to take advantage of the additional CPU capacity because such systems are disk limited.
While transactions can multi-process in the multiple cores, it won’t improve a disk-bound RDB because all processes queue at the same speed. Ancelus is able to leverage multi-core architectures. With N cores, Ancelus delivers about 0.95 × N additional performance.
RAM vs disk
The first step needed to improve transaction rates is to reduce storage access latency, Ancelus adopts a Memory Primary – Disk Secondary architecture.
Relational systems use cacheing or RAID configurations. If 100% of the RDB is cached in memory, the performance improvement is about 10×. And RAID dramatically increases hardware cost.
The unique Ancelus architecture delivers ten thousand times 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 disk access on the critical path.
Columns
Ancelus includes a table view abstraction for stored information, despite using column-centric tables.
The columns in a table row are not stored contiguously in 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.
Locking
Column-level locking is provided when updating a subset of columns in a table. Two threads needing to update (write) separate table columns do not block.
On a multi-processor/core system, processes that update separate tables do not block. On an N-core system the performance improvement for this type of activity will be very nearly 0.95 × N.
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.
Storage
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 data duplication. For example, a 40-byte foreign key is implemented as a 4-byte link for a 10× reduction in the foreign key storage space.
The reduction in data storage allows Ancelus to maintain full speed access to the database as storage requirements increase; even up to exabyte ranges. Plus of course your hardware investment stretches that much further with Ancelus.
Acceleration
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 very nearly 24 times the performance of a single processor system.
An alternative approach to 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.