🚀 go-pugleaf

lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes:

>[about database machines as an example of the tradeoffs
>involved in designing specialized machines of various sorts]

>The question with any such processor is whether it provides a big
>enough performance boost to keep the product ahead of general purpose
>machines, which are usually on a much faster design cycle.

It seems (I have no numbers) that database machines provided a big
enough boost during roughly 1983 to 1988.  After that those KMs adnd
shortened design cycles narrowed the performance gap, reversed the
price/performance gap.

But a lot of database machines, then and now, justify their purchase
not by providing better performance for the database user but rather by
giving the general purpose machine back to everybody else.  Database
applications can be bad citizens in general timesharing environments.
People like to offload them to a separate machine.

Of course, since users connect to their databases from front ends
running on other machines, the catch is how many problems partition
themselves poorly between front and back end, thus bottlenecking on
network throughput and sometimes latency.  No amount of performance in
the workstation or database machine helps in this case, and it is common.

>I have several questions:

>1)	Just what kind of performance, by various appropriate measures, do the 
>	current crop of DBMs provide (BTW - I notice that there are now
>	2 measures of standard TPS units - any enlightenment and/or
>	correspondence between the two appreciated) vs standard architecture
>	machines.

Warning: TPS measurements are susceptible to manipulations that make
string inlining on Dhrystone look honest to a fault.  And TPS's are
almost never measured or reported with anything but intent to deceive.
And even when done honestly, just as compiler optimizations achievable
on small synthetic benchmarks can be poor predictors of performance for
real applications, vendor X's TPS's on TP1 or DebitCredit can lead you
down a garden path.

A simple example is that DebitCredit requires you to scale table size
by measured TPS's, you have to titrate it until your measured TPS's are
obtained against a table of appropriate size.  Reported TPS's seldom
also report enough information to determine whether this was done.
This is just a simple example; it gets much, much worse.
There are many, many variables that can lead to misleading results, and
misleadingly high results are seldom an accident.

Even when done honestly, TPS are a highly derived unit.  They're even
further from characterizing overall DBMS performance than "MIPS" are
from characterizing overall computational performance.  TPS results
aren't comparable across software, hardware, or communications pathways
between front and back ends.  E.g. you can use results to measure
improvements due to software (e.g. single versus multiple server
processes) by comparing on same hardware.  But you can't compare
results from database machines with results from different hardware and
software, the data simply isn't meaningful.

And when the data is collected, all it tells you is how well you did on
short, simple queries.  This is useful to people who want to attach
their point-of-sale system to a general purpose database engine, but of
very limited use to the rest of us.  For instance, TPS numbers don't
contribute a thing to predicting performance of CAD/CAM databases.

>2)  Has anyone considered an extended filesystem approach for Unix,
>	wherein specialized DataBase operations are supported in
>	the filesystem

See:

	The Use of Technological Advances to Enhance
	Database System Performance, P. Hawthorn and M.
	Stonebraker, ACM-SIGMOD Conference Proceedings,
	ACM-SIGMOD International Conference on Management
	of Data, Boston, Massachusetts, June 1979.

	Performance Enhancements to a Relational Database
	System, M.  Stonebraker, J. Woodfill, J.
	Ranstrom, M. Murphy, M. Meyer, and E.  Allman,
	ACM Transactions on Database Systems, vol. 8, no.
	2, June 1983.

Both reprinted in:

	The INGRES papers, M. Stonebraker, ed.,
	Addison-Wesley, 1986, chapters 5 and 6.

> and, a specialized bus-based (e.g. VME, FutureBus)
>	processor is attached to the system.  This would appear to be more
>	flexible and allow many companies to access the functionality, the
>	same way that they do with new disk controllers, etc.

This idea is new as far as I know.

>  What primitive
>	operations should be supported: powerful enough to reduce traffic
>	to memory by a large fraction, general enough to use with a wide
>	variety of database systems?  What I envision is a definition for a
>	dbfs, database filesystem, which would support various RDBMSs such as 
>	Oracle and Sybase via multiple dbfs's.  The parallelism would have 
>	to be across controller boards/filesystems, with processors in the
>	controllers for the operations.  You might support better keyed access,
>	compression, lock support (what kind?), disk optimizations (the usual),
>	and any other useful parallelizable operations.  In configuration terms,
>	you might have 4 controller boards on your VME (say) system, and get 
>	some fraction of parallel performance across the boards.

Analysis of existing database systems shows that simple, short queries
have distinctly different performance characteristics from
complex queries.  (TPS (sometimes) predicts performance for
applications in which the former predominate).  Things that help
are fast commits, fast acquisition and relinquishing of locks,
deferred writes, buffering of various sorts.  Some of this can
be helped by specialized hardware, but currently the bottlenecks
tend to be software.

Also the software can go a long way to reducing raw hardware
requirements.  For instance, a log file can record committed
transactions, from which the main table is silently (safely,
transparently) updated.  This decouples latency from throughput.  You
can then buy a high latency device to store your tables and a high
throughput device to store the log file.  The economies achievable by
not requiring both in a single device are said to be substantial
(again, no numbers, sorry).

Things that help complex queries are, well, complex.  Hardware assists
are more likely to help here, but in very close collaboration with
matching software.  For example, keeping as many parallel paths busy as
possible is intimately connected with query decomposition.  To saturate
your special hardware resources, you have to know which parts of the
query can execute in parallel, how much faster the total query will
(most likely) complete if a given amount of resource is invested to a
given part of the query at a given stage, not to mention the costs
and latencies of fetching from databases distributed over multiple machines.

Thus my guess is that general purpose machines will continue to have an
edge for at least several years.  Special hardware of various sorts
will help some, but until the software can make intelligent use of it
in real time, its potential will be mostly unrealized.

-- Jon
-- 
Jonathan Krueger    jkrueger@dtic.dla.mil   uunet!dgis!jkrueger
The Philip Morris Companies, Inc: without question the strongest
and best argument for an anti-flag-waving amendment.