[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
Title: | DEC Rdb against the World |
|
Moderator: | HERON::GODFRIND |
|
Created: | Fri Jun 12 1987 |
Last Modified: | Thu Feb 23 1995 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 1348 |
Total number of notes: | 5438 |
1340.0. "RDB 3692 TPS-A 3Xfaster than *any* relational database" by NOVA::FEENAN (Jay Feenan - DEC Rdb, Worlds Fastest DB Engine) Wed Apr 13 1994 05:39
In case you have not seen this...
+-+-+-+-+-+-+-+
|d i g i t a l| I N T E R O F F I C E M E M O R A N D U M
+-+-+-+-+-+-+-+
TO: Bob Palmer
DATE: April 8, 1994
FROM: Steve Hagan
DEPT: Rdb/DBMS Engineering Mgr
EXT: 381 - 2425
LOC: ZK2-1/O.C.1
ENET: NOVA::HAGAN
cc: Distribution
SUBJ: ALPHA + RDB = 3,692 TPS-A TRIPLES THE WORLD RECORD
1) HIGHLIGHTS, 2) MARKET POSITIONING, 3) CONFIGURATION 4) KUDOS
This week, we successfully audited 3,692 TPS and $4,866 / TPS
on an ALPHA CLUSTER, VMS, Rdb, ACMS, Digital Compilers.
These results are ready for public release.
This is TRIPLE the benchmark ever run by a relational database on any platform.
Cluster was 4 - Alpha 7650s.
This proves the SPEED and SCALABILITY and AVAILABILITY of the ALPHA platform,
both in SMP and in a Cluster. The database size was 3/4 TERABYTE
(766 gigabytes), with stringent ACID (failure scenario) processing required.
This benchmark was run in CLIENT/SERVER mode, serving 36,920 users.
IN ADDITION:
Rdb + ALPHA hold the FOUR best price-performance records in the industry:
System TPS A $/TPS A
Digital 2100-A500MP 4 CPU Client/Server 662.32 $4,401
Digital 2100-A500MP 1 CPU Client/Server 265.03 $4,405
Digital DEC 4000-720 AXP 2 CPU C/S 402.76 $4,861
Digital DEC 7650 AXP 4 nodes 3692.67 $4,866
--------------------------------------------------------------------------
The message to IBM mainframe customers:
UPSIZE your capabilities while DOWNSIZING your costs.
To HP + SUN + RS6000: You are not in scalability game:
NONE of you can achieve these high end results.
To HP + SUN + RS6000 + Compaq:
You are NOT in the scalability game:
NONE of you can achieve these price / performance results,
NOR the high end results.
These OLTP performance results combine with Rdb's WORLD RECORDS in
SORT and BACKUP/RESTORE, and the best high-availability + multimedia
capabilities in the industry, to make the DIGITAL solution the BEST wherever:
Performance, Very Large Databases, High Availability, and Multimedia
are the requirements. This benchmark used a 240 disk database, yet we
constructed and loaded the database in 6 1/2 hours.
NEXT BENCHMARKS:
Rdb will set WORLD RECORDS in TPC-C (2 months).
Rdb will show a 64 BIT GIANT MAIN MEMORY DATABASE DEMO,
proving the merits of a 64 bit chip.
For Internationalization markets:
Rdb 6.0 shipped in Japan 27 DAYS after shipping in the U.S.
A WORLD RECORD; Rdb is ISO SQL 92 Compliant, implementing ISO9000.
For the OBJECT ORIENTED Markets:
Rdb 6.2 will allow uses/customers to add Object Oriented Class
Libraries to Rdb databases.
TEXT oriented Content Based Retrieval will be the first class library;
OLE support will also be in Rdb 6.2.
NT operating system will also be supported.
2) MARKET POSITION SUGGESTIONS
IBM Downsizing
Alpha platforms, due to SMP + CLUSTER Scaling,
can OUTPERFORM the largest mainframe, and do it
at a better price.
IBM has a TPC-A number of 3509 TPS, $7.9 K/TPS.
Counter: this was run with TPF (Transaction Processing
Facility): also known as SABRE - Airline Reservation System
This is a special purpose, no O/S, custom package.
MESSAGE: Digital, with a general purpose relational database,
good tools, general purpose operating system, and scaleable
platform, can provide your customer with more capability
than even the famous IBM airline reservation, with their
largest mainframe + I/O technology.
PC Desktop UPSIZING
Digital, at the low end, has better price performance
than Compaq. The advantage is that a Digital solution
can then scale up to larger than an IBM mainframe for
capacity. No other vendor can do this.
HP, SUN, IBM RS6000
None of these vendors have a cluster scaling story
to compare with the Digital story. ASK for their benchmark;
(they don't have one). Then explain to the customer
that an OFFICIAL TPC-A requires demonstrating
failure and recovery from losing a disk, a CPU,
an entire NODE in a cluster or the entire cluster.
NO ONE ELSE CAN DO THIS TODAY! DIGITAL HAS IT NOW!
APPROXIMATE CONFIGURATION:
The precise system is described in the TPC report; available
from the author on request.
The cluster benchmark test not only validates the capability of
Alpha AXP, OpenVMS and Rdb to handle extremely large throughput volumes,
but also the ability to support very large databases on very
large hardware configurations. The various ACID tests demonstrate that
this system can recover this huge database correctly from the
failure of a disk, a node and even the entire cluster.
Attached are some vital information on the benchmark.
Cluster Test Database Size
--------------------------
TPC-A Result = 3692.02 TPS-A at $4866/TPS
Number of concurrent users 36960
Number of disks (with 10% spare) 303
Total size of database 747 GB
History table size 638 GB
Account table size 53 GB
After-image journal 57 GB
Other misc 1 GB
Number of records in Account table 369 Million
Important Throughput Data
-------------------------
106 Million transactions per (8-hour) day
8122 disk I/Os every second
7384 network I/Os every second (messages between front and back-end)
Cluster Test Hardware Configuration
-----------------------------------
Back-end System
4 node DEC 7650 AXP (200 MHz) cluster
512 MB memory per each node
303 disks
22 HSJ40 SCSI controllers
4 TZ87 (20GB) tape drives
FDDI connection
Frond-end System
44 MicroVAX 3100/90 with 32 MB Memory on each
44 disks
Terminals
36960 VT510 terminals
5082 DECserver 90L+ terminal servers (with 10% Spare)
Cluster Test Software
---------------------
Back-end System
OpenVMS AXP V6.1
DEC Rdb V6.1
DECnet
Cluster Software
Front-end System
OpenVMS VAX V5.5
ACMS V3.3
Rdb V6.1
VAX C
VAX CDD+
DECnet
NOTES:
The scaling in the SMPs and in particular the cluster was
better than expected.
We actually ran over 4,000 TPS in the server, and found no
bottlenecks in Rdb. We believe Rdb could do over 10,000 TPS-A,
with enough hardware.
The audited benchmark had CPUs at only 90% busy, and we had to slow
the test to stay within the planned TPS level. This is because
we had a limited amount of disks, and were trying to audit by
a deadline, April 8 (we made it).
T.R | Title | User | Personal Name | Date | Lines
|
---|