Hey! Have You Heard About Ancelus?

Hey! Have You Heard About Ancelus?

Ancelus is a patented ACID-compliant database system that replaces pre-defined storage structures with an algorithmic process delivering constant performance at any size or complexity.

John Layden, CEO of Time Compression Strategies, the manufacturer of the Ancelus database management system, has been posting informative tidbits on the strengths and capabilities of Ancelus here on LinkedIn the past few months. In today’s post, I want to share some of these insightful posts with my audience.

One of the first things that DBAs and database practitioners think about when it comes to implementing a database is efficiency. John writes “Speed is the most fundamental measure of database performance. The patented Ancelus database handles a simple R/W operation in under 100 nanoseconds regardless of the size of the database (up to 16 exabytes).” 

Of course, speed alone is not enough to warrant the implementation of any technology, and that is especially so for a DBMS. As John writes: “In the real world we don’t build systems from benchmarks.” Ancelus can perform many complex operations simply, and efficiently. “So, if your goal is to improve throughput (number of concurrent users), shrink hardware, or get better latency (response time to each query), you can use Ancelus to address the challenge.”

Ancelus tackles complexity algorithmically; “Ancelus tables are virtual tables. The relationships are defined algorithmically, rather than by the physical storage structure.”  

Concatenated keys are used in any database that uses an index on a combination of more than one column or field. John writes: “In relational systems the method is to create a table with each of the key fields, then index on the combination. The data in the new table is a copy of the original source data (which now exists in two places).” This redundancy of data storage is eliminated in Ancelus because it works differently. As John explains: “Assume we are interested in three 40-byte key fields, the concatenated table will appear to be 120 bytes wide (plus the index). In Ancelus that actual table will only be 12 bytes wide (plus the index), since the Ancelus table is virtual and contains no actual data. It contains pointers to the actual data and in the 4 series system, the pointer is 4 bytes.”

Another crucial aspect when evaluating DBMS technology is reliability, and the elimination of downtime, both unplanned and planned. John writes: “Uptime is important. In operational systems it can be critical. To eliminate the root causes of downtime requires a passionate focus on the mundane world of what happens in the real world rather than the demo.

Furthermore, John writes about the Ancelus approach of using linked lists: “One of the most important features of the Ancelus database is the native list handling architecture. While the idea of double-linked-lists isn't new (found in most textbooks), the Ancelus implementation is unique … A double-linked-list provides an opportunity for bi-directional traverse of the data structures.

And finally, Ancelus can work with your existing database systems in a complementary and useful manner. Perhaps you have existing applications using a relational DBMS, like Db2 or Oracle, but there are a couple of poorly performing trouble spots. As John explains: “Many existing applications work fine except for a few problem segments (complex reports, for example). A simple path forward may be to build a hybrid system using Ancelus as a streaming cache or side-arm join engine for the troubled parts of the application.

I hope you have found this introductory overview of Ancelus interesting and worthy of further investigation. If so, be sure to take the time to click through these links and read more about the Ancelus database system and how it might be able to assist your complex application and system development.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了