Carey M J and Dewitt D J, The Architecture of the EXODUS Extensible DBMS, in: Proc. of IEEE International Workshop on Object-Oriented Database Systems (Paci c Grove, CA, 1986) 52-65.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....deletion, and modification of the objects that comprise such content descriptions, with concurrent update of the indices involved. C database engine provides persistence primitives that can be used by the description manager, if the repositories of the description type are stored in EXODUS [6], the native storage manager of I C. Alternatively, the description manager may employ an arbitrary persistence method (or methods) possibly exploiting data distribution and parallel search strategies. The description matcher processes contentbased queries addressed to the description type and ....

....C database engine provides primitives for the management of object clusters and indices, which can be used as the building blocks in the development of data repositories for description types. C database engine has been implemented as a client process on top of the EXODUS storage object manager [6]. EXODUS is an extensible database system indented to simplify the development of high performance application specific database systems. According to the OO7 benchmark, EXODUS rates highly among existing OODBMS [7] The EXODUS storage manager client library is linked to the I database engine ....

Carey, M.; DeWitt, D.; Frank, D.; Graefe, G.; Richardson, J.; Shekita, E.; Muralikrishna, M. The architecture of the EXODUS extensible DBMS. In: Dittrich, K.R.; Dayal, U.; Buchman, A.P., eds. On Object-Oriented Database Systems. Springer-Verlag; 1991:231-257. 22

....as C and Smalltalk, with the desirable features of databases, such as concurrency control, recovery, and security, while retaining support for the rich data types and semantics of object oriented languages. Examples of systems that have followed this approach include research prototypes such as [16] and a number of commercial products [7, 66] The object relational database (ORDBMS) systems, on the other hand, approach the problem of adding additional data types by extending the existing relational model with the full blown type hierarchy of object oriented languages. The key observation ....

Michal J. Carey, David J. DeWitt, Daniel Frank, M. Muralikrishna, Goetz Graefe, Joel E. Richardson, and Eugene J. Shekita. The Architecture of the EXODUS extensible DBMS. In Proc. of the 1986.

....These advanced applications differ from conventional (business) applications in a number of important aspects including data modeling and processing, concurrency control and recovery mechanisms, as well as access methods and storage structures. Most of the design and implementation approaches [5,6,8,25,26,28,36,41] refer to some kind of object orientation and extensibility. In these cases, the overall uniting characteristic is adequate support for complex objects. This is accomplished in different ways starting from only a few selected extensions of the relational model and leading up to the integration and ....

M.J. Carey, et al., The Architecture of the EXODUS Extensible DBMS, in: [8], 52-65.

....RDBMS technology does not adequately meet the needs of certain non traditional applications. Consequently, some new approaches have been proposed to increase DBMS expressive power and efficiency in these cases. One such approach, the extensible database management system (exemplified by EXODUS [CARE86] and POSTGRES [STON86a] allows the user to define new operators, types and access methods without significant modification of the underlying database system. However, some extensions do not fit precisely into the extensibility models provided by these systems since they involve changes more ....

....and functions are ideally suited for supporting multimedia information retrieval research. For example, POSTGRES applications have been storing and displaying large text objects (news articles) and images (X Window System bitmaps) since 1987. Unlike users of other extensible systems (e.g. EXODUS [CARE86]) the POSTGRES user need not stop the system and recompile it every time new code is added. In POSTGRES, the query optimizer and query processor are table driven and all user defined extensions used in a query may be loaded into a POSTGRES server process at runtime. That is, the types and ....

M. J. Carey, D. Frank, M. Muralkrishna, D. J. DeWitt, G. Graefe, J. E. Richardson and E. J. Shekita, "The Architecture of the EXODUS Extensible DBMS", Proc. 1986 Int. Wksp. on Object-Oriented Database Systems, Asilomar, CA, Sep. 1986.

....and a cost function to each query. The database administrator has the option of defining new cost functions and new search strategies or transformation functions for new classes of queries as they are developed. 5 Prototype Implementation The TIGUKAT object model is implemented on top of EXODUS [6]. EXODUS is a fairly full fledged system providing many aspects of DBMS functionality. We actually use only its storage system (called EXODUS Storage Manager ESM for short) to provide persistence for TIGUKAT objects. The general architecture of our implementation is shown in Figure 5. The ....

M. Carey, D.J. DeWitt, D. Frank, G. Graefe, M. Muralikrishna, J.E. Richardson, and E.J. Shekita. The Architecture of the EXODUS Extensible DBMS. In M. Stonebraker, editor, Readings in Database Systems, pages 488--501. Morgan Kaufmann, 1988.

....independent. On the other hand, leaf nodes in any index are assumed to contain physical pointers to the data (not indirect pointers such as OID s) ffl Other parameters are assumed as shown in Table 1. To make the evaluation realistic and objective, these default values were taken from [33] and [9]. 1) Cost functions for no caching: When persistent caching is not used, the cost functions for each processing step of the test query are (the step names correspond to those in Section V.B) 20 1. Sel Step 1) The page cost to access the secondary index pages for the selected oe S jjSjj objects ....

M. J. Carey,D.J.DeWitt,D.Frank, G. Graefe, J. E. Richardson, E. J. Shekita, and M. Muralikrishna. The architecture of the EXODUS extensible DBMS. In Proc. Int. Workshop on Object-Oriented Database Systems, Sep. 1986.

....the risk that the maintenance of such a system is abandoned in the course of their project. A lesson we therefore draw from the SAMOS project (and also from EvE) is that the database community should establish some kind of open database software foundation and that making systems (such as Exodus [9], Shore [11] Open OODB [73] available should be rewarded much more than today. 6 ....

M.J. Carey, D.J. DeWitt, D. Frank, G. Graefe, J.E Richardson, E.J. Shekita, M. Muralikrishna. The Architecture of the EXODUS Extensible DBMS. In K.R. Dittrich, U. Dayal, A.P. Buchmann (eds). On Object-Oriented Database Systems. Springer 1991.

....A typical image might be several megabytes and an application program that processes images requires retrieval and storage of such objects at high bandwidth. Current commercial systems tend not to store such objects at all, while prototype extendible systems (e.g. POSTGRES [STON86] and EXODUS [CARE86]) have been designed with object management needs in mind. The current design of both systems will limit the speed at which large objects can be retrieved to the sequential reading speed of a single disk (about 1.5 mbytes sec for current low end disks) Hence, a 64 mbyte object will require about ....

....Using this technique of user written procedures, POSTGRES can provide a variable speed interface. Hence, a transaction can make use of the maximum amount of data base services consistent with its performance requirements. This approach should be contrasted with toolkit systems (e.g. EXODUS [CARE86]) which require a data base implementor to build a custom system out of tool kit modules. 2.2. Inter query Parallelism There is no reason why all commands in TP1 cannot be run in parallel. If any of the resulting parallel commands fails, then the transaction can be aborted. In the usual case ....

Carey, M. et. al., "The Architecture of the EXODUS Extensible DBMS," Proc. International Workshop on Object-oriented Data Bases, Pacific Grove, CA, Sept. 1986.

....some processes may be more tightly coupled than others, for example they may reside on the same processor and share parts of the same virtual address space. The DSP model was adopted in the design of Distributed Texas. This contrasts with other distributed stores, such as Shore [4] and Exodus [3], which adopt the client server model. Compared with the clientserver model, the DSP model s more tightly coupled nature is better suited to a multicomputer with a high speed, low latency communications network than to the loosely coupled distributed environments 4 Process Processor Shared ....

CAREY, M. J., AND DEWITT, D. The architecture of the EXODUS extensible DBMS. In Proc. Int. Workshop on Object-Oriented Database Systems (Pacific Grove, CA (USA), Sept. 1986), IEEE, pp. 52--65.

....server process y initial situation z flush after y y page flush before flush z y y x x x x y x z Figure 2.14: Problem with transactional mark and sweep. with transactions in a client server database. The collector runs on the server and was implemented in the EXODUS database [27]. We call it transactional mark and sweep. When a reference to some object is discarded inside a transaction, the pointed object is eligible for collection only after the commit of that transaction. This rule prevents the unsafe reclamation of an object that becomes unreachable during a ....

Michael J. Carey and David DeWitt. The architecture of the EXODUS extensible DBMS. In Proc. Int. Workshop on Object-Oriented Database Systems, pages 52-- 65, Pacific Grove, CA (USA), September 1986. IEEE. BIBLIOGRAPHY 146

....for advanced applications. Thus, one should open up the DBMS architecture to permit the inclusion of user defined types, written in a convenient implementation language, such as C C . Exemplar research projects in this area are the extensible database architectures of [Gardarin 88, Batory 84, Carey 86] Object oriented database systems are strongly influenced by object oriented programming concepts [Goldberg 83, America87, Stroustrup] Therefore, many analogies can be drawn between programming concepts and database concepts as surveyed in [Dearle89] Matthes 89] Moreover, some researchers ....

M.J. Carey et. al. `The Architecture of the EXODUS Extensible DBMS', Proc. Int. Workshop on Object-Oriented Database Systems, Pacific Grove, USA, page 52-65.

....to even leave the data model open. In that case, apparently no system can be offered; instead, a toolkit, a collection of powerful tools for building database systems is provided with tools such as a general storage manager or an optimizer generator. Major proponents of this approach are EXODUS [Care86], GENESIS [Bato88] DASDBS [Sche90] and more recently Volcano [Gr94] In retrospect, the first approach seems to have been more successful than the second. Extensibility by data types within a fixed data model has made it into commercial systems such as Illustra [Illu95] where one can now buy ....

Carey, M.J., D.J. DeWitt, D. Frank, G. Graefe, M. Muralikrishna, J.E. Richardson, and E.J. Shekita, The Architecture of the EXODUS Extensible DBMS. In [Di86], 52-65.

.... POSTGRES, Starburst, andGralarebasedonrelationalmodelwhilePROBEisbasedonfunctionalmodel.Ontheother hand, the other approach considers even the data model as varying and a toolkit is provided for the construction of an application specic database system as demonstrated in GENESIS [11] and EXODUS [24] projects. See Table 1 for a comparative assessment of some of these systems. Extensible data models provide most exibility as far as the view(s) of picture data is concerned. Picture data can be represented as formatted, structured, complex, or unstructured data. New database features such as ....

....produce a tailor made picture retrieval system for an application from a general picture retrieval system without inheriting all the overhead associated with the latter. This naturally leads us to structure and evolve the system toward the approach featured by database generators such as EXODUS [24] and GENESIS [11] Under GENESIS approach, functionality corresponding to each of the requirements of a general picture retrieval system constitutes a primitive building block. A General Picture Retrieval system is expected to provide facilities for describing how to combine these primitive ....

J.M. Carey et al. The architecture of the EXODUS extensible DBMS. In IEEE/ACM International Workshop on Object-Oriented Database Systems, pages 52-65, Pacic Grove, CA., September 1986.

....transactions have changed for complex applications. Initially, traditional transactions were considered as performing simple read or write operations on the database. However, there has been a merger of ideas from object based programming and database systems, resulting in object based databases [14, 22, 73]. Here, transactions and extended transactions perform higher level operations on objects which reside in the database. Using object based databases provides more support for complex applications than having to work with simple read and write operations. 18 3.2 Access and Concurrency Control ....

M. Carey, et al., "The Architecture of the EXODUS Extensible DBMS," Readings in Database Systems, Morgan Kaufmann, 1988, pp. 488-501.

....and attempts to even leave the data model open. In that case, no system is offered; instead, a toolkit, a collection of powerful tools for building database systems is provided, for instance a general storage manager or an optimizer generator. Major proponents of this approach are EXODUS [Care86] and its successor SHORE [Care94] GENESIS [Bato88] DASDBS [Sche90] and Volcano [Gr94] Toolkits have essentially proven to be deadends ; this is at least the view of Carey and DeWitt [CaD96] The main reason was that it was too difficult to construct a DBMS using the toolkit; also the tools ....

Carey, M.J., D.J. DeWitt, D. Frank, G. Graefe, M. Muralikrishna, J.E. Richardson, and E.J. Shekita, The Architecture of the EXODUS Extensible DBMS. In [Di86], 52-65.

....parser, and semantic analyzer. If they are queries or data manipulation commands, they are passed to the query optimizer. Execution plans produced by the optimizer are carried out by the query plan executor. The executor is built on top of the storage system provided by the EXODUS database toolkit [2, 14]. In addition to the standard components, Ariel has a rule manager to handle creation and activation of rules, a rule catalog for maintaining the definitions of rules, a discrimination network for testing rule conditions, a rule execution monitor for carrying out rule execution, and a rule action ....

....to errors where they run non optimal plans, whereas always recompute always runs the optimal plan. A thorough investigation of pre planning strategies vs. always recompute is a potential topic for future investigation. 6 Implementation and Performance Ariel is implemented using the EXODUS toolkit [2, 14] and in particular the E programming language [15] an extension of C with persistent objects. The current version of Ariel consists of about 28000 lines of C E code. Persistent objects simplified implementation of our catalogs and the rule index. The object oriented programming features of ....

M. Carey, D. DeWitt, D. Frank, G. Graefe, J. Richardson, E. Shekita, and M. Muralikrishna. The architecture of the EXODUS extensible DBMS. In Proceedings of the International Workshop on Object-Oriented Database Systems, September 1986.

....will permit easy configuration of new cluster types and will also enable easy re use of lower level abstractions. 3.2 Container Clusters are stored on storage devices like magnetic disks, optical disks or tapes. Several managements techniques have been proposed recently; e.g. the Exodus [6] tree structured layout technique, the Bullet File System [7] contiguous storing technique, the logstructured management technique [8] and the traditional Unix management technique) None of these techniques works well for all classes of applications. For example, a contiguous storing technique ....

M. J. Carey and D. DeWitt, "The architecture of the EXODUS extensible DBMS," in Proc. Int. Workshop on Object-Oriented Database Systems, (Pacific Grove, CA (USA)), pp. 52--65, IEEE, Sept. 1986.

No context found.

Carey, M., et al, "The Architecture of the EXODUS Extensible DBMS" Proc. of the Int'l. Workshop on Object-Oriented Database Sys., Pacific Grove, CA, Sept. 1986.

....to be efficient. A number of database research efforts have recently begun to address the problem of building database systems to accommodate a wide range of potential applications via some form of extensibility. Such projects include EXODUS at the University of Wisconsin [Carey and DeWitt 1985, Carey, et al. 1986b, Carey and DeWitt 1987] PROBE at CCA [Dayal and Smith 1985, Manola and Dayal 1986] POSTGRES at Berkeley [Stonebraker and Rowe 1986, Rowe and Stonebraker 1987] STARBURST at IBM Almaden [Schwarz, et al. 1986, Lindsay, et al. 1987] and GENESIS at UT Austin [Batory, et al. 1986] Although the ....

....are currently developing a data model and an associated query language to serve as starting points for subsequent EXODUS DBMS implementation efforts. In this chapter we describe the object and file management facilities of EXODUS. The initial design of the EXODUS storage manager was outlined in [Carey, et al. 1986a] this is an updated description, reflecting changes in the design that occurred as we developed the (now operational) first version of the system. The chapter is broken down as follows: The next section describes related work on next genera #################################### 1 Actually, ....

[Article contains additional citation context not shown here]

Carey, M., et al, "The Architecture of the EXODUS Extensible DBMS," Proceedings of the International Workshop on Object-Oriented Database Systems, Asilomar, CA, September 1986

No context found.

Carey M J and Dewitt D J, The Architecture of the EXODUS Extensible DBMS, in: Proc. of IEEE International Workshop on Object-Oriented Database Systems (Paci c Grove, CA, 1986) 52-65.

No context found.

M. Carey, D. DeWitt, D. Frank, G. Graefe, J. Richardson, E. Shekita and M. Muralikrishna, `The architecture of the EXODUS extensible DBMS', Proc. International Workshop on Object-Oriented Database Systems, September 1986.

No context found.

M. Carey, D. DeWitt, D. Frank, G. Graefe, M. Muralikrishna, J. Richardson, and E. Shekita. The Architecture of the Exodus Extensible DBMS. In Proc. 146 of the 1st Int'l Workshop on Object-Oriented Database Systems, pages 52-- 65, 1986.

No context found.

M. J. Carey, D. J. DeWitt, D. Frank, G. Graefe, M. Muralikrishna, J. E. Richardson, E. J. Shikita. The Architecture of the EXODUS Extensible DBMS. In Proc. of the 1st Intl. Workshop on Object-Oriented Database Systems, pp. 52-65, Pacific Grove, September 1986.

No context found.

Michael J. Carey, David J. DeWitt, et al. The architecture of the exodus extensible dbms. In Proceedings of the 1986 International Workshop on Object-Oriented Database Systems, pages 52--65, September 1986.

No context found.

Michael J. Carey, David H. DeWitt, Daniel Frank, Goetz Graefe, M. Muralikrishna, Joel E. Richardson, and Eugene Shekita. The architecture of the exodus extensible dbms. In International Workshop on Object-Oriented Database Systems, pages 52--65, 1986.

First 50 documents  Next 50

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