Ancelus_tm

DBMS

Frequently Asked Questions

Ancelus v. 3.x

Q. What is the current version and status of Ancelus?

A. Current release is version 3.5.1 (includes journaling and real-time replication).  Beta testing of version 3.x started in mid 2007. Limited availability was announced 7/30/2009.  General availability was announced 12/14/2009.

Q: Is Ancelus a hierarchical or network database?

A: Ancelus differs from hierarchical and network databases in several ways:

·     - The ability to directly configure a complete threaded network with any number of chained references,

·     - The ability to enter a list as a database entry

·     - The use of indirect references for foreign keys, and

·     - The use of completely random storage and retrieval of data.

Q.   Is Ancelus a memory resident database?

A. Ancelus is the third generation of memory resident database from the original developers of memory resident database technology.  It differs from the typical relational database locked in memory in several ways:

·     - It replaces tables with a threaded network (it retains a virtual table construct for convenience)

·     - It eliminates the duplication of data and the use of data as indications of relationships

·     - Its uses universal indexing at data entry time

·     - It eliminates all requirement of contiguous storage of the data

Ancelus uses both memory and disk storage, but disk storage is a secondary priority and it is never on the critical path for storage, search or retrieval processes.  Ancelus makes aggressive use of indexes which are always memory resident.  Newly entered or updated data is visible and available within tens of nanoseconds, but may be delayed by hundreds of milliseconds before arriving on the disk.  All secondary data stores (including replicate databases) are journal resident during the interim.

Memory resident relational databases deliver performance improvement of 3 times (Sybase claim) to 10 times (claimed by Times Ten offering from Oracle).  Ancelus improves performance by a factor of 10,000 to 1,000,000.

Q. Does Ancelus support referential integrity checking?

A. Most RDBs provide an option to perform 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 full function referential integrity checking.

Q. How does Ancelus recover from hardware induced corruptions of the database?

A. The Ancelus toolset includes a utility that quickly performs index integrity checking and repair while the database is live and in operation.

Q. Does Ancelus support user level security?

A. Ancelus provides security access for read, write and admin at the column level or virtual table level.  Typical applications can be written to assign this detailed level of security to users as desired.

Q. What is the hardware cost for an Ancelus application compared to a relational system?

A. Ancelus typically reduces hardware cost 40% to 80%.  Ancelus applications will normally require more memory than the relational counterpart, but will reduce the dataspace by about 80% and will run on a much less expensive processor.  Compared to in-memory relational systems an Ancelus system will support a database of about 5 times the size in the same memory space.  In one example a complex, high performance system required a $1 million server for the relational application and was replaced with a $12,000 workstation running at 6% CPU load.  For very large systems (more than a peta-byte the best option is usually multiple low cost servers configured with globally addressable memory.

Ancelus usually requires more memory than relational systems, but recent examples suggest that for very large applications the reverse may be true.  In these challenging applications recommended performance solution seems to specify a very large memory cache for the RDB.

Q. Do I need to convert all my current applications to Ancelus?

A. Not necessarily.  If speed or user responsiveness is the problem, Ancelus can be set up as a cache engine for the RDB.  This may solve the problem without modification to the user interface of the application and will still achieve major hardware cost reductions.

If the RDB problem is structural, a more direct conversion may be necessary.  Ancelus has the ability to directly import and convert relational tables into the Ancelus Threaded Network format.  For user interface conversions, the Ancelus team has developed a methodology for the development of Application Specific Programmer Interfaces (ASPI) which can often eliminate the need for major revisions to the user interface.  In other cases a SQL interpreter is the best solution.

The full efficiency of an Ancelus application is usually achieved through the direct conversion to Ancelus APIs or ASPIs, at least for the critical portion of the application.

A short survey of the current application by a Prevel consultant can provide a preliminary indication of the appropriate approach.

Q. Does Ancelus support web based development tools and network applications?

A. Ancelus can make full use of browser-based interfaces, server languages and client languages.  The Prevel Technology development team supports Windows, Unix and Linux operating systems and their respective toolsets.  These include Internet Explorer, Firefox, Apache, PHP, and JAVA among others.  All current programming languages can be supported.

It is also possible to use the development tools of the RDB manufacturers and then convert the resultant application to Ancelus format.

Q. Is Ancelus available as open source software?

A. No. Prevel retains strict source control over testing and release of Ancelus.

Q. Does Ancelus support SQL queries?

A. The Ancelus design has eliminated the need for complex SQL queries. Since Ancelus has eliminated the use of data as an indirect data reference, there is no need for the complex extraction routines of SQL designed to reconstruct it.  Furthermore Ancelus completely eliminates the sometimes ambiguous relationships that plague SQL queries from relational tables. Threaded Query Language (TQL) provides direct, unambiguous extraction of the target data in a straight line path with dramatically increasing speed, simplicity and reliability.

Q. Why wouldn't I just write my own linked list structures using the facilities in the C programming language?

A. Ancelus started as something like that in 1986.  It took a long time to give it the characteristics of a real, general purpose data management system. If you spend enough time at it you could probably reproduce some of the Ancelus features. But why would you? Would you try to replicate the functions of Oracle or MS SQL or Sybase? Furthermore the critical functions necessary to the success of the Ancelus approach are the subject of the pending patent.

Q. Does Ancelus have a forms development environment?

A. The Ancelus development team uses PHP as the server language and JAVA as the user interface development environment.  Other toolsets can be used as long as the toolset is capable of supporting calls with arguments.

Q.  Does Ancelus require any other middleware?

A. Ancelus ships with Apache, PHP and JAVA included.  These same tools are used on all platforms (UNIX, Linux, Windows) even when there is a native toolset on the operating system.  By keeping the middleware integrated with Ancelus we can assure that our testing standards are always met and that the upgrade environment is always known and controlled.

Q. What operating systems are supported?

A. Ancelus is available for the 32 and 64 bit versions of Linux, Solaris, HPUX, and Windows.

Q. How much improvement should I expect from an Ancelus implementation?

A. For simple systems Ancelus will deliver performance improvements of about 50 to 100 times vs. the typical relational database.  For very large or complex systems, Ancelus may improve basic benchmark performance by 10,000 to 1,000,000 times. The broad range is a result of the dramatic differences in performance in relational systems compared to the relatively stable performance of Ancelus as a function of size and complexity.

Q. Can Ancelus be optimized for data entry or query performance depending on the needs of the application?

A. The unique architecture of Ancelus eliminates the need for performance tuning or even the consideration of these issues through most of the design process.  An Ancelus database will achieve maximum data entry performance and maximum query performance on the first implementation with no tuning required.

There are a number of formatting and-post query data handling questions that still require thoughtful design consideration in the Ancelus environment, but they are not a related to Ancelus performance.