Learn about Ancelus features in the following areas:

Speed

Scalability & Size
Development and Administration
Field Types and Formats



Speed

Data management is ultimately about speed.  You can never have too much speed unless you are forced to achieve it with massive injections of hardware. While computer speeds have increased greatly over the past 30 years, relational databases have made only modest improvements due to the limited gains in disk drive latency.  Multi-core computers have provided almost no relief in relational systems, since it does no good to have more queries queued up waiting for the disk. The next step for these systems is to implement racks of RAID array disk drives in hopes of getting parallel hits.  The expense of this method has led to some creative configurations for disk caching as the next Holy Grail, but when they get to 100% of the database in cache memory the performance improves about ten-fold.

Ancelus delivers speed through the database structure, not through more hardware expense.  Higher speeds deliver opportunities for improvements in user response, concurrent users, smaller hardware, and reduced administration downtime.



-       Transaction Latency: Many database companies publish their benchmarks for a simple lookup process.  This measure is perilously close to useless.  Any system that does only simple lookups doesn't need a database.  The gold standard of database performance is the transaction latency of an insert into a key field. The Ancelus benchmark of 7 microseconds is a new record for a PC (200 million record table). As the database size increases, Ancelus transaction latency increases by about 1 microsecond for each doubling of the number of records in the table.  So in a 1.6 billion record table (three doublings) Ancelus will operate with a predictable and repeatable response of 10 microseconds on our modest development PC. The transaction processing rate at this size is an unprecedented 100,000 transactions per second. This logarithmic performance stands in stark contrast to the behavior of relational systems with an exponential decay with increased size. In the end the real test of data rertieval is the three table join - a practical example of what all databases are required to do.  Ancelus sets another record in this function.  Check out the  benchmarks section.



-       User/application response: For user centric systems the response time of the system is crucial to productivity. Complex systems in relational systems tend to frustrate users and reduce productivity due to slow and unpredictable response.  Solving this problem has become a cottage industry of Artist-Practitioners who know how to "tune" the system to get some speed.  Ancelus maintains three to five orders of magnitude improvement over relational systems in typical applications. The Ancelus advantage grows larger as the systems get larger or more complex. Check the Ancelus performance in the Benchmarks section.



-       Disk drive secondary: Relational databases operate with the disk drive as the primary data store.  Every new transaction puts the data on the disk. Every query finds data on the disk, except for the data in cache memory.  Ancelus sets the disk drive as secondary. New data is stored first in memory, fully indexed, and arrives on the disk with a slight delay.  All indexing and search functions in an Ancelus database are indirect, and occur in memory.



-       Referential Integrity: Most RDBs provide an option to do referential integrity checks during data entry.  It is widely acknowledged that using this feature badly degrades the already limited transaction processing speed of the RDB.  Ancelus automatically maintains referential integrity on every transaction.  There is no option to turn it off.  All of the Ancelus performance benchmarks are based on the full function referential integrity checking.



-       Concurrent users: The number of concurrent users that can be supported is directly proportional to the speed of the supporting database, especially in its locking functions.  Ancelus adds the additional benefit of column level locking (previously described).  We believe that Ancelus is capable of supporting a larger user count than any other database system on a given hardware platform.



-       Administrative functions: The speed of Ancelus is not limited to the operational sphere.  Administrative functions that took hours and even days as 64 bit databases began to grow are now solved in a fraction of a second.  Routine admin functions are performed on a live database.  The most complex function (add a column) takes a full 0.8 seconds in our reference database.



Scalability and Size

Very large datasets are another area where relational systems have failed to keep pace.  Ancelus has the capability to scale to unprecedented size and concurrent user counts while maintaining its exceptional performance.

-       Multi-core CPUs: Ancelus scales linearly with the number of cores available. See the Application Note on Multi-core scaling.



-       Very Large Datasets: Up to 8 Exabytes can be supported in Ancelus. The typical exponential decay of table based systems is now banished to the history books. The Ancelus logarithmic decay profile now assures that prototype systems will continue to perform when scaled to full production.  Full scale system performance is deterministic and predictable, even at the 8 exabyte upper limit of 64 bit addresses. 



-       Hardware size: Even if you have a low transaction volume, the speed and space efficiency of Ancelus will allow a given application to be supported on a much smaller (cheaper) computer. Hardware costs can sometimes be reduced by a factor of 10 to 100 for large or complex applications.



-       Dataspace requirements: Ancelus reduces the size of the dataspace by as much as 80% through two techniques:1)  It eliminates the duplication of data in foreign keys, and 2) variable width field specifications at the transaction level eliminates the sparse matrix problem where some of the reserved dataspace will never be used. 



-       Normalization/de-normalization: Ancelus also eliminates the most common causes of scaling failures - the re-normalization process. In most large systems the table structures need to be "tuned," (normalized or de-normalized) after full scale testing exposes the performance, admin or functional barriers.  Because Ancelus has eliminated tables from the physical structure there is no more "tuning." The first implementation is the final implementation. Ancelus prevents the need for any normalization revisions.  It is always 100% normalized and 100% de-normalized at the same time.  



-       On-line design modifications: When a relational database is deployed, it needs to be right the first time.  The complexity and downtime involved in making significant changes make it painful to revise, and sometimes a days-long process.  Ancelus allows these design changes to be made in fractions of a second while the database is in operation.  Rapid prototyping is now more than a slogan.



-       Concurrent users: The combination of column level locking, spinlocks and blinding speed minimize the chance of collisions by several orders of magnitude. Column level locking allows concurrent write access to separate columns in the same table.  Spinlocks allow a 20 nano second lock/unlock time and the data access time under 100 nanoseconds assures that locked data is returned to service in the shortest possible time.   



-       Reliability and repeatability: The direct network structure of Ancelus assures minimal chance of data corruption.  However when it does occur due to power outage or hardware failures, the verify utility allows the broken links to be detected and corrected without taking the database down.  All database functions in Ancelus (including queries) follow a precisely defined path and are highly repeatable.  Since the only involvement of the operating system is the initial allocation of the memory, the normal variability of OS interface is eliminated.





-       Journaling & Replication: The task of providing a backup for very large datasets is solved with Ancelus. A replication function allows transaction level feed of multiple backups of the master dataset.  The replicate databases can be configured in a star pattern (one master and many replicates) or a sequential chain (Master database feeds replicate A which feeds replicate B). This provides a high degree of flexibility in how backup, recovery and failover schemes are implemented.  During the slight delays during background data transfer, all in-transit information is journaled to assure integrity.



Development and Administration in Ancelus:

The natural structure of information is described as a "threaded network." It is represented by the Entity-relation diagram during the design process.  Relational databases deal with threaded information networks with great difficulty.  Foreign keys require duplication of data, vastly expanding the dataspace, transaction load and administrative time. Tuning the final system is a persistent requirement of relational development.

-          Threaded Networks: The Ancelus data model is a direct logical implementation of n-dimensional threaded networks.  This fundamental change allows Ancelus to deliver a working database directly from the entity-relation diagram with no risk of normalization failure. Design time is greatly reduced (typically 40 to 80%) and performance tuning is completely eliminated.  Ancelus always delivers the shortest path to the data.



-          Tables or Entity-Relation Diagrams: Developers are able to use either design approach with an Ancelus database.  While Ancelus is an inherently threaded network, it retains the table view in "virtual" form as a development convenience. 



-          Normalization: Direct threading and virtual tables eliminate the need to "tune" the database to achieve performance improvements.  The Ancelus schema is always 100% normalized (every record appears to have all the data) and 100% de-normalized (no data is duplicated) at the same time.



-          Locking: Ancelus locks at the column level. This means that a write access to columns 2, 4, and 6 will never collide with a second write access targeting columns 1, 3 and 5. Neither application needs to know about the other.  Neither will detect a delay.



-          Security: Security for read, write and admin permissions is managed at the column or virtual table level.

-          Dynamic Data Dictionary: Ancelus introduces the first non-intrusive implementation of data dictionary modification. Adding a column to the database does not require detectable locking of the database. Weekend-long rebuilds for revisions to the database are now accomplished in less than 100 nanoseconds.  Users are completely unaware of the revisions.



-          Physical storage: Relational tables are organized to store row data contiguously on the disk drive. The goal is to minimize head movement, a performance killer. Ancelus uses a non-contiguous physical storage model. This eliminates the large maintenance times to reorganize the disk layout.  One more administrative nightmare is eliminated.

-          Variable width fields: Ancelus offers variable width fields for all 13 field types supported.  The width is defined as the inherent width of the field type times the count of values to be included with each entry.

o   Fields are declared with field format (type) and entry count (count) in the form of (type,count).  The declaration (F32,3) defines a 32 bit floating point number with 3 values included with each entry.  Missing values are padded with a null value. (see the documentation for the actual format of the specification)

o   If the count is declared as "0" the entry count will be variable and declared as part of each data entry transaction.  Each entry transaction can have a different number of values.  Variable width fields have a fixed overhead of 4 bytes.   

o   When a lookup is executed on a field with count=0, it returns the field declaration before returning the values. All applications should be written to expect this information in the transaction to assure that changes in database specification will not require changes to the application.

Field Types and Formats

Field Types Supported

Field Type	Description
Key	Table of unique (indexed) values
Item	Simple item or value owned by other fields
Foreign Key	Reference to a Key field
Item List	List of (non unique) Items
Key List	List of (unique) Keys
Foreign Key List	List of Foreign Keys
Unowned Item	Block of unstructured rows
Concatenated Key	Unique array of Foreign Keys
Concatenated Key List	Defines the member Keys in a Concatenated Key

Field Formats Supported

Code	Descriptor	Function
0	0	Structured data type, foreign key, concatenated key
1	U8	Unsigned Character
2	I16	Signed 16 bit integer
3	U16	Unsigned 16 bit integer
4	I32	Signed 32 bit integer
5	U32	Unsigned 32 bit integer
6	I64	Signed 64 bit integer
7	U64	Unsigned 64 bit integer
8	I128	Signed 128 bit integer
9	U128	Unsigned 128 bit integer
10	F32	32 bit floating point (single precision)
11	F64	64 bit floating point (double precision)
12	F128	128 bit floating point (quad precision)
13	Event	64 bit timestamp