Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Exploiting parallelism for the performance enhancement of non-numeric applications by DAVID J. DEWITT and DINA FRIEDLAND University of Wisconsin Madison, Wisconsin ABSTRACT In this paper we examine the design of computer architectures that use parallelism to enhance the performance of non-numeric applications. In particular we examine how the technology of mass-storage devices has affected the design of computer architectures for non-numeric processing. 207 From the collection of the Computer History Museum (www.computerhistory.org) From the collection of the Computer History Museum (www.computerhistory.org) Exploiting Parallelism for Non-Numeric Applications 209 INTRODUCTION OPERATIONS OF NON-NUMERIC PROCESSING In this paper we examine the design of computer architectures that use parallelism to enhance the performance of nonnumeric applications. While this has been an active area of research for over ten years,l no commercial products that exploit parallelism have resulted from these efforts. This is especially interesting when one considers the wide range of products available commercially for numeric applications that use parallelism. At the top-end (in terms of both performance and price) are large scientific processors such as the Cray-1. At the bottom end (in terms of price) are products such as the Floating Point Systems attached pipelined processor. Why is this the case? There seem to be several possible explanations. The first is that the problems associated with parallelism for non-numeric computation have not received the same amount of attention as the numeric area. Considering the large number of papers on "database machines," this is not a very plausible explanation. There are, however, two plausible ones. The first is that while there has been a constant demand for "more cycles" for numeric computations from a variety of user groups (e.g., geologists at oil companies doing seismic data analysis, physicists at Lawrence Livermore Laboratory solving large sets of simultaneous differential equations), a similar market has never developed for non-numeric applications. Another feasible explanation is that the recent advances in technology have not really helped make highly parallel non-numeric processors economically viable. In this paper we intend to present and discuss a number of alternative architectures that have been proposed for nonnumeric computation. While we will not present a performance evaluation of these architectures, we have performed a number of such studies recently. 2,3,4,5 Instead, we intend to summarize the results from these studies in describing the problems associated with the architectures that have been proposed. We begin by characterizing those operations that must be efficiently supported by a non-numeric processor (regardless of whether parallelism is used). The impact of limited 110 bandwidth on parallel architectures for non-numeric processing is discussed in the third section. In the fourth and fifth sections, we describe a number of architectures that have been proposed to increase the total 110 bandwidth in the system. A class of architectures referred to as "on-the-disk" machines are described first. Processing "complex" non-numeric operations such as sorting requires a different type of machine. We discuss several alternative organizations for machines of this type in the fifth section. Finally, we present our conclusions and suggestions for future research. Non-numeric databases can be naturally divided into two classes: (1) those that contain unformatted documents such as law cases and (2) those that contain formatted data such as inventory records. In this section we will describe the types of operations that must be supported by non-numeric processors for databases of both types. Unformatted data-text retrieval systems Processing unformatted data is both simple and complex. It is simple in the sense that what is required is to make a sequential pass through a database searching for those records (documents) that have a certain property. For example, in an online medical database containing all research reports dealing with·cancer, a researcher might ask a text retrieval system to retrieve all documents that mention the word "liver." Processing queries can become significantly more complex, however. Consider the query "retrieve those documents that mention the liver and contain a reference to either the chemical 'carbon tetrachloride' or 'perchloroethylene' 0" Processing this query is difficult because the reference to one of these chemicals might appear either before or after the reference to the liver and, in general, the references may be separated by an arbitrary amount of text. Furthermore, the system must be aware of a number of different delimiters (e.g., paragraphs, chapters, etc.), so that it does not retrieve a document when the query is satisfied by strings outside of the appropriate context. The number of documents that must be searched to process a query can be reduced by maintaining secondary indices6 on certain key words or phrases such as "organ type." However, simply storing these indices can become prohibitive when indices must be maintained for a large number of different keywords. Unless users access the database using only a limited number of key words (i.e., organ names or chemical names), secondary indices are not viable. Thus, since processing a query involves primarily a linear scan of the database, application of parallel processing techniques appears to be a very promising approach to providing fast access to very large unformatted databases. In the section on search machines, we will describe several architectures that are well suited for processing unformatted queries. Formatted data-database systems While a number of different data models have been proposed for describing the logical organization of a formatted From the collection of the Computer History Museum (www.computerhistory.org) 210 National Computer Conference, 1982 database,6 most researchers who have designed special purpose architectures for enhancing database system performance have assumed the relational data model. This has occurred primarily because of the regUlarity of the relational data model for specifying information on both entities (e.g., parts, suppliers) and relationships between entities (e.g., which parts a supplier supplies). A relational database7 consists of a number of normalized relations. Each relation is characterized by a fixed number of attributes and contains an arbitrary number of unique tuples. Thus, a relation can be viewed as a two-dimensional table in which the attributes are the columns and the tuples are the rows. In a relational DBMS, relations are used to describe both entities and relationships between entities. Figure 1 shows a simple database that describes information about suppliers (relation S), parts (relation P), and the association between suppliers and the parts they supply (relation SP). The operations supported by most relational database sys- tems can be divided into two classes according to the time complexity of the algorithms used on a uni-processor system. The first class includes those operations that reference a single relation and require linear time (i.e., -they can be processed in a single pass over the relation). The most familiar example is the selection operation which selects those tuples from a relation that satisfy a simple predicate (e.g., suppliers in "New y;ork"). The second class contains operations that have either one or two input relations and require nonlinear time for their execution. An example of a relation in this class that references one relation is the projection operation. Projecting a relation involves first eliminating one or more attributes (columns) of the relation and then eliminating any duplicate tuples that may have been introduced by the first step. Sorting [which requires 0 (nlogn) time] is the generally accepted way of eliminating the duplicate tuples. The join operation is the most frequently used operation from this class that references two relations. This operation can be viewed as a restricted cross-product of two relations. A join would be used by a user to find the name and address of all suppliers who supply a particular part (see Figure 1). S RELATION Si SUPPLIER-NAME 17 The problem of size ADDRESS JONES MADISON P RELATION Pi PART-NAME 36 STOVE COLOR WEIGHT YELLOW 300 SP RELATION Si pi QUANTI TY-ON-HAND 17 36 13 1--. Figure I-Supplier-parts relational database The very size of both formatted and unformatted data sets introduces two important problems. First, operations on both types of database are almost always I/O and not CPU intensive. For certain complex search conditions on both unformatted and formatted databases, a rather fast CPU may be required to process the query at the speed of the mass-storage device. However, as we will discuss in next section, during the last ten years improvements in technology have had a much more dramatic effect on performance of low-cost processing units (e.g., the Motorola 68000) than the bandwidth of I/O devices. We contend that even this type of query should be considered to be I/O limited rather than CPU limited. The second effect of very large data sets is that the algorithms used must be "external" algorithms. For example, in designing a machine that can rapidly sort very large data files, one must never make the assumption that enough main memory will be available to permit the whole file to be brought into main memory and sorted. For a single processor, the algorithm normally used is an external merge sort. 8 It is important to realize that the requirement that external algorithms be used has the side effect of increasing I/O activity. Later we will examine several architectures that employ parallelism for processing complex operations in order to minimize the number of I/O operations performed. The algorithms for processing selection operations on formatted or unformatted databases are naturally external algorithms as the normal mode of execution is to read the next block of data from mass storage and then apply the search condition to it. Since these queries can always by processed in one pass through the database, they are, when measured in terms of I/O activity, significantly simpler than sorting a very large data file. Thus a different class of architectures that exploit parallelism are appropriate. These architectures will be discussed in the fourth section. From the collection of the Computer History Museum (www.computerhistory.org) Exploiting Parallelism for Non-Numeric Applications THE PROBLEM OF I/O BANDWIDTH The key factor in limiting development of parallel processors for non-numeric computation is the lack of sufficient I/O bandwidth from commercially available mass-storage devices. Consider, for example, a typical (for 1981) mass-storage device such as the IBM 3350. Each track on this device holds 19,069 bytes, and a revolution takes 16.7 ms. Thus, the maximum burst bandwidth of the device is 1.144 Mbytes/second. This represents an improvement of only 46% in I/O bandwidth when compared with the IBM 3330-a drive that was introduced over ten years ago. As was discussed briefly in the previous section, executing a sequential search on a formatted or unformatted database is more likely to be. CPU limited than executing an external algorithm for a complex operation (e.g., a join) on a formatted database, since the first task requires only N I/O operations (one for each of the N blocks of data) while the latter requires, in general, on the order of NlogN I/O operations. It is thus most appropriate to examine the level of CPU performance necessary to process data at the rate of 1.144 Mbytes/second. At a data rate of 1.144 Mbytes/second, a processor that is directly attached to a disk controller has approximately 0.87 microseconds to process each incoming byte. If one assumes . that it takes two instructions to process each byte (one instruction both to compare the next byte of the incoming data stream with the next byte of the search pattern and to do an autoincrement of both pointers, and a second instruction to test for both loop termination and branch on failure), then the processor must be approximately a 2.3 MIP processor. While this is significantly faster than a conventional microprocessor such as a Motorola 68000 (which is about a 1 MIP processor), it is certainly within the range of a simple processor constructed using bipolar bit-slice technology. If one insists on using "off the shelf' hardware, one might use three 68000 type processors each with an associated track-long buffer to process the incoming stream of data. Since each processor would now have to process only every third track, the resulting performance should be more than adequate. For formatted databases, every byte of the incoming data stream does not need to be examined, since the offset of the fields to be examined are located at known positions in the incoming records. Thus, a single processor with two tracklong buffers would be able to process selection queries at the data rate of an IBM 3350 disk. While the disk is filling one buffer, the processor can be applying the selection criterion to the records in the other buffer. Processing a record involves simply indexing into the record (by adding the offset of the field in the record) and then applying the selection condition to the field. As long as the number of bytes to be processed does not exceed approximately one-third of the record, one processor should be able to process the records as fast as they are read off the disk. - The point that we are trying to make with these examples is that one needs, at most, two to three processors and not tens or hundreds to process data at the rate of present conventional disk drives. Thus, an architecture that blindly uses a lot of processors (no matter how they are interconnected) to process data that resides on few standard disk drives will inevitably be 211 I/O bound. Advances in disk technology hold only limited hope for a resolution of this problem. Over the past ten years, increased disk capacities have been mainly the result of an increased number of tracks per surface, rather than an increased number of bytes per track. It is only with the recent announcement of the IBM 3380 disk drive that this situation has changed significantly. The 3380, with a revolution time of 16.7 ms. and a track capacity of 47,476 bytes, has a burst data rate (assuming no seeks) of 2.85 Mbytes/second. While this is a significant improvement, it still limits the number of processors that can be effectively used to the range 6-8. In the next two sections, we will examine several architectures that have been proposed for increasing the effective I/O bandwidth. In particular, we show that the architectural solutions for processing selection operations are different than those for processing complex operations on formatted databases. SEARCH MACHINES--"ON THE DISK MACHINES" Architectures for parallel processing of selection operations on formatted or unformatted data consist of two basic components: (1) a processing element and (2) a storage unit. A number of different storage technologies can be used as the basis of the storage unit, including bubble memories, chargecoupled devices, or conventional magnetic disks. Since the logical organization of the processing elements is independent of the storage medium used, we shall assume that the storage unit is a track on a magnetic disk drive and that records are stored bitwise along the track. There are two radically different approaches for designing the search engine. The first is to use a "conventional" processor such as a Motorola 68000 or a simple processor constructed using bit-slice components. The query to be executed is first compiled (by some host processor) into the machine language (or microcode) of the processor. Next the compiled query is loaded into the memory of the processor and then executed by applying the query to the storage unit associated with the processing element. An alternative approach is to construct a special purpose processor9, 10 that behaves like a finite state automaton (FSA). In this approach the query to be processed is compiled into a state-transition matrix that is then loaded into the memory of the FSA. For each incoming byte, the FSA computes a next state based on its current state and the value of the incoming byte. Since processing any query requires only one transition for each byte in the data stream, processing an arbitrarily complex query can always be done at the speed of the data stream. The main disadvantage of this approach is that the state-transition matrix that represents the compiled query is rather large [number of rows (states) * number of different incoming symbols]. In the following sections we shall describe three ways of organizing processing elements and storage units. For each design, we have assumed that the processing elements are connected to a host processor. This processor serves two important functions. First, it accepts and compiles queries from the users of the system. Second, as we shall discuss below, it can be used to assist in the execution of certain queries that are too complex for the processing elements to handle alone. From the collection of the Computer History Museum (www.computerhistory.org) 212 National Computer Conference, 1982 Processor-per-track (PPT) machines In the first class of search machines, each storage unit has its own processing element associated with it as shown in Figure 2. The processing element scans the data as the track rotates and places selected records in an output buffer associated with the head. After a buffer fills, additional logic attempts to place its contents on the output bus for transmission to the host. In the event that the processing logic is not able to output a selected record (because the bus is busy and the temporary storage buffers are full), processing is suspended until at least one buffer is emptied. The PPT architecture appears to be feasible only if the capacity of each storage unit is much larger (with a proportionally longer revolution time). The consequences would be twofold. First, the number of units required to store a "large" database could probably be reduced to a "reasonable" level. Second, a reduction in the number of processing units would ease the output bus bottleneck problem. There are two techniques of increasing storage unit capacities. One is to use a different storage medium such as bubble memories (some of which have a capacity of one million bits each l7). While the performance of such an approach is excellent,2 most manufacturers are dropping bubble memory components because their cost per bit has not become competitive. A second approach is to associate each processing element not with a single track of a disk, but rather with an entire surface of a disk. This approach is discussed in the following section. HOST PROCESSOR PROCESSING } ELEMENTS } S~ORAGE UNITS DATABASE Figure 2-PPT design PPT machines were pioneered in 1970 by Slotnick,1 who suggested using first a track of a fixed head disk as the unit of storage and includes machines proposed by Parker, 11 Minsky,12 and Parhami.13 Two early database machine designs, RAp I4 , 15 and CASSM,16 also belong to this class. Two versions of RAP, each having two processing elements and two storage units, were constructed using first a fixed head disk and then charge coupled devices. Because the entire database can be searched in one revolution of the storage units, this architecture is, at first glance, very appealing. However, it has a number of serious flaws. First, if magnetic disk technology is used as the basis of the storage unit, an extremely large number of storage units and cells are needed. Assume, for example, a state-of-the-art track capacity of 50,000 bytes. To have the same storage capacity as a conventional 300 Mbyte disk drive (which can hold only a very small database), 6,000 storage units and processing elements would be needed. The resulting system would most likely be relatively unreliable. A second major problem with this approach is that the bus connecting these 6000 processing elements to the host can easily become a bottleneck. Assume that the bandwidth of the output bus is 10 Mbytes/second. If the storage units have a revolution time of 16.67 ms., the maximum aggregated bandwidth of the processing elements is 18 billion bytes/second. Even if only 0.1 % of the data stored in each storage element satisfies the search condition, the processing elements will have an output bandwidth of 18 Mbytes/second and hence the bus wiU stili be a bottleneck. Processor-per-head (PPH) machines In the second class of search machines, each processing element is associated with a head of a moving-head disk as illustrated in Figure 3. Thus, the storage unit consists of all the tracks on the surface of a disk instead of a single track. In this class of machines, data is transferred in parallel over I-bit wide data lines from the heads to the processing elements. Each processor applies the selection criteria to its incoming data stream and places selected records in its output buffer, In such an organization, an entire cylinder of a moving-head disk is examined in a single revolution (assuming no output bus contention). As in PPT organizations, additional revolutions may be needed to complete execution of the query if an output buffer overflows. The DBC18 database machine project adopted the PPH approach over the PPT approach as the basis for the design of the "Mass Memory Unit" because PPT devices were not deemed to be cost-effective for the storage of large databases (say more than 1010 bytes). Another possible reason for taking this route is the apparent lack of success of head-per-track disks as secondary storage devices. Moving-head disks with parallel readout, on the other hand, seemed an attractive and feasible alternative. The Technical University of Braun- CONTROL HOST PROCESSOR PROCESSING ELEMENTS Figure 3-PPH design From the collection of the Computer History Museum (www.computerhistory.org) Exploiting Parallelism for Non-Numeric Applications schweig, in cooperation with Siemens, has actually built one for use in the Braunschweig search machine SURE.19 It is the case, however, that parallel readout disks are presently not widely available (a 600-Mbyte drive with a 4-track parallel readout capability and a data transfer rate of 4.84 Mbytesl second is, however, available for the Cray-l for approximately $80,000 without controller) and may never be cost-effective for the storage of large databases (when compared to "stan~ard" drives). 213 processor "join" each tuple in S with all the tuples from R returned by the execution of its subquery. The performance of this approach, however, is very poor. 3 In fact, it is inferior to using only the host processor to perform a traditional "sort-merge" join. In the next section, we will describe several non-numeric architectures that are designed to process complex database operations effectively. MACHINES FOR COMPLEX DATABASE OPERATIONS Processor-per-disk (P P D) machines Unlike the PPT and PPH approaches, the PPD organization utilizes a standard disk drive. In this organization, a processing element is placed between the disk and the memory device to which the selected records are to be transferred as shown in Figure 4. This processor acts as a filter 9 to the disk by forwarding to the host only those records that match the selection criteria. At first glance, it seems as though this approach is so inferior to the others that it does not merit any attention. However, its advantage is that for a relatively low price one can obtain the same functionality (but not the same performance) as the PPT and PPH designs. In addition, by broadcasting the data stream from the disk to a set of processing elements,19 one can simultaneously process selection queries from different users over the same database. Use of Search Machines for Complex Database Operations Since the only functionality provided by the PPT, PPH, and PPD designs is to process selection queries, each of these designs processes complex operations (e.g., join) on formatted databases by decomposing the query using an algorithm based on Wong's tuple substitution algorithm.20 Assume that the join operation as specified by the user has the form R. a = S. b and that S contains fewer tuples than R. These designs will process this query by issuing one selection subquery for each tuple in S. The form of each subquery will be R. a = x where x is the join attribute value from the current tuple in S. The result relation is produced by having the host HOST PROCESSOR Parallelism can also be employed to enhance the performance of complex database operations. The use of parallel processors to enhance the performance of the relational join and project operations is highly desirable, since both are very time-consuming in a conventional database management system. As discussed by De Witt and Hawthorn3 and Boral, De Witt, Friedland and Wilkinson, 21 we strongly advocate an "algorithmic approach" to the design of architectures that use parallelism to enhance the performance of non-numeric operations. As an example of a complex operation, we present the relational join operator in the following section. Afterwards, we discuss four alternative building blocks that can be used as the basis for parallel algorithms for complex formatted database operations. Then we describe parallel architectures based on two of these building blocks. Because a performance analysis of these alternative algorithms and architectures is beyond the scope of this paper, the interested reader is encouraged to examine Boral, DeWitt, Friedland and Wilkins21 and Friedland. 4 Unlike the selection operation; for which a partition of the data can be searched independently by each processor, the join, projection, and the other complex operations require that the processors exchange data among themselves during intermediate stages of execution. In addition, the volume of I/O activity is significantly higher, since unlike the selection operation, these operations cannot be performed in a single pass over the operand relations. While the building blocks vary in terms of the degree of interprocessor communication and amount of I/O activity each requires, the architectural features that are needed to efficiently execute these tasks include a fast interprocessor communication facility and a cost-effective, mass-storage device that provides high I/O bandwidth. PROCESSING ELEMENT "DISK CONTROLLER Figure 4-PPD design The relational join operation In Figure 5 the execution of the join operation is illustrated by the "nested-loops" algorithm. Relations Rand S are assumed to have Nand M tuples respectively, and fields r of relation Rand s of relation S are assumed to be of the same type. Execution of the join requires that the r field from each tuple of R be compared to the s field from each tuple of S. When they match, the two tuples are concatenated. In general, each tuple in R will match an arbitrary number of tuples in S. In the worst case, the join of Rand S will produce N* M tuples. From the collection of the Computer History Museum (www.computerhistory.org) 214 National Computer Conference, 1982 for i <- 1 to N do for j <- 1 to M do if R .. r = 5 .. s then begin ] t = join(R!,S.!); output(t) 1.1.- J end; Figure 5-The nested-loops join algorithm Building blocks for complex database operations While the nested-loops join algorithm is adequate for "small" relations, it is a very slow method joining two "large" relations. If indices exist on the join attributes for both relations, then the join can instead be performed on the index entries (instead of the tuples themselves).22, 23 This procedure substantially reduces the volume of 110 activity, since the index files are much smaller than the data files. If indices are not available, the join of two "large" relations is usually performed by presorting the operand relations. This process is followed by a modified merge phase in which matching tuples are located and joined. After the relations have been sorted, the actual join step requires only a linear pass through both relations. Sorting is also used by conventional database management systems to efficiently perform the duplicate elimination part in the projection. Alternatively, hashing24 can be employed to eliminate duplicate tuples in a projected relation. There appear to be four building blocks that can be used as the basis for parallel algorithms (and parallel machines to execute these algorithms) for complex database operations. They are 1. 2. 3. 4. Indexing Hashing Sorting Broadcasting Of these four techniques, sorting and broadcasting appear to us to be the most promising. In the following paragraphs we will describe a number of unresolved problems associated with using indices and hashing as basic building blocks. In both cases we shall use the join operation as a vehicle for explaining our objections. The basic idea of using indexing2S in a parallel algorithm for the join operation is to have both the indices and the corresponding relations uniformly partitioned among the processors, each of which has a mass-storage device associated with it. During execution of the algorithm, each processor uses its portion of the indices to compute its portion of the result relation. The fundamental flaw of this approach is that it assumes that if you uniformly distribute the tuples from both relations among all the processors, the two tuples from Rand S with the same attribute value will end up on the same processor. Goodman and Despain2s also propose using hashing as the basis for a parallel join algorithm. Again the two relations are assumed initially to be uniformly distributed among all the processors. The algorithm begins by applying a hash function to the "joining" attribute of both relations. This hash function is used to compute a processor number. After the appropriate processor has been identified, the tuple is sent to the processor to be joined with the tuples with the same attribute value. During the second phase of the algorithm, each processor joins the tuples it receives as the result of the first phase. There are a number of problems associated with this algorithm. First note that the number of distinct join attribute values will, in general, be much larger than the number of processors available. Thus, each processor will receive tuples with a range of join attribute values. As a consequence, the processor must somehow (e.g., by sorting) determine exactly to which tuples every tuple is to be joined. A second problem is the cost of moving almost every tuple to a different processor from where it originally resided. While both of these problems have solutions, a serious problem that is impossible to resolve remains. The idea of using a hash function in the first place was to distribute the tuples in a manner that would permit all processors to help perform the actual join operation. However, when there are only a few join attribute values, only a few processors will be used to actually perform the join. In general, since the distribution of join attribute values is unknown, the performance of a machine designed around this algorithm will be unpredictable (an unsettling fact). An architecture based on parallel sorting Until recently,4 parallel sorting had not been suggested or investigated as the basis for performing complex database operations. This can be partly explained by the lack of research in the parallel external sorting area. While extensive literature on parallel sorting exists, no algorithms had been developed for sorting in parallel large mass-storage files. When one considers how successful sorting is for performing complex operations on a single processor, it is natural also to examine_ its use for parallel architectures. Friedland4 has examined and analyzed a number of external parallel sorting algorithms and architectures. The algorithms that display the best performance are based on either a twoway external merge step26 or an extension of Batcher's bitonic sort27 to permit the sorting of external data files. In general case, the algorithm based on the two-way external merge step, termed the parallel binary merge algorithm, has the best performance. In this section we will describe the operation of this algorithm on an architecture that permits the efficient execution of the algorithm. Use of this algorithm for performing the join would occur in two steps. First, both relations would be sorted on the joining attribute. Next, one processor would be used to join the two relations by reading the sorted files in a sequential pass through them. Tuples from the two relations with equal joining attribute values would then be joined. Execution of the parallel binary merge algorithm is divided into three stages as shown in Figure 6~ Wea~~~me that th~. number of pages to be sorted, N, is at least twice the number of processors, P. The algorithm begins execution in a suboptimal stage in which sorting is done by successively merging pairs of longer and longer runs until the number of runs is From the collection of the Computer History Museum (www.computerhistory.org) Exploiting Parallelism for Non-Numeric Applications 215 SUBOPTIMAL STAGE OPTIMAL STAGE INPUT DRIVE POSTOPTIMAL STAGE OUTPUT DRIVE Figure 6-Parallel binary merge with 4 processors and 16 pages Figure 7-Binary tree interconnection between the processors equal to twice the number of processors. During the suboptimal stage, the processors operate in parallel but on separate data. First, each of the P processors reads two pages and merges them into a sorted run of two pages. This step is repeated until all single pages have been read. If the number of runs of two pages is greater than 2 *P, each of the P processors proceeds to the second phase of the suboptimal stage in which it repeatedly merges two runs of two pages into sorted runs of four pages until all runs of two pages have been processed. This process continues with longer and longer runs until the number of runs equals 2* P. When the number of runs equals 2* P, each processor will merge exactly two runs of length N /2P. We term this phase the optimal stage. At the beginning of the postoptimal stage, the controller releases only one processor and logically arranges the remainder as a binary tree (see Figure 6). During the postoptimal stage, parallelism is employed in two ways. First, all processors at the same level of the tree (Figure 6) execute concurrently. Second, pipe lining is used between levels. By pipelining data between levels of the tree, a parent is able to start its execution a single time unit after both its children (i.e., as soon as its children have produced one output page). The ideal architecture for the execution of this algorithm is a binary tree interconnection between the processors as shown in J:igure 7. The mass-storage device consists of two disk drives, and each leaf processor is associated with a surface on both drives as in the PPH organization. This organization permits the leaf processors to do I/O in parallel while reducing almost in half the number of processors that actually must do input/output. Analysis of the performance of this architecture shows substantial performance improvements (over a single processor) when such a mass-storage device is available. If, however, only two conventional disk drives are available, the performance improvement achieved is very limited, which indicates again the need for more I/O bandwidth if parallel architectures for non-numeric applications are to be viable. An architecture based on broadcasting By using broadcasting as a basic building block, a number of very simple and relatively fast parallel algorithms for complex database operations can be constructed. As an example, consider the nested-loops join algorithm shown in Figure 5 and assume that Nand M refer to the number of disk pages occupied by relations Rand S, respectively, instead of the number of tuples. Also assume (for the moment) that N processors are available. A parallel nested-loops join algorithm would begin by having each of the N processors read one page from relation R. Next, the M pages of relation S are broadcast, one at a time, to all the processors. Upon receipt of a page of S, each processor will apply the nested-loops join algorithm to its page of R and the incoming page of S. If P < N processors are available, the algorithm is executed in N/P stages. Furthermore, as shown in Figure 8, the architecture required to support these algorithms is straightforward. All that From the collection of the Computer History Museum (www.computerhistory.org) 216 National Computer Conference, 1982 BROADC;\ST BUS Figure 8--An architecture based on broadcasting is required is a bus that is capable of broadcasting at the same data rate of the mass-storage device. The main disadvantage of this approach is that the first step of the algorithm in which each processor gets a page of R is sequential. It can, however, be parallelized if R resides on a parallel-readout disk drive. CONCLUSIONS AND FUTURE DIRECTIONS From the discussions contained in this paper we are able to draw a number of conclusions about parallel architectures for non-numeric applications. First, manufacturers must place more emphasis on the development of mass-storage devices that have higher transfer rates if parallel architectures for non-numeric applications are to become viable. Second, while we have suggested two different styles of parallel architectures for execute searching and complex operations, database management systems perform both types of operations. Thus, it appears worthwhile to investigate the design of a machine that combines the ability of the "on the disk" machines to process selection queries rapidly with those features that facilitate execution of complex operations on formatted databases. The RDBM28 represents a first attempt at designing such a machine. ACKNOWLEDGMENTS We would like to acknowledge support of this research by the Department of Energy under contract #DE-AC0281ER10920 and the National Science Foundation under grant MCS78-01721. REFERENCES 1. Siotnik, D. L. "Logic per Track Devices." In Frantz Alt (ed.), Advances in Computers (Vol. 10), New York: Academic Press, 1970, pp. 291-296. 2. Boral, H., D. J. DeWitt, and W. K. Wilkinson. "Performance Evaluation of Four Associative Disk Designs." Journal of Information Systems, Vol. 7, No.1, January 1982. 3. D. DeWitt and P. Hawthorn. "Performance Evaluation of Database Machine Architectures." Invited paper, Proceedings of the 7th International Conference on Very Large Databases, September 1981. 4. Friedland, Dina B. "Design, Analysis, and Implementation of Parallel External Sorting Algorithms." Computer Sciences Technical Report #464, University of Wisconsin, January 1982. 5. Hawthorn P. and D. J. DeWitt. "Performance Evaluation of Database Machines." IEEE Transactions on Software Engineering, January 1982. 6. Date, e. J. An Introduction to Database Systems. Reading, Mass.: Addison-Wesley, 1981. 7. Codd, E. F. "A Relational Model of Data for Large Shared Data Banks." Communications of the ACM, Vol. 13, No.6, June 1970. 8. Knuth D. E. The Art of Computer Programming-Sorting and Searching. Reading, Mass.: Addison-Wesley, 1975, p. 160. 9. Bancilhon F. and M. Scholl. "Design of a Backend Processor for a Data Base Machine." Proc. of the ACM SIGMOD 1980 International Conference of Management of Data, May 1980. 10. Haskin, R. L. "Hardware for Searching Very Large Text Databases." Proceedings of the Fifth Workshop on Computer Architecture for Non-Numeric Processing, March 1980, pp. 49--56. 11. Parker J. L. "A Logic per Track Retrieval System." IFIP Congress, 1971. 12. Minsky N. "Rotating Storage Devices as Partially Associative Memories." Proc. 1972 FJCe. 13. Parhami B. "A Highly Parallel Computing System for Information Retrieval." Proc. 1972 FJCe. 14. Ozkarahan, E. A., S. A. Schuster, and K. e. Smith. "RAP-Associative Processor for Database Management." AFlPS Conference Proceedings (Vol. 44) 1975, pp. 379--388. 15. Sadowski P. J. and S. A. Schuster. "Exploiting Parailelism in a Relational Associative Processor." Fourth Workshop on Computer Arch. for Nonnumeric Processing, Aug. 1978. 16. Su, Stanley Y. W., and G. Jack Lipovski. "CASSM: A Cellular System for Very Large Data Bases." Proceedings of the VLDB, 1975, pp. 456--472. 17. Bryson, D., D. Clover, and D. Lee. "Megabit Bubble-Memory Chip Gets . Support From LSI Family." Electronics, April 26, 1979. 18. Kannan, Krishnamurthi. "The Design of a Mass Memory for a Database Computer." Proc. Fifth Annual Symposium on Computer Architecture, Palo Alto, CA., April 1978. 19. Leilich H. 0., G. Stiege, and H. Ch. Zeidler. "A Search Processorfor Data Base Management Systems." Proc. 4th Conference on Very Large Databases. 1978. 20. Wong, E. and K. Youssefi. "Decomposition-A Strategy for Query Processing. ,. ACM Transactions on Database Systems, Vol. 1, No.3, September 1976, pp. 223-241. 21. Boral, H., D. J. DeWitt, D. Friedland, and W. K. Wilkinson. "Parallel Algorithms for the Execution of Relational Database Operations." submitted to ACM Transactions on Database Systems, October, 1980. 22. Astrahan, M. M. et al. "System R: Relational Approach to Database Management." ACM Transactions on Database Systems, Vol. 1, No.2, June 1976, pp. 97-137. 23. Blasgen M. W. and K. P. Eswaran. "Storage and Access in Relational Data Bases." IBM System Journal, Vol. 16, No.4, 1977. 24. Babb, E. "Implementing a Relational Database by Means of Specialized Hardware." ACM Transactions on Database Systems, Vol. 4, No.1, March 1979, pp. 1-29. 25. Goodman, J. R. and A. M. Despain. "A Study of the Interconnection of Multiple Processors in a Data Base Environment." Proceedings 1980 International Conference on Parallel Processing, August 1980, pp. 269--278. 26. Even, S. "Parellelism in Tape Sorting." CACM, Vol. 17, No.4, April 1974. 27. Batcher, K. E. "Sorting Networks and Their Applications." Proceedings Spring Joint Computer Conference (Vol. 32) 1968, pp. 307-314. 28. Hell, W. "RDBM-A Relational Data Base Machine: Architecture and Hardware Design." Proceedings of the 6th Workshop on Computer Architecture for Non-Numeric Processing, June 1981. From the collection of the Computer History Museum (www.computerhistory.org)