M. Stonebraker. The Case for Shared Nothing. IEEE Database Engineering, Mar. 1986.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....like windowed joins and group by aggregate, which may easily outgrow a single site s main memory, to utilize aggregate main memory and other resources. Shared nothing clusters can scale to thousands of computers, scaling available main memory, processors, disk space and bandwidth along the way[8, 28, 30], and thereby provide the potential for high throughput and low latencies. Yet, to date, the sharednothing approach has been overlooked for CQ systems. CQ systems strain traditional dataflow parallelism techniques, because they require adaptive, online repartitioning of lookup based operators. ....

....8 summarizes and presents future work. 2. Background and Contribution In this section, we describe previous approaches for optimizing and executing parallel query plans, delineate their inadequacies in the CQ context, and outline our contribution. For this work, we assume a shared nothing [28] or cluster based parallel computing architecture in which each processing node (or site) has a private CPU, memory, and disk, and is connected to all other nodes via a highbandwidth, low latency network. 2.1. Previous Approach A popular approach for parallel database queries consists of two ....

M. Stonebraker. The Case for Shared Nothing. IEEE Database Engineering, Mar. 1986.

....like windowed joins and group by aggregate, which may easily outgrow a single site s main memory, to utilize aggregate main memory and other resources. Shared nothing clusters can scale to thousands of computers, scaling available main memory, processors, disk space and bandwidth along the way[8, 28, 29], and thereby provide the potential for high throughput and low latencies. Yet, to date, the sharednothing approach has been overlooked for CQ systems. CQ systems strain traditional dataflow parallelism techniques, because they require adaptive, online repartitioning of lookup based operators. ....

....8 summarizes and presents future work. 2. Background and Contribution In this section, we describe previous approaches for optimizing and executing parallel query plans, delineate their inadequacies in the CQ context, and outline our contribution. For this work, we assume a shared nothing [28] or cluster based parallel computing architecture in which each processing node (or site) has a private CPU, memory, and disk, and is connected to all other nodes via a highbandwidth, low latency network. 2.1. Previous Approach A popular approach for parallel database queries consists of two ....

M. Stonebraker. The Case for Shared Nothing. IEEE Database Engineering, Mar. 1986.

....4, 7, 12, 17, 18] In this architecture, the processing nodes (PNs) are interconnected through a communication network. Each PN has its own private memory and dedicated disk drives. Parallel database systems implemented for this hardware structure are popularly known as shared nothing (SN) systems [16]. The join operation has been the most intensively studied among the relational operations for SN systems. Several parallel join algorithms have been proposed. Among them, hash based algorithms [9, 15] are particularly suitable for the multicomputer model. In these strategies the relations are ....

M. Stonebraker. The case for shared nothing. IEEE Database Engineering, 9(1):4-9, March 1986.

....strategy is to use the server model. In this scheme, server processes exist independently of queries; the processing tasks of a query are dynamically bound to the appropriate servers. To minimize the interference problem, a popular technique is to use the shared nothing (SN) computation model [20]. In this approach, base relations are fragmented and distributed among the PNs. Each primitive database operation can be decomposed into many independent operators, each executed in a distinct PN. Obviously, the effectiveness of this scheme depends on the physical layout of the data. This leads ....

M. Stonebraker. The case for shared nothing. IEEE Database Engineering, 9(1):4--9, March 1986.

....Most of the error detection and reconfiguration should be done in software. The HypRa design philosophy gives the added advantage of low hardware cost and a high degree of scalability. HypRa is a homogeneous, coarse grained, shared nothing, parallel computer with typically from 4 to 1024 nodes ([28], 25] HypRa consists of a set of identical microcomputers (nodes) each with its own internal bus, memory and disc channels. Multiple discs are connected to each node. Since the nodes only interact through the communication channels, a high degree of node isolation is achieved. A node has an ....

M. Stonebraker. The Case for Shared Nothing. IEEE Database Engineering, 9(1), 1986.

....of the error detection and reconfiguration should be done in software. The HypRa design philosophy gives the added advantage of low hardware cost and a high degree of scalability. HypRa will be a homogenous, shared nothing, parallel computer with typically from 4 to 1024 coarse grained nodes ([39], 35] The machine consists of a set of identical microcomputers (nodes) with its own internal bus, memory and discs channels. Multiple discs are 2 DBMS DBMS DBMS Node Node Node HW architecture Distributed DBMS . SW architecture . D D RAM CPU NC NC NC Hardware ....

M. Stonebraker. The Case for Shared Nothing. IEEE Database Engineering, 9(1), 1986.

....systems that also have high availability characteristics ( TDG87] SKPO88] MHLPS92] Tandem s NonStop SQL ( TDG87] TPG88] BP88] is one such system. NonStop SQL runs in a shared nothing, multi processor architecture that provides high performance through scalable parallelism ( Bar81] [Sto91]) High availability is afforded Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the VLDB copyright notice and the title of the publication and its date appear, and notice is given that ....

M. Stonebraker. The Case for Shared Nothing. IEEE Database Engineering, March, 1991.

....In Section 4 we present the results of our simulation experiments and discuss their implications. Concluding remarks are given in Section 5. 2 Overview Our objective is to build a database system that captures the key advantages of the SN and SE approaches. From the discussions in the literature [Sto86, DG90, DG92] we know that the main drawback to sharing is scalability. We identify the following simple guidelines to building a scalable system: 1. Eliminate central resources that can become bottlenecks. 2. Minimize communication and thus avoid making the interconnect a bottleneck. 3. Utilize ....

M. Stonebraker. The case for shared nothing. IEEE Database Engineering, 9(1), March 1986.

....reserved. 1 Introduction 1.1 Data Sharing Systems There has been little written in the open literature on how to handle logging in system configurations where a number of computers all access a collection of shared disks. This configuration is called a cluster[6] or a shared disk system [2,13]. A database system that exploits the configuration such that any computer can access any of the data within a single transaction is called a data sharing system. Two commercial systems offering data sharing are Digital s Rdb VMS (and DBMS) 10] and IBM s IMS VS Data Sharing product[14] A data ....

Stonebraker, M. The case for shared nothing. IEEE Database Engineering 9,1 (Jan 1986) 4-9.

....trend towards structuring system software to allow application control over policy decisions. Other examples include thread scheduling [Anderson et al. 1992] interprocess communication [Bershad et al. 1991] compiler optimizations [Steele Jr. 1990] database access routines [DeWitt Carey 1984, Stonebraker 1987] and desktop publishing [Ald 1992, Clark 1992, Dyson 1992] In all of these cases, an applicationspecific structure offers the potential for more flexibility and better performance, in part because it is difficult to design a complex system to be optimal for all users of the system. In our view, ....

Stonebraker, M. Extensibility in POSTGRES. IEEE Database Engineering,, September 1987.

....Section 4 we present the results of our simulation experiments and discuss their implications. Concluding remarks are given in Section 5. 2 Overview Our objective is to build a database system that captures the advantages of both the SN and SE approaches. From the discussions in the literature [26, 8, 6] we know that the main drawback to sharing is scalability. We identify the following simple guidelines to building a scalable system: 1. Eliminate central resources that can become bottlenecks. 2. Minimize communication and thus avoid making the interconnect a bottleneck. 3. Utilize modular, ....

M. Stonebraker. The case for shared nothing. IEEE Database Engineering, 9(1), March 1986.

....techniques were developed for handling distributed query optimization [3, 38, 8] and distributed transactions [3, 23] Commercial systems based on these techniques are now available from several relational DBMS vendors. Architecturally, each distributed DBMS assumes a share nothing architecture [42] and supports the basic distributed processing model of moving query to data . Thus, these systems allocate data to the sites in a computer network and the data allocation is managed by a database administrator. Another distinct feature of distributed database systems is to have a dedicated ....

M. Stonebraker. The case for shared nothing. IEEE Database Engineering, 9(1), 1986.

....between parallel databases and parallel applications we outline our assumptions regarding the parallel database and parallel application models. Parallel database model: In order to simplify our discussion, we assume that the underlying database architecture is a Shared Nothing (SN) architecture [18] based on a Massively Parallel Processing (MPP) system. In the SN parallel database model [3, 4, 6] each table is partitioned and declustered across a number of nodes. Figure 2 shows a typical database application. From the DBMS perspective, the application starts by connecting to a database ....

M. Stonebraker. The Case for Shared Nothing. IEEE Database Engineering, 9(1), March 1986.

....can provide services that prevent faults in distrusted modules from corrupting application data. Such fault isolation services also facilitate software development by helping to identify sources of system failure. For example, the postgres database manager includes an extensible type system [Sto87] Using this facility, postgres queries can refer to general purpose code that defines constructors, destructors, and predicates for user defined data types such as geometric objects. Without fault isolation, any query that uses extension code could interfere with an unrelated query or corrupt ....

Michael Stonebraker. Extensibility in POSTGRES. IEEE Database Engineering, September 1987.

No context found.

St86 Stonebraker, M. 1986: The Case for Shared Nothing. IEEE Database Engineering 9(1), 4-9.

No context found.

M. Stonebraker. The Case for Shared Nothing. IEEE Database Engineering, Mar. 1986.

No context found.

M. Stonebraker. The Case for Shared Nothing. IEEE Database Engineering, 9(1), 1986.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC