This is a legally copyrighted work,
so none of it can,
legally or honorably,
be copied, used, or claimed by anyone other than the owner.

__________________________________________________
Document Stats

Most recent update	20230707
approx. words

__________________________________________________
Important

All tests were run on mechanical disk drives.
To get a rough feel for the impact of solid
state drives, move decimal points two places
to the left in the published test durations.

This address is: jragan.com/axletests.htm#10.85.00

__________________________________________________

__________________________________________________
__________________________________________________

Contents Of This Document

AxleBase Technology
Copyright 2003 - 2023 John E. Ragan.

__________________________________________________
__________________________________________________
AxleBase Tests
Section
System Snapshot

__________________________________________________
__________________________________________________
AxleBase Tests
Section
Test:   Very Large Table (VLT) Build

This address:   jragan.com/axletests.htm#10.85.05

Objective :
      Test ability to build and control a very large table.
      Insure that operation and size are transparent to the user.

Notes follow the Test Tabulation.

Summation :
      The ShowHealth command reports all components on-line
          and operational.
      The ShowTopology command returns the expected
          physical topology morphology.
      Queries and commands perform as expected.

* Build Date :
      Shows completion of the latest addition.
      The intermittent build has actually spanned a decade
          as equipment was added to the project.
      A contiguous build would run for years on this equipment.

Description Sources :
      AxleBase management reports.

SQL :
      Built entirely with standard ANSI-92 SQL.
      AxHandle generated each row and handed it to AxleBase
          in a SQL insert command.

Scalability :
      The AxleBase limit is 20 exabytes per table.
      The Model Hierarchy Validation hypothesis indicates that
          reaching and operating at that size is nearly certain.

Published Value Changes :
      A re-index was completed in October 2015.
      That changed some values because the new index is a
          different size and a hundred times faster.

__________________________________________________
__________________________________________________
AxleBase Tests
Section
Test:   Very Large SQL Queries

This address:   jragan.com/axletests.htm#10.85.10

Purpose :
      Show feasibility of querying very large relational databases.

Notes follow the Test Tabulation.

* Click here to see the raw test data in the appendix.

Operations appeared to the user to be using normal sized tables.

The Index Impact :
      If the indices were removed from this table,
      and assuming that it takes one thousandth of a second to
          locate, read, and analyze each row,
      then a query would run day and night for years.

Queries :
      Industry-standard ANSI-92 SQL queries.
      Each query was a simple select; e.g.
      select * from t_citizen where citizen_id = 89584262310
      select * from t_citizen where name = 'nadine'
      select * from t_citizen where location ='s56565656565656'

Other Query Types :
      Other query types also run well and are not recorded; e.g.
          between, in, greater than, min, max, etc.

File Fragmentation :
      Indices were built after the data to preclude fragmentation.

Test Validity :
      Unique values are in the table at precisely known locations.

Scalability :
      The AxleBase design limit is 20 exabytes per table.
      The Model Hierarchy Validation hypothesis indicates that
          reaching and operating at that size is probable.
      Internal mechanisms treat an index as an open-ended
          object, so size is irrelevant.
      Indexing is designed to conform to any hardware
          and network topology.

Published Value Changes :
      A table re-index was completed in October 2015.
      Some values have changed because the new index is larger
          and a hundred times faster.

( Anomaly :
      With no idea why the VLT join was faster than the VLT query, I apologize for my failure and for cessation of VLT research. They used the same table and the same hardware, so one would expect the complex join to be far slower. My surprise prompted multiple failed attempts (not shown) to reverse the disparity. I end the project with only theories that are unworthy of publication.
            JR )

__________________________________________________
__________________________________________________
AxleBase Tests
Section
Test:   Small Table SQL Queries

This address:   jragan.com/axletests.htm#10.85.12

Purpose :
      Test the query speed of small tables.

Notes follow the Test Tabulation.

Test Result Summation :
      Errors :     None.
      Problems :     None.
      Performance :     To specification.
      Operations appeared to be in normal sized tables.
      Other queries such as between, in, less than, greater,
          min, max, etc. were run and not recorded..

Test Designs :
      Industry-standard ANSI-92 SQL queries.
      Returns were validated.
      Simple queries to ease comparison and discussion.
      Standard tables with a few indices.
      Examples :
      select * from t_citizen where updater = 'laura'
      select * from t_citizen where location = 's877874857901'
      select * from t_citizen where citizen_id = 22459145625

Indexing :
      Indices were built after completing data insertion to preclude fragmentation.

__________________________________________________
__________________________________________________
AxleBase Tests
Section
Test:   Tiny Table SQL Queries

This address:   jragan.com/axletests.htm#10.85.13

Purpose :
      Test the query speed of tiny tables.

See preceeding notes following the Small Table Test Tabulation.

__________________________________________________
__________________________________________________
AxleBase Tests
Section
Test:   Very Large Table Joins

This address:   jragan.com/axletests.htm#10.85.15

Purpose :
      1. Test the ability to join very large objects.
      2. Ascertain approximate large object join speeds.
      3. Insure transparency of the operation.

Notes follow the Test Tabulation.

Query Design :
      Industry-standard ANSI-92 SQL was used.
      Result shown was from following query :
          select a.updater, b.owner, a.status, c.location,
            d.description from t_citizen_status a
          left join t_config b on a.updater = b.owner
          left join t_duplicate c on b.owner = c.updater
          right join t_status_code d on a.status = d.status
          where a.updater = 'monica'
      All four tables were joined into a single dataset.

Operations appeared to the user to be using normal sized tables.

Validity :
      Unique values are in the tables at precisely known segment and row number locations.

Scalability :
      The AxleBase limit is 20 exabytes per table.
      The Model Hierarchy Validation hypothesis now indicates
          that reaching and operating at that size is almost certain.
      Internal mechanisms treat an index as an open-ended object
          so that size is irrelevant to it.
      Indices are designed to conform to any system topology.

Published Value Changes :
      A re-index was completed in October 2015.
      That changed some values because the new index is larger
          and a hundred times faster.

( Anomaly :
      With no idea why the VLT join was faster than the VLT query, I apologize for my failure and for cessation of VLT research. They used the same table and the same hardware, so one would expect the complex join to be far slower. My surprise prompted multiple failed attempts (not shown) to reverse the disparity. I end the project with only theories that are unworthy of publication.
            JR )

__________________________________________________
__________________________________________________
AxleBase Tests
Section
Test:   SQL Updates

This address:   jragan.com/axletests.htm#10.85.20

Purpose :
      Test ability to update large entities.
      Test update of distributed large objects.
      Ascertain approximate update speeds.

Additional comments follow the Test Tabulation.

Query Design :
      Industry-standard ANSI-92 SQL.
      update t_citizen_status set flag = true where updater = 'lauren'

Result :
      No errors.
      Performance to specification.
      Times are shown in the following table.
      Operations appeared to be to a normal sized table.

Validity :
      Unique values are in the table at known locations.
      Row contents were verified before and after query.

* VLT Deferment :
      Updating a test table disturbs its known characteristics, so a backup must be made before the test and restored afterwards to maintain those characteristics. The VLT (very large table) backup requires more hardware than is currently on hand.
      Therefore the VLT test must be deferred.

__________________________________________________
__________________________________________________
AxleBase Tests
Section
Test:   Virtualized Tables

This address:   jragan.com/axletests.htm#10.85.25

Click here for a description of virtualization on the AxleBase description document. For reasons given there, tests have been removed from this document. It will be one of the features of the AxleBase technology that is not covered.

This ten or fifteen year-old note was found while editing documents in 2022: "A virtual table of trillions of rows was joined to billion-row tables." (The builder remembers little about those tests except that they beat the daylights out of the AxleBase-lab hardware.)

__________________________________________________
__________________________________________________
AxleBase Tests
Section
Test:   Mixed Storage Media

This address:   jragan.com/axletests.htm#10.85.30

Purpose :
      Verify AxleBase storage media eclecticism.
      AxleBase was designed for a distributed operation across generalized and disparate hardware of uncontrolled quality and quantity. The question addressed is whether or not that specification has been maintained through development.

Notes follow the Test Tabulation.

Caveat :
      This test attempted to stress AxleBase, and offers no recommendations.

Test Result Summation :
      No errors.
      Performance to specification.
      Operations appeared to be in a normal table.
      If the operating system can recognize a pencil and paper as a storage device, then AxleBase can use it.

Media Selection :
      Every medium that was on hand in the lab was used.

Test Structure :
      A table of 14,250 rows was created.
      It was spread across all of the storage media.
      Rows were mixed so each medium was accessed repeatedly.
      The entire table was returned by every query.
      select * from t_citizen_status
      ( The read-only CD precluded a write test. )

Times :
      Timing the test was considered pointless due to the low speed of some media such as floppy disks from the last century.

__________________________________________________
__________________________________________________
AxleBase Tests
Section
Test:   Concurrency

This address:   jragan.com/axletests.htm#10.85.35

As A Database Server

AxleBase is a database manager, and he can be inserted into a server, which creates a database server. In that configuration, concurrency performance is primarily controlled by the server and not the database manager.

A development and demonstration server has been built in the AxleBase lab, which functions well for those two objectives, but it is not intended to be an enterprise-level server. Therefore, server concurrency has not been tested.

As A Multi-Source Installation

The AxleBase design allows multiple source operations. A mix of multiple servers and single instances can share databases even when those sources are uncommunicative and geographically dispersed. That kind of operation presents unusual challenges that are totally alien to standard database managers.

Successful tests of that kind of operation have been executed.

However, that operation, with its abstract challenges, is so unusual that it is hard to understand, and its tests become meaningless and mis-guiding for most people. At the very best, the natural tendency is to equate test results with the performance of standard database servers. Therefore, those test results have been removed and discarded.

_________________________________________________
__________________________________________________
AxleBase Tests
Section
Test:   Index Build Speed

This address:   jragan.com/axletests.htm#10.85.40

Objective :
      Determine time required to index an existing dataset.

Notes follow the Test Tabulation.

Marginalia :
      Indexing is so complex that we could easily become mired down in the complexities. Therefore, this test is designed to be as simple as possible while giving a "ballpark" performance feel.
      AxleBase can also index "on the fly" as data is entered.
      Indexing on the fly seems faster to the user because each row is indexed so quickly.
      But most large tables are expected to be indexed after they are created.
      AxleBase can also create multi-column indices, but single colums will be easier for you to evaluate.

__________________________________________________
__________________________________________________
AxleBase Tests
Section
Test:   SQL Inserts

This address:   jragan.com/axletests.htm#10.85.45

Using one computer avoided test complications of concurrency.

Large tables are usually indexed or re-indexed after data acquisition.

* Time includes the GUI front end operation, which builds each insert row, hands it to Axlebase, and displays the operation.

__________________________________________________
__________________________________________________
AxleBase Tests
Section
Test:   Very Large Row Stress

This address:   jragan.com/axletests.htm#10.85.70

Purpose :
      To demonstrate AxleBase ability to handle large data rows.

Notes follow the Test Tabulation.

Test Result Summation :
      No errors and no problems.
      AxleBase performed to specification.
      But the little machine had to be rebooted. ': )

Limit :
      AxleBase is designed for rows up to 2 gigabytes where the infrastructure can handle it.

Speed :
      The small index size yielded ridiculously high speed.
      But hardware handling very large rows slowed delivery.

__________________________________________________
__________________________________________________
AxleBase Tests
Section
Test:   File Manager Stress

This address:   jragan.com/axletests.htm#10.85.75

Purpose :
      Stress the sub-systems that manage data files.
      Can AxleBase automatically, and as needed :
          1. Create millions of data files for a table ?
          2. Manage those millions of data files ?
          3. Store data in those files ?
          4. Query the table with standard ANSI-92 SQL ?
          5. Do all of that reliably and accurately ?
          6. Do it transparently so it appears simple to the user ?

Notes follow the Test Tabulation.

** Unexpressed size is if it were allowed to fill the data files.

Problem Constraints :
      1. Resources : The little AxleBase lab cannot afford enough equipment to house even one petabyte-size table.
      2. Time : Inserting two hundred trillion rows at one thousandth of a second per row in the AxleBase lab would require six thousand years.

Solution :
      The standard data file size is two-gigabytes.
      Support of that size has been tested for years.
      So this database was configured for very tiny data files.
      AxleBase stops filling each file when it reaches the
            configuration limit, and starts filling the next file.
      That allows a test of very large table management
            by creating vast numbers of data files.
      Insert data using industry-standard ANSI-92 SQL.

Situation :
      The build was stopped when the computer started laboring.
      Table now contains 10,000,999 data files.
      If those data files were full:
            Table size of twenty petabytes.
            200 trillion rows.

Test Result Summation :
      AxleBase performed to specification.
      Table diagnostics show optimal conditions.
      SQL mechanisms operate correctly.
      AxleBase file manager sub-system demonstrated
      twenty-petabyte capability.
      The operating system evinced great stress that might be
          caused by so many files on a single disk.

Conclusion :
      Since all mechanisms performed to spec with no sign of stress
      it is believed that AxleBase continues to achieve his design limit of
      20 exabytes per table.

For actual queries of tables containing billions of rows, see the Very Large Query test.

__________________________________________________
__________________________________________________
AxleBase Tests
Section
Test:   Super-System Performance

This address:   jragan.com/axletests.htm#10.85.80

Purpose Of Test :
      For extraordinary power, AxleBase can be configured as an axsys super-system driving many computers to deliver super-computer power for queries and utilities.
      When configured as an axsys, AxleBase continues to function as a standard relational database manager, so only the database administrator knows.

Notes follow the Test Tabulation.

* Click here to see the raw test data in the appendix.

System Imbalance :
      The system runs at the speed of the slowest node.
      The primary objective was to build a hundred-billion row table, and to minimize hardware loss from that 24x7 pounding due to limited funds. Therefore, data movement after build was resisted. The resulting load imbalance slowed the test system.
      The test used 11 computers, 5 of which were overloaded with more than twice as much data as the other computers contained. The slower processing time of those 5 overloaded computers set the time for the entire system. The data load is shown in the imbalance table.

AxleBase allows combining query nodes with file servers if desired.

Scalability Of Super-System :
      See the following Scaling The Super-System section and the Limits page.

Test Design :
      Industry-standard ANSI-92 SQL queries.
      Returns were validated.
      Simple queries were used to ease comparison and discussion.
      Example :
      select * from t_citizen where location = 's877874857901'

Estimating AxleBase Super-System Speed :
      The differential is a nearly linear direct correlation with
          axsys node quantity increase in a tuned system.
      Performance estimation where the base is performance
          of the standard database manager configuration :
      time = (base time) / (number of axsys nodes)
      speed = (base speed) * (number of axsys nodes)

Ease Of Use :
      Super-system operation in a production environment is not for the neophyte or faint of heart. An experienced master DBA (database administrator) with appropriate assistance is recommended.

__________________________________________________
__________________________________________________
AxleBase Tests
Section
Scaling The Super-System

This address:   jragan.com/axletests.htm#10.85.83

This is not a test.
This is a scaling demonstration.

Purpose :
Demonstrate the super-system's scaling ability based upon :
      The preceeding test results.
      Known characteristics of the system.
      System configuration features.
      The system's Model Hierarchy Validation.

AxleBase is configured as a super-system by loading it onto multiple computers, and configuring each AxleBase instance to become a node.
      ( Every AxleBase instance looks for an axsys configuration
          for itself when it opens any database.
      If it finds one for itself, it configures itself as directed.
      A query node executes queries and instructions.
      A file server passively stores data.
      A control node sends queries and instructions to the
          query nodes and harvests their responses.)

The test in the preceeding section was run with eleven computers. AxleBase configured each computer as a node in the axsys, and each also served as a file server.
      The VLT (very large table) is so big that every node was over-loaded in the previous test.
      Most nodes were assigned at least six billion rows.

The axsys in the test could be expanded by assigning more nodes to the test. The table is so big that a hundred nodes could easily be used.

Expansion Impact :
      If we continue to use each computer as the file server for its node, then there will be no increased disk contention and no network contention.
      The increased load on the controller node will be negligible since it merely harvests and combines the query nodes' work.
      Each query node's work will be reduced in direct proportion to the increased number of nodes.

Therefore, increasing the number of nodes to ten times as many will increase the speed of the previous test by ten times.

Based upon the following tabulation, AxleBase could query a trillion rows of numeric data in 2 and a half seconds using 110 old desktop computers.
Or under a second with more nodes.

* Please remember that these speeds are based on using turn-of-the-century single-processor desktop computers.

Scalability Limit :
      See the Limits page.
      A point of diminishing returns may be met as the axsys speed approaches or passes infrastructure ability such as the speed of the controller node.

Administration :
      Table size hardly impacts adminstration except for increased hardware maintenance.
      The same is true of axsys size.
      However, if the axsys is enlarged after the table is built, as in this demonstration, that will require unusual work by the DBA. In this hypothetical exercise, the DBA must plan the operation, make backups, carefully divide and relocate large datasets, update the database system files, and test everything, all while meeting daily user needs, all of which will take some time.

__________________________________________________
__________________________________________________
AxleBase Tests
Section
Test:   BLOB Management

This address:   jragan.com/axletests.htm#10.85.85

BLOB is an acronym for binary large object. A blob may be a photograph, piece of music, ultrasound recording, geology probe, movie, etc., etc. BLOBs are not data, but are objects that we want a database manager to manage.

BLOB management is simple for AxleBase, but it gets an inordinate amount of attention from some people, which is why this little report is presented.

* This AxleBase BLOB app. has been in use since approximately 2005.
      The GUI app asks AxleBase for BLOB tables which it displays. The user selects one or more photographs, music, etc., and AxleBase returns them to the app for display, play, etc.

** Photos and music are all compressed.

*** Some people have no idea of the nature of data or of how a database manager works so this query-speed item was entered for them.
      For a database manager like AxleBase that can query rows at a rate of 40 billion or more per second, finding a BLOB in one of these tiny tables is instantaneous.
      Then, displaying a photo or any other manipulation done by any other software is done at the speed of that software and the hardware, with which AxleBase has nothing to do.

__________________________________________________
__________________________________________________
AxleBase Tests
Section
Distribution Performance

This address:   jragan.com/axletests.htm#10.85.90

The performance characteristics of various distributed topologies and configurations have not been formally tested.

      However, the system was run for over a decade in various distributed configurations as needed for other testing without avoiding any configurations.
      The number of computers used varied from one to fifteen, which were limited only by available funds.
      Database and table sizes varied in size and topological distribution.
      The operating systems varied according to what was available when a test was run, some of which are shown in the Test Computer appendix.
      The Misc. Equipment appendix shows the latest network.

Findings:
      It was found that configurations were nearly irrelevant for performance and reliability when running stress and performance tests.
      No configuration of topology, hardware, and operating system ever caused a fault that was detected in the AxleBase system.

__________________________________________________
__________________________________________________
AxleBase Tests
Appendices

This address:   jragan.com/axletests.htm#10.90.00

__________________________________________________
__________________________________________________
AxleBase Tests
Appendix
Empirical Verification Of Tests And Claims

Skepticism is welcome and will be encouraged.
( Even the builder sometimes has a hard time believing the tests on this page and has re-run them many times to convince himself. )

Performance Measurement:
          A timer with a GUI display is built into the AxHandle app, so operations are routinely timed.
          Reported times are averages of multiple runs.

Data Object Size And Configuration:
          AxleBase has management report utilities such as the ShowTopology command that can be run at any time.

Courtesy Demos:
          Courtesy test demonstrations are available for interested businesses, governments, and academia. Facilities limit each attending group to six people.

Longevity Problem:
          The VLT (very large table) is housed on many desktop computers, it is too big to be copied, and there is no power protection. Since it's longevity is problematic and it took years to build, if you want to see a demonstration using it, do it soon.
          Hardware Failure. One of the computers died in December 2016. The data on it may have survived, but the small databases are offline and seven billion rows of the VLT are offline. Demonstrations using those databases and the VLT can be done only if an XP or win2k computer can be found, configured, and brought on line in the system.

Offsite Validation:
          If an organization presents a serious interest in acquisition, has the resources and skilled personnel needed to operate an AxleBase installation, and intellectual property can be insured, consideration may be given to allowing it to run evaluations on its equipment for a limited period. Mentoring and technical support will be provided.

Scientists:
          Computer scientists will be given special consideration for on-site demonstrations, but protection of intellectual property precludes allowing them to have copies of AxleBase or of its databases.

__________________________________________________
__________________________________________________
AxleBase Tests
Appendix
Performance Comparisons: Dremel

This address:   jragan.com/axletests.htm#10.90.10

The complexity of test construction and result analysis is one of the many reasons that Microsoft, Oracle, and others have wisely disallowed open comparisons. Tests are too hard to control and understand to be effectively compared by the average person.

However, the AxleBase developer unwisely publishes his tests. But since billion-dollar marketing budgets and thousand-man open-source projects will try to discount his work, it is done in hopes that others will mitigate mercifully in his favor.

Dremel
Google's Massive Web Scale Database Manager
versus
Little AxleBase
(Weighing in at less than a megabyte.)

Google presented its Dremel database server at the 36th International Conference On Very Large Databases, and published its presentation in a brief white paper. The following steps roughly compare the Dremel test to the AxleBase test.

Query 3 in their paper was used for comparison because it lent itself to comparison to AxleBase and to the AxleBase test.

The AxleBase test used in this comparison is shown in the Super-System table. The string data query was compared because it matched the Dremel data.

1. Determine Hardware Differential :
      This is a software test, so equalize the hardware.
      Dremel used 2,900 computers.
      AxleBase used 11 computers.
      Divide their 2,900 by the AxleBase 11 computers.
      2,900 / 11 = 264

2. Determine Data Differential :
      The amount of data is almost irrelevant to AxleBase.
          See the limits page.
      But the data structure is critical.
      The AxleBase table had 100 billion rows.
      The Dremel table had only 24 billion rows.
      The AxleBase table was 4.167 times bigger.
      100,000,000,000 / 24,000,000,000 = 4.167

3. Original Run Time :
      The original AxleBase run time was 6.96 seconds.

4. Apply Hardware Differential:
      Divide that time by the hardware differential to get the
          AxleBase run time with 2,900 computers.
      6.96 / 264 = 0.0264 of one second run time.

5. Apply Data Differential :
      Equalize the data load by dividing the above run time by
          the data differential.
      0.0264 / 4.167 = 0.0063 of one second run time.

6. Compare The Normalized Performances :
      Dremel : 27 seconds
      AxleBase : Six thousandths of one second (0.0063).
      Result : 27 / 0.0063 = 4,285.7 times faster.

Therefore,
AxleBase was four thousand times faster than Dremel.

Percentage :
      Note the .7 on the result. It was retained to remind us that a system that is 70% faster is remarkable and the result here is nearly a half million percent faster.

Standard Configuration :
      AxleBase can also run on one computer like Oracle and MS Sql Server. The single-computer test used the same data that tested the parallel processor system.

Hardware :
      Standard single-processor turn-of-the-century desktop computers that were scrapped or bought used. Windows 2000 was used. Disks were the cheapest locally available disk drives.

Reminders :
      Performance was achieved by a high-end relational database manager that continued all tasks on the description page such as assessing the health of the 38,000 files in the table during every query.
      AxleBase is so fast that he captures the hardware. Therefore, he has a YieldProcessor toggle that can force him to pause tens of thousands of times per second to allow other systems to run on the machine, and he must check its value each time that he passes it. YieldProcessor is yes in all tests so the operating system's GUI can operate. How fast would he be if that toggle were entirely removed?

Security And Reliability Under Load :
      See the description page.

Unstructured Data :
      Beware. Unstructured data is sometimes an excuse for failure to employ professionals for design of installation and database.

Daydreaming :
      Since the absolute value of AxleBase's test time was 6.96 seconds with only 11 computers, imagine his performance with, not Dremel's thousands, but only a hundred desktop computers.

__________________________________________________
__________________________________________________
AxleBase Tests
Appendix
Scaling and
Model Hierarchy Validation

Concept Source:
          Model hierarchy validation was presented by Kevin Heng (Maximilian University, Germany) as a model validation methodology applicable across all science disciplines where full-size modeling is impossible such as in his field of astrophysics.
(*ref. Source: American Scientist, May-Jun 2014, pp. 174-177. )
A requirement is that the model be unchanged and unadjusted across all magnitudes while delivering consistent result quality.

Hierarchy:
          Years of AxleBase testing have proceeded through ever larger data entities as more equipment was brought online, thus creating a controlled orthogonal, or linear, model hierarchy. Tests have grown through many orders of magnitude from tables with hundreds of rows to a hundred billion rows.

Result:
          Those vast magnitude increases with an unchanged model across a decade of tests have yielded a linear progression of test result magnitudes with unchanged qualitative behaviors. Results have always met specifications and have done so without error.

Conclusion:
          Model hierarchy validation indicates that AxleBase can scale to its design limits of exabytes in trillions of rows.
          ( Also, see the File Manager Stress Test projection.)

__________________________________________________
__________________________________________________
AxleBase Tests
Appendix
Methods and Objectives

Test Objectives :
      1. Show that AxleBase works.
      2. Demonstrate the vast data stores that he can manage.
      3. Test the speed in managing those great tables.
      4. Demonstrate some of his advanced technologies.
      5. Show adherence to the relational database construct.

Scientifically rigorous in-depth testing is not possible. Although desirable, those million-dollar tests are a bit beyond the resources of a poor man.

Presentation of Operation Domain :
      The great range of AxleBase abilities is sampled to present what is thought to be of greatest general public interest. Many of his abilities are not even mentioned on the web site.

Computer Buffers :
      The modern computer has data buffers that uncontrollably impact test results. Even the disk drives have data buffers. Buffers are circumvented where possible, and reboots are sometimes used to verify results with clear buffers.

Tuning For Tests :
      AxleBase has tuning options, but they were not used.
      Although it slows tests, YieldProcessor is left on so
          the user GUI can control test operations.
      Disks are defragged.

Queries :
      Industry-standard ANSII-92 SQL queries are used.
      To enable comparison and evaluation, reported queries are
          usally kept as simple as possible.
      A few complex queries are included merely to show off.
      All query types are done, but few are reported.

Data :
      Test data is generated by an automated system.
      See the data appendix.

Computers :
      See the computer appendix.
      Testing fancy hardware is not the objective, so
          AxleBase is run on commodity desktop computers.
      The cheapest used computers are bought when possible.

Test Dates And Schedules :
      Tests on this page are spread over years.
      Some test updates are long overdue due to limited resources.
      Obviously, there is no formal schedule.

__________________________________________________
__________________________________________________
AxleBase Tests
Appendix
Data Table Metadata

Reference Numbers :
      Numbers in the left column are the reference numbers
          in the preceeding test tabulations.

Data Generation :
      Unless a test needs random, unique, datetimes, or specific
          values, most columns are filled by a set of literal values.
          Not only does this produce a known dataset, it
          also allows old equipment to generate large datasets in
          less than a year.
      See the Data appendix for more information.

Row Width :
      Row width is of little importance to a database manager.
      Therefore, these tests use moderate row sizes to allow
          construction of large tables for stress and speed tests.
      ( But if you doubt that, then see the Large Row test. )

Column Type :
      An AxleBase table can be configured to use either fixed or variable width.
      These tables are fixed width.
      But it matters little because the tests used indexed data.

Data Domain :
      The data domain concept was developed in the AxleBase lab to control data variables more tightly than can be done by the simpler datatype construct. It subsumes the datatype construct.

__________________________________________________
__________________________________________________
AxleBase Tests
Appendix
Column-Datatype Descriptions

Data source :
      All test data is generated by the AxHandle test app.
      AxHandle constructs each data row and hands it to AxleBase in a standard SQL insert statement.
      AxHandle tells AxleBase to generate current dates and times where needed.

Reference Numbers :
      Numbers in the left column of the following table are the reference numbers in the tables of test.

String Type :
      The AxleBase string type accepts any ASCII character that does not conflict with a system control code. However, for these tests, only printable characters are used.

BLOBS :
      Trivialities, such as storage and retrieval of large photographs and other BLOBs, are not in these tests.

Null Values :
      The repeating sets contain some nulls.

Row Targets :
      AxleBase can return a row or a row range by number.

The Shannon Limit :
      See Data theory.

__________________________________________________
__________________________________________________
AxleBase Tests
Appendix
Test Computers

Why are all the computers so old and slow ?
      To prove the power of AxleBase.
      Testing hardware speed is of no interest.
      For a smile, imagine any big-name database manager
          running these tests on these computers.

Computer Count :
      Tests are each run by a single computer.
      Other computers are used as file servers.
      The super-system tests, which use multiple computers, are
          in a separate and prominently labeled section.

Reference Numbers :
      Numbers in the left column are the reference numbers in
          the tables of test.

Missing data is caused by :
      Computer failure years before this table compilation.
      Or the computer was bought used.
      The Linux file server records are all lost.

__________________________________________________
__________________________________________________
AxleBase Tests
Appendix
Misc. Equipment And Environment

Network :
      Segmented, switched, gigabit network using IP lookup tables.
      Stack : SysLink / TCP / IP / ethernet / CAT V
      Some external disks are on USB 2.0 cables.

Computers :
      See preceeding computer appendix.

Storage :
      All storage is on mechanical hard disks.
      Disks are :
          Cheapest available regardless of speed.
          SATA and PATA.
          Mostly internal and some external SATA docks.
          External disks are on USB 2.0 cables.

Data :
      See preceeding data appendix.

Setup :
      Disks are defragmented.
      No special configuration.
      Although it slows performance, the AxleBase yieldProcessor
          toggle is turned on to allow GUI control.

__________________________________________________
__________________________________________________
AxleBase Tests
Appendix
Raw VLT Test Values
Standard Configuration

Run durations for queries against a billion row table.
With AxleBase configured as a standard database manager.
Test tabulation and technical descriptions can be seen HERE .

Building this table has spanned a decade. Unique query values inserted in recent years were well controlled. The early years were not well controlled so those values returned thousands of rows.

Table row is the row in which the target value is located. Row locations in recent years are precise. Approximations are indicated by tildes.

Total 2,541.29 / 20 = 127.06 seconds average per query.

( Anomaly :
      With no idea why the VLT join was faster than the VLT query, I apologize for my failure and for cessation of VLT research. They used the same table and the same hardware, so one would expect the complex join to be far slower. My surprise prompted multiple failed attempts (not shown) to reverse the disparity. I end the project with only theories about that problem that are unworthy of publication.
            JR )

Shannon data was developed specifically to stress AxleBase, because AxleBase is so unbelievably fast. It is discussed in the data theory.

Total 2851.84 / 20 = 142.59 seconds average per query.

Values chosen may look suspicious because they were chosen to test for various things that can arise in very large datasets, such as intra-boundary effects, that might produce anomalous behaviour in a database manager, and to insure that each is unigue in that vast dataset. They have no affect on the test performance.

The first three values were randomly generated. For the value "5:>2UkJ14Q06JEv@", 2,419 rows were returned, which is why randomly generated values should be avoided for target values in very large tests.

Numeric values were arbitrarily chosen, so the locations of values under fifty billion that are in the old part of the table may not be known.

Total 283.43 / 11 = 25.76 seconds average per query.

__________________________________________________
__________________________________________________
AxleBase Tests
Appendix
Raw VLT Test Values
Axsys Super-System Configuration

Run durations for queries against a 100 billion row table.
With AxleBase configured as an axsys super-server.
Test tabulation and technical descriptions can be seen HERE .

Building this table has spanned a decade. Unique query values inserted in recent years were well controlled. The early years were not well controlled so those values returned thousands of rows.

Table row is the row in which the target value is located. Rows in recent years are precise. Approximations are indicated by tildes.

Total 139.22 / 20 = 6.96 seconds average per query.

Shannon data was developed specifically to stress AxleBase, because AxleBase is so unbelievably fast. It is discussed in the data theory.

Total 322.35 / 20 = 16.12 seconds average per query.

Values chosen may look suspicious because they were chosen to test for various things that can arise in very large datasets, such as intra-boundary effects, that might produce anomalous behaviour in a database manager, and to insure that each is unigue in that vast dataset. They have no affect on the test performance.

The first three values were randomly generated. For the value "5:>2UkJ14Q06JEv@", 2,419 rows were returned, which is why randomly generated values should be avoided for target values in very large tests.

Numeric values in the table are all unique, so test values were arbitrarily chosen without regard to location, so the locations were not ascertained.

Total 49.13 / 20 = 2.46 seconds average per query.

Super-System Imbalance

The data load was unbalanced. The primary objective was to build a hundred-billion row table, and to minimize hardware loss from years of that 24x7 pounding. Therefore, data movement after build was resisted.

Performance of the axsys super-system was set by machines 12 thru 16 because they contained so much of the data; queries ran the longest on them. They each contain two disks, so they can be unloaded if more machines are found.

The following table shows the data load on each computer.

__________________________________________________
__________________________________________________
AxleBase Tests
Project Status
__________________________________________________
__________________________________________________

2003 :   Begun.
2006 :   Operational.
              Improvements and tests continued
              and attempts were made to sell it.
2016 :   Stopped.
              The project surpassed all goals,
              and gave me years of fun and lessons,
              so research, development, and testing stopped.
             

( I make changes in the web site when an error is noticed in this massive, many-years project. A fact that I frequently forget is that, many years later, AxleBase still serves my needs and supports research in other areas.)

__________________________________________________

Web site and technology
Copyright 2003 - 2023 John Ragan

Web site is maintained with Notepad.
By intent, so don't bother me about it.