INTRODUCTION
Too late is too late! Critical information received too late,
even by a nano-second,
is no more useful than information received too late by over a month.
Today there is considerable interest in being able to extract information
from fresh data in the shortest possible time.
Unfortunately, current DBMS architecture technology requires that all fresh
data be preprocessed, restructured, and "indexed"
before any information can be extracted.
This "load time" can sometimes be so long as to preclude any reasonable
interpretation of "rapid information access".
[A recent assessment of
the ability of
DBMS products to provide Rapid Information
Access is given below.
The "load times" are devastating.]
This recent comparison of Rapid Information Access (RIAM) capabilities
(using the same platform, with the same source data,
and for the same application requirements)
was made using an Oracle DBMS, DB2, and an Interactive Extended Set Processor (iXSP).
RIAM RESULTS
| SOFTWARE |
ELAPSED TIME |
| DB2 |
over 25 hours |
| ORACLE |
over 21 hours |
| iXSP |
under 40 minutes |
|
RIAM
The Rapid Information Access Measure (RIAM) determines the total elapsed time
it takes (given some well defined source data in a standard readable form)
to (1) load and optimize the source data for a well defined application;
(2) exercise the application for an initial set of queries; then (3)
exercise the application over a class of "optimized" queries using a variety
of different input variables.
For a RIAM to be of any value, the source data and application should reflect
useful, real world oriented, timely information access considerations.
For the RIAM presented below, these considerations were met by choosing
the data and query criteria established by a highly respected and well known
benchmarking organization: the
Transaction Processing Council.
In the results below, it will be noted that [1] reflects the total elapsed time
it takes each of the three systems to complete the data loading, initial querying,
and multiple executions of Query 9 from the TPC-H benchmark
specifications using
the TPC-H DBGEN data generator.
[It is important to note that the RIAM is not compatible with the
restrictions imposed by the TPC-H Benchmark,
since the TPC-H Benchmark specifications
preclude recognition of any impact on performance
induced by the high cost of "loading".]
The additional three tables [2,3,4] below are drawn from the results generated
by [1].
The load and optimization times in [2] reflect just the loading times and
the time to exercise a query once. It also gives the total time it takes
to extract the first usable result, since in some applications the
repeating of a query is not required.
In many applications, however, repetition of a query class is most important.
Table [3] reflects the number of queries that can be completed per hour,
once the data has been loaded and optimized.
While table [4] presents the total number
of queries that can be completed in a 24 hour period, starting with
fresh source data.
INFORMATION ACCESS ACCELERATOR
The iXSP used in the RIAM below
is a low-level "adaptive data access and restructuring" capability
that has been commercially employed, in a variety of roles, over the last
30 years.
One of its future roles could be to complement existing DBMS installations
that require
improved information access. In the role of an
"Information Access Accelerator"
an iXSP capability could be "added on"
and be used in conjunction with an existing DBMS without modifying or
disturbing the existing DBMS in ANY way. This shared co-existence
of Rapid Information Access with traditional Indexed Record Access systems
could then provide end-users with the best of both worlds.
RIAM: Rapid Information Access Measure
-
RIAM - Rapid Information Access Measure:
-
Determines the time it takes to load and optimize source data for initial and
subsequent critical queries;
-
Executes these critical queries for the first time; and
-
Then, using the optimized data generated by (1) above,
executes ten additional variations of these critical queries.
Following are the results for five different input source data sizes:
RIAM
| |
1 Gig |
2 Gig |
4 Gig |
8 Gig |
16 Gig |
| DB2 |
6h 23m |
13h 38m |
1d 1h 52m |
*** |
*** |
| ORACLE |
3h 20m |
9h 4m |
21h 59m |
*** |
*** |
| iXSP |
12m |
22m |
40m |
1h 21m |
2h 46m |
|
-
LOAD & OPT: The time it takes to enter source data onto a platform, analyze it, and do
whatever is required to organize its representation for optimum query performance.
LOAD & OPT
| |
1 Gig |
2 Gig |
4 Gig |
8 Gig |
16 Gig |
| DB2 |
34.32m |
67.91m |
119.03m |
*** |
*** |
| ORACLE |
106.18m |
232.02m |
370.92m |
*** |
*** |
| iXSP |
5.83m |
11.79m |
23.57m |
48.00m |
100.00m |
|
QUERY: The time for initially executing a critical query.
QUERY
| |
1 Gig |
2 Gig |
4 Gig |
8 Gig |
16 Gig |
| DB2 |
31.76m |
68.18m |
130.30m |
*** |
*** |
| ORACLE |
7.60m |
28.35m |
86.17m |
*** |
*** |
| iXSP |
0.52m |
0.90m |
1.50m |
3.00m |
6.00m |
|
FIRST RESULT: Elapsed time to extract the first usable result from the source data.
FIRST RESULT
| |
1 Gig |
2 Gig |
4 Gig |
8 Gig |
16 Gig |
| DB2 |
1h 6m |
2h 16m |
4h 10m |
*** |
*** |
| ORACLE |
1h 54m |
4h 21m |
7h 37m |
*** |
*** |
| iXSP |
7m |
13m |
26m |
51m |
1h 46m |
|
-
CRITICAL QUERIES: The number of critical queries that can be completed in an hour, given that the source
data has been loaded and optimized for best performance.
CRITICAL QUERIES/HOUR
| |
1 Gig |
2 Gig |
4 Gig |
8 Gig |
16 Gig |
| DB2 |
1.89 |
0.88 |
0.46 |
*** |
*** |
| ORACLE |
7.89 |
2.12 |
0.70 |
*** |
*** |
| iXSP |
115.38 |
66.67 |
40.00 |
20.00 |
10.00 |
|
-
24-HOUR THROUGHPUT: Total number of usable results obtainable in the first 24 hours.
24-HOUR THROUGHPUT
| |
1 Gig |
2 Gig |
4 Gig |
8 Gig |
16 Gig |
| DB2 |
43.27 |
17.18 |
9.14 |
*** |
*** |
| ORACLE |
168.08 |
41.60 |
11.41 |
*** |
*** |
| iXSP |
2757.02 |
1585.90 |
943.29 |
463.00 |
222.34 |
|
[***] Vender's optimization requirements exceeded platform storage capacity.
PLATFORM: Intel 500MHz - 256MB RAM - 30GB IDE [effective DTR 20MB/sec]
The source data used above was generated using DBGEN which is the standard data generation
program used by the TPC benchmarks. DBGEN is available from TPC at http://www.tpc.org.
[Products: DB2 UBD 7.2; ORACLE Release 8.1.7; iXSP Version 11.07]
«
Copyright © 2005 -
INTEGRATED INFORMATION SYSTEMS -
XSP Technology »