HomeAncelus TopicsFrequently Asked Questions

Frequently Asked Questions

Q. Is Ancelus an operational database or an analytical database?

A. Ancelus can be configured as either or both in a single database. Ancelus can implement multiple schema's, all live, so the different views needed for analytics can co-exist with a structure intended for high performance streaming.  The total transaction load in the merged mode needs to be below 256 million TPS.  

An alternate implementation would use the Ancelus real-time replication tools. This would use two databases, each configured for a particular role.  In this mode both databases are operating on up-to-the-microsecond data.  The operational database would be primary and the analytics database would be the replicate.  Depending on total load, the persistent store might be configured on a third system.

Q. How are the various benchmark numbers measured, and how is full scale performance estimated?

A. Most Ancelus benchmarks are run on our 32 core server.

The QUERY performance of Ancelus is measured in a three table join test.  It runs in multiple cores in parallel:

         - 4.6 billion TPM (76.7 million TPS), billion row main table (see Benchmarks page for details)

 The R/W latency is stated for a single core and translates as follows:

        - 200 nanosecond simple R/W = 5 million single core TPS.  

                       If the R/W stream targets a single column, performance is 5 million TPS.                

                       If the R/W stream targets 32 different columns, performance scales to 5 x 32 x 80% (multi-cpu scale factor) = 128 million TPS. 

        - 100 nanosecond stream to a linked list = 10 million single core TPS.  

                       If the R/W stream targets a single column, performance is 10 million TPS.               

                       If the R/W stream targets 32 different columns, performance scales to 10 x 32 x 80% (multi-cpu scale factor) = 256 million TPS.

Ancelus also has the ability to perform query and R/W at the same time.  This estimate is best made by simulation of an actual application.

The multi-cpu scale factor is a function of how the Linux operating system allocates computing power.  Multiple cores on a single cpu scale at about 94%.


Q.  How do you query the Ancelus database?

A.  There are three primary tools to query Ancelus datasets:

1. Native APIs are accessible from a command prompt or programmatically with arguments.

2. ASPIs (Application Specific Programmer Interface) are custom interfaces that translate application-oriented queries into the appropriate native API calls.

3. TQL (Threaded Query Language) includes a Real-time Query Builder.  It is a new tool that uses point-and-click + real time results to develop a query.


APIs are the choice of most advanced developers experienced with the logical structure of Ancelus.  They are fast to use and easy to integrate.  They have the disadvantage of requiring the developer to keep the logical structure of the database straight in their head.


ASPIs have the additional advantage of providing true code and data separation.  If the application software changes and needs to issue new queries, no database change is required.  The reverse is also true.  The developer does not need to remember the logical structure of the database, only the common queries of the application.  These translators are usually 1 to 5 pages of code and can improve productivity for queries tant are used many times.


TQL is a further advancement in Ancelus query methods.  The following is a simple example (qualifiers excluded). 


  • The series of graphics on the Ancelus blog stream shows how you would build a query using point and click methods of TQL Visual Query Builder (currently in development).

  • As the query is defined, the query bar displays the XML (JSON available soon) version of the query in a single string. An indented version of the query is shown below.

  • The query can be saved in the database for later execution, or saved as a script that can be embedded in a program, or executed from the TQL VQB screen.

  • Delimiter is set when the TQL interpreter is called.

  • The TQL script could be typed directly into a program if preferred, but that eliminates the advantage of the real-time test display built into the Visual Query Builder.

  • First version of JDBC bindings is now in testing.  PHP to follow.

  • The following example includes 5 tables (identified in the output as 0 thru 4), some as nested lists.  PUL is a three way concatenated key of process/user/location, embedded as a foreign key in the Events table.

  • The output format is arbitrary, and can be piped to other applications.  Excel is the most common for small result sets.



 <TQL dlim="|">

 <!-- This is Threaded Query Language (TQL) file. -->

        <KEY as='U'>Unit


               <FKEY> FanOutMember  </FKEY>




               <LIST as="E">EventsForUnit






                      <LIST as="T">TagList


                      </LIST  >


               <LIST as="FO">FanOut</LIST>

               <LIST as="FI">FanIn</LIST>




Truncated Output:

 ******* Column Names *******






 ******* Row Data *******


 <1>1214402134 0|1|256|18


 <1>1214402155 0|1|16384|18


 <1>1214402167 0|1|512|18


 <1>1214402171 1|0|128|18


 <1>1214402237 0|0|16384|18



 <1>1214402239 0|0|16384|18


 <1>1214402252 0|0|16384|18



 <1>1214402275 0|0|1024|18


 <1>1214402279 0|0|16384|18


 <1>1214402281 0|0|16384|18





 <1>1201201832 0|111|256|ADMI





Go to top View Our Stats