__________________________________________________

Images and other BLOB data are not included in AxleBase tests because they merely inflate the numbers and obscure reality.

Equipment:
      The AxleBase lab uses the cheapest that can be found locally. Computers are used until they break, so one machine has been in use since the nineties. Used equipment is bought for tests when possible.

The network is a switched gigabit single-segment CAT 5 running standard TCP/ IP /ethernet.

Tests are run without tuning and without special configuration. Disk defragmentation is maintained.

Although it may slow tests, the AxleBase yieldProcessor setting is usually turned on to allow control of the computer although it may be subject to slowing processes..

Objective:
    Test the ability to build and control very large tables transparently to the user.

Build Mechanics :
      SQL
      Computers inserting data varied over the six month period with five usually running. Each insert was a fifty-row arrayed insert.

Result :
      The system performed to specification.

Validation:
      The ShowHealth comand reported no problems.

Data :
      Data only. Quantities are not inflated with indices, BLOBs, or other extraneous objects.

Purpose :
      Ascertain approximate speed of large indices.

Query Design :
      Standard SQL queries.
      Each query searched entire table for a single value.
      Example :
      select * from t_citizen where location = 's87787408857901'

Validaty :
      Unique values are in the table at known locations.
      Values and locations were verified before tests.
      Also, see the index validation test section.

Indexing :
      Indices were built after the table was created.
      Indices built on-the-fly are not suitable for large entities.

Queries not shown included between, in, less than, greater than, etc.

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

Table Size :
      Small table :
                  100 million rows ( 101,266,000 ).
                  8 billion bytes ( 8,101,280,000 ).
      Large table :
                  15 billion rows ( 15,392,432,000 ).
                  1 trillion bytes ( 1,231,394,560,000 ).
Sizes do not include indices, and never include BLOBs.

Query Design :
      Standard SQL queries.
      Example :
          select * from t_citizen_status
          left join t_config
          on t_citizen_status.updater = t_config.owner
          where t_citizen_status.updater = 'sarah'

Validity :
      Unique values are in the tables at known locations.
      Values and locations were verified before tests.
      Also, see the index validation test section.

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

Query Design :
      Standard SQL.
      update t_citizen_status set flag = true where updater = 'lauren'

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

Large Table Deferrment :
      The large table test is deferred pending hardware acquisition for backup. 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 large table backup requires more hardware than is currently on hand.

Objective :
      To stress the virtualization mechanism.
      To stress the concatenation mechanism.

Result :
      The system performed to specification.

Data :
      Quantities are not inflated with indices, BLOBs, or other extraneous objects.
      Unique rows were placed at controlled locations in tables to validate queries. Also, AxleBase can retrieve by row number even in virtual tables.

Subjective Understanding :
      If the hardware can deliver each row in .015 second,
      and all indices are removed, then a query of the
      smaller table would run for 3,000 years,
      and the larger table would require 400,000 years.

Comparative Example :
      The large table is thousands of times bigger than the biggest book library in the world, the Library Of Congress.

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.

Caveat :
      This test was designed to touch the extremes, and no part of it is intended to be a recommendation or even a suggestion.

Result :
      The system performed to design specification.
      There were no errors, problems, or data loss.

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

Test Structure :
      The database table segment size was changed from 2 gig to 2k.
      A table of 14,250 rows was created.
      The very small segment size produced 285 table segments.
      Segments were relocated so that the table was spread across various media.
      The entire table was returned by every query.
      select * from t_citizen_status
      (The CD precluded a write test, but it was not considered necessary.)

Times :
      Timing the test was considered pointless, considering the low speed of some components; floppy disks are from the last century.
      Also, the small table and small segments made reads nearly instantaneous.

Purpose :
      To test concurrent operations.

Result :
      The system performed to specification.

Queries :
      The AxHandle query test suite.

Caution :
      Do not be misled by the success of these tests. The inability to achieve a system failure does not necessarily indicate operational safety at or above that load. Only after failures have repeatedly been achieved can a safe operational load be estimated.

Test:   Concurrent Insert

Objective :
      To place a heavy insert load on a single table. The previous test was mainly reads.

Times included interruption by an hourly database purge by every CoreReader instance and database backup by every instance.

The CoreReader log table was chosen. Multiple CoreReader instances were directed against a single remote database, and a departmental job server was started on all instances.

All activity, including job file writes, was on one disk. There was no system tuning or object dispersion.

Objective :
      Determine approximate times required to index an existing table.

Speed Increase :
      A change in a database configuration parameter could have easily increased the speed in the random column build, but would have resulted in a slower index.
      Also, AxleBase could have used multiple computers to speed the build of all indices, but timing of the operation would have been inacurate and confusing.

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 feel" for the performance. AxleBase can also index "on the fly" as data is entered, but most very large data stores will be indexed after they are created.

__________________________________________________

Copyright 2003 - 2012 John Ragan

Web site maintained with Notepad and command line FTP.