Michael Stonebraker. Managing persistent objects in a multi-level store. In James Cliord and Roger King, editors, Proceedings of the 1991 ACM SIGMOD International Conference on Management of Data, Denver, Colorado, May 29-31, 1991, pages 2-11. ACM Press, 1991.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....be regarded as materialized view of DBMSs. Such kind of application of cache will not contribute to the reduction of network traffic. Thus the objectives is different. 2.3 Multi Level Store for Persistent Objects Another relevant work is multi level store of persistent objects. M. Stonebraker [12] proposed the extension of diskresident database to include multiple storage levels, where time critical objects reside in main memory, other objects Priority Manager Storage Manager Topic Manager Data Analyzer Query Processor Constraint Manager Version Manager Topic Sensor Web Requester ....

M. Stonebraker. Managing persistent objects in a multi-level store. In Proceedings ACM SIGMOD Conference on Management of Data (SIGMOD 1991.

....Segment Cache Manager. archical storage systems. Implementations which interface a hierarchical storage system to a relational database are described in [11] and [20] for example. A proposal for extending POSTGRES to provide support for accessing tertiary storage was made by Stonebraker [27]. A proposal for extending object stores to provide support for accessing tertiary storage for the needs of high energy physics was made by Baden and Grossman [1] Access to data provided by NASA s proposed Earth Observing System also require that databases be interfaced to hierarchical storage ....

M. Stonebraker, "Managing persistent objects in a multi-level store," in , Volume 20, ACM, New York, 1991, pp. 2--11.

....disk and tape devices during joins. ML95] also identifies a number of system factors that have a direct impact on query processing with a focus on single relational operations. 6 User Managed Tertiary Storage The first attempt to integrate tertiary storage into a database system appeared in [Sto91] A three level storage hierarchy was proposed to be under the direct control of a database management system with tertiary storage at the bottom layer. Data could be elevated from tertiary storage to secondary storage via user level commands. Another user level approach is described in [FAD ....

M. Stonebraker. "Managing Persistent Objects in a Multi-Level Store," Proc. of the 1991 SIGMOD Conference, May, 1991.

....to long fields picture and voice, respectively. Some applications may prefer the second view of objects because it is easier to treat the long fields within the same object in different ways; e.g. by applying different compression techniques in storing the picture and the voice attribute [19]. 3 The object representation may also depend on the data model that imposes its own constraints on the object layout. For instance, in an object oriented database system based on C [20] a user has explicit control on wether an object contains another one or points to it; the class person ....

Stonebraker, M. et. al., "Managing Persistent Objects in a Multi-Level Store," Electronics Research Laboratory, University of California at Berkeley, TR M91/16, March 1991.

....is one of the most acceptable indexing options for conventional disk bound operations, it looses some of its appeal when it comes to main memory resident data. Instead, AVL trees can be used as they offer elegant re balancing operations in the light of updates, and logarithmic access times [77]. T trees [52] have been designed for main memory databases and the utilization of their node space is user specified. They also exploit pointers to traverse the tree structure fast. Other structures such as BB Trees, Skip Lists and Deterministic Skip Lists can be used efficiently to access data ....

M. Stonebraker. Managing Persistent Objects in a Multi-Level Store. In Proceedings of the ACM SIGMOD Conference, Denver, Colorado, May 1991.

....from limited expensive (disk) storage and are shifted to economical (tertiary) storage which is, additionally, more durable. At the same time, data can be compressed and can change representation (altered logical access paths or physical data stream layout) to adjust to the new device behavior [27]. Contrary to [6] we do not envision a uniform view of active and archived data as far as visibility is concerned. In PRODAT, one has navigational access to all database objects. Data referenced at run time are transparently restored from the (on line) archive. If there were any EXPRESS like ....

M. Stonebraker. Managing persistent objects in a multi-level store. In ACM SIGMOD, pages 2--11, Denver, 1991.

....the equivalences inv 1 5 is analogous. The approach of [Clu92] retains a separation of DML and programming language; thus, the possibility of non termination or infinite data structures are not considered. Several other groups have introduced object algebras and strategies for their optimisation [Dem94, Lie92, Sha89, Sto91, Van91] with analogous equivalences to those we propose here. In general these algebras are either computationally incomplete or support optimisations for only a subset of their operators. Also, some provide only limited facilities for optimising user defined data types; while others allow few algebraic ....

Stonebraker, M. Managing persistent objects in a multi-level store, Proc. ACM SIGMOD, 1991.

....between disk and tape devices during joins. 23] also identifies a number of system factors that have a direct impact on query processing with a focus on single relational operations. User Managed Tertiary Storage The first attempt to integrate tertiary storage into a database system appeared in [25]. A three level storage hierarchy was proposed to be under the direct control of a database management system with tertiary storage at the bottom layer. Data could be elevated from tertiary storage to secondary storage via user level commands. Another user level approach is described in [26] in ....

M. Stonebraker. "Managing Persistent Objects in a MultiLevel Store," Proc. of the 1991 SIGMOD Conference, May, 1991.

....Java, either as predicates or as general functions. The examples include POSTGRES [SR86] Starburst [HCL 90] Iris [WLH90] and several commercially available systems for instance Informix, DB2, Oracle 8. The issue of expensive predicate optimization was first raised in the context of POSTGRES [Sto91] and a practically applicable theory addressing the returns false, the later two are not evaluated; if it returns true, both others are evaluated. Thus the three picked permutations are equivalent in their complexity to 1 3 2, 2 3 1, and 3 2 1, respectively. Technical Report 98 1718. Department ....

M. Stonebraker. Managing Persistent Objects in a Multi-Level Store. ACM SIGMOD'91.

.... and request scheduling [HS96, NKT97] this includes work with special considerations on the real time requirements of video data [GMW94, LLW95] Motivated by the large data volume in data warehouses, tertiary storage management has also received attention in the context of relational DBMS queries [Sto91, ML97, Sa95, Jo98]. Prefetching in database systems has been studied mostly for applications where future access patterns are largely predictable due to specific structures of the underlying databases and the programs accessing them, especially in objectoriented database systems [CK89, CH91, GK94] but also in ....

Stonebraker M (1991) Managing Persistent Objects in a MultiLevel Store. In: ACM SIGMOD Conf., 1991, Denver, Colo., pp 2--11

....1995; Worthington et al. 1994] the cost is still too high, even prohibitive for applications which require terabytes of data on line. Thus, more and more applications today turn to tertiary devices to store data [Silberschatz et al. 1991; Silberschatz et al. 1996; Carey et al. 1993; Stonebraker, 1991]. Although magnetic tapes have significant cost and density advantages, they are mainly used for backup, and hardly for on line processing systems because accessing data on tape must be sequential. Recently, various issues concerning on line tertiary storage systems have been studied. It was ....

Stonebraker, M. (1991). Managing persistent objects in a multi-level store. In Proceeding of the 1991 ACM SIGMOD International Conference on Management of Data, pages 2--11, Denver.

....of object replacement in the dynamic memory. Current policy takes into account the size of atoms and statistic information (access frequencies) We feel, however, that much more can be won by involving semantic information about objects. This approach, for another environment, is proposed in [Ston91]. Below we present examples of optimizations. Frequently an atom should be included after the last member in a ring. To optimize this kind of operation a special atom type TO END is introduced. This atom is (optionally) included as a first member in a ring; this inclusion is automatically made by ....

M. Stonebraker. Managing Persistent Objects in a Multi-level Store. Proc. of SIGMOD 91 Conf., 1991, pp.2-11

.... request scheduling [HS96, NKT97] this includes work with special considerations on the real time requirements of video data [GMW94, LLW95] Motivated by the large data volume in data warehouses, tertiary storage management has also received attention in the context of relational DBMS queries [Sto91, ML97, Sa95, Jo98]. Prefetching in database systems has been studied mostly for applications where future access patterns are largely predictable due to specific structures of the underlying databases and the programs accessing 7 them, especially in object oriented database systems [CK89, CH91, GK94] but also ....

Stonebraker, M.: Managing Persistent Objects in a Multi-Level Store, ACM SIGMOD Conf., Denver, 1991

....for tertiary memory, a lot of issues related to tertiary memory specific performance optimization still remain unexplored. Inclusion of tertiary memory devices in the storage hierarchy requires a rethinking of many design decisions made for a conventional database system. Many database researchers [1, 11, 5, 8] have reached consensus regarding the need of a database system specially optimized for manipulating data stored on a tertiary memory device. In this paper, we will see how we modified the design of an existing Filesystem Disk cache User Tertiary Memory (a) Only Filesytem Filesystem (c) Only ....

M. Stonebraker. Managing persistent objects in a multi-level store. SIGMOD Record, 20(2):2--11, 1991.

....be treated as an expensive function. Thus the work presented in this paper is applicable to the majority of today s production RDBMSs, which support SQL. 1. 2 Related Work Stonebraker first raised the issue of expensive predicate optimization in the context of the POSTGRES multi level store [Sto91] The questions posed by Stonebraker are directly addressed in this paper, although we vary slightly in the definition of cost metrics for expensive functions. One of the main applications of the system described in [Sto91] is Project Sequoia 2000 [SD92] a University of California project that ....

....predicate optimization in the context of the POSTGRES multi level store [Sto91] The questions posed by Stonebraker are directly addressed in this paper, although we vary slightly in the definition of cost metrics for expensive functions. One of the main applications of the system described in [Sto91] is Project Sequoia 2000 [SD92] a University of California project that will manage terabytes of Geographic Information System (GIS) data, to support global change researchers. It is expected that these researchers will be writing queries with expensive functions to analyze this data. A ....

[Article contains additional citation context not shown here]

Michael Stonebraker. Managing Persistent Objects in a Multi-Level Store. In Proc. ACM-SIGMOD International Conference on Management of Data, pages 2--11, Denver, June 1991.

....By contrast, the LDL approach pulls up expensive predicates from inner inputs in all circumstances. 4. RELATED WORK 4.1 Optimization and Expensive Methods 4.1.1 Predicate Migration. Stonebraker raised the issue of expensive predicate optimization in the context of the POSTGRES multi level store [Stonebraker 1991]. The questions posed by Stonebraker are directly addressed in this paper. Predicate Migration was first presented in 1992 [Hellerstein and Stonebraker 1993] While the Predicate Migration Algorithm presented there was identical to the one described in Section 2.2.4 of this paper, the early paper ....

Stonebraker, M. 1991. Managing Persistent Objects in a Multi-Level Store. In Proc. ACM-SIGMOD International Conference on Management of Data (Denver, June 1991), pp. 2--11.

....be treated as an expensive function. Thus the work presented in this paper is applicable to the majority of today s production RDBMSs, which support SQL. 1. 2 Related Work Stonebraker first raised the issue of expensive predicate optimization in the context of the POSTGRES multi level store [Sto91] The questions posed by Stonebraker are directly addressed in this paper, although we vary slightly in the definition of cost metrics for expensive functions. One of the main applications of the system described in [Sto91] is Project Sequoia 2000 [SD92] a University of California project that ....

....predicate optimization in the context of the POSTGRES multi level store [Sto91] The questions posed by Stonebraker are directly addressed in this paper, although we vary slightly in the definition of cost metrics for expensive functions. One of the main applications of the system described in [Sto91] is Project Sequoia 2000 [SD92] a University of California project that will manage terabytes of Geographic Information System (GIS) data, to support global change researchers. It is expected that these researchers will be writing queries with expensive functions to analyze this data. A ....

[Article contains additional citation context not shown here]

Michael Stonebraker. Managing Persistent Objects in a Multi-Level Store. In Proc. ACM-SIGMOD International Conference on Management of Data, pages 2--11, Denver, June 1991.

....oriented towards this technology. Tertiary memory, if used at all, functioned only as an archival storage system to be written once and rarely read. With the inclusion of tertiary memory as an active part of the storage hierarchy it is necessary to rethink the optimization decisions made by a DBMS [STO91a] [CAR93] In this paper, we propose improvements to existing query execution strategies to adapt them to tertiary storage devices. Tertiary memory devices have very different performance characteristics than magnetic disks. A typical device consists of a large number of storage media (tapes or ....

M. Stonebraker. Managing persistent objects in a multi-level store. SIGMOD Record, 20(2):2--11, 1991.

.... amount of data cannot be stored cost effectively on magnetic disks [SD91, SSU95] In view of applications like EOSDIS and other applications like data warehouses [Ome92] image [RFJ 93, OS95] and video storage systems [FR94] there is increasing consensus among database researchers [SSU95, Sto91a, CHL93, Sel93, Moh93] for supporting tertiary memory devices [Ran91] Not only are all these applications huge, they also require efficient querying and data management facilities, making it necessary to deploy database systems instead of relying on conventional file oriented mass storage systems ....

....We will concentrate our discussion on the use of tertiary memory devices with a DBMS. As a result of the increasing demand for handling larger and larger datasets, the database community started realizing the need for handling tertiary memory devices and many researchers proposed doing so [SSU95, Sto91a, CHL93, Sel93, Moh93] As a result some DBMSs started providing support for storing and accessing data on tertiary memory devices. Such DBMSs can be classified into two categories. The first and the more common category consists of DBMSs that do not exercise direct control of the tertiary memory ....

M. Stonebraker. Managing persistent objects in a multi-level store. Proc. ACM SIGMOD International Conference on Management of Data, 20(2):2--11, 1991.

....allow worthy data to migrate to faster storage. Such migration might simply depend on the algorithms of the underlying file system discussed above to manage storage. However, the DBMS understands the logical structure of the data and can make more intelligent partitioning decisions as noted in [STON91]. The third area where we propose investigations concerns indexing. The conventional DBMS paradigm is to provide value indexing. Hence, one can designate one or more fields in a record as indexed, and POSTGRES will build the appropriate kind of index on the data in the required fields. Value ....

Stonebraker, M., "Managing Persistent Objects in a Multi-level Store," Proceedings 1990 ACM SIGMOD Conference on Management of Data, Denver, CO (1990).

No context found.

Michael Stonebraker. Managing persistent objects in a multi-level store. In James Cliord and Roger King, editors, Proceedings of the 1991 ACM SIGMOD International Conference on Management of Data, Denver, Colorado, May 29-31, 1991, pages 2-11. ACM Press, 1991.

No context found.

Stonebraker, M. Managing persistent objects in a multi-level store, Proc. ACM SIGMOD, Denver, May 1991, 2-11.

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